Estes são os três pilares da observabilidade. Eles respondem a perguntas diferentes: métricas dizem que algo está errado, logs dizem o que aconteceu, e traces dizem onde no fluxo distribuído o tempo ou erro foi.
Estes são os três pilares da observabilidade. Eles respondem a perguntas diferentes: métricas dizem que algo está errado, logs dizem o que aconteceu, e traces dizem onde no fluxo distribuído o tempo ou erro foi.
METRICS aggregate numbers over time (counters, gauges, histograms)
→ cheap, low cardinality, great for trends & ALERTING
→ e.g. error rate = 2%, p99 latency = 800ms
LOGS discrete, timestamped events with detail (often structured JSON)
→ rich context for DEBUGGING a specific request
→ e.g. {"level":"error","user":123,"msg":"payment declined"}
TRACES the path of one request across services, with timing per span
→ shows latency BREAKDOWN and where a call fails
→ e.g. checkout 800ms = api 50ms + db 700ms + email 50ms
1. METRIC alerts: "checkout p99 latency jumped to 2s" → you know THERE's a problem
2. TRACE a slow request: 1.8s of 2s is spent in the inventory service
→ you know WHERE it is
3. LOGS of the inventory service at that time: "slow query: missing index"
→ you know WHAT happened
Métricas o direcionam a um sintoma e janela de tempo; traces o localizam em um serviço ou chamada; logs fornecem a causa exata. Ir direto aos logs sem métricas significa buscar às cegas.
Métricas são agregadas, então permanecem baratas mesmo em escala — ideais para dashboards sempre ativos e alertas. Logs e traces são por evento e custosos, então geralmente são amostrados e consultados sob demanda durante investigação.
Usar o pilar errado desperdiça tempo: você não pode alertar efetivamente em logs brutos (muito ruidoso, muito custoso), e você não pode debugar uma requisição falhada específica a partir de uma métrica agregada. Saber que métricas detectam, traces localizam e logs explicam lhe fornece um caminho rápido e repetível de "algo está errado" até a causa raiz.