Skip to main content
What is observability? Observability is the ability to reason about and measure the internal state of a system using the data the system produces. In practice, observability turns raw telemetry into actionable insight: it helps you detect, diagnose, and prevent problems by revealing how components interact and why they behave as they do. Observability becomes essential as architectures grow more complex. In a monolith you can inspect most behavior in one place, but in distributed microservices you have many independent components interacting across the network — making fault isolation, performance analysis, and root-cause identification far more challenging.
A slide titled "Observability" explaining that increasing system complexity creates a greater need for observability as applications move from monoliths to distributed microservices. A diagram shows a monolith transitioning to a microservices box with interconnected services labeled "email", "users", and "auth".
Why observability matters for troubleshooting To troubleshoot effectively you need more than a symptom: you need context. Observability provides that context so you can answer questions such as:
  • Why are error rates rising?
  • Where is latency introduced in a request path?
  • Which service is timing out and why?
Without observability an application behaves like a black box: inputs go in, outputs come out, and the internal state is hidden. With proper telemetry you can trace failures to specific components, understand contributing factors, and design fixes and mitigations that prevent recurrence.
A presentation slide titled "Observability" explaining that troubleshooting requires more context than just what’s wrong and that teams must know why an application entered a specific state and which component is responsible. It lists example questions: why error rates are rising, why there is high latency, and why services are timing out.
The three pillars of observability Observability is commonly described using three complementary telemetry pillars: logs, traces, and metrics. Each provides a different lens into system behavior and, when combined, they give a robust picture that supports fast, accurate debugging and performance monitoring. Logs Logs are timestamped, textual records of events produced by operating systems, applications, and services. They often include structured or unstructured messages that describe what happened. Example syslog entries:
Logs are ubiquitous and often the first source of insight. Their downsides are verbosity and potential interleaving of records from many concurrent processes, which can make it hard to follow a single request through a distributed system.
A dark-themed presentation slide titled "Logs" stating that logs are the most common form of observation produced by systems. It notes logs can be difficult to use due to verbosity and being interwoven across multiple concurrent systems.
Traces Traces capture the causal flow of a single request as it traverses multiple services. A trace is an end-to-end view identified by a trace ID and composed of spans. Each span represents a unit of work (for example: routing through a gateway, an auth check, a DB call) and typically records:
  • start time
  • duration
  • parent span ID (the caller)
  • metadata/tags (attributes that add context)
By following spans you can see where time is spent and which services contribute to latency or errors.
A presentation slide about distributed tracing that defines traces and spans and lists span attributes (start time, duration, parent-id). It also includes a diagram showing a gateway and services (auth, user, datastore) with numbered spans and a timeline of root and child spans.
Metrics Metrics are numeric, time-series measurements used to quantify system state and performance. They are ideal for aggregation, alerting, and visualization over time. Common examples:
  • CPU and memory utilization
  • HTTP request rates and response latencies
  • Error counts and saturation metrics
A metric data point usually contains four elements:
  • metric name — the identifier (e.g., http_requests_total)
  • value — numeric measurement
  • timestamp — time of recording
  • dimensions (labels/tags) — key/value attributes that provide context
Example Prometheus-style metric sample:
A presentation slide titled "Metrics" that lists system measurements like CPU load, number of open files, HTTP response times, and number of errors. It notes that collected data can be aggregated and graphed to identify trends and includes a small line-chart icon.
How logs, traces, and metrics work together
  • Logs provide detailed, event-level context and human-readable messages.
  • Traces show causal relationships and timing across services for individual requests.
  • Metrics give aggregated, numeric trends that are efficient for alerting and capacity planning.
Putting them together accelerates troubleshooting: use metrics to detect anomalies and narrow the scope; use traces to identify where a request spent time and which services were involved; use logs to inspect detailed events and error messages for root cause analysis. Table: Quick reference for the three pillars
Prometheus is a monitoring system centered on metrics: it collects, stores, and queries time-series numeric data. Prometheus does not collect logs or traces; use dedicated log aggregators and tracing systems (for example, OpenTelemetry + Jaeger) for those data types.
Further reading and references Understanding and instrumenting logs, traces, and metrics gives your team the observability required to detect issues early, troubleshoot faster, and improve system reliability.

Watch Video