Интерактивная карта zabbix

Время на прочтение

Количество свободно-распространяемого ПО растёт с каждым годом. Собрать собственную функциональную систему мониторинга из подручных средств становится всё проще. Сегодня расскажу о способах реализации функционала коммерческих систем мониторинга средствами бесплатных инструментов. Будем делать тепловую карту бизнес-сервисов, географическую карту для распределенных объектов, интеграцию с Zabbix и интерфейс управления этой конструкцией. При желании вы сможете повторить все эти шаги самостоятельно и внедрить у себя подобное решение. Под катом описание концепта.

Знакомьтесь — это «Мантра» (на месте надписи Mantra может быть всё что угодно). Буду рассказывать отдельно о каждом ингредиенте. Начнём с интерфейса.

Хабр, конечно, не очень-то подходящая для романтики площадка, но мы не можем не признаться в любви к Zabbix. В очень многих наших проектах по мониторингу мы использовали Zabbix и очень ценим стройность и логичность этой системы. Да, здесь нет модной кластеризации событий и машинного обучения (и некоторых других фичей, доступных из коробки в коммерческих системах), но уже того что есть, определенно достаточно для внутреннего спокойствия за продуктивные системы.

В этой статье расскажем о паре инструментов для расширения функционала Zabbix: CMDB на базе бесплатного решения iTop и карте объектов на базе OpenStreetMap (OSM). А в конце статьи ваш ждет ссылка на репозиторий с кодом фронтовой части для OSM.

Общий концепт разберем на примере условного проекта по мониторингу розничной сети аптек. На скриншоте ниже наш демо-стенд, но похожую концепцию мы используем в боевой среде. Переход с объекта возможен как на вложенную карту так и на карточку объекта в CMDB.

Каждая аптека – это набор следующего оборудования: рабочая станция (или несколько рабочих станций), роутер, IP-камеры, принтер и другая периферия. На рабочих станциях установлены агенты Zabbix. С рабочей станции выполняется проверка через ping периферийного оборудования. Аналогичным образом, на карте объектов, с принтера можно перейти на его карточку в CMDB и посмотреть инвентаризационные данные: модель, дату поставки, ответственного и т.д. Так выглядит вложенная карта.

Здесь нужно сделать небольшое отступление. Вы можете спросить, а почему бы не использовать внутренний инвентарь Zabbix? В некоторых случаях его бывает достаточно, но мы рекомендуем клиентам всё-таки использовать внешнюю CMDB (iTop не единственный вариант, но эта система достаточно функциональна при своей бесплатности). Это удобное централизованное хранилище, где можно формировать отчеты и следить за актуальностью данных (на самом деле не только это).

На скриншоте ниже — пример шаблона для наполнения инвентаря Zabbix из iTop. Все эти данные потом, разумеется, потом можно использовать в тексте уведомлений, что позволит иметь актуальную информацию сразу же при возникновении аварийной ситуации.

На скриншоте ниже — карточка расположения. Здесь мы можем увидеть перечень всего ИТ-оборудования, которое находится в аптеке. На вкладке История можно отслеживать изменения в составе оборудования.

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

На этой странице наш общий подход к интеграции Zabbix с iTop.

Теперь перейдем к картографическому сервису. Мы считаем его удобным инструментом для просмотра статусов распределенных объектов на телевизоре в кабинете с большим кожаным креслом.

При нажатии на аварийную метку появляется всплывающая подсказка. С нее можно перейти на карточку объекта в CMDB либо в Zabbix. При приближении и отдалении метки объединяются в кластеры с цветом наихудшего статуса.

Географическая карта реализована с использованием js-библиотеки leaflet и плагина для кластеризации объектов. На каждую метку добавляются события из системы мониторинга и ссылка на соответствующий объект в CMDB. Статус кластеров определяется по наихудшему событию для вложенных меток. При необходимости, можно интегрировать карту с любой системой мониторинга с открытым API.

Вы можете посмотреть код фронтальной части в репозитории проекта. Контрибуции приветствуются.

Если вам интересен наш подход, на этой странице можно оставить заявку на демонстрацию. Расскажем подробнее и покажем.

А еще можно почитать:

Zabbix под замком: включаем опции безопасности компонентов Zabbix для доступа изнутри и снаружи

Мониторинг принтеров — дело благородное

Структурированная система мониторинга на бесплатных системах

Управляете сетью большего размера, чем локалхост? Не управляете, но хотите научиться? Приглашаем вас на курс «Linux. Уровень 5. Zabbix. Мониторинг IT инфраструктуры предприятия». На бесплатном семинаре учебного центра «Специалист» при МГТУ имени Баумана вы узнаете, как научить Zabbix мониторить сеть автоматически: находить существующие и добавлять новые узлы, рисовать и обновлять топологию.

Проведёт семинар ведущий преподаватель центра «Специалист» при МГТУ имени Баумана, главный системный администратор сети МГТУ им. Н. Э. Баумана Вячеслав Александрович Лохтуров. Записывайтесь (или смотрите в записи) наши бесплатные семинары.

Всем привет! Зовут меня Лохтуров Вячеслав Александрович. Я работаю инженером в МГТУ имени Баумана. Со дня окончания его в 1997 году работаю инженером. Параллельно преподаю в учебном центре № 1 «Специалист» – компании, которая является дружественной МГТУ. Там работает много других преподавателей, сотрудников.

