Nouvelles annonces sur les technologies sans serveur et réseau ainsi que sur le RUM (Real-User Monitoring) dévoilées à la conférence Dash ! Nouvelles annonces dévoilées à la conférence Dash !

Redis

Agent Check Check de l'Agent

Supported OS: Linux Mac OS Windows

Présentation

Que vous utilisiez Redis en tant que base de données, cache ou file d’attente de messages, cette intégration vous permet de suivre les problèmes avec vos serveurs Redis et les composants de votre infrastructure qu’ils desservent. Le check Redis de l’Agent Datadog recueille de nombreuses métriques associées aux performances, à l’utilisation de la mémoire, aux clients bloqués, aux connexions esclaves, à la persistance du disque, aux clés expirées et expulsées, et bien plus encore.

Implémentation

Vous trouverez ci-dessous les instructions pour installer et configurer le check lorsque l’Agent est exécuté sur un host. Consultez la documentation relative aux modèles d’intégration Autodiscovery pour découvrir comment appliquer ces instructions à un environnement conteneurisé.

Installation

Le check Redis est inclus dans le paquet de l’Agent Datadog : vous n’avez donc rien d’autre à installer sur vos serveurs Redis.

Configuration

Modifiez le fichier redisdb.d/conf.yaml dans le dossier conf.d/ à la racine du répertoire de configuration de votre Agent pour commencer à recueillir vos métriques et vos logs Redis. Consultez le fichier d’exemple redis.d/conf.yaml pour découvrir toutes les options de configuration disponibles.

Collecte de métriques

Ajoutez ce bloc de configuration à votre fichier redisdb.d/conf.yaml pour commencer à recueillir vos métriques Redis :

init_config:

instances:
  - host: localhost
    port: 6379 # ou tout autre port utilisé par votre serveur Redis pour l'écoute
  # unix_socket_path: /var/run/redis/redis.sock # si votre serveur Redis utilise un socket au lieu de TCP
  # password: monmotdepasseredis                   # si votre serveur Redis exige une authentification

Options de configuration :

  • unix_socket_path (facultatif) : peut être utilisé à la place de host et port.
  • db, password et socket_timeout : (facultatifs) : options de connexion supplémentaires.
  • warn_on_missing_keys (facultatif) : affiche un avertissement sur la page d’informations si les clés qui font l’objet du suivi sont manquantes.
  • slowlog-max-len (facultatif) : nombre maximal d’entrées à récupérer à partir du log de requêtes lentes. Par défaut, le check lit cette valeur à partir du fichier de configuration de Redis. Si elle est supérieure à 128, la valeur par défaut de 128 sera utilisée étant donné que la récupération de plus de 128 entrées du log de requêtes lentes toutes les 15 secondes entraîne un risque de latence accru. Si vous avez besoin de récupérer plus d’entrées des logs de requêtes lentes, définissez la valeur ici. Avertissement : cela peut avoir une incidence sur les performances de votre instance Redis
  • command_stats (facultatif) : recueille la sortie INFO COMMANDSTATS en tant que métriques.

Consultez le fichier d’exemple redisdb.d/conf.yaml pour découvrir toutes les options de configuration disponibles.

Redémarrez l’Agent pour commencer à envoyer des métriques Redis à Datadog.

Collecte de logs

Disponible à partir des versions > 6.0 de l’Agent

  1. La collecte de logs est désactivée par défaut dans l’Agent Datadog. Vous devez l’activer dans datadog.yaml :

      logs_enabled: true
  2. Ajoutez ce bloc de configuration à votre fichier redisdb.d/conf.yaml pour commencer à recueillir vos logs Redis :

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

Modifiez les valeurs des paramètres path et service et configurez-les pour votre environnement. Consultez le fichier d’exemple redisdb.d/conf.yaml pour découvrir toutes les options de configuration disponibles.

  1. Redémarrez l’Agent.

Validation

Lancez la sous-commande status de l’Agent et cherchez redisdb dans la section Checks.

Données collectées

Métriques

