Мониторинг систем видеонаблюдения с помощью zabbix

Введение

Настройка Zabbix мониторинга, это самое главное что должен делать каждый нормальный системный администратор.

Главных причин по которым вам надо использовать мониторинг несколько:

• Не возможно качественно поддерживать работоспособность сети без постоянного анализа её параметров;
• Вы первый будете в курсе при возникновении проблемы на обслуживающем оборудовании.

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

Иногда руководители просто не понимают в чем разница между приглашением специалиста по вызову и заключением договора на абонентское обслуживание.

Например, один клиент поймал шифровальщик файлов и восстановление данных ему обошлось в кругленькую сумму. Другой, который заключил договор на обслуживание (я успел на 80 % выполнить работы по защите баз данных и мониторинга сети) отделался легким испугом.

Главный принцип и подход разработчиков остается неизменным. В системе нет ничего лишнего и порой кажущееся усложнение на практике оказывается удобным механизмом упрощающим жизнь системному администратору контролирующему большой парк разнообразной техники.

Можно часами рассказывать о всех прелестях работы с этой системой, но не буду этого делать. Постараюсь внести понимание того из чего состоит и как работает эта система. Я посвятил много времени на изучение системы пока до меня не дошли элементарные вещи которые необходимо знать при работе с комплексом Zabbix.

Документация у разработчиков Zabbix есть, но написана она сухим техническим языком который вы сможете понять когда поймете основные принципы работы системы.

Получение доступа к API Яндекс

Вам нужно будет заполнить несколько обязательных полей:

1. Название приложения.
2. В качестве платформы указать Веб-сервисы.
3. Callback URI установить — https://oauth.yandex.ru/verification_code.
4. В Доступах указать: Яндекс.Метрика, Получение статистики, чтение параметров своих и доверенных счетчиков.

Все остальное можно не указывать. Вы должны получить ID приложения и Пароль.

После разрешения, вы получите токен, с помощью которого можно подключаться к api.

Используя этот токен, можно получать данные из Метрики через API. Для примера зайдем на сервер мониторинга и через консоль запросим данные о посещаемости сайта. Для этого нам нужно узнать номер его id в метрике. Можно это сделать прямо в ней же.

Далее формируем запрос через curl с указанием токена в header.

# curl --header "Authorization: OAuth AgAAaaaaaaaaaaaDDDDDDDDDddd" --header "Content-Type: application/x-yametrika+json" -X GET "https://api-merika.yandex.ru/stat/v1/data?&ids=23506456&metrics=ym:s:users,ym:s:visits,ym:s:pageviews&dimensions=&date1=today&pretty=true"

В данном запросе я указал:

• AgAAAAAAGk3WAAaaYZaUSgzNyU7uvqAKCGwDSro — токен;
• ids=23506456 — id сайта в метрике;
• metrics=ym:s:users,ym:s:visits,ym:s:pageviews — запрошенные метрики — пользователи, визиты, просмотры страниц;
• date1=today — дата, сегодняшний день в данном случае;
• pretty=true — вывести в формате удобочитаемого json.

Получили ответ в виде подробного json. Он отлично подходит для zabbix, так как последний умеет из коробки парсить json. У вас есть 2 варианта дальнейшей настройки мониторинга:

1. Сделать скрипт на сервере, который будет слать запросы в api яндекса и передавать полученное значение в zabbix с помощью агента. Плюс решения в том, что нагрузка на сервер мониторинга минимальная. Неудобство в том, что нужно куда-то добавлять скрипт.
2. Слать запросы к api напрямую с zabbix сервера с помощью HTTP Агента. И сразу там же парсить полученный ответ. Плюс этого подхода в том, что все настройки хранятся в шаблоне и легко сохраняются или переносятся через экспорт шаблона. Минус в том, что все вычисления и запросы выполняются самим заббиксом.
   Я обычно иду по второму пути, потому что так удобнее.

В таком виде это можно отправлять в Zabbix, чем мы далее и займемся.

