Как в zabbix мониторить службы windows

Обновлено: 06.07.2024

Будем использовать Zabbix для слежения за списком установленных служб/сервисов Windows.

Это важно по нескольким причинам:

  1. Вирусы часто устанавливают в системе новые службы, а это значит, что нужно следить за появлением новых служб.
  2. Бывает, что некоторые службы Windows , имеющие тип запуска auto или delayed-auto не работают, а это повод проверить их настройки.

Замечание 2.

1. Собираем данные по установленным программам при помощи скрипта.

Скрипт написан на Python 2.7, он собирает данные по установленным службам и формирует 3 файла:

Сам скрипт сохранён под именем C:\Zabbix\scripts\soft_list\serviceslist.py.

2. Устанавливаем скрипт в системе.

Запланировать выполнение скрипта можно при помощи планировщика Windows. Задание планировщика можно создать вручную, а можно и при помощи bat-файла.

3. Формируем шаблон в Zabbix.

В Zabbix при этом добавляем несложный шаблон.

Сначала приведу описание шаблона в картинках.









А вот и готовый для импорта заархивированный файл с описанным выше шаблоном: zbx_export_templates_serviceslist.xml

Описанные ранее скрипты можно найти в этом архиве: soft_list

4. Сбор данных.

Осталось назначить созданный шаблон соответствующему узлу сети и ждать начала поступления данных. 🙂

Аренда серверов.


Надёжные сервера с Pro-бегом
У ВАС В ОФИСЕ!


Безопасный доступ к своей 1С из офиса, командировки и т.п.!

IP-телефония в офис.


IP-телефония давно перестала быть роскошью в офисах.
Хотите себе в офис цифровую АТС - обращайтесь. !

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на . Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Введение

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

  • High CPU utilization
  • Load average is too high
  • Too many processes on hostname

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

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

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

  1. Добавляю в стандартный шаблон новый айтем типа Zabbix Trapper.
  2. Разрешаю на zabbix agent запуск внешних команд.
  3. Настраиваю на Zabbix Server действие при срабатывании одного из нужных мне триггеров. В действии указываю выполнение команды на целевом сервере, которая сформирует список процессов и отправит его на сервер мониторинга с помощью zabbix-sender.

Приступаем к реализации задуманного. Я буду настраивать описанную схему на Zabbix Server версии 5.2. Если у вас его нет, читайте мою статью по установке и настройке zabbix. В качестве подопытной системы будет выступать Centos. Так же предлагаю мои статьи по ее установке и предварительной настройке.

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

Подготовка сервера к мониторингу процессов

Первым делом идем на целевой сервер и изменяем конфигурацию zabbix-agent. Нам надо активировать следующую опцию:

Не забудьте после этого перезапустить агента.

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

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

Список самых ресурсоёмких процессов на linux сервере

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

Настройка мониторинга за процессами

На Zabbix сервере идем в стандартный шаблон Linux и добавляем туда 2 новых айтема:

  1. Process List - список процессов, ограниченный десятью с самой высокой нагрузкой на cpu. Сюда будем записывать информацию о процессах на сервере при срабатывании триггеров на повышенную нагрузку CPU.
  2. Full Process List - полный список всех процессов. Сюда запишем полный список всех процессов, когда сработает триггер на превышение максимально допустимого количества запущенных процессов на сервере.

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

Zabbix Item для процессов сервера

Теперь идем на сервер с агентом и пробуем отправку данных в данный айтем. Для этого нам нужен будет zabbix_sender. Если у вас его нет, то установите.

Отправку данных проверяем следующим образом:

Проверка мониторинга за процессами linux

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

Просмотр списка процессов

Ровно то, что нам было нужно. То же самое можно проверить с айтемом Full Process List, убрав в команде | awk 'NR<=10' в конце.

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

Настройка нового Действия в Zabbix

Сохраняйте действие и можно проверять.

Проверка отправки списка процессов

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

Они достаточно быстро нагрузили единственное ядро тестового сервера, так что оставалось только подождать активации триггера. Через 5 минут это случилось.

Проверка работы мониторинга процессов

Иду в раздел Последние данные и вижу там список процессов, которые нагрузили мой сервер.

Просмотр данных о процессах linux

