Pular para conteúdo

Telemetria e monitoramento

A central ajuda a responder duas perguntas: o endereço está respondendo? e o servidor tem recursos para executar a aplicação? Use os dados para localizar o problema; confirme o funcionamento pelo fluxo real do produto.

Acesso

Abra o Grafana da Bravonix e selecione o painel Parque — disponibilidade e infraestrutura. Solicite acesso à equipe responsável. Senhas e tokens não ficam nesta wiki.

O Coolify da telemetria administra a central. O domínio otel-telemetry.bravonix.ia.br recebe dados dos agentes; não é a interface de consulta.

Como os dados chegam

flowchart LR
    VM["Servidores e containers"]
    A["Agente OpenTelemetry<br/>Coleta métricas"]
    U["URLs monitoradas"]
    C["Collector central<br/>Recebe dados e verifica URLs"]
    P[("Prometheus<br/>Armazena métricas")]
    G["Grafana<br/>Exibe os painéis"]
    VM --> A
    A -->|"HTTPS autenticado"| C
    C -->|"Verificação HTTP"| U
    C --> P
    P --> G

OpenTelemetry Collector é o processo que recebe e encaminha a coleta. Prometheus guarda as séries numéricas. Grafana apresenta os dados em gráficos e tabelas.

A central também tem Loki, armazenamento de logs. O painel instalado inclui uma seção para consultá-los, mas a cobertura real de envio de logs ainda precisa ser validada. A existência dessa seção não comprova que cada máquina esteja enviando registros.

Estado conferido em 05/10/2026

Item Evidência desta revisão
Central Grafana, Collector, Prometheus e Loki com verificações de saúde aprovadas no Docker
Métricas de servidores 25 VMs com CPU recente; todas com amostras de menos de 90 segundos na consulta
Métricas de containers 495 combinações de servidor e container com métrica de memória na consulta
URLs 37 endereços com registro nos últimos 35 minutos; isso não significa 37 endereços saudáveis
Retenção do Prometheus 15 dias, conferidos na configuração em execução
Painel Nome, filtros e seções conferidos no arquivo instalado no container do Grafana

Esses números são uma fotografia da consulta, não uma garantia de cobertura permanente. O inventário de 17/09 registrava 28 VMs e 541 containers; a contagem atual é menor. Ausência de métricas não comprova que a máquina esteja desligada ou que o serviço tenha sido encerrado.

Limites da conferência

Métricas foram consultadas diretamente no Prometheus em execução. O acesso autenticado à interface do Grafana, o recebimento de notificações, a cobertura de logs e a restauração dos backups não foram validados nesta revisão.

Como usar o painel

  1. Escolha o período que inclui o problema e alguns minutos anteriores.
  2. Selecione Ambiente, Nuvem e VM. Para investigar containers, ajuste também Tipo de container.
  3. Comece por Última coleta por máquina. Dados antigos podem parecer estáveis mesmo quando a coleta parou.
  4. Compare CPU, memória e disco no horário do problema.
  5. Abra Detalhe dos containers e Containers reiniciando (janela selecionada) para localizar o processo afetado.
  6. Se houver logs disponíveis para a máquina, use Logs das máquinas selecionadas e Filtro de log.

Painéis identificados como todo o parque podem mostrar um escopo maior que a VM selecionada. Leia o título antes de atribuir um alerta ao servidor investigado.

O que cada indicador responde

Indicador Como interpretar
Última coleta Se as métricas chegaram recentemente; sem isso, os demais gráficos podem enganar
CPU e load por vCPU Se há pressão de processamento; compare com o horário e a duração do problema
Memória e swap Se o servidor está ficando sem memória ou recorrendo ao disco
Disco Ocupação e crescimento; a tendência importa antes de atingir o limite
Memória contra o limite do container Quanto do limite configurado o processo consome
Memória em relação à RAM da máquina Participação no total do servidor; é uma medida diferente do limite do container
Reinícios Se houve reinícios na janela selecionada; investigar os logs para descobrir a causa
Estado por URL e motivo Resultado da verificação HTTP; não substitui login, consulta ao banco ou tarefa real
Certificados TLS Validade dos certificados dos alvos acompanhados

Não interprete um gráfico vazio como zero consumo. Confira filtros, período, última coleta e existência da métrica. Alguns indicadores dependem de coletores opcionais; a seção de métricas de aplicação do Traefik está identificada no painel como aguardando esse job.

Métricas, logs e chamadas de IA

flowchart TD
    Q{"O que precisa investigar?"}
    Q --> M["Consumo, disponibilidade<br/>ou reinícios"]
    Q --> L["Mensagem de erro<br/>de um processo"]
    Q --> I["Etapas, tempo ou consumo<br/>de uma chamada de IA"]
    M --> G["Grafana e Prometheus"]
    L --> C["Logs do recurso no Coolify<br/>ou Loki, se houver coleta"]
    I --> F["Langfuse<br/>no projeto do ambiente"]

Métricas mostram o comportamento ao longo do tempo. Logs registram mensagens dos processos. O Langfuse acompanha chamadas de IA nos fluxos integrados. Configurar um desses caminhos não configura automaticamente os outros.

Investigação depois de um deploy

flowchart TD
    D["Falha percebida depois do deploy"]
    V["Conferir versão e resultado<br/>da publicação no Coolify"]
    R{"As métricas são recentes?"}
    A["Investigar agente, conexão<br/>e Collector central"]
    M["Comparar CPU, memória,<br/>disco e reinícios"]
    L["Correlacionar com logs<br/>e horário da publicação"]
    T["Testar o fluxo afetado<br/>na aplicação"]
    D --> V --> R
    R -->|"Não"| A
    R -->|"Sim"| M --> L --> T

Comece pelo fluxo de build e publicação: imagem enviada ao registry não significa versão nova em execução. Se a publicação terminou, procure mudanças no mesmo intervalo de tempo.

Não reinicie o servidor inteiro como primeiro teste. Identifique o recurso afetado e preserve os registros que ajudam a explicar a falha. Consumo normal de infraestrutura não elimina erro de configuração, banco ou provedor externo.

Alertas e falta de dados

Os cartões do painel são sinais para investigação. Um cartão vermelho não comprova que alguém recebeu uma notificação. Destinatários, canais e entrega de alertas precisam de validação própria.

Na revisão, o Prometheus carregava dois grupos com cinco regras de cálculo para URLs e certificados. Elas produzem séries derivadas; não são prova de envio de alerta. Regras e canais do Grafana não foram confirmados.

Quando uma VM desaparecer, confira também o inventário esperado. Contadores baseados somente nas séries ainda presentes podem deixar de representar uma máquina que parou de enviar dados há mais tempo. Para máquinas temporárias, diferencie desligamento esperado de perda de coleta.

Retenção, backup e recuperação

A retenção de 15 dias do Prometheus limita o histórico disponível; não é backup. Gráficos antigos desaparecem conforme a retenção, mesmo com a central saudável.

O último registro de implantação informava backup externo pendente. Nesta revisão, não foi comprovada uma rotina de cópia externa nem uma restauração. Portanto, a recuperação dos dados da central permanece sem validação.

Antes de manutenção, preservar dados persistentes e configuração. Não usar remoção de volumes como forma de corrigir o painel: ela pode apagar o histórico e o estado dos serviços. A recuperação deve ser ensaiada em destino separado, incluindo fontes de dados, painel e acesso, sem substituir a central ativa.