Zabbix как сканер безопасности / блог компании vulners / хабр

Введение

Кратко о системе мониторинга Zabbix я уже писал в предыдущей своей статье по установке zabbix 2.4, поэтому не буду повторяться. О наиболее важны изменениях я тоже уже рассказывал в материале по обновлению zabbix 2.4 до 3.0, можно ознакомиться. Добавлю новую информацию. Я уже обновил несколько серверов мониторинга до последней версии. В плане функциональности у меня нет претензий, все работает как минимум не хуже чем раньше, но новые возможности я пока не использовал.

А вот внешний вид двух предложенных тем лично мне не нравится. Старая кажется более гармоничной и наглядной. Это сдерживает меня от обновления всех систем на новую версию. Ну не нравятся мне новые темы, не хочу на них смотреть. Я дольше и труднее воспринимаю информацию в них. Скорее всего это мое субъективное мнение, всегда трудно привыкать к новым вещам. Так что предлагаю не ориентироваться на мои впечатления, а ставить новую версию и смотреть.

Было бы любопытно услышать вашу версию того, насколько стали удобнее и приятнее новые темы оформления, по сравнению со старой. Есть еще такие же ретрограды и консерваторы, как я?

Установка Zabbix Agent в Linux

Теперь установим агент Zabbix в Linux. Для установки Zabbix агента в Ubuntu Server 18.04 с помощью пакетного менеджера нужно скачать и установить репозиторий Zabbix. Затем из репозитория установим zabbix agent:

В CentOS для добавления репозитория и установки агента zabbix используется команды:

Перед тем как мы запустим zabbix агент, нужно отредактировать конфигурационный файл /etc/zabbix/zabbix_agentd.conf. В нем нужно указать IP адрес сервера Zabbix для активных проверок.

Server=IP
ServerActive=IP:10051
Hostname=testagent

После этого запустите сервис агента:

Убедитесь, что агент успешно запустился.

Строка cannot parse list of active checks говорит о том, что на сервере нет активных проверок для этого хоста.

Как и в случае с Windows агентом, вам нужно добавить ваш Linux хост в настройках сервера Zabbix

Обратите внимание на параметр Host name в настройка хоста в интерфейсе заббикс сервера — этот параметр должен совпадать с Hostname параметром, который мы указываем в конфиге Zabbix -агента. В конфиге выше я указывал имя хоста testagent. Перезагрузите Zabbix агент и проверьте лог

Перезагрузите Zabbix агент и проверьте лог.

Проверьте, что данные от агента появились на сервере Zabbix.

На этом настройка Zabbix-агента на Linux системе завершена. В следующей статье мы рассмотрим безагентный мониторинг доступности узлов в Zabbix через ICMP Ping.

Установка сервера Zabbix

Перед тем как мы сможем установить zabbix ubuntu 17.04, 16.04 и в других версиях, потребуется кое-что настроить. Нужно установить веб-сервер, MySQL и PHP. Если эти сервисы у вас уже настроены, то просто можете пропустить этот шаг.

Установка Apache, PHP, MySQL

Для установки выполните такие команды:

Дальше необходимо настроить правильный часовой пояс в php.ini. Вам нужна секция Data и строка timezone:\

Добавление репозитория

Скачать установщик репозитория для вашего дистрибутива можно в папкеzabbix/5.2/ubuntu/pool/main/z/zabbix-release/. Там находятся установщики для разных версий Ubuntu:

Например, можно использовать wget для загрузки файла:

Если у вас другая операционная система, посмотрите список файлов на сервере через браузер и выберите нужный установщик. Затем установка zabbix 3.2 на Ubuntu:

После установки пакета репозитория, обновление списка пакетов обязательно:

Установка и настройка Zabbix

Когда репозиторий будет добавлен, можно перейти к настройке самого сервера Zabbix. Для установки программ выполните:

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