redis.aof.buffer_length
(gauge)
Size of the AOF buffer.
Shown as byte
redis.aof.last_rewrite_time
(gauge)
Duration of the last AOF rewrite.
Shown as second
redis.aof.rewrite
(gauge)
Flag indicating a AOF rewrite operation is on-going.
redis.aof.size
(gauge)
AOF current file size (aof_current_size).
Shown as byte
redis.clients.biggest_input_buf
(gauge)
The biggest input buffer among current client connections.
redis.clients.blocked
(gauge)
The number of connections waiting on a blocking call.
Shown as connection
redis.clients.longest_output_list
(gauge)
The longest output list among current client connections.
redis.cpu.sys
(gauge)
System CPU consumed by the Redis server.
Shown as second
redis.cpu.sys_children
(gauge)
System CPU consumed by the background processes.
Shown as second
redis.cpu.user
(gauge)
User CPU consumed by the Redis server.
Shown as second
redis.cpu.user_children
(gauge)
User CPU consumed by the background processes.
Shown as second
redis.expires
(gauge)
The number of keys with an expiration.
Shown as key
redis.expires.percent
(gauge)
Percentage of total keys with an expiration.
Shown as percent
redis.info.latency_ms
(gauge)
The latency of the redis INFO command.
Shown as millisecond
redis.key.length
(gauge)
The number of elements in a given key, tagged by key, e.g. 'key:mykeyname'. Enable in Agent's redisdb.yaml with the keys option.
redis.keys
(gauge)
The total number of keys.
Shown as key
redis.keys.evicted
(gauge)
The total number of keys evicted due to the maxmemory limit.
Shown as key
redis.keys.expired
(gauge)
The total number of keys expired from the db.
Shown as key
redis.mem.fragmentation_ratio
(gauge)
Ratio between used_memory_rss and used_memory.
Shown as fraction
redis.mem.lua
(gauge)
Amount of memory used by the Lua engine.
Shown as byte
redis.mem.maxmemory
(gauge)
Maximum amount of memory allocated to the Redisdb system.
Shown as byte
redis.mem.peak
(gauge)
The peak amount of memory used by Redis.
Shown as byte
redis.mem.rss
(gauge)
Amount of memory that Redis allocated as seen by the os.
Shown as byte
redis.mem.used
(gauge)
Amount of memory allocated by Redis.
Shown as byte
redis.mem.startup
(gauge)
Amount of memory consumed by Redis at startup.
Shown as byte
redis.mem.overhead
(gauge)
Sum of all overheads allocated by Redis for managing its internal datastructures.
Shown as byte
redis.net.clients
(gauge)
The number of connected clients (excluding slaves).
Shown as connection
redis.net.commands
(gauge)
The number of commands processed by the server.
Shown as command
redis.net.commands.instantaneous_ops_per_sec
(gauge)
The number of commands processed by the server per second.
Shown as command
redis.net.rejected
(gauge)
The number of rejected connections.
Shown as connection
redis.net.slaves
(gauge)
The number of connected slaves.
Shown as connection
redis.perf.latest_fork_usec
(gauge)
The duration of the latest fork.
Shown as microsecond
redis.persist
(gauge)
The number of keys persisted (redis.keys - redis.expires).
Shown as key
redis.persist.percent
(gauge)
Percentage of total keys that are persisted.
Shown as percent
redis.pubsub.channels
(gauge)
The number of active pubsub channels.
redis.pubsub.patterns
(gauge)
The number of active pubsub patterns.
redis.rdb.bgsave
(gauge)
One if a bgsave is in progress and zero otherwise.
redis.rdb.changes_since_last
(gauge)
The number of changes since the last background save.
redis.rdb.last_bgsave_time
(gauge)
Duration of the last bg_save operation.
Shown as second
redis.replication.backlog_histlen
(gauge)
The amount of data in the backlog sync buffer.
Shown as byte
redis.replication.delay
(gauge)
The replication delay in offsets.
Shown as offset
redis.replication.last_io_seconds_ago
(gauge)
Amount of time since the last interaction with master.
Shown as second
redis.replication.master_link_down_since_seconds
(gauge)
Amount of time that the master link has been down.
Shown as second
redis.replication.master_repl_offset
(gauge)
The replication offset reported by the master.
Shown as offset
redis.replication.slave_repl_offset
(gauge)
The replication offset reported by the slave.
Shown as offset
redis.replication.sync
(gauge)
One if a sync is in progress and zero otherwise.
redis.replication.sync_left_bytes
(gauge)
Amount of data left before syncing is complete.
Shown as byte
redis.slowlog.micros.95percentile
(gauge)
The 95th percentile of the duration of queries reported in the slow log.
Shown as microsecond
redis.slowlog.micros.avg
(gauge)
The average duration of queries reported in the slow log.
Shown as microsecond
redis.slowlog.micros.count
(rate)
The rate of queries reported in the slow log.
Shown as query
redis.slowlog.micros.max
(gauge)
The maximum duration of queries reported in the slow log.
Shown as microsecond
redis.slowlog.micros.median
(gauge)
The median duration of queries reported in the slow log.
Shown as microsecond
redis.stats.keyspace_hits
(gauge)
The total number of successful lookups in the main db.
Shown as key
redis.stats.keyspace_misses
(gauge)
The total number of missed lookups in the main db.
Shown as key
redis.command.calls
(gauge)
The number of times a redis command has been called, tagged by 'command', e.g. 'command:append'. Enable in Agent's redisdb.yaml with the command_stats option.
redis.command.usec_per_call
(gauge)
The CPU time consumed per redis command call, tagged by 'command', e.g. 'command:append'. Enable in Agent's redisdb.yaml with the command_stats option.

