Modern Observability Has Five Pillars. Most Teams Are Only Using Three.

The three pillars of observability—logs, metrics, and traces—have been the bedrock of how engineering teams monitor production systems for over a decade. You’ve read the posts. You’ve heard the conference talks. You’ve built the dashboards.

And yet, engineering teams are still getting blindsided by production incidents every day.

Users report bugs that never show up in your error logs. Your dashboards are green right up until a customer tweets that your checkout is broken. You close a P1 ticket, write the postmortem, and two weeks later the exact same thing happens because someone on a different team deployed the same antipattern.

The three pillars didn’t fail you. They were just designed for a simpler era—before the browser became a runtime, before every service had an attached security footprint, and before the cost of running five separate observability tools per signal became a line item that finance started asking questions about.

Modern observability has five pillars. Most teams are only using three.

A Quick Recap: Why the Three Pillars Work (and Where They Stop)

The original framework was elegant. Logs tell you what happened. Metrics tell you how things are trending. Traces tell you where time went across a distributed call chain.

Together, they give you a powerful picture of your infrastructure. Kubernetes pods, database query latencies, API error rates, slow service dependencies—logs, metrics, and traces cover this territory well.

But here’s the shape of modern applications in 2026:

• A significant portion of your business logic runs in the browser
• Your users are the first ones to know when something is broken
• Every service you run is an attack surface
• Your observability bill scales with every new service, team, and feature flag

The three pillars tell you a lot about your backend. They tell you almost nothing about your users’ actual experience, and they tell you nothing about whether someone is currently exfiltrating your data.

That’s the gap. Let’s close it.

Pillar 4: Session Replay

Session replay captures exactly what a user saw and did in the browser—clicks, scrolls, page transitions, network requests, JavaScript errors, and rage clicks—and plays it back as a video-like recording tied to your trace and log data.

If you’ve never watched a session replay during an incident investigation, here’s what you’re missing:

Your error monitoring says 12 users hit a TypeError: Cannot read properties of undefined. Your logs show the exception. Your traces show it originating in the checkout service. But you don’t know why those 12 users hit it and the other 4,000 didn’t.

You open a session replay. You watch the user navigate through the cart. They applied a discount code. Nobody had tested the discount + free shipping combination. Two minutes of watching a session replay gave you what four hours of log spelunking couldn’t.

Session replay is also your most direct window into perceived performance. Core Web Vitals—LCP, CLS, INP, FCP—tell you what your performance scores are. Session replay shows you what a 4.2-second LCP actually looks like to a user on a 4G connection in a suburb of Minneapolis.

Why it belongs in your observability stack

Frontend context is not optional when your product is a web application. Every backend improvement you make ultimately serves a user session. Without replay, you’re optimizing in the dark.

The integration angle

Session replay data becomes dramatically more useful when it’s correlated with your traces. When a user session ends in a rage click on a broken button, you want to jump directly from that replay timestamp to the backend trace that explains the 3-second API hang. That correlation only works if your replay and trace data live in the same platform.

Pillar 5: Security Observability (SIEM)

The fifth pillar is the one most engineering teams have outsourced to a completely separate team—security.

The traditional model: DevOps runs observability, SecOps runs SIEM. Two tools, two teams, two alert streams, and a dangerous delay between when something anomalous shows up in your telemetry and when your security team knows about it.

Here’s why that model is breaking down.

Your logs already contain security signals. Every failed authentication attempt, every unusual API access pattern, every privilege escalation, every request from an IP that’s never touched your service before—it’s all in your logs. The problem isn’t that security data is somewhere else. It’s that your observability platform wasn’t looking for it.

A proper security observability layer—a SIEM integrated into your existing telemetry pipeline—gives you:

• PII detection and redaction in real-time, before sensitive data lands in your log storage (email addresses, credit card patterns, SSNs)
• Audit logs for compliance frameworks like SOC 2, giving you a verifiable record of who accessed what and when (CC7.2)
• Detection rules that trigger on behavioral patterns across your full telemetry: an IP hitting your password reset endpoint 400 times in 60 seconds will show up in your logs long before it shows up in a security ticket
• Anomaly signals that your on-call engineer can see alongside infrastructure alerts—not in a separate tool they don’t know how to use at 2am

