Skip to main content
Modern distributed applications can fail in many ways. When something goes wrong, observability gives you the signals and context to understand what happened and why. This guide explains observability using clear analogies, concrete examples, and practical comparisons of the core telemetry signals: metrics, logs, and traces. Observability is the ability to understand a system from the outside — to ask questions and get answers without inspecting internal code or processes. Those answers come from dashboards, traces, logs, or other telemetry outputs. The objective is to surface unknown unknowns: issues you weren’t monitoring directly but that affect your system.
The image explains observability, highlighting its role in understanding systems externally without knowing internals, and in troubleshooting unknown issues. It includes illustrations of a person at a computer and a laptop with gears.

​
Observability through a medical diagnosis analogy

A medical diagnosis is a useful analogy:
  • Symptoms (fever, cough, fatigue) tell you something is wrong.
  • Doctors gather measurements and tests to narrow down the cause.
  • Medical history and timelines help build the full picture.
Translate this to telemetry:
  • Symptoms → metrics (high-level numeric indicators)
  • Timeline and notes → logs (detailed, timestamped events)
  • End-to-end diagnostic tests → traces (request-level paths across services)
The image shows a doctor with a clipboard and a patient coughing, titled "Doctors as Investigators."
Doctors don’t rely on observation alone; they order tests (temperature, blood work, scans). In observability terms, these concise, numeric indicators are metrics.
The image shows an illustration of a person in a lab coat holding papers, with a speech bubble containing a graph icon, and text displaying health indicators: temperature at 100.4°F, blood pressure at 120 mm Hg, and blood sugar at 150 mg/dL.

​
Common software “vital signs” (metrics)

  • Latency / response time — indicates slowness.
  • Error rate — shows increasing failures.
  • Throughput — measures traffic volume.
  • CPU / memory usage — show resource pressure.
  • Saturation — tells if you’ve hit capacity limits.
  • DB query durations and network traffic — additional key signals.
The image outlines ten key software metrics as vital signs, including latency, error rate, throughput, CPU utilization, and more, used to monitor software health.
For quick reference, here’s a compact comparison of typical metric types and their use-cases:

​
Logs — detailed, timestamped events

Logs are verbose records of individual events. They provide contextual details that metrics alone cannot. Think of a patient’s symptom timeline or diary. Example patient event timeline:
In systems, logs include timestamps, severity, event text, and structured fields like client IP, request path, upstream host, etc. Example Nginx upstream error logs:
Logs are scoped to a process or service; correlating logs with metrics and traces helps narrow investigations quickly.

​
Traces — end-to-end request insight

Distributed traces follow a single request as it travels through services. They show timing, dependencies, and where time is spent — ideal for locating latency hotspots or dependency failures. Think of a medical imaging test that reveals the precise area of impaired blood flow. In a web application example, a checkout request may touch multiple services (frontend → checkout → payment → catalog → shipping). A trace stitches spans from each service into a single end-to-end view, revealing total time and each service’s contribution. A trace (waterfall) view often highlights the slowest span and surfaces exceptions and errors encountered during the request.
The image shows a Jaeger UI screenshot displaying a distributed tracing waterfall diagram highlighting exceptions in a service call, including a specific error message "Divisible by 2!" in the trace details.

​
Metrics vs Logs vs Traces — quick comparison

These three are often called the “three pillars” of observability. That mental model helps structure thinking, but modern observability goes beyond just three signals.

​
Additional telemetry and contextual signals

  • Baggage: key/value context that travels with a trace (e.g., user ID, region) to help correlate behavior across services.
  • Profiling: runtime samples of CPU, memory, and heap allocations to find inefficient code paths.
  • Events and custom context: business events or debug snapshots that add diagnostic clarity.
The “three pillars” is a useful starting point, but real-world observability improves when metrics, logs, and traces are correlated with additional telemetry (baggage, profiling, events). Treat metrics, logs, and traces as core signals that are amplified by richer context.

​
Correlation in practice

When metrics, logs, and traces are available and linked, you can answer the key operational question: why is this happening? Example: combining container logs with a shell output confirms a pod’s startup and worker processes:
Correlating that output with metrics (CPU, restarts) and traces (request latency) helps determine if an issue is environmental, configuration-related, or application-level.
The image is a "Quick Recap" slide summarizing key points about observability, diagnosis analogy, metrics, and logs in a software system. Each point is numbered and explained briefly.

​
Quick recap

  • Observability lets you understand a system from the outside without inspecting internals.
  • Diagnosis analogy: symptoms → tests → history → scans maps to metrics → logs → traces.
  • Metrics = vital signs; Logs = timelines and context; Traces = request paths and timing.
  • Correlate signals (plus baggage and profiling when available) to reveal root causes and previously unknown issues.
Thank you.

Watch Video