No history yet

Introduction to Observability

What Is Observability?

Observability is the ability to understand the internal state of a system by examining its external outputs. Think of it like a doctor diagnosing a patient. The doctor can't see inside your body directly, but they can measure your temperature, listen to your heartbeat, and run tests. These external signals help them understand what's happening inside.

In the world of software, especially complex cloud-native systems, our applications are the patients. We can't just pause a massive, distributed system to see what's wrong. Instead, we rely on the data it produces—its outputs—to figure out its health and performance. This is crucial for troubleshooting problems, identifying bottlenecks, and ensuring everything runs smoothly.

Essentially, observability lets you ask new questions about your system without having to ship new code to answer them.

The Three Pillars

Observability is built on three main types of data, often called the "three pillars."

1. Metrics: These are numerical measurements collected over time, like CPU utilization, memory usage, or the number of user requests per second. Metrics are great for getting a high-level overview of system health and spotting trends. They can tell you that a problem is happening, like a spike in errors.

2. Logs: A log is a detailed, timestamped record of an event that occurred in the system. When a user logs in, an error occurs, or a database query is run, a log entry can be generated. Logs provide context and can help you understand why a problem identified by metrics is occurring.

3. Traces: A trace shows the end-to-end journey of a single request as it moves through all the different parts of a distributed system. Think of it as following a package from the warehouse to your doorstep. Traces are essential for pinpointing where failures or slowdowns are happening in a complex chain of services.

Why Microservices Make It Tricky

In the past, many applications were built as a single, large unit—a monolith. Troubleshooting was relatively straightforward because all the code was in one place. If something went wrong, you'd look at the logs on that one server.

Today, many systems use a microservices architecture. This means the application is broken down into dozens or even hundreds of small, independent services that communicate with each other. This approach offers flexibility and scalability, but it creates a huge monitoring challenge. A single user request might travel through ten different services before it's complete.

Lesson image

If that request fails, where did the problem occur? Was it in the authentication service, the payment processor, or the notification service? Without a way to trace the request's full journey, you're left guessing. This is why a comprehensive observability strategy is not just helpful—it's necessary for building and maintaining reliable modern software.

Design for Observability: Logging and metrics are not nice-to-haves—they’re foundational.

By combining metrics, logs, and traces, teams can gain a deep understanding of their system's performance and quickly resolve issues, ensuring a better experience for their users.

Let's test your knowledge on these core concepts.

Quiz Questions 1/5

What is the primary goal of observability in the context of software systems?

Quiz Questions 2/5

Which of the following are widely considered the "three pillars" of observability?

Understanding these fundamentals is the first step toward building more resilient and debuggable systems.