Алерты LibreNMS в Telegram и интеграции: как мы делаем так, чтобы о падении сети клиент узнавал от нас, а не наоборот

Философия алертинга: почему «слать всё» хуже, чем не слать ничего

Меня зовут Семёнов Евгений Сергеевич, я технический директор ITfresh. Мы обслуживаем компании до 50 рабочих мест в Москве, держим собственные серверы в дата-центре МТС, и на мониторинге у нас несколько десятков клиентских площадок. Все аварии со всех площадок стекаются в Telegram-каналы дежурной смены — и именно поэтому я очень трепетно отношусь к тому, что туда попадает.

Главную ошибку молодого внедренца я наблюдал десятки раз: человек ставит систему мониторинга, радуется её возможностям и включает уведомления на всё подряд. Порт мигнул — сообщение. Загрузка процессора подскочила на десять секунд — сообщение. Принтер ушёл в сон — сообщение. Через неделю чат превращается в шумовой фон, который никто не читает. А ещё через месяц среди трёхсот мусорных строк тонет одна настоящая: «роутер клиента недоступен». И мониторинг, формально работающий, фактически мёртв.

Наш принцип сформулирован жёстко: алерт равен действию. Если на сообщение не нужно реагировать прямо сейчас или в ближайший рабочий день — это не алерт, а мусор. Всё, что «интересно, но не требует рук», живёт в дашбордах и еженедельных дайджестах, но не дёргает дежурного.

Уровней серьёзности мы используем два с половиной:

• Critical — сервис для клиента не работает или откажет в ближайшие часы: упал роутер, недоступен терминальный сервер, ИБП на батарее, диск заполнен на 95%. Реакция — немедленно, в любое время.
• Warning — деградация без простоя: ошибки на порту растут, канал утилизирован под завязку, заряд ИБП ниже половины. Реакция — в рабочее время, сегодня-завтра.
• Recovery — «всё восстановилось». Формально не уровень, но обязательная часть: без сообщений о восстановлении дежурный вынужден перепроверять каждый алерт руками.

Как устроены alert rules в LibreNMS

В LibreNMS правило оповещения — это условие над любыми метриками, которые система уже собирает по SNMP. Правила создаются в веб-интерфейсе конструктором (Alerts → Alert Rules): выбираете поле, оператор, значение, при необходимости комбинируете условия через И/ИЛИ. Никакого собственного языка учить не нужно — под капотом условие превращается в SQL-запрос к базе, и это же даёт правилам огромную гибкость: доступна любая таблица из схемы.

Типовые поля, на которых строится 90% наших правил:

• devices.status — устройство отвечает или нет;
• ports.ifOperStatus — состояние конкретного порта;
• sensors.sensor_current — показания датчиков (температура, напряжение, заряд батареи ИБП);
• storage.storage_perc — заполненность дисков;
• processors.processor_usage и mempools.mempool_perc — процессор и память.

Анатомию правила покажу на примере «упал аплинк». Условие: ports.ifOperStatus = "down" AND ports.ifAdminStatus = "up". Вторая часть критична: она отсекает порты, выключенные администратором намеренно. Дальше три параметра, которые превращают сырое условие в осмысленный алерт:

• Delay — сколько условие должно продержаться до отправки. Для портов ставим 2–5 минут: короткий флап при перезагрузке железки не будит дежурного.
• Interval — период повторной отправки, если аварию никто не подтвердил. У нас 30–60 минут для critical, чтобы незакрытый инцидент напоминал о себе.
• Устройства и группы — правило вешается не на всю инсталляцию, а на группу: «сетевое ядро», «ИБП», «серверы». Группы собираются динамически по типу ОС, локации или кастомному полю.

Текст сообщения собирается из шаблона с макросами. Наш базовый шаблон выглядит примерно так:

{{ $alert->severity }} | {{ $alert->sysName }}
Правило: {{ $alert->title }}
Время: {{ $alert->timestamp }}
@foreach ($alert->faults as $f)
Порт/датчик: {{ $f['string'] }}
@endforeach

В сообщение попадает имя устройства, сработавшее правило и конкретный порт или датчик. Дежурный из одного взгляда на телефон понимает, куда идти, — без логина в веб-интерфейс.

Стартовый набор правил ITfresh для типового офиса

За годы внедрений у нас сложился стандартный комплект, который мы включаем на каждой площадке в первый день. Он маленький — и это осознанно: лучше семь правил, на которые реагируют, чем семьдесят, которые скрывают.

