An Introduction to the 3 Pillars of Observability: Logs, Metrics, and Traces

Monitoring vs. Observability: What's the Difference?

In modern microservice architectures, knowing that a system is broken is easy; figuring out why it is broken is the nightmare. Monitoring tells you that a system is down (e.g., "CPU usage is at 100%"). Observability, on the other hand, allows you to interrogate the system from the outside to understand its internal state and pinpoint exactly why that CPU spiked.

To achieve true observability, Site Reliability Engineers (SREs) rely on three foundational pillars: Logs, Metrics, and Traces.

1. Metrics: The Dashboard Indicators

Metrics are aggregated numerical data measured over time. They are incredibly lightweight to store and fast to query. If observability is a car, metrics are the dashboard—they tell you how fast you are going and how much gas is left.

When tracking metrics, the industry standard is the RED Method (Rate, Errors, Duration):

• Rate: The number of requests your service is handling per second.
• Errors: The number of failed requests (e.g., HTTP 5xx responses).
• Duration: The time it takes to process a request, usually measured in percentiles (e.g., P95 latency).

Metrics are the best tool for triggering automated alerts in systems like Datadog or Prometheus.

2. Logs: The Detailed Event Diary

While metrics tell you that an error occurred, logs tell you what the application was doing at that exact moment. Logs are immutable, time-stamped records of discrete events.

The Shift to Structured Logging

In 2026, writing plain text logs (like console.log("Payment failed")) is a massive anti-pattern. Systems like Splunk or Elasticsearch cannot easily parse text. Modern applications use Structured Logging, outputting logs as JSON objects:

{
  "timestamp": "2026-07-27T10:15:30Z",
  "level": "error",
  "service": "payment-api",
  "userId": "usr_998",
  "message": "Payment gateway timeout",
  "gatewayResponseTimeMs": 5005
}

With this structure, an SRE can instantly query: "Show me all errors where gatewayResponseTimeMs is greater than 5000."

3. Traces: The Detective's Red Thread

In a microservices environment, a single user click might touch the API Gateway, an Auth Service, a Payment Service, and three different databases. If the request is slow, logs and metrics won't easily tell you which specific service caused the bottleneck. This is where Distributed Tracing comes in.

A trace follows a single request through its entire journey. The open-source standard for this is OpenTelemetry (OTel). It injects a unique trace_id into the HTTP headers of the request. Every service that touches the request logs how long it held it (called a "span") and passes the ID to the next service.

When visualized in a tool like Jaeger or Honeycomb, a trace looks like a waterfall chart, instantly revealing that a 3-second request spent 2.8 seconds waiting on a poorly indexed database query.

Connecting the Edge: Akamai and Splunk

True observability doesn't start at your backend; it starts at the edge. If you use a CDN like Akamai, you can use Akamai Cloud Monitor or DataStream to push edge logs directly into Splunk via an HTTP Event Collector (HEC).

By passing the trace_id from the Akamai edge all the way through your backend microservices, you achieve the holy grail of observability: a single pane of glass showing a request's journey from the user's browser, through the CDN, past the WAF, and deep into your database.