redis_exporter: Prometheus metrics for Valkey and Redis, including cluster node discovery

What redis_exporter solves, and who ends up running it

Prometheus scrapes HTTP endpoints that return metrics in its text format. Valkey and Redis speak RESP on port 6379, so Prometheus cannot read them directly. redis_exporter sits between the two: it connects to a Valkey or Redis instance with a Redis client, collects the server's own statistics, and re-publishes them as Prometheus metrics on port 9121. The README describes it as a "Prometheus exporter for Valkey metrics (Redis-compatible)" and lists support for Valkey 7.x, 8.x and 9.x.

The people who run it are platform and SRE teams that already operate Prometheus and want cache-layer visibility in the same dashboards and alert rules as the rest of their stack. The repository's docker-compose.yml shows the range of targets the project tests against: valkey/valkey:9, valkey/valkey-bundle:9, redis:8.6.3, redis:8.8 and redis:7.4, plus a replica, a TLS instance and a password-protected instance. That file is the clearest statement of scope you will find in the repository: it is not a Redis client library, it is an adapter whose job is to make an existing server observable.

How the exporter turns a Redis connection into Prometheus metrics

The exporter is a Go program. go.mod pins the module path github.com/oliver006/redis_exporter and pulls in github.com/gomodule/redigo as the Redis client, github.com/mna/redisc for cluster handling, and github.com/prometheus/client_golang for the metric registry and HTTP handler. That dependency list tells you the shape of the thing: redigo does the RESP conversation, client_golang serves the result, and redisc is what makes Redis Cluster a first-class case rather than a set of separate scrape jobs.

The default mode is single-target. The process holds one address (set with --redis.addr) and answers /metrics by querying that instance. The multi-target mode inverts this: start the exporter with --redis.addr= so it does not touch a local instance on every scrape, and let Prometheus drive the target through the /scrape endpoint. The README gives the example request http://exporterhost:9121/scrape?target=first-redis-host:6379, so the target is a query parameter rather than a startup flag. Prometheus reaches that endpoint through relabel_configs, which rewrite each configured target into a __param_target value.

Cluster discovery is the third mode. Started with --is-cluster, the exporter exposes /discover-cluster-nodes, which the README presents as an HTTP service discovery endpoint for Prometheus (http_sd_configs). Prometheus refreshes the node list from that URL and then scrapes each discovered node through /scrape. The README's example uses refresh_interval: 10m. This is the part of the design that saves the most manual work, because a resharded cluster changes its node set and a static target list does not.

Installing redis_exporter and scraping your first Valkey instance

The README gives two paths. Build from source with Go, or take a pre-built binary from the releases page. The build path clones the repository and compiles the current directory into a binary named after the module directory.

git clone https://github.com/oliver006/redis_exporter.git
cd redis_exporter
go build .
./redis_exporter --version

The last command prints the version, which is the quickest way to confirm the toolchain produced a working binary. go.mod requires Go 1.26.0, so an older toolchain will refuse to build.

The Dockerfile builds a static binary and offers two release images: a scratch image and an Alpine image, both running as user 59000:59000 and both exposing port 9121 with ENTRYPOINT ["/redis_exporter"]. If you prefer containers, that is the port to publish.

Once the exporter is running, Prometheus needs a scrape config. The README's basic block is short:

scrape_configs:
  - job_name: redis_exporter
    static_configs:
    - targets: ['<<REDIS-EXPORTER-HOSTNAME>>:9121']

Replace the placeholder with the host running the exporter. After a reload, the target should show as UP and metrics should appear under the redis_ prefix. For more than one Redis instance, the README switches to the multi-target pattern: run the exporter with --redis.addr=, set metrics_path: /scrape on the job, and add the three relabel rules that map __address__ to __param_target, copy __param_target into the instance label, and replace __address__ with the exporter host and port. Targets are written as URIs such as redis://first-redis-host:6379.

The single-password constraint and other limits worth knowing before you commit

The README is explicit about the biggest operational limitation in multi-target mode: authentication is set with the --redis.password command line option, which "means you can currently only use one password across the instances you try to scrape this way. Use several exporters if this is a problem." For a fleet where each tenant or environment has its own credential, that turns into one exporter process per password. It works, but it is a deployment decision you should make deliberately rather than discover during an incident. The docker-compose.yml reflects the same pressure: pwd-redis8 runs with --requirepass redis-password, and the test URIs in the Makefile carry credentials inline, for example redis://:redis-password@localhost:16380 and redis://exporter:exporter-password@localhost:16390.

