Мониторинг одного узла сети с разных серв

[fenderas]

Добрый день.

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

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

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

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

[Jimson]

Интересная задачка. Походу не получится красиво такое реализовать, только создавать кучу фейковых хостов и затем через вычисляемые элементы объединять данные в один хост.

У меня тоже были проблемы с тем что опция "через прокси" это опция хоста, а не интерфейса.

[fenderas]

Есть идея писать скрипт, для удаленных точек мониторинга.
С помощью скрипта или API, точка с основного сервера заббикс будет получать список узлов на мониторинг.
К примеру, пинговать узлы сети и с помощью zabbix_sender отправлять данные на сервер Zabbix, где как траппер уже будет заведен элемент данных для каждого узла сети.

Но были сомнения, что такой функции все же нет в основном заббикс или же есть готовые примеры.

[Jimson]

Если допустимо запускать там скрипт, то лучше уж запустить агента.
Но есть другой момент, а вдруг с хоста не будет доступен сервер?
Я полностью не знаю схему и задачу, но пинговать хост B с хоста A не тоже самое что пинг хоста A с хоста B, ну там асимметрия роутинга, наты и прочее.

P.S. И я не стал бы завязывать самописные пуллеры на API, так как API это frontend (apache, php, etc), недоступность фронтэнда не должна мешать работе пуллера. Так что если агент таки не устраивает, то скрипт придется делать универсальным - пингует все возможные точки и отсылает все данные, а сервер уже разберется, если элемента данных нет, то ничего страшного не произойдет, данные по этому элементу просто будут игнорироваться.

[aib]

Не совсем понятно, как вы себе представляете этот мониторинг.

Давайте детально разбираться:
- Допустим, у вас есть 5 узлов сети (Москва, Владивосток, Киев, Минск, Лондон)
- Допустим, вы хотите проверять доступность каждого узла с 4 точек (из Берлина, из Парижа, из Пекина, из Токио)

Как должно выглядеть описание Хоста?
Какие элементы вы собираетесь включать?
Какие триггеры должны существовать и срабатывать?
Как они должны зависеть друг от друга?

В моем гипотетическом описании присутствуют 5 хостов (Москва, Владивосток, Киев, Минск, Лондон) и каждый из них хранит по 4*3=12 метрик (4 точки по 3 метрики {доступен; потери; время отклика})

Тогда - гипотетически - ничто не мешает мне создать 4 скрипта на каждой "точке", которые будут (по команде с сервера) опрашивать 5 узлов и посылать данные обратно на Zabbix Server, используя zabbix_send, заполняя соответствующие Item's.

А вы как думаете?

[Jimson]

А вы как думаете?

Есть задача мониторить доступность (к примеру по пингу) узлов сети без установки агента на узел

ну как то так и думаем

[fenderas]

Тогда - гипотетически - ничто не мешает мне создать 4 скрипта на каждой "точке", которые будут (по команде с сервера) опрашивать 5 узлов и посылать данные обратно на Zabbix Server, используя zabbix_send, заполняя соответствующие Item's.
А вы как думаете?

Это и придеться делать. Только придеться добавить еще получение списка узлов сети с основного сервера Zabbix (ока предполагаю с помощью API), так как узлы сети буду периодически меняться и нет желания каждый раз лазить на все точки и менять скрипт ручками.