Диагностика работы zabbix

Введение

Если у вас еще нет почтового сервера, то читайте как установить и настроить почтовый сервер postfix, а если нет сервера мониторинга, то соответственно вот это — установка и настройка zabbix на centos или то же самое на debian. Для мониторинга я буду использовать известную утилиту pflogsumm, которая анализирует почтовый лог postfix. В разных системах он может называться по-разному:

/var/log/mail.log в debian и ubuntu
/var/log/maillog в centos и freebsd

Само содержание будет одно и то же, поэтому статья будет актуальна для любого сервера с postfix и любой версией мониторинга zabbix. Я за основу возьму bash скрипт, который чаще всего попадается, если в поисковике поискать что-то на тему мониторинга postfix в заббиксе. Не знаю, кто у кого его скопировал изначально, поэтому автора указывать не буду. Сам скрипт достаточно простой, я расскажу подробно что он делает и как работает, чтобы вы понимали и по возможности могли его изменить так, как вам потребуется.

Я буду показывать на примере системы CentOS. Нам понадобится установить утилиту pflogsumm. Делается это просто.

# yum install postfix-pflogsumm

Тома DFSR (DFS Replication Service Volumes)

Параметры:

состояние (state);
данные счетчиков производительности.

Два правила обнаружения: DFS Replication Service Volumes LLD и DFS Replication Service Volumes PerfCounters LLD. Первое — для параметра state, который может принимать следующие значения:

Initialized (0)
Shutting Down (1)
In Error (2)
Auto Recovery (3)

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

Партнеры (DFS Replication Partners)

Параметры:

доступность по PING (ping check);
доступность по WMI (WMI check).

За оба параметра отвечает правило обнаружения DFS Replication Partners LLD. Как следует из названия, это два типа проверки: проверяется, может ли хост «достучаться» до каждого из партнеров по ICMP и WMI. Подключение по WMI будет выполняться под учетной записью, из-под которой работает служба zabbix-агента. При этом единственное назначение WMI-проверки — убедиться, что установленный на хосте агент может связаться с DFSR-партнером для сбора параметров backlog size и redundancy (они были описаны выше при разборе метрик для реплицируемых папок). А для этого необходимо, чтобы учетная запись zabbix-агента обладала правами локального администратора на каждом из партнеров. Иными словами, WMI-проверка подскажет, если у учетной записи агента не хватает прав на каком-либо из партнеров. Выглядеть это будет вот так:

Общее состояние (General)

Параметры:

установлена ли роль DFSR (DFS Replication role installed);
количество групп репликации, в которые входит сервер (Number of replication groups);
количество ошибок и предупреждений в журнале событий DFSR (DFSR Event Log);
состояние службы (DFS Replication service state);
аптайм службы (DFS Replication service uptime);
версия службы (DFSR Service Version);
версия поставщика DFSR (DFSR Provider Version);
версия поставщика мониторинга DFSR (DFSR Monitoring Provider Version);

Последние два параметра по умолчанию отключены.

Здесь правила обнаружения не нужны, поэтому все параметры находятся в разделе Items шаблона.

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

DFSR Event Log: number of warnings
DFSR Event Log: number of errors
DFSR Event Log: number of critical errors

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

{$DFSRLOGCRITICALMAX} — количество событий со статусом «Критическое» в логе DFSR, при превышении которого должен срабатывать high-триггер (по умолчанию 0);

{$DFSRLOGERRORSMAX} — количество событий со статусом «Ошибка» в логе DFSR, при превышении которого должен срабатывать average-триггер (по умолчанию 0);

{$DFSRLOGWARNINGSMAX} — количество событий со статусом «Предупреждение» в логе DFSR, при превышении которого должен срабатывать warning-триггер (по умолчанию 0);

{$DFSRLOGPERIOD} — за какое время надо анализировать лог (по умолчанию 1 час)

Состояние службы может принимать такие значения:

Service Starting (0)
Service Running (1)
Service Degraded (2)
Service Shutting Down (3)
Stopped (100)
Not Found (101)

Остальные параметры разбирать не буду, там всё ясно из названия.

Настройка в zabbix мониторинга nginx

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

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

Суть мониторинга Nginx будет сводиться к тому, что мы через агента станем забирать страницу http://localhost/nginx-status на сервер. Там с помощью регулярных выражений и зависимых элементов данных будем формировать нужные метрики.

