Prometheus exporter for Redis metrics.
Supports Redis 2.x, 3.x, 4.x, 5.x, 6.x, and 7.x

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

For pre-built binaries please take a look at the releases.

Add a block to the scrape_configs of your prometheus.yml config file:

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

and adjust the host name accordingly.

To have instances in the drop-down as human readable names rather than IPs, it is suggested to use instance relabelling.

For example, if the metrics are being scraped via the pod role, one could add:

          - source_labels: [__meta_kubernetes_pod_name]
            action: replace
            target_label: instance
            regex: (.*redis.*)

as a relabel config to the corresponding scrape config. As per the regex value, only pods with "redis" in their name will be relabelled as such.

Similar approaches can be taken with other role types depending on how scrape targets are retrieved.

The Prometheus docs have a very informative article on how multi-target exporters are intended to work.

Run the exporter with the command line flag --redis.addr= so it won't try to access the local instance every time the /metrics endpoint is scraped. Using below config instead of the /metric endpoint the /scrape endpoint will be used by prometheus. As an example the first target will be queried with this web request: http://exporterhost:9121/scrape?target=first-redis-host:6379

scrape_configs:
  ## config for the multiple Redis targets that the exporter will scrape
  - job_name: 'redis_exporter_targets'
    static_configs:
      - targets:
        - redis://first-redis-host:6379
        - redis://second-redis-host:6379
        - redis://second-redis-host:6380
        - redis://second-redis-host:6381
    metrics_path: /scrape
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: <<REDIS-EXPORTER-HOSTNAME>>:9121

  ## config for scraping the exporter itself
  - job_name: 'redis_exporter'
    static_configs:
      - targets:
        - <<REDIS-EXPORTER-HOSTNAME>>:9121

The Redis instances are listed under targets, the Redis exporter hostname is configured via the last relabel_config rule.
If authentication is needed for the Redis instances then you can set the password via the --redis.password command line option of the exporter (this 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).
You can also use a json file to supply multiple targets by using file_sd_configs like so:

scrape_configs:
  - job_name: 'redis_exporter_targets'
    file_sd_configs:
      - files:
        - targets-redis-instances.json
    metrics_path: /scrape
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: <<REDIS-EXPORTER-HOSTNAME>>:9121

  ## config for scraping the exporter itself
  - job_name: 'redis_exporter'
    static_configs:
      - targets:
        - <<REDIS-EXPORTER-HOSTNAME>>:9121

The targets-redis-instances.json should look something like this:

[
  {
    "targets": [ "redis://redis-host-01:6379", "redis://redis-host-02:6379"],
    "labels": { }
  }
]

Prometheus uses file watches and all changes to the json file are applied immediately.

Redis instance addresses can be tcp addresses: redis://localhost:6379, redis.example.com:6379 or e.g. unix sockets: unix:///tmp/redis.sock.
SSL is supported by using the rediss:// schema, for example: rediss://azure-ssl-enabled-host.redis.cache.windows.net:6380 (note that the port is required when connecting to a non-standard 6379 port, e.g. with Azure Redis instances).\

Command line settings take precedence over any configurations provided by the environment variables.

If your Redis instance requires authentication then there are several ways how you can supply a username (new in Redis 6.x with ACLs) and a password.

You can provide the username and password as part of the address, see here for the official documentation of the redis:// scheme. You can set -redis.password-file=sample-pwd-file.json to specify a password file, it's used whenever the exporter connects to a Redis instance, no matter if you're using the /scrape endpoint for multiple instances or the normal /metrics endpoint when scraping just one instance. It only takes effect when redis.password == "". See the contrib/sample-pwd-file.json for a working example, and make sure to always include the redis:// in your password file entries.

An example for a URI including a password is: redis://<<username (optional)>>:<<PASSWORD>>@<<HOSTNAME>>:<<PORT>>

Alternatively, you can provide the username and/or password using the --redis.user and --redis.password directly to the redis_exporter.

