Home »

Лишние сообщения в ...
 

[Решено] Лишние сообщения в Zabbix при мониторинге портов  

 

Quezovercoatl
(@quezovercoatl)
Эникей
Присоединился: 2 месяца назад
Сообщения: 2
27.07.2020 10:34  

Здравствуйте. Нужна помощь с решением проблемы с Zabbix 5.0.

Задача:

Нужно мониторить доступность 10013(SSH) и 10014(HTTP) портов на сервере. Если недоступен только один из портов, то должно приходить соотвествующее сообщение - SSH Down или HTTP Down. Если недоступны сразу оба порта - то должно прийти только сообщение Server Down. Соотвественно, должны также приходить сообщения о решении проблемы.

Что было сделано: Шаблон TEST с 2 элементами данных и 3 триггерами.

2 элемента данных (Simple check, 10s, Service state):

SSH: net.tcp.service[tcp,,10013]

HTTP: net.tcp.service[tcp,,10014]

3 триггера:

Server Down:

{TEST:net.tcp.service[tcp,,10014].last(#2)}=0 and {TEST:net.tcp.service[tcp,,10013].last(#2)}=0

SSH Down:

{TEST:net.tcp.service[tcp,,10013].last(#2)}=0 #(установлена зависимость от Server Down)

HTTP Down:

{TEST:net.tcp.service[tcp,,10014].last(#2)}=0 #(установлена зависимость от Server Down)

Настроено действие отправка сообщения.

Проблема:

На отдельные порты все срабатывает корректно - 1 сообщение о проблеме и 1 о решении. При недоступности сразу 2 портов приходит только сообщение о проблеме Server Down, тоже все правильно. Но когда порты становятся доступны, происходит следующее - сначала приходит сообщение о решении проблемы - Server Up, а затем еще сразу 2 сообщения - SSH Down и SSH Up. Как избавиться от 2 последних сообщений?

Пробовал различные варианты написания триггеров, например:

SSH {TEST:net.tcp.service[tcp,,10013].last(#2)}=0 and {TEST:net.tcp.service[tcp,,10014].last(#2)}=1

HTTP {TEST:net.tcp.service[tcp,,10013].last(#2)}=1 and {TEST:net.tcp.service[tcp,,10014].last(#2)}=0

и различные варианты настройки Действий. Результат всегда один. Прошу помочь с решением. Возможно, эта проблема легко решается Заббикс агентом, но в данном случае нет возможности его установить на сервер.

Тема была редактированна 2 месяца назад 2 раз от Quezovercoatl

ОтветитьЦитата
Метки темы
Zerox
(@zerox)
Honorable Member Admin
Присоединился: 7 лет назад
Сообщения: 567
27.07.2020 12:14  

Тут дело не в триггерах. Если я правильно понял вашу проблему, то вам просто надо зависимость триггеров настроить. Триггеры SSH Down и HTTP Down должны быть зависимы от триггера Server Down. Тогда при его активности, другие два триггера не будут срабатывать и не будет оповещений. Но вам нужно будет настроить пороги чувствительности. Триггер Server Down должен срабатывать немного раньше, чем два других.

И еще один момент. Не путайте работу условия функции .last(#2) Это не два последних значения, а второе последнее значение с конца. Это не очевидное поведение и многие ошибаются. В данном случае, если не подходит просто last(), последнее значение, лучше использовать avg или min, max функции.


Quezovercoatl лайков
ОтветитьЦитата
Quezovercoatl
(@quezovercoatl)
Эникей
Присоединился: 2 месяца назад
Сообщения: 2
27.07.2020 12:46  

@zerox

Зависимости триггеров я установил сразу, в первом посте об этом писал. А вот с last(#2) действительно ошибся - думал это 2 последних значения. В общем, проблема решилась использованием функции avg в триггерах:

Server Down:  {TEST:net.tcp.service[tcp,,10013].avg(#2)}=0 and {TEST:net.tcp.service[tcp,,10014].avg(#2)}=0

SSH: {TEST:net.tcp.service[tcp,,10013].avg(#4)}=0

HTTP: {TEST:net.tcp.service[tcp,,10014].avg(#4)}=0

 

Большое спасибо за помощь!


Zerox лайков
ОтветитьЦитата