Введение
Настройки мониторинга Windows Server часто развиваются от встроенных инструментов, скриптов и стороннего программного обеспечения до систем, которые становятся фрагментированными, дорогостоящими или трудными в управлении. Эффективная замена требует больше, чем просто сравнение функций продуктов. Эта статья объясняет, когда замена имеет смысл, что должно охватывать мониторинг Windows Server, какие возможности следует приоритизировать, как определить соответствующий объем мониторинга и как мигрировать, не теряя критической видимости инфраструктуры.
В каком случае ИТ-команда будет искать замену для мониторинга Windows Server?
Нет одного продукта под названием "Мониторинг Windows Server", который все хотят заменить. То, что у них есть сейчас, может быть комбинацией встроенных инструментов Windows, комплексного решения от третьих сторон, самописных скриптов или более целостного стека наблюдаемости для предприятий.
Причина, по которой они хотят что-то другое, может быть так же вероятно связана с растущими затратами на лицензии, как и с необходимостью получения более полезной информации, предоставляемой правильным людям в ИТ-организации.
В других случаях это просто вопрос масштаба - растущая инфраструктура теперь требует больше, чем может предоставить любительская самодельная система, или инструменты, доступные системному администратору, просто не предоставляют типы информации, необходимые для обнаружения и решения проблем до того, как они повлияют на бизнес-операции.
Когда стандартных инструментов Windows становится недостаточно
Нативные инструменты Windows действительно имеют некоторую диагностическую и мониторинговую ценность. Монитор производительности например, имеет счетчики производительности для процессоров, памяти, дисков, процессов и многого другого.
Просматривая через Диспетчер серверов, данные о производительности, событиях или службах могут быть доступны для локальных и удаленных серверов.
Однако это всего лишь диагностика. В этих инструментах отсутствуют возможности мониторинга и оповещения, которые необходимы ИТ-команде для их физических и виртуальных серверов Windows.
Начните с того, чего не хватает в вашей текущей системе мониторинга
Первое, что нужно спросить при рассмотрении изменения, это не "Какой продукт имеет наибольшее количество функций?", а "Чего не хватает нашему существующему программному обеспечению для мониторинга серверов?" Потому что именно эти ограничения должны определять критерии выбора для потенциального решения-замены.
В каком случае ваша текущая настройка мониторинга Windows Server нуждается в замене?
Решение для мониторинга не нужно заменять только потому, что оно устарело, а скорее если оно мешает администраторам своевременно обнаруживать, понимать и реагировать на проблемы с инфраструктурой.
Несколько предупреждающих знаков могут указывать на то, что текущий подход больше не удовлетворяет этой потребности.
Мониторинг стал слишком фрагментированным
Администраторы могут использовать один инструмент для производительности сервера, другой для журналов событий, различные инструменты для доступности сервиса и еще одну панель управления для веб-сайтов или приложений.
Хотя каждый компонент может работать самостоятельно, процесс устранения неполадок становится более сложным, если администраторам необходимо вручную сопоставлять данные, так как это требует гораздо больше усилий. Кроме того, может стать трудно обеспечить постоянный мониторинг всех критически важных систем.
Поэтому вариант замены должен объединять основные компоненты и позволять администраторам более тщательно приоритизировать системы, которые они нуждаются в мониторинге, исключая те, которые не нужны.
Оповещения создают шум вместо полезной информации
Система оповещения, которая сообщает о каждом временном всплеске ЦП, может быть почти такой же бесполезной, как и та, которая упускает важные проблемы.
Эффективный мониторинг требует контекста; краткое увеличение использования ресурсов вряд ли потребует каких-либо действий, в то время как увеличение использования ЦП в сочетании с долгосрочным увеличением памяти, повторяющимися сбоями в обслуживании или уменьшением дискового пространства будет указывать на развивающуюся проблему. Базовые линии и тенденции являются важными факторами в определении наличия проблемы или нормального варианта операций.
Если администраторы игнорируют оповещения, поскольку они являются общими и неважными, настройка системы оповещения должна быть ключевым приоритетом при выборе замены.
Затраты растут быстрее, чем инфраструктура
Продукты мониторинга имеют крайне разнообразные модели лицензирования. В зависимости от поставщика они могут масштабироваться в зависимости от количества серверов, датчиков, услуг, элементов, ядер ЦП, метрик или объема данных.
Платформа, которая была экономически эффективной для десяти серверов, может стать значительно менее привлекательной при пятидесяти или ста. Рост инфраструктуры также может увеличить косвенные расходы, если платформа мониторинга требует дополнительных ресурсов для хранения, сборщиков или административных ресурсов.
Планирование замены должно учитывать не только сегодняшнюю цену, но и то, что приводит к росту общей стоимости мониторинга со временем.
Проблемы достигают пользователей раньше, чем достигают ИТ.
Одним из самых распространенных предупреждающих знаков является то, что тикеты поддержки регулярно выявляют проблемы с инфраструктурой до того, как они будут обнаружены системой мониторинга.
Недостаточная память, нехватка свободного места на дисках, сбой служб, аномальное потребление пропускной способности или деградация производительности приложения должно быть выявлено достаточно рано, чтобы администраторы могли провести восстановительные работы до того, как затронутые системы испытают серьезные простои.
Если IT-отделы организации регулярно сталкиваются с проблемами инфраструктуры, которые были выявлены через каналы поддержки пользователей, может возникнуть необходимость пересмотреть существующую настройку.
Что должен мониторить заменитель мониторинга Windows Server?
Перед сменой платформ необходимо определить возможности мониторинга, которые командам ИТ нужно сохранить, и те, которые новое решение должно обеспечить.
Большинство реализаций Windows Server требуют мониторинга как минимум нескольких категорий.
Производительность ЦП, памяти и диска
Хотя использование ЦП полезно, проценты редко рассказывают всю историю. Устойчивое давление на процессор, активность процессов и переменные модели использования предоставляют больше контекста по общим операциям, чем изолированные пики.
Мониторинг памяти также должен выявлять устойчивое потребление, давление на страницу и необычный рост, а не просто отображать текущее использование ОЗУ. Мониторинг диска должен учитывать как емкость, так и активность, так как сервер может иметь достаточно свободного места, сталкиваясь с узким местом ввода-вывода, или работать нормально, в то время как доступная емкость приближается к критическому уровню.
Руководство по производительности Windows Server от Microsoft использует счетчики по процессорам, памяти, логическим и физическим дискам, процессам и другим компонентам для исследования узких мест в системе. Важный момент для планирования замены заключается в том, чтобы сохранить достаточную глубину для понимания причин изменения потребления ресурсов, а не просто в том, высоко ли оно.
Процессы и критические службы
Здоровье операционной системы - это лишь часть картины.
Машина Windows Server может быть включена и работать, даже если приложение, процесс или служба, которые пользователи на самом деле хотят запустить, перестали работать. Требования к мониторингу должны отражать роль каждого сервера и услуги, которые необходимы для выполнения этой роли.
Сервер Internet Information Services (IIS), сервер базы данных, контроллер домена и хост сеансов удаленного рабочего стола не имеют одинаковых требований. Полезная замена позволила бы администраторам отслеживать то, что важно для каждого сервера, вместо того чтобы просто использовать одно определение состояния для всей среды.
Сетевая активность и пропускная способность
Неожиданные паттерны трафика, сетевые ошибки или необычное потребление пропускной способности может выявить как проблемы с производительностью, так и проблемы с инфраструктурой.
Сетевое видение становится особенно полезным, когда администраторам необходимо определить, является ли медленная производительность приложения следствием работы сервера, сети или другой зависимой системы.
Замена мониторинга Windows Server не обязательно должна становиться полноценной платформой для мониторинга сети. Однако она должна обеспечивать уровень видимости сети, который требуется для нормальных процессов устранения неполадок вашей команды.
События, Приложения и Нагрузки
Для некоторых организаций общие метрики операционной системы достаточно. Для других они лишь начало.
Среда Windows Server может размещать службы домена Active Directory, IIS, SQL Server, Hyper-V и другие рабочие нагрузки с их собственными показателями состояния. Базовый мониторинг ЦП, памяти и диска не может выявить каждую ошибку, специфичную для рабочей нагрузки.
Это создает важный критерий замены: нуждается ли организация в основном в общем мониторинге состояния Windows Server или ей требуется глубокая видимость конкретных рабочих нагрузок и приложений Microsoft?
Ответ может значительно изменить, какая платформа мониторинга является подходящей.
Что должно улучшить замещение?
Поддержание жизненно важного мониторинга является лишь частью задачи. Новая система также должна решить операционные ограничения, которые привели к замене.
Четыре функции заслуживают особого внимания.
Централизованная видимость
Администраторы должны иметь возможность оценивать состояние многих контролируемых серверов, не затрачивая время на подключение каждый раз или использование набора разрозненных инструментов.
Централизация станет более важной по мере расширения инфраструктуры на несколько мест, виртуальных экземпляров, удаленные серверы или на территории клиента. Цель состоит не в том, чтобы создать еще одну панель управления, а в том, чтобы предоставить администраторам обзор, с помощью которого они могут определить области, требующие более тщательной проверки.
Исторические данные и базовые показатели
Мониторинг в реальном времени отвечает на вопрос "Что происходит сейчас?", но исторический мониторинг отвечает на не менее важный вопрос "Является ли то, что происходит сейчас, чем-то, что должно происходить?"
Сервер, работающий с 70% использованием памяти, может быть совершенно здоровым, если это максимальный уровень, до которого он когда-либо достигает, но медленный рост с 30% до 70% использования также может быть началом важного инцидента.
Исторические данные позволяют ИТ-командам установить базовые уровни производительности углубиться в повторяющиеся инциденты, чтобы выявить их основные причины, планировать емкость и принимать решения о том, положительно или отрицательно изменения в инфраструктуре повлияли на производительность. Поэтому замена должна оцениваться по способности предоставлять ценность на основе исторических данных, а также по тому, что она предлагает для панелей мониторинга в реальном времени.
Действительные уведомления
Оценки замены должны выходить за рамки бинарного подхода к тому, поддерживает ли платформа «уведомления».
Администраторы захотят узнать, можно ли настроить пороги под их окружение, кто получает уведомления и делают ли уведомления различение между временными аномалиями и условиями, требующими вмешательства, практичным.
Цель не в том, чтобы генерировать больше предупреждений. Она заключается в том, чтобы уменьшить шум и сделать труднее упустить важные условия.
Полезная отчетность
Отчеты полезны как средство передачи информации, которую необходимо просмотреть в течение определенного времени или сообщить за пределами администратора, который в настоящее время просматривает панель управления.
Они могут помочь ИТ-персоналу проверить потребление ресурсов, исследовать повторяющиеся проблемы, документировать доступность или предоставлять информацию об инфраструктуре клиентам и руководству. Запланированная отчетность может сэкономить администраторам ручные усилия по многократному извлечению одной и той же информации.
Ключевым критерием является не количество доступных шаблонов отчетов, а то, что отчеты касаются операционных вопросов, которые организация действительно должна задавать.
Вам нужно мониторинг сервера или полная наблюдаемость?
Это может быть самым критическим решением в области выбора замены для мониторинга Windows Server. Современные платформы наблюдаемости могут собирать метрики и журналы инфраструктуры, а также поддерживать трассировки, мониторинг производительности приложений, облачные сервисы, контейнеры и телеметрию в крупном масштабе.
Для распределенных приложений, микросервисов или сложных гибридных облачных сред эти возможности могут быть необходимы.
Когда мониторинг сервера с фокусом достаточно
Они не всегда необходимы для каждой среды Windows-сервера, однако.
Команда ИТ, сосредоточенная исключительно на производительности серверов, процессах, пользователях, пропускной способности, веб-сайтах, оповещениях и тенденциях инфраструктуры, может не получить выгоду от внедрения архитектуры наблюдаемости, которая добавляет дополнительные телеметрические каналы, требования к хранению и специализированное администрирование.
Когда более широкая наблюдаемость становится необходимой
Обратное также верно. Платформа для мониторинга серверов может быть недостаточной, если инженерам требуется распределенное трассирование, картирование зависимостей приложений, централизованная аналитика журналов или детальный мониторинг производительности приложений.
Решение, следовательно, касается объема больше, чем того, какой вариант более сложный. Выберите мониторинг сервера когда требуется благополучие инфраструктуры и операционная видимость. Выбирайте более широкую наблюдаемость, когда устранение неполадок требует от администраторов или инженеров сопоставления поведения инфраструктуры с приложениями, журналами, трассировками и распределенными сервисами.
Правильная замена - это платформа, которая обеспечивает необходимую глубину, не усложняя архитектуру мониторинга без необходимости.
Как следует сравнивать заменители мониторинга Windows Server?
Как только требования и объем будут определены, сравнения продуктов станут гораздо более полезными.
Сравните продукты по одному и тому же набору вопросов, а не начиная с особенностей различных поставщиков.
- Поддерживает ли это версии Windows Server и роли серверов, которые вы используете?
- Может ли он отслеживать ЦП, память, диски, процессы и службы, а также сетевую активность в необходимой степени?
- Могут ли администраторы контролировать несколько серверов из центральной консоли?
- Сохраняет ли он достаточно исторической информации для выявления тенденций и расследования инцидентов?
- Можно ли настроить пороговые значения и оповещения в соответствии с вашей средой?
- Предоставляет ли он отчеты, необходимые администраторам, руководству или клиентам?
- Сколько инфраструктуры необходимо для работы системы мониторинга?
- Мониторинг зависит от агентов, удаленного опроса или другого метода сбора?
- Как изменяется лицензирование по мере увеличения инфраструктуры, которая подлежит мониторингу?
Требует ли команда мониторинга нагрузки, специфичного для Windows, или более широкого наблюдения?
Это создает гораздо более полезное сравнение, чем количество функций на странице продукта.
Глубина мониторинга, сложность развертывания, администрирование, качество оповещений, лицензирование и время до получения ценности — все это влияет на ценность платформы. Меньший вариант может оказаться более подходящим с операционной точки зрения, чем большая платформа, из-за меньших накладных расходов и удовлетворения требований, необходимых организации.
Как вы можете заменить систему мониторинга, не теряя видимости?
Смена программного обеспечения для мониторинга представляет собой определенный риск, так как всегда существует вероятность снижения видимости в критический момент перехода, когда организация заменяет программное обеспечение, предоставляющее такую услугу.
Процесс миграции будет менее рискованным, если он будет поэтапным.
Существующее покрытие мониторинга инвентаря
Текущую систему следует инвентаризировать, чтобы установить базовый уровень того, что новый инструмент должен отслеживать до начала процесса миграции и снятия любых компонентов.
Инвентаризация должна включать все серверы, веб-сайты, программы, услуги, наиболее важные показатели производительности, пороги, уведомления и отчеты.
Особое внимание следует уделить пользовательским проверкам, созданным со временем, которые могли утратить свою значимость для тех, кто поддерживает систему после миграции. Этот базовый инвентаризационный список будет служить критическим покрытием для проверки замены.
Установить текущие базовые линии
Запишите нормальную производительность перед миграцией.
Использование ЦП, потребление памяти, активность диска и пропускная способность варьируются в зависимости от нагрузки и роли сервера. Контроллер домена не обязательно будет иметь такое же нормальное поведение, как сервер приложений или баз данных.
Существующая базовая информация предоставляет администраторам справочную информацию для настройки и оценки новой платформы.
Запустите обе системы мониторинга временно
По возможности, поддерживайте работу существующих и заменяемых систем на протяжении всего переходного периода.
Параллельный мониторинг помогает администраторам убедиться, что собранная информация на обеих системах согласована и важные элементы не отсутствуют. Это также полезно для выявления любых различий в интервале сбора, методах измерения и других факторах до полного развертывания заменяющей системы.
Новые и старые платформы не обязаны предоставлять точно одни и те же данные, но они должны позволять администраторам получать необходимую информацию.
Проверить покрытие мониторинга
Сравните новую платформу с инвентарем, который был создан до миграции на нее.
Убедитесь, что важные серверы, службы, веб-сайты, метрики и другие контролируемые ресурсы учитываются. Это также хорошее время, чтобы подумать, имеют ли устаревшие проверки ценность, операционную или они просто слепо повторяют старые конфигурации.
Инициатива по замене должна стремиться сохранить необходимую видимость, но не ту сложность, которая была ненужной.
Тестовые оповещения перед отключением старой платформы
Не предполагайте, что оповещение будет работать только потому, что установлен порог.
Убедитесь, что ожидаемые условия отправляют уведомления, что они доставляются правильным людям и что пороги не установлены слишком высоко/низко. Где это возможно, следите за тем, чтобы замена проходила через достаточное количество нормальных вариаций нагрузки, чтобы увидеть очевидный шум оповещений.
Снимите с эксплуатации старую платформу только после того, как вы проанализируете покрытие и оповещения.
Ищете более простую замену для мониторинга Windows Server?
Не каждой организации нужна платформа наблюдаемости на уровне предприятия для поддержания полезной видимости своей серверной инфраструктуры. Для ИТ-команд, которые в основном следят за состоянием серверов, потреблением ресурсов, процессами, пропускной способностью, пользователями и веб-сайтами, специализированное решение может обеспечить необходимую операционную видимость без введения ненужной сложности мониторинга.
Мониторинг сервера TSplus централизует мониторинг в реальном времени и исторический мониторинг серверов Windows и Linux, а также веб-сайтов, с настраиваемыми оповещениями и индивидуальной отчетностью. Администраторы могут отслеживать использование ЦП, памяти, активности диска, процессов, пропускной способности и подключенных пользователей из одного места, что делает его практичным вариантом для замены фрагментированной или чрезмерно сложной системы мониторинга.
Заключение
Выбор замены для мониторинга Windows Server начинается с понимания, почему существующая настройка больше не работает, и определения видимости, которая действительно требуется вашей инфраструктуре. Важнее, чем просто выбрать платформу с самым длинным списком функций, являются охват мониторинга, действенные оповещения, исторические данные, отчетность, администрирование и масштабируемость.
Как только будет установлен правильный объем, постепенно мигрируйте и проверяйте покрытие мониторинга перед выводом существующей системы из эксплуатации. Цель состоит не в том, чтобы воспроизвести каждую унаследованную конфигурацию, а в том, чтобы сохранить необходимую видимость, снижая при этом затраты, сложность или операционные ограничения, которые изначально стали причиной замены.