Free Report! Gartner® Hype Cycle™ for Monitoring and Observability.Read more

How to Monitor Redis with OpenTelemetry

Deepa Ramachandra
Deepa Ramachandra

We’re excited to announce that we’ve recently contributed Redis monitoring support to the OpenTelemetry collector. You can check it out here!

You can utilize this receiver in conjunction with any OTel Collector, including the OpenTelemetry Collector and observIQ’s distribution of the collector.

Below are steps to get up and running quickly with observIQ’s distribution and shipping Redis metrics to a popular backend: Google Cloud Ops. You can find out more about it on observIQ’s GitHub page.

What signals matter?

Unlike other databases, monitoring the performance of Redis is relatively simple, focusing on the following categories of KPIs:

  • Memory Utilization
  • Database Throughput
  • Cache hit ratio and evicted cache data
  • Number of connections
  • Replication

All of the above categories can be gathered with the Redis receiver – so let’s get started.

Step 1: Installing the collector

The simplest way to get started is with one of the single-line installation commands shown below. For more advanced options, you’ll find various installation options for Linux, Windows, and macOS on GitHub.

You can use the following single-line installation script to install the observIQ distribution of the OpenTelemetry Collector. Just so you know, the collector must be installed on the Redis system.


1msiexec /i "" /quiet

Related Content: Rapid telemetry for Windows with OpenTelemetry and BindPlane OP


1sudo sh -c "$(curl -fsSlL"

Step 2: Setting up pre-requisites and authentication credentials

In the following example, we are using Google Cloud Operations as the destination. However, OpenTelemtry offers exporters for many destinations. Check out the list of exporters here.

Setting up Google Cloud exporter prerequisites:

If running outside of Google Cloud (On-prem, AWS, etc.) or without the Cloud Monitoring scope, the Google Exporter requires a service account.

Create a service account with the following roles:

  • Metrics: roles/monitoring.metricWriter
  • Logs: roles/logging.logWriter

Create a service account JSON key and place it in the system running the collector.


In this example, the key is placed at /opt/observiq-otel-collector/sa.json, and its permissions are restricted to the user running the collector process.

1sudo cp sa.json /opt/observiq-otel-collector/sa.json
2sudo chown observiq-otel-collector: /opt/observiq-otel-collector/sa.json
3sudo chmod 0400 /opt/observiq-otel-collector/sa.json

Set the GOOGLE_APPLICATION_CREDENTIALS environment variable by creating a systemd override. A systemd override allows users to modify the systemd service configuration without changing the service directly. This allows package upgrades to happen seamlessly. You can learn more about systemd units and overrides here.

Run the following command.

1sudo systemctl edit observiq-otel-collector

If this is the first time an override is being created, paste the following contents into the file:


If an override is already in place, insert the Environment parameter into the existing Service section.

Restart the collector.

1sudo systemctl restart observiq-otel-collector


In this example, the key is placed at C:/observiq/collector/sa.json.

Set the GOOGLE_APPLICATION_CREDENTIALS with the command prompt setx command.

Run the following command.

1setx GOOGLE_APPLICATION_CREDENTIALS "C:/observiq/collector/sa.json" /m

Restart the service using the services application.

Related Content: How to Install and Configure an OpenTelemetry Collector

Step 3: Configuring the Redis receiver

After the installation, the config file for the collector can be found at

  • C:\Program Files\observIQ OpenTelemetry Collector\config.yaml (Windows)
  • /opt/observiq-otel-collector/config.yaml(Linux)

Edit the configuration file and use the following configuration.

2  redis:
3    endpoint: "localhost:6379"
4    collection_interval: 60s
7  # Resourcedetection is used to add a unique (
8  # to the metric resource(s), allowing users to filter
9  # between multiple agent systems.
10  resourcedetection:
11    detectors: ["system"]
12    system:
13      hostname_sources: ["os"]
15  # Used for Google generic_node mapping.
16  resource:
17    attributes:
18    - key: namespace
19      value: "redis"
20      action: upsert
21    - key: location
22      value: "global"
23      action: upsert
25  normalizesums:
27  batch:
30  googlecloud:
31    retry_on_failure:
32      enabled: false
33    metric:
34      prefix:
35    resource_mappings:
36    - source_type: ""
37      target_type: generic_node
38      label_mappings:
39      - source_key:
40        target_key: node_id
41      - source_key: location
42        target_key: location
43      - source_key: namespace
44        target_key: namespace
47  pipelines:
48    metrics:
49      receivers:
50      - redis
51      processors:
52      - resourcedetection
53      - resource
54      - normalizesums
55      - batch
56      exporters:
57      - googlecloud

