Мониторинг Redis с помощью Proto Observability

На этой странице:

• Сбор метрик Redis
  • Конфигурация Redis
  • Конфигурация ProtoOBP агента
    • Если агент запускается в виде службы на хосте
    • Если агент запускается в виде Docker контейнера
  • Проверка
  • Собираемые метрики
    • Лейблы
      • Общие (на всех метриках)
      • Дополнительные лейблы
    • Соединения и сеть
    • Память
    • Keyspace
    • Персистентность (RDB / AOF)
    • Репликация
    • CPU и производительность
    • Команды (command_stats)
    • Slowlog
    • Pub/Sub
    • Длина ключей (keys)
    • Кластер
  • Ключевые метрики для дашбордов и алертов
• Сбор логов Redis
  • Конфигурация ProtoOBP агента
    • Если агент запускается в виде службы на хосте
    • Если агент запускается в виде Docker контейнера
  • Проверка

Сбор метрик Redis

Интеграция redisdb подключается к Redis по его собственному протоколу (RESP) и снимает метрики из вывода INFO / CONFIG GET, SLOWLOG GET, опционально COMMAND INFO + INFO COMMANDSTATS (флаг command_stats) и per-key TYPE / *LEN (опция keys). Поддерживаются standalone, реплики, Sentinel и кластерные ноды; JMX не используется — образ агента с суффиксом -jmx не нужен.

Конфигурация Redis

Для базового мониторинга достаточно сетевого доступа к Redis с хоста агента — никаких изменений конфигурации Redis не требуется. Если на Redis включена аутентификация, заведите для агента отдельную учётную запись.

• Аутентификация Redis:
• ACL-пользователь (Redis 6+)
• requirepass (любая версия)
• Без аутентификации

redis-cli ACL SETUSER protoobp on '>protoobp' '~*' '&*' \
  +info +config|get +slowlog +client +command|docs +command|info +command|count \
  +type +strlen +llen +scard +hlen +zcard +xlen +pfcount

user protoobp on >protoobp ~* &* +info +config|get +slowlog +client +command|docs +command|info +command|count +type +strlen +llen +scard +hlen +zcard +xlen +pfcount

requirepass <пароль>

Конфигурация ProtoOBP агента

Если агент запускается в виде службы на хосте

1. В файле конфигурации ProtoOBP агента (/etc/protoobp-agent/conf.d/redisdb.d/conf.yaml) укажите адрес, порт Redis и — если включена аутентификация — учётную запись, под которой агент подключится к базе:

   init_config:
   
   instances:
     - host: localhost
       port: 6379
       # username: protoobp        # только Redis 6+, при ACL-аутентификации
       # password: protoobp        # пароль (ACL-пользователя или requirepass)
       # unix_socket_path: /var/run/redis/redis.sock   # альтернатива host/port
       # db: 0                      # индекс базы (по умолчанию 0)
       # ssl: false                 # TLS-подключение
       # ssl_certfile: /path/client.pem
       # ssl_keyfile: /path/client.key
       # ssl_ca_certs: /path/ca.pem
       command_stats: true          # собирать redis_command_* (INFO COMMANDSTATS)
       # collect_client_metrics: false   # redis_net_connections per client name (CLIENT LIST)
       # slowlog-max-len: 128       # сколько записей slowlog читать за раз
       warn_on_missing_keys: false
       keys:                        # длина перечисленных ключей (redis_key_length)
         - 'app:list:*'
         - 'app:hash:session'
       # tags:
       #   - 'redis_instance:cache-1'
   

2. Перезапустите агента: systemctl restart protoobp-agent.

Если агент запускается в виде Docker контейнера

Добавьте autodiscovery-лейблы к контейнеру Redis. В docker-compose.yaml:

services:
  redis:
    image: redis:7-alpine
    labels:
      com.protoobp.ad.check_names: '["redisdb"]'
      com.protoobp.ad.init_configs: '[{}]'
      com.protoobp.ad.instances: '[{"host": "%%host%%", "port": 6379, "username": "protoobp", "password": "protoobp", "command_stats": true, "keys": ["app:list:events", "app:hash:session"], "warn_on_missing_keys": false}]'

Если Redis без аутентификации — уберите username / password:

com.protoobp.ad.instances: '[{"host": "%%host%%", "port": 6379, "command_stats": true}]'

То же набором LABEL в Dockerfile:

LABEL "com.protoobp.ad.check_names"='["redisdb"]'
LABEL "com.protoobp.ad.init_configs"='[{}]'
LABEL "com.protoobp.ad.instances"='[{"host": "%%host%%", "port": 6379, "username": "protoobp", "password": "protoobp", "command_stats": true}]'

Проверка

Убедитесь, что проверка запустилась и собирает метрики:

docker exec protoobp-agent agent status | grep -A 10 "redisdb ("

Ожидаемый вывод — [OK] у Instance ID и ненулевые Metric Samples:

    redisdb (4.5.2)
    ---------------
      Instance ID: redisdb:f727141fd4988515 [OK]
      Configuration Source: container:docker://707347e5e2...
      Total Runs: 26
      Metric Samples: Last Run: 135, Total: 3,372
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 1, Total: 26
      Average Execution Time : 16ms