Отдельная история — тонер в принтерах. Технически LibreNMS видит уровень тонера по SNMP, и правило пишется за минуту. Но включаем мы его не всем: если у клиента картриджи возит подрядчик по договору, алерт полезен — уходит сразу офис-менеджеру, и картридж приезжает до того, как принтер встал. Если печатью никто централизованно не занимается, алерт повисает мёртвым грузом и только зашумляет канал. Это хорошая иллюстрация принципа «алерт равен действию»: одна и та же метрика у одного клиента — алерт, у другого — строчка в дашборде.

Доставка: Telegram, email и дежурная смена

Транспорт Telegram за десять минут

Telegram — наш основной канал доставки, и в LibreNMS он поддержан из коробки. Настройка сводится к четырём шагам:

1. Создаём бота через @BotFather командой /newbot и получаем токен.
2. Добавляем бота в канал или группу дежурной смены.
3. Узнаём chat_id: пишем в группу любое сообщение и открываем https://api.telegram.org/bot<токен>/getUpdates — идентификатор чата будет в ответе (у групп он отрицательный).
4. В LibreNMS: Alerts → Alert Transports → создаём транспорт типа Telegram, вписываем токен и chat_id.

Дальше транспорт привязывается либо к конкретным правилам, либо назначается транспортом по умолчанию. Проверяется кнопкой Test — сообщение прилетает мгновенно.

Email как резервный и «медленный» канал

Электронную почту мы не считаем каналом для аварий: её читают раз в час, а не раз в минуту. Но у email две законные роли. Первая — резерв: если Telegram недоступен (бывает и такое), критические алерты дублируются на почту смены. Вторая — «медленные» уведомления: еженедельная сводка warning-событий, дайджест по новым устройствам из автообнаружения, отчёты о доступности. То, что должно быть прочитано, но не должно никого будить.

Разные каналы для разных severity

Ключевой приём, который делает алертинг переносимым для людей: critical и warning живут в разных каналах. Critical падает в основной чат смены со звуком. Warning — в отдельный канал, который дежурный просматривает утром и после обеда. Recovery-сообщения идут туда же, куда шла авария. В LibreNMS это делается привязкой разных транспортов к разным правилам — у нас просто два бота-транспорта на два канала.

Maintenance-окна: не будить дежурного зря

Плановые работы — главный источник ложных ночных подъёмов. Перед любыми работами на площадке инженер обязан поставить maintenance-окно (Alerts → Scheduled Maintenance): выбирается устройство, группа или локация целиком и интервал времени. Все алерты по объектам окна подавляются. У нас это пункт чек-листа выезда: не поставил окно — разбудил смену — объясняешься на планёрке. Работает безотказно.

Интеграции глубже алертов

REST API: мониторинг как источник данных

У LibreNMS полноценный REST API: токен создаётся в настройках пользователя, дальше любые данные доступны обычным HTTP-запросом:

curl -H "X-Auth-Token: ваш_токен" \
  https://nms.example.ru/api/v0/devices

curl -H "X-Auth-Token: ваш_токен" \
  https://nms.example.ru/api/v0/devices/core-sw-01/ports

Мы используем API для сверки инвентаризации: скрипт раз в неделю выгружает список устройств со всех клиентских инсталляций и сравнивает с учётной системой. Появилась в сети железка, которой нет в учёте, — карточка на разбор. Исчезло устройство, которое числится боевым, — тоже. Инвентаризация из ежегодного подвига превратилась в фоновый процесс.

Oxidized: кто и когда поменял конфиг

Oxidized — отдельный открытый инструмент, который по расписанию забирает конфигурации с коммутаторов и роутеров и складывает их в git-репозиторий. Связка с LibreNMS штатная: на странице устройства появляется вкладка Config с текущей конфигурацией и историей изменений в виде диффов. Это маст-хэв, который мы ставим рядом с каждой инсталляцией. Он закрывает вечный вопрос «сеть сломалась — что менялось?»: открываешь дифф за последние сутки и видишь, что вчера в 18:40 на ядре кто-то трогал VLAN. Плюс это бесплатный бэкап конфигов: замена умершего коммутатора превращается в «залить последний конфиг из git».

Syslog и SNMP trap: события между опросами

Опрос по SNMP идёт раз в пять минут — всё, что случилось и прошло между опросами, поллер не увидит. Для таких событий LibreNMS принимает syslog и SNMP trap: флап порта, срабатывание защиты петли, ошибки аутентификации на железке прилетают в систему мгновенно и видны в журнале устройства. На syslog тоже можно вешать правила — например, мы ловим строки о срабатывании loop protection: это почти всегда означает, что кто-то в офисе воткнул патч-корд «кольцом» в две розетки.

Дашборд на ТВ-панель

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

Миграция на LibreNMS с других систем

С «мониторинга в голове админа»