С точки зрения методического материала и преподавания я использую раздел «Материалы по методике чтения курсов»:

И есть раздел с вебинарами. По каждому из прочитанных мною здесь есть запись:

У нас имеется небольшая википедия, которая используется для работы. И среди элементов этой википедии есть раздел, посвященный коммутации сети. Доступ к этой википедии ещё закрыт небольшим VPN’ом:

Я сейчас покажу, как выглядит топология сети у нас в университете. Это стоит того, чтобы увидеть; а потом сравним с тем, что получится в результате:

Мне кажется, всё ясно: все свичи и путь их к корневому коммутатору; если что-то пропало – мы быстро из этого текстового файла восстановим. Строится топология сети еженочно. Всё хорошо, но не зрелищно, конечно. Продать это сложно. Поэтому у нас в университете такая схема.

Топология сети нужна, когда какой-то коммутатор исчез. Чтобы понять, куда он был подключен

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

В ней рассказывается, что есть какой-то чудесный скрипт, написанный на моём бывшем любимом языке Perl, которые опрашивает сетевое оборудование, делает из этого какие-то выводы и каким-то чудесным образом скармливает результаты «Заббиксу». Но Perl мы не будем использовать, а будем использовать кое-что другое.

Прощаемся с тем, что у нас есть. Перейдём к практике.

Я буду счастлив, если вы сможете всё это воспроизвести в домашних условиях и постарался подготовить для этого всё, что только можно. После вебинара вы захотите всё повторить и начнёте с того, что вам потребуется развернуть «Заббикс», виртуальную машину, сеть. Как же это делать?

Дома вы наберёте команду ipconfig и увидите, что у вас дома такая IP-сеть (может, другая, но чаще всего такая):

Где взять машину? Ничего не мешает взять дистрибутив Linux. Я – большой фанат этого дистрибутива. Не будем разводить холивары – я его люблю, я его выбираю, я его использую на курсах. Можете с этого сайта взять и установить:

Чтобы нам 45 минут не тратить на установку Debian, я возьму готовый предустановленный образ. Кому надо – пишите на почту, пришлю вам этот образ, хотя ничего особенно выдающегося в нём нет (просто чтобы не тратить время на инсталляцию):

Развёртывание стенда

Там есть история про команду ipconfig:

А дальше, когда машина развернётся:

Можно дать имя в настройках, дадим ей побольше оперативной памяти:

Виртуализации разные бывают – VirtualBox хорош для домашнего использования. На предприятии мы с товарищами используем VSphere (очень довольны продуктом от VMware), но на курсах «Виртуалбокса» хватает более чем.

Раз мы говорим, что эта машина будет подключена к нашей сети, мы сможем с ней работать – она должна быть соединена мостом с физическим адаптером. Mac-адрес перегенерирую. Запускаю нашу виртуальную машину:

Развёртывание Zabbix

В образе сразу заведён пароль этого пользователя (root) – никогда его не используйте на практике! Только ради экономии времени я пользуюсь привилегированной учётной записью:

В пособии перечислены файлы, которые надо отредактировать.

Далее даю название нашей машине (сервер мониторинга Zabbix):

Меняем адрес на 100-й и название нашего выдуманного домена (у каждого слушателя на наших курсах он свой, индивидуальный, как и сеть с доменом):

Что ещё осталось? Resolv.conf (клиент DNS):

Corp1.un будет пристыковываться к коротким именам, а в качестве DNS-сервера работает, как правило, ваш WI-FI-роутер:

Что осталось? Самый главный, большой файл – network/interfaces. Здесь шаблон для разных курсов, много интерфейсов:

Но у нашей машины будет один интерфейс. Она будет сервером мониторинга с 100-м адресом и ходить в интернет через 1-й:

Пожалуй, необязательно, но быстрее для применения всех файлов – перезагрузить машину.

Установка и запуск сервиса в Debian

«Заббикc» можно устанавливать различными способами. По «Заббиксу» имеется прекрасный сайт с документацией (кстати, на русском языке активный раздел поддерживается). Соответственно, здесь предлагаются разные варианты. Я являюсь большим сторонником установки ПО из штатного репозитория. Не случайно именно поэтому я выбрал «Дебиан»:

Кстати, если всё сделано хорошо, то сейчас я должен иметь возможность подключиться к своей системе. Давайте попробуем сделать. Беру любимый клиент SSH и подключаюсь к системе 192.168.1.100:

Опять же, не очень правильно, что здесь разрешён вход пользователю root:

Никогда так не делайте на предприятии! Здесь – только экономия времени.

Теперь мы должны установить «Заббикс». Будучи большим любителем и сторонником использования базового ПО и противником подключения всяких сторонних репозиториев, я буду ставить ту версию, которая есть в данном Debian. Опять же, спасибо авторам «Дебиана» – достаточно набрать установку такого пакета:

Вспомнил ещё одну вещь! Мы только что систему установили – надо синхронизировать репозиторий (apt update):

Таким образом, достаточно набрать команду установки zabbix-server с поддержкой базы данных (БД) своей информации в SQL, как будет установлено достаточно много компонентов (пара минут должна уйти на инсталляцию):

Из чего состоит «Заббикс»

«Заббикс» состоит из следующих компонентов:

Для того чтобы мы с вами могли работать c «Заббиксом», используется так называемый frontend. Frontend Zabbix – это приложение, написанное, наверное, на PHP (может, не всё, но большая часть). Соответственно, само приложение используется веб-сервер. Пока ставится только эта часть (сейчас мы дождёмся её установки):

Окончена. Теперь, поскольку «Заббикс» использует базу данных, нам надо её создать, следуя документации. Чтобы создать БД, я буду использовать простой скрипт:

Теперь, используя этот скрипт, создаю базу данных:

И заполняю эту БД метаданными. Имеются несколько файлов, описывающих, какие таблицы должны, какие атрибуты, параметры и прочее (всё это делается, опять же, согласно документации):

То есть сейчас мы в MySQL загоняем метаданные, которые «Заббикс» будет использовать для хранения конфигурации и результатов:

Не буду тратить время на то, чтобы глянуть, что он там создаст (будет огромное количество таблиц создано). « Заббикс» как продукт развивается уже более десяти лет и постоянно стремится стать всё лучше и лучше, поэтому структура данных там довольно увесистая. Но всё это «под капотом». Мы же, как администраторы, будем работать с внешним фронтенд-приложением, с которым всё будет просто, понятно и доступно.

Согласно документации, почему-то несколько файлов. Но раз они так сделали – значит, они знают, что нужно! База данных готова:

Теперь, согласно документации, надо вот этому компоненту:

В самый конец файла вставляем:

Здесь у нас описывается, что сервер БД находится здесь под нашей учёткой:

«Дебиан»-пакет под «Заббикс» не подразумевает автостарт. Перед вами – команда великого и ужасного SystemD, о которой есть великое множество холиваров:

Она делает запуск «Заббикса» автоматическим после загрузки сервера. Запускаем «Заббикс:

Эти два компонента запущены:

Развёртывание Zabbix. Локализация временной зоны

Я развернул образ, а в нём – неправильное время:

Дата у нас правильная. У нас временная зона неправильная, поэтому вот таким махом я её поправил:

Приступаем к frontend. Установка и запуск web-интерфейса

В Debian стоит установить такой пакет (после того, как будет установлен веб-сервер Apache):

Будут установлены PHP, библиотека для связи программ, написанных на PHP, с MySQL. В общем, запускаю:

Никаких действий выполнять долго не нужно, всё будет сделано автоматически:

Сейчас мы ставим вот этот компонент – фронтенд «Заббикса»; веб-сервер, и будем ему объяснять, что ему надо работать с «Заббикс»-сервером и СУБД:

Через веб-сервер мы будем управлять «Заббиксом» и через него же будем смотреть, что же он там намониторил.

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

В этом файле ↑ инициализации PHP необходимо это ↓ сделать:

Не буду углубляться, как веб-приложение настраивается в «Дебиане». Достаточно подключить конфигурацию, которая досталась из пакета «Заббикса» и перезагрузить веб-сервер «Апач»:

Подключаемся к frontend для настройки Zabbix

Почти готовы подключиться к фронтенду. Осталось только объяснить ему, где находится сервер баз данных. Здесь два варианта, и мы сделаем через Wizard. Для него потребуется файл, куда будут конфигурации записаны:

А веб-сервер должен обладать правами на запись в этот файл:

У нас появляется Wizard «Заббикса», где я буду нажимать Next, поскольку большинство его уже устанавливали:

Разворачиваем облако коммутаторов

Но нашем вебинаре никаких «Заббикс»-агентов не будет. Это слишком просто и неинтересно! У нас с вами будет мониторинг распределённой сети, цепочек коммутаторов связи, поэтому нам понадобится эта цепочка коммутаторов. Где же их взять?

Я посоветовал использовать виртуализацию Virtual Box. Он позволяет эмулировать PC (компьютеры), а сейчас познакомлю вас с другим эмулятором, тоже используемый на наших курсах. Замечательный продукт – называется Graphical Network Simulator (GNS):

Этот эмулятор позволяет эмулировать оборудование Cisco. Здесь мы и развернём наше облако коммутаторов. Потребуется снова придумать название проекта (сохраним конфигурацию, вдруг завтра понадобится):

Если вы дома хотите научиться работать с оборудованием Cisco, поставьте себе этот GNS и сделайте так, как мы делаем на семинаре, а именно – развернём сейчас облако коммутаторов. Проблема в том, что в GNS нет коммутаторов (их эмуляция здесь отсутствует) – только эмуляция роутеров. Поэтому нам придётся положить роутер (перетащить курсором мыши):

И как-то сделать, чтобы он был коммутатором. Как сделать в GNS эмуляцию коммутаторов? Надо взять роутер 36-й серии. Можно назвать его коммутатором (клик правой кнопкой по коммутатору):

Можно нарисовать коммутатор:

Похож? Но настоящим коммутатором он станет только тогда, когда вы добавите туда вот такую плату:

В этой линейке роутеров Cisco можно ставить 16-портовую Ethernet-плату. И для большого количества лабораторных работ, связанных с коммутаторами, эта плата вполне годится.
Коммутаторов у нас должно быть облако, поэтому сейчас я это облако сделаю (меняю название, картинку и вставляю плату). Начнём с трёх коммутаторов, а если успеем, то и четвёртый добавим:

Соединять будем, особо не целясь не куда. У нас же топология должна будет автоматически построена:

Теперь я это дело запускаю:

Это наша Windows-система (Windows 7) и Debian:

Здесь виртуализация GNS3 и облако коммутаторов:

Теперь понятно, что происходит: в рамках одной машины используется две системы виртуализации. Виртуализация PC-систем (справа) и виртуализация Cisco-систем (слева):

Надо сделать так, что сервер мог мониторить оборудование:

А чтобы он мог его мониторить, это оборудование должно иметь адреса в этой же сети:

Поэтому, долго не думая, я решил этим коммутаторам дать адреса (точки 101, 102, 103 для 1-го, 2-го и 3-го коммутаторов соответственно). 100-й – наш Linux:

Настроить это можно следующим образом: пойти на авторизованный курс Cisco и вам за недорого это расскажут.

Два раза кликните по нужному коммутатору (сейчас – switch1):

Настроили switch1. Теперь – конфигурация для второго свича: называется switch2, IP – 102:

Соответственно поступаем с третьим коммутатором.

Ну что, будет очень круто, если с нашего Windows-компьютера будет доступен не только наш сервер, но и то, что мы сейчас настроили:

Ан нет, не ответит, сколько бы я не ждал! Связи не хватает между нашим компьютером и GNS. G NS сам по себе, так что не хватает ещё одного элемента:

Подключаем Cloud

Для того чтобы эти коммутаторы стали доступны, необходимо использовать объект Cloud:

Сегодня Cloud использует его в совершенно другом смысле. Авторы GNS как интернет-сервис провайдера. В настройках этого объекта я могу его подключить к своей сетевой карте:

Выглядит она страшно, но это та самая сетевая карта:

Cloud я положил. Теперь нужно соединить один из коммутаторов с Cloud (только тогда связь может появиться):

Подозреваю, что быстрее в нашем случае перезагрузить коммутатор, чтобы всё встало. Единственно, хочу убедиться, что его конфигурация сохранена. К слову, внутри коммутаторов ping уже должен идти:

Настоящий Cisco! Первый пакет пропадает, остальное всё есть:

На самом деле здесь не натуральная эмуляция используется, а iOS. Поэтому я останавливаю 1-й коммутатор и снова запускаю:

Пошло! Видите, связь появилась:

Опыт показал: для того чтобы связь была между всеми тремя элементами (с Windows – на Linux, с Linux – на GNS), необходимо зайти в настройки сетевой карты и выбрать странную опцию – «Неразборчивый режим» («Разрешить всё»):

Приходите на «Виртуализацию»! Этот неразборчивый режим есть во всех решениях (и в «Сфере» тоже). Связан он с прохождением Ethernet-пакетов, mac-адресов и так далее. Приходите на курс по виртуализации, подробности – там.

Запускаем снова нашу систему в надежде на то, что коннективность восстановится:

Только теперь можно будет настраивать мониторинг наших коммутаторов из «Заббикса». Давайте посмотрим, как это произойдёт:

Заложен фундамент. Если у нас сейчас будет связь, то будет всё готово. В «Заббиксе» уйма «Цисок», хитро соединённых друг с другом – можно начинать мониторить. Подключаемся к пользователю root с паролем и проверяем пинг:

Как администратор местного DNS я ещё сделал возможность отправлять по именам пинга.

Как же Zabbix может мониторить оборудование Cisco?

На оборудование Cisco нельзя установить агент. Многие из вас знают, что оборудование Cisco прекрасно мониторится по протоколу SNMP. Сейчас мы подготовим почву для этого.

Сейчас мы с вами подготовим почву для этого. Чтобы мониторить оборудование по протоколу SNMP надо, во-первых, на сам сервер мониторинга установить поддержку SNMP:

В «Заббикс» эта поддержка не входит, он использует внешние библиотеки, входящие в эти пакеты:

Не буду вам рассказать, что такое management information base – приходите на курсы по взаимодействию Lunux и Cisco, там об этом подробно рассказывается. А сейчас мы просто ставим на «Линукс» пакеты, необходимые для мониторинга:

И ставим на наши Cisco элементы конфигурации, которые позволят мониторить их в свою очередь.

Здесь просто запускается SNMP-сервер с таким паролем:

И делаем это на всех трёх наших коммутаторах:

После этих действий мы проверим, может ли наш сервер мониторинга обратиться к оборудованию Cisco (к любому из этих коммутаторов) по протоколу SNMP и, например, что-нибудь узнать. Здесь есть тестовые варианты:

Можно опрашивать наши коммутаторы, используя так называемые OID’ы (object-идентификаторы). Здесь мы опрашиваем свич (запрашиваем значения параметра switch1):

И мы видим, что этот Oid ссылается на имя коммутатора, то есть мы можем с каждого коммутатора вытянуть его имя (для топологии пригодится, даже очень):

А можно использовать более человеческие, текстовые – sysName запрашиваем у свича (то же самое можно у switch2 спросить и т. д.):

Установка SNMP-консоли

Ещё одно действие неочевидное:

Соответственно, «Заббикс»-сервер надо перезагрузить, потому что мы установили библиотеки, которые будут им использоваться:

Но мы не для того здесь собрались. Давайте попробуем заставить «Заббикс» автоматически найти все наши коммутаторы. У нас с вами их три, а в Бауманке их больше ста (120, кажется). 100 коммутаторов добавлять было бы не так весело, поэтому – бонус: мы с вами посмотрим, как «Заббикс» найдёт наши коммутаторы.

Автоматическое добавление устройств в Zabbix

Страница «Автоматическое добавление устройств в Zabbix»:

Чтобы он это делал, мы пойдём в раздел «Конфигурация» (подраздел Discovery) и не будем там создавать новое правило, а будем использовать существующее:

Этого недостаточно для того, чтобы наши устройства появились в этом списке:

Необходимо настроить действия. Мы создадим новое (назову его, копируя из методички):

Условие: запрос должен вернуть информацию о том, что это – коммутатор. По «счастливой случайности», у нас все коммутаторы называются switch (switch1, switch2, switch3), поэтому Received value должно быть похоже (like) на switch:

Всё это есть в методичке. Осталось указать, что с этим делать – «Операции»:

В первую очередь необходимо добавить в какую-нибудь группу. Я буду использовать готовую группу Discovered hosts:

Следующее, самое главное, мы должны объяснить, что мониторить на этом оборудовании. В данном случае мы будем использовать готовый шаблон, который пригоден для большого количества разнообразных SNMP-устройств:

Если всё сделано верно, то через какое-то время у нас в «Заббиксе» чудесным образом должно появиться 3 коммутатора. Ждём. Появятся они в разделе Hosts. Связь есть (проверили на всякий случай):

Было бы у нас 100 коммутаторов – появилось бы 100 коммутаторов. Теперь можно говорить о главной теме – автоматическое построение топологии сети.

Создание карты сети

В «Заббиксе» в разделе «Мониторинг» – подраздел «Карты сети». Можно создать свою собственную карту с любым произвольным именем (назову, как в методичке – Switches map):

В эту карту можно добавлять устройства:

Нам предстоит довольно занудная операция по добавлению всей нашей сотни коммутаторов сюда:

Добавляю новый элемент и говорю системе, что это на самом деле хост, который ты мониторишь; хост – switch1:

Я сейчас добавлю все 3 коммутатора вручную, но обещаю, что линии связи между ними я рисовать не буду. Вы добавляете 101-й коммутатор, у нас автоматом добавляется в «Заббикс» – извольте нарисовать его в карте ручками. Неприятный момент, но имеет место быть. Простого решения этой задачи нет, за 45 минут уж точно. И то, что у нас получится, мне кажется интересным.

Быстро добавляю 3 коммутатора:

Я сказал, что линии не буду добавлять? Буду, но только для того, чтобы потом нам можно было понять, как их рисовать. Я соединю два этих коммутатора (у нас 1-й с 3-м не соединён):

Я их соединю (выделяются свич1 и свич3):

Наша система должна будет это дело исправить:

Важно не забыть сохранить результат:

Как нам построить топологию? Настройка автоматического создания и обновления линий связи

Чтобы топология строилась автоматически, нам необходимо получать информацию о ней автоматически. В университете мы используем оборудование Cisco, поэтому давно полюбили протокол, который называется Cisco discovery protocol – достаточно набрать на любом устройстве show cdp neighbors, и он подскажет, что к 5-му интерфейсу подключён коммутатор switch1:

Альтернатива cdp – lldp (у нас есть сегмент коммутаторов «страшной» компании Nortel – там lldp). Видите, тут два коммутатора:

Сервер «Заббикс» должен как-то вытаскивать эту информацию (её я вижу на самой Cisco). Способов много. Один из самых быстрых, но стрёмных – использовать протокол RSH. Весьма дремучий протокол, и я о нём знаю только в силу своего возраста:

Нормальные люди RSH не знают, зато его можно быстро использовать, чтобы удалённо что-то с Cisco делать. Или, если речь идёт о какой-то менеджмент-сети, где никого постороннего нет, то можно и в продакшне использовать. Впрочем, точки безопасности – всё равно полный швах!

Соответственно должно появиться на свиче2:

Подключение с сервера мониторинга

Далее. Пишут мне менеджеры: «Вячеслав, поступил запрос от слушателя. Хочет углублённо пройти Bash, Csh, Sed и Awk». Это дремучие Unix-утилиты, которые в лохматом году люди знали. Вот сейчас будет немного дремучего Unix. Мы установим этот пакет (нам надо отформатировать вывод, чтобы он был лучше структурирован):

А целиком команда будет выглядеть следующим образом:

Не буду рассказывать, чем код возврата в Dos отличается от Unix. Далее отфильтрую только строки, в которых содержится switch, удалю лишние пробелы и вырежу через пробелы нужные поля:

Давайте посмотрим результат, и вы увидите, чем он отличается от предыдущего. Ещё немного «магии» Unix. Обработка превращения информации в структурированную (на примере switch2). Вместо этой неструктурированной информации (куча пробелов, какие-то непонятные ключи):

На выходе появляется:

Коммутатор мы должны только добавить физически, а он автоматом должен обнаружиться «Заббиксом». База данных коммутаторов у нас уже есть в «Заббиксе». Как приложению вытащить информацию о коммутаторах из «Заббикса»?

Zabbix API

JSON – это формат, используемый для обмена данных с веб-сервером, и утилита cURL – одна из тех удобных утилит, которые позволяют направить любой запрос к веб-серверу:

Не буду углублённо рассказывать, что такое POST-запрос, GET-запрос, а скажу кратко. В «Заббиксе», который работает здесь:

Входит это приложение:

Которое готово воспринять вот такой запрос в «страшных» фигурных скобках (это и есть JSON):

В этом запросе указывается, что я хочу сделать с «Заббиксом», указываются параметры:

Такой JSON-запрос сейчас нам вернёт JSON-ответ:

И в этом JSON-ответе будет такая строка:

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

Работа с объектами host