Точечно проверить собираемые метрики (имена и значения) можно через agent check:

docker exec protoobp-agent agent check redisdb \
  | grep -oE '"metric": "redis\.[a-z._0-9]+"' | sort -u

На стороне агента (в выводе agent check) метрики печатаются в исходном dotted-виде (redis.net.clients, …); в хранилище ProtoOBP backend они попадают с точками, заменёнными на подчёркивания (redis_net_clients, …) — именно так на них ссылаются дашборды и алерты. Ниже все имена приведены в backend-форме.

На одном standalone Redis 7.x под нагрузкой (command_stats: true, keys: [...]) проверка выдаёт около 135 сэмплов за прогон, порядка 48 уникальных имён метрик, в том числе:

redis_net_clients              redis_mem_used                redis_keys
redis_net_maxclients           redis_mem_rss                 redis_expires
redis_net_rejected             redis_mem_peak                redis_persist
redis_net_slaves               redis_mem_overhead            redis_keys_expired
redis_net_instantaneous_ops_per_sec  redis_mem_fragmentation_ratio  redis_keys_evicted
redis_clients_blocked          redis_mem_maxmemory           redis_pubsub_channels
redis_command_calls            redis_rdb_bgsave              redis_pubsub_patterns
redis_command_usec_per_call    redis_rdb_changes_since_last  redis_perf_latest_fork_usec
redis_slowlog_micros_count     redis_rdb_last_bgsave_time    redis_replication_master_repl_offset
redis_slowlog_micros_avg       redis_aof_rewrite             redis_key_length
redis_slowlog_micros_max       redis_aof_last_rewrite_time   redis_info_latency_ms
redis_slowlog_micros_median    redis_slowlog_micros_95percentile  redis_server_io_threads_active

redis_command_* собираются с лейблом command (по записи на каждую команду из INFO COMMANDSTATS), redis_key_length — с лейблами key / key_type по ключам из опции keys. На метриках присутствуют лейблы redis_host, redis_port, redis_db, redis_role, service, env, docker_image, image_name, image_tag, short_image (для контейнера).

Собираемые метрики

Все метрики — типа gauge (мгновенное значение на момент сбора), за исключением redis_slowlog_micros_count (типа rate — частота записей в slowlog в секунду). Часть метрик, имена которых в INFO выглядят как кумулятивные счётчики (keyspace_hits, keyspace_misses, total_commands_processed и т.п.), интеграция отдаёт уже как rate в секунду.

Ниже — наиболее востребованные метрики (имена приведены в backend-форме, с подчёркиваниями). Полный набор зависит от версии Redis и включённых опций; метрики, специфичные для отдельных версий, помечены [vN+]. Уровень детализации (COMMANDSTATS, per-key длины) управляется опциями command_stats и keys. Часть «потенциальных» метрик из INFO (redis_stats_keyspace_hits / redis_stats_keyspace_misses, redis_cpu_*, redis_net_commands) на практике интеграцией не эмитится — они помечены ниже как «может не отправляться».

Лейблы

Общие (на всех метриках)

Добавляются агентом и ProtoOBP backend’ом:

Дополнительные лейблы

Соединения и сеть

Память

Keyspace

Персистентность (RDB / AOF)

Репликация

CPU и производительность

Семейство redis_cpu_* присутствует в INFO, но на практике интеграцией обычно не эмитится — может не отправляться.

Команды (command_stats)

Появляются только при command_stats: true. Несут лейбл command (command:set, command:get, command:incr и т.п.) — по записи на каждую команду из INFO COMMANDSTATS.

Slowlog

Считаются по записям, прочитанным агентом из SLOWLOG GET (до slowlog-max-len записей). Заполнятся, только если в Redis есть записи медленнее slowlog-log-slower-than.

Pub/Sub

Длина ключей (keys)

Появляется только при заданной опции keys. Несёт лейблы key и key_type.

Кластер

Появляются на нодах с включённым cluster mode (INFO/CLUSTER INFO).

Ключевые метрики для дашбордов и алертов

Доступность инстанса

• Отсутствие свежих серий по инстансу (redis_host / redis_port) — алерт: Redis недоступен или агент не может подключиться.
• redis_ping_latency_ms / redis_info_latency_ms резко выросли — Redis под нагрузкой или сетевые проблемы.

Память

• redis_mem_used приближается к redis_mem_maxmemory — алерт по доле (mem_used / mem_maxmemory > 80–90 %): дальше начнётся eviction или OOM command not allowed.
• redis_mem_fragmentation_ratio стабильно > 1.5 (фрагментация) или < 1 (swap — особенно опасно).
• redis_keys_evicted > 0 при maxmemory-policy != noeviction — данные вытесняются; если политика noeviction — записи будут отвергаться.

Эффективность кэша

