Início / Serviços / Observabilidade & monitoração
Serviço

Observabilidade que vai do alerta até a linha de código

Métricas, logs, traces e monitoramento de usuário real numa plataforma única e aberta. O time abre o log do erro, clica no traceId e chega à requisição inteira — até o método, a classe e a exceção que dispararam o evento. Sem cobrança por host, por GB ingerido ou por assento.

Alertmanager · disparo
[FIRING] HighErrorRate
service portal-backend
valor 6.2% de 5xx (limite 1%)
desde 14:21:38
// do alerta ao código em 3 cliques:
alerta → log → trace → classe

Quatro sinais, uma única tela

Monitoração tradicional responde "está no ar?". Observabilidade responde "por que está lento e onde exatamente quebrou?". Para isso, os quatro sinais precisam conversar entre si — e é isso que montamos.

Métricas

O que está acontecendo

Séries temporais de CPU, memória, disco, latência, taxa de erro e filas — a base dos alertas e dos painéis de capacidade.

Prometheus
Logs

O que o sistema disse

Logs de todos os contêineres e servidores centralizados, indexados por label e pesquisáveis por período, serviço e nível.

Loki
Traces

Por onde a requisição passou

A requisição inteira em cascata: cada serviço, cada método instrumentado, cada query — com o tempo gasto em cada etapa.

Tempo
RUM

O que o usuário viveu

Erros de JavaScript, Web Vitals e sessões capturados no navegador do usuário real — não em teste sintético.

Grafana Faro
O diferencial

Loki + Tempo: do log de erro até a classe que disparou o evento

Log solto conta que algo falhou. Trace conta a história inteira daquela requisição. Quando os dois estão correlacionados, o desenvolvedor deixa de reconstituir o incidente por dedução: ele clica no traceId da linha de log e cai direto na cascata de spans — o serviço, o método, a query e a exceção com o stack trace. É o recurso pelo qual as plataformas SaaS cobram caro, e ele funciona igualmente bem numa stack aberta bem montada.

1
O usuário reclama (ou o alerta dispara) "Deu erro ao salvar o pedido, às 14h22." O Faro já registrou o erro no navegador com o ID da sessão e a URL exata.
2
O log aparece com traceId Toda linha de log carrega o identificador do trace como metadado — sem parser frágil, sem regex adivinhando formato.
3
Um clique abre o trace no Tempo O Grafana transforma o traceId em link. A requisição inteira abre em cascata, com o tempo gasto em cada etapa.
4
O span aponta a classe e a exceção Controller, service, repositório, SQL executado e o stack trace com arquivo e linha. O caminho de volta também existe: de qualquer span, um clique lista os logs daquele momento.
Grafana · Explore · Loki  {app="portal-backend"} |= "ERROR"
14:22:07.413 ERROR portal-backend Falha ao salvar pedido 88214
traceId=4f9c1a7e8b02d3f5 usuario=m.souza
↳ clique no traceId abre o trace no Tempo
Grafana · Explore · Tempo  trace 4f9c1a7e8b02d3f5 · 812 ms
POST /api/pedidos 812 ms
  PedidoController.salvar 784 ms
    PedidoService.processar 701 ms
      EstoqueClient.reservar 183 ms
      PedidoRepository.save erro · 462 ms
        SQL INSERT INTO pedidos 441 ms
span.status=ERROR
PSQLException: duplicate key value violates "pedidos_numero_key"
at br.com.apcode.pedido.PedidoRepository.save(PedidoRepository.java:88)
Correlação nos dois sentidos Log → trace e trace → log. Você entra pelo sinal que tiver em mãos e chega ao mesmo lugar.
Do navegador ao banco O trace começa no clique do usuário no frontend e segue no backend — é o mesmo trace de ponta a ponta.
Lentidão também tem culpado A cascata mostra onde os milissegundos foram gastos: a query N+1, a API externa lenta, o lock no banco.

O que muda na hora do incidente

A diferença não está em ter gráfico bonito, e sim em quanto tempo o time leva do "está fora" ao "achei a causa".

Sem observabilidade correlacionada

  • O usuário avisa antes do monitoramento — quando avisa.
  • Alguém entra por SSH em cada servidor e faz grep em arquivo de log.
  • O log diz "erro ao processar", mas não diz de qual requisição, de qual usuário, nem em qual serviço começou.
  • Time de frontend e de backend discutem de quem é o problema, sem dado que decida.
  • Lentidão intermitente vira mistério: some antes de alguém conseguir reproduzir.
  • Cada incidente é investigado do zero, porque nada ficou registrado de forma pesquisável.

