Monitorar é saber que o servidor caiu. Observar é entender por que ele caiu, o que aconteceu antes e o que vai acontecer a seguir. Essa diferença, que parece sutil no papel, separa operações que resolvem incidentes em minutos daquelas que passam horas tentando reproduzir o problema. A stack aberta formada por Prometheus, Loki e Grafana — com Tempo para traces — cobre os três pilares de observabilidade com custo operacional muito abaixo de qualquer SaaS de monitoramento equivalente.
Resumo rápido: Observability é a capacidade de inferir o estado interno de um sistema a partir de suas saídas externas: métricas, logs e traces. Prometheus coleta métricas, Loki agrega logs, Tempo rastreia spans distribuídos e o Grafana os exibe de forma unificada. Juntos, eliminam o ciclo de adivinhação durante incidentes e permitem alertas precisos com contexto suficiente para agir.
Monitorar e observar não são a mesma coisa
Monitoramento tradicional funciona por threshold: se CPU passa de 90%, dispara alerta. O problema é que esse modelo pressupõe que você sabe, antes do incidente, qual métrica vai importar e qual valor é crítico. Em sistemas distribuídos — qualquer combinação de containers, workers, filas e bancos — você nunca sabe com antecedência todas as formas que uma falha pode assumir.
Observability inverte o raciocínio: em vez de definir o que checar, você coleta dados ricos o suficiente para responder qualquer pergunta no futuro, inclusive as que você não imaginou agora. Métricas dão o "o quê" (latência subiu). Logs dão o "quando e onde exatamente" (qual request, qual função, qual linha). Traces dão o "caminho completo" (esse request passou por 7 serviços; o gargalo está no terceiro).
A diferença prática: monitoramento avisa que há fumaça. Observability mostra onde está o fogo.
Os três pilares: Prometheus, Loki e Tempo
Cada ferramenta resolve um problema específico. Usadas juntas, formam uma superfície de diagnóstico sem ponto cego.
Prometheus é um banco de dados de séries temporais focado em métricas. Ele faz scraping de endpoints /metrics nos seus serviços a cada intervalo configurável, armazena os dados localmente e permite queries com PromQL. É o componente que responde "a latência do endpoint /checkout aumentou 3x nas últimas 2 horas?".
Loki é o equivalente do Prometheus para logs, mas com uma diferença de arquitetura importante: ele não indexa o conteúdo dos logs, apenas os rótulos (labels) associados a eles — container, pod, ambiente, serviço. Isso reduz drasticamente o custo de armazenamento e operação em relação a soluções como Elasticsearch. Você busca os logs por label e filtra por conteúdo via LogQL. O resultado é um sistema que aguenta volume alto sem exigir cluster dedicado.
Tempo cobre o terceiro pilar: tracing distribuído. Cada request recebe um trace ID que percorre todos os serviços envolvidos. O Tempo armazena os spans e os correlaciona. No Grafana, você clica em uma anomalia na métrica do Prometheus, salta para os logs do Loki do mesmo intervalo e de lá vai direto ao trace do Tempo para ver o caminho completo da requisição. É o fluxo de investigação que elimina o ping-pong entre ferramentas.
Como a stack se encaixa na prática
A arquitetura típica de implantação é direta. Prometheus faz scrape dos seus serviços e do Kubernetes (se for o caso, via kube-state-metrics e node-exporter). O Promtail — ou o Alloy, que é o agent moderno do Grafana Labs — coleta logs dos containers e envia para o Loki. A sua aplicação envia traces para o Tempo via OTLP, o protocolo aberto do OpenTelemetry.
O Grafana fica na frente de tudo como camada de visualização e alerta. Uma configuração básica de docker-compose.yml sobe os quatro serviços em poucas dezenas de linhas. Em Kubernetes, os Helm charts oficiais da Grafana reduzem o tempo de instalação para menos de uma hora.
O ponto que muda o nível de maturidade da operação é o seguinte: dashboards em git. Em vez de criar painéis pelo clique no Grafana, você escreve os dashboards como JSON versionados no repositório. O Grafana os lê via provisioning na inicialização. O resultado é que toda mudança em dashboard tem histórico, code review e rollback — a mesma disciplina aplicada ao código de produção.
Tabela: ferramenta, o que resolve e quando você precisa dela
| Ferramenta | O que resolve | Sinal de que você precisa dela |
|---|---|---|
| Prometheus | Métricas de latência, erro, saturação e tráfego | Você descobre falhas pelo cliente, não pelo sistema |
| Loki | Centralização e busca de logs sem Elasticsearch | Você faz SSH em 3 servidores para ver logs de um único request |
| Tempo | Rastreamento de requests em sistemas distribuídos | Você não sabe qual serviço causou lentidão em uma cadeia |
| Grafana | Visualização unificada e alertas contextualizados | Você usa 4 ferramentas diferentes para investigar um incidente |
| Alloy/Promtail | Coleta de logs dos containers automaticamente | Logs somem quando containers reiniciam |
| node-exporter | Métricas de CPU, memória, disco e rede do host | Você não sabe se o problema é na aplicação ou no hardware |
Alertas que não viram ruído
O maior problema de alertas mal configurados não é o falso positivo: é o efeito de habituação. Quando o time começa a ignorar alertas porque "quase sempre é falso alarme", o alerta real chega e ninguém age rápido o suficiente.
A regra prática mais eficaz é alertar em comportamento, não em threshold absoluto. Em vez de "CPU acima de 80%", o alerta útil é "taxa de erro do endpoint /pagamento subiu 5x em relação à baseline da última hora". O Prometheus permite isso com PromQL e a função rate(). O AlertManager — componente nativo do Prometheus — roteia esse alerta com contexto: serviço, ambiente, severidade e link direto para o dashboard correspondente.
Para destinos de alerta, a stack suporta Slack, Telegram, PagerDuty, e-mail e webhooks genéricos. O que recomendamos na prática é o seguinte fluxo: crítico (serviço fora, perda de dados) vai para PagerDuty ou Telegram com wake-up; alto (degradação visível ao usuário) vai para canal Slack de ops; informativo (anomalia para investigação) vai para thread separada ou fila de revisão. Separar os canais por severidade preserva a atenção do time para o que realmente importa.
Dashboards em git: por que isso importa
A grande maioria das operações configura o Grafana pelo clique no browser. O dashboard existe enquanto existe o container. Se o Grafana reinicia com uma imagem limpa, os painéis somem. Se você quer replicar o setup em outro ambiente, refaz na mão.
Grafana suporta provisioning via arquivo: você coloca os JSONs dos dashboards em um diretório mapeado, e ele os carrega automaticamente na inicialização. Combine isso com um repositório Git e você tem dashboards como código. Toda alteração vira commit. Novos ambientes nascem com os mesmos dashboards. O rollback de um painel problemático é um git revert.
A mesma lógica vale para datasources e alertas. Um repositório de observability bem estruturado contém prometheus/rules/, grafana/dashboards/, grafana/datasources/ e um docker-compose.yml ou conjunto de manifests Kubernetes. Qualquer engenheiro novo no time consegue subir o ambiente completo de monitoramento em um único comando. É exatamente essa estrutura versionada que o time de DevOps da MaxVision entrega junto com cada implantação de observabilidade.
Stack aberta versus SaaS de monitoramento: a conta real
Ferramentas SaaS como Datadog, New Relic e Dynatrace têm vantagem real em facilidade de setup inicial e em recursos avançados de APM para linguagens específicas. A desvantagem aparece no custo em escala e no lock-in.
O modelo de preço por host ou por volume de dados ingerido escala de forma não linear. Uma operação com dezenas de serviços e volume alto de logs pode pagar mensalmente o equivalente ao salário de um engenheiro de infraestrutura — que poderia estar operando a stack aberta e resolvendo outros problemas.
A stack Grafana/Prometheus/Loki/Tempo tem custo operacional: você precisa mantê-la. Mas esse custo é previsível e não cresce com o volume de dados da mesma forma. Para operações com time técnico capaz de operar infraestrutura, a conta favorece a stack aberta a partir de um determinado patamar de uso.
Por onde começar: ordem de implantação
A ordem importa. Subir tudo de uma vez gera complexidade sem benefício imediato.
Começa pelo Prometheus com node-exporter e os targets dos seus serviços mais críticos. Isso já te dá visibilidade de CPU, memória, disco e as métricas que cada serviço expõe. Em seguida, sobe o Grafana apontando para o Prometheus como datasource e importa os dashboards padrão da comunidade (Node Exporter Full, por exemplo).
Com isso funcionando, adiciona o Loki e o Promtail/Alloy para centralizar logs. Esse passo já elimina a necessidade de SSH para ver logs de produção. O Tempo vem depois, quando você tiver instrumentação OpenTelemetry nas aplicações — é o componente que exige mais trabalho na camada de código.
Alertas úteis devem ser configurados logo após o Prometheus estar estável, enquanto o time ainda tem energia para calibrar os thresholds sem pressa de incidente.
Perguntas Frequentes
Preciso de Kubernetes para usar essa stack?
Não. A stack roda perfeitamente em Docker Compose em um único servidor. Kubernetes facilita a escala e o deployment automatizado, mas não é pré-requisito. Para a maior parte das operações, Docker Compose com volumes persistentes é suficiente e mais simples de operar.
Loki substitui o Elasticsearch para logs?
Para a maioria dos casos de uso de observabilidade de aplicação, sim. O Elasticsearch tem vantagens em busca full-text complexa e em análise de dados não estruturados. O Loki é mais eficiente para o padrão de uso mais comum em infraestrutura: filtrar logs por serviço, ambiente e intervalo de tempo. O custo operacional do Loki é significativamente menor.
Como o Grafana se integra com alertas no Telegram?
O Grafana tem suporte nativo a Telegram como contact point. Você configura um bot via BotFather, obtém o token e o chat ID e adiciona como destination no AlertManager do Grafana. Os alertas chegam com contexto: nome do alerta, severidade, valores que dispararam e link direto para o dashboard. O processo de configuração leva menos de 30 minutos.
Grafana Cloud é uma opção viável?
É uma opção intermediária: você usa as ferramentas da Grafana Labs (Prometheus gerenciado, Loki gerenciado, Tempo gerenciado) sem operar a infraestrutura. O tier gratuito tem limites de retenção e volume. Para produção real com volume moderado, o custo do Grafana Cloud é menor que Datadog ou New Relic mas maior que self-hosted. Faz sentido para times que querem a stack aberta sem overhead operacional.
Quanto tempo leva para ter a stack básica funcionando?
Para um ambiente com Docker Compose com Prometheus, Loki, Grafana e dashboards básicos: um dia de trabalho de um engenheiro familiarizado com a stack. Para ambiente Kubernetes com Helm charts, alertas configurados e dashboards em git: de dois a quatro dias. A instrumentação OpenTelemetry nas aplicações para tracing tem prazo variável dependendo do número de serviços.
Conclusão
Observability não é um projeto para quando "tiver tempo". É o que separa uma operação que descobre incidentes pelo cliente de uma operação que detecta anomalias antes de virar problema. A stack formada por Prometheus, Loki, Tempo e Grafana entrega os três pilares — métricas, logs e traces — com código aberto, sem lock-in de fornecedor e com custo operacional previsível.
A parte que a maior parte das equipes subestima não é a tecnologia: é a disciplina de manter dashboards em git, calibrar alertas para eliminar ruído e criar runbooks que acompanham cada alerta. Sem isso, você tem ferramentas sem processo, que é quase o mesmo que não ter nada.
Implementar observability de verdade — da stack até os runbooks — é trabalho que exige mais do que instalar ferramentas: exige calibrar alertas para o contexto real e versionar dashboards como código. O departamento de DevOps da MaxVision faz exatamente isso, do Prometheus até o AlertManager, com cada painel rastreável em git. Quando quiser entender o que faz sentido para a sua operação, fale com a equipe.