Что мне в итоге и требовалось. Теперь нет нужды каким-то образом проверять, что конкретно нагружает сервер. В момент пиковой нагрузки я получу список запущенных процессов в отдельный айтем. Для полного списка процессов все делается по аналогии.

Заключение

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

Мониторинг активных процессов в NewRelic

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

И вам на почту придет список запущенных процессов после активации триггера.

На предыдущей работе я довольно напользовался тем, что в моей системе мониторинга Zabbix использовал разобранную возможность мониторить статусы установленных служб в системах. К примеру есть важный процесс и его нужно мониторить , как он только выключится, то нужно сразу же смотреть почему такое произошло, а не ждать когда тебе начнут звонить . Караул — почему сервисы не работают как и должны работать. А потому данная заметка будет своеобразной пошаговой напоминалкой самому себе, как в кратчайшие сроки поставить те или иные сервисы Windows на мониторинг в универсальный конструктор мониторинга Zabbix.

У меня Zabbix развернут на Ubuntu 12.04.5 Server amd64 версии 2.2.11

$ apt-cache show zabbix-server-mysql | grep Version

Задача: мониторить буду службу: FusionInventory-Agent

это агент GLPI посредством которого происходит инвентаризация рабочей станции: Какая ось, какой софт, какое железо, кто сейчас работает, IP-адрес станции и т. д.

Теперь создаю новый элемент данных в дефолтном шаблоне Template OS Windows:

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 принимает ответные значения:

Теперь создаю Trigger ( описание тревоги на этот элемент данных ), в этом же Template OS Windows — Triggers — Create Trigger

Name: Service State — GLPI Agent on

Severity: High

Enabled: Отмечаю галочкой

Сохраняю внесенные изменения: Save

Триггер среагировал на проблему хоста

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

Тип уведомление: Высокий

Время последнего изменения статуса

Продолжительность недоступности сервиса в связи с выключенным состояние службы FusionInventory-Agent

Служба FussionInventory-Agent выключена

вернув сервис в режим “Старт” , уведомление в Zabbix о сработанных триггерах вернулось в норму:

Запустив сервис на рабочей станции хост изменил поведение триггера

Если ведем какие-либо работы, то можно на сработанных триггер по этому хосту поставить комментарий (Acknowledge) или же когда сервис в строю:

Message: Работа сервиса восстановлена

После нажимаю: Acknowledge and return

По такому принципу можно настроить свой шаблон и свои элементы данных которые нужно отслеживать.

На этом собственно пока все, до новых встреч на моем блога, с уважением автор блога – ekzorchik.

Используйте прокси ((заблокировано роскомнадзором, используйте vpn или proxy)) при использовании Telegram клиента:

Поблагодари автора и новые статьи

будут появляться чаще :)

Карта МКБ: 4432-7300-2472-8059

Большое спасибо тем кто благодарит автора за практические заметки небольшими пожертвованиями. С уважением, Олло Александр aka ekzorchik.

Хотите узнать, как использовать Zabbix для мониторинга службы Windows? В этом уроке мы покажем вам, как настроить Zabbix для мониторинга службы, установленной на компьютере под управлением Windows.

• Версия Zabbix: 3.4.12
• Версия для Windows: 2012 R2

Список оборудования:

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

Все перечисленные выше аппаратные средства можно найти на веб-сайте Amazon.

Zabbix Playlist:

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

Не забудьте подписаться на наш канал YouTube, названный FKIT.

Учебное пособие Zabbix:

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

Учебное пособие - имя службы Windows

Во-первых, вам нужно установить агент Zabbix на компьютер под управлением Windows.

Затем откройте экран управления службами Windows и найдите службу, которую вы хотите контролировать.

Откройте свойства сервиса и обратите внимание на имя службы.

В нашем примере мы будем следить за статусом антивирусной службы Symantec.

Имя службы Symantec Antivirus - SepMasterService.

Zabbix Windows service

Обратите внимание на название службы.

Учебник - Zabbix Monitor Служба Windows

Теперь нам нужно получить доступ к панели мониторинга сервера Zabbix и добавить компьютер Windows в качестве хоста.

Откройте браузер и введите IP-адрес вашего веб-сервера plus / zabbix.

В нашем примере в браузере был введен следующий URL:

На экране входа в систему используйте имя пользователя по умолчанию и пароль по умолчанию.

• Имя пользователя по умолчанию: Admin
• Пароль по умолчанию: zabbix

