Monitoring Microservices: A Practical Guide to Metrics, Logs, and Traces

Your checkout request in a microservices system can cross many services before it returns a response. When you can follow that request end to end, you can locate the slow dependency. 

When microservices spread your application across independently deployed services, host-centric monitoring alone can miss failures that cross service boundaries.

This guide covers what to collect from every service, which signals should page someone, and how to connect metrics, logs, and traces into one investigation path. Together those choices form a microservices monitoring strategy that each new service joins by adopting the same instrumentation and alerting rules.

Why Monitoring Microservices Is Different from Monitoring a Monolith

In a monolith, you can often investigate a failure within one process, one log file, and one stack trace. Microservices multiply that surface. In a 2023 survey of 300 IT and software engineering leaders, 39 percent of organizations using microservices managed 100 or more microservices.

A failure in that environment can cascade across service boundaries. The edge shows symptoms such as a latency spike or a rising error rate, while the service and dependency that caused them remain hidden. Autoscaling complicates Kubernetes monitoring because pods appear and disappear faster than a static list of hosts can keep up. 

That symptom-versus-cause gap is the observability vs monitoring distinction in practice. Monitoring confirms the what, and observability, built from correlated metrics, logs, and traces, supplies the why. 

A dashboard can show checkout’s error rate climbing, and a correlated trace can show that the errors start in a downstream dependency.

The Three Pillars of Microservices Telemetry

Metrics, logs, and traces each answer a different question. Microservices observability needs all three because a trace rebuilds the path of a request across services, logs record what happened at the failing step, and metrics show how often that failure occurs across all requests.

OpenTelemetry (OTel) instruments all three through one set of software development kits (SDKs), though support varies by language.

Metrics: What Is Happening Right Now

Metrics are numeric time-series samples such as request count, error rate, p50/p95/p99 latency per service, and pod CPU and memory. Prometheus scrapes them, Micrometer emits them from Java Virtual Machine (JVM) application code, and InfluxDB is an alternative store. 

The Rate, Errors, Duration (RED) method gives you a per-service template for request health. Raw CPU percentage and memory utilization belong on debugging dashboards and become alerts only when a resource is on track to run out. Many containers share a host, and high CPU on one node doesn’t necessarily mean a user is affected.

Logs: Why the Error Happened

Logs are timestamped records of discrete events, and they answer why a specific error occurred. Structured JavaScript Object Notation (JSON) with fields such as service name and status code gives a query engine something to filter without regular expressions (regex). 

The trace identifier (ID) field holds the correlation ID across services. A log line without one has only timestamps joining it to the lines other services wrote for the same request. 

OpenTelemetry’s log data model includes trace and span ID fields so application performance monitoring (APM) tools can move between a request’s trace and its logs. Fluentd or Fluent Bit, running as a node agent, ships every container’s output to a central store such as Grafana Loki or Elasticsearch.

Traces: Where in the Request Chain the Delay Sits

Traces follow one request across every service hop and show where in the chain latency or failure occurred. Under the long-standing World Wide Web Consortium (W3C) W3C Trace Context standard, the traceparent header carries the request’s trace ID and the calling span’s ID. OpenTelemetry propagates them by default, and when service A calls service B, B opens a child span inside A’s trace. 

Have the gateway or ingress create the trace ID and every downstream service forward it. This shared ID ties distributed tracing to log correlation. Jaeger and Zipkin are common open-source backends, or a commercial APM backend can store the spans.

The Four Golden Signals Every Microservice Should Expose

Long-standing site reliability engineering (SRE) guidance in Google’s SRE book recommends measuring the four golden signals and paging when one becomes problematic, defining them as “latency, traffic, errors, and saturation.” 

Latency, traffic, and errors are user-facing symptoms. For saturation, Google’s SRE book advises paging when a resource is nearly exhausted, such as a database disk predicted to fill within four hours. Raw CPU and memory readings stay on dashboards for debugging.

Signal	What to measure	What to alert on
Latency	Time to service a request, tracked as p50, p95, and p99 per endpoint, with successful and failed requests kept separate	Tail percentile crossing the target, with a slow error treated as worse than a fast one
Traffic	Requests per second per service, compared with its normal baseline	Deviation from baseline in either direction, including a drop to zero that can signal an upstream outage
Errors	Rate of failed requests, including explicit Hypertext Transfer Protocol (HTTP) 5xx errors, 200 responses with wrong content, and responses slower than the committed time	Convert raw error counts to an error budget burn rate for paging
Saturation	How full the most constrained resource is, for example CPU, memory, thread pools, connection pools	Predicted exhaustion, such as a disk on track to fill within hours

Burn rate makes the errors signal usable. It measures how fast the service consumes its error budget relative to its service level objective (SLO). 

Google’s SRE workbook recommends paging when a 14.4x burn rate holds over both the previous hour and the previous five minutes, which means two percent of a 30-day budget disappears in an hour. The workbook adds a 6x page over six hours and 30 minutes and a 1x ticket over three days and six hours to catch lower error rates that still drain the budget, with each short window at one-twelfth of its long window. 

Burn-rate paging tends to reduce the alert fatigue that static thresholds create. Coralogix SLO Center offers burn-rate alerts in a single mode that uses one window you set and a dual mode that adds a fixed 10-minute check with the same multiplier.

Key Challenges in Microservices Monitoring

These five problems grow with every service you add:

• Service dependency mapping: A slow downstream call can be hard to locate without a trace spanning the hop. During Roblox’s 73-hour outage in October 2021, the monitoring that could have explained the failure relied on Consul, one of the affected systems, and engineers spent several hours assembling a list of every service that used Consul and disabling the ones that weren’t essential.
• Alert fatigue: Static thresholds across many services can generate noise. Alert fatigue can slow incident response, and established symptom-based alerting practice ties each page to error and latency SLOs, which keeps pages focused on user impact.
• Data volume and cost: Each added service can increase log, metric, and trace volume. Elasticsearch moves older data through hot, warm, cold, and frozen tiers when you configure a lifecycle policy, while Loki indexes only labels and keeps compressed chunks in object storage, which narrows query flexibility.
• Tech stack diversity: Polyglot services need one instrumentation standard, and OTel provides SDKs across many languages. Its per-language status varies, with Java logs stable and Python and JavaScript logs still in development.
• Dynamic scaling: Pods under autoscaling can be short-lived, which leaves static scrape targets out of date. Prometheus’s Kubernetes service discovery reads targets from the Kubernetes application programming interface (API) and stays synchronized with cluster state.

OpenTelemetry addresses instrumentation differences, symptom-based alerts cut alert noise, and Kubernetes service discovery keeps scrape targets current as pods change. 

For dependency mapping and data cost, the Coralogix Service Map draws service dependencies from your distributed traces, and the TCO Optimizer routes data by policy into the Frequent Search, Monitoring, or Compliance tier, each priced for how you use that data.

Monitoring Microservices Best Practices

• Instrument with OpenTelemetry first: It’s vendor-neutral and holds the second-highest project velocity among more than 240 cloud-native foundation projects, behind only Kubernetes, with graduation in May 2026. Instrumenting once with OpenTelemetry means you can change backends without touching application code.
• Expose liveness and readiness endpoints: Services should expose health check endpoints such as /healthz or Spring Boot’s /actuator/health/liveness and /actuator/health/readiness, and Kubernetes restarts a container whose liveness probe fails and pulls a pod from Service load balancing when readiness fails. Your liveness checks should stay free of external systems,because a database outage can otherwise make Kubernetes restart every instance.
• Centralize log aggregation: Every container’s output goes through a node agent to one searchable store, since per-node log hunting is usually insufficient once a pod is evicted or its node fails.
• Alert on symptoms: A high burn rate or a p99 breach signals that users are affected, which makes those conditions worth a page. A practical approach is to page on these symptoms and surface likely causes as context inside each page or on debugging dashboards, which keeps on-call engineers from being paged for causes alone.
• Map services before an incident does it for you: A service catalog that records each service’s owner and dependencies turns “which service calls payments?” into a lookup and tells the pager which team to wake.
• Align monitoring with service ownership: The team that owns a service owns its dashboards, alerts, and SLO, with a shared system-wide view on top.

Coralogix correlates logs, metrics, and traces in one interface, and its log details panel links a log line to its full trace whenever the log carries the trace ID in a recognized field. A parsing rule can extract the ID when it sits inside the raw message.

Tools for Monitoring Microservices by Function

You can assemble an open-source stack with a tool for each telemetry job, or use a commercial product that bundles them:

• Metric collection and storage: Prometheus scrapes and stores time series, Micrometer instruments application code, and InfluxDB is an alternative time-series store.
• Distributed tracing: Jaeger and Zipkin store and visualize spans, and the OpenTelemetry Collector receives and exports them.
• Log shipping and aggregation: Fluentd and Fluent Bit run as node agents, and Grafana Loki and Elasticsearch store and query logs.
• Visualization: Grafana dashboards query Prometheus, Loki, and Jaeger side by side, though it’s another service to operate. Cloud-native suites bundle visualization with storage.
• Commercial unified platforms: Coralogix, Datadog, Dynatrace, and New Relic each ingest metrics, logs, and traces into a single product.

Whichever combination you choose, an investigation still depends on linking the metrics, logs, and traces those tools collect.

Connecting Metrics, Logs, and Traces into One Investigation Path

If you collect metrics, logs, and traces through OpenTelemetry, you can correlate them using trace IDs on spans, on logs when trace context is available, and in optional metric exemplars. 

When you also page on the golden signals using burn rate and use a shared interface, you can follow a checkout alert to the slow span in payments without switching tools. 

Coralogix is a unified observability platform that ingests all three signals through OpenTelemetry-native pipelines. If you want to see how quickly a trace ID takes you from a checkout alert to the failing span, start a free 14-day Coralogix trial with your own production telemetry.

Frequently Asked Questions About Monitoring Microservices

What are the best monitoring tools for microservices?

The answer depends on your telemetry needs. Prometheus and Micrometer for metrics, Jaeger or Zipkin for distributed tracing, and Fluentd, Fluent Bit, or Grafana Loki for log aggregation are the common open-source starting points. Grafana is the usual visualization layer across all three. You can consolidate onto one product so you aren’t switching tools mid-incident.

What is the difference between monitoring and observability in microservices?

Monitoring tells you what is wrong, such as a service returning errors or a spike in its latency. Observability identifies which downstream dependency caused the spike and which code path is responsible. Microservices observability, built on structured logs, metrics, and distributed traces, lets you follow a request from the entry point to the failure.

What are the seven principles of microservices?

One widely cited list is Sam Newman’s principles, which covers modeling around the business domain, a culture of automation, hiding implementation details, decentralization, independent deployment, failure isolation, and high observability. 

Other authors cut the list differently, and the 2014 microservices article by James Lewis and Martin Fowler describes nine characteristics. From a monitoring standpoint, failure isolation and high observability pair naturally, because a service that exposes its own health endpoint and telemetry keeps one failure from making the whole system opaque.

Is microservices architecture still widely used?

Yes. Container adoption is a proxy for microservices use. The share of organizations using containers for most or all production applications rose from 41 percent in 2023 to 56 percent in 2025. Maturing OpenTelemetry support and burn-rate alerting make the many services those containers run easier to monitor.