Nagios: алерты, а не графики

Красивые графики никто не смотрел. Это честный вывод после нескольких лет работы с MRTG и самодельными скриптами. Графики висят на внутреннем сервере, выглядят убедительно, показывают трафик, загрузку CPU и место на дисках. Проблема одна: чтобы что-то увидеть, надо туда зайти. А заходишь туда только когда что-то уже сломалось - и в этот момент ты и так знаешь, что сломалось, потому что тебе уже позвонили.

Мониторинг как идею мы обсуждали ещё в 2002-м, но тогда ограничились пингом и самописными проверками. Пора было вырасти.

Почему Nagios

Nagios существует уже несколько лет под именем NetSaint, сменил название, постепенно обрастает экосистемой плагинов. Версия 2.0 вышла в январе, принесла нормальный механизм эскалаций и зависимостей между хостами - именно это нас и убедило.

Главная мысль Nagios простая: система сама замечает проблему и сообщает тебе. Не ты смотришь на графики, а система смотрит на инфраструктуру и кричит когда что-то не так. Это принципиальный сдвиг - из режима «зайди посмотри» в режим «тебя позвали».

Сам Nagios написан на C, конфиги текстовые, плагины - отдельные скрипты на чём угодно. Стандартный набор nagios-plugins покрывает большую часть базовых проверок из коробки: ping, HTTP, SMTP, дисковое место, загрузку, процессы, порты.

Что и как ставили

Развернули на отдельной виртуалке под Debian. Установка несложная, но конфиги Nagios с первого взгляда пугают - там шаблоны, наследование, define-блоки. Разобравшись, понимаешь логику: хосты, сервисы, контакты, временные окна, эскалации - всё отдельными объектами, которые ссылаются друг на друга.

Оповещения настроили двухуровневые. Первый уровень - e-mail дежурному администратору. Если через 30 минут проблема не подтверждена как «видим, работаем» - уходит SMS через шлюз. Для этого нашли простой HTTP-шлюз к SMS-агрегатору, написали скрипт в десяток строк - он и отправляет. Nagios вызывает скрипт при эскалации.

Дополнительно настроили «окна обслуживания» - scheduled downtime. Плановые перезагрузки, обновления, резервное копирование в ночное время - на этот период алерты заглушаются. Без этого Nagios будет орать каждую ночь что СУБД недоступна во время бэкапа.

Первый реальный сбой - и он случился быстро

Прошло три дня после запуска. Около двух ночи Nagios отправил e-mail: «CRITICAL - swap использован на 98%, swap free = 47 MB». Администратор увидел утром - пока нормально, SMS-эскалация на ночь была отключена. Зашли, посмотрели: сервер базы данных медленно течёт по памяти уже несколько дней. PostgreSQL держит открытые соединения, которые не закрываются корректно из приложения, память потихоньку уходит в своп, производительность падает. До этого момента это никак не проявлялось - сервер работал, запросы шли, пусть и медленнее обычного.

Раньше это обнаружили бы утром по жалобам пользователей на тормоза - или не обнаружили бы вообще до момента когда сервер встал. Теперь - нашли за три дня до катастрофы, перезапустили PostgreSQL в плановом окне, разобрались с утечкой соединений в коде.

Вот ради этого и ставили.

Что мониторить в первую очередь

Когда начинаешь, хочется мониторить всё. Это ошибка - через неделю получишь поток алертов, половина которых ложные, и начнёшь их игнорировать. Мы пришли к такому приоритету:

Доступность сервисов. Это важнее метрик. HTTP 200, SMTP отвечает, PostgreSQL принимает соединения, 1С-сервер живой. Если сервис не отвечает - всё остальное неважно.

Дисковое место. Warning на 80%, Critical на 90%. Диск заканчивается предсказуемо, и заблаговременный алерт даёт время разобраться спокойно, а не в панике когда уже 100%.

Свободная память и своп. Память заканчивается по-разному: иногда резко (утечка), иногда постепенно (накопление). Мониторинг свопа - ранний индикатор проблем с памятью, потому что своп начинает расти до того как всё встало.

Загрузка CPU. Но без фанатизма - кратковременные пики нормальны. Ставим порог выше и смотрим на длительность, а не на моментальный снимок.

Время отклика ключевых запросов. Это уже следующий уровень: не просто «сервис живой», а «сервис отвечает за разумное время». Можно делать через check_http с порогом по времени.

Всё остальное - почта, бэкапы, обновления, специфические процессы - добавляем постепенно, по мере появления конкретных поводов.

Ложные срабатывания - это отдельная война

Nagios по умолчанию алертит сразу при первом сбое. Сеть моргнула на секунду - алерт. Это плохо: если алерты приходят часто и оказываются ложными, их перестают читать.

Параметр max_check_attempts решает это: ставим 3-4 попытки перед тем как считать сбой реальным. Между попытками 1-2 минуты. Реальный сбой подтвердится, случайный пинг-пропуск - нет.

Кроме того, правило: если алерт пришёл и ты его не понял - разберись, а не игнорируй. Хронически игнорируемые алерты надо или починить или отключить. Мусор в оповещениях - это хуже чем их отсутствие.

Где это живёт у нас

Сейчас Nagios стоит у нескольких клиентов в рамках сопровождения инфраструктуры. Мониторинг мы держим на нашей стороне - не на серверах клиента, а отдельно - и алерты получаем мы, а не только клиент. Это означает что проблему видим одновременно с её появлением, а не тогда когда нам позвонили.

Это и есть смысл мониторинга с оповещениями: не красивые графики для отчётов, а система которая смотрит за тебя пока ты спишь.