Com a stack que entregamos

  • O alerta chega antes do usuário, com o serviço e o sintoma já identificados.
  • Busca de log centralizada, por serviço e período — sem acessar servidor nenhum.
  • Do log ao trace em um clique: requisição completa, método, query e exceção com arquivo e linha.
  • O trace atravessa frontend e backend, então a fronteira da falha é fato, não opinião.
  • Intermitência fica registrada: o trace lento de ontem às 3h ainda está lá para análise.
  • Painéis e alertas versionados em Git — o conhecimento do incidente vira ativo do time.

A mesma capacidade das plataformas SaaS, sem o modelo de cobrança delas

Datadog, New Relic e similares são excelentes produtos — o problema costuma ser a conta. A cobrança é por host, por GB ingerido, por sessão de RUM, por métrica personalizada e por usuário, então ela cresce justamente quando o ambiente cresce ou quando o incidente aumenta o volume de log. A stack aberta inverte isso: o custo é o da infraestrutura que você já tem, mais a operação.

Aspecto Stack aberta (APcode) SaaS por consumo (Datadog / New Relic)
Modelo de cobrança Sem licença. Custo é o do servidor/armazenamento que roda a stack, mais o serviço de operação Por host, por GB ingerido, por sessão de RUM, por métrica personalizada, por assento
Previsibilidade Fixa: o gasto muda quando você decide mudar capacidade ou retenção Variável: um incidente que multiplica o log multiplica a fatura do mês
Efeito colateral no time Ninguém corta log ou trace por medo do custo Amostragem e corte de log viram prática comum para segurar a conta
Onde ficam os dados Na sua infraestrutura, sob a sua política de retenção e LGPD Na nuvem do fornecedor, geralmente fora do país
Instrumentação OpenTelemetry — padrão aberto, portável entre backends Agente proprietário; migrar depois exige reinstrumentar
Retenção longa Decisão sua: mais disco custa disco Item de preço à parte, normalmente caro
Esforço inicial Maior: alguém precisa montar e manter a stack (é o nosso papel) Menor: instalar agente e começar
Manutenção Atualizações, capacidade e backup ficam com você ou conosco Por conta do fornecedor
Risco de dependência Baixo: componentes abertos, dados e dashboards seus Alto: painéis, alertas e instrumentação presos ao formato do fornecedor

Sendo justos: se o seu time é grande, o ambiente é enorme e ninguém quer operar a plataforma, o SaaS pode compensar. Nossa proposta é para quem quer o mesmo nível de diagnóstico com custo previsível — e não quer descobrir no fim do mês que investigar um incidente saiu caro.

O que entregamos no projeto

Stack completa provisionada como código, integrada às suas aplicações e com o time treinado para usar — não só instalada.

Stack provisionada como código

Prometheus, Loki, Tempo, Grafana e coletor (Alloy/OTel) implantados via manifestos versionados, com armazenamento persistente e retenção definida com você.

Correlação log ↔ trace ↔ métrica

A ligação entre os sinais configurada e testada nos dois sentidos — o clique do log para o trace e do span de volta para os logs daquele intervalo.

Instrumentação das aplicações

OpenTelemetry nas suas aplicações (Java/Spring, Node, Python, .NET), com propagação de contexto e o traceId injetado no padrão de log — em geral sem alterar regra de negócio.

Monitoramento de usuário real

SDK no frontend capturando erros de JavaScript, Web Vitals e sessões, com o trace do navegador amarrado ao trace do backend.

Dashboards que o time usa

Painéis de disponibilidade, latência, erro e capacidade — por serviço e por banco — versionados em Git, não montados na mão e esquecidos.

Alertas acionáveis

Regras com limiar e janela pensados para evitar alarme falso, entregues por WhatsApp, e-mail ou chat — cada alerta com o que olhar primeiro.

Acesso controlado e LGPD

Grafana atrás de autenticação corporativa, TLS em todos os endpoints de coleta e cuidado com dado sensível em log — o que não pode ser coletado, não é.

Treinamento do time

Sessão prática com os desenvolvedores: como buscar no Loki, ler uma cascata de spans e sair do alerta até a classe. Observabilidade que ninguém usa não vale nada.

O que passa a ser monitorado

Da máquina física ao clique do usuário — cada camada com o sinal que faz sentido para ela.

Servidores e rede

