В стандартных шаблонах Zabbix есть триггеры на загрузку процессора, а так же на превышение максимально допустимого числа процессов. Триггеры эти практически бесполезны, если у вас плавающая нагрузка. Допустим, вы получаете уведомление о том, что у вас сильно нагружен процессор. Через 10 минут нагрузка прошла, а вы не успели зайти на сервер и посмотреть, чем он был нагружен в это время. Вот эту проблему я и решаю своим велосипедом, которым делюсь в статье.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном онлайн-курcе по администрированию MikroTik. Автор курcа – сертифицированный тренер MikroTik Дмитрий Скоромнов. Более 40 лабораторных работ по которым дается обратная связь. В три раза больше информации, чем в MTCNA.
Введение
Рассказываю подробно, что я хочу получить в конце статьи. В стандартном шаблоне Zabbix для Linux есть несколько триггеров. Они могут немного отличаться в названиях, в зависимости от версии шаблона, но смысл один и тот же:
- High CPU utilization
- Load average is too high
- Too many processes on hostname
Я хочу получить информацию о запущенных процессах на хосте в момент срабатывания триггера. Это позволит мне спокойно посмотреть, что создает нагрузку, когда у меня будет возможность. Мне не придется идти руками в консоль хоста и пытаться ловить момент, когда опять появится нагрузка.
В дефолтной конфигурации у Zabbix нет готовых инструментов, чтобы реализовать желаемое. Вы можете настроить мониторинг процесса или группы процессов в Zabbix. Но это не то, что нужно. Можно настроить автообнаружение всех процессов и мониторить их. Чаще всего это тоже не нужно, а подобный мониторинг будет генерировать большую нагрузку и сохранять кучу данных в базу. Особенно если на сервере регулярно запущено несколько сотен процессов.
Моя задача посмотреть на список процессов именно в момент нагрузки. Более того, мне даже не нужны все процессы, достаточно первой десятки самых активных, нагружающих больше всего систему. Я буду реализовывать этот мониторинг следующим образом:
- Добавляю в стандартный шаблон новый айтем типа Zabbix Trapper.
- Разрешаю на zabbix agent запуск внешних команд.
- Настраиваю на Zabbix Server действие при срабатывании одного из нужных мне триггеров. В действии указываю выполнение команды на целевом сервере, которая сформирует список процессов и отправит его на сервер мониторинга с помощью zabbix-sender.
Приступаем к реализации задуманного. Я буду настраивать описанную схему на Zabbix Server версии 5.2. Если у вас его нет, читайте мою статью по установке и настройке zabbix. В качестве подопытной системы будет выступать Centos. Так же предлагаю мои статьи по ее установке и предварительной настройке.
Подготовка сервера к мониторингу процессов
Первым делом идем на целевой сервер и изменяем конфигурацию zabbix-agent. Нам надо активировать следующую опцию:
EnableRemoteCommands=1
Не забудьте после этого перезапустить агента.
# systemctl restart zabbix-agent
Предупреждаю, что подобная настройка - огромная дыра в безопасности сервера. Используйте на свой страх и риск. Чтобы у вас не было проблем с этим, настоятельно рекомендую ограничивать доступ к порту агента на сервере на уровне firewall только с сервера мониторинга. Так же в обязательном порядке использовать шифрованное соединение между сервером и агентом. Вообще, это универсальное правило при настройке мониторинга. В идеале, так надо делать всегда. Я стараюсь все это настраивать при работе мониторинга через интернет. Если проигнорировать данное предупреждение и оставить все в открытом доступе, то через разрешенные удаленные команды вам могут залить на сервер зловред.
Далее проверим команду, которая будет формировать список процессов для отправки на сервер мониторинга. Я предлагаю использовать вот такую конструкцию, но вы можете придумать что-то свое.
# ps aux --sort=-pcpu,+pmem | awk 'NR<=10'
Получаем список запущенных процессов, отсортированный по потреблению cpu и ограниченный первыми десятью строками. В данный момент на сервере с агентом нам делать нечего. Перемещаемся в web интерфейс Zabbix Server.
Настройка мониторинга за процессами
На Zabbix сервере идем в стандартный шаблон Linux и добавляем туда 2 новых айтема:
- Process List - список процессов, ограниченный десятью с самой высокой нагрузкой на cpu. Сюда будем записывать информацию о процессах на сервере при срабатывании триггеров на повышенную нагрузку CPU.
- Full Process List - полный список всех процессов. Сюда запишем полный список всех процессов, когда сработает триггер на превышение максимально допустимого количества запущенных процессов на сервере.
Так выглядит первый айтем. Второй сделайте по аналогии.
Теперь идем на сервер с агентом и пробуем отправку данных в данный айтем. Для этого нам нужен будет zabbix_sender. Если у вас его нет, то установите.
# yum install zabbix-sender
Отправку данных проверяем следующим образом:
/usr/bin/zabbix_sender -c /etc/zabbix/zabbix_agentd.conf -k process.list -o "`ps aux --sort=-pcpu,+pmem | awk 'NR<=10'`"
Я не буду подробно останавливаться на формате запросов с помощью zabbix_sender. Все это хорошо описано в документации. Теперь идем в веб интерфейс сервера и в разделе Последние данные смотрим на список процессов, который нам пришел с целевого сервера.
Ровно то, что нам было нужно. То же самое можно проверить с айтемом Full Process List, убрав в команде | awk 'NR<=10' в конце.
Далее нам нужно создать действие, которое будет запускать данную команду на сервере при срабатывании триггеров. Для этого идем в раздел Настройка -> Действия и добавляем новое.
Сохраняйте действие и можно проверять.
Проверка отправки списка процессов
Теперь проверим, как все это будет работать. Для этого идем на целевой сервер и нагружаем его чем-нибудь. Я для примера запустил в двух разных консолях по команде:
# cat /dev/zero | bzip2 -c > /dev/null # md5sum /dev/urandom
Они достаточно быстро нагрузили единственное ядро тестового сервера, так что оставалось только подождать активации триггера. Через 5 минут это случилось.
Иду в раздел Последние данные и вижу там список процессов, которые нагрузили мой сервер.
Что мне в итоге и требовалось. Теперь нет нужды каким-то образом проверять, что конкретно нагружает сервер. В момент пиковой нагрузки я получу список запущенных процессов в отдельный айтем. Для полного списка процессов все делается по аналогии.
Заключение
Вот такую реализацию я придумал, когда потребовалось решить задачу. Один сервер постоянно донимал оповещениями по ночам. Нужно было понять, что его дергает в это время. Жаль, что у Zabbix из коробки нет реализации подобного информирования. Помню лет 5 назад был бесплатный тариф у мониторинга NewRelic. Можно было поставить агент мониторинга на сервер и потом смотреть очень удобные отчеты в веб интерфейсе. Никаких настроек не нужно было, все работало из коробки. Там были отражены все запущенные процессы на сервере на временном ряду со всеми остальными метриками. Это было очень удобно. Я нигде в бесплатном софте не видел такой реализации. Это примерно вот так выглядело.
Кстати, в первоначальной версии действия я просто отправлял список процессов на почту. Мне показалось это удобным. Можно было сразу же в почте, в соседнем письме с триггером, посмотреть список процессов. Но потом решил, что удобнее все же хранить историю в одном месте на сервере и настроил сбор данных туда. Хотя можно делать и то, и другое. Например, в действии можно указать другую команду к исполнению:
# ps aux --sort=-pcpu,+pmem | awk 'NR<=10' | mail -s "Process List" zabbix@mail.ru
И вам на почту придет список запущенных процессов после активации триггера.
На углубленном курсе "Архитектура современных компьютерных сетей" вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.
Раньше я собирал данные по 10 самым прожорливым процессам каждую минуту, просто sender в cron отрабатывал. А теперь переделал на этот вариант, реально работает, спасибо)
Добрый день
в действиях на вкладке операции доступна только опция отправить сообщение
Все излазил не нашел "Удаленная команда"
Подскажите пожалуйста может ее теперь куда-то в другое место убрали?
zabbix 6.0
Этот функционал в версии 6 сильно изменился. Появился отдельный раздел для скриптов (Администрирование -> Скрипты). Надо туда добавить скрипт, а потом уже выбрать его через выпадающий список в действиях, в разделе "операция".
Добрый день!
Возможен ли мониторинг для windows систем. Т.е. чтобы видеть какое приложение сколько съело памяти, как грузило процессор и на сколько сильно грузило дисковую подсистему?
Zabbix такой мониторинг не поддерживает.
Удалось найти решение?
Добрый день, Владимир!
Наткнулся на эту статью, с интересом ознакомился, большое спасибо.
Несколько замечаний.
1. Про использование опции "EnableRemoteCommands=1":
а) я всегда вместе с ней включаю также и "LogRemoteCommands=1" (просто для перестраховки, чтобы при необходимости можно было видеть, что именно через таким образом запускалось);
б) я не считаю таким уж критичным использование локального фаервола (хотя это и не лишне) и шифрования, по крайней мере - в локальной сети. Обычно бывает достаточно того, что правильно выставлен параметр "Server=" - он эффективно ограничивает попытки соединения с "левых" адресов. Если между агентом и сервером трафик идёт в открытую через Интернет, то все эти навороты имеют смысл, а в пределах своей локальной сети - весьма спорно: например, шифрование явно усложняет настройки и слегка подгружает как агент, так и сервер;
в) для работы всей этой конструкции необходимо, чтобы агент поддерживал работу в пассивном режиме: для active-only режима она работать не будет.
2. Для вырезания только первых 10 строк лучше использовать не "awk 'NR<=10'" (поскольку awk "тяжелее", т.к. каждую входную строку анализирует и разбивает на поля), а "head -n 10" (более лёгкая альтернатива). Хотя, применительно к данной задаче это и не принципиально.
3. Чтобы хранить многострочное текстовое значение на сервере, тип элемента данных лучше указывать не "Log", а "Text". Для типа "Log" в базе данных Zabbix предусмотрены дополнительные поля под метаданные - такие как таймстэмп события в логе, его EventID, Source и Severity, которые через "zabbix_sender" всё равно не передаются.
4. Данное решение подходит только для *NIX-систем, на Windows нужны какие-то свои средства. Я не большой специалист в скриптах под Windows; но простого и "лёгкого" решения для этой операционки у меня нет (а было бы любопытно). Теоретически, можно любые вещи сделать через PowerShell, но, к сожалению, сам вызов PS довольно "тяжёлый": занимает несколько секунд и изрядно подгружает операционку, что сильно "смазывает" картину (особенно применительно к данной задаче). Наверное, можно дёргать тот же агент Zabbix для выполнения WMI-запроса (возможно, с какой-то последующей промежуточной обработкой результата через препроцессинг уже на сервере Zabbix)...
Привет!
Не вкурсе как выполнение скрипта по срабатыванию триггера на 5.4 сделать? Actions все перерыл - там только отправка сообщений
Там немного поменялась логика. Сначала нужно добавить скрипт в раздел Администрирование -> Скрипты. А потом уже его использовать в Действиях.
Привет!
Вот только что разобрался ))) Я добавлял скрипт в раздел, только Scope не тот указал - надо Action operation, а я Manual host action выбрал.
Спасибо за помощь!
Владимир, а никак по другому не сделать? Может быть появился свой элемент или шаблон, чтобы не городить надстройку в виде забикс сендера и разрешения на выполнение команд?
Ничего готового на этот счет в Zabbix я не видел. Так что реализация остается за конечным пользователем системы мониторинга. Тут сделано просто и топорно, зато тратится минимум ресурсов и не хранится в базе ничего лишнего. Можно делать более грамотно через автообнаружение процессов на примере того, как это сделано в шаблоне windows со службами. Но это длинный путь. Мне жаль было тратить время на реализацию.
Разве NewRelic не стал сейчас снова бесплатным?
Я не видел такую информацию. Я им долго пользовался, пока был бесплатный тариф. Потом они его убрали, и я больше с ним не работал.
Он реально опять free тариф добавил.