Вспоминаем, для чего мы начали JSON изучать: мы хотим из «Заббикса вытащить базу данных коммутаторов. Какие коммутаторы опрашивать? Давайте это вытащим!

Познакомьтесь: в «Заббикс»-API входит, среди прочего, метод host.get:

Host – это наши хосты. Get – это «дай». Далее я указываю: дай мне информацию о хостах!

В параметрах говорю: выводи всё, что знаешь о хостах:

Но должен сопроводить свой запрос этой строкой:

Давайте продемонстрирую. Чтобы мне было удобно, я этот запрос скопирую:

И вставлю тот аутентификатор, который мне «Заббикс» вернул:

Итак, Zabbix Api: мы посмотрели, как попросить у «Заббикса» аутентификатор на доступ. А далее демонстрирую, как с помощью этого аутентификатора получить какой-нибудь ответ:

Глаза я ломал долго, а потом решил почитать, как же с этим JSON в командной строке работать. И одна из рекомендаций звучала так: используйте JSON Query. Она очень здорова, скрашивает ответ, смотрите:

Во-первых, всё стало цветное – уже хорошо; во-вторых, здесь явно видно свич2, свич1:

Далее, немного повозившись с JSON Query, мы с вами увидим ещё много интересного. И чтобы каждый раз не копировать эти «крокодилы» из блокнота, я предлагаю определить, на чём мы будем программировать работу с нашим «Заббиксом». Есть Zabbix API – это JSON, есть куча языков программирования. J SON вроде как к Java-скрипту относится, но на самом деле для работы с «Заббиксом» чаще всего используют другие языки – например, Perl, Perl-скрипт, который что-то делает.

Оформление запросов в виде Bash-скриптов

Perl не модный нынче язык, устаревший. Если бы я начинал жизнь сначала, я бы начинал изучать, наверное, Pyton. И однозначно известно, что под «Питон» есть удобная библиотека для работы с «Заббиксом». Но, поскольку мы с вами здесь собрались и не будем отдавать предпочтение каким-то языкам, я использую этот язык:

Язык системного администратора, то есть меня – Bash! Поэтому я эти запросы к «Заббиксу»:

Оформлю в виде скриптов:

Скрипты готовые, я буду их копипастить. Выглядят они адски. Думаю, хороший код на «Питоне» будет гораздо более читабельным. Но, поскольку я сам не знаю «Питон» и не хочу отдавать какое-то предпочтение, я буду писать на том, что близко сердцу системного администратора:

Не буду рассказывать, что это за обратные слэши (и бог с ними). А вот строка аутентификации будет у нас оформлена в виде переменной, которую надо перед этим экспортировать:

Какое значение она у нас имела? И теперь вместо того, чтобы длинные строки копипастить, я могу просто запускать скрипт:

Скрипт возвращает полный швах. Через JSON Query можно вывести это красиво:

Вспоминаем задачу: получить базу данных коммутаторов, которые есть в «Заббиксе»!

Я сразу результат нарисую. Не буду долго и окольно рассказывать что здесь и как. У нас задача грандиозная:

Вот такой результат, смотрите, что содержит. Здесь говорится, что у нас в «Заббиксе» имеются вот такие коммутаторы, а это (10105, 10106, 10107) – внутренний «заббиксковский» идентификатор коммутатора:

Получился плоский файл. При добавлении каждого нового коммутатора надо этот скрипт запускать, чтобы создать файл. Чтобы таких «крокодилов» у нас не было, я эту строку включу в сам скрипт:

И он у нас будет возвращать аккуратное табличное представление. Теперь я покажу. Запускаю скрипт, он выводит на экран и тут же сохраняет этот файл:

Утилита tee – хорошая утилита, которая пишет результат в файл и пропускает результат наружу. У нас с вами теперь 3 коммутатора и имеется текстовый файл, в котором все коммутаторы перечислены:

Теперь можно опрашивать через RSH каждый из этих коммутаторов и выяснять, кто с чем связан.
Итак, базу данных коммутаторов получили. Наша конечная цель – карты!

Получение списка карт и их элементов из Zabbix

Как работать с картами? Давайте научимся читать информацию о картах из «Заббикса». Скопирую такой скрипт:

Кому понравится – можете все эти скрипты брать. Я старался максимально упростить их – проще не получается. Если найдёте, как упростить – пишите, я поправлю:

Этот скрипт ↑ обращается к «Заббиксу» с запросом map.get и говорит: «Расскажи мне про линки и расскажи про элементы, которые эти линки связывают друг с другом».

Теперь я этот скрипт запускаю:

И показываю результат:

Так же, как информацию о хостах, очень легко из «Заббикса» вытащить информацию о картах. Для каждой карты имеется её название:

Далее перечисляются элементы в этой карте. Узнаёте номер? Это внутренний элемент «Заббикса»:

Самое неприятное, что в «Заббиксе» элементы ещё раз нумеруются. Слева – элемент id, справа – нумерация элемента внутри карты:

То есть в «Заббиксе» каждый хост имеет номер, и на карте имеет ещё один номер – такая цепочка получается. То есть коммутатор switch1 называется в «Заббиксе» 10105, а на карте – 2 (получается небольшое усложнение задачи).

Сводим всё вместе через CDP и RSH, выясняем связь коммутаторов с интерфейсами

Финал этого скрипта заключается в том, что я должен получить информацию, какие идентификаторы «Заббикса» с какими идентификаторами на карте связаны. Смотрите, в «Заббиксе» вот этот идентификатор (10105, 10106 и т. д.), а на карте – 2, 3 и т. д.:

Традиционно сохраню это в текстовый файл:

Теперь у нас почти всё есть. Имеется информация, какие коммутаторы есть в этом файле (какие идентификаторы внутри «Заббикса» используются):

И у нас есть информация, какой идентификатор на карте с каким идентификатором «Заббикса» связан (например, switch1 имеет в «Заббиксе» номер 10105, а на карте номер 10105 имеет идентификатор 2):

Я не виноват! Это в «Заббиксе» ребята написали. Но я уверен, что есть причина, почему они на карте не используют прямые идентификаторы. Возможно, потому, что на карте можно несколько раз отобразить один и тот же объект, и у него должен быть уникальный идентификатор. Поэтому цепочка длиннее получается.

И вот этот адский скрипт я, наверное, совсем мало буду комментировать. Воспроизведите его:

В цикле я читаю строчки, описывающие, какой коммутатор с каким идентификатором «Заббиксом»:

К каждому коммутатору из «Заббикса» подключаюсь по RSH:

Читаю, с какими хостами он связан. Этот результат перенаправляю в другой цикл:

Который, в свою очередь, читает идентификаторы и выясняет, кто с кем связан:

Покажу результаты этого скрипта (chmod +x):

На карте второй коммутатор связан с третьим (помним, что на карте свои идентификаторы) через соответствующие интерфейсы (Fas 0/5 – для второго, Fas 0/6 – для третьего↑). Эти названия мы должны нарисовать на линках, создадим.

Если до этого момента мы только читали информацию из «Заббикса» (хосты, карты вычитывали и т. д.), то теперь мы должны будем писать информацию в «Заббикс».

Давайте сохраним результат:

Рисование линий связи в Zabbix

Я решил написать простой скрипт, который что-нибудь поменяет в «Заббиксе». Честно говоря, я так и изучал API – мне было важно, чтобы что-то простое заработало:

Первый скрипт не будет иметь отношения к задачам – он поменяет имя карты (чтобы посмотреть, как это делается). Если мы хотим что-то поменять в «Заббиксе», то мы должны так же обратиться через запрос POST и описать его в JSON, но используя метод map.update. Среди параметров мы должны явно указать: MAPID, который найдёт нужную карту, и MAPNAME, который поменяет имя карты:

Это минимальный набор параметров. Сами эти параметры:

Передают через переменные, аргументы скрипта. Делаю скрипт выполняемым (chmod +x):

Запускаю, как в методичке написано. Если всё верно, карта должна назваться Super MAP:

Monitoring – Maps – вуаля:

Легко поменять – Super MAP2:

Но наша-то задача сложная – поменять линии связи!

Надо сгенерировать JSON, который опишет нашу карту и все линии связи. Для этого я делаю очередной скрипт:

То, что у меня много скриптов, это не значит, что так надо делать на предприятии. На предприятии надо взять нормальный язык, который вы знаете («Питон», «Перл» или ещё что-то), и запрограммировать то, что здесь есть, используя нормальный язык. Эти кирпичики, каждый из которых прост, позволяют понять что, для чего и как делать.

Очередной скрипт, который служит скорее для понимания того, что нужно сделать, а не для копирования (готовый продукт я вам тут не продам):

Данный скрипт читает этот файл:

В котором прописано, какой элемент на карте с каким элементом на карте через какие интерфейсы связан. Точнее, мы будем брать элемент на карте, элемент на карте и метку. Это элемент на карте:

А это подпись должна быть:

Читаю этот файл. Перебираю все элементы на карте:

Программирую линки – описания линков в виде JASON. Конечный запрос выглядит так: обновить карту (номер карты↓):

Линки будут описаны в этой переменной:

Которая была сформирована в этом цикле (были перебраны все элементы и подписи картам):

Есть ожидание у меня, что сейчас всё должно произойти. Запустил скрипт:

Обновить страницу Maps:

Ну как? По крайней мере, это работает! Давайте добавим ещё один коммутатор и прогоним сценарий ещё раз.

Берём коммутатор, называем его switch4:

Рисуем, что это – коммутатор:

Соединяем его, как хотим (звёздочкой, можно колбасу нарисовать):

Настраиваем коммутатор. Запускаю:

Всё, что мы ранее делали (только меняем на switch4 и адрес – 104):

Двойной щелчок по коммутатору (вставить то, что скопировали):

Опять же, быстрее будет перезагрузить третий коммутатор (switch3), сохранив конфигурацию:

А пока он перезагружается, проверим, доступен ли на наш новый коммутатор по SNMP. Когда «Заббик» его найдёт, первым делом спросит hostname SNMP. Поэтому добавляем эту конструкцию в наш новый коммутатор:

Теперь ждём, когда коммутатор будет доступен. 101-й, 102-й доступны, 103-й перезагружается:

104-й отозвался. Проверю, по SNMP доступен ли свич4:

Доступен! У нас все шансы увидеть его в списке хостов. Подождём минуту (каждую минуту у нас сканируется сеть):

Раз он появился, мы возвращаемся к первому скрипту. Он у нас выгружал информацию, какие коммутаторы вообще есть:

Ваши кабельщики побежали, новый коммутатор воткнули, вы link подняли и в «Заббиксе» он появился автоматически. Соответственно, здесь мы с вами должны увидеть, что четвёртый свич появился:

База данных у нас заполняется автоматически.

