Monitoreo y métricas

sh0 mide el servidor y cada contenedor de aplicación cada 10 segundos y conserva la última hora. Las alertas y las comprobaciones de disponibilidad le avisan cuando algo falla.

Qué se mide

Un recolector lee las estadísticas de Docker y las cifras del host cada 10 segundos y las guarda en la base de datos de sh0. No se envía nada fuera del servidor.

• Servidor -- CPU, memoria usada, porcentaje de memoria, memoria total, uso del disco.
• Cada contenedor de aplicación en marcha -- CPU, memoria usada, memoria como porcentaje de su límite, red recibida y enviada.

Retención

Las métricas se conservan una hora. Las muestras más antiguas las elimina una purga que se ejecuta cada hora. En un servidor en marcha, la última hora de una serie tiene, por tanto, unas 360 muestras (salida real):

$ curl -s -H "Authorization: Bearer $SH0_TOKEN" \
    "https://panel.example.com/api/v1/metrics?metric_type=server_cpu" \
  | jq -c '{n:(.data|length), oldest:([.data[].recorded_at]|min), newest:([.data[].recorded_at]|max)}'
{"n":360,"oldest":"2026-10-02 02:10:27","newest":"2026-10-02 03:10:17"}

Ambos valores son opciones de sh0 serve: --metric-interval (segundos; 0 desactiva la recolección) y --metric-retention (segundos, 3600 por defecto). Para cambiarlos, edite la línea ExecStart del servicio sh0 y reinícielo.

En el panel

• Monitoreo, pestaña Vista general -- CPU, memoria, disco y red actuales del servidor.
• Pestaña Aplicaciones -- las aplicaciones en marcha con su CPU y memoria, ordenables.
• Pestaña Disponibilidad -- las comprobaciones de disponibilidad y sus incidentes (licencia Pro).
• Pestaña Alertas -- las reglas de alerta, con Crear alerta y Probar (licencia Pro).

API de métricas

Las mismas cifras por la API (respuesta real para una aplicación limitada a 256 MB):

$ curl -s -H "Authorization: Bearer $SH0_TOKEN" https://panel.example.com/api/v1/apps/<app-id>/stats
{"data":{"cpu_percent":0.0,"memory_bytes":8355840,"memory_limit_bytes":268435456,"memory_percent":3.11279296875,"network_rx_bytes":3124,"network_tx_bytes":542}}

• GET /api/v1/metrics/server -- cifras actuales del servidor.
• GET /api/v1/apps/<id>/stats -- cifras actuales de una aplicación, como arriba; GET /api/v1/apps/stats para todas a la vez; GET /api/v1/apps/<id>/metrics -- las muestras guardadas de una aplicación.
• GET /api/v1/metrics -- muestras guardadas, filtradas por app_id, metric_type (cpu, memory, memory_percent, network_rx, network_tx, server_cpu, server_memory, server_memory_percent, server_disk…) y since.

Alertas

Las alertas requieren una licencia Pro o superior. Créelas desde Monitoreo, Alertas, o por la API. channel_config es un objeto JSON pasado como cadena (respuesta real):

$ curl -X POST https://panel.example.com/api/v1/alerts \
    -H "Authorization: Bearer $SH0_TOKEN" -H "Content-Type: application/json" \
    -d '{"app_id":"<app-id>","alert_type":"high_memory","threshold":90,"channel":"webhook","channel_config":"{\"url\":\"https://hooks.example.com/sh0\"}"}'
{"data":{"alert_type":"high_memory","app_id":"<app-id>","channel":"webhook","channel_config":"{\"url\":\"https://hooks.example.com/sh0\"}","created_at":"2026-10-02 03:10:54","enabled":true,"id":"ca506b3d-b91a-4ca3-941e-be42c6ad2ef3","last_fired":null,"threshold":90.0}}

Una alerta con app_id requiere el rol developer en el proyecto de esa aplicación; una alerta sin él abarca todo el servidor y requiere el rol admin u owner. Quien tiene el rol viewer ve la alerta sin su channel_config, que contiene las credenciales.

Tipos de alerta

• high_cpu, high_memory -- la última muestra supera threshold (un porcentaje). Se evalúan cada 30 segundos; una alerta disparada se queda en silencio 5 minutos.
• app_down -- ninguna muestra de CPU de la aplicación en los últimos 30 segundos, lo que ocurre cuando su contenedor no está en marcha.
• disk_full -- se comprueba cada 15 minutos contra el threshold de la alerta, u 80 % si no tiene; el mismo aviso no se reenvía antes de 6 horas. Por encima del 90 %, los despliegues se rechazan.
• deploy_failed -- se envía cuando falla un despliegue de la aplicación.
• uptime, uptime_down, uptime_up -- las envían las comprobaciones de disponibilidad (más abajo).
• ssl_expiry -- Desde 1.10.3: se activa cuando un certificado de la aplicación de la alerta (o de cualquier dominio, sin aplicación) caduca en menos días que el umbral, 14 por defecto. El umbral es un número de días, no un porcentaje. Se evalúa sobre el certificado que sh0 guarda en disco; las direcciones *.sh0.app y los certificados que haya subido usted no están cubiertos. Se envía como máximo una vez al día por alerta.

Canales de notificación

• email -- recipients, una lista de direcciones. El correo sale por el servidor SMTP configurado para el servicio sh0 con las variables de entorno SH0_SMTP_HOST, SH0_SMTP_PORT (587 por defecto), SH0_SMTP_USER, SH0_SMTP_PASSWORD, SH0_SMTP_FROM y SH0_SMTP_TLS; sin ellas no se envía ningún correo.
• slack, discord -- webhook_url, la URL del webhook entrante del canal.
• telegram -- bot_token y chat_id.
• webhook -- url, y opcionalmente secret y headers. sh0 envía un POST JSON; con un secreto, la cabecera X-sh0-Signature: sha256=… lleva un HMAC del cuerpo.

Probar (POST /api/v1/alerts/<id>/test) envía una notificación de ejemplo por el canal configurado; está limitado a 10 pruebas por minuto y usuario.

Comprobaciones de disponibilidad

Una comprobación de disponibilidad consulta una URL a intervalos fijos y abre un incidente cuando falla varias veces seguidas. Créela desde la pestaña Disponibilidad de la aplicación o desde Monitoreo: método GET o HEAD, intervalo de 10 a 86 400 segundos, tiempo de espera de 1 a 30 segundos, código de estado esperado y umbral de fallos. Requieren una licencia Pro; sus notificaciones pasan por las alertas de tipo uptime.