Prometheus — scrape config, exporters, PromQL and alerting rules — CI/CD, GitOps, DevSecOps & Observability

Prometheus is the de facto standard metrics system for cloud-native environments, designed for reliability—it continues to function even when individual targets are down—and for the dimensional data model that enables powerful aggregation queries. Its pull-based scrape model, where Prometheus periodically fetches metrics from configured endpoints, is fundamentally different from push-based systems: targets expose a `/metrics` endpoint in the Prometheus exposition format, and Prometheus queries that endpoint on its schedule. This pull model provides a natural discovery mechanism for Kubernetes workloads and makes it easy to test what data a target exposes without deploying any configuration.

The combination of Prometheus for collection and PromQL for querying provides a complete metrics observability platform. PromQL is a functional query language designed for time-series data, with primitives for computing rates over time windows, aggregating across label dimensions, and computing quantiles from histograms. Together with the Prometheus Operator's Kubernetes-native CRDs—ServiceMonitor, PodMonitor, and PrometheusRule—Prometheus integrates natively into GitOps-managed Kubernetes environments where all configuration is version-controlled and applied declaratively.

Analogy🏏Cricket

Think of it like cricket: Imagine the BCCI's team management system for an international tour with matches in three different countries simultaneously. Rather than a coordinator manually managing each match day's logistics, the system reads the official tour schedule document and automatically dispatches the right squad, equipment, and support staff to each venue. When the tour schedule changes—a match is rescheduled, a squad member is replaced—the system detects the change and updates the arrangements automatically. Just as the tour management system uses the official document as the source of truth and orchestrates multiple concurrent deployments to multiple venues, ArgoCD uses the Git repository as the source of truth and orchestrates multiple concurrent Application syncs to multiple clusters. Just as the system provides a dashboard showing which venues are 'ready', 'delayed', or 'degraded', ArgoCD provides a dashboard showing which Applications are Synced, OutOfSync, or Degraded. This reveals why ArgoCD is valued at scale: managing dozens of applications across multiple clusters manually is operationally equivalent to coordinating an international cricket tour by phone.