To są trzy filary obserwabilności. Odpowiadają na różne pytania: metryki mówią Ci że coś jest nie tak, logi mówią Ci co się stało, a traces mówią Ci gdzie w rozproszonej sekwencji zaszła strata czasu lub błąd.
To są trzy filary obserwabilności. Odpowiadają na różne pytania: metryki mówią Ci że coś jest nie tak, logi mówią Ci co się stało, a traces mówią Ci gdzie w rozproszonej sekwencji zaszła strata czasu lub błąd.
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
Metryki zawężają Cię do objawu i okna czasowego; traces lokalizują to do usługi lub wywołania; logi dają dokładną przyczynę. Przejście bezpośrednio do logów bez metryk oznacza wyszukiwanie na ślepo.
Metryki są agregowane, więc pozostają tanie nawet na dużą skalę — idealne dla zawsze włączonych dashboardów i alertów. Logi i traces są na zdarzenie i kosztowne, więc zwykle są próbkowane i przeszukiwane na żądanie podczas badania.
Używanie złego filaru marnuje czas: nie możesz skutecznie alertować na surowych logach (zbyt głośne, zbyt kosztowne), i nie możesz debugować konkretnego nieudanego żądania z zagregowanej metryki. Wiedza, że metryki wykrywają, traces lokalizują, a logi wyjaśniają, daje Ci szybką, powtarzalną ścieżkę od "coś jest nie tak" do pierwotnej przyczyny.