В нашей производственной среде для записи видео (как IP потоков, так и по SDI) используется программное обеспечение METUS-Ingest. Сразу возникла задача по мониторингу работы этого ПО и оперативному оповещению при его сбоях.

Сам сервер, на котором функционирует данное ПО, мониторится стандартным образом при помощи Zabbix-agent. А вот задача по контролю доступности самого сервиса записи решилась оригинальным способом. Встроенных средств, типа SNMP, Metus-Ingest не имеет, зато наличествует система удаленного управления по протоколу Telnet, соответственно, при помощи Zabbix-server можно как минимум контролировать доступность TCP-порта, через который эта система работает.

В Zabbix-server существует специальный элемент данных, типа Telnet-agent, для его работы при подключении, от сервера telnet в обязательном порядке должен поступить активный запрос на авторизацию. Но в Metus-Ingest используется т.н. пассивная авторизация, когда никакого запроса сервер не отправляет, а клиент после подключения должен сам передавать строку типа:

Соответственно использовать Telnet-agent не получится. Выйти из положения можно двумя способами:

1. Использовать тип данных «Внешняя проверка» совместно с отдельным файлом скрипта (например на bash), в котором будут производиться все необходимые действия по проверке доступности сервера, а в Zabbix будет передаваться только результат этой проверки.
2. Использовать тип данных «Простая проверка», в котором необходимо прописать выражение для простого контроля доступности TCP-порта, через который работает система удаленного управления сервисом записи.

Т.к. для определения факта работы самого сервиса записи, нам достаточно контролировать доступность TCP-порта системы удаленного управления, остановимся на втором варианте.

Итак, наш хост-сервер для записи видео уже контролируется при помощи Zabbix-agent, соответственно на Zabbix-server уже существует необходимый узел сети (VDR-1).Заходим на вкладку «Элементы данных» этого узла и создаем новый элемент (кнопка в правом верхнем углу) и заполняем все необходимые поля и нажимаем кнопку «Добавить»:

Собственно для контроля доступности нужного нам порта используется выражение в поле «Ключ», типа:

После создания элемента данных, необходимо создать и соответствующий триггер, который будет реагировать на изменение состояния этого элемента. 

На вкладке «Триггеры» этого же узла сети создадим новый триггер, заполним поле «Имя»,  важность выставим как «Высокая», а режим генерации событий ПРОБЛЕМА, как «Множественный». Последний параметр позволит создавать оповещение каждый раз при срабатывании этого триггера, соответственно вплоть до устранения проблемы нам будут лететь оповещения. Если такая важность не требуется можно оставить этот режим, как одиночный.

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

Обратите внимание, что в поле «Результат» остается выражение «=0». В данном случае это верно, т.к. элемент данных при недоступности сервиса TCP возвращает именно «0». А проверяется состояние доступности сервиса каждую минуту, соответственно при настройке количества проверок равной 3, этот триггер сработает после недоступности сервиса в течение 3х минут.

На этом настройку мониторинга доступности TCP-порта можно считать оконченной.

Спасибо за внимание!