Программа курса

Модуль 06 / Урок 24 из 27

Мониторинг: метрики и алерты

Теория и практика

INFO — главный источник телеметрии Redis. Урок о том, какие секции смотреть ежедневно, какие метрики завести в дашборд и на что настроить алерты, чтобы узнавать о проблеме раньше пользователей.

Секции INFO

INFO memory        # used_memory, used_memory_rss, maxmemory, mem_fragmentation_ratio
INFO stats         # keyspace_hits/misses, evicted_keys, rejected_connections, ops_per_sec
INFO clients       # connected_clients, blocked_clients
INFO persistence   # rdb_*, aof_*, latest_fork_usec
INFO replication   # роль, master_link_status, offset-ы → lag
INFO keyspace      # db0: ключей, с TTL, средний TTL

Как читать память

  • used_memory — память данных (счётчик аллокатора);
  • used_memory_rss — память процесса по мнению ОС;
  • mem_fragmentation_ratio = rss/used: 1.0–1.5 норма; > 1.5 — фрагментация (или COW); < 1 — своп, тревога максимального уровня;
  • used_memory_peak — исторический максимум: планирование ёмкости.

Минимальный набор алертов

МетрикаПорогЧто значит
used_memory / maxmemory> 85–90%скоро eviction или OOM-ошибки
evicted_keys (дельта)> 0 стабильновытесняются живые ключи
mem_fragmentation_ratio> 1.5 или < 1фрагментация / своп
client p99 latencyрезкий ростslowlog/fork/сеть — урок 6.2
master_link_status≠ upреплика отвалилась
replication lag> 2–5среплика не успевает: риск при failover
rejected_connections> 0maxclients или лимиты ОС
rdb_last_bgsave_status / aof_last_write_status≠ okперсистентность сломана (диск!)
blocked_clientsрастётзалипли BLPOP/XREAD — проверьте логику

Инструментарий

  • redis_exporter → Prometheus → Grafana: стандартный путь; готовые дашборды существуют — возьмите и адаптируйте;
  • CLIENT LIST — кто подключён, какие команды, с каких адресов (поиск «виновника» соединений);
  • MONITOR — стрим всех команд: только для отладки на деве/сушке (дорог и сам создаёт нагрузку);
  • redis-cli --stat — «топливо» процессом: QPS/память/клиенты в реальном времени;
  • Клиентские метрики: важнее серверных — латентность по операциям из приложения показывает полный путь (сеть + очередь + Redis).

Дашборд «один экран»

  1. Память: used/max, фрагментация, пики;
  2. Трафик: ops/s, hit rate, evictions;
  3. Латентность: клиентский p99 по ключевым командам;
  4. Репликация: lag по репликам, статус линка;
  5. Персистентность: статус последнего BGSAVE/AOF, длительность fork;
  6. Соединения: connected, blocked, rejected.

Практика

  1. Поднимите redis_exporter + Prometheus + Grafana (docker-compose), соберите дашборд из шести панелей выше.
  2. Симулируйте инциденты и проверьте алерты: залейте память до eviction; разорвите линк реплики; заполните диск для bgsave error.
  3. Разберите INFO clients своего приложения: сколько соединений, откуда, какие команды. Найдите клиента без пула.
Мини-квиз

1. mem_fragmentation_ratio = 0.9. Что это? — RSS меньше used_memory: часть данных в свопе — критическая ситуация.

2. Почему клиентский p99 важнее серверного? — Показывает весь путь: очереди, сеть, пулы; серверная метрика может быть идеальной при больном клиенте.

3. evicted_keys растёт при hit rate 95% — норм? — Нет: вытесняются живые ключи, значит памяти не хватает под рабочий набор; расширять или чистить.