Design a Metrics Monitoring & Alerting System
Design a Metrics Monitoring & Alerting System
Observability platforms ingest millions of metric data points per second from microservices, store them in time-series databases, evaluate real-time alert rules, and render low-latency query dashboards.
1. System Requirements
Functional Requirements
- Metrics Ingestion: Collect counters, gauges, and histograms from distributed hosts and microservices (e.g.
cpu_usage{host="srv-1"} 78.4 1672531199). - Time-Series Querying: Support fast range queries and aggregations across custom tag dimensions.
- Alerting Rules: Continuously evaluate alerting thresholds (e.g.
p99 latency > 500ms for 5m) and dispatch PagerDuty/Slack webhooks. - Dashboards: Visualize real-time graphs with sub-second page loads.
Non-Functional Requirements
- Massive Write Throughput: Ingest 10 Million metric samples per second.
- Storage Efficiency: Compress time-series data to $< 1.5\text{ bytes per data point}$ using delta-of-delta and Gorilla compression.
- Query Latency: Dashboard queries over past 1 hour return in $< 200\text{ms}$.
2. Ingestion Model: Pull vs. Push
Pull Model (Prometheus Style)
- The central metrics engine periodically scrapes an
/actuator/prometheusHTTP endpoint exposed by each microservice. - Pros: Simple client implementation; easy detection of down/unreachable nodes.
- Cons: Requires service discovery mechanism (Consul/Kubernetes DNS); struggles with ephemeral serverless functions (AWS Lambda).
Push Model (Datadog Style)
- Lightweight agents running on every server stream UDP/gRPC packets to a local forwarder or central collector.
- Pros: Natural fit for dynamic/ephemeral workers; supports high-frequency telemetry.
- Cons: Influx spikes can overwhelm ingestion servers unless cushioned by an upstream Kafka buffer.
3. High-Level Architecture Blueprint
+-----------------------+
| Monitored Services |
+-----------+-----------+
|
| gRPC / OTLP Metrics Stream
v
+-----------------------+
| Ingestion Gateway |
+-----------+-----------+
|
v
+-----------------------+
| Kafka Metrics Buffer |
+-----+-----------+-----+
| |
+------------------------+ +------------------------+
| Raw Metrics Stream | Alert Evaluation Stream
v v
+------------------------+ +------------------------+
| Time-Series DB (TSDB) | | Alerting Rule Engine |
| (Gorilla Compression / | | (Sliding Window Engine)|
| ClickHouse / InfluxDB) | +-----------+------------+
+------------------------+ |
v
+------------------------+
| PagerDuty / Slack Alert|
+------------------------+Key Architecture Trade-Offs & Decision Matrix
| Dimension | Option A: Asynchronous / Decoupled | Option B: Synchronous RPC | Trade-off & Recommendation |
|---|---|---|---|
| Communication Pattern | Message Queues (Kafka / SQS) | Direct gRPC / REST Calls | Message queues prevent cascading failures and provide backpressure buffering. |
| Failure Handling | Dead Letter Queue (DLQ) with Exponential Backoff | Immediate Circuit Breaker trip | DLQ preserves unparseable messages for manual operational inspection. |
| Ordering Guarantees | Partition-level Strict FIFO | Unordered Parallel Execution | Partition-key routing guarantees chronological order per entity without global lock contention. |
Related Topics
Expand your knowledge by learning about adjacent concepts in system design.
Design a Distributed Caching System (Redis Architecture)
Comprehensive architecture guide for designing production-grade Redis distributed caching clusters: master-replica replication, Redis Sentinel, Redis Cluster sharding, and memory eviction.
Event-Driven Architecture & Scaling with Apache Kafka
Design resilient, event-driven distributed architectures using Apache Kafka: topic partitioning, consumer group rebalancing, idempotence, and exactly-once semantics.
Sharding
Learn about sharding and when to use it in system design interviews.
Cheat Sheet Utility
View and print a concise system design reference card.