Événements

Le check Redis n’inclut aucun événement.

Checks de service

redis.can_connect :
Renvoie CRITICAL si l’Agent n’est pas capable de se connecter à Redis pour recueillir des métriques. Si ce n’est pas le cas, renvoie OK.

redis.replication.master_link_status :
Renvoie CRITICAL si cette instance Redis n’est pas capable de se connecter à son instance principale. Si ce n’est pas le cas, renvoie OK.

Dépannage

Connexion impossible de l’Agent

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

Vérifiez que les informations de connexion dans redisdb.yaml sont correctes.

Authentification impossible de l’Agent

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

Configurez un password dans redisdb.yaml.

Développement

Consultez la documentation principale sur les outils de développement pour découvrir comment tester et développer des intégrations reposant sur l’Agent.

Procédures de test

Ce check comprend 2 matrices de test, dont une qui fournit des détails sur le type de test :

  • tests d’unité (aucune instance Redis en cours d’exécution nécessaire)
  • tests d’intégration (une instance Redis doit s’exécuter en local)

L’autre matrice définit les versions de Redis à utiliser avec les tests d’intégration :

  • redis 3.2
  • redis 4.0

La première matrice est gérée par pytest avec l’option mark. Les tests qui nécessitent une instance Redis en cours d’exécution doivent être décorés comme suit :

@pytest.mark.integration
def tester_élément_nécessitant_exécution_redis():
  pass

L’exécution des tests avec pytest -m"integration" entraînera l’exécution des tests d’intégration uniquement, tandis que pytest -m"not integration" entraînera l’exécution de tout élément non marqué en tant que test d’intégration.

La deuxième matrice est définie avec tox comme suit :

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

...

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

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

Tests d’intégration

Les instances Redis sont orchestrées avec docker-compose, qui constitue maintenant une dépendance pour l’exécution des tests d’intégration. pytest est utilisé pour démarrer/arrêter/supprimer une instance au moyen du concept fixture.

Voici à quoi ressemble une orchestration d’instances Redis avec fixture :

@pytest.fixture(scope="session")
def redis_auth():
    # configuration d'appel de docker-compose omise ici…
    subprocess.check_call(args + ["up", "-d"], env=env)
    yield
    subprocess.check_call(args + ["down"], env=env)

Le concept de base est le suivant : docker-compose up est exécuté directement après la mise à disposition de fixture dans la fonction de test (celle-ci se bloque au niveau de la commande yield). Une fois que le test est terminé, la commande yield est bloquée et la commande docker-compose down est appelée. Notez l’argument scope=session transmis au décorateur fixture : il permet à la commande yield de n’être bloquée qu’une seule fois pour tous les tests et d’être débloquée seulement après le dernier test, ce qui est utile afin d’éviter que les commandes docker-compose up et down soient appelées à chaque test. Mise en garde concernant cette approche : si vous avez des données dans Redis, certains tests peuvent s’exécuter sur une base de données corrompue. Cela ne pose pas de problème dans ce cas, mais il est important de ne pas l’oublier lorsque vous utilisez scope=session.

Exécution des tests en local

Remarque : docker et docker-compose doivent être installés sur votre système pour exécuter des tests en local.

Lors du développement, les tests peuvent être exécutés en local avec tox, de la même façon que dans le CI. Dans le cas de Redis, il n’est pas forcément nécessaire de tester l’ensemble de la matrice tout le temps. Ainsi, si vous souhaitez par exemple exécuter uniquement les tests d’unité ou de simulation :

tox -e unit

Si vous souhaitez exécuter les tests d’intégration, mais en vous basant sur une seule version de Redis :

tox -e redis40

L’outil tox est particulièrement utile car il créé un environnement Python virtuel pour chaque environnement tox. Si toutefois vous n’avez pas besoin de ce niveau d’isolation, vous pouvez accélérer les itérations de développement en utilisant pytest directement (comme le fait tox en réalité) :

REDIS_VERSION=4.0 pytest

Si vous ne souhaitez pas exécuter des tests d’intégration :

pytest -m"not integration"

Pour aller plus loin

Documentation, liens et articles supplémentaires utiles :


Mistake in the docs? Feel free to contribute!