zabbix login

После успешного входа в систему вы будете отправлены на панель инструментов Zabbix.

zabbix dashboard

На экране панели инструментов откройте меню «Конфигурация» и выберите параметр «Хост».

zabbix add host

В правом верхнем углу экрана нажмите кнопку «Создать хост».

Zabbix Create Host

На экране конфигурации хоста вам нужно будет ввести следующую информацию:

• Имя хоста - введите имя хоста для контроля.
• Видимое имя хоста - повторите имя хоста.
• Новая группа - введите имя для идентификации группы подобных устройств.
• Интерфейс агента - введите IP-адрес имени хоста.

Вот исходное изображение, перед нашей конфигурацией.

zabbix Cisco - Antes

Вот новое изображение с нашей конфигурацией.

Zabbix Windows host

На экране панели инструментов откройте меню «Конфигурация» и выберите параметр «Хост».

zabbix add host

Найдите и щелкните имя хоста, которое вы создали ранее.

В нашем примере мы выбрали имя хоста: WINDOWS-SERVER-01

На экране «Свойства хоста» перейдите на вкладку «Приложения».

Zabbix Windows Service Application menu

В верхней правой части экрана нажмите кнопку «Создать приложение».

Zabbix Windows Service Application

На экране «Хост-приложения» создайте новое приложение под названием «Служба Windows».

Закончив создание приложения, перейдите на вкладку «Элементы».

Zabbix Item Tab

В верхней правой части экрана нажмите кнопку «Создать элемент».

На экране создания элемента вам необходимо настроить следующие элементы:

• Имя: введите идентификатор в элемент службы Windows.
• Тип: Zabbix Agent
• Ключ: service.info [SepMasterService] • Тип информации: числовой (без знака)
• Интервал обновления: 60 секунд
• Показать значение: Состояние службы Windows
• Приложение: служба Windows

Zabbix Windows Service monitor

Подождите 5 минут.

Чтобы проверить свою конфигурацию, откройте меню «Мониторинг» и нажмите «Последний параметр данных».

Zabbix Latest data

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

В нашем примере мы выбрали имя хоста WINDOWS-SERVER-01

Zabbix Windows service Filter

Вы должны увидеть результаты мониторинга службы Windows с помощью Zabbix.

Zabbix Windows Service Status

Поздравляем! Вы настроили сервер Zabbix для контроля состояния службы Windows.

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

Первый способ — это при помощи SNMP-запросов, с отправкой которых Zabbix замечательно справляется. Так можно вытащить и загрузку сетевых интерфейсов, и загрузку процессора, памяти. Поверх этого, производители сервера могут выдать нам по SNMP еще много информации о состоянии железа.

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

image

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

Нам оставили несколько стандартных интерфейсов для того, чтобы расширить возможности Заббикса по мониторингу серверов настолько, насколько позволит нам наша фантазия и наличие свободного времени на написание скриптов. Интерфейсы эти UserParameter и zabbix_sender. О первом и пойдет речь, а в качестве примеров будет показано как можно собирать состояние S.M.A.R.T жестких дисков и контролировать, когда кто-то удаляет или устанавливает новые программы на своей Windows-машине.

Немного матчасти

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

  • Добавить в конце конфигурационного файла zabbix_agentd.conf строчку вида

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

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


Итак, ключ здесь system.test, а выполняем команду who | wc -l, которая возвращает нам количество открытых сессий в системе. Добавляем (или раскомментируем данную строчку если уже есть), идем дальше.

  • В Веб-консоли Zabbix создать новый элемент данных с ключом, который мы использовали, если брать пример выше, то это system.test.

и затем выставляем ключ такой же, как указали в конфиг-файле, а тип Zabbix агент:

image

Мониторинг SMART через UserParameter

Так что теперь рассмотрим пример, который уже больше будет походить на реалистичный.

Если нам интересно мониторить момент, когда пора планово менять жесткие диски, то есть два варианта:

  1. Если диски за аппаратным RAID-контроллером, то, как правило, сами диски операционная система «не видит». Поэтому ищем способы как вытащить информацию о состоянии жестких дисков через утилиты или SNMP-сабагента, которые нам любезно предоставил(или не предоставил) производитель RAID-контроллера. Для каждой отдельной серии контроллеров свой путь до этой информации.
  2. Если речь идет о просто рабочих станциях, серверах с софтовом RAID и т.д., то тогда к дискам есть доступ из операционной системы, и мы вольны использовать различные утилиты для чтения их статуса. В случае Zabbix нам подходит утилита smartctl, из пакета SMARTMONTOOLS.


