Мониторинг synology в zabbix

Введение

Традиционно, буду использовать самые простые подручные средства, завернутые в консольные скрипты, которые будут передавать значения в zabbix с помощью UserParameter. Для уменьшения ручной работы, добавление доменов в систему мониторинга будет осуществляться с помощью автообнаружения. Сами списки доменов с сертификатами ssl для проверки будут храниться в текстовых файлах.

У нас будут 2 отдельных списка для проверки:

1. Домены с ssl сертификатами для веб сайтов.
2. Домены с ssl сертификатами для почтовых серверов.

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

Если у вас еще нет готового сервера для мониторинга, предлагаю его настроить по моей статье — установка и настройка zabbix 3.4 на Centos 7. Если предпочитаете Debian, то вот материал на эту тему — установка и настройка zabbix 3.4 на Debian 9. В данном случае все можно сделать на одном сервере — достаточно на один сервер поставить zabbix-server и zabbix-agent.

Введение

За основу мониторинга Mikrotik я возьму стандартный шаблон Zabbix от разработчиков. Он очень качественно сделан. Забирает информацию по snmp. Итемы и триггеры настраиваются через автообнаружение. Вот основные метрики, которые в нем реализованы:

1. Состояние процессоров (загрузка, температура).
2. Статус и характеристика интерфейсов (трафик, активность, ошибки, тип, скорость).
3. Хранилища (общий объем и используемый).
4. Использование оперативной памяти.
5. Проверка доступности пингом.
6. Версия прошивки, модель, система, серийный номер, расположение, описание устройства.
7. Время работы (uptime).

Для всех основных метрик есть графики. На все значимые события настроены триггеры:

• Высокая температура процессора.
• Изменение серийного номера, прошивки.
• Сетевая недоступность по icmp.
• Высокая загрузка памяти или процессора.
• Окончание свободного места на хранилищах.
• Уменьшилась скорость на интерфейсе.
• Высокая утилизация интерфейса.
• Большое количество ошибок на интерфейсе.
• Интерфейс отключился.

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

1. Mikrotik отправляет логи подключений на удаленный syslog сервер.
2. На syslog сервере логи анализирует zabbix-agent.
3. По определенному шаблону агент определяет имя и ip адрес подключившегося к микротику и отправляет эту информацию в уведомлении.

В целом, никаких сложностей в этой настройке нет. У меня уже есть статьи по сбору логов с микротиков — отправка в elk stack и на удаленный rsyslog сервер. Сегодня я актуализирую эту информацию и опишу еще раз.

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

Если у вас еще нет своего сервера для мониторинга, то рекомендую материалы на эту тему. Для тех, кто предпочитает систему CentOS:

1. Установка CentOS 8.
2. Настройка CentOS 8.
3. Установка и настройка zabbix сервера.

То же самое на Debian 10, если предпочитаете его:

1. Установка Debian 10.
2. Базовая настройка Debian.
3. Установка и настройка zabbix на debian.

Введение

Идея настроить мониторинг openvpn подключений с помощью zabbix витала у меня давно, но никак не доходили руки. Когда выбрал время и сел настраивать, сходу не придумал, а как же лучше это сделать. Так как в задаче много нюансов, то и подходов тоже может быть несколько.

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

Перед настройкой решил погуглить и посмотреть, что уже есть из готового. И сразу же нашел вот этот проект — https://github.com/Grifagor/zabbix-openvpn. Идею быстро понял, оценил все плюсы и минусы и решил не заморачиваться сам, а взять готовое, благо тут все в комплекте:

• Скрипты
• Конфиги
• Шаблон с автообнаружением, графиками и триггерами.

Шаблон имеет следующие элементы в своем составе:

1. Итемы для мониторинга за полученным и переданным трафиком пользователя.
2. Итемы для мониторинга за статусом подключения, отключения пользователя.
3. Триггер со срабатыванием на подключение и отключение пользователя.
4. График полученных, отправленных данных в байтах.
5. График со статусом подключения пользователя.
6. Количество подключенных пользователей к openvpn серверу.

Все эти итемы, графики и триггеры создаются автоматически для каждого пользователя.

Минус один и весьма существенный — добавление итемов в виде отдельных пользователей работает через автообнаружение конфигураций пользователей в директории с ccd. Для того, чтобы приведенный способ мониторинга openvpn подключений работал, у вас должны существовать индивидуальные конфигурации пользователей, заданные в конфиге openvpn параметром client-config-dir.

Сами конфигурации пользователей могут быть пустыми. Их содержимое не используется. Они нужны только для того, чтобы получить имя пользователя и затем по этому имени анализировать лог файл состояния openvpn, настроенный с помощью параметра status в конфигурации openvpn сервера.

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

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

Если у вас еще нет своего сервера для мониторинга, то рекомендую материалы на эту тему. Для тех, кто предпочитает систему CentOS:

1. Установка CentOS 8.
2. Настройка CentOS 8.
3. Установка и настройка zabbix сервера.

То же самое на Debian 10, если предпочитаете его:

1. Установка Debian 10.
2. Базовая настройка Debian.
3. Установка и настройка zabbix на debian.

Методика мониторинга времени ответа сервера

Если у вас еще нет своего сервера для мониторинга, то рекомендую материалы на эту тему. Для тех, кто предпочитает систему CentOS:

1. Установка CentOS 8.
2. Настройка CentOS 8.
3. Установка и настройка zabbix сервера.

То же самое на Debian 10, если предпочитаете его:

1. Установка Debian 10.
2. Базовая настройка Debian.
3. Установка и настройка zabbix на debian.

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