Представляю вам готовый шаблон для мониторинга nginx. Скачиваем его zabbix-nginx-template.xml и открываем web интерфейс zabbix сервера. Идем в раздел Configuration -> Templates и жмем Import:

Выбираем файл и снова нажимаем Import:

Шаблон я подготовил сам на основе своих представлений о том, что нужно мониторить. Проверил и экспортировал его с версии 4.2 Регулярные выражения для парсинга html страницы статуса подсмотрел тут — https://github.com/AlexGluck/ZBX_NGINX. К представленному шаблону я добавил некоторые итемы и переделал все триггеры. Плюс убрал макросы. Не вижу в них в данном случае смысла.

В шаблоне 11 итемов, описание которых я привел ранее.

Подробнее остановимся на триггерах. Их 5 штук.

Many active connections — срабатывает если среднее количество соединений за последние 10 минут больше в 3 раза, чем среднее количество за интервал на 10 минут ранее.
many requests и too many requests — срабатывают, когда среднее количество запросов за последние 10 минут больше в 3 и 6 раз соответственно, чем на 10 минут ранее.
nginx is not running — тут все просто. Если не запущен ни один процесс nginx, шлем уведомление.
nginx is slow to respond — срабатывает если время выполнения запроса на получение страницы со статусом за последние 10 минут больше предыдущих 10 минут в 2 раза.

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

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

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

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

С мониторингом nginx почти все готово. Теперь нам нужно прицепить добавленный шаблон к web серверу, который мы мониторим и дождаться поступления данных. Проверить их можно в Monitoring -> Latest Data:

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

На этом настройка мониторинга nginx закончена, можно пользоваться.

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

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

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

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

Настройки системы
Рекомендую полезные материалы по 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. Отправка оповещений по событиям из лога.

Добавляем UserParameter в zabbix agent

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

UserParameter=pump_1, C:\zabbix\parser\pump_1.bat
UserParameter=time_pump_1, C:\zabbix\parser\time_pump_1.bat
UserParameter=state, C:\zabbix\parser\state.bat
UserParameter=power, C:\zabbix\parser\electric-power.bat

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

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

C:\zabbix>zabbix_agentd.exe -c c:\zabbix\zabbix_agentd.win.conf -t power
power

Если у вас все работает и значения правильные выводятся, идем на сервер, настраивать сбор параметров.

Подготовка zabbix agent

Мониторинг значений SMART жесткого диска будет выполняться с помощью smartmontools. Установить их можно следующей командой для CentOS:

# yum install smartmontools

Либо аналогично в Debian/Ubuntu

# apt install smartmontools

Далее нам понадобится скрипт на perl для автообнаружения дисков и вывода информации о них в JSON формате, который понимает заббикс. Создадим такой скрипт.

# mcedit /etc/zabbix/scripts/smartctl-disks-discovery.pl

#!/usr/bin/perl

#must be run as root

$first = 1;

print "{\n";
print "\t\"data\":[\n\n";

for (`ls -l /dev/disk/by-id/ | cut -d"/" -f3 | sort -n | uniq -w 3`)
{
#DISK LOOP
$smart_avail=0;
$smart_enabled=0;
$smart_enable_tried=0;

#next when total 0 at output
        if ($_ eq "total 0\n")
                {
                        next;
                }

    print "\t,\n" if not $first;
    $first = 0;

$disk =$_;
chomp($disk);

#SMART STATUS LOOP
foreach(`smartctl -i /dev/$disk | grep SMART`)
{

$line=$_;

        # if SMART available -> continue
        if ($line = /Available/){
                $smart_avail=1;
                next;
                        }

        #if SMART is disabled then try to enable it (also offline tests etc)
        if ($line = /Disabled/ & $smart_enable_tried == 0){

                foreach(`smartctl -i /dev/$disk -s on -o on -S on | grep SMART`) {

                        if (/SMART Enabled/){
                                $smart_enabled=1;
                                next;
                        }
                }
        $smart_enable_tried=1;
        }

        if ($line = /Enabled/){
        $smart_enabled=1;
        }


}

    print "\t{\n";
    print "\t\t\"{#DISKNAME}\":\"$disk\",\n";
    print "\t\t\"{#SMART_ENABLED}\":\"$smart_enabled\"\n";
    print "\t}\n";

}

print "\n\t]\n";
print "}\n";

