Redis

Agent Check

Overview

Whether you use Redis as a database, cache, or message queue, this integration helps you track problems with your Redis servers and the parts of your infrastructure that they serve. The Datadog Agent’s Redis check collects a wealth of metrics related to performance, memory usage, blocked clients, slave connections, disk persistence, expired and evicted keys, and many more.

Setup

Find below instructions to install and configure the check when running the Agent on a host. See the Autodiscovery Integration Templates documentation to learn how to apply those instructions to a containerized environment.

Installation

The Redis check is included in the Datadog Agent package, so you don’t need to install anything else on your Redis servers.

Configuration

Edit the redisdb.d/conf.yaml file, in the conf.d/ folder at the root of your Agent’s configuration directory to start collecting your Redis metrics and logs. See the sample redis.d/conf.yaml for all available configuration options.

Metric Collection

Add this configuration block to your redisdb.d/conf.yaml file to start gathering your Redis metrics:

init_config:

instances:
  - host: localhost
    port: 6379 # or wherever your Redis listens
  # unix_socket_path: /var/run/redis/redis.sock # if your Redis uses a socket instead of TCP
  # password: myredispassword                   # if your Redis requires auth

Configuration Options:

• unix_socket_path - (Optional) - Can be used instead of host and port.
• db, password, and socket_timeout - (Optional) - Additional connection options.
• warn_on_missing_keys - (Optional) - Display a warning in the info page if the keys we’re tracking are missing.
• slowlog-max-len - (Optional) - Maximum number of entries to fetch from the slow query log. By default, the check will read this value from the Redis config. If it’s above 128, it will default to 128 due to potential increased latency to retrieve more than 128 slowlog entries every 15 seconds. If you need to get more entries from the slow query logs set the value here. Warning: It may impact the performance of your Redis instance
• command_stats - (Optional) - Collect INFO COMMANDSTATS output as metrics.

See the sample redisdb.d/conf.yaml for all available configuration options.

Restart the Agent to begin sending Redis metrics to Datadog.

Log Collection

Available for Agent >6.0

• Collecting logs is disabled by default in the Datadog Agent, you need to enable it in datadog.yaml:

  logs_enabled: true

• Add this configuration block to your redisdb.d/conf.yaml file to start collecting your Redis Logs:

    logs:
        - type: file
          path: /var/log/redis_6379.log
          source: redis
          sourcecategory: database
          service: myapplication

Change the path and service parameter values and configure them for your environment. See the sample redisdb.yaml for all available configuration options.

• Restart the Agent to begin sending Redis logs to Datadog.

Validation

Run the Agent’s status subcommand and look for redisdb under the Checks section.

Data Collected

Metrics

Events

The Redis check does not include any events.

Service Checks

redis.can_connect:

Returns CRITICAL if the Agent cannot connect to Redis to collect metrics, otherwise OK.

redis.replication.master_link_status

Returns CRITICAL if this Redis instance is unable to connect to its master instance. Returns OK otherwise.

Troubleshooting

• Redis Integration Error: “unknown command ‘CONFIG’”

Agent cannot connect

    redisdb
    -------
      - instance #0 [ERROR]: 'Error 111 connecting to localhost:6379. Connection refused.'
      - Collected 0 metrics, 0 events & 1 service chec

Check that the connection info in redisdb.yaml is correct.

Agent cannot authenticate

    redisdb
    -------
      - instance #0 [ERROR]: 'NOAUTH Authentication required.'
      - Collected 0 metrics, 0 events & 1 service check

Configure a password in redisdb.yaml.

Development

See the main documentation for more details about how to test and develop Agent based integrations.

Testing Guidelines

This check has 2 test matrix, one detailing the test type:

• unit tests (no need for a Redis instance running)
• integration tests (a Redis instance must run locally)

another matrix defines the Redis versions to be used with integration tests:

• redis 3.2
• redis 4.0

The first matrix is handled by pytest using mark: tests that need a running redis instance must be decorated like this:

@pytest.mark.integration
def test_something_requiring_redis_running():
  pass

Running the tests with pytest -m"integration" will run only integration tests while pytest -m"not integration" will run whatever was not marked as an integration test.

The second matrix is defined with tox like this:

envlist = unit, redis{32,40}, flake8

...

[testenv:redis32]
setenv = REDIS_VERSION=3.2
...

[testenv:redis40]
setenv = REDIS_VERSION=4.0
...

Integration tests

Redis instances are orchestrated with docker-compose which is now a dependency to run the integration tests. It’s pytest responsible to start/stop/dispose an instance using the fixture concept.

This is how a fixture orchestrating Redis instances looks like:

@pytest.fixture(scope="session")
def redis_auth():
    # omitted docker-compose invokation setup here ...
    subprocess.check_call(args + ["up", "-d"], env=env)
    yield
    subprocess.check_call(args + ["down"], env=env)

the basic concept is that docker-compose up is run right after the fixture is made available to the test function (it blocks on yield). When the test has done, yield unblocks and docker-compose down is called. Notice the scope=session argument passed to the fixture decorator, it allows the yield to block only once for all the tests , unblocking only after the last test: this is useful to avoid having docker-compose up and down called at every test. One caveat with this approach is that if you have data in Redis, some test might operate on a dirty database - this is not an issue in this case but something to keep in mind when using scope=session.

Running the tests locally

Note: you need docker and docker-compose to be installed on your system in order to run the tests locally.

During development, tests can be locally run with tox, same as in the CI. In the case of Redis, there might be no need to test the whole matrix all the times, so for example if you want to run only the unit/mocked tests:

tox -e unit

if you want to run integration tests but against one Redis version only:

tox -e redis40

tox is great because it creates a virtual Python environment for each tox env but if you don’t need this level of isolation you can speed up the development iterations using pytest directly (which is what tox does under the hood):

REDIS_VERSION=4.0 pytest

or if you don’t want to run integration tests:

pytest -m"not integration"

Further Reading

Read our series of blog posts about how to monitor your Redis servers with Datadog. We detail the key performance metrics, how to collect them, and how to use Datadog to monitor Redis.

Mistake in the docs? Feel free to contribute!