Well, hello there, my dear friend. How’s your mood today? Still craving the unknown? Then grab your telescope — we’re going on a monitoring mission. Monitoring? Monitoring? What is monitoring and why do we even need it in a DevOps environment, you ask? Why give it a separate area, others might wonder? Oh, it’s not that simple. Can we say that monitoring helps us react to problems in our infrastructure? Sure, we can. Can it help us improve that infrastructure? Also, yes. But can it help the business, not just the ops team, make better decisions? Oh yes, absolutely! Let’s split the metrics a well-built monitoring setup provides into a couple of types: Infrastructure metrics – the usual stuff: CPU, memory, network, and so on.
Business metrics – will show us what’s popular, how much, for whom, and where in the world they’re clicking from (a simplified description, sure, but the idea is right). Infrastructure metrics – the usual stuff: CPU, memory, network, and so on. Infrastructure metrics Business metrics – will show us what’s popular, how much, for whom, and where in the world they’re clicking from (a simplified description, sure, but the idea is right). Business metrics Now you might ask: what kind of metrics would actually help the business? Oh, I’m so glad you asked. Imagine a store that sells clothes, music, or whatever. Basic metrics will show what people buy more of (size, color, style, genre, theme), which products are getting the most views, where your traffic is coming from geographically, how long people hesitate before buying, what age group your users are — and so on. See? Properly set up monitoring is awesome. And we haven’t even touched logs yet. But what if I told you… we have something even better? What if I told you that traditional monitoring is kinda… outdated? What if I told you that while monitoring helps you react after the fact, it doesn't really help you predict issues before they happen? Aha — now you're starting to get why we need observability. Observability is more than just sexy dashboards with colorful graphs. It's about predicting the problem before it becomes one, based on subtle signals in how your system behaves right now. Observability They call this the three pillars of observability (in any order you like 😄): Metrics
Traces
Logs Metrics Traces Logs Let’s break that down a bit. Metrics show you the current health of your system — errors, load, latency. But they won’t tell you exactly what happened. They’re aggregated by default — you won’t see a specific user or request just from metrics alone. Metrics Traces let you see the full journey of a request, end to end. They highlight bottlenecks, slow points, and errors along the way. Great for post-mortem analysis. But they have a downside: they’re tricky to collect, tricky to store, and really shine only with a well-configured observability setup. Traces Logs give you detailed context of what happened and why. Super useful for diagnosing weird or critical stuff. But the downside? We have a lot of logs. No — like, A LOT OF LOGS. ALL CAPS KIND OF A LOT. Logs So how do we build observability? So how do we build observability? Okay, here’s a simplified scheme — not perfect, but pretty close. And yes, it may look like traditional monitoring at first glance. But there’s one key difference that makes observability a whole different game: Analysis. What does analysis give us? What does analysis give us? Event correlation – linking logs, metrics, and traces to understand cause and effect.
Anomaly detection – using rules, statistics, or ML to spot weird behavior.
Trend analysis – looking at historical data to predict what might happen next.
Root cause analysis – understanding exactly what broke and why. Event correlation – linking logs, metrics, and traces to understand cause and effect. Event correlation Anomaly detection – using rules, statistics, or ML to spot weird behavior. Anomaly detection Trend analysis – looking at historical data to predict what might happen next. Trend analysis Root cause analysis – understanding exactly what broke and why. Root cause analysis Dashboards & reports – you gotta show off that knowledge somehow, right? Dashboards & reports What tools and techniques do we use to make analysis actually useful? So, we’ve touched on how observability works and how it’s built — getting interested yet? But what if I told you... that we’ve only scratched the surface? Ready to dive deeper? What if I told you observability itself can be approached in multiple ways? Ah, I see your eyes widening. Here are some of the key approaches worth knowing about: OpenTelemetry is an open standard for collecting, normalizing, and exporting metrics, logs, and traces. Its main strength is universality — you’re not tied to any vendor. But it takes work to set up, configure, and maintain, especially in mixed or complex systems. OpenTelemetry APM (Application Performance Monitoring) focuses on app performance and gives you sleek, integrated solutions with dashboards and alerting right out of the box. Great for small teams and quick wins. But it’s often closed-source, expensive, and limited in flexibility — you’re locked into someone else's way of seeing your data. APM (Application Performance Monitoring) Combining whitebox and blackbox observability gives you different angles: blackbox checks external availability (like a user would), while whitebox sees what’s going on inside your systems. The strength is in the combo. But blackbox doesn’t tell you why something broke, and whitebox can drown you in data without context. Combining whitebox and blackbox observability SLOs and error budgets come from the SRE world — they align observability with user expectations, not just raw metrics. They help focus on what truly matters and balance reliability with velocity. The challenge? They need a mature engineering culture and alignment with business goals. SLOs and error budgets Event-based observability focuses on application and business-level events, not just system stats. That helps you understand user impact and internal logic. But it requires deliberate event design and isn’t always easy to standardize. Event-based observability Topological / graph-based observability builds dynamic maps of your system components and their dependencies. Great for Kubernetes, service meshes, and debugging complex systems. But it can get visually messy and overwhelming in larger environments — and not always up to date. Topological / graph-based observability User-centric observability looks at real user experience: frontend errors, load times, behavior patterns. This gives the business insights backend data often misses. But these tools can be noisy, hard to interpret, and need privacy-conscious implementation. User-centric observability Yes, that’s a lot of info. But you know what? You don’t have to memorize all of it. I just want to nudge you in the right direction — give you a better sense of what to think about when you’re designing these systems on your own projects. So what did we learn today? So what did we learn today? That the world is full of signals, and if you can analyze them well, you can teach your system to survive load spikes, attacks, or even just save you some money. And hey — isn’t that happiness? May DevOps be with you !! May DevOps be with you !!

Dash

Super

Playing Real Life RPG as DevOps

Monitoring Observability — or What the Heck Is It Anyway?

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

AI Might Soon Watch Your Login Attempts the Blade Runner Way

The Noonification: How to Deal With Flapping or Broken Tests (11/29/2023)

The Noonification: Delving Into OpenTelemetry Collector (11/18/2023)

The Noonification: How to Implement a Merkle Tree in Solidity (11/12/2023)

105 Stories To Learn About K8s

104 Stories To Learn About Continuous Integration

AI Might Soon Watch Your Login Attempts the Blade Runner Way

The Noonification: How to Deal With Flapping or Broken Tests (11/29/2023)

The Noonification: Delving Into OpenTelemetry Collector (11/18/2023)

The Noonification: How to Implement a Merkle Tree in Solidity (11/12/2023)

105 Stories To Learn About K8s

104 Stories To Learn About Continuous Integration

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps