Observabilidade
A observabilidade da Zenifra ajuda a acompanhar comportamento operacional dos projetos depois do deploy. A disponibilidade de logs e métricas varia conforme o plano contratado.
Escopo: esta página trata de logs e métricas da aplicação em execução. Em projetos GitHub, os logs de build ficam na aba Logs de Build da página do projeto.
Projetos HTTP
Para projetos HTTP, a Zenifra oferece visibilidade de:
- logs da aplicação
- uso de CPU
- uso de RAM
- uso de armazenamento
- quantidade de requisições HTTP recebidas pela aplicação
- tráfego de rede por janela de tempo
- distribuição por status HTTP
- rotas mais acessadas e principais user agents
- latência P95 quando disponível
- eventos de requisição com IP de origem bruto
Esses recursos estão disponíveis em planos Premium ou superiores.
Granularidade e atualização
Logs e métricas são visualizados por instância quando o projeto possui mais de uma instância.
| Recurso | Atualização esperada |
|---|---|
| Logs | até 60 segundos |
| Métricas de recursos | até 5 minutos |
| Tráfego de rede HTTP | até 5 minutos |
Use essa janela de atualização ao investigar deploys recentes, picos de tráfego ou comportamento logo após um restart.
Tráfego de rede HTTP
A visualização de rede agrega o comportamento HTTP do projeto em janelas de 5 min, 1 h, 6 h, 24 h e 7 dias. Use esses filtros para comparar tráfego recente com padrões mais longos sem misturar dados de períodos diferentes.
O painel mostra:
- total de requisições no período
- entrada e saída de dados da aplicação
- latência P95 quando disponível
- distribuição por respostas
2xx,3xx,4xxe5xx - rotas mais acessadas por método e caminho
- principais user agents
- eventos individuais de requisição com IP de origem bruto, rota sanitizada, status e latência
Ao clicar em uma classe de status, como 4xx ou 5xx, o console abre um detalhamento com rotas, user agents e eventos de requisição associados ao filtro. Isso ajuda a investigar erros de cliente, falhas de servidor, IPs de origem envolvidos e endpoints com maior volume.
Privacidade: Eventos de requisição exibem IPs de origem brutos para usuários com acesso às métricas do projeto e ficam retidos por até 7 dias. Query strings e referrers não são armazenados nessa visualização.
Bancos de dados
Projetos PostgreSQL e MariaDB em planos Premium+ têm métricas de recursos e snapshots nativos por instância ou réplica.
| Engine | Grupos nativos |
|---|---|
| PostgreSQL | saúde, conexões, transações, cache de leitura, atividade, locks, latência, WAL/checkpoints, armazenamento e replicação |
| MariaDB | saúde, conexões e threads, atividade, cache de leitura, redo/I/O, locks, latência, armazenamento e replicação |
O cache de leitura representa o cache interno da engine, não o cache do sistema operacional. Campos acumulados são contadores; campos por segundo são taxas calculadas entre amostras. Após reinício ou reset, uma taxa pode ficar indisponível até existir uma nova base válida.
O Console mostra o horário da última coleta e diferencia dados available, partial, stale e unavailable. Campos não suportados ou que não puderam ser calculados aparecem como indisponíveis, nunca como zero sintético.
Essa capacidade oferece o snapshot mais recente. history: null significa que não há retenção de séries nem gráficos históricos. Consulte os detalhes de PostgreSQL, MariaDB e a referência da API.
Projetos Valkey
Projetos Valkey têm um painel separado de observabilidade com identificadores públicos de instância, como instance-1.
O acesso é controlado pela capacidade retornada pelo projeto. Os tiers valkey_realtime, valkey_premium e valkey_enterprise oferecem snapshots; o tier none não oferece acesso. O Console consulta essa capacidade antes de solicitar qualquer snapshot.
Métricas nativas do snapshot
Quando existe um snapshot válido, o contrato nativo do Valkey contém:
| Grupo | Métricas |
|---|---|
| Memória e capacidade | memória usada, pico de memória usada, limite de memória e razão de fragmentação |
| Clientes | clientes conectados e clientes bloqueados |
| Atividade | operações por segundo, taxa de entrada e taxa de saída |
| Ciclo de vida de chaves | chaves expiradas e chaves removidas por eviction |
| Estado da instância | uptime, perfil, instância, versão do schema e disponibilidade |
| Confiabilidade | estado da replicação, réplicas disponíveis, réplicas esperadas, atraso de replicação, estado da persistência e último sucesso da persistência |
As taxas de entrada e saída são expressas em bytes por segundo. Os valores podem ser null quando o dado não estiver disponível ou não houver evidência suficiente para calculá-lo.
Métricas específicas por perfil
- Cache: total de hits, total de misses e hit ratio. O hit ratio é calculado entre snapshots e pode ficar indisponível no primeiro snapshot.
- Key-value: total de chaves e quantidade de chaves com expiração configurada.
- Queue: usa as métricas comuns. Profundidade da fila, idade do item e atraso do consumidor não fazem parte da capacidade verificada.
Console e disponibilidade
No Console, o painel mostra os campos legados de CPU e memória, além de memória usada e limite, clientes conectados, atividade, ciclo de vida de chaves, métricas específicas do perfil, uptime, perfil e instância selecionada.
O contrato da API também retorna pico de memória, fragmentação, clientes bloqueados e os detalhes de replicação e persistência para integrações. Esses campos ainda não têm cards detalhados no painel visual atual.
Quando ainda não existe snapshot, quando a coleta está indisponível ou quando o snapshot é inválido, o Console mostra indisponível e não inventa valores, timestamps ou estados de saúde.
Consulte a capacidade do projeto antes de montar integrações:
GET /v1/project/{id}/metrics/capabilitiesGET /v1/project/{id}/instancesGET /v1/project/{id}/metrics?instance={instance}
Para os tiers com snapshot, a atualização indicada por refresh_seconds é de 60 segundos. O histórico atual é null: não há retenção histórica nem gráficos históricos nessa capacidade.
Recursos ainda não disponíveis
Atualmente, estes itens não estão disponíveis como capacidades documentadas:
- uptime por aplicação
- autoscaling automático
Se esses dados forem necessários para um contrato ou operação crítica, valide a disponibilidade no console e com o suporte antes de depender deles.
Como usar no dia a dia
Use logs da aplicação para entender erro de inicialização, exceções em runtime e problemas de configuração depois que o processo principal já começou.
Use Logs de Build para investigar instalação de dependências, pre-build, build e falhas de publicação do projeto GitHub.
Use métricas de CPU, RAM, storage e requisições HTTP para decidir quando aumentar instâncias, trocar de plano, revisar queries, otimizar cache ou investigar consumo anormal.
Próximos passos
FAQ
Por que os dados não aparecem imediatamente?
Logs e métricas têm janela de atualização. Aguarde alguns minutos após deploy, restart ou pico de tráfego antes de concluir que não há dados.
Métricas substituem monitoramento externo?
Não necessariamente. Para operações críticas, combine métricas da Zenifra com alertas e monitoramento da sua aplicação.
Autoscaling automático está disponível?
Sim, para projetos HTTP em planos com a feature habilitada. O console também mostra o histórico auditável de scale up e scale down, com horário, instâncias e thresholds.