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

в 8:05, , рубрики: zabbix, автоматизация труда админа, Блог компании Zabbix, Серверное администрирование, системное администрирование, метки: , ,

Мониторинг большого количества устройств требует в помощь инструменты автоматизации. Иначе, если все делать мышкой, то можно “укликаться”, пока добавишь и настроишь все, что требовалось. К тому же, обязательно где-нибудь ошибёшься, человек не робот. Благо, в Zabbix все эти инструменты есть: это шаблоны, API, обнаружение сетевых устройств, авторегистрация Zabbix-агентов.

И вот с версии 2.0 сюда добавилось Low-Level Discovery (LLD) или низкоуровневое обнаружение. Хотелось бы рассказать что это такое.

Низкоуровневое обнаружение

image

Обнаружение сетевых устройств (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.

image

Будем мониторить состояние портов, используя SNMPv2 и счетчики, описанные в IF-MIB. LLD у нас пока нет, поэтому начнем писать обычный шаблон. Назовем его Template_IF_MIB_SNMPV2.

В шаблоне для одного порта нам нужно создать 14 элементов данных (можно конечно и меньше, но мы решим, что нам критически важно собирать практически все), а также некоторое количество триггеров, графиков. В веб-интерфейсе Zabbix на это уйдет минут 10, если активно махать мышкой и пользоваться кнопкой “Клонировать”.

image

Переведя дух, как-то продолжать не сильно хочется для других портов. Кому охота делать одно и то же 50 раз? Поэтому сразу возникают вопросы:

  • Как избежать траты времени при создании оставшихся портов (2-50)
  • Как избежать без ручного вмешательства заведомо обреченных на неудачу запросов к счетчикам с 6 по 50 порта, когда универсальный шаблон будет прикреплен к 5 портовому коммутатору
  • Как не засорять сеть опросами счетчиков портов, которые не используются

Первую проблему можно попробовать решить, например, выгрузкой шаблона в XML с последующим CTRL+C /CTRL+V в текстовом редакторе. Или даже написать небольшой внешний скрипт и генерировать XML им. Но…

Что можно сделать теперь при помощи LLD

Но с Low-Level Discovery у нас есть возможность сделать все гораздо проще. Вместо того, чтобы создавать элементы данных для одного порта, мы просто ОДИН раз создадим прототипы элементов данных, а также прототипы необходимых триггеров. Так как мы это делаем только один раз, то совсем не жалко потратить время и создать в дополнении также информативные графики, а точнее прототипы графиков.

Итак, чтобы создать в шаблоне LLD заходим в правила обнаружения:

image

Далее, нажимаем создать правило обнаружения и создаем новое правило, назовем его Network interfaces discovery:

image

Указываем все как на картинке. Некоторые поля стоит прокомментировать:

Ключ 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:

image

Описание полей:

Имя 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}, чтобы опрашивать счетчик нужного нам интерфейса.

Создадим прототипы и для остальных элементов данных, которые нам нужны для каждого интерфейса, получим примерно вот такой список:

image

создадим прототипы триггеров

image

… и прототипы графиков:

image

Прицепив наш шаблон к реальным узлам сети, через некоторое время мы получим результат. Вот так будут выглядеть последние данные для узла сети, после отработки LLD:

image

Как и предполагалось, данные собираются только для активных портов.

А вот и графики, также динамически созданные через LLD:

image

Итого

Подведем итог, что мы получили, используя 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

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js