глубже надо копать)

глубже надо копать)

со слоу)

А кто что монитрит в нджинксе? Только вывод модуля nginx_stub?

Привет всем, хочу мониторить несколько интернет линии, цель - когда все линии падают только тогда должен триггер срабатывать, не хочу создавать триггер в ручную в одном из хостов. Было бы удобнее через discovery. Я пробовал в хосте прописать несколько IP адресов хоста но так не получаеться. Есть у кого то опыт как правильнее было бы сделать ?

Привет всем, хочу мониторить несколько интернет линии, цель - когда все линии падают только тогда должен триггер срабатывать, не хочу создавать триггер в ручную в одном из хостов. Было бы удобнее через discovery. Я пробовал в хосте прописать несколько IP адресов хоста но так не получаеться. Есть у кого то опыт как правильнее было бы сделать ?

Проще триггер ручками создавать, а айтемы через ллд.

Проще триггер ручками создавать, а айтемы через ллд.

я подумал так как в хосте мы можем указать несколько интерфейсов, то можно там прописать все публичные адреса, и уже через дисковери создать айтемы и триггеры. Я могу и через сервис мониторинг тоже делать, но в этом случае не возможно акшнить и получить нотификацию :(

У меня давно вопрос в голове висит, зачем в заббиксе можно несколько интерфейсов одинаковых создавать если они не работают? На следующий всё равно же не переключается автоматически.

У меня давно вопрос в голове висит, зачем в заббиксе можно несколько интерфейсов одинаковых создавать если они не работают? На следующий всё равно же не переключается автоматически.

ага, согласен, он же айтем может подключить только к одному интерфейсу, и не возможно указать там несколько даже если делаю simple check

в 3.4 версии есть что то новенькое https://www.zabbix.com/documentation/3.4/manual/discovery/low_level_discovery/host_interfaces я подумал может кто то делал уже

А кто что монитрит в нджинксе? Только вывод модуля nginx_stub?

response codes

У меня давно вопрос в голове висит, зачем в заббиксе можно несколько интерфейсов одинаковых создавать если они не работают? На следующий всё равно же не переключается автоматически.

их можно использовать в icmpping , по-моему. Как HOST.IP1..2..3

Коды ответа это не к нджинксу, а к мониторингу приложения ближе. Их же пару десятков и написать более менее универсальный шаблон не получится, это скорее дочерний шаблон который каждый под свои реалии пишет и паравозиком к нджинксу вешает.

их можно использовать в icmpping , по-моему. Как HOST.IP1..2..3

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

А я и не утверждал, что там что-то автоматически происходит. Скорее всего это какое-то архитектурное наследие.

А кто что монитрит в нджинксе? Только вывод модуля nginx_stub?

все что отдает

Типа такого? https://share.zabbix.com/cat-app/web-servers/template-app-nginx-for-zabbix-3-4-x Я переделал популярный шаблон нджинкса на использование препроцессинга и без юзерпараметров. Он собирает все 7 метрик из stub модуля и запущен ли процесс нджинкса, думаю версию нджинкса мониторить не обязательно. Т.к. используется препроцессинг то минимальная версия заббикса 3.4. В остальном пользуйтесь на здоровье.

Доброго вечера. Такой вопрос: есть триггер на web-проверки, он зависит от триггеров "no ICMP ping" для проксей. Пропал пинг на прокси, триггер web-проверки, соответственно, тоже не отработал. Пинг восстановился, но свои функции прокси выполнять не начал. Триггер на web имеет вид {AFS:web.test.rspcode[{$AFS_CODE} AD check via DC2 balancer,{$AFS_CODE} AD via DC2].count(#3,200,ne)}>=3 Правильно я понимаю, что из-за того, что три не-200-х кода пришли во время работы триггера по пингу - то после восстановления этого триггера - триггер web-проверки уже и не сработает, даже если проблема с вэб продолжается?

вроде бы должны ж?

Триггер это функция и не важно в какой момент родительский триггер восстановится. Функция работает с полученными данными

Вот и я так думал. Спасибо. Буду дальше причину искать

Если разница во времени восстановления родительского триггера ранее обработанных данных, то зависимый триггер сработает. Там даже микросекунды влияют.

Я так понял триггер отрабатывает по сути всегда

Но если он зависит от других то условно отображаться не будет

Нет, если родительский триггер зажегся, то веб проверка не зажгется пока не погаснет родительский

Нет, если родительский триггер зажегся, то веб проверка не зажгется пока не погаснет родительский

Не зажгется, но он уже активирован

Но если он зависит от других то условно отображаться не будет

Да, наверно я не правильно выразился, именно что не отображается как проблема и не было уведомления

Доброго вечера. Такой вопрос: есть триггер на web-проверки, он зависит от триггеров "no ICMP ping" для проксей. Пропал пинг на прокси, триггер web-проверки, соответственно, тоже не отработал. Пинг восстановился, но свои функции прокси выполнять не начал. Триггер на web имеет вид {AFS:web.test.rspcode[{$AFS_CODE} AD check via DC2 balancer,{$AFS_CODE} AD via DC2].count(#3,200,ne)}>=3 Правильно я понимаю, что из-за того, что три не-200-х кода пришли во время работы триггера по пингу - то после восстановления этого триггера - триггер web-проверки уже и не сработает, даже если проблема с вэб продолжается?

Вообще должен зажечься

Нет, он может иметь выражение которое учитывает статус родительского триггера или данные в него могут упасть раньше погашения родителя

если 200 не пришло

Нет, он может иметь выражение которое учитывает статус родительского триггера или данные в него могут упасть раньше погашения родителя

Ну сейчас речь про простую зависимость

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

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

Ну я про 200 уточнил же :)

Доброго вечера. Такой вопрос: есть триггер на web-проверки, он зависит от триггеров "no ICMP ping" для проксей. Пропал пинг на прокси, триггер web-проверки, соответственно, тоже не отработал. Пинг восстановился, но свои функции прокси выполнять не начал. Триггер на web имеет вид {AFS:web.test.rspcode[{$AFS_CODE} AD check via DC2 balancer,{$AFS_CODE} AD via DC2].count(#3,200,ne)}>=3 Правильно я понимаю, что из-за того, что три не-200-х кода пришли во время работы триггера по пингу - то после восстановления этого триггера - триггер web-проверки уже и не сработает, даже если проблема с вэб продолжается?

Периоды сбора какие на оба итема?

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

2 минуты у вэб и 1 минута у icmp

и кстати, веб собирает прокси?

Да тут не флапинг... Тут что-то куда проще... 9 часов тригер не срабатывал после восстановления icmp

А веб работал?

и кстати, веб собирает прокси?

Нет, сервер

Вэб как раз и не сработал

Родительский погас?

Нет, сервер

А веб доступен то был? :)

Как веб мониторится? Айтемом или веб проверкой?

Icmp погас и восстановился. Проблема была около часа с флапингом в нескоьько минут, но вэб не сработал после окончательного восстановления icmp.

Как веб мониторится? Айтемом или веб проверкой?

Web-проверки

Icmp погас и восстановился. Проблема была около часа с флапингом в нескоьько минут, но вэб не сработал после окончательного восстановления icmp.

Данные то по вебу были?

А веб доступен то был? :)

Это один из двух балансеров.... Лежал, с...а...

Данные то по вебу были?

Нет

Нет

Вот и ответ

В триггере 3 ПОСЛЕДНИХ значения

Вот и ответ

Ммм, надо no data еще добавить

Блин

Ммм, надо no data еще добавить

?

Лошпет я

Спасибо

я сам так с УТМками мучался

или не с ними

но с чем то мучался )

Да благо - трафик на другой балансер пошёл, но все равно - проблема...

nodata нормально работают только с версии 3.0, в неподдерживаемых айтемах уведомления надо делать для версий до 3.0

nodata нормально работают только с версии 3.0, в неподдерживаемых айтемах уведомления надо делать для версий до 3.0

ЭЭэээ. Поподробнее

Я ошибся, с версии 3.2 nodata нормально работают https://www.zabbix.com/documentation/3.2/manual/appendix/triggers/functions#functions_and_unsupported_items

nodata нормально работают только с версии 3.0, в неподдерживаемых айтемах уведомления надо делать для версий до 3.0

Все, я понял что ты имел ввиду. То что для unsupported функция nodata не канала и нужно было дополнительно уведомлять об unsupported.

Ага

Ужас

Столько подводных камней

Доброго вечера. Такой вопрос: есть триггер на web-проверки, он зависит от триггеров "no ICMP ping" для проксей. Пропал пинг на прокси, триггер web-проверки, соответственно, тоже не отработал. Пинг восстановился, но свои функции прокси выполнять не начал. Триггер на web имеет вид {AFS:web.test.rspcode[{$AFS_CODE} AD check via DC2 balancer,{$AFS_CODE} AD via DC2].count(#3,200,ne)}>=3 Правильно я понимаю, что из-за того, что три не-200-х кода пришли во время работы триггера по пингу - то после восстановления этого триггера - триггер web-проверки уже и не сработает, даже если проблема с вэб продолжается?

а причём пинги к хттп?

вам все равно есть пинг или нет

вам просто веб-проверку сделать надо - курлом по сути дернуть урл

зачем тут зависимость от ицмп я так и не понял

вам все равно есть пинг или нет

Это было сделано, чтоб при падении прокси не орали все проверки на неё завязанные

вам просто веб-проверку сделать надо - курлом по сути дернуть урл

Так и сделано

зачем тут зависимость от ицмп я так и не понял

А представь за прокси десятка два триггеров

Хотя тут я так понял 1

Поэтому пинг по сути избыточен

ну вот

и даже опасен

проверять работу прокси надо, а не хождение пингов

проверять работу прокси надо, а не хождение пингов

Там оба проверяются же

пинг не нужен же

Просто если нет пинга то похрен на все остальное - орем о проблеме

пинг не нужен же

Может на будущее

@varrkan82 а вы прокси с того же дц проверяете или извне?

Извне

И да, там тригерров накручено достаточно. Тех же web

Ща на скорую 24 тригера, ну из них, пусть, штук 5 - прямые проверки. Остальные делятся между двумя балансерами

у вас же есть возможность доползти до фронтэнда в обход прокси?

Есть, но она ж клиентам не афишируется.

Только через прокси

я к тому что вам вообще зависимости не нужны

вы чётко можете поймать прокси или фронт упал

зачем городить зависимости...

2 проверки

1 на фронт