- Как мониторить работу службы через Zabbix
- ZABBIX — Настраиваем мониторинг служб
- ZABBIX — Настраиваем мониторинг служб.
- Создаём элемент данных.
- Zabbix Documentation 5.2
- Sidebar
- Table of Contents
- 8 Обнаружение служб Windows
- Overview
- Ключ элемента данных
- Поддерживаемые макросы
- Zabbix Documentation 3.2
- Sidebar
- Table of Contents
- Специфичные ключи элементов данных для Windows
- Ключи элементов данных
- Мониторинг служб Windows
- Обнаружение служб Windows
Как мониторить работу службы через Zabbix
На предыдущей работе я довольно напользовался тем, что в моей системе мониторинга Zabbix использовал разобранную возможность мониторить статусы установленных служб в системах. К примеру есть важный процесс и его нужно мониторить , как он только выключится, то нужно сразу же смотреть почему такое произошло, а не ждать когда тебе начнут звонить . Караул — почему сервисы не работают как и должны работать. А потому данная заметка будет своеобразной пошаговой напоминалкой самому себе, как в кратчайшие сроки поставить те или иные сервисы Windows на мониторинг в универсальный конструктор мониторинга Zabbix.
У меня Zabbix развернут на Ubuntu 12.04.5 Server amd64 версии 2.2.11
$ apt-cache show zabbix-server-mysql | grep Version
Первое условие на станции Windows которую нужно мониторить на предмет статуса запущенного сервиса должен стоят Zabbix—агент и заведен на Zabbix-сервер.
Задача: мониторить буду службу: FusionInventory-Agent
это агент GLPI посредством которого происходит инвентаризация рабочей станции: Какая ось, какой софт, какое железо, кто сейчас работает, IP-адрес станции и т. д.
Теперь создаю новый элемент данных в дефолтном шаблоне Template OS Windows:
http://IP&DNS — Configuration — Templates — Template OS Windows — Items — Create Item
Name: GLPI Agent
Type: Zabbix agent
Key: service_state[FusionInventory-Agent]
Update interval (in sec): 60
History storage period (in days): 7
Trend storage period (in days): 365
New Application: Services
Description: Мониторим статус работы службы установленного агента GLPI
Enabled: Отмечаю галочкой
Сохраняю внесенные изменения: Save
На заметку: ключ service_state принимает ответные значения:
State of service. 0 — running, 1 — paused, 2 — start pending, 3 — pause pending, 4 — continue pending, 5 — stop pending, 6 — stopped, 7 — unknown, 255 — no such service
Теперь создаю Trigger ( описание тревоги на этот элемент данных ), в этом же Template OS Windows — Triggers — Create Trigger
Name: Service State — GLPI Agent on
Expression: — Add находим нужно правило, в моем случаем правило следующее:
Severity: High
Enabled: Отмечаю галочкой
Сохраняю внесенные изменения: Save
Теперь проверяю, сейчас на хосте (W7X86) выключаю/останавливаю службу и в Zabbix’е – Monitoring у меня в где Windows Stations обозначена среагированная проблема:
Перехожу в группу и вижу на каких хоста сработало уведомление о неполадках:
Тип уведомление: Высокий
Время последнего изменения статуса
Продолжительность недоступности сервиса в связи с выключенным состояние службы FusionInventory-Agent
вернув сервис в режим “Старт” , уведомление в Zabbix о сработанных триггерах вернулось в норму:
Если ведем какие-либо работы, то можно на сработанных триггер по этому хосту поставить комментарий (Acknowledge) или же когда сервис в строю:
Message: Работа сервиса восстановлена
После нажимаю: Acknowledge and return
По такому принципу можно настроить свой шаблон и свои элементы данных которые нужно отслеживать.
На этом собственно пока все, до новых встреч на моем блога, с уважением автор блога – ekzorchik.
Используйте прокси ((заблокировано роскомнадзором, используйте vpn или proxy)) при использовании Telegram клиента:
Поблагодари автора и новые статьи
будут появляться чаще 🙂
Карта МКБ: 4432-7300-2472-8059
Yandex-деньги: 41001520055047
Большое спасибо тем кто благодарит автора за практические заметки небольшими пожертвованиями. С уважением, Олло Александр aka ekzorchik.
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 Documentation 5.2
Sidebar
Table of Contents
8 Обнаружение служб Windows
Overview
Аналогично обнаружению файловых систем, имеется возможность также обнаружения и служб Windows.
Ключ элемента данных
Ключом элемента данных, который используется в правиле обнаружения является
Этот ключ поддерживается начиная с Zabbix Windows агента 3.0.
Поддерживаемые макросы
Следующие макросы поддерживаются для использования в фильтре правила обнаружения и прототипах элементов данных, триггеров и графиков:
| Макрос | Описание |
|---|---|
| Имя службы. | |
| Отображаемое имя службы. | |
| Описание службы. | |
| Числовое значение состояния службы: 0 — Запущена 1 — Пауза 2 — Ожидание старта 3 — Ожидание паузы 4 — Ожидание продолжения 5 — Ожидание остановки 6 — Остановлена 7 — Неизвестно | |
| Имя состояния службы (Запущена, Пауза, Ожидание старта, Ожидание паузы, Ожидание продолжения, Ожидание остановки, Остановлена или Неизвестно). | |
| Путь к службе. | |
| Пользователь службы. | |
| Числовое значение типа запуска службы: 0 — Автоматически 1 — Автоматически (отложенный запуск) 2 — Вручную 3 — Отключена 4 — Неизвестно | |
| Имя типа запуска службы (Автоматически, Автоматически (отложенный запуск), Вручную, Отключена, Неизвестно). | |
| Числовое значение, указывающее, тип запуска службы: 0 — не запускается по триггерам 1 — запускается по триггерам Этот макрос поддерживается начиная с Zabbix 3.4.4. Он полезен для обнаружения таких типов запуска служб как Автоматический запуск (по триггеру), Автоматический отложенный запуск (по триггеру) и Ручной запуск (по триггеру). |
На основе обнаружения служб Windows вы можете создать прототип элементов данных, к примеру:
где парам принимает следующие значения: state, displayname, path, user, startup или description.
Zabbix Documentation 3.2
Sidebar
Table of Contents
Специфичные ключи элементов данных для Windows
Ключи элементов данных
В таблице приводится подробная информация о ключах элементов данных, которые вы можете использовать только с Zabbix Windows агентом.
| Ключ | ||||
|---|---|---|---|---|
| ▲ | Описание | Возвращаемое значение | Параметры | Комментарии |
| eventlog[имя, , , , , , ] | ||||
| Мониторинг журналов событий. | Журнал (лог) | имя — имя журнала событий регулярное выражение — регулярное выражение описывающее требуемый шаблон содержимого важность — регулярное выражение описывающее важность Параметр может принимать следующие значения: “Information”, “Warning”, “Error”, “Critical”, “Verbose” (начиная с Zabbix 2.2, работающих на Windows Vista или на более новых версиях) источник — регулярное выражение, описывающее идентификатор источника (регулярное выражение поддерживается начиная с версии Zabbix 2.2.0) eventid — регулярное выражение описывающее идентификатор(ы) событий макс. кол-во строк — максимальное количество новых строк в секунду, которое агент будет отправлять Zabbix серверу или прокси. Этот параметр заменяет значение ‘MaxLinesPerSecond’ в zabbix_agentd.win.conf режим — возможные значения: all (по умолчанию), skip — пропустить обработку старых данных (влияет только на недавно созданные элементы данных). | Элемент данных должен быть настроен активной проверкой. | |
Примеры:
⇒ eventlog[Application]
⇒ eventlog[Security,,»Failure Audit»,,529|680]
⇒ eventlog[System,,»Warning|Error»]
⇒ eventlog[System. ^1$]
⇒ eventlog[System. @TWOSHORT] — здесь используется ссылка на пользовательское регулярное выражение с именем TWOSHORT (заданное с типом Результат ИСТИНА, само выражение равно ^1$|^70$ ).
Обратите внимание, агент не может отправлять события из «Пересланные события» журнала.
Параметр режим поддерживается начиная с версии 2.0.0.
“Windows Eventing 6.0” поддерживается начиная с Zabbix 2.2.0.
Обратите внимание, что выбор не журнального типа информации для этого элемента данных приведет к потере локального штампа времени, а также важности журнала и информации о источнике.
Смотрите дополнительную информацию о мониторинге файлов журналов.
Обратите внимание, что включение/отключение некоторых компонентов Windows могут изменить порядок имён интерфейсов в Windows.
В некоторых версиях Windows (к примеру, Server 2008) может потребоваться установка последних обновления для поддержки не-ASCII символов в именах интерфейсов.
период — последние N секунд для сохранения усредненного значения.
Значение период должно быть равно значению с 1 до 900 секунд (включительно), значение по умолчанию 1.
Смотрите также: Счетчики производительности в Windows.
— запрашиваемый атрибут процесса.
— тип представления (имеет смысл, когда есть более одного процесса с одним именем)
vmsize — размер виртуальной памяти процесса в Кбайтах
wkset — размер working set процесса (количество физической памяти используемой процессом) в Кбайтах
pf — Количество ошибок на страницах
ktime — время ядра процесса в миллисекундах
utime — пользовательское время процесса в миллисекундах
io_read_b — количество байт чтения процессом в процессе I/O операций
io_read_op — количество операций чтения выполненных процессом
io_write_b — количество байт записи процессом в процессе I/O операций
io_write_op — количество операций записи выполненных процессом
io_other_b — количество байт переданных процессу в течении операций отличных от чтения и записи
io_other_op — количество I/O операций выполненных процессов, отличных от операций чтения и записи
gdiobj — количество объектов GDI используемых процессом
userobj — количество объектов USER используемых процессом
Допустимые типы :
min — минимальное значение среди всех процессов с именем
max — максимальное значение среди всех процессов с именем
avg — среднее значение среди всех процессов с именем
sum — сумма значений для всех процессов с именем
Примеры:
⇒ proc_info[iexplore.exe,wkset,sum] — для получения общего количество физической памяти выделенной под все процессы Internet Explorer
⇒ proc_info[iexplore.exe,pf,avg] — для получения среднего количества ошибок на страницах для процессов Internet Explorer
Обратите внимание, что для корректной работы этого элемента данных на 64-битной системе потребуется 64-битный Zabbix агент.
Обратите внимание: Все атрибуты io_*, gdiobj и userobj доступны только в Windows 2000 и более поздних версиях Windows, не в Windows NT 4.0.
Строка — с парам равным displayname, path, user
Текст — с парам равным description
В частности при state:
0 — запущена,
1 — пауза,
2 — ожидание старта,
3 — ожидание паузы,
4 — ожидание продолжения,
5 — ожидание остановки,
6 — остановлена,
7 — неизвестно,
255 — такой службы не существует
В частности при startup:
0 — автоматически,
1 — автоматически (отложенный запуск),
2 — вручную,
3 — отключена,
4 — неизвестно
парам — state (по умолчанию), displayname, path, user, startup или description
⇒ service.info[SNMPTRAP] — состояние службы SNMPTRAP
⇒ service.info[SNMP Trap] — состояние этой же службы, но указано отображаемое имя
⇒ service.info[EventLog,startup] — состояние запуска при загрузке службы Журнала событий
Элементы данных service.info[служба,state] and service.info[служба] вернут одинаковую информацию.
Обратите внимание, что только парам равный state у этого элемента данных возвращает значение по несуществующим службам (255).
Этот элемент данных поддерживается начиная с Zabbix 3.0.0. Его необходимо использовать вместо устаревшего элемента данных service_state[служба].
Текст — список служб, разделенных новой строкой.
состояние — all (по умолчанию), stopped, started, start_pending, stop_pending, running, continue_pending, pause_pending, paused
исключение — список служб исключенных из результата.
Исключенные службы должны быть указаны в двойных кавычках, разделенные запятой, без пробелов.
⇒ services[,started] — список запущенных служб
⇒ services[automatic, stopped] — список остановленных служб, которые должны быть запущены
⇒ services[automatic, stopped, «service1,service2,service3»] — список остановленных служб, которые должны быть запущены, исключая службы с именами service1,service2 и service3
Параметр исключения поддерживается начиная с версии 1.8.1.
запрос — WMI запрос, возвращающий один объект
⇒ wmi.get[root\cimv2,select status from Win32_DiskDrive where Name like ‘%PHYSICALDRIVE0%’] — возвращает состояние первого физического диска
Этот ключ поддерживается начиная с Zabbix 2.2.0.
Число с плвающей точкой — для процентов
available (доступно виртуальной памяти), pavailable (доступно виртуальной памяти, в процентах), pused (использовано виртуальной памяти, в процентах), total (всего виртуальной памяти, по умолчанию), used (использовано виртуальной памяти)
⇒ vm.vmemory.size[pavailable] → доступно виртуальной памяти, в процентах
Мониторинг статистики виртуальной памяти основывается на:
* Общего количества виртуальной памяти на Windows (сумма физической памяти + размера файла подкачки);
* Максимального количества памяти, которое может занять Zabbix агент;
* Текущего предела выделенной памяти в системе или Zabbix агенте, смотря что меньше.
Этот ключ поддерживается начиная с Zabbix 3.2.3.
Мониторинг служб Windows
Это руководство содержит пошаговые инструкции по настройке мониторинга служб Windows. Предполагается, что Zabbix сервер и агент уже настроены и работают.
Шаг 1
Узнайте имя службы.
Вы можете получить имя, перейдя в оснастку MMC Службы и открыв свойства службы. На вкладке Общие вы должны увидеть поле называемое ‘Имя службы’. Значение которого и будет именем желаемой службы, которое вы будете использовать при настройке элемента данных для наблюдения.
Например, если вы хотите наблюдать службу “workstation”, то ваша служба скорее всего будет: lanmanworkstation.
Шаг 2
Элемент данных service.info[служба, ] возвращает информацию о указанной службе. В зависимости от требемой вам информации, укажите опцию парам, которая принимает следующие значения: displayname, state, path, user, startup или description. Значением по умолчанию является state, если парам не указан (service.info[служба]).
Тип возвращаемого значения зависит от выбранного парам: целое число при state и startup; строка символов при displayname, path и user; текст при description.
Имеется два преобразования значений Windows service state и Windows service startup type, которые сопоставляют числовое значение в веб-интерфейсе его текстовому представлению.
Обнаружение служб Windows
Низкоуровневое обнаружение дает возможность автоматического создания элементов данных, триггеров и графиков по различных объектам на компьютере. Zabbix может автоматически начать наблюдение за службами Windows на вашей машине, без необходимости знания точного имени службы или создания элементов данных по каждой службе вручную. Можно использовать фильтр для генерирования реальных элементов данных, триггеров и графиков только по интересующим службам.