In the example above, the Redis receiver configuration is set to:

  1. Receive metrics from the Redis system at the specified endpoint.
  2. Set the time interval for fetching the metrics. The default value for this parameter is 10s. However, if exporting metrics to Google Cloud operations, this value is set to 60s by default.
  3. The resource detection processor is used to create a distinction between metrics received from multiple Redis systems. This helps with filtering metrics from specific Redis hosts in the monitoring tool, in this case, Google Cloud operations.
  4. In the Google Cloud exporter here, do the following mapping:
  • Set the target type to a generic node to simplify filtering metrics from the collector in cloud monitoring.
  • Set node_id, location, and namespace for the metrics. The resource processor sets the location and namespace.
  1. It is important to note that the project ID is not set in the googlecloud exporter configuration. Google automatically detects the project ID.
  2. Add the normalizesums processor to exclude the first metric with a zero value when the configuration is done and the collector is restarted.
  3. Add the batch processor to bundle the metrics from multiple receivers. We highly recommend using this processor in the configuration, especially for the benefit of the collector's logging component.
  4. It is recommended that the retry_on_failure be set to false. If this is not set, the retry attempts to fall into a loop for five attempts.

Step 4: Viewing the metrics collected in Google Cloud operations

Following the steps detailed above, you should see the following metrics exported to Metrics Explorer.

1redis.uptimeNumber of seconds since Redis server
2redis.cpu.timeSystem CPU consumed by the Redis server in seconds since server
3redis.clients.connectedNumber of client connections (excluding connections from replicas)
4redis.clients.max_input_bufferBiggest input buffer among current client
5redis.clients.max_output_bufferLongest output list among current client
6redis.clients.blockedNumber of clients pending on a blocking
7redis.keys.expiredTotal number of key expiration
8redis.keys.evictedNumber of evicted keys due to maxmemory
9redis.connections.receivedTotal number of connections accepted by the
10redis.connections.rejected:Number of connections rejected because of maxclients
11redis.memory.usedTotal number of bytes allocated by Redis using its
12redis.memory.peakPeak memory consumed by Redis (in bytes)
13redis.memory.rssNumber of bytes that Redis allocated as seen by the operating
14redis.memory.luaNumber of bytes used by the Lua
15redis.memory.fragmentation_ratioRatio between used_memory_rss and
16redis.rdb.changes_since_last_saveNumber of changes since the last
17redis.commandsNumber of commands processed per
18redis.commands.processedTotal number of commands processed by the total number of bytes read from the total number of bytes written to the
21redis.keyspace.hitsNumber of successful lookup of keys in the main
22redis.keyspace.missesNumber of failed lookup of keys in the main
23redis.latest_forkDuration of the latest fork operation in
24redis.slaves.connectedNumber of connected
25redis.replication.backlog_first_byte_offsetThe master offset of the replication backlog
26redis.replication.offsetThe server's current replication
27redis.db.keysNumber of keyspace
28redis.db.expiresNumber of keyspace keys with an redis.db.expires
29redis.db.avg_ttlAverage keyspace keys

To view the metrics, follow the steps outlined below:

  1. In the Google Cloud Console, head to Metrics Explorer.
  2. Select the resource as a generic node.
  3. Follow the namespace equivalent in the table above and filter the metric to view the chart.

Related Content: Exploring & Remediating Consumption Costs with Google Billing and BindPlane OP

observIQ’s distribution is a game-changer for companies looking to implement the OpenTelemetry standards. The single-line installer, seamlessly integrated receivers, exporter, and processor pool make working with this collector simple. Follow this space to keep up with all our future posts and simplified configurations for various sources. For questions, requests, and suggestions, contact our support team at

Deepa Ramachandra
Deepa Ramachandra

Related posts

All posts

Get our latest content
in your inbox every week

By subscribing to our Newsletter, you agreed to our Privacy Notice

Community Engagement

Join the Community

Become a part of our thriving community, where you can connect with like-minded individuals, collaborate on projects, and grow together.

Ready to Get Started

Deploy in under 20 minutes with our one line installation script and start configuring your pipelines.

Try it now