TLS has a related wrinkle that the README addresses directly: for TLS targets whose certificate hostname differs from the target address, pass tls_server_name to /scrape, for example through the Prometheus relabel target __param_tls_server_name. That is a per-target override rather than a global setting, which is the right shape, but it does mean your relabel configuration grows a rule per certificate mismatch.

The README excerpt ends mid-sentence at the cluster defaults ("By default, Redis "), so the behaviour of cluster mode when a node is unreachable, and the exact defaults for the discovery endpoint, are not documented in the README text available for this review. Treat that as something to confirm against the current README or the source before you depend on it.

Where redis_exporter is the wrong tool

If you do not run Prometheus, this project does nothing for you. It has no built-in dashboard, no alerting engine and no storage; it produces a metrics endpoint and stops there. Teams on a hosted metrics service, or on an agent-based collector that already speaks the Redis protocol, gain nothing from adding a second process to the path.

It is also the wrong choice for application-level timing. The exporter reads server statistics. If you need to know how long a specific command took from a specific caller, that belongs in your application's own instrumentation, not in a scrape of the cache.

Finally, a single exporter process scraping many targets concentrates failure. The multi-target pattern means one process is the scrape path for every Redis host in a job. The README's own answer to the password limitation (run several exporters) is also the answer to blast radius, and it is worth taking seriously rather than treating the exporter as a singleton by default.

How it compares with running a Redis client library yourself

The obvious alternative is a small custom collector: a Go or Python service that connects with a Redis client, calls INFO and related commands, and registers the results with the Prometheus client library for that language. That is genuinely not much code, and it gives you exactly the metrics you care about.

The difference is in what you inherit. redis_exporter already depends on redigo and redisc, so cluster topology handling is part of the binary. Its test matrix, visible in the Makefile, spans Valkey 9, a Valkey 9 replica, a Valkey bundle image, TLS on both Valkey and Redis 7, Redis 5 through 8.8, KeyDB instances, password-protected and user-password instances, and both a Valkey cluster and a Redis 8.8 cluster. TEST_VALKEY_CLUSTER_MASTER_URI, TEST_VALKEY_CLUSTER_SLAVE_URI and TEST_VALKEY_CLUSTER_PASSWORD_URI show that cluster authentication is exercised too. Matching that coverage in a bespoke collector is a maintenance commitment, not a weekend task.

The counter-argument is real: a custom collector emits only what you ask for, while the exporter's metric set is fixed by the project. If your need is narrow and stable, the exporter may be more surface area than you want. The deciding question is whether you expect your Redis topology to change. If it will, the cluster discovery endpoint is the feature that justifies the dependency.

Maintenance, releases and what the MIT licence means for you

The repository is not archived, and the last push was on 2026-09-23. Releases are frequent: v1.92.0 on 2026-09-23, v1.91.1 on 2026-09-07 and v1.91.0 on 2026-09-07. That cadence matters for an exporter, because it tracks upstream server releases, and the docker-compose.yml already references valkey/valkey:9, redis:8.6.3 and redis:8.8.

The licence is MIT. In practical terms that permits commercial use, modification and redistribution with the licence text retained. It gives no patent grant and no warranty, and it is not a legal opinion; if your organisation has a policy on bundled dependencies, note that the binary links redigo, redisc, client_golang, logrus, golang.org/x/crypto and their transitive dependencies, each under its own licence. The repository ships a LICENSE file at the top level.

Upgrade cost is low but not zero. The exporter is a single binary with no schema migrations and no persistent state, so a version bump is a container image change plus a restart. The exposure is in your Prometheus configuration: if a release changes metric names or the shape of the discovery endpoint, dashboards and alerts referencing those names need updating. Pin the image tag rather than tracking latest, and read the release notes before moving across a minor version.

Editorial conclusion

Adopt redis_exporter if you already run Prometheus and need Valkey or Redis metrics without writing a collector: the /scrape endpoint, the --is-cluster flag and the /discover-cluster-nodes HTTP SD endpoint cover single instances, fleets and clusters from one binary. Do not adopt it if you need per-target passwords across many instances, since the README states --redis.password gives you one password for all targets and suggests running several exporters instead. Before rolling it out, read the README section on the /scrape endpoint and confirm which flags your version supports, because the README excerpt ends mid-sentence at the cluster defaults and does not document rollback or a security model for the HTTP endpoints.

Frequently asked questions

Official sources

1. License: MIT
2. oliver006/redis_exporter on GitHub
3. Project website
4. README
5. Releases