Why it belongs in your observability stack

Security incidents are operational incidents. When your database is being scraped, your on-call engineer is the first person who will see the spike in query latency. They need the security context in the same pane of glass, not filed away in a SIEM that requires a separate login and a different query language.

The Real Problem: Five Pillars, Five Tools, One Enormous Bill

Here’s the math most teams are living with:

Signal	Typical Tool
Logs	Datadog Log Management
Metrics	Datadog Infrastructure / Prometheus
Traces	Datadog APM / Jaeger
Session Replay	FullStory, Hotjar, LogRocket
Security / SIEM	Splunk, Sumo Logic, Elastic SIEM

You’re paying for five separate ingestion pipelines, five storage backends, five sets of dashboards, and five vendor contracts. And none of them talk to each other natively.

When you want to correlate a user’s session replay with the backend trace from that session—which is exactly what you need during a frontend incident—you’re copy-pasting timestamps between tabs and hoping the time zones line up.

This is not a workflow problem. It’s an architecture problem.

The cost side is just as brutal. Datadog’s custom metrics pricing means that adding a user_id tag to a core metric can multiply your bill by 10x overnight as cardinality explodes. Log Management charges per GB with no real way to predict your bill in advance. And the more services you run, the more APM hosts you’re paying for.

Industry surveys consistently find that engineering teams spending over $100K/year on observability have effectively zero visibility into what’s generating that cost until they get the invoice.

What a Unified Five-Pillar Stack Looks Like

The alternative is a single platform that handles all five signal types—logs, metrics, traces, session replay, and security—in one storage backend with native correlation between every signal type.

The key enabler here is ClickHouse. Traditional observability platforms were built on time-series databases and inverted-index log stores—purpose-built systems that are good at one thing but can’t answer the cross-signal questions that matter most during incidents.

ClickHouse is a columnar analytical database that handles all of these workloads efficiently. Your logs, metrics, and traces all land in the same database. Queries across signal types are fast because the data is co-located. PII detection runs as a pipeline transformation before data is stored. Session replay events are just another event stream.

The practical benefits:

• Correlation is instant. Jump from a JavaScript error in a session replay to the backend trace in one click, because both are rows in the same database.
• Cost is predictable. ClickHouse’s columnar compression means observability data is stored 5–10x more efficiently than traditional solutions. You pay for what you actually store and query.
• Security data is just data. Detection rules are queries. Audit logs are tables. There’s no separate SIEM architecture to maintain.

Getting Started: Migrating to a Unified Stack

You don’t have to rip out everything at once. Most teams start with the signal type that’s causing the most pain.

Start with logs if you’re spending too much on your current log management or if you’re hitting cardinality walls on metrics. The OpenTelemetry Collector makes it straightforward to add a new exporter alongside your existing one while you validate the new platform.

Start with session replay if your frontend incident response is weak. This is additive—you’re adding a new signal you don’t have today, and the immediate ROI of a single incident resolved in two minutes instead of four hours usually makes the business case obvious.

Add security last if you already have a separate SecOps workflow. The goal isn’t to disrupt it—it’s to bring the security context into the same tools your engineers are already using during incidents.

The OpenTelemetry standard makes this migration much less painful than it used to be. Your instrumentation sends telemetry to the OTel Collector, and the Collector routes it wherever you tell it to. Switching backends doesn’t require touching your application code.

The Bottom Line

The three pillars of observability—logs, metrics, traces—are not going anywhere. They’re the foundation. But treating them as a complete solution means you have blind spots in your frontend, blind spots in your security posture, and a stack that costs more than it should because you’re paying five vendors to do five things a single platform can handle.

Modern observability is five pillars: logs, metrics, traces, session replay, and security. The question isn’t whether you need all five. It’s whether you’re going to pay five vendors for them, or one.

---

Questions about building a unified observability stack? Reach out at support@qorrelate.io or join our Slack community.