Обнаружение

[Awalansh]

Создаю обнаружение с SNMP OID CISCO-SLB-MIB::slbServerFarmRowStatus, попутно создаю прототипы итемов. При добавлении шаблона к хосту выдает ошибку: snmp_parse_oid(): cannot parse OID "CISCO-SLB-MIB::slbServerFarmRowStatus". На самом сервере данный OID успешно парсится.
Где то натыкался что вроде бы обнаружение по SNMP работает только для OID-ов указанных в description (You may also consider using IF-MIB::ifType or IF-MIB::ifAlias for discovery depending on your filtering needs.).
Так ли это и есть ли подобное ограничение? Или же обнаружение работает для любых OID?

[Awalansh]

Разобрался, для работы парсера в версии 2.2.5 необходимо рестартануть сервис zabbix server-а. Теперь борьба с созданием прототипов итемов...

[Dron777]

Всем привет. Чтобы не засорять новыми постами форум, поднял старую тк как больше подходит под мой вопрос....


Вообщем ситуация такая, по обнаружению я получаю от хоста список запущенных сервисов(5 шт) с использумыми сервисами портами (например 11201-11205) и с этими данными могу мониторить через item.prototype память, cpu и так далее.

Есть второй хост с которого я хочу мониторить доступность этих сервисов например через net.tcp.service , но вбивать в итемы те порты что определились вручную не совсем удобно, так как сервисов/портов может быть 5 а может быть 50.

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

net.tcp.service[tcp,192.168.1.1,host1:servivce.discovery{#PORTS}]
что то в этом духе?
p.s Надеюсь понятно обяснил. Прошу помощи или совета как это реализовать

[Semiadmin]

Для этого на сервере 2 тоже д.б. LLD, с другими прототипами айтемов (net.tcp.service), но с тем же набором {#PORTS}. Как получить список портов от сервера 1? Сделать тип этого второго LLD Zabbix trapper, и тем же скриптом, которым выполняется LLD на сервере 1, заодно посылать сендером json для сервера 2.

[Kos]

Есть второй хост с которого я хочу мониторить доступность этих сервисов например через net.tcp.service , но вбивать в итемы те порты что определились вручную не совсем удобно, так как сервисов/портов может быть 5 а может быть 50.

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

Отвечая на непосредственно заданный вопрос: боюсь, что нет, нельзя. Но возможны какие-то способы, как эту проблему обойти. Один вариант предложил коллега Semiadmin, я могу предложить другой.

Если я понял правильно, то создавать item-ы на втором хосте в Вашем случае нужно только для того, чтобы с этого второго хоста мониторить доступность сервисов на первом (через ключ net.tcp.service агента, который работает на этом втором хосте). Собственно триггеры, если они таки сработают, реально указывают на проблемы с первым хостом (где должны работать сервисы), а не со вторым (откуда они проверяются).

Мой предложение сводится к тому, что на первом хосте нужно добавить (через веб-интерфейс Zabbix) ещё один интерфейс (с типом "Agent interface"), где прописать IP-адрес либо DNS-имя второго хоста (откуда должны делаться проверки). И новые item-ы (вместе с соответствующими им триггерами) создавать на этом же первом хосте, в том числе используя стандартный механизм LLD. Но для прототипов item-ов net.tcp.service использовать тип "Zabbix agent" (не "Zabbix agent (active)") и явно выбирать второй интерфейс (который реально относится к другому хосту).
В результате у Вас должен работать и механизм LLD штатным образом, и события будут относиться к тому хосту, на котором проблемы.

[Dron777]

Для этого на сервере 2 тоже д.б. Lld, с другими прототипами айтемов (net.tcp.service), но с тем же набором {#ports}. Как получить список портов от сервера 1? Сделать тип этого второго lld zabbix trapper, и тем же скриптом, которым выполняется lld на сервере 1, заодно посылать сендером json для сервера 2.

Спасибо Вам огромное.
Всё получилось. Это именно то что я хотел

[Dron777]

Отвечая на непосредственно заданный вопрос: боюсь, что нет, нельзя. Но возможны какие-то способы, как эту проблему обойти. Один вариант предложил коллега Semiadmin, я могу предложить другой.

Если я понял правильно, то создавать item-ы на втором хосте в Вашем случае нужно только для того, чтобы с этого второго хоста мониторить доступность сервисов на первом (через ключ net.tcp.service агента, который работает на этом втором хосте). Собственно триггеры, если они таки сработают, реально указывают на проблемы с первым хостом (где должны работать сервисы), а не со вторым (откуда они проверяются).

Мой предложение сводится к тому, что на первом хосте нужно добавить (через веб-интерфейс Zabbix) ещё один интерфейс (с типом "Agent interface"), где прописать IP-адрес либо DNS-имя второго хоста (откуда должны делаться проверки). И новые item-ы (вместе с соответствующими им триггерами) создавать на этом же первом хосте, в том числе используя стандартный механизм LLD. Но для прототипов item-ов net.tcp.service использовать тип "Zabbix agent" (не "Zabbix agent (active)") и явно выбирать второй интерфейс (который реально относится к другому хосту).
В результате у Вас должен работать и механизм LLD штатным образом, и события будут относиться к тому хосту, на котором проблемы.

Ваше предложение с первого раза не совсем понял) вся суть у меня заключалась в том, чтобы проверять этот сервис на живучесть. На первом сервере он мог просто зависнуть и не отвечать на запросы с других серверов. Хотя по проверкам он в UP. Запрос на порт с определенным ключем идет и если сервис отправил в ответ "i`m alive" значит все ок.

На данный момент, то что получаю мне вполне достаточно

[Kos]

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

Наверное, я слишком коряво написал.
Основная мысль такая: сделать так, чтобы айтемы, необходимые для этих проверок, были "привязаны" не к тому объекту "хост" в Zabbix-е, с которого эти проверки делаются, а к тому, кого они проверяют. Сами проверки выполняются точно так же (с физически другой машины), разница лишь в том, как это красивей организовать. Мне казалось, что в моём варианте это удобнее.
Впрочем, главное - чтоб работало, и результат бы устраивал :-)

[Semiadmin]

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