Logs vs Metrics vs Traces

Objectives

By the end of this lesson, you should be able to:

• Distinguish logs, metrics, and traces, by the specific question each answers
• Explain why Course 3’s structured logging alone doesn’t answer every operational question
• Explain what “observability” means, as more than just “having logs”

💡 Why this matters: Course 3, Module 9 built structured logging, genuinely useful, and still only one piece of what a real, running, scaled application needs to be observable. This module adds the other two pieces, starting here, with what each one is actually for.

Logs

A log entry, Course 3’s pino output, records a single, specific event, “this request failed,” “this user registered,” each entry is detailed, and tied to one moment in time. Logs answer, “what exactly happened, in this one specific case?”, invaluable for debugging a specific failure, once you already know roughly where to look, less useful for answering a broader question like “is the whole system healthy right now?”, reading through thousands of individual log lines to answer that isn’t practical.

Metrics

A metric is a number, tracked over time, aggregated, “how many requests in the last minute,” “what’s the average response time,” “how many are currently failing.” Metrics answer, “how is the system behaving, overall, right now, and is it getting worse?”, exactly the question logs don’t answer well, a single counter or histogram can summarize millions of individual events into something a person, or an automated alert, can actually act on at a glance.

Traces

A trace follows a single request across every service it touches, this API calls that database, which calls that cache, a trace shows the full path, and how long each step within it took. Traces answer, “where, specifically, in a complex, multi-service request, did the time go, or the failure happen?”, most valuable once a system has enough moving parts that a single log line, or even a single metric, can’t localize a problem to one specific step.

Why This Module Focuses on Metrics

All three matter in a mature system, this module builds real, working metrics, the piece most directly missing from what this track has built so far, and covers uptime checks and alerting, tying logs and metrics together into something a team actually gets notified by. Distributed tracing, genuinely useful once an application is calling multiple other services, matters most for architectures more complex than this track’s single-API Notes application, worth knowing about, not the focus here.

Try It

1. For each of the following questions, decide whether logs, metrics, or a trace would answer it best: “did user 42’s login attempt at 3:14pm succeed?”, “is error rate higher this hour than usual?”, “which of these three chained service calls is slow?”
2. Explain, in your own words, why “we have logging” (Course 3, Module 9) isn’t the same claim as “this system is observable.”
3. Explain, in one or two sentences, why metrics are better suited than logs for triggering an automated alert.

Recap

• Logs record individual events in detail, metrics summarize behavior over time, traces follow a single request across multiple services, each answers a different operational question.
• Course 3’s structured logging is genuinely useful, and only one piece, this module adds metrics, the piece most directly missing so far.
• Observability means having the right tool for the question actually being asked, not just having logs and assuming that’s enough.

Next lesson: instrumenting a real Express app with Prometheus-style metrics.