Для нормальной работы Zabbix нужна кодировка базы данных UTF-8, если вы создадите базу в кодировке utf8mb4, то получите ошибку: «Specified key was too long; max key length is 767 bytes». Дальше нужно загрузить все таблицы в базу данных, они находятся в папке /usr/share/doc/zabbix-server-mysql/ или /usr/share/zabbix-server-mysql/. Вместо zabbix и zabbixdb нужно указать своего пользователя и имя базы данных:

Чтобы Zabbix смог подключиться к базе данных нужно отредактировать конфигурационный файл /etc/zabbix/zabbix_server.conf и указать там данные аутентификации:

Далее, включаем конфигурационный файл zabbix для apache2:

Теперь нужно перезапустить Zabbix и Apache, чтобы применить изменения:

Установка и настройка Zabbix Ubuntu почти завершена, осталось настроить веб-интерфейс.

Настройка веб-интерфейса zabbix

Веб-интерфейс программы готов к работе, теперь вы можете его открыть, набрав в адресной строке http://адрес_сервера/zabbix/:

На первой странице нажмите Next. На следующем шаге программа проверит правильно ли настроен интерпретатор PHP:

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

На следующем шаге можно изменить ip и порт, на котором будет слушать Zabbix:

Далее можно выбрать тему оформления:

Последний шаг, проверьте все ли верно и не нужно ли чего менять:

Теперь вернитесь в браузер и нажмите Finish:

Перед вами откроется окно ввода логина и пароля. Используйте стандартные значения, логин Admin и пароль zabbix.

Вот и все, теперь установка Zabbix Ubuntu завершена и вы можете переходить к настройке.

Sensu

Sensu — фреймворк для мониторинга (или платформа, как они сами о себе говорят), но не готовая система мониторинга.

Её сильные стороны включают:

Интеграция с Puppet \ Chef — определяйте, что проверять, и куда отправлять уведомления прямо в вашей системе управления конфигурацией
Использование имеющихся технических решений там, где это возможно, вместо изобретения велосипедов (Redis, RabbitMQ)

Sensu вытягивает события из очереди и выполняет на них обработчики, вот и всё. Обработчики (Handlers) могут посылать сообщения, выполнять что-то на сервере, или делать что угодно ещё, чему вы их научите.

Масштабируемость

Sensu имеет гибкую архитектуру, поскольку каждый компонент может быть продублирован и заменён несколькими путями. Пример простой отказоустойчивой системы описан в следующей презентации; вот общая схема:

С HAProxy и Redis-sentinel вы можете построить систему, в которой, при наличии хотя бы одной живой машины каждого типа (Sensu API, Sensu Dashboard, RabbitMQ, Redis) мониторинг будет продолжать работать без какого-либо ручного вмешательства.

Интеграция с системами управления конфигурацией

Встроенная (Puppet, Chef, EC2?!) но только в платной версии, что плохо, особенно если у вас тысячи серверов и вы не хотите платить за что-то, имеющее бесплатные аналоги.

UI

Интерфейс по-умолчанию для Sensu, Uchiwa, имеет много ограничений. Он выглядит слишком простым для окружения с тысячами хостов, которые имеют большой разброс по ролям. Платная версия имеет свой собственный дашборд, однако он не сильно отличается от бесплатной редакции, и только добавляет несколько выключенных из-коробки возможностей открытой версии.

Недостатки

Отсутствие исторической информации и очень ограниченные возможности создания проверок, основанной на ней;
Подход «сделай сам» — нет готового мониторинга, который можно было бы включить для вашей системы сразу после установки;
Агрегирование событий нетривиально;
Замудрёная отправка сообщений, что страшно (потому что это та часть системы, которая должна быть самой простой и надёжной) — неправда, я получил неправильное впечатление от документации, спасибо x70b1 за разъяснение;
Путь «мы не хотим изобретать колесо» имеет свои ограничения, которые могут быть вам знакомы, если вы когда-либо использовали подобные системы (в моём случае, это была система мониторинга Prometheus, которая оставляла ряд функций на откуп пользователю, например, авторизацию\аутентификацию\идентификацию).

VI. Дополнительные материалы

В конечном итоге, в системе должны работать следующие компоненты, обеспечивающие работу Zabbix:

sudo systemctl status компонент