CPU, memória, disco, saturação de I/O e disponibilidade de cada nó, com alerta antes de o disco encher.

Cluster e contêineres

Estado dos nós, pods reiniciando, limites de recurso estourando e deploys que não estabilizaram.

Bancos de dados

Conexões, locks, consultas lentas, replicação e crescimento — com painel dedicado por instância.

Aplicações

Latência, taxa de erro e throughput por endpoint, filas de processamento e jobs agendados que falharam em silêncio.

Frontends

Erros de JavaScript em produção, tempo de carregamento percebido e a jornada da sessão até o erro.

Certificados e rotinas

Validade de TLS, execução de backups e tarefas críticas — o tipo de falha silenciosa que só aparece no pior dia.

Como o projeto acontece

Em poucas semanas o time sai do "descobrimos pelo cliente" para "o alerta chegou e já sabemos onde olhar".

1
Mapeamento

Levantamos serviços, dependências, incidentes recorrentes e o que hoje passa despercebido — daí saem os primeiros alertas.

2
Plataforma

Subimos a stack, definimos retenção e capacidade, publicamos o Grafana com acesso controlado e ligamos as fontes entre si.

3
Instrumentação

Aplicações e frontends passam a emitir métricas, logs com traceId e traces, validando a correlação ponta a ponta.

4
Rotina e ajuste

Afinamos alertas com base nos incidentes reais, treinamos o time e evoluímos os painéis conforme o sistema muda.

A stack que colocamos em pé

Tudo aberto, padrão de mercado e sem agente proprietário. É a mesma stack que usamos na nossa própria infraestrutura — inclusive na correlação log↔trace descrita acima.

Prometheus Loki Tempo Grafana Grafana Alloy Grafana Faro (RUM) OpenTelemetry Alertmanager node-exporter postgres-exporter kube-state-metrics Ansible & Terraform

O que perguntam antes de começar

Bem menos do que se imagina. Em Java/Spring, boa parte vem da instrumentação automática do OpenTelemetry: requisições HTTP, chamadas a banco, clientes REST e filas já são rastreados sem alterar código. O que costuma exigir ajuste é o padrão de log — para que o traceId apareça em toda linha — e a criação de spans manuais em trechos de negócio que você queira ver na cascata. No frontend, é inicializar o SDK e propagar o cabeçalho de trace.

Menos do que a fama sugere. Loki indexa apenas os rótulos (e não o conteúdo de cada linha) e o Tempo guarda traces em blocos baratos — é por isso que essa combinação roda bem em servidor próprio, sem cluster dedicado de busca. O dimensionamento sai do volume real: número de serviços, requisições por segundo, taxa de amostragem de traces e quantos dias de retenção você quer. Fazemos essa conta no diagnóstico, junto com a política de retenção.

Não necessariamente — as coisas resolvem problemas diferentes. Ferramentas clássicas são fortes em disponibilidade de infraestrutura ("o host responde?"). O que entregamos ataca a camada de aplicação: por que a requisição demorou, em qual serviço quebrou, qual classe lançou a exceção. Dá para conviver, integrando os alertas num canal único, ou consolidar tudo no Grafana. Avaliamos o que já existe antes de propor troca.

Funciona. A stack roda em Kubernetes, em Docker Swarm ou direto em máquinas virtuais com o coletor instalado como serviço. O modelo de coleta é o mesmo; muda só a forma de implantar. Se o ambiente ainda não é containerizado, isso também não é pré-requisito — veja a página de Kubernetes & contêineres se os dois assuntos estiverem na mesa.

É tratado no desenho, não depois do vazamento. Definimos junto o que não pode ser coletado (senha, token, CPF, dado de cartão), aplicamos filtro e mascaramento no coletor, restringimos acesso ao Grafana por autenticação corporativa e ciframos o transporte. Como tudo fica na sua infraestrutura, o dado não sai do seu perímetro — o que simplifica bastante a conversa de LGPD.

Você, seu time ou nós — a escolha é sua. Tudo é entregue versionado em repositório Git, com dashboards e alertas como código, e passamos o conhecimento em uma sessão de handover. Para quem prefere não se preocupar, oferecemos operação contínua: acompanhamos os alertas, mantemos as versões em dia e ajustamos os painéis conforme o sistema evolui.

Quanto tempo seu time gasta para achar a causa de um erro?

Se a resposta for "horas", há muito a ganhar aqui. Vamos conversar sobre o seu ambiente — diagnóstico sem compromisso.

Falar com um especialista