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

УСТАНОВКА СЕРВЕРА ZABBIX

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

УСТАНОВКА APACHE, PHP, MYSQL

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

 sudo apt update
sudo apt install apache2
sudo apt install mysql-server
sudo apt install php php-cli php-common php-mysql

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

[Date]
date.timezone = 'Europe/Kiev'

ДОБАВЛЕНИЕ РЕПОЗИТОРИЯ

Репозиторий Zabbix добавляется в систему очень необычным способом так же, как и в CentOS. Вам нужно всего лишь установить один deb пакет. Вы можете скачать нужную версию по ссылке.

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

 wget http://repo.zabbix.com/zabbix/3.2/ubuntu/pool/main/z/zabbix-release/zabbix-release_3.2-1+xenial_all.deb

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

 sudo dpkg -i zabbix-release_3.2-1+xenial_all.deb
sudo apt-get update

УСТАНОВКА И НАСТРОЙКА ZABBIX

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

 sudo apt install zabbix-server-mysql zabbix-frontend-php

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

 mysql -u root -p

mysql> CREATE DATABASE zabbixdb;
mysql> ALTER DATABASE zabbixdb CHARACTER SET utf8 COLLATE utf8_general_ci;
mysql> GRANT ALL on zabbixdb.* to zabbix@localhost IDENTIFIED BY 'password';
mysql> FLUSH PRIVILEGES;

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

 zcat schema.sql.gz | mysql -u zabbix -p zabbixdb
zcat data.sql.gz | mysql -u zabbix -p zabbixdb
zcat images.sql.gz | mysql -u zabbix -p zabbixdb

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

 sudo vi /etc/zabbix/zabbix_server.conf

DBHost=localhost
DBName=zabbixdb
DBUser=zabbix
DBPassword=password

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

 sudo a2enconf zabbix-frontend-php

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

 sudo service apache2 restart
$ sudo service zabbix-server restart

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

НАСТРОЙКА ВЕБ-ИНТЕРФЕЙСА ZABBIX

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

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

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

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

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

Если получаете такую ошибку, то файл нужно скачать и сохранить в /etc/zabbix/ вручную:

wget http://ip_сервера/zabbix/setup.php?save_config=1
sudo mv setup.php\?save_config\=1 /etc/zabbix/zabbix.conf.php

Владельца файла нужно изменить на www-data, чтобы программа имела к нему права доступа:

 sudo chown www-data /etc/zabbix/zabbix.conf.php

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

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

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

УСТАНОВКА ZABBIX AGENT

Чтобы начать наблюдение за удаленным хостом нам понадобится Zabbix Agent. Эта программа собирает все доступные данные о нагрузке на систему, использовании ресурсов и передает все это на сервер Zabbix. Можно настроить активную проверку, когда агент будет отправлять все данные на сервер периодически или пассивную, когда данные будут отправляться по запросу.

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

 sudo apt-get install zabbix-agent

Теперь отредактируем файл, нам нужно указать IP адрес сервера и имя хоста:

 sudo vi /etc/zabbix/zabbix_agentd.conf

Server=192.168.1.2
Hostname=Zabbix

После изменения конфигурации нужно перезапустить сервис zabbix-agent:

 sudo service zabbix-agent restart

Теперь вы можете добавить новый хост в Zabbix и наблюдать за его состоянием через панель.

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

[scn3

Сообщение Установка ZABBIX на UBUNTU появились сначала на Clip-Clap.

Введение

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

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

Я все настраивал на сервере с версией 3.2, агенты той же версии. Работоспособность в 3.4 не проверял, но, по идее, все должно работать и там. Если у вас еще нет сервера мониторинга, то можете его установить и настроить — 3.2 или 3.4 на Centos 7 или 3.4 на Debian 9.

Параметры мониторинга asterisk

В интернете есть примеры мониторинга asterisk. Кое-что я оттуда подсмотрел, но готового решения, которое бы мне подошло полностью, я не увидел, поэтому решил сделать по-своему. Я подумал в решил, что мне полезны для мониторинга следующие метрики:

1. Состояние транков. Если один из них отваливается, я узнаю о его имени уже в оповещении на почте.
2. Состояние самой службы asterisk на сервере. Тут все просто — либо работает, либо нет.
3. Состояние работы программы fail2ban. Тоже все просто — либо работает, либо нет.
4. Наличие цепочек fail2ban в таблице iptables. Эта проверка гарантирует, что fail2ban не только запущен, но и успешно блокирует нарушителей.
5. Факт перезапуска сервиса asterisk. Как бонус к этой метрике — uptime службы астериска.
6. Количество активных разговоров в данный момент.

Небольшие комментарии к метрикам. Если сервер смотрит в интернет, то обязательно наличие iptables и fail2ban. Боты будут регулярно к вам стучаться и перебирать учетки. Так что следить за работой этих служб необходимо. По транкам я уже сказал, это один из основных параметров, так как время от времени они отваливаются. Гораздо чаще, чем сами сервисы. На всякий случай будем следить за работой сервиса астериск на сервере. Он хоть у меня обычно и не падает, даже не припомню такого, но теоретически с ним это может происходить. Мониторинг перезагрузки и аптайма службы сделан в основном для любопытства. Практической пользы в этой метрике я не вижу, если вы единственный админ на сервере и без вас его никто не перезапускает. Мониторинг за количеством активных звонков в asterisk сделан для того, чтобы можно было оценить примерную нагрузку и занятость линий.

Я больше не придумал, на что еще стоит обратить внимание. Некоторые считают количество звонков в день, количество транков, пиров, их статус. Я лично не вижу в этом большого смысла. Если кто-то считает, что есть еще важные параметры в asterisk, которые надо мониторить, прошу поделиться.

Настройка zabbix-agent

Для мониторинга за asterisk, я буду использовать один скрипт и несколько обработанных выводов из запросов к астериску. Начнем со скрипта. Он будет проверять статус транков и если какой-либо из них будет в offline, назовет его. Кладем этот скрипт в директорию /etc/zabbix/scripts.

# cat /etc/zabbix/scripts/asterisk.trunk-with-name.sh

#!/bin/bash

# Получаем количество всех транков в системе
total=`sudo asterisk -rx 'sip show registry' | sed -n '/registrations/p' | awk '{print $1}'`
# Получаем число активных транков
active=`sudo asterisk -rx 'sip show registry' | sed -n '/Registered/p' | wc -l`
# Получаем имена транков с проблемам
offline=`sudo asterisk -rx 'sip show registry' | sed -n '/Request\|Rejected\|Authentication\|Auth/p' | awk '{print $3}'`
# Сравниваем общее число с числом активных транков и выводим сообщение об их состоянии
if [ $active -lt $total ]
then
echo Trunks offline $offline
else
echo All trunks are online
fi

Я все прокомментировал. Добавлю только пояснение к регулярке, которая определяет проблемные транки. Я знаком со следующими состояниями транков, когда они не работают:

• Request Sent
• No Authentication
• Auth. Sent
• Rejected

Соответственно, эти состояния я и ищу. Если один из транков находится в одном из этих состояний, то он считается проблемным.

Далее создаем файл конфигурации zabbix с UserParameters в /etc/zabbix/zabbix_agentd.d.

# cat /etc/zabbix/zabbix_agentd.d/asterisk.conf

# Статус службы fail2ban
UserParameter=asterisk.fail2ban_status,ps cax | grep fail2ban | wc -l
# Количество цепочек fail2ban в iptables
UserParameter=asterisk.fail2ban_chain,iptables -nL | grep Chain | grep -E 'f2b|fail2ban' | wc -l
# Время работы службы asterisk
UserParameter=asterisk.uptime,asterisk -rx "core show uptime seconds" | grep --text -i "System uptime:" | gawk '{print $3}'
# Количество активных разговоров
UserParameter=asterisk.active_calls,asterisk -rvvvvvx 'core show channels'| grep --text -i 'active call'| cut -c1
# Статус транков
UserParameter=asterisk.trunk,/etc/zabbix/scripts/asterisk.trunk-with-name.sh
# Статус службы asterisk
UserParameter=asterisk.asterisk_status,ps cax | grep asterisk | wc -l

Некоторые из приведенных метрик требуют права root для своего исполнения. Скажу честно, мне было лениво разбираться с разрешениями и я просто запустил zabbix с правами root. Для этого в его конфиге /etc/zabbix/zabbix_agentd.conf раскомментировал следующую строку:

AllowRoot=1

После этого можно перезапустить zabbix-agent и проверить работу будущих итемов.

# systemctl restart zabbix-agent

Проверяем, насколько корректно агент возвращает указанные значения.

 # zabbix_agentd -t asterisk.asterisk_status
asterisk.asterisk_status [t|2]

# zabbix_agentd -t asterisk.fail2ban_chain
asterisk.fail2ban_chain [t|2]

# zabbix_agentd -t asterisk.trunk
asterisk.trunk [t|All trunks are online]

Все в порядке. В завершении настройки агента, поясню некоторые моменты для тех, кто не очень разбирается в bash скриптах. Для мониторинга статусов служб я просто вывожу список всех процессов, вычленяю из него нужный мне процесс, в данном случае asterisk или fail2ban и подсчитываю количество этих процессов. Далее в шаблоне я просто буду проверять число этих процессов. Если оно будет равно 0, значит процессы не работают.

Для анализа цепочки iptables я также обрабатываю ее вывод, ищу строки со словами fail2ban и подсчитываю их количество. Если они равны 0, значит fail2ban не работает, либо работает, но не добавляет правила в iptables, что по большому счету и равно тому, что он не работает.

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

Мониторинг asterisk в zabbix сервере

Всю теорию я изложил выше. Осталось только добавить готовый шаблон на сервер и посмотреть на результат. Скачиваем шаблон — zabbix-asterisk-template.xml и импортируем его на сервер. В шаблоне присутствуют 6 элементов данных, которые мы определили в агенте, 5 триггеров и 1 график просто для красоты, чтобы был :). В этом шаблоне надобности в графиках нет. Остановлюсь подробнее на триггерах.

