Что делать если пропадает интренет

[mkolomiets]

Вот это могло бы быть правильным решением, НО зашаблонить то нельзя.

ИМХО, можно - ниже пример условия триггера из шаблона, в выражение которого включена проверка sla по доступности канала с роутера (реальный узел, на котором осуществляется проверка доступности внешнего канала). Делайте логическое исключение, которое отменяет взвод триггера при условии падения канала.

ЗЫ. Шлюз по умолчанию проверять действительно не самая лучшая идея, но есть узлы с постоянными ИП-шками типа гуглового ДНСа, проверяйте по ним.

ЗЫЫ. Извиняюсь соврал - задать условия триггера с указанием проверки от другого узла можно, но сохранить такой триггер заббикс не дал... Полагаю, что наверное эту проблему можно попробовать обойти с помощью проверки типа траппера или внешней проверки.

[PyKaB]

ЗЫ. Шлюз по умолчанию проверять действительно не самая лучшая идея, но есть узлы с постоянными ИП-шками типа гуглового ДНСа, проверяйте по ним.

да, Вы правы, но т.к. мониторятся узлы в дата центре, для которого есть отдельные настройки на фаерволе в офисе(где стоит заббикс). в таком случае более правильно мониторить кокретный постоянный узел в датацентре,а не гугл, т.к. иначе придется еще мониторить правила фаервола

ЗЫЫ. Извиняюсь соврал - задать условия триггера с указанием проверки от другого узла можно, но сохранить такой триггер заббикс не дал... Полагаю, что наверное эту проблему можно попробовать обойти с помощью проверки типа траппера или внешней проверки.

в этом-то и беда. я первым делом так и хотел сделать.

[mkolomiets]

Добрый день!
Попробуйте посмотреть на проблему с другой стороны - если для вас критична информация мониторинга и компания готова идти на дополнительные издержки, устраните "бутылочное горлышко" и добавьте резервный канал связи. Маршрутизацию по нескольким каналам можно реализовать, например, с помощью ВПН туннелей и скрипта перебрасывающего маршруты по событию или динамической маршрутизации типа ОСПФ.

Если агенты у вас работают в активном режиме, есть еще вариант резервирования каналов связи, правда, требующий небольших изменений в исходниках агента.
По требованиям доступности каналов связи, на площадке где размещен сервер мониторинга, мы используем два независимых внешних канала, соответственно имеем две точки входа на сервер мониторинга. В свое время я сделал маленькую доработку в коде агента, позволяющую обращаться поочередно к нескольким серверам из списка в конфиге (она обсуждалась когда то на этом форуме). В случае недоступности сервера по первому адресу из списка в пределах заданного таймаута, агент пытается подключится к следующему и тд. Таким образом у нас контролируется более 600 удаленных узлов.

Первый вариант предусматривает защиту данный передаваемых между агентом и сервером, но требует работы по настройке туннелей и маршрутизации, второй естественно таких проблем не имеет, но и данные ходят открыто через публичные каналы связи.

[mkolomiets]

да, Вы правы, но т.к. мониторятся узлы в дата центре, для которого есть отдельные настройки на фаерволе в офисе(где стоит заббикс). в таком случае более правильно мониторить кокретный постоянный узел в датацентре,а не гугл, т.к. иначе придется еще мониторить правила фаервола

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

в этом-то и беда. я первым делом так и хотел сделать.

Цитата из документации:

19.7 Простые проверки
Простая проверка обычно используются для мониторинга без использования Агента или для проверки удаленных сервисов. Обратите внимание, что zabbix агент не является необходимым для простой проверки. За обработку простых проверок отвечает zabbix сервер (осуществление внешних подключений и т.д.).

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

Вторая цитата из того же источника:

19.10 Внешние проверки
Внешние проверки это проверки выполняемые zabbix сервером путем выполнения скрипта или бинарного файла.

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