и утилита готова к использованию.

Для каждого диска, который есть в системе сначала проверим, что SMART включен:


если вдруг SMART поддерживается диском, но выключен, то активируем его:


Теперь мы можем проверять статус SMART командой:


Именно эту команду мы и запишем в наш zabbix_agentd.conf:


где uHDD.health — ключ.

Мониторинг SMART через Flexible UserParameter

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


В веб-интерфейсе Zabbix в ключе мы будем подставлять параметры в квадратные скобки вместо *. Например, для одного элемента данных мы напишем sda, а для другого sdb. В команде этот параметр найдет отражение там, где стоит переменная $1.

image

Создадим для второго диска элемент данных:

image

И через некоторое время сможем наблюдать результат в последних данных:

image

Мониторинг SMART через Flexible UserParameter c Low-level Discovery

Все получилось. Но тут возникает резонный вопрос, как быть если дисков не два, а двадцать два. И тут нам пригодится замечательная возможность низкоуровнего обнаружения (LLD), про которую мы уже говорили.

Низкоуровневое обнаружение позволяет системе мониторинга обнаруживать какое количество однотипных элементов присутствует на узле сети и динамически по шаблону создавать необходимые элементы данных, триггеры и графики для этих элементов. «Из коробки» системе доступна возможность находить файловые системы, сетевые интерфейсы и SNMP OID'ы. Однако, и здесь разработчики оставили возможность дополнить стандартные возможности, нужно просто передать в систему информацию о том, какие элементы обнаружены в формате JSON. Этим и воспользуемся.

Создадим маленький скрипт на perl, smartctl-disks-discovery.pl. Он будет находить все диски в системе и выводить эту информацию в JSON, передавая также информацию, включен ли у диска SMART или нет, а также попытается сам включить SMART, если он выключен:

При запуске скрипт выдает:


Теперь, для того чтобы скрипт автоматически запускался Zabbix'ом, просто добавим еще один UserParameter в zabbix_agentd.conf:


Покончив с настройкой конфига, переходим в веб-интерфейс, где создаем новое правило обнаружения для smartctl:

image

Обратите внимание на ключ и на фильтр, (=1) благодаря последнему будут добавляться только те обнаруженные диски, которые поддерживают SMART. Теперь мы можем переписать два наших элемента данных для дисков sda и sdb в один прототип элементов данных, просто заменив имя диска на макрос :

image

Последнее, перед тем, как Zabbix сможет запускать команды, которые мы прописали в zabbix_agentd.conf из-под root и мониторить SMART, нужно добавить разрешения для его пользователя запускать эту команду без ввода пароля, для этого добавим в /etc/sudoers строчку:


Готовый шаблон для мониторинга SMART с остальными элементами данных, триггерами прикладываю, так же как и настроенный под него конфиг.

Контроль за установкой новых программ на Windows

Zabbix агент, установленный на Windows, точно также может быть расширен через UserParameter, только команды будут уже другие. Хотя, например, smartctl — кроссплатформенная утилита, и точно также можно ее использовать для контроля за жесткими дисками в Windows.

Кратко рассмотрим еще другой пример. Задача получать уведомление каждый раз, когда пользователь самостоятельно удаляет или устанавливает программы.
Для этого будем использовать наш vbs-скрипт:

Для его интеграции с Zabbix добавим UserParameter в конфиг-файл:


Добавим элемент данных в шаблон для Windows:

image

Добавим триггер:

image

и действие, которое будет отправлять e-mail уведомление:

image

Весь процесс мониторинга выглядит так: каждый час запускается скрипт Zabbix агентом, который сравнивает два списка программ: текущий и предыдущий. Затем скрипт выписывает все изменения в отдельный файл. Если же изменений нет, то в файл пишется 0x0

Содержимое файла уходит на Zabbix сервер, где поднимается триггер в случае, если значение элемента данных uDiffProgramms отлично от 0x0. Затем отдельное действие отправляет по почте уведомление со списком того, что было установлено или удалено на данном компьютере:


В итоге

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

Читайте также: