Core components of Prometheus

WHAT THIS TESTS Whether you understand Prometheus's architecture and, crucially, its pull-based scraping model and label-based time-series storage.

A GOOD ANSWER COVERS The central Prometheus server does three things: discovery, scraping, and storage. It discovers targets through static configuration or dynamic service discovery integrations such as Kubernetes, Consul, or cloud APIs. It then pulls metrics by making HTTP GET requests to each target's /metrics endpoint on a configured scrape interval. Scraped samples are written to a local on-disk time-series database, where each series is uniquely identified by its metric name plus a set of key-value labels. Supporting components include exporters, which translate third-party systems into Prometheus format; the Pushgateway, for short-lived batch jobs that cannot be scraped; and Alertmanager, which receives fired alerts and handles grouping, deduplication, silencing, and routing to receivers like email or PagerDuty. PromQL is the query language used for dashboards and alert rules.

COMMON WRONG ANSWERS Saying Prometheus pushes metrics by default; it pulls. Claiming it is built for durable long-term storage; local storage is intended for relatively recent data and you use remote write for long-term. Confusing Alertmanager with the rule evaluation, which happens in the server.

LIKELY FOLLOW-UPS Why pull over push? How does it handle high availability? What is remote write and when do you need it?

ONE CONCRETE EXAMPLE In a Kubernetes cluster, Prometheus uses the Kubernetes service-discovery integration to find all pods labeled for scraping. Every 15 seconds it scrapes each pod's /metrics endpoint, stores series like http_requests_total{pod="api-7",code="500"} in its TSDB, evaluates an alert rule on the error rate, and when the rule fires sends the alert to Alertmanager, which groups it and pages the on-call engineer.