• Hit ratio: redis_stats_keyspace_hits / (keyspace_hits + keyspace_misses) (если эти метрики эмитятся) — падение → кэш «не греет».
• redis_keys_expired — фоновый поток истечения TTL; всплеск может вызвать кратковременные просадки.

Нагрузка / поток команд

• redis_net_instantaneous_ops_per_sec — основной SLI пропускной способности.
• redis_command_calls / redis_command_usec_per_call per command (при command_stats) — какая команда «съедает» CPU.
• redis_net_rejected > 0 или redis_net_clients уперлось в redis_net_maxclients — лимит подключений исчерпан.
• redis_clients_blocked стабильно высокий — много клиентов висит на блокирующих вызовах.

Латентность

• redis_slowlog_micros_95percentile / redis_slowlog_micros_max — «тяжёлые» команды (большие KEYS, SORT, Lua-скрипты).
• redis_perf_latest_fork_usec высокий — fork() под BGSAVE/AOF-rewrite блокирует процесс (типично на больших датасетах / без THP-tuning’а).

Персистентность

• redis_rdb_last_save_time давно не обновлялся при ненулевом redis_rdb_changes_since_last — снапшоты не проходят (нет места, права).
• redis_aof_delayed_fsync растёт — диск не успевает за fsync AOF.
• redis_rdb_bgsave == 1 / redis_aof_rewrite == 1 подолгу — фоновая операция зависла.

Репликация (если есть реплики)

• redis_net_slaves упало ниже ожидаемого — реплика отвалилась.
• redis_replication_master_link_down_since_seconds > 0 или redis_replication_last_io_seconds_ago растёт — канал к мастеру оборван.
• redis_replication_delay / разница master_repl_offset − slave_repl_offset растёт — реплика отстаёт.
• Всплеск redis_replication_sync_full — частые full-resync’ы (мал backlog или нестабильная сеть).

Сбор логов Redis

Логи Redis собираются ProtoOBP агентом и отправляются в бэкенд ProtoOBP. Здесь — только специфичные для Redis настройки. Включение логов на стороне агента (logs_enabled, logs_pobp_url) описано в Получение данных логов.

По умолчанию redis-server пишет лог в stdout (когда daemonize no); если в redis.conf задана директива logfile, лог дублируется в указанный файл (в дистрибутивных пакетах обычно /var/log/redis/redis-server.log).

Конфигурация ProtoOBP агента

Если агент запускается в виде службы на хосте

Создайте /etc/protoobp-agent/conf.d/redisdb.d/conf.yaml (либо дополните уже существующий — тот же файл, в котором лежит instances: для метрик) блоком logs::

logs:
  - type: file
    path: /var/log/redis/redis-server.log
    source: redis
    service: redis

Путь к файлу — значение директивы logfile из redis.conf (в дистрибутивных пакетах обычно /var/log/redis/redis-server.log, в Docker-образе по умолчанию лог идёт только в stdout).

Перезапустите агента: systemctl restart protoobp-agent.

Если агент запускается в виде Docker контейнера

Шаг 1 — включите сбор логов в самом агенте через переменные окружения и смонтируйте директорию JSON-логов docker-демона:

services:
  protoobp-agent:
    environment:
      POBP_LOGS_ENABLED: "true"
      POBP_LOGS_CONFIG_USE_HTTP: "true"
      POBP_LOGS_CONFIG_LOGS_POBP_URL: <protoobp-backend>:<port>
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      # Прямое чтение JSON-лог файлов docker-демона быстрее,
      # чем тянуть их через Docker socket API.
      - /var/lib/docker/containers:/var/lib/docker/containers:ro

Шаг 2 — добавьте лейбл com.protoobp.ad.logs к контейнеру Redis. Агент подхватит stdout/stderr контейнера и пометит записи указанными source и service:

services:
  redis:
    labels:
      com.protoobp.ad.logs: '[{"source": "redis", "service": "redis"}]'

com.protoobp.ad.logs: '[{"source": "redis", "service": "redis", "log_processing_rules": [{"type": "multi_line", "name": "log_start_with_pid_date", "pattern": "\\d+:[A-Z] \\d{1,2} \\w{3} \\d{4}"}]}]'

Проверка

В выводе agent status должен быть раздел Logs Agent с ненулевым LogsProcessed / LogsSent и источником Source: redis с ненулевым BytesRead:

docker exec protoobp-agent agent status | awk '/Logs Agent/,/^====[^=]/'

Logs Agent
==========
    Reliable: Sending compressed logs in HTTPS to <backend> on port 443
    BytesSent: 152858
    EncodedBytesSent: 15685
    LogsProcessed: 260
    LogsSent: 260

  docker
  ------
    - Type: file
      Path: /var/lib/docker/containers/707347e5e2.../707347e5e2...-json.log
      Service: redis
      Source: redis
      Status: OK
      BytesRead: 2220
      Average Latency (ms): 0

У источника типа «JSON-файл docker-контейнера» поле Status может отображаться как Pending даже при активном чтении — ориентируйтесь на BytesRead / LogsProcessed. Принятые записи доступны в Logs Explorer ProtoOBP UI.