А сам фронтэнд (веб-интерфейс) Zabbix должен открыться в браузере.

Список некоторых файлов Zabbix и пути к ним :

Файл	Назначение
/var/log/zabbix/zabbix_agentd.log	лог-файл Zabbix-агента
/var/log/zabbix/zabbix_server.log	лог-файл Zabbix-сервера
/etc/zabbix/zabbix_agentd.d/zbxpcp.conf	Конфигурационный файл, подключающий zbxpcp.so
/etc/zabbix/zabbix_agentd.conf	Конфигурационный файл Zabbix-агента
/etc/zabbix/zabbix_server.conf	Конфигурационный файл Zabbix-сервера
/etc/zabbix/web/maintenance.inc.php	Конфигурационный файл GUI Zabbix
/etc/zabbix/web/zabbix.conf.php	Конфигурационный файл GUI Zabbix, настройки БД (включая логин и пароль), настройки zabbix-сервера
/run/zabbix/zabbix_agentd.pid	Файл, в котором хранится идентификатор процесса zabbix-agentd
/run/zabbix/zabbix_server.pid	Файл, в котором хранится идентификатор процесса zabbix-server
/usr/share/zabbix/	Папка пользовательской оболочки Zabbix. Содержит php-файлы.
/usr/lib/systemd/system/zabbix-agent.service	Модульный файл zabbix-агента. Определяет порядок его загрузки и работы.
/usr/lib/systemd/system/zabbix-server.service	Модульный файл zabbix-сервера. Определяет порядок его загрузки и работы.

Настройка Zabbix proxy

Открываем файл конфигурации zabbix proxy для настройки:

# mcedit /etc/zabbix/zabbix_proxy.conf

Необходимо изменить несколько параметров, все остальное можно не трогать:

server=84.143.241.246
hostname=proxy01
DBName=/var/lib/sqlite/zabbix.db

server	Адрес центрального сервера мониторинга
hostname	Имя прокси сервера, которое мы будем использовать на основном сервере
DBName	Путь к локальной базе данных

Добавляем proxy в автозагрузку и запускаем:

systemctl enable zabbix-proxy
systemctl start zabbix-proxy

Если сейчас посмотреть лог, то увидим там следующее:

# cat /var/log/zabbix/zabbix_proxy.log

2701:20160816:225839.865 cannot obtain configuration data from server at "84.143.241.246": proxy "proxy01" not found
2702:20160816:225839.865 cannot send heartbeat message to server at "84.143.241.246": proxy "proxy01" not found

В данном случае все в порядке, это не ошибка. Просто основной сервер еще ничего не знает о только что настроенном прокси. Нам нужно идти на сервер и добавлять свежеустановленный proxy. Заходим в web панель, идем в раздел Administration -> Proxies (Администрирование -> Прокси) и справа нажимаем на кнопку Create proxy (Создать прокси):

Заполняете необходимые поля. В данном случае обязательное только одно поле Proxy name.

Proxy name	Имя прокси сервера, должно соответствовать параметру hostname в файле конфигурации прокси
Proxy mode	Режим работы: active — прокси всегда сам обращается к основному серверу и отправляет данные, passive — команды на получение данных каждый раз инициирует основной сервер
Hosts	Хосты, которые будут мониториться через этот прокси. Так как мы только добавляем прокси, вряд ли у нас есть хосты для него.
Description	Произвольное описание сервера

После добавление proxy на основной сервер, можно перезапустить сам прокси сервер и посмотреть лог:

# systemctl restart zabbix-proxy
# cat /var/log/zabbix/zabbix_proxy.log

2871:20160816:231130.025 received configuration data from server at "84.143.241.246", datalen 2664

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

В качестве теста запустим на самом прокси сервере zabbix agent и подключим его к основному серверу мониторинга через proxy. Для этого открываем конфиг агента и устанавливаем следующие параметры:

# mcedit /etc/zabbix/zabbix_agentd.conf

Server=192.168.56.10
ServerActive=192.168.56.10
Hostname=proxy01

192.168.56.10 — локальный ip адрес прокси сервера.

Сохраняем файл, агента пока не запускаем. Идем в веб интерфейс и добавляем новый хост.

Имя указываем такое же, как Hostname у агента, ip адрес — локальный адрес агента, Monitored by proxy выбираем в выпадающем списке нужный proxy сервер. Когда добавите их несколько, они все будут в этом списке. Не забудьте назначить какой-нибудь шаблон. Если этого не сделать, то можно долго ждать поступления данных и недоумевать, почему ничего не поступает, хотя на вид все в порядке и ошибок в логах нет. Я много раз с подобным сталкивался в своей практике.

После того, как добавите новый хост на основном сервере, возвращаемся на proxy и перезапускаем его, чтобы сразу же получить настройки с основного сервера. Это делать не обязательно, через некоторое время (не знаю точно какое, любопытно было бы узнать) прокси сам заберет конфигурацию. Но мы форсируем процесс:

# systemctl restart zabbix-proxy

Теперь запускаем агент и добавляем его в автозагрузку:

# systemctl enable zabbix-agent
# systemctl start zabbix-agent

Проверяем лог агента:

# cat /var/log/zabbix/zabbix_agentd.log

Все в порядке, ошибок нет. Через некоторое время данные начнут поступать на основной сервер мониторинга с помощью посредника zabbix proxy.

Дополнительные материалы по Zabbix

Онлайн курсы по Mikrotik

Если у вас есть желание научиться работать с роутерами микротик и стать специалистом в этой области, рекомендую пройти курсы по программе, основанной на информации из официального курса MikroTik Certified Network Associate. Помимо официальной программы, в курсах будут лабораторные работы, в которых вы на практике сможете проверить и закрепить полученные знания. Все подробности на сайте .

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

Знания, ориентированные на практику;
Реальные ситуации и задачи;
Лучшее из международных программ.

Настройки системы
Рекомендую полезные материалы по Zabbix:
Установка 4.0 Обновление 3.0 -> 3.2 Обновление 3.4 -> 4.0 Установка Zabbix Proxy Работа на NGINX Видео и подробное описание установки и настройки Zabbix 4.0, а также установка агентов на linux и windows и подключение их к мониторингу. Подробное описание обновления системы мониторинга zabbix версии 3.4 до новой версии 4.0. Пошаговая процедура обновления сервера мониторинга zabbix 2.4 до 3.0. Подробное описание каждого шага с пояснениями и рекомендациями. Подробное описание установки и настройки zabbix proxy для организации распределенной системы мониторинга. Все показано на примерах. Подробное описание установки системы мониторинга Zabbix на веб сервер на базе nginx + php-fpm.
Мониторинг служб и сервисов
Температура процессора Nginx и php-fpm Mysql репликация Службы Linux Рейд mdadm Транки Asterisk Synology Мониторинг температуры процессора с помощью zabbix на Windows сервере с использованием пользовательских скриптов. Настройка полноценного мониторинга web сервера nginx и php-fpm в zabbix с помощью скриптов и пользовательских параметров. Мониторинг репликации mysql с помощью Zabbix. Подробный разбор методики и тестирование работы. Описание настройки мониторинга tcp служб с помощью zabbix и его инструмента простых проверок (simple checks) Настройка мониторинга рейда mdadm с помощью zabbix. Подробное пояснение принципа работы и пошаговая инструкция. Подробное описание мониторинга регистраций транков (trunk) в asterisk с помощью сервера мониторинга zabbix. Подробная инструкция со скриншотами по настройке мониторинга по snmp дискового хранилища synology с помощью сервера мониторинга zabbix.
Мониторинг различных значений
Мониторинг сайта Мониторинг бэкапов Размер бэкапа Делегирование домена Значения из текстового файла Мониторинг логов Настройка мониторинга web сайта в zabbix. Параметры для наблюдения — доступность сайта, время отклика, скорость доступа к сайту. Один из способов мониторинга бэкапов с помощью zabbix через проверку даты последнего изменения файла из архивной копии с помощью vfs.file.time. Подробное описание настройки мониторинга размера бэкапов в Zabbix с помощью внешних скриптов. Пример настройки мониторинга за временем делегирования домена с помощью Zabbix и внешнего скрипта. Все скрипты и готовый шаблон представлены. Пример распознавания и мониторинга за изменением значений в обычных текстовых файлах с помощью zabbix. Описание мониторинга лог файлов в zabbix на примере анализа лога программы apcupsd. Отправка оповещений по событиям из лога.

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

