В стандартных шаблонах Zabbix есть триггеры на загрузку процессора, а так же на превышение максимально допустимого числа процессов. Триггеры эти практически бесполезны, если у вас плавающая нагрузка. Допустим, вы получаете уведомление о том, что у вас сильно нагружен процессор. Через 10 минут нагрузка прошла, а вы не успели зайти на сервер и посмотреть, чем он был нагружен в это время. Вот эту проблему я и решаю своим велосипедом, которым делюсь в статье.
Если у вас есть желание научиться администрировать системы на базе Linux, рекомендую познакомиться с онлайн-курсом «Linux для начинающих» в OTUS. Курс для новичков, для тех, кто с Linux не знаком. Подробная информация.
Содержание
Введение
Рассказываю подробно, что я хочу получить в конце статьи. В стандартном шаблоне Zabbix для Linux есть несколько триггеров. Они могут немного отличаться в названиях, в зависимости от версии шаблона, но смысл один и тот же:
- High CPU utilization
- Load average is too high
- Too many processes on hostname
Я хочу получить информацию о запущенных процессах на хосте в момент срабатывания триггера. Это позволит мне спокойно посмотреть, что создает нагрузку, когда у меня будет возможность. Мне не придется идти руками в консоль хоста и пытаться ловить момент, когда опять появится нагрузка.
Установка и настройка Zabbix Agent на Windows.
В дефолтной конфигурации у Zabbix нет готовых инструментов, чтобы реализовать желаемое. Вы можете настроить мониторинг процесса или группы процессов в Zabbix. Но это не то, что нужно. Можно настроить автообнаружение всех процессов и мониторить их. Чаще всего это тоже не нужно, а подобный мониторинг будет генерировать большую нагрузку и сохранять кучу данных в базу.
Особенно если на сервере регулярно запущено несколько сотен процессов.
Моя задача посмотреть на список процессов именно в момент нагрузки. Более того, мне даже не нужны все процессы, достаточно первой десятки самых активных, нагружающих больше всего систему. Я буду реализовывать этот мониторинг следующим образом:
- Добавляю в стандартный шаблон новый айтем типа Zabbix Trapper.
- Разрешаю на zabbix agent запуск внешних команд.
- Настраиваю на Zabbix Server действие при срабатывании одного из нужных мне триггеров. В действии указываю выполнение команды на целевом сервере, которая сформирует список процессов и отправит его на сервер мониторинга с помощью zabbix-sender.
Приступаем к реализации задуманного. Я буду настраивать описанную схему на Zabbix Server версии 5.2. Если у вас его нет, читайте мою статью по установке и настройке zabbix. В качестве подопытной системы будет выступать Centos. Так же предлагаю мои статьи по ее установке и предварительной настройке.
Сразу же сделаю важное замечание. Все, что написано далее, полностью придумано и реализовано мной. Это не самый оптимальный вариант решения задачи, но лично я ничего лучше, удобнее, проще придумать не смог. Если вы знаете, как сделать то же самое лучше, поделитесь информацией. С удовольствием ознакомлюсь с ней.
Zabbix с нуля до короля. Часть 1
Подготовка сервера к мониторингу процессов
Первым делом идем на целевой сервер и изменяем конфигурацию zabbix-agent. Нам надо активировать следующую опцию:
EnableRemoteCommands=1
Не забудьте после этого перезапустить агента.
# systemctl restart zabbix-agent
Предупреждаю, что подобная настройка — огромная дыра в безопасности сервера. Используйте на свой страх и риск. Чтобы у вас не было проблем с этим, настоятельно рекомендую ограничивать доступ к порту агента на сервере на уровне firewall только с сервера мониторинга. Так же в обязательном порядке использовать шифрованное соединение между сервером и агентом.
Вообще, это универсальное правило при настройке мониторинга. В идеале, так надо делать всегда. Я стараюсь все это настраивать при работе мониторинга через интернет. Если проигнорировать данное предупреждение и оставить все в открытом доступе, то через разрешенные удаленные команды вам могут залить на сервер зловред.
Далее проверим команду, которая будет формировать список процессов для отправки на сервер мониторинга. Я предлагаю использовать вот такую конструкцию, но вы можете придумать что-то свое.
# ps aux —sort=-pcpu,+pmem | awk ‘NR
Получаем список запущенных процессов, отсортированный по потреблению 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
Я не буду подробно останавливаться на формате запросов с помощью zabbix_sender. Все это хорошо описано в документации. Теперь идем в веб интерфейс сервера и в разделе Последние данные смотрим на список процессов, который нам пришел с целевого сервера.
Ровно то, что нам было нужно. То же самое можно проверить с айтемом Full Process List, убрав в команде | awk ‘NR в конце.
Далее нам нужно создать действие, которое будет запускать данную команду на сервере при срабатывании триггеров. Для этого идем в раздел Настройка -> Действия и добавляем новое.
Сохраняйте действие и можно проверять.
Проверка отправки списка процессов
Теперь проверим, как все это будет работать. Для этого идем на целевой сервер и нагружаем его чем-нибудь. Я для примера запустил в двух разных консолях по команде:
# cat /dev/zero | bzip2 -c > /dev/null # md5sum /dev/urandom
Они достаточно быстро нагрузили единственное ядро тестового сервера, так что оставалось только подождать активации триггера. Через 5 минут это случилось.
Иду в раздел Последние данные и вижу там список процессов, которые нагрузили мой сервер.
Что мне в итоге и требовалось. Теперь нет нужды каким-то образом проверять, что конкретно нагружает сервер. В момент пиковой нагрузки я получу список запущенных процессов в отдельный айтем. Для полного списка процессов все делается по аналогии.
Заключение
Вот такую реализацию я придумал, когда потребовалось решить задачу. Один сервер постоянно донимал оповещениями по ночам. Нужно было понять, что его дергает в это время. Жаль, что у Zabbix из коробки нет реализации подобного информирования. Помню лет 5 назад был бесплатный тариф у мониторинга NewRelic.
Можно было поставить агент мониторинга на сервер и потом смотреть очень удобные отчеты в веб интерфейсе. Никаких настроек не нужно было, все работало из коробки. Там были отражены все запущенные процессы на сервере на временном ряду со всеми остальными метриками. Это было очень удобно. Я нигде в бесплатном софте не видел такой реализации.
Это примерно вот так выглядело.
Кстати, в первоначальной версии действия я просто отправлял список процессов на почту. Мне показалось это удобным. Можно было сразу же в почте, в соседнем письме с триггером, посмотреть список процессов. Но потом решил, что удобнее все же хранить историю в одном месте на сервере и настроил сбор данных туда. Хотя можно делать и то, и другое. Например, в действии можно указать другую команду к исполнению:
# ps aux —sort=-pcpu,+pmem | awk ‘NR
И вам на почту придет список запущенных процессов после активации триггера.
Если у вас есть желание научиться администрировать системы на базе Linux, но вы с ними никогда не работали и не знакомы, то рекомендую начать с онлайн-курса «Linux для начинающих» в OTUS. Курс для новичков, для тех, кто с Linux не знаком. Цена за курс минимальная (символическая). Информация о курсе и цене.
Помогла статья? Подписывайся на telegram канал автора
Анонсы всех статей, плюс много другой полезной и интересной информации, которая не попадает на сайт.
Автор Zerox
Владимир, системный администратор, автор сайта. Люблю настраивать сервера, изучать что-то новое, делиться знаниями, писать интересные и полезные статьи. Открыт к диалогу и сотрудничеству. Если вам интересно узнать обо мне побольше, то можете послушать интервью. Запись на моем канале — https://t.me/srv_admin/425 или на сайте в контактах.
15 комментариев
Раньше я собирал данные по 10 самым прожорливым процессам каждую минуту, просто sender в cron отрабатывал. А теперь переделал на этот вариант, реально работает, спасибо)
Добрый день в действиях на вкладке операции доступна только опция отправить сообщение
Все излазил не нашел «Удаленная команда»
Подскажите пожалуйста может ее теперь куда-то в другое место убрали?
zabbix 6.0
Этот функционал в версии 6 сильно изменился. Появился отдельный раздел для скриптов (Администрирование -> Скрипты). Надо туда добавить скрипт, а потом уже выбрать его через выпадающий список в действиях, в разделе «операция».
Добрый день!
Возможен ли мониторинг для windows систем. Т.е. чтобы видеть какое приложение сколько съело памяти, как грузило процессор и на сколько сильно грузило дисковую подсистему?
Zabbix такой мониторинг не поддерживает.
Удалось найти решение?
Добрый день, Владимир! Наткнулся на эту статью, с интересом ознакомился, большое спасибо.
Несколько замечаний. 1. Про использование опции «EnableRemoteCommands=1»:
а) я всегда вместе с ней включаю также и «LogRemoteCommands=1» (просто для перестраховки, чтобы при необходимости можно было видеть, что именно через таким образом запускалось);
б) я не считаю таким уж критичным использование локального фаервола (хотя это и не лишне) и шифрования, по крайней мере — в локальной сети. Обычно бывает достаточно того, что правильно выставлен параметр «Server=» — он эффективно ограничивает попытки соединения с «левых» адресов. Если между агентом и сервером трафик идёт в открытую через Интернет, то все эти навороты имеют смысл, а в пределах своей локальной сети — весьма спорно: например, шифрование явно усложняет настройки и слегка подгружает как агент, так и сервер;
в) для работы всей этой конструкции необходимо, чтобы агент поддерживал работу в пассивном режиме: для active-only режима она работать не будет. 2. Для вырезания только первых 10 строк лучше использовать не «awk ‘NR
Привет!
Не вкурсе как выполнение скрипта по срабатыванию триггера на 5.4 сделать? Actions все перерыл — там только отправка сообщений
Там немного поменялась логика. Сначала нужно добавить скрипт в раздел Администрирование -> Скрипты. А потом уже его использовать в Действиях.
Привет!
Вот только что разобрался ))) Я добавлял скрипт в раздел, только Scope не тот указал — надо Action operation, а я Manual host action выбрал.
Спасибо за помощь!
Владимир, а никак по другому не сделать? Может быть появился свой элемент или шаблон, чтобы не городить надстройку в виде забикс сендера и разрешения на выполнение команд?
Ничего готового на этот счет в Zabbix я не видел. Так что реализация остается за конечным пользователем системы мониторинга. Тут сделано просто и топорно, зато тратится минимум ресурсов и не хранится в базе ничего лишнего. Можно делать более грамотно через автообнаружение процессов на примере того, как это сделано в шаблоне windows со службами. Но это длинный путь.
Мне жаль было тратить время на реализацию.
Источник: serveradmin.ru
Автоматический мониторинг свежеустановленного софта в ZABBIX
В ZABBIX есть отличный механизм, который позволяет автоматически обнаруживать и ставить на мониторинг файловые системы, сетевые интерфейсы, CPU, ядера CPU и другие объекты. Но к сожалению тоже самое делать с софтом из коробки он не умеет.
С помощью всего пары скриптов, один из который необходимо положить на сервер, а второй раскидать по клиентам, можно сделать низкоуровневое авто-обнаружение nginx, mongod, rabbitmq, mysql, postgresql и любого другого сервиса.
Конечно мой вариант данной реализации не лишен недостатков и скорее всего гуру меня закидают помидорами! Буду крайне благодарен конструктивной критике и советам.
Ход действий, описание функционала и принцип работы
Навешиваем на хост шаблон авто/обнаружения «Template service auto discovery», в шаблоне или уже на хосте в макрос «» добавляем список сервисов (через пробел), которые необходимо обнаружить и поставить на мониторинг.
картинка со списком в макросе
Если необходимый сервис установлен и запущен, например «nginx», то на хосте появляется элемент данных «SERVICE_AUTO_DISCOVERY: detected_and_run_nginx»
и триггер SERVICE_AUTO_DISCOVERY: trigger_detected_and_run_nginx,
через 30секунд срабатывает триггер, а на сработанный триггер запускается действие,
картинка с описанием действия
действие выполняет скрипт «auto-discovery.py» (не забудьте в скрипте поменять логин «zabbixapi_API_user» и пароль «password» на свои)на сервере zabbix.
картинка с описанием операции при срабатывании действия
Скрипт в свою очередь через API-zabbix отключает соответствующий триггер и навешивает необходимы для этого сервиса шаблон.
Сработавшие триггеры
Можно было бы сразу с клиента обращаться напрямую к API, но тогда придется на клиенте держать этот скрипт. Это не очень безопасно т.к. пароль от API придется держать на хосте т.е. в скрипте. Кстати сервер zabbix у нас за NAT.
Было решено, что обнаруживать будем запущенный софт, ведь нет никакого смысла ставить на мониторинг то, что не работает(куча алертов, паника, звонки и т.д.).
Подытожим:
Можно использовать абсолютно любой шаблон для мониторинга любого сервиса. Для этого необходимо переименовать шаблон дав ему имя вида:
«Template_».
То есть для мониторинга БД «mongo» необходимо в макрос «» добавить «mongod», а шаблон для мониторинга монги переименовать в «Template_mongod».
Прошу обратить внимание на нижнее подчеркивание в имени шаблона, именно с помощью него, скрипт ищет подходящий шаблон. Имя шаблона и имя триггера должны быть «абсалютно» одинаковыми после «_» иначе либо не накинется шаблон, либо не сработает триггер.
Примеры шаблонов
Сами скрипты и шаблоны лежат на гитхабе в папке autodiscovery.
Расширенный функционал скрипта для хоста
Скрипт на хосте попутно был обучен обнаруживать севисы «systemctl» т.к. разработчики в нашей компании частенько пишут свои сервисы, которые необходимо мониторить выключен/выключен. Авто-обнаружение этих сервисов происходит если сервис «is-enabled».
Макрос называется , в именах сервисов можно опустить «.service», перечислять так-же через пробел.
Прошу обратить внимание, что никаких шаблонов тут не накидывается, а создаётся необходимый для мониторинга сервиса элемент данных и триггер.
Немного про дебаг:
Если сервис не обнаруживается, т.е. не создаются триггеры:
На хосте проверяем, как отрабатывает скрипт авто-обнаружения:
Тоесть если сервис не обнаружен, то скрипт вернет пустой JSON.
Если сервис обнаружился, но триггеры не отключаются:
Скорее всего скрипт не может подключиться к API zabbix. Проверяем что происходит:
Со стороны zabbix сервера запускаем скрипт и передаём ему два параметра? первый — имя хоста, а второй — имя триггера. Имя хоста как и имя триггера берем из «вэбморды» zabbixa, имя триггера берем из имени триггера в хосте.
/usr/bin/python3 /lib/zabbix/externalscripts/api/auto-discovery.py
Курица или яйцо?
Следующим этапом думаю допилить интеграцию с Ansible:
Но тут возникает вопрос: Что должно быть первым zabbix или ansible?
Если zabbix, то ошибочные действия в системе мониторинга приведут к ненужной установке лишнего софта.
Если первым будет ansible, то его интеграция с zabbix излишня, ведь zabbix итак всё обнаружит и замониторит, а необходимые для zabbix-agent скрипты и конфиги накидывать во время разворачивания плейбука.
Остаётся третий вариант, когда накидывая шаблон с авто-обнаружением(в котором в макросе перечислены стандартные сервисы) на хост, zabbiz попутно запустит плейбук для разворачивания скриптов и конфигов для zabbix-agent. Но опять-же если сервисы стандартные то и на хосте как минимум при разворачивании этих стандартных сервисов необходимо разворачивать роль для мониторинга.
- Системное администрирование
- Серверное администрирование
- Визуализация данных
Источник: habr.com
Мониторинг определенного процесса Windows машины в Zabbix
У блога появился хостинг, его любезно предоставила компания Облакотека. Облакотека — облачные сервисы для создания и управления виртуальной ИТ-инфраструктурой.
Если вам понравился мой блог и вы хотели бы видеть на нем еще больше полезных статей, большая просьба поддержать этот ресурс. Если вы размещаете материалы этого сайта в своем блоге, соц. сетях, и т.д., убедительная просьба публиковать обратную ссылку на оригинал
Источник: itdraft.ru