Prometheus exporter

Prometheus asks its questions over HTTP, but your disk, your router and your game server do not speak its language. The exporter does the translating.

The short answer

A Prometheus exporter is a small server that reads metrics from a system that cannot expose them in Prometheus format itself and serves them over HTTP, so the Prometheus server can scrape them [1][2]. The best-known example is the node_exporter, which reports hardware and kernel metrics of Linux and other Unix-like machines, such as CPU, memory, disks and network, and listens on port 9100 by default [3][4]. Our assessment: put a node_exporter on every machine you care about, add more exporters only for questions you really have, and keep their ports inside your own network.

How it works

1. Prometheus pulls. The server collects time series through a pull model over HTTP and scrapes its targets at a set interval. Pushing is possible only through an intermediary gateway, meant for short-lived jobs [2].
2. Why exporters exist. They help where instrumenting a system directly is not feasible, the Prometheus docs name HAProxy and Linux system stats as examples [1]. Some software already exposes Prometheus metrics itself, for example Grafana, the Docker daemon and Caddy, and needs no exporter [1].
3. The format is plain text. An exporter answers a GET request with lines such as # HELP, # TYPE and name{label="x"} 42, UTF-8 encoded and served as text/plain with version=0.0.4 [5]. A metric without a # TYPE line counts as untyped [5].
4. Official or not. Some exporters belong to the Prometheus GitHub organization and are marked official. The project says it encourages more exporters but cannot vet them all for best practices [1].
5. Collectors inside node_exporter. Many collectors are on by default, and you switch them with --collector.NAME or --no-collector.NAME, where NAME is the collector [3]. Two meta metrics, node_scrape_collector_success and node_scrape_collector_duration_seconds, show whether a collector worked [3]. The textfile collector reads *.prom files from a directory and serves them, which suits batch jobs; timestamps are not supported [3].
6. Containers need care. node_exporter is designed for the host system. In a container it needs the host namespaces (--net=host, --pid=host), a read-only bind mount of / and the flag --path.rootfs [3].
7. Access control exists. The exporter supports TLS and basic authentication through a web configuration file passed with --web.config.file. The README still marks this as experimental, and passwords in that file are stored as bcrypt hashes [3][6].
8. Naming rules. Good exporters use base units (seconds, bytes), snake_case names and _total for counters, and they expose ratios, not percentages [7].

A practical example

You start node_exporter on a Linux machine and check it with curl. Prometheus then scrapes it with a minimal configuration like the one in the official guide [4]:

curl http://localhost:9100/metrics | grep "node_"

global:
  scrape_interval: 15s

scrape_configs:
- job_name: node
  static_configs:
  - targets: ['localhost:9100']

In the expression browser, node_filesystem_avail_bytes then shows the space available to non-root users in bytes [4]. We have not documented a Prometheus setup in our inventory (14 to 16 Oct 2026), so this is a generic walk-through from the project's guide, not our own measurement.

Checklist

• Check the exporter's /metrics page with curl before you add it to Prometheus [4].
• Prefer software that exposes metrics natively over an extra exporter when both exist [1].
• Open exporter ports only to the Prometheus host, and add TLS or basic authentication if the network is shared [3][6].
• Watch node_scrape_collector_success to catch collectors that quietly fail [3].
• Disable collectors you do not need with --no-collector.NAME [3].
• Read third-party exporters before you run them, because the project does not vet them [1].