Привет! Меня зовут Денис Мухин. Я руковожу управлением мониторинга в РТК-ЦОД. Расскажу о том, как должен работать грамотный мониторинг и зачем он вообще нужен.
Задача мониторинга — указывать на потенциально опасные ситуации, которые могут привести к финансовым и репутационным потерям, например:
Пользователи не могут зайти в приложение или совершить покупку на сайте.
Не работает CRM, привязанная к кассам.
«Упала» складская программа и невозможно завершить отгрузку товара и т. д.
Подобные инциденты тормозят работу компании и могут неприятно сказаться на бизнесе. Как тут поможет мониторинг?
Для начала давайте рассмотрим, как обычно отрабатывают такие ситуации. Традиционно каждую информационную систему контролирует профильная команда. В каждой команде предпочитают определенные инструменты и фокусируются на своем участке инфраструктуры. Обычно это выглядит так:
разные элементы IT-окружения подключены к своим инструментам мониторинга;
каждая система генерирует свои типы предупреждений о проблемах;
в случае крупного сбоя начинается совместная работа команд: обмен уведомлениями, определение приоритетов;
вручную ищется первопричина, анализируется ущерб, команды перекладывают ответственность друг на друга.
При таком подходе сказывается человеческий фактор и можно пропустить часть важной информации.
Даже если есть четкий регламент и понятно, кто с кем взаимодействует, проблемы могут быть неочевидными. Например, у вас есть сайт, который начинает тормозить, то есть запросы от пользователя обрабатываются слишком долго. Инцидент передается группе обслуживания сайта. Там смотрят и говорят: «Похоже, процессор в троттлинг уходит», — и переводят инцидент коллегам, отвечающим за инфраструктуру. Те смотрят: «Да, видимо, процессор перегрелся», и кидают заявку инженеру, чтобы тот поехал в ЦОД и посмотрел, что с процессором. Инженер заходит в серверную, а там сломался кондиционер, который дует на стойку, где этот процессор находится. То есть у вас тормозит сайт, потому что сломался кондиционер.
Спускать заявку все ниже и ниже занимает иногда часы и даже дни. А сайт все это время висит. С хорошо настроенным мониторингом вы бы сразу поняли, что у вас проблема на самом нижнем уровне инфраструктуры.
Как должен работать комплексный мониторинг?
Комплексный мониторинг сигнализирует о потенциальной недоступности сервиса. По его показателям можно предугадывать, когда начнутся проблемы, и заранее принимать меры. Если компромисс между скоростью реакции и планированием — приоритетная задача, то именно мониторинг поможет укротить хаос, покажет, где есть уязвимости, и вы сможете устранить их до того, как произойдет серьезный сбой.
Условно системы мониторинга можно разделить на три типа:
системы мониторинга инженерной инфраструктуры;
системы мониторинга ИТ-инфраструктуры;
системы мониторинга приложений.
Мониторинг инженерной инфраструктуры — это первый уровень системы комплексного мониторинга, очень важный для дата-центров. Отвечает на вопрос, обеспечены ли необходимые физические условия для нормальной работы ИТ-оборудования. Для этого он собирает данные и показывает состояние всех компонентов инженерной инфраструктуры:
температуру и влажность в серверных стойках и коридорах;
стабильность напряжения, состояние источников бесперебойного питания (ИБП/UPS), нагрузку на цепи, работу автоматических вводов резерва (АВР), генераторов и всего, что касается электропитания;
работоспособность кондиционеров, чиллеров, давление в фальшполе;
состояние систем контроля и управления доступом (СКУД), видеонаблюдения и системы пожарной сигнализации.
Для контроля этих параметров обычно используют специализированные DCIM-системы (Data Center Infrastructure Management) или SCADA-системы (Supervisory Control and Data Acquisition).
Следующий уровень — ИТ-инфраструктура, которая обеспечивает работу информационных систем и приложений. На этом уровне мониторятся серверное оборудование, ОС, виртуализация и сетевая инфраструктура.
Мониторинг серверного оборудования позволяет контролировать «здоровье» аппаратных компонентов — состояние процессоров, памяти, дисковых массивов. Благодаря этой диагностике вы узнаете о выходе оборудования из строя до того, как случится сбой сервиса.
Мониторинг операционных систем включает в себя сбор метрик производительности (CPU, RAM, Disk I/O, Network) и проверку критических системных процессов, чтобы оценить нагрузку на серверы.
Мониторинг виртуализации показывает состояние гипервизоров, кластеров и самих виртуальных машин (ВМ). Основные метрики: потребление ресурсов пулами и хостами, загрузка кластера, миграция и состояние резервных копий ВМ.
Мониторинг сетевой инфраструктуры сфокусирован на доступности и производительности коммутаторов, маршрутизаторов, межсетевых экранов. Контролируются загрузка портов, потери пакетов, появление ошибок и состояние сетевых сервисов.
Для сбора данных с ИТ-инфраструктуры применяют универсальные платформы мониторинга — Zabbix, Prometheus и Grafana.
Система мониторинга приложений (Application Performance Monitoring) делает условно инъекцию в приложение и позволяет в режиме «водопада» смотреть все запросы к серверу, базе данных и другим компонентам. Система показывает запрос и время выполнения. Вы можете найти тот самый «селект» (SQL-оператор SELECT, который занимается выборкой данных из таблицы) к базе данных, который тормозит весь процесс, и оптимизировать его.
Я выделю два типа коммерческих систем мониторинга приложений. Первые делают всю работу за вас, но при этом требуют полный доступ к приложению, что не подходит некоторым организациям. Второй тип — это системы с открытым исходным кодом. Чтобы использовать систему второго типа, придется самим писать методы мониторинга приложения и выполнять трассировку метками в коде. Далее система будет опрашивать эти методы, вести статистику и показывать результат.
Разработчики приложений часто используют системы анализа лог-файлов — это специальные сборщики логов, которые записывают их в документоориентированную базу данных. Веб-интерфейс сборщика должен позволять удобно искать, группировать и просматривать результаты. Обычно для таких задач используют ELK-стек (Elasticsearch, Kibana & Logstash).
Некоторые организации используют расширенный мониторинг с отслеживанием активности пользователей. Например, компания продает товары на своей онлайн-площадке. Если мониторинг выстроен правильно, вы сразу узнаете, что отклик сайта у пользователя увеличился и сколько клиентов зашли на сайт и ушли. Сможете вычислить процент потенциальных клиентов, которых потеряли, и предсказать убытки из-за сбоя. А главное — быстро найти первопричину сбоя, будь то проблема в приложении, сети или на уровне ИТ-инфраструктуры.
Зонтичная система мониторинга
Как мы видим, для каждой области в ИТ существуют свои типы мониторинга. Чтобы получить общую картину состояния инфраструктуры и сервисов, используют зонтичные системы. Они подключаются к другим системам мониторинга и собирают информацию в одном окне.
Зонтичные системы мониторинга связаны с ITSM-системами (Service desk): у вас происходит какое-то событие, и по нему можно в автоматическом режиме или с помощью оператора первой линии завести инцидент. Что в этом случае делает зонтичная система? Кроме указания на проблему, она заполняет все необходимые поля: на какой конфигурационной единице случился сбой, кто за нее отвечает, на какую группу нужно перевести инцидент, описание, приоритет и т. д. Заявка уйдет профильному специалисту, минуя промежуточные звенья.
Важный момент — уровень зрелости процессов в компании. Небольшим предприятиям зонтичный мониторинг, возможно, и не нужен — достаточно отслеживать работоспособность «железа» и операционных систем. При этом выгоднее заказать мониторинг как услугу, чем настраивать его самостоятельно.
Если компания достаточно зрелая, можно пойти дальше и организовать детекцию аномалий. Нужно взять базу данных мониторинга за максимально длительный период. Система обучится на этом дата-сете, выявит нормальные показатели для ваших метрик и, когда какой-то показатель выйдет за границы нормы, будет сигнализировать об этом.
Детекция аномалий может учитывать периодичность или сезонность. Допустим, у вас каждый четверг загрузка процессора на каком-то сервере доходит до пиковых значений. Это происходит на протяжении двух лет и не вызывает сбоев. В таком случае система скажет: «Подкорректируй тут пороги, у тебя нормальная ситуация». В реальности каждый четверг у вас происходит бэкап, система нагружается на пике, но это не авария, не нужно будить инженера в три часа ночи.
Еще одна возможность мониторинга со статистикой — предсказание поведения метрик, предиктивная аналитика. «Предиктивка» подскажет, когда кончится место на диске, насколько его хватит при текущих темпах расхода, нужно ли докупать ядра или увеличивать память.
Модель здоровья
Модель здоровья — это система метрик, набор правил, которые описывают критерии работоспособности для сервиса или компонента инфраструктуры. В ней упорядочены признаки корректной работы системы, которые включают:
перечень ключевых метрик (утилизация CPU, потребление RAM, использование дискового пространства);
пороговые значения метрик, при превышении которых статус компонента меняется;
уровень критичности инцидентов и их потенциальное влияние на сервисы.
Задача модели здоровья — преобразовывать сырые данные телеметрии, например «CPU 98%», в осмысленные и приоритизированные оповещения: «Критически важная ВМ: высокая нагрузка на процессор, риск отказа сервиса». Это позволяет командам реагировать на проблемы с учетом их серьезности и влияния на инфраструктуру.
Модель здоровья может быть создана для любого инфраструктурного компонента с измеримыми показателями. Сами правила распространяются как на весь класс устройств, например, на веб-серверы, так и на конкретный критически важный компонент, требующий более строгого контроля.
Условия в модели не ограничиваются одиночными метриками. Возможны целые сценарии, например: «Критический инцидент объявляется, только если одновременно на ВМ-1 зафиксирована проблема А, а на ВМ-2 — проблема Б». По отдельности эти события необязательно негативно повлияют на сервис, но вместе приведут к сбою.
Дополнительным преимуществом модели здоровья является возможность автоматизировать реагирование. В нее можно сразу закладывать описание вероятных причин проблемы и рекомендации по ее устранению, что ускоряет работу инженеров и сокращает время на восстановление сервиса.
в системе зонтичного мониторинга
Главное правило мониторинга
Любое событие мониторинга должно расцениваться как важное. Ваш мониторинг настроен и работает правильно, если есть реакция на событие. Для этого должны четко работать ITSM-процессы. Если, например, поставили новое оборудование, старое «железо» переехало, что-то ремонтируется, то об этом должны знать не только все заинтересованные, но и система мониторинга. Нужно вовремя учитывать все активы и обновлять модель здоровья.
Когда что-то требует ремонта или технического обслуживания, важно перевести объект в режим обслуживания. Однако на практике это правило часто игнорируют. Я не раз наблюдал ситуации, когда оборудование, которое нужно ремонтировать, продолжало работать с перебоями. Если ремонт затягивался из-за отсутствия запчастей и других сложностей, то устройство месяцами отправляло сигналы, которые воспринимались как привычные и не требующие немедленной реакции. Такое халатное отношение создает риск упустить действительно важные инциденты, так как внимание к уведомлениям постепенно снижается.
При посещении отдела мониторинга какой-нибудь компании на экранах дашбордов или панели событий часто можно увидеть большое количество событий красного цвета, то есть аварий высокого приоритета. Сотрудники говорят, что на самом деле все хорошо, все под контролем: «Про это красное мы знаем. Вот когда будет новое красное или бордовое, тогда и начнем действовать».
Потеря доверия — это худшая ситуация, которая может возникнуть в мониторинге. Люди просто не обращают внимания на сигналы и мониторинг превращается в систему, которая увеличивает энтропию и издержки на реагирование.
Внедрение мониторинга
Мониторинг нельзя внедрять стихийно. Сначала надо организовать инфраструктурный мониторинг, потом можно добавить мониторинг приложений. Наконец, систему можно венчать предиктивной аналитикой и детекцией аномалий.
Если ИТ-интегратор говорит: «Сейчас я вам все сразу сделаю, за неделю все внедрю», — скорее всего, вы получите не то, что ожидали. Будет мешанина из разных инструментов, которые еще не адаптированы под вашу ИТ-инфраструктуру. Они будут генерировать кучу «шума», в том числе ложноположительные срабатывания, и все это нужно будет обрабатывать.
Оптимальный вариант — внедрить сначала один процесс, обкатать его, настроить постоянную актуализацию модели здоровья. Затем внедрить второй слой, третий, и так далее.
Для крупной компании внедрение комплексного мониторинга может стать болезненным процессом. Прежде всего, нужно убедить всех профильных специалистов в том, что это необходимо.
Доходит иногда до того, что сотрудники говорят: «Слушайте, у нас уже есть свои скрипты, мы уже все это мониторим. Ну что вы еще лезете со своей системой? Да, мы понимаем, вас руководство обязало. Давайте просто по-тихому. Мы поставим, но будем работать, как мы привыкли, а вы отчитаетесь, что все работает».
Централизованный мониторинг — это не то же самое, что скрипты. Они могут выполнять аналогичные функции, но система мониторинга эту информацию собирает и хранит. У вас будет статистика, и когда произойдет сбой вы сможете посмотреть, а был ли он уже раньше и какие показатели были у всех смежных объектов.
Мы должны были разработать модель здоровья — проанализировать все показатели, которые выдает информационная система, и определить, какие показатели означают, что все хорошо, какие — не очень, а какие говорят о том, что все плохо. Сотрудники заказчика уже на первом этапе не хотели помогать. Мы настроили дополнительно собственную консоль, куда приходили оповещения из системы заказчика. Обнаружив критичные сбои, писали им в чат: «Вы знаете, что у вас сбой?». Они отвечали: «Нет, не знаем, спасибо». Мы так раза три сделали и на стороне заказчика поняли, что система позволяет выявлять сбои, которые привели бы к реальным проблемам.
Еще важный момент: мониторинг сразу выявит слабые места в организации бизнеса. Это не только отсутствие регламентов. Вполне типичен диалог:
— А почему не было проблемы по такому-то оборудованию?
— А где оно? У меня в мониторинге его нет.
— Так вчера поставили же!
— А кто мне об этом сказал?
Понятно, что не налажен процесс постановки оборудования на учет.
Или вы смотрите в систему мониторинга и видите, что имена всех устройств — непонятные наборы символов, и неясно что это, где это, и нужного специалиста быстро не найти. Значит, нет регламента наименования оборудования.
Когда в самом названии устройства закодировано, где оно стоит, какие функции выполняет и прочее, это сильно упрощает работу. Как минимум, эту информацию можно брать для заполнения необходимых полей при заведении инцидента в ITSM-системе.
Службы ИБ часто опасаются, что новая система усложнит их работу и увеличит риск утечки информации. Мониторинг — это самостоятельная система, которая минимально влияет на инфраструктуру и не управляет ею напрямую. При правильном подходе можно обеспечить выполнение всех требований ИБ.
Я считаю, что мониторинг полезен для кибербезопасности. Вы сможете отследить подозрительные события, собрать логи аудита и быстро связать инциденты с внештатными ситуациями.
Выводы
Фундамент мониторинга — сбор информации. Нужно определить, как собираемая информация будет использоваться.
Мониторинг обязательно должен быть встроен в процессы компании и информация там должна быть актуальной. Тогда вы сможете предвидеть проблемы и повышать доступность сервисов.
Спасибо за внимание. Внедряйте мониторинг и держите свои системы под контролем!