Первые 4 триггера очевидны, по ним комментировать нечего. Остановлюсь на последнем с проверкой транков. Данный триггер проверяет текстовую строку «All trunks are online», которую возвращает итем. Если 2 раза подряд ее не было, значит проблема, и идет оповещение. Проблема закрывается, когда она же появляется 2 раза подряд. Сделал специально 2 проверки, чтобы не было ложных срабатываний на моментах перерегистрации или кратковременных сбоев, которые не требуют вмешательства.

После применения шаблона на хостах, увидите примерно такую картинку в «Последних данных».

Если какой-то транк отвалится, то в оповещении на почте будет его название. У меня вот так выглядят подобные оповещения.

На этом по мониторингу asterisk в zabbix все. Надеюсь, раскрыл тему достаточно подробно и понятно.

Заключение

Не понравилась статья и хочешь научить меня администрировать? Пожалуйста, я люблю учиться. Комментарии в твоем распоряжении. Расскажи, как сделать правильно!

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

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

Данный шаблон должен работать вместе со стандартным шаблоном для linux. Я видел в сети примеры шаблонов мониторинга asterisk, куда были добавлены метрики таких параметров сервера, как память, процессор, сеть и т.п. Не вижу смысла в таком подходе. Шаблоны надо максимально разделять, чтобы ими было удобнее пользоваться и не нагружать сервера лишними метриками. Я под каждый функционал сервера делаю отдельный шаблон. Примеры таких шаблонов можно посмотреть в моей рубрике zabbix.

Сообщение Настройка мониторинга asterisk в zabbix появились сначала на Clip-Clap.

Введение

Я уже много раз использовал внешние скрипты и UserParameter для мониторинга в zabbix. Не буду подробно на этом останавливаться. Приведу список своих материалов по этой теме:

• Мониторинг информации из текстовых файлов
• Следим за временем делегирования домена в zabbix
• Мониторинг бэкапов
• Статус транков в астериск
• Мониторинг рейда mdadm
• Наблюдение за mysql репликацией с помощью заббикс
• Состояние веб сервера nginx и php-fpm
• Мониторинг температуры windows сервера

Использовать будем такой же подход. У нас будет 2 скрипта. Первый будет собирать информацию о размерах папок с файлами, второй будет передавать сформированные данные в заббикс. Делать все будем раз в сутки, чаще нет смысла, так как у меня бэкапы выполняются с суточным интервалом. Сами бэкапы представляют из себя не отдельные файлы-архивы, а папки. Настроено все примерно так же, как в статье про настройку backup с помощью rsync.

Скрипты по сбору информации о размере бэкапов

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

# mkdir /etc/zabbix/scripts
# mcedit /etc/zabbix/scripts/size-backup-dir.sh

#!/bin/bash

# Файл с информацией о размере папок
logfile=/etc/zabbix/scripts/size-log.txt

# Удаляем файл предыдущей работы скрипта
rm $logfile

# Определяем размер папки
size_1c=`du -s /mnt/data/backup/1c | awk '{print $1}'`

# Записываем результат в текстовый файл
echo 1c $size_1c >> $logfile

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

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

# cat size-log.txt
1c 41374052

Необходимо добавить этот скрипт в крон и выполнять раз в сутки. Находите конфиг крона в вашей системе и добавляете туда:

30      15       *       *       *      /etc/zabbix/scripts/size-backup-dir.sh

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

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

# mcedit /etc/zabbix/scripts/send-zabbix-size.sh

#!/bin/bash
cat /etc/zabbix/scripts/size-log.txt | grep $1 | cut -d " " -f 2

Проверяем его работу следующим образом:

# ./send-zabbix-size.sh 1c
41374052

На выходе просто цифра с размером, которая уходит на сервер заббикса. То, что нужно. Важно не забыть один момент, иначе ничего не зааработает. Скрипту нужно назначить владельца zabbix, чтобы агент мог его запускать:

# chown zabbix. /etc/zabbix/scripts/send-zabbix-size.sh

Если этого не сделать, получите ошибку в логе агента:

sh: 1: /etc/zabbix/scripts/send-zabbix-size.sh: Permission denied

Настраиваем zabbix агент

Делаем все как обычно. Идем в папку /etc/zabbix/zabbix_agentd.conf.d и создаем файл с пользовательскими параметрами:

# mcedit /etc/zabbix/zabbix_agentd.conf.d/backup-size.conf

UserParameter=size.1c,/etc/zabbix/scripts/send-zabbix-size.sh 1c

Сохраняем файл. Перезапускаем агента и проверяем в консоли, что улетит на сервер:

# zabbix_agentd -t size.1c
size.1c                                       [t|41374052]

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

Добавляем новый итем на сервер мониторинга zabbix

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

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

Смотреть результат следует, как обычно, в Latest data. Там же можно и график посмотреть, когда накопятся данные для него. Для более наглядных и красивых графиков, необходимо будет их вручную создать в конструкторе графиков конкретного хоста. Лично мне достатчно информации из последних данных.

Заключение

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

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

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

Сообщение Мониторинг размера бэкапа в Zabbix появились сначала на Clip-Clap.