Закрепляем материал (добавляем switch4), выполняем финальный скрипт

Далее, к сожалению, придётся сбегать и отобразить наш свич на карте:

Мало того что ваши кабельщики бегали, мало того что вы настраивали линк – придётся ещё пойти сюда и сказать: «У нас добавляется новый коммутатор».

Располагаете, где положено, и указываете, что это у нас хост, свич4, а также нарисовать, что это свич:

И обновить (линию связи пока не рисуем!):

Теперь вспоминаем, что наши скрипты линии связи строят на основании протокола CDP. И чтобы получить информацию по протоколу CDP с коммутатора, необходимо настроить к нему доступ RSH. Помните, я решил вот такой метод использовать?

Если всё хорошо, то я могу попробовать, то я могу попробовать RSH – запросить с 4-го коммутатора информацию о его связи. Вот он говорит: «Я к третьему подключён, с моей стороны – 10-й, с той стороны – 8-й интерфейс».

На карту-то добавили, а у нас есть таблица соответствия между идентификаторами в «Заббиксе» и идентификаторами в карте (видите, он 5-й стал на карте):

RSH подняли. Теперь можем построить связь: какие коммутаторы через какие линки подключены (текстовый файл у нас получился):

Попробуем запустить финальный скрипт, который этот текстовый файл прочитает и сформирует JASON-запрос на обновление карт, перерисовав все линки на карте:

Ну как? Впечатляет? За 45 планируемых минут не успел, но всё равно быстро (порядка 75 минут) – быстрее, наверное, не получится.

До новых встреч!

Немного рекламы

Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные VPS для разработчиков от $4.99, уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от $19 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

Dell R730xd в 2 раза дешевле в дата-центре Equinix Tier IV в Амстердаме? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?

Интерфейс управления

Что должен иметь интерфейс для эффективного управления всей конструкцией? Как минимум базу данных для хранения настроек и удобный хорошо документированный движок для разработки. Не знаю о чём вы подумали, но наш выбор пал на Laravel. Так выглядит главный интерфейс, который сделали.

Первый пункт — «Бизнес-сервисы». Сюда добавляем объекты, за которыми нужно наблюдать на тепловой карте. Если приписать объекту координаты — он появится также и на географической карте. При добавлении нужно указывать сервис-родитель, к которому прикрепится потомок. В комментариях можно задать текст, который потом будет отображаться во всплывающем меню тепловой или географической карты.

Второй пункт — «Источники данных». Выбираем систему, из которой будут тянуться события. У нас настроена интеграция через Zabbix API, но сюда можно добавлять неограниченное количество источников данных: Nagios, Zenoss, SCOM и другие — зависит от ваших потребностей.

Третий пункт — «Источники событий». К каждому квадрату тепловой карты нужно привязать что-то из системы мониторинга, нечто влияющее на статус объекта. В случае с Zabbix — это триггеры. Для другой системы мониторинга будет что-то другое. В настройках «Источников событий» бизнес-сервис привязывается к триггеру.

Теперь при срабатывании триггера, квадрат на тепловой карте будет подкрашиваться в соответствующий событию цвет. При наведении на объект появляется всплывающее меню с текстом события и ссылкой на алармящий триггер в Zabbix.

Географическая карта

Для создания географической карты со статусами объектов лучше всего использовать самый банальный OpenStreetMap. Google и Яндекс просят слишком многое для использования их карт (я про деньги и токены).

Можно просто нанести объекты на карту. А можно их объединять в кластеры при смене масштаба и присваивать результирующему кластеру цвет по наивысшей критичности события на вложенных объектах. На Github вы найдёте подходящее решение (или можно посмотреть в действии на jsfiddle). Как и в случае с тепловой картой, на географической тоже можно перейти на триггер в Zabbix по ссылке с объекта. Под мобилку тоже адаптируется.

На весь интерфейс сделана авторизация и даже простая ролевая модель: администраторы и пользователи. В планах добавить в этот же интерфейс какую-нибудь консоль событий и нечто типа Selenium или Casper.js для транзакционного мониторинга. Если есть вопросы — задавайте в комментариях или личным сообщением. Могу вам персонально прислать ссылку на то, что получилось у нас. Тут публиковать не буду, боюсь хабраэффекта.

Тепловая карта

Интерфейс основан на бесплатном фреймворке Google Charts (можете посмотреть демо на jsfiddle). Ничего более подходящего под это найти не удалось. Есть похожее решение у D3js, но там нет возможности настраивать влияние разноуровневых объектов друг на друга. Сразу предупреждаю, что Google Charts тянет за собой гугловые библиотеки, которые лежат на просторах googleapis.com. Так что сделать полностью оффлайновое решение не получится. На Github видел эти библиотеки в скачанном виде, но очень трудно поручиться за их актуальность.

Отображение дерева объектов настраивается в плоском файле или базе данных.

Ещё одно дополнительное преимущество Google Charts — адаптивный дизайн по умолчанию. Одинаково хорошо выглядит на десктопе и мобилке.

Эта карта визуализирует связи внутри вашего сервиса или бизнес-процесса. Если использовать подход с отвязыванием бизнес-процессов от бизнес-сервисов — потребуется две параллельные структуры, которые можно визуализировать на двух отдельных тепловых картах, чтобы не тревожить руководство по пустякам.

На размер квадратов влияет вес объектов, который можно задать в свойствах. По умолчанию вес у всех квадратов одинаковый.