Введение
За основу мониторинга Mikrotik я возьму стандартный шаблон Zabbix от разработчиков. Он очень качественно сделан. Забирает информацию по snmp. Итемы и триггеры настраиваются через автообнаружение. Вот основные метрики, которые в нем реализованы:
- Состояние процессоров (загрузка, температура).
- Статус и характеристика интерфейсов (трафик, активность, ошибки, тип, скорость).
- Хранилища (общий объем и используемый).
- Использование оперативной памяти.
- Проверка доступности пингом.
- Версия прошивки, модель, система, серийный номер, расположение, описание устройства.
- Время работы (uptime).
Для всех основных метрик есть графики. На все значимые события настроены триггеры:
- Высокая температура процессора.
- Изменение серийного номера, прошивки.
- Сетевая недоступность по icmp.
- Высокая загрузка памяти или процессора.
- Окончание свободного места на хранилищах.
- Уменьшилась скорость на интерфейсе.
- Высокая утилизация интерфейса.
- Большое количество ошибок на интерфейсе.
- Интерфейс отключился.
Шаблон настолько хорош и полон, что я даже не придумал, чего в нем не хватает. По метрикам есть все. Для полного мониторинга Микротика мне не хватало только оповещений о том, что к нему кто-то подключился. Я реализовал это по своему, о чем расскажу далее подробно. В двух словах мониторинг подключений выглядит так:
- Mikrotik отправляет логи подключений на удаленный syslog сервер.
- На syslog сервере логи анализирует zabbix-agent.
- По определенному шаблону агент определяет имя и ip адрес подключившегося к микротику и отправляет эту информацию в уведомлении.
В целом, никаких сложностей в этой настройке нет. У меня уже есть статьи по сбору логов с микротиков — отправка в elk stack и на удаленный rsyslog сервер. Сегодня я актуализирую эту информацию и опишу еще раз.
Если вы не очень хорошо знакомы с описываемым роутером, рекомендую мою статью по базовой настройке микротика.
Если у вас еще нет своего сервера для мониторинга, то рекомендую материалы на эту тему. Для тех, кто предпочитает систему CentOS:
- Установка CentOS 8.
- Настройка CentOS 8.
- Установка и настройка zabbix сервера.
То же самое на Debian 10, если предпочитаете его:
- Установка Debian 10.
- Базовая настройка Debian.
- Установка и настройка zabbix на debian.
А что там с JMX обнаружением?
JMX обнаружение появилось в Zabbix одновременно с появлением нативной поддержки мониторинга Java приложений через JMX. За эту функцию отвечает недокументированный (на тот момент) ключ jmx.discovery. В документации о нём не было ни слова, потому что это была ещё очень сырая функция:
- В таком обнаружении нет особого смысла, потому что нет никаких возможностей для фильтрации. А вряд ли кому-то требуется обнаруживать все существующие JMX-объекты.
- Это очень медленное решение, т.к. здесь выполняется по одному запросу на каждый MBean, а их может быть довольно много. Очень вероятно, что такая проверка просто отвалится по таймауту.
- В таком виде можно создать лишь одно правило обнаружения в рамках хоста, что весьма печально, потому что на практике хотелось бы создавать множество правил (банально могут отличаться типы данных для разных атрибутов).
В Zabbix 3.4 появилась возможность фильтрации, что сразу решает многие проблемы.
Новая проверка выглядит так:
И позволяет указать, требуется ли обнаружение MBean’ов или их атрибутов, а также по какому шаблону их искать.
Давайте попробуем её в деле! Замониторим, к примеру, сборщики мусора. Известно, что их имена могут различаться в зависимости от того, с какими параметрами запущена JVM. А значит мы не можем задать статичные имена и ключи для элементов данных — это работёнка как раз для jmx.discovery.Документация описывает нам четыре примера использования:
| Ключ | Описание |
|---|---|
| Получение всех JMX MBean атрибутов | |
| Получение всех JMX MBeans | |
| Получение всех атрибутов сборщика мусора | |
| Получение всех сборщиков мусора |
Первые два варианта мы использовать не будем, т.к. это не очень хорошо с точки зрения производительности. Посмотрим, что возвращают нам два последних.
Для этой цели мы можем просто создать item с нужным нам ключом и текстовым типом данных. Но это не очень удобно. Во-первых, вывод будет неформатированным и ненаглядным. Во-вторых, чтобы изменить запрос, нам всякий раз придётся изменять ключ item’а и какое-то время ждать обновления данных.
Это не наш путь. Давайте лучше сделаем что-то вроде zabbix_get, только вместо агента будем обращаться к Java Gateway. Для этого немного доработаем предложенный в этой заметке скрипт под новый API: добавим jmx_endpoint в запрос и поправим удаление заголовка из ответа:
Теперь мы с лёгкостью можем посмотреть, что возвращает нам шлюз в ответ на наши запросы:
То что нужно!
Если бы нам требовалась, допустим, всего пара метрик, то мы могли бы обнаружить все gc и создать на каждую метрику по прототипу.
Создаём правило обнаружения
Ищем MBean’ы (кстати, обратите внимание, что везде используется кастомный JMX endpoint).
Создаём прототипы на каждую интересующую нас метрику. В имени элемента данных и его ключе мы можем использовать любые макросы, которые видели в JSON’е.
Кстати, о макросах. При обнаружении MBean’ов макросы генерируются динамически на основе свойств MBean’ов (таких как type и name).
Но, допустим, мы хотим создать все доступные числовые метрики по сборщикам мусора.
- Тогда мы создадим правило обнаружения атрибутов с фильтром по типу данных.
- И всего лишь один прототип:
Вот таким нехитрым образом можно замониторить любое Java приложение. Дерзайте! 
Step 2: Prepare Zabbix and vCenter for VMware monitoring
a) Create a user on the VMware vCenter server
Zabbix is monitoring VMware using API service (SDK), therefore make sure to create a valid user on the VMware platform (vCenter) that Zabbix server can use.
b) Update Zabbix server configuration file
You need to configure Zabbix server for VMware monitoring. Open zabbix_server.conf file with command: “” and add these VMware parameters anywhere in the file:
StartVMwareCollectors parameter is mandatory, while others are optional. Without VMware collectors, you would receive error “no vmware collector processes started”.
Also, make sure that you have big enough configuration cache or you will receive the error ““. Start with 128M or more and increase gradually if necessary:
Save and exit file (ctrl+x, followed by y and enter).
In order to apply the new settings you need to restart the Zabbix server, so let’s do that:
And that’s all you need to prepare before using VMware template in Zabbix. You can move on to the next step, but if you want to know more about the VMware parameters check out the table below.
| Parameter | Range (default) | Description |
|---|---|---|
| StartVMwareCollectors | 0-250 (0) | Number of pre-forked vmware collector instances. This value depends on the number of VMware services you are going to monitor. Use this formula to calculated required StartVMwareCollectors: servicenum < StartVMwareCollectors < (servicenum * 2).Where servicenum is the number of VMware services, for example, if you have 1 VMware service to monitor set StartVMwareCollectors to 2, if you have 3 VMware services, set it to 5. In most cases, this value should not be less than 2 and should not be 2 times greater than the number of VMware services that you monitor. |
| VMwareCacheSize | 256K-2G (8M) | Shared memory size for storing VMware data. You can view how much cache is utilized on the graph “Zabbix cache usage, % used” on the “Zabbix server” host. Start with 32M and then increase VMware cache size gradually if it is utilized more than 60%. |
| VMwareFrequency | 10-86400 (60) | Delay in seconds between data gathering from a single VMware service. This delay should be set to the least update interval of any VMware monitoring item. |
| VMwarePerfFrequency | 10-86400 (60) | Delay in seconds between performance counter statistics retrieval from a single VMware service. This delay should be set to the least update interval of any VMware monitoring item that uses VMware performance counters. |
| VMwareTimeout | 1-300 (60) | The maximum number of seconds Zabbix vmware collector proccess will wait for a response from VMware service (ESXi hypervisor or vCenter). |
Настройка мониторинга на Zabbix сервере
Теперь идем на сервер. У меня Zabbix установлен на сервере CentOS, хотя это не принципиально. Добавляем новый Item. Пойти можно двумя путями:
- Создать template, в него добавить все items, создать триггеры, графики и назначить этот шаблон нужным серверам.
- К каждому серверу отдельно добавлять только необходимые итемы и вручную добавлять триггеры и графики.
Очевидно, что первым путем идти удобнее и разумнее. Я так и поступил, но в процессе реализации столкнулся с проблемой. Не все сервера имеют одинаковый набор датчиков. Где-то я не смог снять температуру с материнской платы, где-то вместо одного процессора, стояло два и хотелось снимать температуру с обоих камней. Как будет в вашем случае — не знаю. Если все серверы однотипные, то создавайте template, если все разные, то вручную добавляйте каждый итем на сервер. Я в итоге сделал и шаблон для одинотипных серверов, и вручную добавлял итемы туда, где имелись отличия от шаблона.
Итак, сначала создадим шаблон. Идем в Configurations — Templates — Create Template. Шаблон я назвал Temperature Windows. Добавил в него Application — Temperature, затем Item CPU Temperatue. Заполняем поля итема как у меня на картинке:
Параметр Temperature.CPU тот же самый, что и в файле конфигурации агента.
По аналогии создаем итем Mother Temperatue:
Сохраняем шаблон. По желанию создаем для него триггеры и графики. Можно и без них. Добавляем шаблон к серверу, который хотим мониторить. Ждем некоторое время и идем проверять входящие данные. Открываем Monitoring — Latest data:
Нажимаем graph и смотрим график:
Теперь добавим в Zabbix еще один сервер для мониторинга, который будет отличаться по конфигурации от предыдущего. На его примере я покажу, как менять настройки клиента и сервера. С этого сервера я не могу снять данные с датчика температуры материнской платы, по какой причине — не знаю, но не AIDA64 ни OpenHardwareMonitor мне температуру не показывают. Ее можно взять по SNTP с этого сервера, но это отдельная тема. В этом сервере 2 процессора и я хочу мониторить температуру обоих.
Запускаем GUI интерфейс и смотрим, какие датчики мы сможем мониторить:
Нас будет интересовать температура обоих ядер процессора. Теперь запускаем OpenHardwareMonitorReport.exe с выводом информации в текстовый файл. Смотрим, как выглядят строки с интересующей нас информацией:
| +- CPU Package : 59 59 59 (/intelcpu/0/temperature/6)
| +- CPU Package : 53 53 54 (/intelcpu/1/temperature/6)
Создаем два bat файла следующего содержания:
CPU1Temperature.bat
@echo off for /F "usebackq tokens=7-10" %%a in (`C:\OpenHardwareMonitor\OpenHardwareMonitorReport.exe`) do echo %%b %%c %%d| find "/intelcpu/0/temperature/6">nul && set temper=%%a echo %temper%
CPU2Temperature.bat
@echo off for /F "usebackq tokens=7-10" %%a in (`C:\OpenHardwareMonitor\OpenHardwareMonitorReport.exe`) do echo %%b %%c %%d| find "/intelcpu/1/temperature/6">nul && set temper=%%a echo %temper%
Редактируем конфигурационный файл zabbix_agentd.win.conf агента Zabbix на клиенте. Добавляем в конец две строки:
UserParameter=Temperature.CPU1, C:\OpenHardwareMonitor\CPU1Temperature.bat UserParameter=Temperature.CPU2, C:\OpenHardwareMonitor\CPU2Temperature.bat
Перезапускаем службу агента, чтобы изменения вступили в силу.
Дальше идем на сервер Zabbix и по аналогии с предыдущим сервером создаем там Итемы мониторинга. Причем итемы создаем не в шаблоне, а в конкретном сервере, который будем мониторить. Параметр key в этих итемах будет соответственно Temperature.CPU1 и Temperature.CPU2 Ждем некоторое время и проверяем результат.
Может лучше на практике?
Нет ничего проще Давайте для примера попробуем настроить мониторинг JBoss EAP 6.4.
Для начала сделаем несколько предположений:
- Вы уже установили Zabbix 3.4 и Zabbix Java Gateway. Если еще нет, то вы можете сделать это в соответствии с документацией Zabbix.
- Zabbix Server и Java Gateway с префиксом /usr/local/.
- JBoss уже установлен в /opt/jboss-eap-6.4/ и запускается в standalone режиме.
- Для простоты эксперимента будем считать, что все эти компоненты работают на одной и той же машине.
- Firewall и SELinux отключены (или настроены соответствующим образом, но это выходит за рамки статьи).
Сделаем несколько простых настроек в zabbix_server.conf:
И в конфиге zabbix_java/settings.sh (или zabbix_java_gateway.conf):
Проверьте, что JBoss слушает свой стандартный management port:
Теперь давайте создадим в Zabbix хост с JMX интерфейсом 127.0.0.1:9999.
Если мы сейчас просто возьмём стандартный шаблон «Template App Generic Java JMX» и прилинкуем его к хосту, то наверняка получим ошибку:
Java Gateway сообщает нам, что по указанному endpoint отвечает совсем не RMI. Хорошо, мы уже знаем, что эта версия JBoss использует протокол JBoss Remoting вместо RMI, и нам нужно лишь начать стучаться в правильный endpoint.
Давайте сделаем Full Clone шаблона «Template App Generic Java JMX» и назовём его «Template App Generic Java JMX-remoting». Выделим все элементы данных внутри этого шаблона и выполним операцию Mass update для параметра JMX endpoint. Пропишем такой URL:
Обновим конфигурационный кэш:
И снова ошибка.
Что на этот раз?
“Unsupported protocol: remoting-jmx” означает, что Java Gateway не умеет работать с указанным протоколом. Что ж, давайте его научим. В этом нам поможет совет из статьи «JBoss EAP 6 monitoring using remoting-jmx and Zabbix».
Создадим файл ~/needed_modules.txt со следующим содержимым:
Выполним команду:
Таким образом, Java Gateway будет иметь все необходимые модули для работы с jmx-remoting. Остаётся лишь перезапустить Java Gateway, немного подождать и, если вы всё сделали правильно, увидеть, что заветные данные начали поступать в Zabbix:
Настройка Zabbix для мониторинга standalone ESXi server
Всем доброго времени суток! На днях впервые устанавливал Zabbix и столкнулся с проблемой мониторинга standalone VMware ESXi 6.0. Проблема заключалась в том, что стандартные шаблоны Zabbix предусматривают мониторинг через vCenter и в случае standalone не срабатывают.
Начальную установку и настройку Zabbix в этой статье пропускаем и приступаем сразу к обнаружению нашего standalone хоста. Мы имеем установленный и настроенный Zabbix 4.2.5 на Ubuntu server (18.04), ESXi 6.0 с парой машин внутри. Перед началом действий советую создать для Zabbix отдельного юзера в ESXi с правами Read-only, это позволит не отвлекаться в середине пути.
Настройка протокола SNMPv3 на ESXI
Выше мы рассмотрели, как включить и настроить на хостах ESXi SNMP агент версии 1 и 2. Начиная с ESXi 5.1 поддерживается более современная версия протокола – SNMP v3. Чтобы настроить более безопасный протокол SNMPv3, воспользуйтесь следующими командами.
Задаем протоколы аутентификации и шифрования:
Генерируем хэши для паролей аутентификации и шифрования (замените authpass и privhash на нужный пароль):
С помощью полученных хэшей (authhash и privhash), добавим пользователя:
Теперь нужно указать SNMP-таргет:
Вы можете удаленно проверить SNMP конфигурацию с помощью Linux утилиты snmpwalk:
Я ничего не понял. JMX, RMI, JNDI? WTF?
Хорошо-хорошо, давайте немного разберёмся, как всё это работает.JMX (Java Management Extensions) — технология Java, предназначенная для мониторинга и управления (в т.ч. удалённо) различными объектами (ресурсами): приложениями, устройствами, сетями — лишь бы этот объект был написан на Java.
Эти ресурсы называются MBeans (ManagedBeans). Каждый такой объект реализует определённый интерфейс, через который можно получить доступ к значениям атрибутов этого объекта, а также вызвать его методы и получать уведомления (если приложение зарегистрирует соответствующие “слушающие” MBean’ы).
MBeans регистрируются на MBean Server — реестре объектов. Любой зарегистрированный объект становится доступным для приложений (точнее, становится доступным его интерфейс).
Доступ к ресурсам осуществляется при помощи JMX-коннекторов, которые делают MBean Server доступным для JMX-клиентов. JMX-коннектор состоит из клиента и сервера. Коннектор-сервер соединяется с MBean-сервером и слушает запросы соединений от клиентов. Коннектор-клиент обычно находится на другой JVM, а чаще всего вообще на другой машине по отношению к коннектор-серверу.
JMX API имеет стандартный протокол подключения, основанный на Remote Method Invocation (RMI). Этот протокол позволяет JMX-клиенту удалённо получить доступ к MBean’ам на MBean-сервере. Кроме штатного RMI существуют и другие протоколы: JMXMP, JBoss Remoting, Hessian, Burlap, и даже HTTP и SNMP.
Используя интерфейс MBean’а клиент может получать различные метрики этого объекта, а также вызывать публичные методы.
Схематично взаимодействие компонентов можно изобразить так:
Любое приложение на платформе Java SE “из коробки” имеет возможности для его мониторинга: RMI коннектор автоматически делает доступным ваше Java приложение для удалённого управления и мониторинга. Достаточно лишь запустить приложение с нужными параметрами, и JMX-клиенты (а Zabbix Java Gateway — это JMX-клиент) уже смогут подключаться к нему удалённо и получать нужные метрики.
Чтобы указать JMX-клиенту конкретное приложение, к которому вы хотите подключиться, используется специальный адрес, который называется JMX endpoint (он же JMXServiceURL). Если говорить строже, то это адрес коннектор-сервера JMX API. Формат этого адреса определяется RFC 2609 и RFC 3111. В общем случае он выглядит так:
Где «service:jmx:» — константа.
protocol — это транспортный протокол (один из многих: RMI, JMXMP, etc), используемый для подключения к коннектор-серверу.sap — адрес, по которому коннектор-сервер может быть найден. Задаётся в таком формате (это подмножество синтаксиса, определённого в RFC 2609):
host — ipv4 адрес хоста (или ipv6, заключённый в квадратные скобки) и необязательный (в зависимости от протокола) номер порта.url-path — необязательный URL (обязательность зависит от протокола).
Лучше всего разобраться с этим на примере. Часто можно встретить такой JMX endpoint, вид которого некоторых может ввести в ступор:
Но на самом деле не всё так страшно.host — это целевой хост, где запущено наше приложение.port1 — это порт RMI-сервера, к которому мы хотим подключиться.
а port2 — это порт RMI registry (каталог, где регистрируются RMI-серверы). По умолчанию: 1099.
Если знать о том, что RMI-реестр выдаёт адрес и порт RMI-сервера по запросу клиента, то становится понятно, что первая часть здесь лишняя. Таким образом адрес можно сократить до такого вида:url-path часть означает буквально следующее: возьми ту часть URL, которая следует сразу за /jndi/ и выполни по этому адресу JNDI-запрос в RMI registry, чтобы получить информацию об RMI-сервере. Реестр вернёт в ответ его хост и порт.
Следует отметить, что порт в таком случае генерируется случайным образом и могут возникнуть проблемы с настройкой файрвола. В таких случаях и записи JMX endpoint’а, потому что он позволяет явно указать порт.
Если вам хотелось бы глубже разобраться в JMX, то рекомендуем обратиться к официальной документации Oracle.
Дополнительные материалы по Zabbix
Онлайн курс «DevOps практики и инструменты»
Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, научиться непрерывной поставке ПО, мониторингу и логированию web приложений, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров.
Проверьте себя на вступительном тесте и смотрите программу детальнее по .
| Рекомендую полезные материалы по Zabbix: |
| Настройки системы |
|---|
Видео и подробное описание установки и настройки Zabbix 4.0, а также установка агентов на linux и windows и подключение их к мониторингу. Подробное описание обновления системы мониторинга zabbix версии 3.4 до новой версии 4.0. Пошаговая процедура обновления сервера мониторинга zabbix 2.4 до 3.0. Подробное описание каждого шага с пояснениями и рекомендациями. Подробное описание установки и настройки zabbix proxy для организации распределенной системы мониторинга. Все показано на примерах. Подробное описание установки системы мониторинга Zabbix на веб сервер на базе nginx + php-fpm. |
| Мониторинг служб и сервисов |
Мониторинг температуры процессора с помощью 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. Отправка оповещений по событиям из лога. |
Служба SNMP Server в VMWare ESXi
Из веба интерфейса vSphere вы можете только проверить, что служба SNMP сервер запушена, изменить режим ее запуска, остановить/перезапустить сервис. Перейдите на свой ESXi хост -> Configure -> Services -> SNMP Server. По умолчанию служба остановлена. Запустите ее.
Включите SSH доступ на ESXi хосте и подключитесь к нему любым ssh-клиентом (я использую встроенный OpenSSH клиент Windows 10).
Чтобы проверить текущие настройки SNMP, выполните команду:
SNMP не настроен: все параметры пустые, агент отключен:
Authentication: Communities: Enable: false Engineid: Hwsrc: indications Largestorage: true Loglevel: info Notraps: Port: 161 Privacy: Remoteusers: Syscontact: Syslocation: Targets: Users: V3targets:
Step 4: Learn how VMware monitoring works in Zabbix
VMware monitoring on Zabbix can be implemented in a few minutes, but it may be challenging for beginners to understand how everything works.
Zabbix has the 3 templates for monitoring the VMware system: “Template VM VMware“, “Template VM VMware Guest”, and “Template VM VMware Hypervisor“, but you only place one template on the host in Zabbix. Who sets the other two templates on hypervisors and VMs? How and when are hypervisors and virtual machines discovered?
There’s that old saying “A picture is worth a thousand words”, so I drew the whole process so that you can understand better how Zabbix monitors VMware virtual environment.
How VMware monitoring works in Zabbix
As you can see in the picture, after the user has created a host (with the appropriate template and macros), Zabbix will start collecting data over the VMware API service (SOAP). Note that in the latest VMware templates, macros are configured on the template “Template VM VMware macros“.
Within an hour, Zabbix low-level discovery (LLD) feature will start discovering VMware ESXi hypervisors, datastores, clusters, and VMs.
And now comes the key part, using his low-level discovery host prototype feature Zabbix will create a host for each VMware ESXi hypervisor and virtual machine (VM) and set the appropriate template on them respectively. Now, those templates have their own low-level discovery so within an hour they will start to discover datastores, disks, filesystems, network interfaces on the newly created hosts.
When hypervisor and virtual machines are discovered, those prototypes become actual hosts are added to the host groups “Hypervisors” and “Virtual machines” respectively. However, they still belong to an existing host and will take the IP address of the existing host.
There are few things to note about the datastore monitoring, but more about that in the next step.
Note, consider using the Zabbix agent for server monitoring and disabling limited VMware guest virtual machine discovery. With the Zabbix agent, you can monitor virtually anything at the OS level. Check out this step-by-step Linux and Windows server monitoring guide.
Триггеры шаблона
Для полноты картины, поясню остальные триггеры шаблона, чтобы у вас было понимание, за чем они следят и как правильно реагировать на них. Ниже список триггеров шаблона для мониторинга mysql сервера.
- Buffer pool utilization is too low (less {$MYSQL.BUFF_UTIL.MIN.WARN}% for 5m) — под innodb пул выделено слишком много памяти и она не используется вся. Триггер чисто информационный, делать ничего не надо, если у вас нет дефицита памяти на сервере. Если нехватка оперативной памяти есть, то имеет смысл забрать немного памяти у mysql и передать другому приложению. Настраивается потребление памяти пулом параметром innodb_buffer_pool_size.
- Failed to get items (no data for 30m) — от mysql сервера не поступают новые данные мониторинга в течении 30 минут. Имеет смысл уменьшить этот интервал до 5-10 минут.
- Refused connections (max_connections limit reached) — срабатывает ограничение на максимальное количество подключений к mysql. Увеличить его можно параметром mysql сервера — max_connections. Его необходимо увеличить, если позволяют возможности сервера. Напомню, что увеличенное количество подключений требует увеличения потребления оперативной памяти. Если у вас ее уже не хватает, нет смысла увеличивать число подключений. Нужно решать вопрос с потреблением памяти.
- Server has aborted connections (over {$MYSQL.ABORTED_CONN.MAX.WARN} for 5m) — сервер отклонил подключений выше заданного порога в макросе. Надо идти в лог mysql сервера и разбираться в причинах этого события. Скорее всего там будут подсказки.
- Server has slow queries (over {$MYSQL.SLOW_QUERIES.MAX.WARN} for 5m) — количество медленных запросов выше установленного макросом предела. Надо идти и разбираться с медленными запросами. Тема не самая простая. Надо заниматься профилированием запросов и решать проблемы по факту — добавлением индексов, редактированием запросов, увеличения ресурсов mysql сервера и т.д.
- Service has been restarted (uptime < 10m) — информационный триггер, срабатывающий на перезапуск mysql сервера (не ребут самого сервера).
- Service is down — служба mysql не запущена.
- Version has changed (new version value received: {ITEM.VALUE}) — версия mysql сервера изменилась. Тоже информационный триггер, сработает, к примеру, после обновления mysql сервера.
Правка конфигурационных файлов служб Zabbix
Базовый файл конфигурации Zabbix
Выполним базовую настройку сервера Zabbix.
Откроем файл конфигурации в текстовом редакторе:
Переведите редактор vi в режим «вставки» клавишей I.
Найдите, раскомментируйте и установите значение для поля пароль вашего пользователя zabbix:
DBPassword=password
Убедитесь также, что указанные параметры соответствуют приведенным:
ListenPort=10051 StartTrappers=5
После этого сохраните файл (Esq, Shift+:, wq).
Файл настройки PHP
Откройте конфигурационный файл
и приведите указанные параметры удовлетворяющими требованиям для системы zabbix:(удалите символ ; — знак комментария перед теми строками параметров, где они встретятся)
max_execution_time = 300 max_input_time = 300 post_max_size = 18M date.timezone = Europe/Moscow memory_limit = 128M upload_max_filesize = 2M
Сохраните изменения.
Правила для сетевого экрана IPTABLES
Установим правило, разрешающее входящие соединения на порт нашего web-сервера:
сохраним новое правило для постоянного использования в iptables:
Параметры системы безопасности SeLinux
Данный компонент системы, по-умолчанию задействованный в системах на базе RedHat, как правило включен в свой максимально «секьюрный» режим, что может при такой конфигурации помешать работе собственного агента сервера, служащего для само-мониторинга в web-панели.
Для деактивации данной системы необходимо выполнить следующие действия.
исправьте параметр на значение указанное ниже:
SELINUX=permissive
Сохраните файл.
Такая настройка отключит блокировку процессов в Selinux — это, конечно не самый безопасный способ для некоторых критичных систем, но при этом самый быстрый. Для описания более тонкой «настройки» Selinux требуется отдельная статья, выходящая за рамки текущего текста.
Для временного отключения блокировок в текущем сеансе, можно выполнить еще одно действие:
Хочу добавить еще одно небольшое дополнение, которое может пригодиться, если вы захотите задействовать в дальнейшем такой инструментарий в администрировании средств наблюдения, как встроенные функции так называемой «Простой проверки» — icmpping и аналогичные ей.
Чтобы иметь возможность «пинговать» серверы, на которые у вас нет возможности/прав устанавливать собственные программы (агенты), на сервер Zabbix должна быть установлена небольшая программа fping. В моем случае она уже была в системе, поэтому дальше опишу некоторые настройки, необходимые для корректной работы с ней системы Zabbix.
FpingLocation=/usr/sbin/fping
(2 эти команды выше — именно в таком порядке)
После этого приступим к проверке работы сервера.
Заключение
В своем материале я рассмотрел два различных способа, с помощью которых можно мониторить любой удаленный сервис по протоколу tcp, либо локальную службу на сервере linux. Конкретно в моих примерах можно было воспользоваться вторым способом в обоих случаях. Я этого не сделал, потому что первым способом я не просто проверяю, что служба запущена, я еще и обращаюсь к ней по сети и проверяю ее корректную работу для удаленного пользователя.
Разница тут получается вот в чем. Допустим, сервер squid у вас запущен и работает на сервере. Проверка работы локальной службы показывает, что сервис работает и возвращает значение 1. Но к примеру, вы настраивали firewall и где-то ошиблись. Сервис стал недоступен по сети, пользователи не могут им пользоваться. При этом мониторинг будет показывать, что все в порядке, служба запущена, хотя реально она не может обслужить запросы пользователей. В таком случай только удаленная проверка покажет, что с доступностью сервиса проблемы и надо что-то делать.
Из этого можно сделать вывод, что система мониторинга zabbix предоставляет огромные возможности по мониторингу. Какой тип наблюдения и сбора данных подойдет в конкретном случае нужно решать на месте, исходя из сути сервиса, за которым вы наблюдаете.
