В ИТ-среде есть свой профессиональный сленг, который быстрее и понятнее описывает производственные процессы. Большинству читателей встречалось выражение: «какие боли заказчиков лечит …». В данной статье мы поговорим о методе лечения, называемом мониторинг. Нам предстоит разобраться, кому предписано подобное лечение, что является показанием к процедурам, как протекает процесс выздоровления и что такое мониторинг здорового заказчика.
Какие симптомы могут привести заказчика к поставщику систем мониторинга?
Во-первых, это отсутствие системы мониторинга вообще. Это не означает, что систему мониторинга обязательно требуется внедрить. Например, в компании небольшая ИТ-инфраструктура, все оборудование и сервисы которой размещены в одной серверной, находящейся в десяти шагах от рабочего места системного администратора. Специалист в любой момент может проверить работоспособность системы и принять необходимые меры. Полярная ситуация — это инфраструктура, которая только проектируется, и с учетом перспектив бизнеса в проект закладывается возможность дальнейшего расширения ИТ-инфраструктуры. В этом сценарии уже необходим мониторинг.
Рассмотрим второй вариант развития событий. Допустим, система мониторинга у заказчика уже присутствует, но произошедшее расширение инфраструктуры не может быть охвачено имеющимися средствами мониторинга. В силу разных причин. Это может быть, как достижение технологического предела системы мониторинга, так и добавление оборудования, данные с которого, по тем или иным причинам, не могут быть обработаны в имеющейся системе мониторинга.
Что же является объектами мониторинга? Только ли классическое ИТ-оборудование? Безусловно, это привычное «железо»: серверы и периферия, а также иное, «не-ИТ» оборудование (например, кондиционеры). Но важно знать, что в мониторинг можно включать также и сервисы: системное и прикладное ПО заказчика.
В системе мониторинга и управления СТ.Монитор реализован мониторинг оборудования и сервисов, — всего, что имеет цифровой интерфейс. Ядро СТ.Монитор является собственной разработкой команды SMART technologies SOFT, что сообщает большую гибкость системе, дает возможность создать специфические коннекторы для доступа к определенному оборудованию и ПО и внести некоторые интерфейсные изменения. Мониторинг прикладного ПО является комплексной задачей в силу разнообразия объектов надзора: есть ПО, имеющее некоторые коннекторы, позволяющие считывать информацию; есть серверы приложений; есть базы данных. Например, если прикладное ПО написано на Java, то можно получать мониторинговую информацию из виртуальной машины Java.
Система мониторинга собирает метрики из разных источников, и в каждом случае сбор и обработка столь разнообразной информации является предметом консалтинга со стороны команды внедрения системы мониторинга. Команда СТ.Монитор не ставит окончательный диагноз и аналоговым интерфейсам: разработчики системы дают оценку конкретного оборудования и только после этого подтверждают возможность подключения к системе аналоговых интерфейсов.
Процесс мониторинга Система мониторинга собирает со всех объектов наблюдения необходимые данные, сопоставляет их с эталонными значениями и, в зависимости от степени совпадения реальных данных с табличными, формирует предупреждения или сигналы тревоги. В целом понятно, но возникает вопрос: откуда в систему поступают эталонные значения?
Некоторые российские производители оборудования, например, компания YADRO, поставляет вместе со своими продуктами и правила мониторинга, включающие те самые эталонные значения. Производитель считает, что при пересечении информационной системой таких контрольных точек по соответствующим метрикам, необходимо формировать предупредительные сигналы.
Помощь в формализации эталонных данных может быть предоставлена профессиональным сообществом: возможно, кто-то сталкивался с задачей определения контрольных параметров и готов поделиться своим опытом. Этот вариант позволяет получить качественную апробированную информацию, но при условии, что кто-то уже сталкивался с подобным и готов поделиться своими результатами.
Мониторинг
Каким именно оборудованием представлена инфраструктура заказчика? Если говорить о действующих, а не проектируемых системах, то, как правило, это слоеный пирог, нижний слой которого составлен постепенно замещаемым оборудованием ушедших западных вендоров: Dell, IBM, HP и т.д., следующий слой — оборудование Востока и современный слой — это продукция отечественных вендоров: Aquarius, YADRO, Nerpa и т.д.
Большинство вендоров снабжает поставляемое оборудование проприетарными системами мониторинга. Соответственно, возникает задача объединения разрозненных систем в единый центр обработки информации с целью получения полного представления о работоспособности системы. В описанной ситуации хорошим подспорьем становится система СТ.Монитор, изначально проектировавшаяся как мультивендорная, управляющая ИТ-серверами с помощью протокола RedFish и обеспечивающая полноценную поддержку оборудованию различных вендоров.
Из вышесказанного может сложиться представление, что система СТ.Монитор показана для применения только тем организациям, которые имеют большие серверные. Не совсем так. Система СТ.Монитор способна принимать и обрабатывать метрики, получаемые не только с ИТ-оборудования и сервисов, но и с инженерных систем зданий: системы кондиционирования, блоки распределения питания (БРП), источники бесперебойного питания (ИБП), систем контроля и управления доступом (СКУД) и интегрированных с ними систем видеонаблюдения. Все перечисленное присутствует и в ЦОДах, и в серверных, но также находится вне помещений, напрямую относящихся к ИТ инфраструктуре.