The three kinds of telemetry

Logs, metrics and traces answer different questions, and teams end up with all three because none of them substitutes for the others.

Logs answer "what happened to this request?"

A log is a record of an event, with detail attached. Logs are the richest telemetry and the most expensive to keep.

They're excellent at explaining one thing that went wrong and poor at telling you how often it goes wrong, because counting things in logs means reading all of them.

Metrics answer "how much, and how is it trending?"

Metrics are numbers aggregated over time: requests per second, error rate, latency at the 95th percentile, memory in use.

They're cheap to store and cheap to query over a long history, and they lose all detail. A metric tells you the error rate tripled at nine o'clock, and it can't tell you what any of those errors said.

Traces answer "where did the time go?"

A trace follows a single request across every component it touched, with a duration for each.

It's the one this application needs least, because there's one process. The senior course "System Design: service mesh architecture" established that the call graph a trace exists to reveal doesn't exist here.

flowchart TB
  L["logs: what happened to this request"] --> L1["rich detail, expensive, hard to count"]
  M["metrics: how much, and trending"] --> M1["cheap, long history, no detail"]
  T["traces: where the time went"] --> T1["needs a call graph across components"]
  T1 --> N["one process here, so little to reveal"]

The pairing that works

Metrics tell you that something has gone bad, and logs tell you what.

Neither works alone. Metrics without logs give you an alert and no explanation. Logs without metrics give you an explanation you only look for after somebody complains.

The fourth thing that is none of these

Error tracking is a service that receives exceptions, groups identical ones, counts them and tells you when a new kind appears.

It's technically built from logs, but the grouping is what makes it different in practice. A hundred instances of one bug become one entry with a count, and that's the difference between a signal and a wall of text.

Key takeaways

• Logs explain one event richly and are poor at counting.
• Metrics count cheaply over long periods and carry no detail.
• Traces follow a request across components, which matters least in a single process.
• Metrics tell you that something has gone bad and logs tell you what, and neither works alone.
• Error tracking groups identical exceptions, turning a wall of text into a signal.