Я буду в своем примере настраивать все на CentOS 7, но в данном случае дистрибутив не имеет принципиального значения, все так же настраивается и на других linux системах с учетом их особенностей в установке пакетов и путей для конфигов и программ.

Мы будем использовать в качестве источника информации штатные возможности nginx, apache и php-fpm, затем передавать данные в zabbix сервер и там анализировать. Я подразумеваю, что nginx или apache вы уже настроили и имеете некое представление о работе его компонентов, поэтому некоторые вещи я не разжевываю, а просто говорю, что делать.

Подготовка nginx к мониторингу

Я планирую мониторить следующие параметры nginx:

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

server {
    listen localhost;
    server_name localhost;
    keepalive_timeout	0;
    allow	127.0.0.1;
    allow	::1;
    deny	all;
    access_log	off;

        location /nginx-status {
	stub_status	on;
        }

Я обычно добавляю в самый конец основного конфига nginx.conf. Сохраняем и перечитываем конфигурацию, перед этим проверив его конфиг на ошибки:

# nginx -t
# nginx -s reload

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

# curl http://localhost/nginx-status
Active connections: 89 
server accepts handled requests
 1374661 1374661 9511381 
Reading: 0 Writing: 1 Waiting: 87

Теперь проверим, сможет ли zabbix получать эту страницу.

# zabbix_agentd -t web.page.get[localhost,nginx-status,80]

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

Сразу обращаю внимание на один важный момент, на котором я застрял на приличное время. Через curl я без проблем забирал страничку со статусом nginx, а вот через zabbix никак не получалось. Была ошибка:

[m|ZBX_NOTSUPPORTED] [HTTP get error: cannot connect to [[localhost]:80]: [111] Connection refused]

Я всю голову сломал, 10 раз перепроверил конфиги, никак не мог понять, почему не работает. Оказалось, дело было вот в чем. Zabbix-agent обращался к серверу Nginx по протоколу ipv6. Это при том, что как агент, так и nginx работали по ipv4. Я принудительно отключаю у служб ipv6, если он не используется.

Обнаружил это случайно, когда от безысходности запустил Nginx на всех интерфейсах и снял ограничения allow/deny в конфиге. Тогда запрос прошел нормально. Я посмотрел access лог и увидел, что zabbix-agent обращается с адреса ::1. И все стало ясно. Я так и не понял, как заставить агента ходить по ipv4. В итоге запустил nginx на обоих протоколах и разрешил забирать страницу статуса с адреса ::1. После этого заработало.

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

Настройка в 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 штук.

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

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

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

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

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

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

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

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

Подготовка php-fpm к мониторингу

Переходим к мониторингу php-fpm. Он отдает побольше метрик, не буду описывать их все. Рассмотрю только самые основные. Мы будем наблюдать следующие параметры php-fpm:

Пару слов о том, зачем это нужно и как пользоваться полученными данными. Этот мониторинг актуален, если у вас динамическое создание процессов в php-fpm. К примеру, если у вас значение max children reached регулярно больше единицы, то вам рекомендуется увеличить лимит на максимальное количество процессов, если позволяют ресурсы сервера. То же самое относится и к параметру length of listen queue. Если он больше нуля, то создается очередь из запросов, которые не успевают обработать сервер. Необходимо увеличить количество процессов, которые смогут обработать ожидающие подключения.

Приступаем к настройке мониторинга php-fpm на web сервере. Установим fcgi:

# yum install fcgi

Теперь подготовим pfp-fpm для сбора статистики. Для этого мы снова воспользуемся nginx. Редактируем его конфиг, добавляя в ту же секцию server, что и на прошлом этапе, следующую конструкцию:

location /phpfpm-status {
	include fastcgi_params;
	fastcgi_pass   unix:/var/run/php-fpm/php-fpm.sock;
	fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

Обращаю ваше внимание на то, что я в своей конфигурации использую подключение к php-fpm через unix сокет. За это отвечает параметр конфигурации fastcgi_pass. Если вы используете в работе tcp/ip порт, обычно 127.0.0.1:9000, то нужно указать его вместо сокета, вот так: fastcgi_pass 127.0.0.1:9000

Перезапускаем nginx:

# systemctl restart nginx

Внесем необходимые изменения в конфиг php-fpm — добавим одну строку:

# mcedit /etc/php-fpm.d/www.conf
pm.status_path = /phpfpm-status

Перезапускаем php-fpm:

# systemctl restart php-fpm

Проверяем, что по указанному адресу мы получаем статистику php-fpm:

# curl http://localhost/phpfpm-status

И ее же в формате json.

# curl -s 'http://localhost/phpfpm-status?json'
{"pool":"www","process manager":"dynamic","start time":1566494413,"start since":2049,"accepted conn":3236,"listen queue":0,"max listen queue":0,"listen queue len":0,"idle processes":5,"active processes":1,"total processes":6,"max active processes":6,"max children reached":0,"slow requests":0}

Если у вас примерно то же самое, то все в порядке, php-fpm отдает информацию о своем состоянии.

Мониторинг php-fpm в zabbix

Теперь настраиваем мониторинг php-fpm на сервере zabbix. Действуем по аналогии с мониторингом nginx. Забираем страницу состояния php-fpm на сервер мониторинга и там его парсим в зависимых элементах данных.

С php-fpm будет один нюанс. Нам все-таки придется менять параметры zabbix agent. Настраивать мониторинг php-fpm очень легко, потому что он из коробки умеет отдавать все свои метрики в формате json. Это очень удобно, так как его не надо парсить регулярками. Достаточно только указать JSONpath для получения необходимой метрики.

Нам нужно добавить один UserParameter следующего содержания.

UserParameter=phpfpm.json[*],curl -s 'http://localhost/phpfpm-status?json' | tr ' ' _

Перезапускаем zabbix-agent и проверяем, что он корректно возвращает необходимые данные.

# systemctl restart zabbix-agent
# zabbix_agentd -t phpfpm.json
phpfpm.json                                   [t|{"pool":"www","process_manager":"dynamic","start_time":1566494413,"start_since":3525,"accepted_conn":5820,"listen_queue":0,"max_listen_queue":0,"listen_queue_len":0,"idle_processes":6,"active_processes":1,"total_processes":7,"max_active_processes":7,"max_children_reached":0,"slow_requests":0}]

Дальше как и в случае с nginx, идем в веб интерфейс и импортируем шаблон zabbix-phpfpm-template.xml. Добавляем этот шаблон к серверу и ждем обновления данных. Проверяем их поступление, как обычно, в Monitoring -> Latest Data:

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

В шаблоне php-fpm настроен только один триггер, который следит за тем, чтобы хотя бы один процесс php-fpm был запущен. Раньше я использовал больше триггеров, но потом решил, что они не очень нужны. Состояние работы сайта лучше оценивать по финальным метрикам, таким как скорость загрузки страниц, доступность сайта и коды ответов. Если с этими метриками проблемы, нужно идти в мониторинг, смотреть графики и решать, что нужно изменить в конфигурации. Это мое личное мнение, с ним можно поспорить. Для этого есть комментарии, буду рад замечаниям и обсуждениям по существу.

Подготовка apache к мониторингу

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

С веб сервером apache мне давно не приходилось связываться в отрыве от bitrix сайтов, поэтому решил показать его мониторинг на его примере. Здесь принцип будет такой же, как и раньше — забираем страницу с информацией о веб сервере, который apache нам предоставляет через свой модуль mod_status.

Дальше мы передаем страницу в zabbix server и там парсим регулярками по зависимым элементам данных. Первым делом вам надо настроить указанный выше модуль. Подробности на официальном сайта — https://httpd.apache.org/docs/current/mod/mod_status.html. Если кратко, то просто добавьте в конфиг apache примерно следующие настройки.

<Location "/server-status">
    SetHandler server-status
    Require host localhost
</Location>

Bitrixenv автоматически все настроит, если вы через консольное меню включите Monitoring in pool. Запустится роль ansible, которая настроит в том числе apache, установит и запустит nagios и munin. Если они вам не нужны, то просто добавьте приведенный выше кусок конфига в /etc/httpd/bx/custom/z_bx_custom.conf.

Listen localhost:8886
<IfModule mod_status.c>
    ExtendedStatus On
</IfModule>
<VirtualHost localhost:8886>
    <Location /server-status>
        SetHandler server-status
        Require ip 127.0.0.1
	require ip ::1
    </Location>
</VirtualHost>

После этого проверьте настройки apache и перезапустите его.

# apachectl -t
# apachectl restart

Если все настроили правильно, то состояние apache можно посмотреть в консоли.

# curl http://localhost:8886/server-status?auto
Total Accesses: 1051
Total kBytes: 104324
CPULoad: 4.7515
Uptime: 1835
ReqPerSec: .572752
BytesPerSec: 58216.8
BytesPerReq: 101644
BusyWorkers: 1
IdleWorkers: 29
Scoreboard: _______________________W______

И на всякий случай проверьте, что zabbix-agent может получать эту же информацию.

# zabbix_agentd -t web.page.get[localhost,server-status?auto,8886]

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

Настройка мониторинга apache

Теперь настроим мониторинг apache в zabbix server. Как обычно, я подготовил шаблон с итемами и триггерами, которые посчитал полезными. Скачиваем его — zabbix-apache-template.xml.

Обратите внимание на элемент, который забирает страницу со статусом. Его url я реализовал через макросы:

• {$S_HOST} — название виртуального хоста
• {$S_PATH} — путь к странице со статистикой
• {$S_PORT} — порт сервера apache, на котором работает статистика

Вот как выглядят настройки макроса на типичном сайте с bitrixenv.

Так же обращаю внимание на итемы проверки количества рабочих процессов и занимаемой виртуальной памяти. Для проверки процессов указан пользователь bitrix, от которого работают все воркеры. В случае проверки памяти указан пользователь root, так как основной процесс запущен от него. А все воркеры используют разделяемую память. Ее суммарный объем, особенно когда воркеров много, огромен и представляет из себя нереальную цифру. Отслеживать ее нет никакого смысла.

Так как apache обычно работает в роле бэкенда, у него минимум триггеров, как и у php-fpm. Я сделал 2:

1. Apache service not work — предупреждение о том, что системный процесс web сервера apache не запущен.
2. Failed to fetch apache server status page — триггер срабатывает, если не получается загрузить страницу со статистикой.

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

На это про мониторинг apache в zabbix все. Дальше идет пример готового Dashboard.

Дашборд Zabbix для Web сервера

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

В самом верху список текущих проблем. В настоящий момент висит активный триггер о ssh подключению к серверу. Справа от списка проблем — мониторинг бэкапов в zabbix.

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

Ниже идут метрики с мониторинга web сайта. Выбирается контрольный набор из нескольких страниц (обычно 3-5) и настраивается мониторинг времени ответа и скорости загрузки этих страниц. Для этих параметров настроены триггеры, так как они очень важны. По сути, это ключевые метрики. Если с ними проблемы, надо внимательно смотреть web сервер и разбираться, в чем проблема. Мониторинг web сайта нужно настраивать минимум с двух независимых серверов zabbix, иначе вы не сможете отличить проблемы доступа с сервера мониторинга к сайту от реальных проблем сайта. Только если оба сервера мониторинга сигнализируют о проблемах, можно сделать однозначный вывод о том, что с сайтом и web сервером что-то не так.

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

В принципе, сюда можно было бы добавить информацию по I/O дисков, инфу с сетевого стека, данные Mysql. Не стал этого делать, так как это обзорный dashboard, который беглым просмотром позволяет оценить состояние сервера. Так же этот дашборд можно показать заказчику. Для более глубокого анализа проблем, нужно собирать отдельную панель.

Заключение

Подведем итог того, что мы сделали:

1. Настроили сервисы nginx, apache, php-fpm таким образом, чтобы они отдавали информацию о своем состоянии.
2. С помощью zabbix агентов передали эту информацию на сервер.
3. Используя зависимые элементы (dependent items) настроили парсинг метрик.
4. Настроили на сервере мониторинга необходимые шаблоны и прикрепили их к наблюдаемым серверам.
5. Собрали dashboard для мониторинга за веб сервером.

То есть выполнили весь комплекс действий для организации полноценного мониторинга web сервера в zabbix.

Одно из применений подобного мониторинга — выбор более быстрого хостинга для сайта. К примеру, мне некоторое время назад понадобилось сменить хостинг. Но как узнать, будет ли он быстрее текущего или нет. Характеристики примерно у всех одинаковые. Я просто взял тестовый период, настроил на сервере все, что мне нужно, в том числе мониторинг веб сервера, перенес туда сайт и понаблюдал сутки. Уже по времени отклика nginx и php-fpm мне стало понятно, что новый хостинг быстрее:

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

Это пример из старой версии статьи, где показаны старые метрики и графики. Оставил его, так как он в целом информативен. Текущий мониторинг web сайта так же можно использовать для анализа производительности хостинга.

Сообщение Настройка мониторинга nginx, php-fpm, apache в Zabbix появились сначала на Clip-Clap.

Несколько слов о том, что именно мы будем мониторить. Посмотреть статус репликации можно с помощью простой команды в консоли mysql:

MariaDB [(none)]> show slave status\G;

Нас будут интересовать три параметра:

• Seconds_Behind_Master — то, насколько слейв сервер отстает от мастера в репликации.
• Slave_IO_Running — индикатор работы демона по сбору бинарного лога с мастера и записи его в локальный relay лог.
• Slave_SQL_Running — индикатор выполнения команд из локального relay лога.

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

Реализовывать будем так же как и в случае с мониторингом nginx и php-fpm через скрипт и UserParameter. Если у вас репликация master-mastert, то настраиваете мониторинг на обоих серверах.

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

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

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

Создаем в mysql юзера, у которого будет доступ к информации о репликации:

# mysql -uroot -ppassword

MariaDB [(none)]> CREATE USER 'zabbix'@'localhost' IDENTIFIED BY 'parol';
MariaDB [(none)]> GRANT REPLICATION CLIENT ON *.* TO 'zabbix'@'localhost' IDENTIFIED BY 'parol';

Создали учетную запись zabbix с паролем parol и правами replication client. Её мы будем использовать в дальнейшей работе.

Создание скрипта для мониторинга mysql репликации

Теперь создадим скрипт для мониторинга. Скачиваем его отсюда mysql-slave.sh и вставляем содержимое в папку /etc/zabbix/scripts:

# mcedit /etc/zabbix/scripts/mysql-slave.sh
# chown zabbix:zabbix /etc/zabbix/scripts/mysql-slave.sh
# chmod 550 /etc/zabbix/scripts/mysql-slave.sh

Проверяем его работу:

/etc/zabbix/scripts/mysql-slave.sh Master_Host zabbix parol

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

Данный скрипт анализирует вывод show slave status\G и парсит 3 необходимых нам значения. Он передает агенту информацию о задержке репликации через параметр Seconds_Behind_Master и анализирует значения Slave_IO_Running и Slave_SQL_Running. Если их значения равны Yes, он передает агенту 1, если там что-то другое то 0.

Настройка zabbix agent

Добавляем новый параметр в zabbix_agentd.conf

# mcedit /etc/zabbix/zabbix_agentd.conf
UserParameter=mysql-slave[*],/etc/zabbix/scripts/mysql-slave.sh "$1" zabbix parol

Сохраняем конфиг и перезапускаем агента:

# systemctl restart zabbix-agent

Настройка мониторинга репликации mysql на zabbix server

Здесь все как обычно. Скачиваем шаблон mysql-slave.xml импортируем его на сервер. Для этого идем в Configuration -> Templates и нажимаем Import:

Выбираем скачанный шаблон и жмем Import:

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

Жмем Update для применения настроек. Ждем несколько минут и идем проверять поступление новых данных репликации mysql. Открываем Monitoring -> Latest Data, настраиваем фильтр и проверяем значения:

В данном случае мы видим, что значение Seconds Behind Master = 0, отставания от мастера нет. Два других значения равны единице, это значит, что наш скрипт проверки состояния репликации получает статусы Slave_IO_Running и Slave_SQL_Running равные Yes и поэтому возвращает значения 1. То есть наша репликация работает в штатном режиме, все в порядке.

Проверка работы триггеров

Попробуем нарушить работу репликации mysql и проверим работу триггеров. Для этого я просто отключу vpn соединение, по которому доступны сервера. После разрыва связи на slave сервере следующая картинка статуса репликации:

Проверяем данные мониторинга репликации:

Значение Slave_IO_Running сменилось с Yes на Connecting и скрипт проверки вернул значение 0 вместо 1. Этого достаточно, чтобы сработал триггер и пришло оповещение о том, что репликация mysql сервера нарушена:

На почту пришло оповещение:

По-умолчанию мониторинг не умеет отправлять оповещения на сторонние серверы с авторизацией по smtp.

Восстанавливаем связь между серверами и ждем новой работы триггера и уведомления:

Проверяем Latest Data:

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

Заключение

Для мониторинга состояния репликации mysql мы воспользовались самописным скриптом, который парсит вывод значения show slave status\G и анализирует необходимые нам параметры реплики. На основе этих параметров он передает zabbix агенту необходимые значения для отправки на сервер.

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

Сообщение Мониторинг MySQL репликации в Zabbix появились сначала на Clip-Clap.

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

Введение

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

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

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

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

Настройка агента для мониторинга транков (trunks)

Создадим папку для пользовательских скриптов в каталоге zabbix:

# mkdir /etc/zabbix/scripts

Создаем в ней скрипт asterisk.trunk.sh следующего содержания:

#!/bin/sh
# Получаем количество всех транков в системе
number_tranks=`/usr/sbin/asterisk -rx "sip show registry" | grep "SIP registrations" | awk '{print $1}'`
# Считаем количество зарегистрированных транков
reg_tranks=`/usr/sbin/asterisk -rx "sip show registry" | grep Registered | wc -l`
# Вычисляем разницу между полученными значениями
let result=$number_tranks-$reg_tranks
# Выводим результат вычисления
echo $result

Назначаем владельцем файла пользователя zabbix и выставляем права на выполнение скрипта:

# chown zabbix. /etc/zabbix/scripts/asterisk.trunk.sh
# chmod 0750 /etc/zabbix/scripts/asterisk.trunk.sh

Теперь просто запустите скрипт и посмотрите результат. Если все регистрации подключены, то скрипт должен вернуть значение 0:

# /etc/zabbix/scripts/asterisk.trunk.sh
0

Открываем на редактирование конфиг агента и добавляем параметр UserParameter:

UserParameter=asterisk.trunk,/etc/zabbix/scripts/asterisk.trunk.sh

Перезапускаем zabbix-agent той командой, что соответствует вашей системе. В CentOS 7 делаем так:

# systemctl restart zabbix-agent

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

# zabbix_agentd -t asterisk.trunk
asterisk.trunk [t|0]

Все в порядке, то что надо. На этом настройка агента на сервере asterisk закончена. Переходим на сервер мониторинга.

Создание шаблона мониторинга asterisk на сервере zabbix

Нам нужно создать шаблон на сервере, для назначения его серверам с астериском. Здесь ничего сложного, делаем все то же самое, что мы делали ранее, настраивая мониторинг рейда mdadm. Идем в раздел Configuration -> Templates, нажимаем Create template.

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

Открываем шаблон, переходим в раздел Items и жмем на Create item. Заполняем параметры нового итема как на картинке.

Я поставил интервал проверок 120 секунд = 2 минуты. Вы можете поменять под свои нужды этот параметр. Сохраняем новый итем.

Для сбора данных все готово. Теперь назначаем шаблон серверам с астериском, где мы подготовили агенты мониторинга и скрипты и ждем поступления данных. Проверять как обычно идем в Latest data. Через пару минут должны поступить значения.

У меня пришло значение 0 как и должно быть. Все регистрации на месте. Теперь нам нужно добавить триггер, который будет отправлять уведомление, если какая-нибудь из регистраций отвалится. Для этого идем в созданный шаблон и переходим в раздел Triggers. Жмем Create trigger и указываем значения, как у меня.

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

Возможные ошибки

Если ваш новый item не работает, получает статус not supported, а в описании причины ошибка:

Unable to connect to remote asterisk (does /var/run/asterisk/asterisk.ctl exist?)

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

zabbix ALL = NOPASSWD: /usr/sbin/asterisk

После этого проверяем выполнение скрипта от пользователя zabbix:

# sudo -u zabbix /etc/zabbix/scripts/asterisk.trunk.sh

Если получаете вывод значения, значит все в порядке. Если же все равно видите ошибку:

Unable to connect to remote asterisk (does /var/run/asterisk/asterisk.ctl exist?)

Добавьте в скрипт перед /usr/sbin/asterisk выполнение /usr/bin/sudo. Должно получиться так:

reg_tranks=`/usr/bin/sudo /usr/sbin/asterisk -rx "sip show registry" | grep Registered | wc -l`

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

sudo: sorry, you must have a tty to run sudo

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

# cat /etc/passwd | grep zabbix
zabbix:x:496:496:Zabbix Monitoring System:/var/lib/zabbix:/sbin/nologin

Пользователям без оболочки по-умолчанию запрещено использовать sudo, которое мы добавили в скрипт. Исправить это можно в фале /etc/sudoers, закомментировав параметр:

#Defaults    requiretty

После этого снова отцепляем шаблон и прикрепляем заново. Теперь должно быть все в порядке.

Постарался предусмотреть все варианты развития событий. Наличие тех или иных ошибок будет зависеть от операционной системы и версии zabbix и asterisk.

Заключение

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

Сообщение Мониторинг транков (trunk) в asterisk с помощью zabbix появились сначала на Clip-Clap.

Введение

У нас имеется любой сервер Linux с настроенным рейдом mdadm. Я специально не останавливаюсь на каком-то конкретном дистрибутиве, потому что этот рецепт универсален и будет актуален в любом дистрибутиве. Узнать состояние рейда можно командой в консоли:

# cat /proc/mdstat

Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid6 sdg1[6] sde1[3] sdd1[2] sdf1[4] sdc1[7] sdb1[0]
11720534016 blocks super 1.2 level 6, 512k chunk, algorithm 2 [6/6] [UUUUUU]

Заглавные буквы U означают, что все жесткие диски на месте, с рейдом все в порядке. Если какой-то из них выйдет из строя, то вместо буквы будет стоять знак _ . По этому значению мы и будем определять статус рейд массива mdadm — если знака _ нет, то все в порядке.

Воспользуемся простой командой для определения символа _ в выводе mdstat:

# egrep -c "\[.*_.*\]" /proc/mdstat

Если символа _ нет, то на выходе получаем значение 0. Если же это значение больше 1, то рейд считается поврежденным, zabbix отправляет уведомление. Отправлять полученные значения на сервер мониторинга будем с помощью UserParameter.

Настройка агента для мониторинга mdadm

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

# mcedit /etc/zabbix/zabbix_agentd.conf

UserParameter=mdadm.status,egrep -c "\[.*_.*\]" /proc/mdstat

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

# service zabbix-agent restart

Проверим работу этого параметра:

# zabbix_agentd -t mdadm.status
mdadm.status [t|0]

Все в порядке. Рейд в нормальном состоянии, команда возвращает параметр 0. Для проверки правильности регулярного выражения можно направить вывод /proc/mdstat в текстовый файл, изменить там значение U на _ и прогнать egrep по этому файлу. Должно на выходе быть значение 1 или более, в зависимости от того, сколько вы подчеркиваний добавите. Например вот так:

# cat /proc/mdstat > /root/mdstat
# mcedit /root/mdstat

Заменяем U на _ .

# cat /root/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid6 sdg1[6] sde1[3] sdd1[2] sdf1[4] sdc1[7] sdb1[0]
11720534016 blocks super 1.2 level 6, 512k chunk, algorithm 2 [6/6] [UUU_UU]

# egrep -c "\[.*_.*\]" /root/mdstat
1

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

Настройка на сервере Zabbix

Теперь идем на сервер мониторинга и настраиваем на нем все, что необходимо для мониторинга mdadm. Нам нужно будет создать шаблон, в нем один item и один trigger. Создаем шаблон: Configuration -> Templates ->  Create template.

Пишем название, добавляем в группу и сохраняем. Открываем созданный шаблон, переходим в Items и создаем новый.

Заполняем параметры как у меня и жмем add.

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

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

Добавляем триггер. На этом настройка шаблона закончена. Можно назначить шаблон всем хостам, на которых мы добавили  UserParameter и ждать, когда в Last Data появятся первые значения. Я на момент отладки на всякий случай поставил сбор данных каждые 60 секунд. Когда убедился, что все работает, изменил это значение обратно на 3600.

Заключение

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

Сообщение Мониторинг программного рейда mdadm в zabbix появились сначала на Clip-Clap.

Введение

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

Чем больше доменов я ставил на мониторинг, тем чаще сталкивался с тем, что по каким-то зонам не мог получить инфу. Из свежих примеров — .pro, .fm, .io. Наверняка были и другие, но я сталкивался с проблемами именно в этих зонах. Решил разобраться с этим вопросом поподробнее.

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

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

Ниже я опишу несколько консольных способов получения информации о времени оплаты домена для передачи этой информации в zabbix:

• Ruby gem Whois.
• Консольная утилита linux — whois, jwhois.
• Питоновский модуль — python-whois.
• Whois client для node.js.

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

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

Подготовка к мониторингу за доменами

Для мониторинга за сроком делегирования доменов мы будем использовать скрипт на языке программирования Ruby. Чтобы скрипт работал, необходимо установить Ruby на сервер. Там как раз речь идет об установке необходимого гема whois-parser для мониторинга срока делегирования домена.

Парсинг времени делегирования домена через ruby

Если у вас настроен и готов к работе zabbix и установлен ruby, приступаем к настройке скриптов. Идем в папку /etc/zabbix/scripts и создаем там скрипт:

# mcedit /etc/zabbix/scripts/domain_left.rb

#!/usr/bin/env ruby

require 'whois-parser'

record = Whois.whois(ARGV[0])
parser = record.parser
expire = parser.expires_on.strftime("%Y-%m-%d")
today = Time.now.strftime("%Y-%m-%d")
expire_date = DateTime.parse(expire)
today_date = DateTime.parse(today)
left = (expire_date - today_date).to_i
puts left

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

# /etc/zabbix/scripts/domain_left.rb serveradmin.ru
394

Отлично, на выходе просто число, которое очень удобно передать в zabbix. Данный скрипт я написал не сам, а подсмотрел у автора этой статьи. У него есть большой минус. В скрипте используется whois-parser и его функция expires_on. Сделано это для упрощения создания скрипта. Не пришлось вручную парсить вывод, за нас это сделали авторы гема whois-parser. Но эти функции работают не со всеми доменами. В разных зонах вывод может быть разным. Покажу на примере.

Для этого создадим простой скрипт на ruby, который будет просто выводить информацию whois без парсинга, в сыром виде.

#!/usr/bin/env ruby

require 'whois-parser'
domain = ARGV[0]
whois = Whois::Client.new
r = whois.lookup(domain)
puts r

Сохраняем скрипт и проверим с его помощью 2 домена: из зоны .pro и зоны .ru.

# ./domain.rb server.pro

# ./domain.rb serveradmin.ru

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

Registry Expiry Date: 2019-08-18T00:00:00Z

а в другом вот так:

paid-till:     2019-08-09T11:01:06Z

Whois-parser умеет обрабатывать только первую строчку, вторую он не понимает, поэтому приведенный выше скрипт выдаст ошибку. Но в целом, библиотека ruby whois по моим опытам корректно обрабатывает больше всего доменов. Нужно только правильно распарсить вывод. Я программировать на ruby не умею, разбираться у меня не было времени, поэтому я оставил это решение как есть. Можно, конечно, выводить в текстовый файл, а потом парсить вывод через bash. Это я умею, но не захотелось костылить таким образом. Да и в целом, мне не нравится этот способ тем, что надо ставить ruby и регулярно обновлять его библиотеку. Только это гарантирует поддержку новых зон и всех изменений по старым.

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

Пока же я просто сделал костыль и распарсил вывод с помощью bash следующим образом:

#!/bin/bash

DOMAIN="$1"

data=$(/etc/zabbix/scripts/domain-simple.rb $1 | grep -E 'paid|Expir' | grep -o -E '[0-9]{4}.[0-9]{2}.[0-9]{2}|[0-9]{2}/[0-9]{2}/[0-9]{4}' | tr . / | awk 'NR == 1')
expire=$((`date -d "$data" '+%s'`))
today=$((`date '+%s'`))
lefts=$(($expire - $today))
leftd=$(($lefts/86400))
echo $leftd

Сам скрипт domain-simple.rb:

#!/usr/bin/env ruby

require 'whois-parser'
record = Whois.whois(ARGV[0])
puts record

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

Linux утилиты whois и jwhois

В комментариях к первоначальной статье мне подсказали про консольную утилиту whois, а позже я нагуглил и еще одну — jwhois. Я посмотрел на них внимательно и написал простенький скрипт для парсинга информации о делегировании. Данный способ самый простой и удобный. Обе утилиты ставятся через yum, первая из базового репозитория, вторая из репозитория epel. Не нужно дополнительных инструментов. Информативность средняя — все популярные домены есть, в том числе .io, но .pro и .fm не поддерживает. Увы и ах, мне они нужны.

Установим утилиту whois:

# yum install whois

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

#!/bin/bash
 
DOMAIN="$1"
 
data=$(whois $1 | grep -E 'paid|Expir|expir' | grep -o -E '[0-9]{4}.[0-9]{2}.[0-9]{2}|[0-9]{2}/[0-9]{2}/[0-9]{4}' | tr . / | awk 'NR == 1')
expire=$((`date -d "$data" '+%s'`))
today=$((`date '+%s'`))
lefts=$(($expire - $today))
leftd=$(($lefts/86400))
echo $leftd

Сохраняйте скрипт и проверяйте работу. Работает так же, как и скрипт для ruby.

# ./domain_left.sh serveradmin.ru
358

Я для себя решил остановиться на этом способе, как самом простом и универсальном.

Модуль python-whois для мониторинга оплаты доменов

В рамках своего исследования я решил проверить как с помощью python можно получать информацию whois. Я подозревал, что должен быть готовый модуль для этого и не ошибся. Такой модуль есть — python-whois. Для его работы нужен python версии 2, который по-умолчанию стоит в системе CentOS 7, что очень удобно.

Нам нужно только установить этот модуль через pip. Pip для 2-й версии ставится из репозитория epel.

# yum install python2-pip
# pip install python-whois

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

#!/usr/bin/env python

import whois
from datetime import datetime
from sys import argv,exit

now = datetime.now()
domain = argv[1]

w = whois.whois(domain)

if type(w.expiration_date) == list:
    w.expiration_date = w.expiration_date[0]
else:
    w.expiration_date = w.expiration_date

domain_expiration_date = str(w.expiration_date.day) + '/' + str(w.expiration_date.month) + '/' + str(w.expiration_date.year)
timedelta = w.expiration_date - now
days_to_expire = timedelta.days

Проверка:

# ./domain-left.py serveradmin.ru
358

Работает так же, как и предыдущие скрипты. Решение на python поддерживает зоны .pro, .fm, не поддерживает .io.

Whois клиент для Node.js

Последнее рассмотренное мной консольное решение по получению данных whois основывается на клиенте для Node.js. Этот способ неудобен, как и с ruby, тем, что надо отдельно ставить node на сервер. Если python на centos сервере точно будет, то node придется ставить отдельно. Сделаем это.

# curl --silent --location https://rpm.nodesource.com/setup_8.x | sudo bash -
# yum install nodejs

Устанавливаем whois client:

# npm install whois

Под node.js я программировать вообще не умею и со скриптами не работал никогда. Так что готового скрипта для zabbix не сделал. Покажу на простом примере, как выполнять проверку. Делаем скрипт и в нем сразу указываем домен для проверки.

var whois = require('whois')
whois.lookup('serveradmin.ru', function(err, data) {
    console.log(data)
    })

Запускаем его:

# node domain-left.js

В выводе увидите привычную информацию whois в таком же виде, как и для остальных проверок. Если бы этот способ проверял все необходимые мне домены, я бы его доделал. Он понимает домены .pro и .io, но не понимает .fm. Так что я не стал на нем подробно останавливаться.

Скрипт auto discovery доменов для zabbix

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

# mcedit /etc/zabbix/scripts/domain_discovery.sh

#!/bin/bash
JSON=$(for i in `cat /etc/zabbix/scripts/domain_list.txt`; do printf "{\"{#DOMAIN}\":\"$i\"},"; done | sed 's/^\(.*\).$/\1/')
printf "{\"data\":["
printf "$JSON"
printf "]}"

И последнее — создадим файл со списком доменов. Каждый домен с новой строки.

# mcedit /etc/zabbix/scripts/domain_list.txt

yandex.ru
mail.ru

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

# /etc/zabbix/scripts/domain_discovery.sh
{"data":[{"{#DOMAIN}":"mail.ru"},{"{#DOMAIN}":"yandex.ru"}]}

Вывод подходящий для передачи в заббикс.

Настройка zabbix агента

Я настраиваю zabbix агент на работу со скриптом на ruby. Вы можете выбрать скрипт по своему усмотрению. Изменить нужно будет только путь к скрипту в описании итема domain.expire.

Добавим скрипты через пользовательские параметры (UserParameter) агента. Для этого идем в папку с пользовательскими скриптами /etc/zabbix/zabbix_agentd.d и создаем там конфиг для наших параметров:

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

UserParameter=domain.discovery[*], /bin/bash /etc/zabbix/scripts/domain_discovery.sh
UserParameter=domain.expire[*], /usr/local/bin/ruby /etc/zabbix/scripts/domain_left.rb $1

Обращаю внимание на путь к ruby. В разных системах он может быть разный. Проверьте куда он у вас установлен и отредактируйте путь. Проверить можно командой:

# whereis ruby
ruby: /usr/lib64/ruby /usr/local/bin/ruby /usr/local/lib/ruby /usr/share/ruby /usr/src/ruby-2.3.1/ruby.o /usr/src/ruby-2.3.1/ruby /usr/src/ruby-2.3.1/ruby.c

Сохраняйте конфиг и перезапускайте zabbix agent:

# systemctl restart zabbix-agent

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

Создание шаблона для наблюдения за доменами

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

Импортируете шаблон себе в систему. Назначаете его хосту, в котором настроили скрипты и ждете появления данных. Минут через 5 проверяете в Latest Data:

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

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

Сообщение Мониторинг времени делегирования домена в zabbix появились сначала на Clip-Clap.

Введение

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

Дальнейшие действия я буду выполнять в системе CentOS 7 и версии Zabbix сервера 3.4.6. Все описанное ниже будет актуально и для других систем и версий заббикса, так как разработчики стараются максимально сохранять совместимость между версиями.

Подготовка тестового триггера

Я в своих статьях по настройке заббикса часто использую в качестве примера триггер, который срабатывает, когда залогиненных пользователей в системе становится больше 2-х. Он основывается на стандартном итеме шаблона Template OS Linux — Number of logged in users.

Триггер срабатывает, когда каждое из двух последних значения залогиненных в систему пользователей больше двух (count(#2,1,»gt»)}=2), выключается, когда последнее значение залогиненных пользователей меньше двух (last(#1)}<2). То есть, когда мы заходим двумя пользователями на сервер, через 2 минуты срабатывает триггер. Когда остается только один пользователь или вообще ни одного, через минуту триггер выключается.

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

Настройка повторяющегося оповещения

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

Во вкладке Действие указываете имя и добавляете тестовый триггер.

Дальше переходим в раздел Операции и указываем длительность шага равное 1 минуте. Добавляем шаг с параметром 1 — 0 и указываем необходимое действие. В примере я просто буду отправлять всем администраторам оповещение на почту.

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

Заключение

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

Если вы настроили мониторинг бэкапов, который выполняется ночью, то его тоже не обязательно чинить в ту же минуту, можно отложить на вечернее время. Чтобы не забыть, можно настроить уведомления раз в 2 часа. И так далее. Смысл, я думаю, понятен.

Сообщение Повторяющиеся уведомления в Zabbix появились сначала на Clip-Clap.

Введение

Если у вас еще нет готовой системы мониторинга, можете воспользоваться моей статьей по установке и настройке zabbix на centos.

Задача по своей сути не сложная. Нечто похожее я уже делал, когда настраивал мониторинг температуры процессора в windows сервере. Мы берем текстовый файл, парсим его с помощью bat файлов и передаем готовые числовые или строковые значения в Zabbix через windows агента и функционал UserParameter.

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

Скрипты для парсинга значений

Первый текстовый файл имел примерно такое содержание:

state_pump_1: off
state_pump_2: off
running_time_pump_1: 557
running_time_pump_2: 442
sensor: empty
general_state: OK

Описание возможных значений параметров:

• state_pump может принимать значения on или off
• running_time_pump имеет нарастающее числовое значение
• sensor может принимать 3 значения: empty, full, overflow
• general_state либо ОК, либо номер ошибки

Рисуем батник для первого параметра. Если значение on, передаем в заббикс 1, если off — 0.

@echo off
for /f "delims=" %%a in ('find /i "state_pump_1: off" ^< D:\Насосы.txt') do echo 0
for /f "delims=" %%a in ('find /i "state_pump_1: on" ^< D:\Насосы.txt') do echo 1

Обращаю внимание на то, что у меня имя файла было на русском языке. Чтобы его корректно обрабатывало, необходимо сохранить файл в кодировке OEM 866. ПО крайней мере так она называлась в Notepad++, который я использовал для изменения кодировки. Это была самая простая задача, которая решилась прямо в лоб. По аналогии написал скрипт для параметра sensor:

@echo off
for /f "delims=" %%a in ('find /i "sensor: empty" ^< D:\Насосы.txt') do echo 0
for /f "delims=" %%a in ('find /i "sensor: full" ^<D:\Насосы.txt') do echo 1
for /f "delims=" %%a in ('find /i "sensor: overflow" ^< D:\Насосы.txt') do echo 2

Дальше пришлось соображать, как передать числовое значение, обрезав все, что стоит перед ним. Наверное, для любого программиста это простая задача, для скрипта в linux я тоже не вижу больших проблем придумать что-нибудь с sed, cat, grep или чем-то еще. Но тут у меня в распоряжении bat. Можно было на vbs написать, но для меня это было бы еще сложнее.

Начал читать документацию по for и find, смотреть примеры и пробовать. В итоге все получилось очень просто и коротенько, но повозиться мне пришлось прилично, пока родились эти строки:

@echo off
for /f "delims=" %%a in ('find /i "running_time_pump_1:" ^< D:\Насосы.txt') do set str=%%a
set d=%str:~21,25%
Echo %d%

Подробно описывать не буду, что тут к чему, при желании сами можете поискать описание параметров. Обращу внимание только на строку set d=%str:~21,25%. Она меня очень выручила. Наткнулся где-то в примере на описание обрезания строк по заданным колонкам. Тут мы выводим значения с 21 по 25 колонки найденной строки. Как раз то, что мне нужно. На выходе просто цифры, которые отлично принимает zabbix.

Обработку параметра general_state делаем аналогичным способом:

@echo off
for /f "delims=" %%a in ('find /i "general_state:" ^< D:\Насосы.txt') do set str=%%a
set d=%str:~15,25%
Echo %d%

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

Второй текстовый файл был примерно такого содержания:

Power = 1
MAP = 1
bypass = 0
Voltage = 230
Electric_current = 5.1
Full_power = 1173
Active_power = 959
Reactive_power = 676
Cos_F = 0.82
frequency = 50

Здесь по аналогии делается все так же, как и в первом примере за одним исключением. Я в какой-то момент поставил в команде find ключ /i, который означает, что значение ищется без учета регистра. В итоге в новом файле я получил проблемы при поиске строк, где есть слово power. Таких строк несколько, причем первая точно повторяет 6-ю, где встречается точно такая же конструкция:

Power = 1
Full_power = 1173

Или еще пример со строками:

Active_power = 959
Reactive_power = 676

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

@echo off
for /f "eol=R delims=" %%a in ('find /i "active_power =" ^< D:\Электрика.txt') do set str=%%a
set d=%str:~15,19%
Echo %d%

То есть я нахожу первую и нужную мне строку с active_power, а вторую, где тоже есть эта фраза пропускаю, так как она начинается с символа R. Такой вот костыль придумал, но тем не менее поставленную задачу эта конструкция решает. Рассказываю об этом, чтобы поделиться опытом и самому потом не забыть эти подходы. В итоге я просто убрал ключ /i в команде find и поиск стал работать с учетом регистра без лишних телодвижений.

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

Добавляем 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                                         [t|1]

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

Настройка новый итемов на сервере zabbix

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

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

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

Заключение

Подобным способом можно настроить мониторинг любых значений текстового файла. Достаточно его распарсить нужным образом. Хотя в большинстве случаев это будет костылем. У заббикса очень много способов получения данных. Лучше обходиться без промежуточных звеньев в виде текстового файла и передавать данные напрямую в zabbix. Но конкретно в данной ситуации это было самое простое и быстрое решение.

Сообщение Мониторинг значений из текстового файла в Zabbix появились сначала на Clip-Clap.

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

Существует бесплатная утилита Open Hardware Monitor, которая может показывать температуру некоторых датчиков сервера. Вообще говоря, она много чего может показывать (напряжение, скорость вентиляторов, загрузку процессора), но в данном случае нас интересует только температура. У этой утилиты есть версия, работающая в командной строке. Из командной строки показания датчиков можно записывать в файл. Этот файл можно анализировать и забирать из него необходимую для мониторинга информацию. Дальше эта информация передается в сервер Zabbix с помощью опции UserParameter. Все достаточно просто и в то же время эффективно.

Приступим к реализации. Скачиваем GUI версию утилиты по ссылке, приведенной ранее и консольную версию OpenHardwareMonitorReport. Запускаем GUI на сервере и смотрим, какие датчики нам доступны для мониторинга.

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

Оказалось — 45 градусов. Я запомнил, что датчик Temperature #3 отображает температуру материнской платы.

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

Почему-то в этой панели не оказалось информации с датчика температуры процессора. Но нам это не важно. Самое главное, что мы узнали параметры, за которыми будем следить — это CPU Packege и Temperature #3. Теперь запускаем консольную версию и смотрим вывод информации. Я для удобства положил OpenHardwareMonitorReport.exe в папку с основной программой и все это хозяйство скопировал в корень диска C:

Открываем файл 1.txt. Ищем там строки

|  +- CPU Package    :       52       51       52 (/intelcpu/0/temperature/4)

|  |  +- Temperature #3 :       45       45       45 (/lpc/nct6776f/temperature/3)

Нас интересует выделенный текст. По нему мы будем вычленять температуру для мониторинга и передавать ее на Zabbix сервер. Создаем в этой же папке 2 bat файла следующего содержания:

CPUTemperature.bat

@echo off
for /F "usebackq tokens=7-10" %%a in (`C:\OpenHardwareMonitor\OpenHardwareMonitorReport.exe`) do echo %%b %%c %%d| find "/intelcpu/0/temperature/4">nul && set temper=%%a 
echo %temper%

MotherTemperature.bat

@echo off
for /F "usebackq tokens=7-10" %%a in (`C:\OpenHardwareMonitor\OpenHardwareMonitorReport.exe`) do echo %%b %%c %%d| find "/lpc/nct6776f/temperature/3">nul && set temper=%%a 
echo %temper%

Запускаем эти батники в командной строке и проверяем вывод. Там должны быть только цифры температуры:

Отлично, на выходе готовые цифры, которые мы будем передавать в Zabbix. Займемся его настройкой.

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

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

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

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

Настройка мониторинга на 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 Ждем некоторое время и проверяем результат.

item became not supported

Во время отладки работ я столкнулся с проблемами. Периодически Item отваливались и получали статус: Not Supported. При этом в логах сервера были следующие записи:

27614:20150702:065936.698 item "videoserver:Temperature.CPU" became not supported: Timeout while executing a shell script.
27625:20150702:070938.720 item "videoserver:Temperature.CPU" became supported

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

Я обратил внимание, что при запуске батника из командной строки, вывод данных происходит с приличной задержкой в 3-5 секунд. В Zabbix по-умолчанию стоит параметр, по которому агент ожидает ответа от скрипта 3 секунды и на сервере есть подобный параметр, по которому сервер ждет ответа от агента 3 секунды. Если за это время данные не поступают, то итем переходит в статус Not Supported и данные с него не собираются.

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

Timeout=15

Потом перезапускаем сервер и агентов и ждем результатов. Больше ошибок быть не должно.

На этом, собственно настройка мониторинга температуры окончена. Можно дальше все оформить как полагается: настроить тригеры, оповещения, графики красивые нарисовать. Кому что нужно. Я себе вывел вот такую картинку для наглядности:

Сообщение Zabbix настройка мониторинга температуры появились сначала на Clip-Clap.