Лучше всего создавать шаблон web мониторинга, а не настраивать его на конкретном агенте. Совет этот универсальный для любых метрик, но именно для web мониторинга он более актуальный. Так вы сможете оперативно запускать проверки сайта с разных серверов, где установлены агенты забикса. Плюс, через экспорт шаблона вы легко сможете перенести мониторинг на другой сервер

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

Например, у вас среднее время отклика сайта 200-300 мс. Иногда вы будете видеть на графике всплески до 1500 мс, 2500 мс, 3500 мс. Значения будут кратны одной секунде. Я не нашел подробной информации, как именно заббикс делает мониторинг сайта. Я думаю, что свыше какой-то задержки, он ждет секунду, пробует снова и так далее
Эти данные не стоит брать в расчет.
Не стоит обращать внимание на абсолютные цифры. Все системы измеряют время отклика по-разному
В вебмастере яндекса вы увидите одно значение времени отклика сервера, в его же яндекс.метрике другое, гугл покажет третье, а заббикс четвертное. Отличаться эти значения могут существенно, в 2-3-4 раза. Я использую мониторинг времени отклика сайта в заббиксе для отслеживания динамики. К примеру, вы решили переехать на новый web сервер. Нужно как-то оценить его быстродействие. Вы сравниваете значения в мониторинге на старом сайта, потом на новом и делаете выводы.

По последнему пункту приведу простой пример из недавнего опыта. Я подготовил новый веб сервер. Нужно было оценить, насколько он быстрее работает на том же сайте, чем предыдущий. Я развернул сайт на новом сервере, поправил в файле hosts на сервере с заббикс агентом ip адрес сайта, направив запросы на новый web сервер. Получилась такая картинка.

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

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

• Сетевую систему хостера
• Отклик жестких дисков
• Загруженность ноды виртуальных машин, если переезжаете на VDS.

Вы можете заказать сервер с хорошими параметрами по железу, но не получить быстрого отклика сайта по независящим от вас причинам. С этим столкнулся не так давно, когда пробовал использовать веб сервер у облачного провайдера. На словах все красиво — гибкая настройка параметров, отказоустойчивость, удобный бэкап и т.д. В общем, все то, чем хвалят облака. А на деле время отклика сайта было 300-400 мс при типовых настройках веб сервера. Использовался самый дорогой и быстрый тип диска. На выделенном бюджетном сервере при тех же настройках отклик был 100 мс.

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

Триггеры шаблона

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

1. Buffer pool utilization is too low (less {$MYSQL.BUFF_UTIL.MIN.WARN}% for 5m) — под innodb пул выделено слишком много памяти и она не используется вся. Триггер чисто информационный, делать ничего не надо, если у вас нет дефицита памяти на сервере. Если нехватка оперативной памяти есть, то имеет смысл забрать немного памяти у mysql и передать другому приложению. Настраивается потребление памяти пулом параметром innodb_buffer_pool_size.
2. Failed to get items (no data for 30m) — от mysql сервера не поступают новые данные мониторинга в течении 30 минут. Имеет смысл уменьшить этот интервал до 5-10 минут.
3. Refused connections (max_connections limit reached) — срабатывает ограничение на максимальное количество подключений к mysql. Увеличить его можно параметром mysql сервера — max_connections. Его необходимо увеличить, если позволяют возможности сервера. Напомню, что увеличенное количество подключений требует увеличения потребления оперативной памяти. Если у вас ее уже не хватает, нет смысла увеличивать число подключений. Нужно решать вопрос с потреблением памяти.
4. Server has aborted connections (over {$MYSQL.ABORTED_CONN.MAX.WARN} for 5m) — сервер отклонил подключений выше заданного порога в макросе. Надо идти в лог mysql сервера и разбираться в причинах этого события. Скорее всего там будут подсказки.
5. Server has slow queries (over {$MYSQL.SLOW_QUERIES.MAX.WARN} for 5m) — количество медленных запросов выше установленного макросом предела. Надо идти и разбираться с медленными запросами. Тема не самая простая. Надо заниматься профилированием запросов и решать проблемы по факту — добавлением индексов, редактированием запросов, увеличения ресурсов mysql сервера и т.д.
6. Service has been restarted (uptime < 10m) — информационный триггер, срабатывающий на перезапуск mysql сервера (не ребут самого сервера).
7. Service is down — служба mysql не запущена.
8. Version has changed (new version value received: {ITEM.VALUE}) — версия mysql сервера изменилась. Тоже информационный триггер, сработает, к примеру, после обновления mysql сервера.

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

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

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

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

Установка и запуск proxy

Из репозитория Zabbix

# apt install zabbix-proxy-sqlite3

# mkdir /var/lib/zabbix

# zcat /usr/share/doc/zabbix-proxy-sqlite3/schema.sql.gz | sqlite3 /var/lib/zabbix/zabbix.db

# chown -R zabbix:zabbix /var/lib/zabbix

# vim /etc/zabbix/zabbix_proxy.conf

...
Hostname=gate
ConfigFrequency=60
Server=server
DBName=/var/lib/zabbix/zabbix.db

Debian 10

gate# apt install zabbix-proxy-mysql

gate# cat zabbix_proxy.sql

#drop database zabbix_proxy;
create database zabbix_proxy character set utf8 collate utf8_bin;
grant all privileges on zabbix_proxy.* to zabbix@localhost identified by 'zabbix';

gate# mysql < zabbix_proxy.sql

gate# zcat /usr/share/zabbix-proxy-mysql/schema.sql.gz | mysql -uzabbix -pzabbix zabbix_proxy

gate# cat /etc/zabbix/zabbix_proxy.conf

...
Hostname=gate
ConfigFrequency=60
Server=server
DBHost=localhost
DBName=zabbix_proxy
DBUser=zabbix
DBPassword=zabbix

gate# systemctl enable zabbix-proxy

gate# service zabbix-proxy start