SNMP-мониторинг в Odoo 19: порог превышен, тикет открыт
Серверы, коммутаторы, ИБП, датчики температуры в серверной: почти всё, что подключено к сети, говорит по SNMP и может сообщить о своём состоянии. Вопрос лишь в том, кто слушает — и что происходит, когда значение выходит из-под контроля.
Для инфраструктуры, которую мы обслуживаем для наших клиентов, мы теперь собрали эту цепочку в одном месте: наша Odoo 19 опрашивает устройства, сравнивает значения с пороговыми и, когда порог достигнут, открывает тикет в Helpdesk — у клиента, которому принадлежит устройство. Не отдельная система мониторинга, которая пишет в Helpdesk по электронной почте, а та же система, в которой клиент, устройство и тикет и так связаны.
Модуль мы разработали для собственной работы. Это не публикация для сообщества, как наши модули для банковских выписок или электронных счетов, а часть нашей внутренней платформы обслуживания — как и система отслеживания, о которой мы писали в последний раз.
От измеренного значения до тикета
Процесс намеренно сделан простым:
- Устройство создаётся с адресом и учётными данными (SNMP v1, v2c или v3 с аутентификацией и шифрованием). При сохранении Odoo получает описание системы, имя системы и uptime — самое честное подтверждение того, что адрес и учётные данные верны.
- На устройстве определяются точки данных: OID, единица измерения, привязка к клиенту.
- По расписанию опрашиваются все активные точки данных. Для каждого устройства соединение устанавливается один раз, а не для каждой точки данных — при двадцати OID на коммутаторе это разница между одной и двадцатью сессиями.
- Каждая точка данных может отслеживать пороговые значения: верхний предел, нижний предел или оба.
- При превышении порога создаётся тикет Helpdesk.
Один тикет на инцидент, а не на измерение
Важнейший момент в логике тревог: значение имеет только смена состояния. Кто создаёт тикет при каждом измерении, тот после ночи с заедающим или дребезжащим датчиком получает триста тикетов — это не оповещение, это затуманивание.
Поэтому модуль запоминает для каждой точки данных, находится ли она в состоянии «Норма» или «Тревога». При первом превышении порога состояние меняется, в Chatter устройства появляется сообщение и открывается тикет — с затронутым клиентом в качестве партнёра, с точкой данных, устройством, измеренным значением и нарушенным порогом в тексте. Пока значение остаётся за пределами порога, больше ничего не происходит: тикет открыт, наши техники в курсе.
Когда значение возвращается в нормальный диапазон, модуль записывает отбой тревоги в тот же тикет и снимает связь. Будет ли тикет затем закрыт, по-прежнему решает человек — значение, ненадолго опустившееся ниже порога, ещё не означает, что причина устранена.
Пороговые значения проверяются при каждом измерении независимо от того, сохраняется ли значение. Постоянно слишком высокое значение остаётся тревогой. И тревога никогда не должна срываться из-за того, что тикет не может быть создан — если создание не удалось, протокол и сообщение на устройстве всё равно остаются.
Сохранять только то, что меняется
Точка данных, опрашиваемая каждые пять минут, даёт 105 000 значений в год. При ста точках данных это более десяти миллионов строк — для значений, которые в большинстве случаев вообще не изменились.
Поэтому сохраняется только то, что отличается от последнего сохранённого значения больше чем на заданный порог — для каждой точки данных как абсолютная разница (например, 0,5 °C), как процентное отклонение или при каждом изменении. Текущее значение и время последнего опроса при этом всегда указаны в точке данных; прореживается только история.
Куда записываются значения, тоже настраивается: в базу данных Odoo, в MongoDB или в виде CSV-файлов в Filestore Odoo. Так мы держим измеренные значения вне базы данных ERP — тот же принцип, что и для данных о позициях в системе отслеживания. История в любом случае может отображаться в виде диаграммы, при почасовом уплотнении — как среднее значение, а не как сумма.
Заполненность в процентах вместо байтов
Некоторые величины в устройстве как таковые не представлены. Заполненность раздела нужно вычислять из занятой памяти и общего размера; датчики температуры часто выдают масштабированные целые числа — 235 для 23,5 градуса.
Поэтому точка данных может принимать значение как сообщено, умножать его на коэффициент или вычислять как процент от второго OID. Для пороговых значений это решающе: порог в 90 % действует для любого размера диска. Порог в гигабайтах пришлось бы поддерживать для каждого диска отдельно.
Никому не нужно помнить OID наизусть
Для серверов Windows и Linux HOST-RESOURCES-MIB стандартизирован: диски и оперативная память находятся в известном месте. Определение устройства считывает таблицу, пересчитывает заполненность в проценты и создаёт точки данных вместе с порогом тревоги одним щелчком.
Для всего остального есть SNMP-браузер, который обходит дерево OID и показывает каждый найденный OID с его текущим значением — и, если известно в каталоге, с названием, описанием и единицей измерения из импортированной MIB производителя. Достаточно поставить отметку.
Что получают от этого наши клиенты
Устройства и точки данных привязаны к клиентам. В клиентском портале в разделе Мои значения SNMP вы найдёте текущие измеренные значения ваших устройств и историю за последние 24 часа, 7 дней, 30 дней или 12 месяцев в виде диаграммы — те же значения, которые видим и мы. Видно исключительно то, что привязано к вашей компании.
А если порог превышен, вам ничего не нужно делать: тикет уже у нас — с устройством, значением и временем — прежде чем вы это заметите.
Чем модуль намеренно не является
Это не замена полноценному мониторингу с проверками доступности, цепочками эскалации и деревьями зависимостей. Он не принимает SNMP-трапы, а опрашивает активно. И он не закрывает тикет автоматически — отбой тревоги является сообщением, а не изменением статуса.
Речь идёт ровно об одном участке: от измеренного значения через порог к технику, который этим занимается. Этот участок теперь настолько короток, насколько это возможно.
Если вы хотите включить ваши серверы, сетевые устройства или датчики в этот мониторинг, обращайтесь к нам.