Prometheus

In my previous post on Prometheus and Thanos, I covered the sidecar architecture — Thanos Sidecar runs alongside Prometheus, uploads TSDB blocks to object storage, and exposes data to the Querier. It works beautifully for clusters with stable connectivity to your central infrastructure. But what happens when your clusters are at the edge? When they might lose connectivity for hours or days? When you’re running dozens or hundreds of small clusters and don’t want sidecar complexity on each one? ...

You can’t fix what you can’t see. You can’t optimize what you can’t measure. Prometheus is the standard for Kubernetes metrics. It works beautifully — until you need long-term storage, or multiple clusters, or high availability. Then you hit its limits. Thanos extends Prometheus without replacing it. Keep your existing setup, add Thanos components, get unlimited retention and global querying. The Problem with Standalone Prometheus Prometheus has built-in limitations: Single node — No native clustering or HA Local storage — Retention limited by disk size Single cluster view — Can’t query across clusters No downsampling — Old data takes as much space as new For a single small cluster with 2 weeks retention, these aren’t problems. For production multi-cluster environments with compliance requirements, they’re blockers. ...