Monitoring Things You Don't Own
The Pull model works great if you can modify your application code to expose a /metrics endpoint. But what about a database like PostgreSQL, a web server like Nginx, or hardware sensors? You can't change their source code.
An Exporter is a small standalone application designed to bridge this gap. It acts as a translator between a service's native instrumentation and the Prometheus metrics format.
How an exporter works:
- The exporter runs alongside the service you want to monitor (as a sidecar container in Kubernetes, or a separate process on the same host).
- It queries the service using that service's native interface — for example, connecting to PostgreSQL and running
SELECT * FROM pg_stat_activity, or reading Nginx'sstub_statuspage. - It translates those native stats into properly named and labeled Prometheus metrics.
- It exposes a
/metricsHTTP endpoint that Prometheus scrapes on its regular schedule.
Common exporters you'll encounter:
| Exporter | What It Monitors |
|---|---|
node_exporter |
Linux host metrics: CPU, memory, disk, network |
postgres_exporter |
PostgreSQL database internals |
nginx_prometheus_exporter |
Nginx connection and request stats |
blackbox_exporter |
External probing: HTTP, TCP, DNS, ICMP |
kube-state-metrics |
Kubernetes object state (pod status, deployment replicas) |
The exporter ecosystem is one of Prometheus's greatest strengths — there are hundreds of community-maintained exporters covering almost every piece of infrastructure software imaginable.