Compare Scenarios

Migration Step 1

Both scenarios define a migration step at this stage. Observability Platform: triggered by 'Prometheus storage limits reached at production metric volum'. Event-Driven Analytics Pipeline: triggered by 'OLTP query performance degrading due to analytics query inte'.

Migration Step 2

Both scenarios define a migration step at this stage. Observability Platform: triggered by 'Elasticsearch indexing pressure causing log rejection (HTTP '. Event-Driven Analytics Pipeline: triggered by 'Sub-minute analytics latency required; ETL scheduling overhe'.

Migration Step 3

Observability Platform has a defined migration; Event-Driven Analytics Pipeline does not at this stage.

ClickHouse part merge frequency increasing; dashboard queries timing out on metrics with high label cardinality; ClickHouse system.metrics showing active_parts count elevated; new metric instrumentation causing sudden storage growth disproportionate to fleet size; query_log showing metrics queries scanning full column segments without pruning

Tier 1: Metric Cardinality Budget Exceeded: Unbounded label cardinality generating millions of distinct time series that exceed ClickHouse part merge capacity and query planner pruning effectiveness. Recommended evolution: Enforce a cardinality budget at ingestion: before a metric is accepted, evaluate the distinct value count of each label dimension against a per-dimension limit (e.g., max 100 distinct values for any single label key). Reject or rewrite metrics that exceed the budget: rewrite user_id labels to user_cohort or drop them entirely. Implement a cardinality analysis dashboard showing the top 10 highest-cardinality metric series sorted by storage cost. ClickHouse distributed table partitioning by metric name reduces the impact of a single high-cardinality metric on global query performance. .

Kafka log topic consumer lag growing > 1 million messages during incident periods; Elasticsearch indexing throughput metrics showing queue buildup; incident post-mortems noting that relevant log records were not available in the search interface during the incident; log consumer memory pressure from unbounded batch accumulation

Tier 2: Log Volume Spike Exceeding Consumer Throughput: Log Kafka consumer sized for normal throughput; unable to drain the spike volume produced during incident-driven log floods. Recommended evolution: Size the log consumer for 10x normal throughput, not 1x: observability platform capacity must be planned for the incident scenario, not the steady state. Implement consumer autoscaling triggered by consumer lag metric: when Kafka consumer lag exceeds a threshold, add consumer instances automatically. Implement log sampling at the producer side for DEBUG and INFO level messages during identified spike periods : preserve all ERROR and WARN messages, sample INFO at 10%, sample DEBUG at 1%. This bounds the worst-case log volume without sacrificing diagnostic signal. .

pg_replication_slots shows growing pg_wal_lsn delta for CDC slot; PostgreSQL WAL directory growing faster than expected

Tier 1: CDC Slot Lag: Debezium / CDC connector not keeping up with write volume. Recommended evolution: Increase CDC connector parallelism; review filtered topics vs full-table CDC; monitor slot lag as a first-class SLA .

Kafka consumer group lag growing; analytics dashboards increasingly stale; consumer CPU and network I/O near ceiling

Tier 2: Kafka Consumer Lag: Insufficient consumer parallelism or insufficient Kafka partitions. Recommended evolution: Increase topic partition count (note: keyed messages lose ordering when partitions added); add consumer replicas up to partition count .