Автоматизируем мониторинг: низкоуровневое обнаружение

[sha1dy]

Присоединяюсь к просьбе написать про JMX и JVM мониторинг,

[alexvl]

Поддержка шаблонов для Web мониторинга уже реализована, но будет доступна только в следующей версии — Zabbix 2.2. Пока существует только шестая альфа доступная для предварительного тестирования.

[madnut]

Когда-то писал простой скрипт создания кастомного LLD ответа для Zabbix-агента под винду — pastebin.com/gFXdhj5Y
Использовать в агенте можно создав UserParameter. Пример работы:

$services = Get-Service | Select-Object -Property «Name», «Status»
New-JsonForZabbix -Format $true -Objects $services;

Создаст LLD ответ со всеми сервисами в системе с макросов, которые совпадают с именами выбранных NoteProperty — {#Name} и {#Status} Сразу отвечу за плохой код — это должно было работать под PS 2.0 и .NET 2.0, где не было штатных средств работы с json, а таскать за собой dll'ку очень не хотелось.

[k0ldbl00d]

Если бы оно еще умело строить карту с указанием соединений между устройствами, как это делает NetXMS…

[sn00p]

Оно умеет, если использовать ZabbixAPI.

map.createSelements, map.updateSelements, map.deleteSelements

[sas1024]

LLD — совершенно шикарная штука!
Вот жаль только, что Zabbix не различает длинные динамические индексы (например, .40.112.104.121.115.105.99.97.108.32.109.101.109. 111.114.121.32.54.102.50.56.48.49.102.52.54.48.49.102.50.48.49.102.52.53.48.49.102.53.99.48)

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

Искренне не понимаю, почему этот патч не внесут в официальную ветку Zabbix.

[alexvl]

Дело в том, что мы стараемся не вносить никаких изменений в стабильные версии Заббикса за исключением исправления багов. Бывают редкие исключения. Поддержка длинных динамических индексов уже реализована и будет доступна в 2.2.

[AwesomeBanana]

Теперь половину моих скриптов можно будет выкинуть — их функционал заменен LLD :))

Я правильно понимаю что критерием уникальности обнаруженного интфейса является snmp interface index. Т.е. если я добавлю новую лайнкарту и у меня все индексы «поплывут» то LLD сотоворить что-то плохое?

[sasha5]

«Из коробки» в шаблонах Zabbix используются индексы как критерий уникальности.

Но если на устройстве индексы не статичны, то нужно эти шаблоны подправить используя динамические индексы — в правиле обнаружения нужно указать OID, возвращающее уникальное значения (например ifDescr), а в прототипах элементов использовать не индекс "{#SNMPINDEX}", а значение "{#SNMPVALUE}" (например ifInOctets[index,ifDescr,{#SNMPVALUE}])

[AwesomeBanana]

Я всё это прекрасно знаю. Вопрос в том, можно ли эти динамические индексы использовать в LLD как критерий уникальности?

[sasha5]

Да, их даже нужно использовать в таких случаях :)

[m0ps]

Было бы очень хорошо если бы вы выложили готовый шаблон, что бы народу вручную не набивать его.

[alexvl]

Шаблоны для низкоуровневого обнаружения включены в Zabbix 2.0.x. Можно скачать с Zabbix wiki.

[soulruins]

Большое спасибо за статью. Благодаря ей наконец-то нашел время для создания собственных LLD шаблонов.

Подскажите, Вы в статье упоминаете про макрос {$PORT{#SNMPINDEX}_DESC}. Вы самостоятельно прописываете его значение в параметрах узла или Zabbix заполняет его динамически? Например у меня есть данные порта ifAlias, могу ли я создать конструкцию вроде этой: "if.{#SNMPINDEX} {{HOST:HOST}:ifAlias.["{#SNMPINDEX}"].last(0)} on {HOST.NAME} is down" для более наглядного описания порта в триггере?

[soulruins]

И ещё вопрос:

Если я использую правило обнаружения с фильтром, то в случае, если порт перешел в состояние "down (2)" и в это время отработало это правило, то порт встаёт в очередь на удаление потерянных ресурсов. Всё бы ничего, но удаляется триггер, который после восстановления порта уже имеет статус «Disabled» (так как мы выше отключили их по умолчанию). Есть способ побороть эту проблему?

[sasha5]

Это баг, который должен быть исправлен. Его можно видеть здесь: ZBX-6315

[sasha5]

Да, Zabbix позволяет делать такие конструкции в имени триггера. При создании триггера на основе такого прототипа получится триггер с промерно таким названием: «if.1 {{HOST.HOST}:ifAlias.[»1"].last(0)} on {HOST.NAME} is down". В секции мониторинга остальные макросы тоже будут раскрыты.

[soulruins]

У меня на выходе получается if.10146 {{HOST:HOST}:ifAlias.["10146"].last(0)} is down on CISCO1. В чём может быть проблема?

[sasha5]

У вас опечатка. Замените {HOST:HOST} на {HOST.HOST}.

[soulruins]

Ох, чёрт. Тем не менее, теперь на выходе:

if.10146 {CISCO1:ifAlias.["10146"].last(0)} is down on CISCO1

а хотелось бы видеть алиас интерфейса.

[sasha5]

Сразу не осилил. Zabbix не подерживает составные макросы "{host:key.func()}" в имени триггера.

Если вы хотите увидеть алиас интерфейса, то лучше будет сделать так:
* в правило обнаружения в поле OID вписать ifAlias
* а название прототипа триггера сделать таким: "if.{#SNMPINDEX} {#SNMPVALUE} on {HOST.NAME} is down"

[soulruins]

Ну да, простите, долго не мог сообразить, как понятнее написать. Жаль, что не поддерживает. И в 2.2 не ожидается?

Идея с правилом обнаружения хорошая, вот только с фильтрацией по ifOperStatus очень уж печально тогда. Ладно, спасибо. Будем думать.

[sasha5]

В 2.2 не ожидается.

[soulruins]

Т.к. ifAlias = TO CISCO2, я надеялся увидеть нечто вроде if.10146 (TO CISCO2) is down on CISCO1.