If you want to use a dedicated Redis user for the redis_exporter (instead of the default user) then you need enable a list of commands for that user. You can use the following Redis command to set up the user, just replace <<<USERNAME>>> and <<<PASSWORD>>> with your desired values.

ACL SETUSER <<<USERNAME>>> +client +ping +info +config|get +cluster|info +slowlog +latency +memory +select +get +scan +xinfo +type +pfcount +strlen +llen +scard +zcard +hlen +xlen +eval allkeys on > <<<PASSWORD>>>

The latest release is automatically published to the Docker registry.

You can run it like this:

docker run -d --name redis_exporter -p 9121:9121 oliver006/redis_exporter

Docker images are also published to the quay.io docker repo so you can pull them from there if for instance you run into rate limiting issues with Docker hub.

docker run -d --name redis_exporter -p 9121:9121 quay.io/oliver006/redis_exporter

The latest docker image contains only the exporter binary. If e.g. for debugging purposes, you need the exporter running in an image that has a shell then you can run the alpine image:

docker run -d --name redis_exporter -p 9121:9121 oliver006/redis_exporter:alpine

If you try to access a Redis instance running on the host node, you'll need to add --network host so the redis_exporter container can access it:

docker run -d --name redis_exporter --network host oliver006/redis_exporter

Here is an example Kubernetes deployment configuration for how to deploy the redis_exporter as a sidecar to a Redis instance.

Tile38 now has native Prometheus support for exporting server metrics and basic stats about number of objects, strings, etc. You can also use redis_exporter to export Tile38 metrics, especially more advanced metrics by using Lua scripts or the -check-keys flag.
To enable Tile38 support, run the exporter with --is-tile38=true.

Most items from the INFO command are exported, see Redis documentation for details.
In addition, for every database there are metrics for total keys, expiring keys and the average TTL for keys in the database.
You can also export values of keys by using the -check-keys (or related) flag. The exporter will also export the size (or, depending on the data type, the length) of the key. This can be used to export the number of elements in (sorted) sets, hashes, lists, streams, etc. If a key is in string format and matches with --check-keys (or related) then its string value will be exported as a label in the key_value_as_string metric.

If you require custom metric collection, you can provide a Redis Lua script using the -script flag. An example can be found in the contrib folder.

The metric redis_memory_max_bytes will show the maximum number of bytes Redis can use.
It is zero if no memory limit is set for the Redis instance you're scraping (this is the default setting for Redis).
You can confirm that's the case by checking if the metric redis_config_maxmemory is zero or by connecting to the Redis instance via redis-cli and running the command CONFIG GET MAXMEMORY.

Example Grafana screenshots:

Grafana dashboard is available on grafana.com and/or github.com.

If running Redis Sentinel, it may be desirable to view the metrics of the various cluster members simultaneously. For this reason the dashboard's drop down is of the multi-value type, allowing for the selection of multiple Redis. Please note that there is a caveat; the single stat panels up top namely uptime, total memory use and clients do not function upon viewing multiple Redis.

There is a set of sample rules, alerts and dashboards available in redis-mixin

PR #256 introduced breaking changes which were released as version v1.0.0.

If you only scrape one Redis instance and use command line flags --redis.address and --redis.password then you're most probably not affected. Otherwise, please see PR #256 and this README for more information.

When a single Redis instance is used for multiple purposes, it is useful to be able to see how Redis memory is consumed among the different usage scenarios. This is particularly important when a Redis instance with no eviction policy is running low on memory as we want to identify whether certain applications are misbehaving (e.g. not deleting keys that are no longer in use) or the Redis instance needs to be scaled up to handle the increased resource demand. Fortunately, most applications using Redis will employ some sort of naming conventions for keys tied to their specific purpose such as (hierarchical) namespace prefixes which can be exploited by the check-keys, check-single-keys, and count-keys parameters of redis_exporter to surface the memory usage metrics of specific scenarios. Memory usage aggregation by key groups takes this one step further by harnessing the flexibility of Redis LUA scripting support to classify all keys on a Redis instance into groups through a list of user-defined LUA regular expressions so memory usage metrics can be aggregated into readily identifiable groups.