Сохраняем скрипт и делаем исполняемым.

# chmod u+x smartctl-disks-discovery.pl

Выполняем скрипт и проверяем вывод. Должно быть примерно так с двумя дисками.

{
	"data":
}

В данном случае у меня 2 физических диска — sda и sdb. Их мы и будем мониторить.

Настроим разрешение для пользователя zabbix на запуск этого скрипта, а заодно и smartctl, который нам понадобится дальше. Для этого запускаем утилиту для редактирования /etc/sudoers.

# visudo

Добавляем в самый конец еще одну строку:

zabbix ALL=(ALL) NOPASSWD:/usr/sbin/smartctl,/etc/zabbix/scripts/smartctl-disks-discovery.pl

Сохраняем, выходим Это если вы умеете работать с vi. Если нет, то загуглите, как работать с этим редактором. Именно он запускается командой visudo.

Проверим, что пользователь zabbix нормально исполняет скрипт.

# chown zabbix:zabbix /etc/zabbix/scripts/smartctl-disks-discovery.pl
# sudo -u zabbix sudo /etc/zabbix/scripts/smartctl-disks-discovery.pl

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

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

# mcedit /etc/zabbix/zabbix_agentd.d/smart.conf

UserParameter=uHDD,sudo smartctl -A /dev/$1| grep -i "$2"| tail -1| cut -c 88-|cut -f1 -d' '
UserParameter=uHDD.model.,sudo smartctl -i /dev/$1 |grep -i "Device Model"| cut -f2 -d: |tr -d " "
UserParameter=uHDD.sn.,sudo smartctl -i /dev/$1 |grep -i "Serial Number"| cut -f2 -d: |tr -d " "
UserParameter=uHDD.health.,sudo smartctl -H /dev/$1 |grep -i "test"| cut -f2 -d: |tr -d " "
UserParameter=uHDD.errorlog.,sudo smartctl -l error /dev/$1 |grep -i "ATA Error Count"| cut -f2 -d: |tr -d " "
UserParameter=uHDD.discovery,sudo /etc/zabbix/scripts/smartctl-disks-discovery.pl

Версия настроек для агента 3.4

UserParameter=uHDD.A,sudo smartctl -A /dev/$1
UserParameter=uHDD.i,sudo smartctl -i /dev/$1
UserParameter=uHDD.health,sudo smartctl -H /dev/$1 || true
UserParameter=uHDD.discovery,sudo /etc/zabbix/scripts/smartctl-disks-discovery.pl

Сохраняем файл и перезапускаем zabbix-agent.

# systemctl restart zabbix-agent

Проверяем, как наш агент будет отдавать данные. Ключ uHDD.discovery будет одинаковый для обоих версий агента.

# zabbix_agentd -t uHDD.discovery

Вы должны увидеть полный JSON вывод с информацией о ваших диска. Теперь посмотрим, как передаются информация о smart. Запросим температуру дисков для версии 3.2.

# zabbix_agentd -t uHDD

uHDD

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

Заключение

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

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

Надеюсь, моя статья поможет вам повысить эффективность администрирования почтового сервера. Буду рад замечаниям, советам и информации о собственном опыте в мониторинге почты, в частности postfix. Хотя опыт других серверов тут тоже применим. Zabbix универсальный инструмент, на котором можно реализовать практически любые проверки.

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

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

Заключение

Пару слов о мониторинге логов. Для парсинга лога используется регулярное выражение. В данном случае такое: ^.*sshd.*(Accepted|closed).* В это условие попадают все строки, где присутствует слово sshd и обязательно одно из Aceepted или closed. Если будете менять условия парсинга, или возьмете вообще другой лог, то нужно будет подготовить другое регулярное выражение.

Онлайн курс Infrastructure as a code

Если у вас есть желание научиться автоматизировать свою работу, избавить себя и команду от рутины, рекомендую пройти онлайн курс Infrastructure as a code. в OTUS. Обучение длится 4 месяца.

Что даст вам этот курс:

Познакомитесь с Terraform.
Изучите систему управления конфигурацией Ansible.
Познакомитесь с другими системами управления конфигурацией — Chef, Puppet, SaltStack.
Узнаете, чем отличается изменяемая инфраструктура от неизменяемой, а также научитесь выбирать и управлять ей.
В заключительном модуле изучите инструменты CI/CD: это GitLab и Jenkins

Смотрите подробнее программу по .