Мониторинг большого количества устройств требует в помощь инструменты автоматизации. Иначе, если все делать мышкой, то можно “укликаться”, пока добавишь и настроишь все, что требовалось. К тому же, обязательно где-нибудь ошибёшься, человек не робот. Благо, в Zabbix все эти инструменты есть: это шаблоны, API, обнаружение сетевых устройств, авторегистрация Zabbix-агентов.
И вот с версии 2.0 сюда добавилось Low-Level Discovery (LLD) или низкоуровневое обнаружение. Хотелось бы рассказать что это такое.
Низкоуровневое обнаружение
Обнаружение сетевых устройств (Network Discovery) — очень полезная штука, которая позволяет избежать ручного добавления новых узлов сети и связывания их с нужными шаблонами. При чем можно создавать довольно сложные сценарии. Например, автоматически связывать нового клиента(его CPE) базовой станции Wi-Fi c нужным шаблоном для CPE и даже автоматически добавлять этот узел в нужном месте на карте. В документации есть наглядный пример того как сетевое обнаружение настраивается.
LLD становится нужен на следующем этапе, после того как узел найден и прикреплён к шаблону. LLD позволяет находить объекты самого узла.
LLD позволяет нам автоматически создавать элементы данных, триггеры и графики для:
- файловых систем компьютера
- сетевых интерфейсов компьютера
- данных из SNMP-таблиц с одномерным индексом
Можно расширить возможности LLD путем своих собственных скриптов, главное, чтобы на выходе скрипта для Zabbix был понятный ему вывод вида JSON.
Кроме того, что LLD создает, он еще и регулярно сканирует узел сети на изменения и динамически удаляет старые элементы данных (удалили файловую систему) и добавляет новые (вставили плату расширения с дополнительными портами).
Конечно можно обойтись и без LLD, ведь во всех предыдущих версиях обходились же шаблонами. Вот только все, кто Zabbix используют, сталкивались с ситуацией, что в одном сервере логических дисков два, а в другом четыре. Что у одного коммутатора Ethernet-портов 8, а у другого из той же линейки – 24. Остается писать шаблон на 24 порта (на 4 диска), а потом, после привязки устройства вручную отключать лишние элементы данных, триггеры. Вот мы уже и “укликались”. А тут кто-то новый сервер сделал, а в нем этих дисков 8… А еще кто-то из коллег в существующем сервере еще одну партицию создал с нестандартным путем и ничего не сказал…
Как это было раньше
Чтобы понять, что нам дает LLD, нет ничего лучше наглядного примера. Вспомним, что приходилось делать с многопортовыми коммутатороми в предыдущих версиях Zabbix.
Допустим, у нас есть коммутаторы Cisco, D-Link, Zyxel и прочий “зоопарк”. С количеством портов 5/8/16/24/50.
Будем мониторить состояние портов, используя SNMPv2 и счетчики, описанные в IF-MIB. LLD у нас пока нет, поэтому начнем писать обычный шаблон. Назовем его Template_IF_MIB_SNMPV2.
В шаблоне для одного порта нам нужно создать 14 элементов данных (можно конечно и меньше, но мы решим, что нам критически важно собирать практически все), а также некоторое количество триггеров, графиков. В веб-интерфейсе Zabbix на это уйдет минут 10, если активно махать мышкой и пользоваться кнопкой “Клонировать”.
Переведя дух, как-то продолжать не сильно хочется для других портов. Кому охота делать одно и то же 50 раз? Поэтому сразу возникают вопросы:
- Как избежать траты времени при создании оставшихся портов (2-50)
- Как избежать без ручного вмешательства заведомо обреченных на неудачу запросов к счетчикам с 6 по 50 порта, когда универсальный шаблон будет прикреплен к 5 портовому коммутатору
- Как не засорять сеть опросами счетчиков портов, которые не используются
Первую проблему можно попробовать решить, например, выгрузкой шаблона в XML с последующим CTRL+C /CTRL+V в текстовом редакторе. Или даже написать небольшой внешний скрипт и генерировать XML им. Но…
Что можно сделать теперь при помощи LLD
Но с Low-Level Discovery у нас есть возможность сделать все гораздо проще. Вместо того, чтобы создавать элементы данных для одного порта, мы просто ОДИН раз создадим прототипы элементов данных, а также прототипы необходимых триггеров. Так как мы это делаем только один раз, то совсем не жалко потратить время и создать в дополнении также информативные графики, а точнее прототипы графиков.
Итак, чтобы создать в шаблоне LLD заходим в правила обнаружения:
Далее, нажимаем создать правило обнаружения и создаем новое правило, назовем его Network interfaces discovery:
Указываем все как на картинке. Некоторые поля стоит прокомментировать:
| Ключ | snmp.discovery.v2 |
| SNMP OID | OID, который будем использовать для критерия добавления интерфейса на мониторинг, в данном случае ifOperStatus. |
| SNMP community | В данном примере используется макрос {$COMMUNITY}. В этом же шаблоне прописано значение по умолчанию, {$COMMUNITY}=public. Далее, для каждого конкретного узла сети, к которому мы прикрепим данный шаблон, мы можем либо переписать значение макроса, если его snmp community будет иным, либо ничего не делать, и тогда будет использоваться прописанное в шаблоне public. Данный прием помогает избежать необходимости изменять элементы данных на уровне узла сети. |
| Фильтр | Значение специального макроса {#SNMPVALUE}, который соответствует результату запроса ifOperStatus.X к устройству, мы подвергаем очень сложному регулярному выражению: 1. Как мы знаем из IF-MIB, ifOperStatus.X = 1 соответствует up(1). Таким образом, мы будем ставить на мониторинг только те интерфейсы, которые на момент сканирования сети были в состоянии up(1). Это нас избавит от сбора счетчиков тех интерфейсов, которые не используются. Если же мы хотим добавлять на мониторинг все порты без разбора, то поле фильтр просто оставляем пустым. |
| Период сохранения потерянных ресурсов | Через сколько дней удалить сетевой интерфейс с мониторинга, если сетевой интерфейс перестал находиться повторным сканированием LLD, или статус ifOperStatus.X перестал быть up(1). В данном случае выставлен ноль – не удалять. |
Итак, мы создали правило, теперь мы должны создать прототипы элементов данных. Здесь все практически также, как при создании обычных элементов данных, но есть пара особенностей. Для примера добавим входящий трафик, ifInOctets:
Описание полей:
| Имя | if{#SNMPINDEX} ({$PORT{#SNMPINDEX}_DESC}) In. Расшифруем конструкцию. Как мы уже знаем {#SNMPINDEX} – системный макрос, который будет соответствовать индексу интерфейса в SNMP. Его мы и будем подставлять в название интерфейса, для понятных нам имен. Будет получаться: if1, if2, if3 и т.д. Второй макрос – пользовательский, {$PORT{#SNMPINDEX}_DESC}, в имя которого будет вставляться индекс интерфейса, динамически изменяя имя макроса. Он опционален, но я его использую, для того, чтобы можно было в Zabbix прописывать дополнительное описание каждого интерфейса, просто добавив на уровне узла сети макрос, например:
{$PORT1_DESC} = uplink, ISP1 |
| Ключ | В ключе должен присутствовать {#SNMPINDEX}, чтобы ключ всегда был уникален |
| SNMP OID | Точно также, мы подставляем в наш SNMP OID макрос {$SNMPINDEX}, чтобы опрашивать счетчик нужного нам интерфейса. |
Создадим прототипы и для остальных элементов данных, которые нам нужны для каждого интерфейса, получим примерно вот такой список:
создадим прототипы триггеров…
… и прототипы графиков:
Прицепив наш шаблон к реальным узлам сети, через некоторое время мы получим результат. Вот так будут выглядеть последние данные для узла сети, после отработки LLD:
Как и предполагалось, данные собираются только для активных портов.
А вот и графики, также динамически созданные через LLD:
Итого
Подведем итог, что мы получили, используя LLD в шаблоне для многопортовых коммутаторов:
- Универсальный шаблон для всех устройств, поддерживающих IF-MIB
- Не требует донастройки на уровне узла сети после добавления шаблона. Максимум, что нужно, это заполнить макросы {$COMMUNITY} (если snmp community не public), заполнить ряд макросов {$PORTx_DESC) (если хочется видеть описание порта) и активировать триггеры [NET] if{#SNMPINDEX} ({$PORT{#SNMPINDEX}_DESC}) is down для ключевых портов, для которых требуется оповещение об изменении статуса с up на down (именно поэтому эти триггеры в прототипах деактивированы, чтобы не быть засыпанным сработавшими триггерами от access портов пользователей, который то включают, то выключают свои компьютеры).
А ведь, как уже упоминалось, точно такой же фокус можно провернуть и с файловыми системами, и сетевыми интерфейсами компьютера (еще пример здесь), а также со многим другим, что хранится в SNMP. Правда, есть ограничения. Например, к сожалению, LLD не будет работать в случае, если таблица SNMP содержит несколько индексов. Есть возможность это ограничение обойти при помощи макросов, однако, это уже, как говорится, из разряда “костылей”.
Вот так. И никакой больше возни с однотипными элементами данных, триггерами, графиками. Просто настраиваем LLD и наслаждаемся плодами автоматизации. Или настраиваем LLD + сетевое обнаружение и вообще уходим в отпуск :)
Автор: alexvl