To enable memory usage aggregation by key groups, simply specify a non-empty comma-separated list of LUA regular expressions through the check-key-groups redis_exporter parameter. On each aggregation of memory metrics by key groups, redis_exporter will set up a SCAN cursor through all keys for each Redis database to be processed in batches via a LUA script. Each key batch is then processed by the same LUA script on a key-by-key basis as follows:

1. The MEMORY USAGE command is called to gather memory usage for each key
2. The specified LUA regexes are applied to each key in the specified order, and the group name that a given key belongs to will be derived from concatenating the capture groups of the first regex that matches the key. For example, applying the regex ^(.*)_[^_]+$ to the key key_exp_Nick would yield a group name of key_exp. If none of the specified regexes matches a key, the key will be assigned to the unclassified group

Once a key has been classified, the memory usage and key counter for the corresponding group will be incremented in a local LUA table. This aggregated metrics table will then be returned alongside the next SCAN cursor position to redis_exporter when all keys in a batch have been processed, and redis_exporter can aggregate the data from all batches into a single table of grouped memory usage metrics for the Prometheus metrics scrapper.

Besides making the full flexibility of LUA regex available for classifying keys into groups, the LUA script also has the benefit of reducing network traffic by executing all MEMORY USAGE commands on the Redis server and returning aggregated data to redis_exporter in a far more compact format than key-level data. The use of SCAN cursor over batches of keys processed by a server-side LUA script also helps prevent unbounded latency bubble in Redis's single processing thread, and the batch size can be tailored to specific environments via the check-keys-batch-size parameter.

Scanning the entire key space of a Redis instance may sound a lttle extravagant, but it takes only a single scan to classify all keys into groups, and on a moderately sized system with ~780K keys and a rather complex list of 17 regexes, it takes an average of ~5s to perform a full aggregation of memory usage by key groups. Of course, the actual performance for specific systems will vary widely depending on the total number of keys, the number and complexity of regexes used for classification, and the configured batch size.

To protect Prometheus from being overwhelmed by a large number of time series resulting from misconfigured group classification regular expression (e.g. applying the regular expression ^(.*)$ where each key will be classified into its own distinct group), a limit on the number of distinct key groups per Redis database can be configured via the max-distinct-key-groups parameter. If the max-distinct-key-groups limit is exceeded, only the key groups with the highest memory usage within the limit will be tracked separately, remaining key groups will be reported under a single overflow key group.

Here is a list of additional metrics that will be exposed when memory usage aggregation by key groups is enabled:

If using Redis version < 4.0, most of the helpful metrics which we need to gather based on length or memory is not possible via default redis_exporter. With the help of LUA scripts, we can gather these metrics. One of these scripts contrib/collect_lists_length_growing.lua will help to collect the length of redis lists. With this count, we can take following actions such as Create alerts or dashboards in Grafana or any similar tools with these Prometheus metrics.

The tests require a variety of real Redis instances to not only verify correctness of the exporter but also compatibility with older versions of Redis and with Redis-like systems like KeyDB or Tile38.
The contrib/docker-compose-for-tests.yml file has service definitions for everything that's needed.
You can bring up the Redis test instances first by running make docker-env-up and then, every time you want to run the tests, you can run make docker-test. This will mount the current directory (with the .go source files) into a docker container and kick off the tests.
Once you're done testing you can bring down the stack by running make docker-env-down.
Or you can bring up the stack, run the tests, and then tear down the stack, all in one shot, by running make docker-all.

Note. Tests initialization can lead to unexpected results when using a persistent testing environment. When make docker-env-up is executed once and make docker-test is constantly run or stopped during execution, the number of keys in the database changes, which can lead to unexpected failures of tests. Use make docker-env-down periodacally to clean up as a workaround.

Open an issue or PR if you have more suggestions, questions or ideas about what to add.