В мире OpenSource существует прекрасная платформа мониторинга сетевого оборудования Zabbix. Грамотный админ одним из первых сетевых инструментов поднимает именно эту систему, чтобы практически в реальном времени понимать, что происходит у него в сети. Zabbix лучше всего ставить на выделенный сервер, чтобы его скрипты работали с физической сетевой картой. На вдумчивое конфигурирование Zabbix уходит несколько недель, чтобы полностью разобраться с ним и отладить все механизмы сбора данных.

Но что делать, если под рукой только единственный тестовый сервер, на котором крутится все что можно - от 1С с его PostgreSQL и апачевым веб-клиентом до видеонаблюдения? А бедолагу-админа завалили тоннами бумаги по безопасности, тратя все его время на проверки и прохождение очередных сертификаций? В такой ситуации можно и заколхозить самодельную легковестную систему монторинга, чтобы через нее видеть проблемы, возникающие хотя бы в ядре сети. Так сказать, до лучших времен.

Так у меня появилась маленькая самописная система мониторинга, и неплохо отработала несколько месяцев, пока на предпиятии не появились новые сервера и админ наконец-то не настроил Zabbix. Написана система на Python. Особенность этой системы в том, что она способна делать различные замеры по ICMP и SNMP, а отправлять отчеты о критических ситуациях может на только на email, но и по SMS. Да, для этого дела я прикрутил к серверу по COM-порту старенький мобильник Siemens M50 с параллельной подзарядкой и с SIM-картой, которая была активирована на корпоративный тариф с бесплатными SMS-сообщениями в количестве 2000 штук.

Логика настройки этой  системы следующая: сначала настраивются источники обрабатываемых данных (источники именованных значений), и потом настраиваются правила, которые выполняют различные проверки полученных значений. В случае, если обнаружено отклонение от допустимых величин, считается что наступило критическое событие.

Сами именованные значения могут иметь обычные Python-типы int, float, bool, string.И вытягиваются они из оборудования примерно так:

measureValue.addItem(
 "APC5000_Temperature",            # Имя значения
 "int",                            # Тип значения
 "snmpDeviceSensor",               # Механизм получения
 "10.153.0.88",                    # IP устройства
 ".1.3.6.1.4.1.318.1.1.1.2.2.2.0") # SNMP идентификатор

А сравнение возможно по принципу больше/меньше/равно и даже можно оценивать градиент, так как недавняя история каждого значения хранится в БД SQLite3. И выглядит описание правил примерно так:

valueAnalytic.addRule({
"ruleName"    : "ИБП APC5000 слишком горячий",
"ruleType"    : "aboveOrEqual",
"valueName"   : "APC5000_Temperature",
"targetValue" : 35
})

valueAnalytic.addRule({
"ruleName"   : "На ИБП APC5000 нет напряжения питания",
"ruleType"   : "equal",
"valueName"  : "APC5000_InputVoltage",
"targetValue": 0

})

Исходники этой системы мониторинга опубликованы на GitHub:

Проект Monitoring-sp

Почему в названии используется суффикс "-sp"? Потому что нотификация возможна по SMS и по электропочте (Post), вот почему.

К вопросу, зачем вообще заморачиваться с COM-портом и SMS, рекомендую рассмотреть непредвиденные ситуации, когда из-за форсмажора обрубается интернет (например, перерубили кабель, возник пожар, которокое замыкание в блоке питания маршрутизатора), и никто в этом случае никакого письма не получит, да и SMS, отправляемое через какое-нибудь Interner API, тоже отправлено не будет. Конечно, лучше было бы использовать промышленный GSM-модуль. Но предприятия бывают разные, и есть такие, в которых доказать необходимость закупки такого устройства невозможно, а если чудо и произойдет, то поставка затягивается на годы. В таких условиях, хочешь не хочешь, а расчехлишь свой старенький мобильник с AT-командами, и сделаешь из говна и палок очередного монстрика.