Критический SQL-сервис или банальный диспетчер печати «упали» в три часа ночи, а вы узнали об этом только утром от разгневанных пользователей? Знакомая ситуация.
Наблюдение за состоянием фоновых процессов (служб) — это фундамент любой ИТ-инфраструктуры, стоящий в одном ряду с проверкой пинга и отслеживанием свободного места на дисках. Но просто получать алерты о том, что служба остановлена (Status: Stopped) — недостаточно. Грамотный системный администратор настраивает систему мониторинга предприятия, например System Center Operations Manager (SCOM) так, чтобы она не только замечала сбои, но и самостоятельно их лечила без участия человека.
В этом подробном гайде мы разберем, как настроить мониторинг служб Windows «из коробки», используя встроенные Management Pack Templates. Вам не придется писать сложные скрипты — весь функционал уже заложен в Operations Manager. Подробнее об этом шаблоне вы может узнать в официальной документации Microsoft.
Что мы сделаем в этой инструкции:
- За 5 минут настроим шаблон наблюдения за службой (на примере Print Spooler).
- Добавим контроль потребления ресурсов (CPU и RAM) конкретным сервисом.
- Настроим Recovery Tasks: научим SCOM автоматически перезапускать упавшую службу командой
net start. - Проведем боевое тестирование и убедимся, что система реально «лечит» инфраструктуру.
Инструкция актуальна для SCOM 2016 / 2019 / 2022 / 2025 и серверов Windows Server 2016 / 2019 / 2022 /2025
- Настройка мониторинга служб в SCOM с помощью Windows Service Template
- Настройка задач диагностики и восстановления для служб
- Тестирование мониторинга
- Итоги: от пассивного наблюдения к активной автоматизации
- Часто задаваемые вопросы (FAQ)
- Как мониторить службу, если её тип запуска стоит «Вручную» (Manual)?
- Что делать, если служба постоянно падает, и авто-перезапуск (Recovery Task) создает бесконечный цикл?
- Можно ли с помощью этого шаблона узнать, что служба «зависла», а не остановилась?
- Как применить этот мониторинг сразу ко всем серверам в домене, не добавляя их по одному?
Настройка мониторинга служб в SCOM с помощью Windows Service Template
Для того, чтобы контролировать службы, на серверы должен быть установлен агент SCOM. Допустим, что у нас это уже сделано — агент установлен и подключен к управляющему серверу.
Нужно запустить консоль Operations Manager, перейти в раздел «Authoring», далее «Management Pack Templates» и «Windows Service».
Из панели задач справа или из контекстного меню запустите мастер настройки — «Add Monitoring Wizard». Далее выберите тип «Windows Service».
Укажите название, описание и выберите пакет управления для сохранения ваших настроек. Если пакет еще не создан, то нажмите кнопку «New» и создайте его. Подробнее процесс создания пакета управления в консоли SCOM рассматривался ранее.
В следующем важном окне нужно задать имя службы. Если вы не знаете ее точное название, то можно, нажав маленькую кнопку справа и введя имя конкретного сервера, выбрать службу из списка.
Для примера будем настраивать контроль службы Spooler (Диспетчер печати).
Также обязательно нужно выбрать группу, для которой будет действовать этот шаблон. Вы можете выбрать из существующих групп, как например в примере «Windows Server Computer Group», или создать свою заранее, наполнив ее серверами, на которых нужно контролировать данный сервис.
Примечание. Обратите внимание на чекбокс «Monitor only automatic service». По умолчанию он включен и означает, что будут наблюдаться только службы, у которых настроен автоматический тип запуска, все остальные будут игнорироваться.
Нажмите «Next».
Следующий блок настроек опционален, по умолчанию в нем все выключено. Здесь настраиваются параметры сбора счетчиков производительности и пороги оповещений.
Для служб можно задать пороговые значения для использования процессора (в %) и памяти (в Mb).
В нижнем блоке настроек задается интервал сбора метрик производительности (5 минут по умолчанию) и количество превышений порога прежде, чем сработает монитор и сгенерируется оповещение.
Совет. Хотя по умолчанию все эти настройки отключены, советуем помнить о них или сразу настраивать адекватные вашей специфике настройки, чтобы избежать ложных срабатываний при кратковременных пиках, тем самым снизится «шум» в оповещениях.
Примечание. Если не указать пороговые значение, то никаких счетчиков производительности по этой службе собираться не будет. Но всегда можно вернуться в свойства шаблона позже, и включить настройки.
Нажмите далее и в следующем окне проверьте все ваши настройки, и нажмите «Create».
Ваш объект создан.
В течение нескольких минут автоматически создадутся необходимые мониторы и правила для него. Ваш пакет управления будет тиражирован на все агенты SCOM Windows, подключенные к группе управления. На тех агентах, которые входят в группу, указанную при создании, запустится скрипт обнаружения для поиска контролируемой службы, и в результате в консоли Operations Manager начнут появляться объекты. Сначала с пустым статусом. Но через несколько минут начнут работать мониторы и статусы будут отображать реальное состояние служб.
Настройка завершена.
Можно зайти в свойства автоматически созданных мониторов в Health Explorer и напрямую отредактировать доступные свойства, например, описание или текст оповещения.
Свойства монитора Service Running State.
Свойства монитора Windows Service CPU Usage.
Примечание. Необходимо помнить, что все атрибуты отредактированные напрямую, могут сброситься после того, как вы снова зайдете в шаблон, внесете какие-то изменения и сохраните настройки.
Настройка задач диагностики и восстановления для служб
Для всех мониторов в Operations Manager на вкладке «Diagnostic and Recovery» можно настроить автоматический и ручной запуск диагностических и восстанавливающих задач (команд или скриптов) в зависимости от состояния мониторов.
Для настройки наблюдения за службами Windows соответственно можно, например, сделать задачу по автоматическому запуску службы, если обнаружится, что она остановилась, то есть при статусе монитора «Critical». Сделаем это с помощью команды net start.
Нажмите «Add» в блоке «Configure recovery tasks».
Задайте базовые параметры — имя и описание задачи, тип health state для запуска. И обязательно включите опцию «Run recovery automatically» для автоматического запуска задачи.
Выберите тип задачи «Run Command».
Recovery task сохраняется в том же пакете управления, что и монитор.
Настройте путь, параметры запуска, рабочий каталог и таймаут для запуска команды. И нажмите «Create».
Задача создана, можно переходить к тестированию.
Совет. В производственной среде обязательно тестируйте сначала все команды и скрипты для recovery task на тестовой группе серверов! Выборочно включить recovery task можно через механизм «Override» в SCOM.
Тестирование мониторинга
Для тестирования настроенного мониторинга достаточно будет остановить службу руками на каком-либо сервере из тестовой группы.
В нашем примере это можно сделать так: net stop spooler
В консоли SCOM в окне Windows Service State статус службы Print Spooler для выбранного сервера должен стать красным.
Но через несколько секунд он изменится на зеленый. Возможно понадобится обновить консоль с помощью кнопки «F5».
Зайдем в Health Explorer для выбранного экземпляра и увидим следующую картину.
Мы видим, что при переходе состояния монитора в «Critical», запустилась и успешно отработала наша задача восстановления по запуску службы. После чего монитор перешел в состояние «Healthy». То есть все отработало как надо.
В окне алертов также было соответствующее событие.
Итоги: от пассивного наблюдения к активной автоматизации
Настройка мониторинга служб через встроенные Management Pack Templates — это самый быстрый и надежный способ взять под контроль фоновые процессы Windows. Но главная ценность SCOM раскрывается не в самих алертах, а в Recovery Tasks. Настроив автоматический перезапуск «упавших» сервисов командой net start, вы превращаете систему мониторинга из простого «сторожа» в полноценного ИТ-помощника, который устраняет типовые инциденты (например, внезапную остановку SQL Server или IIS) еще до того, как вы успеете открыть тикет.
Совет от автора: Не останавливайтесь на мониторинге отдельных служб. Объединяйте связанные сервисы (например, связку SQL Server + IIS + ваша бизнес-служба) в Distributed Applications (Распределенные приложения). Это позволит вам видеть здоровье всего бизнес-сервиса целиком на одном дашборде, а не искать иголку в стоге сена среди сотен разрозненных серверов.
Что дальше? В этой статье мы разобрали нативные инструменты Microsoft. Но если в вашей компании используется кроссплатформенный мониторинг или OpenSource-решения, обязательно читайте наш следующий гайд: Настройка мониторинга служб и процессов в Zabbix.
Остались вопросы?
А какие службы вы мониторите в первую очередь на новых серверах? Используете ли вы Recovery Tasks для авто-лечения или предпочитаете реагировать на алерты вручную, чтобы избежать зацикливания? Делитесь опытом и задавайте вопросы в комментариях ниже, мы всегда помогаем с настройкой!
Часто задаваемые вопросы (FAQ)
Как мониторить службу, если её тип запуска стоит «Вручную» (Manual)?
По умолчанию в мастере Add Monitoring Wizard включена опция «Monitor only automatic service». Из-за неё SCOM игнорирует службы с ручным запуском, считая, что они не должны работать постоянно. Чтобы это исправить, зайдите в свойства созданного шаблона (или самого монитора в Health Explorer) и снимите эту галочку. После этого SCOM будет генерировать алерт, если такая служба остановится в процессе работы.
Что делать, если служба постоянно падает, и авто-перезапуск (Recovery Task) создает бесконечный цикл?
Это классическая проблема «boot-loop». Если служба падает из-за критической ошибки (например, не хватает памяти, занят порт или поврежден конфиг), net start будет запускать её, а она тут же будет падать, спамя алертами и нагружая систему. Решение: В настройках Recovery Task можно задать лимит срабатываний. Но лучший подход — настроить параллельно Diagnostic Task, которая при падении службы будет автоматически выгружать последние 50 строк из Event Log (журнала событий Windows) и прикреплять их к тексту алерта в SCOM. Так вы (или дежурный админ) сразу увидите первопричину сбоя, не заходя на сервер по RDP.
Можно ли с помощью этого шаблона узнать, что служба «зависла», а не остановилась?
Стандартный шаблон Windows Service Template опрашивает SCM (Service Control Manager) и отслеживает только бинарный статус сервиса в ОС (Running / Stopped). Если процесс завис и не отвечает на запросы пользователей, для Windows он всё еще считается «работающим» (Status: Running). Чтобы мониторить зависания, нужно использовать другие подходы: например, настроить TCP Port Monitor (если служба слушает определенный порт) или написать кастомный PowerShell-скрипт, проверяющий время отклика (Time-to-Respond) сервиса или наличие конкретных Event ID в логах.
Как применить этот мониторинг сразу ко всем серверам в домене, не добавляя их по одному?
При создании шаблона на этапе выбора группы (Group) не выбирайте конкретные сервера. Вместо этого создайте в консоли SCOM Динамическую группу (Dynamic Group) на основе класса Windows Computer. Задайте правило, например: «Имя компьютера содержит ‘SRV’» или «Операционная система = Windows Server 2019/2022». Применяйте шаблон к этой группе. Все новые сервера, введенные в домен и подходящие под критерии, будут автоматически браться под мониторинг без вашего участия.
