How Hepsiburada Centralized Monitoring with VictoriaMetrics

To monitor its massive infrastructure spanning over 2000 Ubuntu servers and 500+ Kubernetes clusters, Hepsiburada long relied on isolated Prometheus and Grafana stacks per service group. This setup suffered from a hard 14-day retention limit, no unified visibility, inconsistent alerting rules across environments, and heavy operational overhead. An earlier attempt to extend retention with Thanos also fell short due to compactor reliability issues, slow cross-time-range queries, and growing component complexity.

The team migrated to VictoriaMetrics, a Prometheus-compatible time-series database with native clustering support, to address these problems directly. Its superior compression solved the cost-driven retention limit, while storing data on local disks instead of object storage made even multi-month queries return in seconds. With only three core components—vminsert, vmselect, and vmstorage—the architecture became simpler and easier to maintain than the previous Thanos setup.

The new design runs two independent VictoriaMetrics clusters, vmetrics-av for Europe and vmetrics-as for Asia, ensuring geographic separation and monitoring high availability. On the server side, Consul-based service discovery feeds a central Prometheus instance that now only performs remote_write instead of storing data locally, cutting its retention to just two days and nearly eliminating per-instance maintenance costs. Kubernetes clusters follow the same pattern, with ArgoCD-managed Prometheus stacks forwarding metrics to the appropriate regional VictoriaMetrics deployment.