Observability vs Monitoring

When a single checkout in a microservices system touches ten services, two queues and three databases, "is it up?" stops being a useful question. The moment something is slow, you need to ask where and why — and that is exactly the line between monitoring and observability. Monitoring tells you the patient has a fever; observability lets you find the infection.

Both terms get used interchangeably in job descriptions, which is a mistake worth clearing up early. If you already understand how services fan out in a microservices architecture, this distinction will feel natural.

The core difference in one sentence

Monitoring answers questions you knew to ask in advance. Observability answers questions you did not.

Monitoring is threshold-driven: you decide CPU above 80% is bad, error rate above 1% is bad, and you get alerted when those lines are crossed. It is essential, but it only covers known failure modes. Observability is the property of a system that lets you understand its internal state from the outside — to slice, filter and correlate the data it emits and answer brand-new questions during an incident nobody predicted.

In practice, monitoring is a subset of observability. You build monitoring dashboards and alerts on top of the raw signals that make a system observable.

The three pillars of observability

Observability rests on three types of telemetry data. Interviewers love this list, so learn it cold.

Logs are timestamped records of discrete events: "order 4821 validated", "payment declined", "connection refused". They are rich in detail but expensive to search at scale.

Metrics are numeric measurements aggregated over time: requests per second, p99 latency, JVM heap used. They are cheap to store and perfect for dashboards and alerts, but they lose the detail of any single request.

Traces follow one request as it travels across every service. A trace is made of spans, one per operation, each with a start time and duration. Traces are what make microservices debuggable — they show you that the checkout took 3 seconds because the inventory service, hop number seven, stalled.

Pro tip: Remember the pillars by what question each answers. Metrics tell you something is wrong, logs tell you what the error was, and traces tell you where in the call chain it happened. You usually move metrics → traces → logs during a real incident.

A metric with Micrometer

Here is how you expose a custom metric in a Spring Boot service using Micrometer, the metrics facade that ships with Spring Boot Actuator. This counter increments every time an order is placed, so you can graph order throughput and alert if it drops to zero.

import io.micrometer.core.instrument.Counter;
import io.micrometer.core.instrument.MeterRegistry;
import org.springframework.stereotype.Service;

@Service
public class OrderService {

    private final Counter ordersPlaced;

    public OrderService(MeterRegistry registry) {
        this.ordersPlaced = Counter.builder("orders.placed")
                .description("Total orders placed")
                .tag("channel", "web")
                .register(registry);
    }

    public void placeOrder(Order order) {
        // ... business logic to save the order ...
        ordersPlaced.increment();   // one line makes it observable
    }
}

Prometheus scrapes the /actuator/prometheus endpoint, stores the counter over time, and Grafana turns it into a chart. That chart plus an alert rule is monitoring. The raw counter, queryable by any tag, is what makes the service observable.

Tracing across services with correlation IDs

The single most important habit for observable microservices is propagating a correlation ID. When a request enters at the API gateway, you assign it a unique ID and pass it to every downstream service in a header. Every log line then carries that ID, so you can reconstruct one user's journey across a dozen services.

import jakarta.servlet.*;
import jakarta.servlet.http.HttpServletRequest;
import org.slf4j.MDC;
import java.util.UUID;

public class CorrelationIdFilter implements Filter {

    @Override
    public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain)
            throws java.io.IOException, ServletException {
        HttpServletRequest http = (HttpServletRequest) req;
        String id = http.getHeader("X-Correlation-Id");
        if (id == null || id.isBlank()) {
            id = UUID.randomUUID().toString();
        }
        MDC.put("correlationId", id);      // now every log line includes it
        try {
            chain.doFilter(req, res);
        } finally {
            MDC.clear();                   // prevent leaking to the next request
        }
    }
}

With the ID in the logging MDC and a log pattern that prints %X{correlationId}, a support engineer can paste one ID into the log search and see the full story. Modern tooling like OpenTelemetry automates this propagation, but understanding the manual version is what proves you get the problem it solves.

Common mistake: Teams add flashy dashboards and call it observability. Dashboards are monitoring. If, during an unexpected outage, you cannot filter your telemetry by a dimension nobody thought to pre-aggregate — say, requests from a single customer in one region — your system is being monitored but is not truly observable.

How this plays out during a real incident

Walk through a typical checkout outage to see the pillars work together.

At 9:05 the metrics dashboard fires an alert: checkout error rate jumped from 0.2% to 6%. That is monitoring doing its job — it caught a known bad signal. But the metric alone cannot tell you which of ten services is failing.

You open distributed traces filtered to failed checkouts and notice every broken trace stalls on the same span: the call to the payment service, which is timing out. That is observability narrowing the search from "the system" to "one hop".

Finally you pull the logs for that service using the correlation IDs from the failed traces and read the actual exception: the payment provider's TLS certificate expired. Metrics found the symptom, traces located the fault, logs explained the cause. No single pillar would have solved it alone.

This is also where resilience patterns connect. A well-placed circuit breaker would have stopped the failing payment calls from cascading, and your observability data is exactly what tells you the breaker tripped and why.

Where the boundary blurs

Do not treat monitoring and observability as rivals — you need both, and they overlap.

Monitoring gives you fast, cheap, always-on alerting. You cannot afford to run expensive trace-level analysis on every request, so aggregated metrics remain the front line. Observability gives you depth on demand, so when an alert fires you can investigate causes you never coded an alert for.

A mature microservices team runs metrics-based alerting for the 20 known failure modes, keeps traces and structured logs flowing for the infinite unknown ones, and uses correlation IDs to tie them together. Message-driven systems add another dimension: when services talk over Apache Kafka, you also want to observe consumer lag and topic throughput, because a silent consumer can break a flow without throwing a single HTTP error.

Why interviewers ask about this

Observability separates candidates who have only built toy CRUD apps from those who think about running software in production. When an interviewer asks "how would you debug a slow request that spans five services?", they are testing whether you reach for distributed tracing rather than adding random print statements.

A strong answer names the three pillars, explains that monitoring alerts on known thresholds while observability lets you investigate the unknown, and mentions correlation IDs or OpenTelemetry for stitching a request together. You do not need to have operated a Prometheus cluster; you need to reason about it clearly. Practise articulating this until it is second nature — you can rehearse it against the microservices interview questions guide.

Related concepts to study next

Observability rarely stands alone. Pair it with resilience patterns so you not only see failures but survive them, and with the fundamentals of how requests flow through a distributed system in the first place.

If you are building services on the JVM, the practical next step is wiring Actuator, Micrometer and structured logging into a real app — something we cover hands-on in the Java Full Stack with AI program at CodeBegun, where you instrument a multi-service project and read your own traces. Start from the Spring Boot fundamentals if you have not built a service yet, then return here and instrument it. Seeing your own correlation ID travel across services is the moment observability stops being a buzzword and becomes a skill.