ИТ-мониторинг: советы интегратора

Для контекста напомним, что такое мониторинг, какие задачи он решает и кто является его пользователем.

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

Пользователями систем мониторинга могут быть инженеры дежурной смены, второй и третьей линий технической поддержки, администраторы оборудования, систем и сервисов, а также менеджеры сервисов. И каждый из них использует возможности системы, которые ему необходимы для выполнения должностных обязанностей. Так, для первых важна оперативная реакция на инциденты, вторым нужно оценивать текущее техническое состояние сервисов для обеспечения их надежного функционирования, третьим требуются детальные срезы собранных данных о работе ИТ-инфраструктуры для анализа и последующего разбора «полетов». А менеджеры сервисов должны видеть общую картину и статистику по услугам. И даже более того – на верхнем уровне управления можно отслеживать непрерывность бизнеса, соединив технические данные с показателями эффективности или с финансовыми показателями.

Директор департамента программных решений INLINE Technologies Алексей Скворцов
Фото: INLINE Technologies

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

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

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

Прежде всего скажем, что в системе, ориентированной на крупную ИТ-инфраструктуру, специализированное хранилище следует формировать на основе колоночных баз данных с функцией управления временными рядами (Time Series). Это обусловлено тем, что функции агрегации большого числа объектов на традиционных реляционных СУБД гораздо менее производительны.

Что касается непосредственно архитектуры системы, то в ней должны быть предусмотрены решения для сбора данных из нескольких контуров и/или региональной сети. Это обеспечивает возможность горизонтального масштабирования при увеличении нагрузки. Хорошо, если такой сборщик сможет работать в режиме ненадежной связи и будет накапливать данные, которые отправит в ядро мониторинга при ее восстановлении.

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

Элементом подсистемы сбора данных часто являются установленные, например, на сервер программы – агенты, собирающие характеристики уже «изнутри». Это могут быть сведения как о загрузке CPU или свободной памяти, так и о запущенных процессах, наличии библиотек в системе, их актуальности, работе сервисов и приложений, действиях пользователя. Агенты в системе мониторинга также должны получать задания от ядра системы и исполнять их. Такая возможность позволяет, помимо сбора данных, реализовать функции управления наблюдаемым объектом – скажем, программирование непосредственной реакции на происходящее событие. Так, на случай отказа системы охлаждения в ЦОД из-за проблем с питанием можно будет настроить принудительное выключение серверов по достижении определенной температуры. И тогда удастся гарантированно избежать перегрева устройств, даже если батареи бесперебойного питания еще поддерживают работу оборудования.

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

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

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

Один из самых полезных элементов системы мониторинга – это подсистема обнаружения, дискаверинга. При задании адреса сети запускается процесс сканирования, и система находит установленные устройства. Сканирование по MAC-адресам, портам, IPMI, службам zeroconf позволяет не только обнаружить активное устройство, но и достаточно точно его описать.

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

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

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

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

Хорошо, если предметом ИТ-мониторинга станут не только физические, но и логические объекты. Ведь наблюдение отдельных устройств в крупных инфраструктурах целостной картины не дает. Дашборд с метриками 100 единиц оборудования не поможет понять происходящее. Равно как и отображение отказа одного сервера не поможет оценить масштаб проблемы.

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

Отметим, что моделирование логических зависимостей создает предпосылки для формирования в системе мониторинга общей ресурсно-сервисной модели с возможностью поиска причин отказа (Root Cause Analysis). Но здесь важно понимать, что речь идет не о том, что система магическим образом распознает «бессигнальные» ошибки на устройстве, а о том, что она ориентируется на те взаимосвязи, которые в нее заложены экспертом. Это позволяет однозначно определять источник неисправности и тратить меньше времени на решение инцидентов.

Конечно, нельзя обойти тему искусственного интеллекта. По мере накопления в себе сведений ИТ-мониторинг превращается в полноценную систему больших данных, обработка которых требует подходов на основе ИИ. И на базе машинного обучения система мониторинга может выявлять аномалии, проводить корреляции множественных событий, автоматизировать группировку большого числа связанных алертов в единый инцидент.

ИИ-инструменты очень полезны в решении ресурсоемких рутинных задач. Например, при обработке слабоструктурированных данных, таких как логи, с их помощью можно извлекать сведения об ошибках приложений, восстанавливать историю развития этих ошибок и таким образом формировать готовые инциденты. Кроме того – проводить детальную диагностику с учетом параметров запросов, приведших к проблеме, осуществлять предиктивный анализ и прогнозировать, скажем, срок переполнения диска, темпы и периоды нарастания ошибок в логах или деградацию производительности БД. При этом надо помнить – использование ИИ не заменяет человека, а лишь повышает эффективность его работы.

Еще один аспект, которым не стоит пренебрегать, – рассмотрение ИТ-мониторинга с точки зрения информационной безопасности. Очевидно, он – критически значимый объект информационной защиты. Предоставление системой мониторинга доступа ко всей инфраструктуре делает ее потенциальной целью для несанкционированного проникновения и взлома злоумышленниками. Для того чтобы закрыть это окно для хакеров, проработки требуют все аспекты ИБ: механизмы авторизации и разделение ролей пользователей, аудит и логирование действий, шифрование данных при связи между компонентами системы, криптозащита конфигурационной информации, сегментирование сети, блокировка ненужных портов. В свою очередь, API должен быть защищен от DDoS-атак, настроен на проверку входных данных и обязательную авторизацию, а также иметь лимит на количество соединений.

В заключение скажем, что полезным дополнением к системе мониторинга являются средства организации работы, входящие в Service Desk. Отдельные списки обнаруженных, но не описанных элементов, возможность передать объект другому ответственному, различные напоминания и уведомления о задачах, календари с графиками обслуживания – все это значительно упрощает работу администраторов с обширной номенклатурой оборудования и ПО.

Безусловно, в системах мониторинга реализовано много и других функций. В статье мы рассказали о тех, без которых, по нашей обширной практике, трудно построить эффективный ИТ-мониторинг, который будет отслеживать не только ИТ-инфраструктуру, но и влияние ее состояния на производственные и бизнес-процессы современной организации.

Мониторинг — это всегда «пошив индивидуальный», и выбор тех, кто будет его внедрять и поддерживать, не менее важен, чем выбор самой системы.

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

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

Автор: Алексей Скворцов, директор департамента программных решений INLINE Technologies.