Quando um sistema fica lento às 3 da manhã, a pergunta não é só "está no ar?", mas "por que está assim?". Monitoramento responde a primeira; observabilidade responde a segunda. Em sistemas distribuídos, onde uma única requisição passa por dezenas de serviços, saber investigar o desconhecido é o que diferencia apagar incêndios de entender o sistema.

Monitoramento vs observabilidade

A distinção é sutil e cai muito em entrevista. Monitoramento é vigiar coisas que você já sabe que podem dar errado: CPU acima de 90%, disco cheio, serviço fora do ar. Você sabe quando quebrou. Observabilidade é a capacidade de fazer perguntas novas sobre o sistema sem precisar reimplantá-lo — de descobrir por que quebrou, inclusive em falhas que você nunca previu.

Monitoramento responde perguntas conhecidas; observabilidade permite responder perguntas que você nem sabia que faria. Em sistemas complexos, a maioria dos problemas é do segundo tipo.

Os três pilares

A observabilidade se apoia em três tipos de dados, cada um respondendo a uma classe de pergunta diferente:

Logs estruturados

Logs são o registro detalhado de eventos. A boa prática moderna é usar logs estruturados (geralmente JSON), porque máquinas conseguem filtrar e agregar campos em vez de fazer busca por texto solto.

When a system gets slow at 3 a.m., the question isn't just "is it up?" but "why is it like this?". Monitoring answers the first; observability answers the second. In distributed systems, where a single request goes through dozens of services, knowing how to investigate the unknown is what separates firefighting from understanding the system.

Monitoring vs observability

The distinction is subtle and comes up a lot in interviews. Monitoring is watching for things you already know can go wrong: CPU above 90%, a full disk, a service that is down. You know when it broke. Observability is the ability to ask new questions about the system without having to redeploy it — to find out why it broke, even in failures you never anticipated.

Monitoring answers known questions; observability lets you answer questions you didn't know you'd ask. In complex systems, most problems are of the second kind.

The three pillars

Observability rests on three types of data, each answering a different class of question:

Structured logs

Logs are the detailed record of events. Modern best practice is to use structured logs (usually JSON), because machines can filter and aggregate fields instead of searching loose text.

Métricas: números agregados

Métricas são números medidos ao longo do tempo — requisições por segundo, latência, uso de memória. Por serem agregadas, são baratas de guardar e ótimas para gráficos e alertas. Dois frameworks ajudam a escolher o que medir:

• RED (para serviços): Rate (requisições/s), Errors (taxa de erro), Duration (latência).
• USE (para recursos): Utilization, Saturation, Errors.

Traces: a requisição atravessando serviços

Num sistema de microsserviços, uma requisição do usuário pode passar por API, autenticação, banco e cache. Um trace costura toda essa jornada e mostra quanto tempo cada etapa levou. É a ferramenta certa quando "o sistema está lento" e você precisa achar onde.

Metrics: aggregated numbers

Metrics are numbers measured over time — requests per second, latency, memory usage. Because they're aggregated, they're cheap to store and great for charts and alerts. Two frameworks help you choose what to measure:

• RED (for services): Rate (requests/s), Errors (error rate), Duration (latency).
• USE (for resources): Utilization, Saturation, Errors.

Traces: the request crossing services

In a microservices system, a user request may go through an API, authentication, a database and a cache. A trace stitches that whole journey together and shows how long each step took. It's the right tool when "the system is slow" and you need to find out where.

Alertas e SLO

De nada adianta coletar dados se ninguém é avisado quando algo importa. Um alerta dispara quando uma métrica cruza um limite. Para não alertar por qualquer coisa, define-se um SLO (Service Level Objective) — uma meta como "99,9% das requisições respondem em menos de 300ms". Você alerta quando está prestes a estourar o SLO, não a cada soluço. Esses dados também alimentam decisões de escala, como o autoscaling no Kubernetes.

Conclusão

Observabilidade é o que permite entender sistemas que você não consegue prever por completo. Logs dizem o que aconteceu, métricas dizem quanto, traces dizem onde — e juntos transformam um incidente confuso numa investigação objetiva. Saber qual pilar usar em cada situação é uma marca de maturidade técnica de um DevOps pleno.

Alerts and SLOs

There's no point collecting data if nobody is notified when something matters. An alert fires when a metric crosses a threshold. To avoid alerting on every little thing, you define an SLO (Service Level Objective) — a target such as "99.9% of requests respond in under 300ms". You alert when you're about to blow the SLO, not at every hiccup. This data also feeds scaling decisions, such as autoscaling in Kubernetes.

Conclusion

Observability is what lets you understand systems you can't fully predict. Logs tell you what happened, metrics tell you how much, traces tell you where — and together they turn a confusing incident into an objective investigation. Knowing which pillar to use in each situation is a sign of technical maturity in a mid-level DevOps engineer.