Простое описание работы Zabbix

Система Zabbix это клиент-серверное решение. На всех контролируемых узлах должен быть установлен клиент (агент) который собирает данные для мониторинга узла.

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

Порты работы

Один из важных моментов который надо учитывать при настройке это знать на каких портах по умолчанию работает Zabbix.

Порта всего два:

1. 10051 — по нему сервер получает данные от активных агентов. Порт должен быть открыть на сервере;
2. 10050 — по нему сервер опрашивает клиентов и забирает данные. Порт должен быть открыть на клиенте.

Клиенты

Клиент  может быть двух видов:

• Обычный агент — сервер получает доступ к узлу мониторинга и забирает данные;
• Активный агент — клиент сам отправляет данные серверу.

Далеко не сразу я смог разобраться в нюансах использования активного агента. Из статьи вы узнаете как правильно пользоваться мониторингом компьютеров которые не имеют статического IP адреса.

Шаблоны

Шаблоны это основа системы Zabbix. Разработчик добавил большое количество шаблонов для разных систем и настолько грамотно и взвешено подошел к их разработке, что они подходят под основные требования мониторинга. Кроме того, на просторах интернета вы можете встретить огромное количество шаблонов созданных пользователями. Для использования сторонних шаблонов вам достаточно загрузить их в свою систему и произвести минимальные настройки.

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

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

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

Триггеры

Триггеры это то на чем держится и в чем заключается вся прелесть мониторинга

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

и тп. В триггере указывается важность события. При добавлении нового триггера разработчик придумал конструктор выражения по которому можно составить необходимый вам вариант срабатывания триггера.

Установка обновления zabbix 4.4 до 5.0

Centos 8

Устанавливаем само обновление zabbix на сервер Centos следующей командой:

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

В приведенном примере есть еще пакеты zabbix-get и zabbix-sender. Обновляем все сразу:

Centos 7

В Centos 7 обновить Zabbix с 4-й вертки на 5-ю может оказать не такой простой задачей. Связано это с тем, что необходима версия php 7.2, в ее в базовых репозиториях Centos 7 нет. Необходимо подключать репозиторий centos-release-scl и ставить пакеты из него. Но просто так взять и поставить не получится, будет конфликт с текущими версиями пакетов. Так что нужно аккуратно что-то удалить, а что-то добавить. Действуем аккуратно и внимательно.

Удаляем старые пакеты, которые будут заменены при обновлении:

# yum remove zabbix-web-*

Подключаем репозиторий centos-release-scl:

# yum install centos-release-scl

Редактируем файл /etc/yum.repos.d/zabbix.repo, разрешая обновляться пакетам из zabbix-frontend. Не забудьте проверить, что у вас подключился репозиторий от 5-й версии.

name=Zabbix Official Repository frontend - $basearchbaseurl=http://repo.zabbix.com/zabbix/5.0/rhel/7/$basearch/frontendenabled=1gpgcheck=1gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-ZABBIX-A14FE591

Устанавливаем новые пакеты:

# yum install zabbix-web-mysql-scl zabbix-apache-conf-scl

Обновляем существующие:

# yum update zabbix-*

Теперь убедитесь, что у вас активирован новый конфиг zabbix для apache. У вас должен быть файл /etc/httpd/conf.d/zabbix.conf, а в нем следующая строка:

SetHandler "proxy:unix:/var/opt/rh/rh-php72/run/php-fpm/zabbix.sock|fcgi://localhost"

Она отвечает за использования новой версии php 7.2 из пакета php-fpm. Перезапускаем все службы:

# systemctl restart zabbix-server httpd# systemctl enable --now rh-php72-php-fpm

После этого у вас должно корректно пройти обновление zabbix на 5-ю версию в Centos 7.

Debian / Ubuntu

Устанавливаем само обновление zabbix на сервер с Debian или Ubuntu следующей командой:

Дальше инструкция общая для всех систем. После завершения обновления, запускаем сервер:

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

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

