Наблюдаемость и мониторинг

Система мониторинга непрерывно собирает сигналы о хостах и сервисах, хранит их во времени, визуализирует и поднимает алерты, когда что-то пересекает порог. Её цель — рано обнаруживать сбои и деградацию и давать данные для их диагностики. Распространённые инструменты — Prometheus, Zabbix, Grafana и стек ELK.

Метрики — это числовые временные ряды: дешёвые агрегаты вроде частоты запросов или CPU, показывающие состояние и тренды сервиса. Логи — это дискретные события с меткой времени и деталями, помогающие понять, что случилось вокруг ошибки. Трейсы прослеживают один запрос через сервисы, вскрывая задержки для поиска узких мест. «Здоров ли?» — метрики, «что случилось?» — логи, «где тормозит?» — трейсы.

Counter только растёт — запросы или ошибки — и его читают через rate(). Gauge меняется в обе стороны, как память или длина очереди. Histogram раскладывает наблюдения по бакетам, из которых выводят перцентили задержки; summary считает их на стороне клиента. Для задержки берите histogram — среднее прячет хвост.

Load average — это среднее число процессов, готовых к выполнению или в непрерываемом ожидании, за последние 1, 5 и 15 минут. Здесь 50/20/10 значит, что нагрузка быстро растёт — недавняя сильно превышает старое окно. Плохо ли это, зависит от числа ядер: нагрузка около числа ядер нормальна, а намного выше значит, что задачи стоят в очереди за CPU, диском или I/O.

Частота ошибок — это rate() по счётчику http_requests_total, отфильтрованному по 5xx и за 5m. Для p95 берут histogram_quantile(0.95, ...) по rate от серий _bucket, но сперва нужен sum by (le). Задержку не усредняют, и перцентили нельзя усреднять между инстансами — сначала агрегируют бакеты, затем берут квантиль.

Prometheus работает по pull: он опрашивает цели с интервалом через service discovery, поэтому пропавший scrape уже сигнал недоступности. Batch-задачи, слишком короткие для опроса, пушат в Pushgateway, который Prometheus скрейпит. Правила алертинга пересчитывают PromQL каждый интервал и срабатывают в окне for — алертите на симптомы, не на причины.

Load average 38 на 4 ядрах далеко за пределом, но CPU почти простаивает, а 86,5% — это wa (ожидание I/O), и память в норме — значит хост упирается в диск, а не в CPU. Узкое место — дисковый I/O: процессы заблокированы в ожидании хранилища. Подтвердите через iotop или iostat -x, найдя занятое устройство и виновный процесс.

Система управления конфигурацией вроде Ansible или Puppet описывает желаемое состояние множества хостов как код и приводит каждый хост к нему — пакеты, файлы, службы. Инструмент вносит лишь нужные изменения. Она идемпотентна: повторный запуск того же playbook на уже корректном хосте ничего не меняет, поэтому запуски безопасно повторять, и они сходятся к заданному состоянию.

Не делать это вручную. Используйте управление конфигурацией (Ansible, Puppet или Salt), чтобы идемпотентно установить пакет, разложить шаблонный конфиг и включить службу на всех хостах — единый повторяемый источник правды. Гоните пачками, чтобы не перегрузить сервер мониторинга, и применяйте авторегистрацию за allow-list, регистрируя только ожидаемые хосты. Ожидайте: отсутствие сетевых доступов, разнородность ОС/версий, слабые хосты и раздачу учёток.

Ровный CPU значит, что хост не узкое место. Примените RED — rate, errors, duration — по маршрутам: рост duration с редкими ошибками указывает на медленную зависимость, а не на процессор. USE — utilization, saturation, errors — остаётся низким, исключая CPU и память. Читайте p99 из гистограммы, а не среднее, которое прячет хвост.

Скрейпьте через Prometheus с service discovery, чтобы новые Pod находились; храните в Thanos или Mimir; визуализируйте в Grafana; алертите через Alertmanager по прогоранию SLO (service-level objective), не по ошибкам. Добавьте логи (Loki) и трейсы (Tempo), связанные correlation id, чтобы дашборд показывал, приложение виновато или зависимость.