Carregando página
Carregando conteúdo
Disponibilidade, ocorrências e desempenho da operação.
Visão geral da operação
dependências não lidasAgora
Disponibilidade e tempo de resposta dessas duas conexões. Esta verificação não avalia todas as funções do aplicativo.
Agora
o que o processo sabe sobre si (emissão, dreno, pendência) somado ao que o banco sabe (último registro, total na retenção)
O painel não conseguiu ler /admin/telemetry/status. Enquanto isso, nenhum vazio desta página pode ser lido como zero: não se sabe se alguém está medindo.
Emissão
não lido
a leitura do processo não voltou — não é "desligada"
Consumidor
não lido
a leitura do processo não voltou — não é "desligado"
Pendentes no stream
não sei
com o consumidor desligado não há consumer group para perguntar
Eventos na retenção
não lido
a consulta ao banco não voltou — o total pode ser qualquer um
No período selecionado
Veja o que merece verificação e o que o sistema tratou. Abra uma situação para entender o próximo passo.
Evolução no período
O tamanho do intervalo vem com a série, e a série não voltou — então nem o passo da coleta é conhecido agora. As barras somariam os registros por intervalo; as linhas mostram o tempo das operações.
Infra
amostragem do painel a cada 15 s — a API não guarda histórico de probe, então esta série nasce quando a aba abre
ida e volta medida pelo painel · probe sem resposta aparece como buraco, não como zero
Nenhuma amostra ainda — a primeira chega em até 15 s, e a série cresce enquanto esta aba ficar aberta.
o que o console do dock mostra aqui e esta API ainda não serve
Não instrumentado. /health/deep devolve {ok, latencyMs} por dependência e nada além — não há ocupação do pool, conexões recusadas nem memória do Postgres.
Ocupação do pool é o número que antecipa saturação: latência alta com pool folgado é consulta ruim, e latência alta com pool no teto é fila. As duas pedem consertos diferentes, e sem o denominador o painel não sabe qual dos dois está vendo. Pedido registrado em DEPENDENCIAS-API.md.
Aplicação
Aplicação
inventário canônico dos ramos perdedores: o que cada pico significa, com que etiquetas ele agrega e onde ele é emitido
Lacunas
as seções do console de referência que não têm fonte nesta API — declaradas em vez de desenhadas vazias
volume, latência e status das respostas HTTP
Não instrumentado — e por decisão, não por esquecimento.
O critério está escrito no próprio catálogo de telemetria: o que se instrumenta aqui é ramo perdedor — o lugar onde o sistema descobre que perdeu uma corrida —, e não contagem de requisição nem uso de CPU, “para isso existem ferramentas melhores e mais baratas”. Não há interceptor de HTTP somando rota, bucket e classe de status, então não há rollup de rota, nem distribuição de 2xx a 5xx, nem vazão.
Para existir: um contador por (rota, método, classe de status) com p95 por bucket, e uma rota de leitura na mesma janela da telemetria. Enquanto não existir, a taxa de erro da API não é uma pergunta que esta tela possa responder.
o que morre no aparelho ou na rede antes de chegar à API
Não instrumentado. Nenhuma rota recebe relato do app nem do web.
É a falha que nenhum servidor vê: requisição que não saiu do aparelho, timeout de rede do lado de fora, tela que quebrou antes do primeiro fetch. O sistema pode estar perfeito nos gráficos acima e inutilizável para uma parte dos usuários — e nada nesta tela contradiria isso.
Para existir: um POST de relato de erro de cliente, com conjunto fechado de rótulos (plataforma, versão, tipo de falha) pelo mesmo motivo do catálogo — id de usuário ou de sessão transformaria série temporal em dump.
Para não haver dois números diferentes para o mesmo gasto, este painel não soma custo por conta própria. FinOps mostra a origem de cada valor — medido ou estimado —, a série no tempo, o detalhamento por operação e modelo, e os maiores consumidores.
Abrir FinOpsCuidado em movimento.