В логах агента и сервера можно посмотреть версию запущенных сервисов.

Теперь можно идти в веб интерфейс и смотреть на обновленную версию zabbix server. Перед этим почистите кэш браузера и удалите куки от страницы заббикса. Если этого не сделать, то могут быть проблемы и ошибки, с чем я не раз сталкивался. Если у вас в качестве веб сервера используется nginx, не забудьте поменять владельца директории /etc/zabbix/web на nginx, в том случае, если веб сервер работает от него. После обновления он будет принадлежать apache, а web интерфейс не заработает.

Можете лицезреть обновленную версию web интерфейса.

Сначала провел обновление на небольшом сервере. У меня весь процесс прошел без ошибок и накладок. Новый интерфейс сразу заработал.

Добавление web сайта к мониторингу

Самый простой способ подключить сайт к мониторингу — добавить его проверку на уже существующем хосте. В этом подходе есть один большой минус — если вы захотите включить этот мониторинг от другого хоста, или просто перенести на другой сервер, то делать это будет неудобно. Гораздо удобнее мониторинг сайтов и все, что с ним связано, настраивать в отдельном шаблоне. Так что идем в раздел Configuration -> Templates и создаем новый шаблон.

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

Открываем этот шаблон. Переходим на вкладку Web Scenarios и добавляем новый сценарий для мониторинга сайта.

Заполняем основные параметры сценария. В качестве названия я обычно указываю адрес сайта. В моем примере это будет github.com. Тут же указываю название приложения для мониторинга сайтов для удобной сортировки итемов, относящихся к сайтам, интервал проверки и число попыток соединения.

После этого перехожу на вкладку Steps и добавляю шаг проверки.

Дальше указываю параметры шага.

Поясню каждый параметр:

• Name — имя шага. В данном случае проверяться будет главная страница сайта, поэтому называю шаг index. Это не принципиально, но названия рекомендую давать осмысленные, чтобы потом было удобно оперировать названиями, к примеру, в триггерах.
• URL — адрес проверяемой страницы.
• Required string — строка на странице, которую будет искать zabbix. Я взял строку из футера сайта. Если заббикс ее найдет на странице, будет считать, что с сайтом все в порядке. Если нет — выдаст ошибку.
• Required status codes — требуемый код ответа. Указываю 200. Если заббикс получит какой-то другой код в ответ от web сервера, будет считать, что проверка закончилась неудачей.

После заполнения всех параметров жмем Add, чтобы добавить шаг и далее еще раз Add, чтобы добавить сам сценарий проверки. Должна получиться вот такая картина.

Простейшая проверка доступности сайта сделана. Дальше нам надо прикрепить этот шаблон к какому-нибудь хосту, чтобы начались реальные проверки. Я прикреплю шаблон к самому zabbix серверу. Для этого идем в Configuration -> Hosts, выбираем Zabbix Server и прикрепляем к нему созданный ранее шаблон.

Ждем несколько минут и идем в раздел Monitoring -> Web смотреть результаты мониторинга сайта github.com.

Код ответа 200, искомая строка найдена, что подтверждает Status OK. Тут же графики скорости загрузки сайта и время отклика. Более подробную информацию о мониторинге указанного сайта можно посмотреть в Latest Data.

Значение параметра Failed step of scenario «github.com» равное 0 означает, что все шаги проверки сайта выполнены без ошибок. Если у вас несколько шагов и какой-то из них завешается ошибкой, тут будет номер этого шага. То есть в общем случае, все, что не 0, это какие-то проблемы. Позже мы это будем использовать в триггере. А пока добавим пару графиков к шаблону, которые потом можно будет использовать в дашбордах.

Оповещение о недоступности сайта

Давайте настроим уведомления о проблемах на сайте. Я предлагаю 2 типа оповещения:

1. О низкой скорости доступа к сайту.
2. О недоступности сайта вообще.

Идем, как обычно в исходный шаблон, на вкладку Triggers и добавляем новый.

