A Redis-compatible service can approach its memory limit or develop replication trouble before applications report an outage. redis_exporter gathers supported measurements from Redis or Valkey and exposes them to Prometheus for investigation and alerting. It helps teams monitor the data service rather than only the application using it. Optional collection of individual keys or key patterns needs care because scanning large datasets adds work and can expose application identifiers through monitoring labels.
Current guidance
This entry identifies oliver006/redis_exporter. Its current upstream describes a Prometheus exporter for Valkey and Redis-compatible metrics, while retaining the established repository and exporter name. That is exporter coverage, not a claim that Redis and Valkey have identical licenses, modules, commands or upgrade paths.
Collect the smallest set of metrics needed to understand memory pressure, replication, persistence and workload health. Optional key or key-pattern collection can introduce scan cost and expose application identifiers; assess it against dataset size and sensitivity. Use a monitoring identity with the commands required by the selected collectors, and configure TLS and authentication for the actual target engine.
For a replacement deployment, preserve instance labels and compare metric availability on the exact server versions. Review the exporter’s multi-target scrape mode and prevent untrusted clients from selecting arbitrary network targets. Validate alerts with a bounded test dataset, a failed connection and a replica-state change where available. A successful scrape does not prove backup recoverability or application compatibility after an engine migration.
Historical upstream link check · 2026-10-09
The recorded upstream address responded successfully (HTTP 200) on 2026-10-09. GitHub does not mark oliver006/redis_exporter archived or disabled; this does not establish active maintenance, support or compatibility. Link availability does not certify the historical installation instructions or current security support.
Website availability is separate from project, chart and image support. Use the current guidance and primary sources on this page to assess the distribution.
Historical Kubedex content
Preserved for context. Commands, versions, prices and results below reflect the original research.
redis_exporter is a Prometheus exporter for Redis metrics. This chart bootstraps a redis_exporter deployment on a Kubernetes cluster using the Helm package manager.
Prerequisites
- Kubernetes 1.8+ with Beta APIs enabled
Prometheus exporter for Redis metrics.
Supports Redis 2.x, 3.x, and 4.x
Exporters and integrations
There are a number of libraries and servers which help in exporting existing metrics from third-party systems as Prometheus metrics. This is useful for cases where it is not feasible to instrument a given system with Prometheus metrics directly (for example, HAProxy or Linux system stats).
Third-party exporters
Some of these exporters are maintained as part of the official Prometheus GitHub organization, those are marked as official, others are externally contributed and maintained.
We encourage the creation of more exporters but cannot vet all of them for best practices. Commonly, those exporters are hosted outside of the Prometheus GitHub organization.
The exporter default port wiki page has become another catalog of exporters and may include exporters not listed here due to the overlapping functionality or still being in development.
The JMX exporter can export from a wide variety of JVM-based applications, for example, Kafka and Cassandra.
Other third-party utilities
This section lists libraries and other utilities that help you instrument code in a certain language. They are not Prometheus client libraries themselves but make use of one of the normal Prometheus client libraries under the hood. As for all independently maintained software, we cannot vet all of them for best practices.
- Clojure: Prometheus-clj
- Go: go-metrics instrumentation library
- Go: gokit
- Go: prombolt
- Java/JVM: EclipseLink metrics collector
- Java/JVM: Hystrix metrics publisher
- Java/JVM: Jersey metrics collector
- Python-Django: django-prometheus
- Node.js: swagger-stats
Extending “Prometheus-kubernetes” to add custom monitoring
As we all aware, Prometheus (https://prometheus.io/) is a great tool to monitor Kubernetes cluster and pods. I have been part of setting up a monitoring tool using Prometheus and Grafana, the research landed me to a customized and easy-to-use Prometheus integrated with default monitoring setup for Kubernetes.
Architecture Overview
Let’s talk a little about how the architecture of ‘prometheus-kubernetes’ implementation. GitHub page talks about the overall design a little, so it will of our interest if we get to know the architecture first.
“Prometheus-kubernetes” is implemented based on the Prometheus-Operator from CoreOS. Prometheus Operator creates, configures, and manages Prometheus monitoring instances, the major advantage is that we don’t have to use any ‘scrape-configurations’ at Prometheus server instead it generates monitoring target configurations based on Kubernetes label queries.
Now, when you use the “Prometheus-kubernetes” package, you are ready to monitor your Kubernetes. For me, that was not enough, I wanted to monitor other applications deployed to Kubernetes like Redis, RabbitMQ, NodeJS, etc. This article covers how to monitor additional systems by making configuration changes on the ‘kubernetes-Prometheus’
Sources & further reading
Spotted something that needs another look?
Help improve this page →