У меня есть zabbix-прокси и 12 узлов в этом прокси. Прямо сейчас, когда прокси-сервис выходит из строя. Он отправляет почту вне досягаемости для всех 12 узлов. Я хочу отправлять почту только для прокси zabbix, а не для узлов под этим прокси
Обновлено: теперь я пытаюсь создать один триггер, в котором я хочу проверить оба условия, такие как 1-check, zabbix-host недоступен за последние x минут. 2-проверьте, что хост не передает никаких данных прокси (хост не работает).
Не триггер должен начать кричать только тогда, когда у нас есть условие, в котором прокси работает, а узел не работает. Я пробовал следующее, но у меня это не работает. Могут ли некоторые помочь мне в этом
({ip-10-4-1-17.ec2.internal:agent.ping.nodata(2m)}=1) & ({ip-10-4-1- 17.ec2.internal:zabbix[proxy,zabbixproxy.dev-test.com,lastaccess].fuzzytime(120)}=1)
Один из способов добиться этого - отслеживать доступность Zabbix прокси. Это делается с помощью zabbix[proxy,<name>,lastaccess] внутренний элемент. в документация по внутренним предметам, затем предлагается использовать fuzzytime() функция триггера для проверки доступности вашего прокси:
{<zabbix>:zabbix[proxy,<name>,lastaccess].fuzzytime(2m)}=0
После этого вы можете сделать триггеры «хост недоступен» зависимыми от этого триггера, что предотвратит их активацию, когда прокси недоступен (см. документация по зависимостям триггеров Чтобы получить больше информации).
ответ асавельева хороший. некоторые заметки о потенциальных проблемах.
прокси будет обнаружен как отсутствующий, и зависимости будут работать должным образом. но предположим, что прокси-сервер недоступен в течение длительного периода времени - 30 минут и более. предположим, что он продолжает собирать данные. после восстановления соединения он отправляет значения. В этот момент сервер видит, что прокси доступен (обновляется внутренний элемент последнего доступа), но прокси всегда отправляет данные последовательно (сначала старые значения). если прокси-сервер собрал большое количество значений, потребуется некоторое время, чтобы отправить последние значения. для хостов за прокси-серверами у вас будут триггеры nodata () по их доступности, и эти триггеры увидят, что данные отсутствуют, и они сработают.
начиная с zabbix 2.2, есть новый внутренний элемент - zabbix[proxy_history] . теоретически его можно использовать для отслеживания количества неотправленных значений, которые имеет прокси zabbix, и иметь триггер (t), если это число велико. тогда у каждого будет зависимость от этого триггера (t) от всех триггеров доступности хоста, а триггер (t), в свою очередь, будет зависеть от триггера последнего доступа. таким образом, если прокси внезапно исчезнет, у нас все еще будет задержка при последнем доступе. если он вернется, мы заметим большое отставание в истории и по-прежнему не будем предупреждать ни о чем ... кроме того, что внутренние элементы подчиняются той же самой очереди прокси / более старым первым правилам. пока мы не получим значения о большом буфере / истории прокси, мы уже запускали триггеры о хостах за прокси.
так есть ли решение? может быть.
информацию о буфере прокси можно извлечь из базы данных прокси. наша задача - доставить его на сервер как можно скорее после восстановления связи. у нас есть два варианта:
Агент zabbix будет собирать размер буфера / истории и отправлять его непосредственно на сервер, не проходя через кеш / буфер прокси. если бы это был пассивный агент, мы бы полностью потеряли значения буфера во время простоя, а затем мы бы зависели от интервала элемента, чтобы получить первое значение после восстановления соединения. если бы это был активный агент, мы могли бы сохранить некоторый объем данных (100 или 50 по умолчанию) во время простоя. однако это, вероятно, приведет к крошечной задержке для отправки этих значений. по умолчанию агент будет пытаться отправлять эти значения каждые 5 секунд или чаще.
в этом случае мы сможем решить, заботимся ли мы о ценностях во время простоя. если нет, то просто - соберите значения и просто отправьте их на сервер, игнорируя сбои. если мы хотим получить значение i как можно скорее, мы, вероятно, введем некоторую логику для отправки значения каждые 60 секунд, но если это не удается, каждые 5 секунд или около того. если мы заботимся о значениях во время простоя, нам придется реализовать логику для хранения этих значений каждые секунды. если отправка не удалась, всегда сначала повторите попытку со старыми значениями, но продолжайте собирать значения (более старые значения должны быть отправлены первыми, чтобы не все события из триггера для этого элемента были испорчены). по сравнению с отбрасыванием значений это может вызвать крошечную задержку для получения последнего значения на сервер.
во всех этих случаях, вероятно, существует очень маленькое окно для состояния гонки, которое потенциально может быть устранено с помощью некоторых хитрых уловок вокруг триггеров (возможно, требуя, чтобы последний доступ был недавним, и убедившись, что последние 3 его значения все разные или что-то в этом направлении ).
о, и потенциальный запрос для получения истории / размера буфера на прокси-базе данных (может не работать со всеми поддерживаемыми базами данных, при необходимости адаптируйте):
выберите ((выберите max (proxy_history.id) from proxy_history) -nextid) из идентификаторов, где field_name = 'history_lastid';