Я предлагаю вот такое условие срабатывания для определения недоступности сайта. Если среднее значение 3-х последних проверок больше, либо равно единице, то срабатывает оповещение о недоступности сайта.

Когда идет 0 во всех проверках, все в порядке. Триггер сработает только если все 3 последних проверки не равны нулю. В моем примере Failed step может принимать значение либо 0, либо 1, где 1 это номер сбойного шага. Если у вас шагов несколько, то сбойным может оказаться второй шаг или третий шаг. То есть значение может быть больше 1. Но в любом случае, если последние 3 значения подряд строго не 0, то идет срабатывание триггера. Операция восстановления очень простая. Если последняя проверка без ошибки, то есть код равен 0, то считаем, что сайт уже работает.

Чтобы проверить работу триггера, достаточно на zabbix server в файл /etc/hosts добавить строку:

127.0.0.1 github.com

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

Дальше делаем проверку времени ответа сервера. Тут каждый волен настраивать так, как ему кажется более правильным и удобным. Я использую такую схему. Беру среднее время отклика сайта и умножаю его на 3. Далее смотрю последние 7 проверок. Если в 5 проверках среди этих семи были значения выше, чем утроенное среднее время отклика, то считаю, что сайт тормозит и надо слать уведомление. Немного замороченно, но на практике такая схема у меня себя хорошо зарекомендовала без ложных срабатываний. При этом, если возникают реальные проблемы, я их вижу. Рисуем триггер.

Условие восстановления — в последних трех запросах два и более были быстрее, чем утроенное среднее время доступа. Текст выражений для копирования:

