Monitoramento e métricas

O sh0 mede o servidor e cada contêiner de app a cada 10 segundos e guarda a última hora. Alertas e verificações de disponibilidade avisam quando algo dá errado.

O que é coletado

Um coletor lê as estatísticas do Docker e os números do host a cada 10 segundos e as grava no banco de dados do sh0. Nada é enviado para fora do servidor.

• Servidor -- CPU, memória usada, porcentagem de memória, memória total, uso de disco.
• Cada contêiner de app em execução -- CPU, memória usada, memória como porcentagem do limite, rede recebida e enviada.

Retenção

As métricas são mantidas por uma hora. Amostras mais antigas são apagadas por uma limpeza que roda a cada hora. Num servidor em funcionamento, a última hora de uma série tem cerca de 360 amostras (saída 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"}

Os dois valores são opções de sh0 serve: --metric-interval (segundos; 0 desativa a coleta) e --metric-retention (segundos, padrão 3600). Para mudá-los, edite a linha ExecStart do serviço sh0 e reinicie-o.

No painel

• Monitoramento, aba Visão geral -- CPU, memória, disco e rede atuais do servidor.
• Aba Aplicativos -- os apps em execução com CPU e memória, ordenáveis.
• Aba Disponibilidade -- verificações de disponibilidade e seus incidentes (licença Pro).
• Aba Alertas -- regras de alerta, com Criar alerta e Testar (licença Pro).

API de métricas

Os mesmos números pela API (resposta real para um app limitado 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 -- números atuais do servidor.
• GET /api/v1/apps/<id>/stats -- números atuais de um app, como acima; GET /api/v1/apps/stats para todos de uma vez; GET /api/v1/apps/<id>/metrics -- as amostras guardadas de um app.
• GET /api/v1/metrics -- amostras guardadas, filtradas por app_id, metric_type (cpu, memory, memory_percent, network_rx, network_tx, server_cpu, server_memory, server_memory_percent, server_disk…) e since.

Alertas

Alertas exigem licença Pro ou superior. Crie-os em Monitoramento, Alertas, ou pela API. channel_config é um objeto JSON passado como string (resposta 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}}

Um alerta com app_id exige o papel developer no projeto desse app; um alerta sem ele vale para o servidor inteiro e exige o papel admin ou owner. Quem tem o papel viewer vê o alerta sem o channel_config, que contém as credenciais.

Tipos de alerta

• high_cpu, high_memory -- a amostra mais recente passa de threshold (uma porcentagem). Avaliados a cada 30 segundos; um alerta disparado fica em silêncio por 5 minutos.
• app_down -- nenhuma amostra de CPU do app nos últimos 30 segundos, o que acontece quando o contêiner não está rodando.
• disk_full -- verificado a cada 15 minutos contra o threshold do alerta, ou 80% sem ele; o mesmo aviso não é reenviado antes de 6 horas. Acima de 90%, as implantações são recusadas.
• deploy_failed -- enviado quando uma implantação do app falha.
• uptime, uptime_down, uptime_up -- enviados pelas verificações de disponibilidade (abaixo).
• ssl_expiry -- Desde a 1.10.3: dispara quando um certificado do aplicativo do alerta (ou de qualquer domínio, sem aplicativo) expira em menos dias que o limite, 14 por padrão. O limite é um número de dias, não uma porcentagem. Avaliado sobre o certificado que o sh0 guarda em disco; endereços *.sh0.app e certificados enviados por você não são cobertos. Enviado no máximo uma vez por dia por alerta.

Canais de notificação

• email -- recipients, uma lista de endereços. O e-mail sai pelo servidor SMTP configurado para o serviço sh0 com as variáveis de ambiente SH0_SMTP_HOST, SH0_SMTP_PORT (587 por padrão), SH0_SMTP_USER, SH0_SMTP_PASSWORD, SH0_SMTP_FROM e SH0_SMTP_TLS; sem elas, nenhum e-mail é enviado.
• slack, discord -- webhook_url, a URL do webhook de entrada do canal.
• telegram -- bot_token e chat_id.
• webhook -- url, e opcionalmente secret e headers. O sh0 envia um POST JSON; com um segredo, o cabeçalho X-sh0-Signature: sha256=… traz um HMAC do corpo.

Testar (POST /api/v1/alerts/<id>/test) envia uma notificação de exemplo pelo canal configurado; o limite é de 10 testes por minuto por usuário.

Verificações de disponibilidade

Uma verificação de disponibilidade consulta uma URL em intervalo fixo e abre um incidente quando ela falha várias vezes seguidas. Crie-a na aba Disponibilidade do app ou em Monitoramento: método GET ou HEAD, intervalo de 10 a 86.400 segundos, timeout de 1 a 30 segundos, código de status esperado e limite de falhas. Exigem licença Pro; suas notificações passam pelos alertas do tipo uptime.