Самый частый исходник — мониторинга нет вообще, есть админ, который «и так всё знает». Тут миграция сводится к дисциплине: сначала автообнаружение и полная инвентаризация (обычно с сюрпризами — про них ниже), неделя-две накопления графиков, и только потом правила. Включать алерты в первый день на неизученной сети — гарантированный шторм.

С Observium

LibreNMS исторически вырос как форк Observium, структура похожа, и в сети встречаются инструкции по переносу базы целиком. Мы так не делаем: тащить чужую базу со всем накопленным мусором — плохой старт. Переносим только список устройств (выгрузили — добавили скриптом через API) и осмысленные пороги. Графики отрастают заново за пару недель.

С PRTG и Zabbix

Автоматического импорта из PRTG или Zabbix не существует, и это нормально: у систем разные модели данных, и любой «конвертер» переносил бы синтаксис, а не смысл. Мы переносим именно смыслы: выгружаем из старой системы список объектов, действующие пороги, контакты и цепочки эскалации — и переписываем их в терминах LibreNMS. Заодно происходит естественная ревизия: треть старых проверок обычно оказывается никому не нужной.

Обязательный элемент — параллельная работа двух систем 2–4 недели. Старый мониторинг продолжает алертить, новый работает в «тихом» режиме, дежурные сверяют: всё ли, что поймал старый, увидел новый. Только после сверки старая система выключается. Дважды такая параллель ловила нам пробелы в покрытии — дешёвая страховка.

Ложные срабатывания и тюнинг: первый месяц эксплуатации

Первый месяц после включения алертов — период обкатки, и его надо планировать заранее. Покажу на реальном журнале одного из клиентов (офис на два этажа, около 60 устройств в мониторинге): за первый месяц система отправила 240 уведомлений. Через месяц тюнинга — 30 в месяц, и почти каждое требовало действия. Что мы сделали:

• Flapping-порты. Половину шума давали два порта доступа, к которым были подключены ноутбуки через док-станции: линк падал и поднимался десятки раз в день. Лечение — правило на access-порты убрали вовсе (алертим только аплинки и магистрали), на пограничных случаях подняли delay.
• Гостевой Wi-Fi. Точки гостевой сети перезагружались по ночному расписанию и исправно будили смену. Вынесли их в отдельную группу устройств с warning вместо critical и delay 15 минут.
• Филиал за нестабильным каналом. Площадка на загородном складе с LTE-каналом «падала» на две-три минуты несколько раз в день. Для её группы подняли delay до 10 минут и повесили отдельное правило на суммарную недоступность за сутки — канал под замену, но пока живём так.
• Датчики-фантомы. Пара железок отдавала по SNMP несуществующие сенсоры с мусорными значениями — отключили конкретные датчики в карточках устройств.

Важно: тюнинг — это не «подкрутили и забыли», а еженедельный получасовой разбор журнала алертов в первый месяц. Каждое ложное срабатывание получает решение: изменить порог, поднять delay, перегруппировать, отключить. Если этот месяц пропустить, чат зашумляется, и дальше происходит то, с чего начиналась статья.

Итог: во что превращается поддержка с настроенным алертингом

Наша главная метрика качества мониторинга — «кто узнал первым». До внедрения нормальной системы оповещений порядка 80% инцидентов нам сообщал клиент: звонок «у нас не работает» — и инженер начинает диагностику с нуля под давлением. После внедрения LibreNMS с выверенными правилами картина зеркальная: около 90% инцидентов дежурная смена видит в Telegram до первого звонка, и клиенту звоним уже мы — со словами «знаем, чиним, срок такой-то». Разница в доверии колоссальная.

Если начинаете с нуля — вот десять правил, которых достаточно для старта на типовом офисе:

1. Устройство недоступно дольше 5 минут — critical.
2. Аплинк или магистральный порт down — critical.
3. ИБП на батарее — critical.
4. Заряд ИБП ниже 50% — warning.
5. Температура в серверной выше порога — warning.
6. Диск сервера заполнен на 90% — warning.
7. Аптайм меньше 10 минут — warning.
8. Ошибки на магистральных портах — warning.
9. Утилизация канала выше 80% дольше 15 минут — warning.
10. Recovery-уведомления — на все правила выше.

Всё остальное добавляйте только тогда, когда сможете назвать действие, которое последует за сообщением.

Алертинг — это середина жизненного цикла системы мониторинга. Про то, что происходит дальше — обновления, бэкапы (спойлер: MySQL — это ещё не всё), безопасность самого сервера мониторинга и масштабирование, — читайте в следующей статье: «LibreNMS в бою: регламент эксплуатации». А если хотите, чтобы всё это настроили и сопровождали мы, — контакты ниже.