{Sites Monitoring:web.test.time.count(#7,1.5,"ge")}>4
{Sites Monitoring:web.test.time.count(#3,1.5,"lt")}>1

В выражении 1.5 это время отклика в секундах. Именно в таком виде оно попадает в zabbix сервер. Проверить можно в Latest Data.

В завершении оставляю свой шаблон, который создал для написания статьи. Можете копированием и редактированием приспособить его для своих сайтов. Это быстрее, чем составлять с нуля. Шаблон экспортирован с версии zabbix 4.0 — sites_monitoring.xml

Вот и все, мониторинг веб сайта работает, авторизация проверяется, оповещение о недоступности сайта настроено. Для полноты картины можно создать Screen или Dashboard с выводом всех необходимых параметров на один экран. Его настройки уже будут зависеть от конкретной ситуации и тех данных, которыми вы располагаете. К примеру, если у вас настроен мониторинг веб сервера, то можно разместить рядом графики его загрузки и параметры доступа к сайту. Туда же можно добавить загрузку самого сервера по процессору и памяти и вывести график использования сетевого интерфейса.

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

Более подробно о мониторинге за временем отклика сайта читайте в отдельной статье на этот счет. Там описана теория процесса и практические рекомендации, вместе с готовым триггером.

Особенности веб-интерфейса

Система мониторинга Zabbix располагает удобным веб-интерфейсом, в котором сгруппированы элементы управления. Консоль предусматривает просмотр собранных данных, их настройку. Для безопасности входа и работы осуществляется автоматическое отсоединение через 30 минут пользовательского бездействия.

На главном экране всегда представлена информация о состоянии узлов сети и триггеров.

Пользователю доступны пять функциональных разделов, включая Monitoring («Мониторинг»), Inventory («Инвентарные данные»), Reports («Отчеты»), Configuration («Конфигурация») и Administration («Администрирование»).

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

Управлять шаблонами, доступными администратору, можно в соответствующем подразделе — Templates («Шаблоны»).

Подготовка к обновлению

Важная информация перед обновлением. Версия 5.2 без длительной поддержки. Через пол года к ней перестанут выходить обновления, так что вам обязательно придется обновляться на следующую версию. Если для вас не критичны нововведения этого релиза, пропускайте его и ждите новой LTS версии.

Если у вас версия ниже 5.0, то предварительно обновите ее до указанной. У меня есть цикл статей на тему обновления Zabbix:

• 2.4 до 3.0
• 3.0 до 3.2
• 3.2 до 3.4
• 3.4 до 4.0
• 4.0 до 4.2
• 4.2 до 4.4
• 4.4 до 5.0

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

У меня что-то активно писалось в базу, поэтому сервер выключался долго. Я проверил лог zabbix-server, чтобы убедиться в корректном выключении. Там все нормально было, сервер штатно завершил работу, дописав то, что у него там накопилось. Так что бэкапим.

zabbix	название базы данных заббикса
-uzabbix	ключ -u и дальше имя пользователя базы данных
-p’password’	ключ -p и дальше пароль пользователя бд, если в пароле есть спецсимволы, экранируйте их одиночными кавычками

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

Centos 7

Подключаем репозиторий версии zabbix 5.0:

# rpm -Uvh https://repo.zabbix.com/zabbix/5.2/rhel/7/x86_64/zabbix-release-5.2-1.el7.noarch.rpm

Centos 8

# rpm -Uvh https://repo.zabbix.com/zabbix/5.2/rhel/8/x86_64/zabbix-release-5.2-1.el8.noarch.rpmСтарый репозиторий от версии 4.4 будет автоматически удален.

Очищаем и пересоздаем кэш yum:

Удаляем пакет текущего репозитория:

Подключаем новый:

Обновляем информацию о репозиториях:

Удаляем пакет текущего репозитория:

Подключаем новый:

Обновляем информацию о репозиториях:

Ubuntu 20

Удаляем пакет текущего репозитория:

Подключаем новый:

Обновляем информацию о репозиториях:

Если у вас другие версии систем, то простой найдите ссылки пакетов под свою версию в официальном репозитории — https://repo.zabbix.com/zabbix/5.2/ Дальнейшее обновление не будет отличаться от текущего.

К обновлению подготовились, можно приступать.

Наконец-то настройка

Долго готовились, а теперь пора настроить то ради чего это все затевалось — мониторинг web-страниц Zabbix-ом.
Сразу оговорюсь — в этом руководстве я исхожу из того, что у вас уже есть настроенный узел сети (он же host), в который надо просто добавить web-сценарий проверки.

Дальше будет много скриншотов.

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

Создаем шаги:
Первый шаг — запрещаем переход по редиректам и проверяем код ответа

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

Третий шаг — запрещаем переходы по редиректам и проверяем HTTPS версию (код ответа и наличие строки указывающей на работоспособность сайта)

Теперь создадим триггер, который проверяет, что сценарий отработал успешно.
Коротко суть:
1) ITEM.VALUE указатель на первое из двух выражений триггера (если нужно использовать несколько выражений или конкретное по номеру, то нужно использовать порядковые номера. Например — ITEM.VALUE3);
2) Выражения триггера — первое проверяет на что сообщение об ошибке не пустое, а второе что номер проваленного шага не 0 (если 0, значит проверка завершена успешно).

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

Вообще это очень гибкий инструмент Zabbix-а. Из сложного вспоминается возможность выполнения WSDL-запросов с авторизацией на целевом сервере по SSL-сертификату, но по понятным причинам типовых сценариев использования таких возможностей нет.

Обзор

Систему создал Алексей Владышев на языке Perl. Впоследствии проект подвергся серьезным изменением, которые затронули и архитектуру. Zabbix переписали на C и PHP. Открытый исходный код появился в 2001 г., а уже через три года выпустили первую стабильную версию.

Веб-интерфейс Zabbix написан на PHP. Для хранения данных используются MySQL, Oracle, PostgreSQL, SQLite или IBM DB2.

На данный момент доступна система Zabbix 4.4. Скачать ее можно на официальном сайте. Там же можно найти официальные курсы и вебинары для начинающих пользователей системы.

Далее рассмотрим, из чего состоит и как работает технология Zabbix в доступном формате «для чайников».