How do you know if a cloud-native application is healthy when you cannot see its internal workings? This is the fundamental problem that observability solves for IT professionals studying for the KCNA exam. It matters because modern applications run across hundreds of containers, and without observability, you are flying blind — unable to fix problems before they affect users.
Jump to a section
A simple way to picture Observability: Monitoring, Logging, and Tracing
When a restaurant kitchen runs a busy Friday dinner service, chaos can erupt, which leads to burnt steaks, angry customers, and a frantic chef. To prevent this, the kitchen needs three things: monitoring, logging, and tracing. Monitoring is like the chef constantly checking the temperature of the grill and the speed of orders coming in. If the grill is too hot, the chef adjusts it immediately to avoid burning the food. Logging is like the kitchen's order tickets. Every single order, from the starter to the dessert, is written down and stored. If a customer complains about a cold soup two hours later, the kitchen can pull the ticket to see when that soup was fired and who cooked it. Tracing is like tracking a single dish's journey through the kitchen. Take a well-done steak: you follow it from the butcher's counter, to the grill, to the resting rack, to the garnish station, and finally to the waitress. It lets you see exactly which step took too long. Together, these three practices turn a chaotic kitchen into a well-oiled machine, ensuring every customer gets a perfect meal on time.
Observability is the practice of understanding a system's internal state by examining its external outputs. In the world of Kubernetes and cloud-native applications, these outputs come in three forms: metrics, logs, and traces. These are called the 'three pillars of observability'. Each pillar gives you a different type of information, and together they give you a complete picture of your application's health and performance.
Let's start with metrics. A metric is a numerical measurement taken at a specific point in time. Think of it as the speedometer in your car. It tells you, right now, that you are travelling at 60 miles per hour. Common metrics for a web application include CPU usage, memory consumption, request count, and error rate. Prometheus is the most popular open-source tool for collecting and storing metrics. It works by 'scraping' — reaching out to your application at regular intervals and pulling the latest metric values. These values are stored in a time-series database, which means every data point is tied to a timestamp. This allows you to create dashboards that show how your system behaves over minutes, hours, or days. Grafana is the tool that turns these raw numbers into visual graphs and charts. It connects to Prometheus and lets you build dashboards that show, for example, a line graph of CPU usage over the last 24 hours.
Next comes logging. A log is a text record of an event that happened inside your system. Continuing the car analogy, a log is like the event data recorder (the black box) in your car. It records things like 'brake applied at 3:45 PM' or 'engine temperature exceeded 200 degrees'. In software, logs are generated by applications and stored in files or sent to a central logging system. Each log entry usually includes a timestamp, a severity level (like INFO, WARN, or ERROR), and a message. For example, a log entry might say: '2025-03-15 14:30:22 ERROR connection to database failed retrying in 5 seconds'. Logs are invaluable for debugging specific problems, because they give you the precise sequence of events that led to an error. In Kubernetes, containers produce logs that are captured by the container runtime. Tools like the ELK stack (Elasticsearch, Logstash, Kibana) or Loki are used to collect, store, and search through logs.
The third pillar is tracing. A trace follows a single user request as it travels through multiple services in a distributed system. Imagine you book a flight on a travel website. That single click might trigger requests to an authentication service, a flight search service, a payment service, and a confirmation email service. A trace tracks that request across all those services, recording how long each step took. Each step is called a 'span'. A span has a start time, an end time, and a unique ID that ties it to the parent request. If the flight search is slow, the trace will show you exactly which backend call caused the delay — perhaps the airline's API took 2 seconds to respond. Jaeger and Zipkin are common tools for distributed tracing.
Why do you need all three? Consider this scenario. Your monitoring dashboard shows a spike in error rates (a metric). You look at the logs and see 'ERROR failed to connect to database'. But you also need to trace that specific user's request to understand that the database failure happened because the user's session token expired mid-transaction. Each pillar alone gives you part of the picture, but together they give you the whole story.
Before observability, IT teams relied on 'monitoring' alone. They would set up alerts for when CPU usage went above 90%. But they often had no idea why it happened. Observability is a step beyond monitoring: it is designed to let you ask new questions about your system without having to pre-configure every possible scenario. In a cloud-native world, where services are constantly being updated and scaled, that flexibility is essential.
For the KCNA exam, you need to understand that observability is not a single tool but a combination of practices and tools. The exam will test your knowledge of Prometheus for metrics, Grafana for visualisation, and the general concepts of logging and tracing. You do not need to memorise every command, but you must understand what each pillar does and how they complement each other.
Instrument Your Application
Add code to your application to expose metrics (e.g., using a Prometheus client library), emit structured logs, and generate trace spans. This is the foundation of observability because without data, you cannot observe anything.
Collect Metrics with Prometheus
Configure Prometheus to scrape your application's metrics endpoint at regular intervals. Prometheus stores these numerical values in a time-series database, allowing you to see trends over time.
Centralise Logs with a Log Aggregator
Use a tool like Fluentd or Logstash to collect logs from all containers and send them to a central store like Elasticsearch. This makes it possible to search through logs from every service in one place.
Set Up Distributed Tracing
Use a tool like Jaeger or OpenTelemetry to propagate trace context across services. Each service adds a span to the trace, recording the duration and any errors. This lets you visualise the entire journey of a request.
Create Dashboards and Alerts
Use Grafana to build dashboards that display key metrics (CPU, request latency, error rates). Set up alerts in Prometheus or Grafana to notify your team when metrics exceed thresholds, such as error rate above 5%.
Investigate Incidents Using All Pillars
When an alert fires, start with metrics to see the scope and timing of the problem. Drill into logs for error details, then use traces to find the exact service and request that caused the issue. This structured approach speeds up diagnosis.
Imagine you are an IT operations engineer at a company called 'ShopFast', an online clothing retailer. ShopFast runs its entire e-commerce platform on Kubernetes, with dozens of microservices handling everything from user logins to payment processing. One day, customers start reporting that the website is slow, especially when they try to search for products. Here is how you would use observability to diagnose and fix the problem, step by step.
First, you open your Grafana dashboard, which is connected to Prometheus. You look at the metrics for the search service. You see that the CPU usage is normal, but the 'request latency' metric — the time it takes to respond to a search request — has jumped from 200 milliseconds to 5 seconds. The metric tells you there is a problem, but it does not tell you why. Next, you open your logging system. You search the logs for the search service around the time the latency spiked. You find multiple log entries that say 'ERROR cache miss for product catalogue data'. This tells you that the search service is failing to read from its cache, forcing it to fetch data from the database every time. But why is the cache failing?
Now you use distributed tracing. You trigger a test search request and follow its trace through the system. The trace shows you the request flowing from the web frontend to the search service, then to the product catalogue service, then to the database. The trace reveals that the product catalogue service is taking 4.8 seconds to respond. That is the bottleneck. The trace also shows you which specific database query is slow. Armed with this information, you look at the database metrics and see that a recent update to the product catalogue introduced a new index that is causing slow query performance.
You then roll back the database change, and the latency returns to normal. Without observability, you might have restarted the entire search service, wasting time. Observability gave you a precise diagnosis.
In day-to-day work, an IT professional would:
Set up Prometheus to collect metrics from every microservice.
Create Grafana dashboards that display key metrics like request count, error rate, and response time.
Configure alerts in Prometheus to notify the team when error rates exceed a threshold.
Use a log aggregator like Elasticsearch to centralise logs from all containers.
Implement distributed tracing using Jaeger or OpenTelemetry for critical user journeys.
Run 'post-mortem' reviews after incidents, using traces and logs to document exactly what went wrong.
The key takeaway is that observability is not a one-time setup. It is an ongoing practise of refining your dashboards, alerts, and log queries so that you can always answer the question: 'What is happening in my system, and why?'
The KCNA exam tests your understanding of observability in a direct but beginner-friendly way. You will be asked to identify the three pillars, match them to their definitions, and recognise the tools associated with each. The exam does not ask you to write Prometheus queries or configure Grafana dashboards. Instead, it tests conceptual knowledge and the ability to pick the correct tool for a given job.
Here are the exact concepts the KCNA exam loves to test:
The three pillars of observability: metrics, logs, and traces. You must know what each one is and what it measures.
Prometheus is the standard tool for metrics collection and alerting. Know that it uses a 'pull model' where it scrapes targets.
Grafana is the visualisation tool that connects to Prometheus (and other data sources) to create dashboards.
Logging is typically done using tools like Elasticsearch, Fluentd, and Kibana (the ELK stack) or Loki. Know that logs are unstructured text data.
Distributed tracing uses tools like Jaeger or Zipkin. Know that a trace consists of spans, and that tracing is essential for understanding latency in microservices.
The difference between 'monitoring' and 'observability'. Monitoring tells you if a system is up or down. Observability lets you debug why.
Common traps in the exam:
They might list a tool like 'Prometheus' and ask which pillar it belongs to. Some might confuse Prometheus with a logging tool. Remember: Prometheus is for metrics.
They might ask: 'Which pillar would you use to understand the path of a single user request across services?' The answer is tracing, not logging.
They might describe a scenario where a developer needs to see historical data about CPU usage. The correct answer is metrics, because metrics are numerical and time-stamped.
They might test your understanding of 'pull vs push' models. Prometheus pulls metrics from targets. Some logging tools push logs to a central server. Know the difference.
They might ask about 'OpenTelemetry' — know that it is a standard for collecting telemetry data (metrics, logs, traces) in a vendor-neutral way.
To memorise for the exam:
Metrics measure numbers (CPU, memory, requests).
Logs record events (errors, warnings, info messages).
Traces follow requests across services.
Prometheus + Grafana = metrics and dashboards.
ELK stack = logging.
Jaeger = tracing.
Do not overthink it. The exam is testing foundational knowledge. If you remember which tool does which job, and what each pillar measures, you will pass this section.
The three pillars of observability are metrics, logs, and traces, and each serves a distinct purpose in understanding your system.
Prometheus collects metrics using a pull model, and Grafana visualises them on dashboards.
Logs are unstructured text records of events, and they are crucial for debugging specific errors.
Traces follow a single request across multiple services, helping you identify performance bottlenecks.
Observability is broader than monitoring; it lets you ask new questions about your system without predefining every scenario.
For the KCNA exam, remember which tool belongs to which pillar: Prometheus (metrics), ELK/Loki (logs), Jaeger/Zipkin (traces).
OpenTelemetry is a standard for collecting all three types of telemetry data in a vendor-neutral way.
These come up on the exam all the time. Here's how to tell them apart.
Metrics
Numerical data points like CPU usage and request count.
Collected by Prometheus using a pull model.
Best for identifying trends and triggering alerts.
Logs
Text records of events like errors or warnings.
Collected by tools like Fluentd or Logstash using a push model.
Best for debugging specific events and understanding context.
Prometheus
A time-series database that stores metrics.
Uses a pull model to scrape targets.
Can send alerts based on metric thresholds.
Grafana
A visualisation tool that creates dashboards.
Connects to multiple data sources (Prometheus, Elasticsearch, etc.).
Does not store data itself; it queries data sources.
Monitoring
Focuses on predefined metrics and alerts.
Can only answer questions you already thought to ask.
Often uses a single source of data (e.g., CPU usage).
Observability
Includes metrics, logs, and traces together.
Lets you explore and answer novel questions.
Requires instrumentation and tooling across all three pillars.
Tracing
Follows a single request across services.
Uses spans with timing information.
Best for identifying latency bottlenecks in microservices.
Logging
Records all events from all services.
Uses unstructured or structured text messages.
Best for understanding the context of an error or state change.
Mistake
Observability and monitoring are the same thing.
Correct
Observability is a broader concept that includes monitoring. Monitoring tells you if a system is up or down based on predefined metrics. Observability lets you explore the system to answer questions you did not anticipate, using metrics, logs, and traces.
The terms are often used interchangeably in casual conversation, but the exam distinguishes them. Beginners conflate them because both involve dashboards and alerts.
Mistake
Logs are enough to debug every problem.
Correct
Logs are great for recording events, but they are unstructured and can be overwhelming. For performance problems, metrics give you the numerical trend, and traces show you the exact path a request took. You need all three pillars.
Beginners often come from a background where they only used logs in small applications. They underestimate the complexity of distributed systems.
Mistake
Prometheus can be used to collect logs.
Correct
Prometheus is designed only for metrics (numerical data). It cannot ingest or search through log text. Tools like Fluentd or Logstash are used for logs.
The name 'Prometheus' sounds like a general monitoring tool, so beginners assume it does everything. The exam explicitly tests that Prometheus is for metrics.
Mistake
Tracing is only useful for very large companies like Google or Netflix.
Correct
Tracing is valuable for any application that uses microservices, even with just three services. It helps you find bottlenecks that metrics and logs alone cannot reveal.
Distributed tracing sounds complex and is often perceived as an advanced topic. Beginners think it is optional. The KCNA exam includes it as a fundamental pillar.
Mistake
You only need one pillar of observability to understand your system.
Correct
Each pillar gives a different perspective. Metrics tell you what is happening, logs tell you details about specific events, and traces tell you the flow. Using all three gives you full observability.
Beginners want simplicity. They think one tool can replace three. The exam explicitly teaches that they are complementary.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Monitoring is the practise of checking predefined metrics to see if a system is healthy. Observability is the ability to understand the internal state of a system by examining its outputs (metrics, logs, traces), even for problems you did not anticipate.
Kubernetes provides basic monitoring for pods and nodes (e.g., via kubectl top), but it does not include a full observability stack. You need to add tools like Prometheus, Grafana, and a logging solution yourself.
Yes, Grafana supports many data sources, including Elasticsearch for logs, MySQL for relational data, and InfluxDB for metrics. However, for the KCNA exam, the most common pairing is Prometheus and Grafana.
A span is a single unit of work in a distributed trace. It represents one operation, like a database query or an HTTP request, and includes a start time, end time, and optional metadata. Spans are linked together to form a complete trace.
The pull model means Prometheus reaches out to scrape metrics from targets. This makes it easier to detect when a target is down (because the scrape fails) and avoids overwhelming the network with pushed data from every service.
ELK stands for Elasticsearch, Logstash, and Kibana. Elasticsearch stores and indexes logs, Logstash collects and transforms logs, and Kibana provides a web interface for searching and visualising logs. It is a common logging solution.
You've finished Observability: Monitoring, Logging, and Tracing. Continue through the KCNA study guide to build a complete picture of the exam.
Done with this chapter?