- ZABBIX — Настраиваем мониторинг служб
- ZABBIX — Настраиваем мониторинг служб.
- Создаём элемент данных.
- Мониторинг списка запущенных процессов в Zabbix
- Введение
- Подготовка сервера к мониторингу процессов
- Настройка мониторинга за процессами
- Проверка отправки списка процессов
- Заключение
- ZABBIX — Настраиваем мониторинг демонов Systemd
- ZABBIX — Настраиваем мониторинг демонов запущенных через Systemd.
- Zabbix: LLD-мониторинг служб FlexLM (ОБНОВЛЕНО)
- Шаблон
- Скрипт для Windows
- Скрипт для Linux
- Конфигурация Zabbix-агента
ZABBIX — Настраиваем мониторинг служб
Всем привет, часто возникает необходимость настроить мониторинг различные службы и всегда знать если что-то упало. В данной статье расскажу о том как настроить мониторинг служб по средствам Zabbix.
ZABBIX — Настраиваем мониторинг служб.
Создаём элемент данных.
Для начала необходимо выбрать наш шаблон, к которому привязан интересующий нас узел сети, если его нет создаём, о том как создать шаблон можете прочитать тут: ZABBIX — Новый шаблон. В нашем случае шаблон у нас уже есть с привязанным к нему узлом сети. Переходим в “Настройка” -> “Шаблоны” -> Выбираем наш шаблон ->Выбираем “Элементы данных” и нажимаем кнопку “Создать элемент данных”
Zabbix-создаём элементы данных
Дальше необходимо вписать наши условия, оставляем все пункты по умолчанию, кроме “Имя” и “Ключ”. Вписываем любое угодное нам имя и в поле ключ нажимаем “Выбрать”
Ищем в списке ключ “proc.num[ , , , ]”, выбираем его.
Вот что про данный ключ пишут в документации Zabbix-а:
| proc.num[ , , , ] | ||||
|---|---|---|---|---|
| Количество процессов. | Целое число | имя – имя процесса (по умолчанию “все процессы”) пользователь – имя пользователя (по умолчанию “все пользователи”) состояние – возможные значения: all (по умолчанию), run, sleep, zomb cmdline – фильтр по командной строке (является регулярным выражением) | Примеры ключей: ⇒ proc.num[,mysql] – количество процессов выполняемых под пользователем mysql ⇒ proc.num[apache2,www-data] – количество процессов apache2 выполняемых под пользователем www-data ⇒ proc.num[,oracle,sleep,oracleZABBIX] – количество процессов в спящем состоянии выполняемых под oracle и имеющих oracleZABBIX в содержимом командной строкиСмотрите заметки по выбору процессов с параметрами имя и cmdline (специфика для Linux).В Windows, поддерживаются только параметры имя и пользователь. | |
Затем нам необходимо указать необходимые параметры для ключа. К примеру мы хотим настроить мониторинг демона под названием “sendsms”, тогда ключ у нас будет таким:
Источник
Мониторинг списка запущенных процессов в Zabbix
В стандартных шаблонах Zabbix есть триггеры на загрузку процессора, а так же на превышение максимально допустимого числа процессов. Триггеры эти практически бесполезны, если у вас плавающая нагрузка. Допустим, вы получаете уведомление о том, что у вас сильно нагружен процессор. Через 10 минут нагрузка прошла, а вы не успели зайти на сервер и посмотреть, чем он был нагружен в это время. Вот эту проблему я и решаю своим велосипедом, которым делюсь в статье.
Введение
Рассказываю подробно, что я хочу получить в конце статьи. В стандартном шаблоне 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. Нам надо активировать следующую опцию:
Не забудьте после этого перезапустить агента.
Предупреждаю, что подобная настройка — огромная дыра в безопасности сервера. Используйте на свой страх и риск. Чтобы у вас не было проблем с этим, настоятельно рекомендую ограничивать доступ к порту агента на сервере на уровне firewall только с сервера мониторинга. Так же в обязательном порядке использовать шифрованное соединение между сервером и агентом. Вообще, это универсальное правило при настройке мониторинга. В идеале, так надо делать всегда. Я стараюсь все это настраивать при работе мониторинга через интернет. Если проигнорировать данное предупреждение и оставить все в открытом доступе, то через разрешенные удаленные команды вам могут залить на сервер зловред.
Далее проверим команду, которая будет формировать список процессов для отправки на сервер мониторинга. Я предлагаю использовать вот такую конструкцию, но вы можете придумать что-то свое.
Получаем список запущенных процессов, отсортированный по потреблению cpu и ограниченный первыми десятью строками. В данный момент на сервере с агентом нам делать нечего. Перемещаемся в web интерфейс Zabbix Server.
Настройка мониторинга за процессами
На Zabbix сервере идем в стандартный шаблон Linux и добавляем туда 2 новых айтема:
- Process List — список процессов, ограниченный десятью с самой высокой нагрузкой на cpu. Сюда будем записывать информацию о процессах на сервере при срабатывании триггеров на повышенную нагрузку CPU.
- Full Process List — полный список всех процессов. Сюда запишем полный список всех процессов, когда сработает триггер на превышение максимально допустимого количества запущенных процессов на сервере.
Так выглядит первый айтем. Второй сделайте по аналогии.
Теперь идем на сервер с агентом и пробуем отправку данных в данный айтем. Для этого нам нужен будет zabbix_sender. Если у вас его нет, то установите.
Отправку данных проверяем следующим образом:
Я не буду подробно останавливаться на формате запросов с помощью zabbix_sender. Все это хорошо описано в документации. Теперь идем в веб интерфейс сервера и в разделе Последние данные смотрим на список процессов, который нам пришел с целевого сервера.
Ровно то, что нам было нужно. То же самое можно проверить с айтемом Full Process List, убрав в команде | awk ‘NR Настройка -> Действия и добавляем новое.
Сохраняйте действие и можно проверять.
Проверка отправки списка процессов
Теперь проверим, как все это будет работать. Для этого идем на целевой сервер и нагружаем его чем-нибудь. Я для примера запустил в двух разных консолях по команде:
Они достаточно быстро нагрузили единственное ядро тестового сервера, так что оставалось только подождать активации триггера. Через 5 минут это случилось.
Иду в раздел Последние данные и вижу там список процессов, которые нагрузили мой сервер.
Что мне в итоге и требовалось. Теперь нет нужды каким-то образом проверять, что конкретно нагружает сервер. В момент пиковой нагрузки я получу список запущенных процессов в отдельный айтем. Для полного списка процессов все делается по аналогии.
Заключение
Вот такую реализацию я придумал, когда потребовалось решить задачу. Один сервер постоянно донимал оповещениями по ночам. Нужно было понять, что его дергает в это время. Жаль, что у Zabbix из коробки нет реализации подобного информирования. Помню лет 5 назад был бесплатный тариф у мониторинга NewRelic. Можно было поставить агент мониторинга на сервер и потом смотреть очень удобные отчеты в веб интерфейсе. Никаких настроек не нужно было, все работало из коробки. Там были отражены все запущенные процессы на сервере на временном ряду со всеми остальными метриками. Это было очень удобно. Я нигде в бесплатном софте не видел такой реализации. Это примерно вот так выглядело.
Кстати, в первоначальной версии действия я просто отправлял список процессов на почту. Мне показалось это удобным. Можно было сразу же в почте, в соседнем письме с триггером, посмотреть список процессов. Но потом решил, что удобнее все же хранить историю в одном месте на сервере и настроил сбор данных туда. Хотя можно делать и то, и другое. Например, в действии можно указать другую команду к исполнению:
И вам на почту придет список запущенных процессов после активации триггера.
Источник
ZABBIX — Настраиваем мониторинг демонов Systemd
Недавно появилась необходимость настроить мониторинг служб запущенных по средствам Systemd. В данной статье расскажу о том как я настроил мониторинг таких демонов по средствам Zabbix-а.
ZABBIX — Настраиваем мониторинг демонов запущенных через Systemd.
Немного теории. Systemd – менеджер системы и сервисов(демонов) в операционной системе Linux. При помощи данного менеджера можно отслеживать состояния демонов, перезапустить их, просматривать всю интересующую информацию по ним. В общем может многое, глубоко вдаваться не буду. Представим, что у нас есть уже работающая служба, через systemctl, с названием “kktstoredecrypted” и нам необходимо настроить для неё мониторинг.
Так вот, возникла необходимость настроить мониторинг таких демонов по средствам Zabbix-а. Для настройки мониторинга у нас есть множество вариантов, я выделил два:
- Воспользоваться стандартным ключём “proc.num[]”
- И создать отдельный параметр для zabbix, в котором будем выполнять определённую команду.
Первый вариант меня немного не устраивал, так он будет определять только, что сам демон запущен, но не даст данных о том, что он активен в среде systemd. Но кому интересно первый способ описан тут: ZABBIX — Настраиваем мониторинг служб.
Источник
Zabbix: LLD-мониторинг служб FlexLM (ОБНОВЛЕНО)
Эта статья — более детальная проработка предыдущей. Теперь шаблон унифицирован для использования как в Windows (PowerShell), так и в Linux (Bash). Если вы использовали предыдущий шаблон, то все должно встать болт-он.
Что умеет: находить серверы/лицензии, считывать состояния серверов, считывать суммарное и использованное количество лицензий, в случае ошибок передает коды состояний (строку с описанием) и рапортует о них.
Схема все та же:
- Шаблон
- Скрипты (PowerShell/Bash)
- Правильная настройка агента
Шаблон
Здесь все просто: импортировал и забыл. Шаблон был сконструирован в Zabbix версии 3.2, имейте это ввиду.
Как и в прошлый раз, для читаемости используются макросы конструкции <$<#ID>> в именах элементов и триггеров. Шаблон уже содержит некоторое количество макросов, вы просто добавляете свои преобразования, исходя из найденных элементов.
Также внутри уже есть несколько базовых триггеров для отслеживания состояния серверов и отдельных лицензий.
Скрипт для Windows
Скрипт для Windows писался под Windows 7 SP1 на PSv4, на XP он не работает. Само собой, на сервере должен быть разрешен запуск PowerShell-скприптов (Set-ExecutionPolicy Unrestricted).
Показатели сервера лицензирования берутся из утилиты lmutil.exe, которая входит в дистрибутивы разных вендоров. Для нормальной работы скрипта необходимо прописать путь к ней в системные переменные среды в переменную Path без кавычек. К примеру, по умолчанию для CSoft v11.5 это папка «C:\Program Files (x86)\CSoft\CS License Server», а для Autodesk v11.13.1 — «C:\Autodesk\Network License Manager». В качестве разделителя используйте используется знак «;».
Если вы используете сервер лицензий Autodesk, то посмотрите особенность под спойлером.
С этим разработчиком оказалось не все так просто. «Из коробки» lmutil отдает ошибку -1,359. Хотя если указать порт@хост, то все нормально.
Связано такое поведение скорее всего с тем, что в старших версиях FLEXlm lmutil сопоставляет пути переменных LM_LICENSE_FILE и VENDOR_LICENSE_FILE. Пути эти стандартные и по умолчанию не существуют.
Для решения достаточно взять lmutil.exe версии 11.5 из произвольного пакета (CSoft/Nanosoft). Или выполнить на хосте команду вида
lmutil lmpath -override all «путь_к_файлу_вашей_лицензии»
Аналогичным образом можно использовать команду
lmutil lmpath -add «произвольное_имя_вендора» «путь_к_файлу_вашей_лицензии»
Команды эти нужно выполнить от имени системной учетной записи, иначе Zabbix-агент так и не сможет работать с утилитой. Сделать это можно с помощью утилиты PsExec с ключом -s: psexec -s cmd и в открывшее окно командной строки внести нужные команды.
Подробнее об этих и других командах вы можете узнать из инструкции по лицензированию, рекомендую к прочтению при дебаге.
Скрипт для Linux
А этот скрипт писался под Ubuntu. О том, как пошагово установить сервер лицензирования Autodesk на Ubuntu читай ниже (Ubuntu официально не поддерживается).
Скрипт копируете в произвольную папку на сервере (путь ее указываете в конфиге агента, об этом ниже), не забывайте дать соответствующие права на его исполнение.
Также необходимо указать в скрипте каталог утилиты lmutil в разделе «Пользовательские переменные».
Конфигурация Zabbix-агента
Добиться одновременной работы разных систем от одного шаблона позволяет правильная настройка агента, а точнее его части UserParameter. Еще этот метод позволяется раз и навсегда забыть про перезапуск агента в случае добавления нового функционала в виде скриптов. Это важно для высоконагруженных серверов, где при перезапуске агента можно потерять часть метрик.
Итак, в данном случае используется строка:
для Windows — UserParameter=ZScript[*],powershell C:\Zabbix\Scripts\ $1.ps1 $2 $3 $4
для Linux — UserParameter=ZScript[*],bash /etc/zabbix/scripts/$1.sh $2 $3 $4
Пути и количество переменных указываете свои. Переменных можно указать с запасом, лишним не будет.А к необходимым скриптам можно будет обратиться, используя ключ ZScript[$1,$2,$3,$4].
Источник
