Monitoring Microservices: Sidecars, Daemons, and Centralized Checks

Microservices introduce 10x the complexity. Learn the 3 architectures for monitoring them effective: The Sidecar, The DaemonSet, and The Central Scraper.

J
Jesus Paz
2 min read

With a Monolith, you have one thing to monitor. With Microservices, you have 50 things. And they all talk to each other. And when one fails, they all seemingly fail.

How do you monitor this mesh without going insane? There are three main architectural patterns.

1. The Sidecar Pattern

How it works: You run a tiny monitoring agent container inside the same Pod as your application container.

  • Pros: The agent shares the localhost network. It can scrape metrics securely without encryption.
  • Cons: Resource Overhead. If you have 1,000 pods, you have 1,000 sidecars consuming excessive RAM.

2. The DaemonSet Pattern (Kubernetes)

How it works: You run ONE monitoring agent per Kubernetes Node (Server).

  • Pros: Efficient. 100 Nodes = 100 Agents, regardless of how many pods are running.
  • Cons: Complexity. The agent needs permissions to query the Kubelet API to discover all the pods running on that node.

3. The Central Scraper (Cluster Uptime Style)

How it works: A centralized service (outside the cluster or in a dedicated namespace) “pings” the public or internal endpoints of your services.

  • Pros: Simplicity. It simulates the actual traffic flow.
  • Cons: Network policies might block access.

Synthetic Transactions (The Golden Key)

Don’t just check “Is the generic API up?” Write a Synthetic Transaction that touches multiple microservices.

Scenario: E-Commerce.

  1. Frontend Service: Returns 200 OK.
  2. Auth Service: Returns Token.
  3. Cart Service: Adds Item.
  4. Inventory Service: Reserves Item.

If you write a single Cluster Uptime Monitor that performs this 4-step chain, you are validating the health of 4 microservices with one check. If step 3 fails, you know exactly where the breakage is.

Distributed Tracing

Monitoring tells you that you are broken. Tracing tells you where. Pair Cluster Uptime (for the “It’s Broken” alert) with Jaeger/Tempo (for the “Why” investigation). When an alert fires, grab the TraceID and paste it into Jaeger to see the waterfall of failing calls.

👨‍💻

Jesus Paz

Founder

Read Next

Join 1,000+ FinOps and platform leaders

Get uptime monitoring and incident response tactics delivered weekly.