LLD появилась в Zabbix где-то с версии 2.0. Эта техника применяется не только для автообнаружения на хостах, LLD еще очень хорошо разгружает работу сервера Zabbix. В случае активной проверки сервер Zabbix сам отправляет запрос на хост, чтобы получить метрику. Обычно запрос ставится в очередь наряду со всеми остальными запросами и обрабатывается в порядке очереди, но, если метрик много, сервер будет серьезно загружен. В случае с LLD в режиме проверки хост zabbix-trapper сам отправляет серверу список метрик, а спустя небольшое время — и сами метрики со значениями. То есть нагрузка выходит минимальная. Сервер сам решает, что принимать, а что нет, исходя из настроек.

Реализация технологии LLD на хосте следующая: используется связка «приложение — скрипт — сендер Zabbix — сервер Zabbix». Давай пройдемся по всем этапам, чтобы было понятнее.

Инициализация скрипта.
Запрос от скрипта к приложению на получение метрик.
Обработка запроса от скрипта приложением.
Ответ скрипту от приложения с передачей данных.
Формирование скриптом JSON LLD для передачи имен метрик на сервер Zabbix.
Выдача JSON при вызове скрипта.
Обработка полученных от приложения данных путем формирования метрик и их значений (к примеру, с записью в файл).
Вызов сендера Zabbix скриптом и инициализация отправки метрик на сервер.
Сендер передает запрос на сервер Zabbix. Режим проверки на сервере zabbix-trapper.
Сервер Zabbix считывает метрики и отправляет ответ для сендера.
Сендер получает ответ от сервера и логирует его на экран или в файл.

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

Схема взаимодействия компонентов Zabbix LLD

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

Что нового в Zabbix 5.4?

Все нововведения свежей версии Zabbix 5.4 вы можете прочитать в официальном релизе — https://www.zabbix.com/ru/whats_new_5_4. Я среди них выделил следующие:

Ну конечно же новый синтаксис триггеров. Странно, что они это изменение не поставили на первое место. Я уже делал заметку (https://t.me/srv_admin/684) по этому поводу, так что не буду повторяться. Изменение очень значимое и полезное.
Планировщик для pdf отчетов. Теперь можно будет настроить отправку регулярных отчетов себе на почту или куда-то еще. Интересная и полезная возможность. Для руководства в самый раз.
Новые расширенные способы агрегации данных. Это следствие использования нового синтаксиса. Примеры этого уже были в заметке, на которую дал ссылку в начале.
Обновлена визуализация. Как я понял, появилась возможность объединять дашборды в виде отдельных страниц на одном экране. В целом, полезно. Сам часто думаю о том, что переключаться между дашбордами не очень удобно и быстро. Надо бы это как-то упростить. Придумали поместить их во вкладки на дашборде. Посмотрим, удобно ли будет на практике.

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

Новые api токены с истекающим сроком действия.
Tags стали поддерживаться еще большим количеством объектов (templates, hosts, host prototypes, triggers, metrics, events)
У шаблонов появились уникальные ID, теперь не будем с одинаковыми именами путаться.
Улучшено масштабирование.
Появились какие-то Global scripts. Из описания не понял, для чего они.
Появились локальные value maps. Раньше все глобально хранилось в одном месте.
Добавились интеграции с Brevis, Express, iTop, RocketChat, Signal, VictorOps.
Добавились шаблоны для APC UPS hardware, Hikvision cameras, etcd, Hadoop, Zookeeper, Kafka, AMQ, HashiCorp Vault, MS Sharepoint, MS Exchange, smartclt, Gitlab, Jenkins, Apache Ignite и других.

Ну и много других более мелких изменений. Я пробежался глазами по release_notes и перевел то, что показалось наиболее интересным. В общем, Zabbix не стоит на месте, развивается. Свою нишу в мониторинге удерживает твердо. Если кто-то не читал мою статью про сравнение Zabbix vs Prometheus, можете ознакомиться. Описал своими словами отличия.

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

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

Также отдельно обращаю внимание, что с большой долей вероятности сломается интеграция с Grafana, если в метриках использовали Applications, так как их в 5.4 отменили и заменили полностью триггерами. Будете получать ошибку: Method not found

Incorrect API «application».

Настройка Zabbix agent в Windows

Предполагается, что у вас уже настроен сервер мониторинга Zabbix и подключены клиенты, которые ему передают информацию. В данном материале я не буду касаться непосредственно установки и настройки сервера Zabbix, это будет отдельный материал. Сейчас же мы берем готовый файл конфигурации агента zabbix_agentd.win.conf и добавляем в самый конец файла следующие строки:

UserParameter=Temperature.CPU, C:\OpenHardwareMonitor\CPUTemperature.bat
UserParameter=Temperature.Mother, C:\OpenHardwareMonitor\MotherTemperature.bat

Перезапускаем службу агента Zabbix, чтобы изменения вступили в силу.

Подготовка сервера к установке

Начинаем традиционно с подготовки рабочего окружения. Первым делом вам необходимо установить и настроить сервер CentOS 7. Дальше нам нужно настроить web сервер для работы интерфейса управления. У меня есть подробный материал на тему настройки web сервера на centos 7, можете ознакомиться с ним и настроить внимательно и осмысленно. Далее я буду просто приводить команды установки, без пояснений. В этой статье я буду делать стандартную установку Zabbix на традиционный веб сервер apache + php. Если вы хотите, чтобы ваш заббикс работал на веб сервере nginx + php-fpm, читайте отдельный материал по установке zabbix на nginx и php-fpm.

# yum -y update

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

# mcedit /etc/sysconfig/selinux

Редактируем строку:

SELINUX=disabled

и перезагружаемся.

Теперь установим mariadb. Ее необходимо ставить отдельно, почему-то она не устанавливается как необходимая зависимость при установке самого сервере zabbix.

На всякий случай упомяну для тех, кто не знает, что такое mariadb и почему мы ставим ее, а не mysql. Mariadb — ответвление mysql. Они полностью совместимы, возможен в любой момент переход с одной субд на другую и обратно. Есть информация, что mariadb пошустрее работает mysql и люди потихоньку перебираются на нее. Разработчики CentOS начиная с версии 7 предлагают ее как сервер баз данных по-умолчанию.

# yum install -y mariadb mariadb-server

Запускаем mariadb и добавляем ее в автозагрузку:

# systemctl start mariadb
# systemctl enable mariadb.service

Отрабатываем скрипт первоначальной настройки mysql:

# /usr/bin/mysql_secure_installation

Все подготовительные работы выполнены, двигаемся дальше.

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

Давайте настроим уведомления о проблемах на сайте. Я предлагаю 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

Основная наша идея заключалась в том, чтобы сделать в 1С HTTP-сервис, через который Zabbix будет забирать информацию из базы данных и строить на ее основании метрики, триггеры и оповещения.

Для начала разберемся, что такое узлы сети.

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

В нашем случае, узлы сети – это торговые точки, производства, города и даже базы 1С. Это то, по чему мы хотим получать информацию.

На слайде показан узел сети – торговая точка сети СушиВок Санкт-Петербурга:

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

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

На примере, показанном на слайде, макросы узла сети – это:

адрес URL базы, где находится торговая точка;
GUID данной точки.

Таким образом узлы сети — это элементы бизнеса, которые необходимо мониторить.

Переходим к элементам данных.

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

Итак, метрика – это конкретный фрагмент данных, получаемый от узла сети.

Мы подразделяем метрики на «родительские» и зависимые.

«Родительские» метрики с некоторой периодичностью отправляют в 1С JSON с нужными ключами метрик, а в ответ получают из 1С JSON с такой же структурой, но уже с полученными данными.

В примере мы отсылаем ключи метрик:

MaxTimeKitchen – максимальное время отдачи кухни;
CountOrdersInKitchen – количество заказов на кухне и т.д.

И вместе с каждым ключом метрик отправляем $STOREGUID – это тот самый пользовательский макрос из узла сети.

На следующем слайде представлен пример JSON-структуры, полученной из базы 1С. Здесь мы видим результаты запрошенных метрик – например, максимальное время отдачи кухни равно 9 минутам, а активных заказов сейчас 2.

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

В примере на слайде мы видим зависимую метрику «Совокупное время доставки», которая обновилась в 22:29 и получила информацию, что данный параметр равен 35 минутам.

Разбор JSON в Zabbix стал возможен с версии 4.0, которая вышла в 2018 году.

Как это выглядит на практике

Что можно мониторить с помощью LLD? Да все что угодно! Главное — чтобы на хосте было большое количество объектов. Также желательно, чтобы объекты имели структуру. Хороший пример — мониторинг количества сообщений в очередях на сервере RabbitMQ. Общее количество очередей на сервере может быть больше ста штук. А из структуры объектов нам понадобятся только имя очереди на сервере и количество сообщений за последнюю минуту.

Итак, ставим себе задачу.

Собирать количество сообщений в очереди AMQP на сервере.
В том случае, если в очереди скопилось больше пяти сообщений за пять минут, вывести триггер предупреждения. Если свыше 100 за 30 минут, то триггер повышается до статуса чрезвычайного.

Zabbix Agent

Install the repository configuration package. This package contains yum configuration files.

yum install -y http://repo.zabbix.com/zabbix/3.0/rhel/7/x86_64/zabbix-release-3.0-1.el7.noarch.rpm
yum install zabbix-agent -y

grep -q '^Server=' /etc/zabbix/zabbix_agentd.conf && sed -i 's/^Server=.*/Server=localhost/' /etc/zabbix/zabbix_agentd.conf || echo 'Server=10.254.236.71' >> /etc/zabbix/zabbix_agentd.conf

grep -q '^ServerActive=' /etc/zabbix/zabbix_agentd.conf && sed -i 's/^ServerActive=.*/ServerActive=localhost/' /etc/zabbix/zabbix_agentd.conf || echo 'ServerActive=localhost' >> /etc/zabbix/zabbix_agentd.conf

grep -q '^Hostname=' /etc/zabbix/zabbix_agentd.conf && sed -i "s/^Hostname=.*/Hostname=`hostname`/" /etc/zabbix/zabbix_agentd.conf || echo "Hostname=`hostname`" >> /etc/zabbix/zabbix_agentd.conf


systemctl restart zabbix-agent
systemctl enable zabbix-agent

Заключение

Напоминаю, что с обновлением 5.4 появились и новые шаблоны. Они автоматически не появятся у вас на сервере. Их нужно будет скачать и импортировать вручную из репозитория — https://github.com/zabbix/zabbix/tree/release/5.4/templates. Это же касается и способов оповещения, которые регулярно добавляются. Если не обновили их вручную при переходе на 5-ю ветку, то так же можете забрать их из репы и импортировать к себе на сервер.

Онлайн курсы по Mikrotik

Знания, ориентированные на практику;
Реальные ситуации и задачи;
Лучшее из международных программ.

Заключение

Напоминаю, что с обновлением 5.2 появились новые шаблоны. Они автоматически не появятся у вас на сервере. Их нужно будет скачать и импортировать вручную из репозитория — https://github.com/zabbix/zabbix/tree/master/templates. Это же касается и способов оповещения, который много добавилось в 5-й версии. Если не обновили их вручную при переходе на 5-ю ветку, то так же можете забрать их из репы и импортировать к себе на сервер.

Онлайн курс «DevOps практики и инструменты»

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, научиться непрерывной поставке ПО, мониторингу и логированию web приложений, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров.

Проверьте себя на вступительном тесте и смотрите программу детальнее по .