«Ну вот и дожили до системы мониторинга систем мониторинга», «А потом ещё обязательно нужно настроить мониторинг системы мониторинга, объединяющую мониторинги», – шутят пользователи под обзором зонтичной системы ИТ-мониторинга Monq в одном Telegram-канале о системном администрировании. Шутки в сторону – в этой статье ищем ответы на вопросы, зачем нужен «зонтик» и как в нём действительно всё работает. 

Сразу к делу: кому нужен зонтичный ИТ-мониторинг (и кому не нужен)?

Если кратко, то зонтичный ИТ-мониторинг будет полезен тому самому суровому зрелому энтерпрайзу, который сильно зависит от стабильной работы ИТ. Вот по каким признакам можно понять, что компания созрела для зонтика:

При чём тут слон?

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

Поэтому, столкнувшись с вопросами вроде «Каково влияние отказа этого сервера на общую работоспособность?» или «Какой сервис следует восстановить в первую очередь?», команды могут оказаться в затруднении. Этот отсутствующий компонент обзора приводит к тому, что каждая команда может видеть только свою часть «слона», не осознавая контекста всей ситуации:

Классическая модель реагирования на инциденты в таких организациях часто выглядит так:

→ разные элементы ИТ-окружения подключены к множеству инструментов мониторинга;

→ каждая система генерирует множество предупреждений о проблемах на определенных узлах или ресурсах;

→ уведомления получает ситуационный центр и ответственные команды; 

→ в случае крупного сбоя начинается сложный и часто запутанный процесс совместной работы: обмен взаимными уведомлениями, определение приоритетов и попытки координации действий между командами («Ну что, когда почините?» – «А что чинить-то в первую очередь? У нас там почта завалена алертами. Мы пока вчерашнее не разгребем, не до этого» – «Это вообще не у нас проблема, спросите в группе в телеге»);

→  поиск первопричин, анализ ущерба, перебрасывание «мяча ответственности» – происходит вручную – это увеличивает время реакции и риски для бизнеса.

Схематично работа с авариями при таком сценарии выглядит так:

Какие проблемы это порождает?

Помимо этого, хаос в горизонтальной коммуникации внутри команды часто приводит к путанице в определении ответственности при устранении технических проблем, а также актуальную сегодня проблему ухода западных продуктов, решающих схожие задачи (Splunk, IBM Tivoli, Micro Focus и др.).

Что такое зонтичный мониторинг?

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

• журналы событий операционных систем, оборудования и приложений;

• логи с разных уровней;

• алерты систем мониторинга;

• метрики с оборудования, прикладного и системного ПО;

• трейсы. 

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

Что меняется?

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

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

В результате:

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

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

3. Оценка сбоев через призму бизнеса: проблемы и неполадки теперь оцениваются с точки зрения их воздействия на общую стабильность и эффективность бизнеса, а не просто как инциденты на конкретных узлах инфраструктуры.

4. Автоматизация устранения проблем: процесс реагирования на технические проблемы и сбои становится максимально автоматизированным, что ускоряет процесс восстановления и уменьшает потери для бизнеса.

Откуда можно собирать данные в «зонтик»? 

Зонтичный мониторинг и принцип «одного экрана» был бы бессмысленным, если бы в него нельзя было собрать действительно все данные ИТ-окружения, в том числе логи, события, метрики, трейсы и любые другие структурированные и неструктурированные текстовые данные. Monq, как пример, предоставляет интеграцию с некоторыми ключевыми инструментами, такими, как Prometheus, Zabbix, Nagios, SCOM, Vcenter и Ntopng, используя свои шаблоны. Он также способен без проблем интегрироваться с системами вроде k8s, Linux, zVirt. Однако наиболее мощной особенностью является его способность интегрироваться через API, что позволяет принимать любые текстовые данные из любых систем (способных эти данные по API отправлять). Коннекторы также можно написать самостоятельно или заказать их создание у вендора. Кроме того, Monq предлагает контент-паки для расширения и улучшения функциональности системы и упрощения процедуры её настройки. Вот примерная – не окончательная – схема того, какие данные можно агрегировать:

А что вообще происходит: «вжух – и магия» или всё же придётся поработать? 

Если кратко и без маркетинговых уловок типа «да оно там всё само делается!» – тогда и то, и другое. Чтобы платформа заработала, её нужно настроить. Тут поможет публичная документация и ресурсы поддержки, взаимодействие с вендором и партнёрами, контент-паки, обучение и консультации, ну и, конечно, low-code, здорово облегчающий процесс внедрения.

При внедрении зонтика обычно рассматривается два основных подхода, в зависимости от того, какие сервисы хочется им «накрыть» и как быстро начать им пользоваться.

Подход к внедрению #1. Waterfall, или каскадная модель

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

Процесс внедрения может выглядеть примерно таким образом: 

Подход к внедрению #2. Agile

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

–  «сверху вниз»: клиент выбирает верхний, наиболее важный слой бизнес-сервисов и подключает его к зонтику – точность расчетов здоровья будет не 100%-ной, но решение начнет приносить ценность намного быстрее;

– «фрагмент»: клиент выбирает любой блок ИТ-окружения, например, блок сервисов «Банкоматы» – и внедряет решение на этом фрагменте. «Время до получения ценности» – короткое, и, если всё работает, решением покрывают поэтапно другие фрагменты. Кстати,  попробовать решение и провести свой мини-пилот может любой инженер с бесплатной версией Monq – функционал в ней не ограничен. 

Процесс внедрения при таком подходе намного проще и короче: 

Что всё это даёт? 

1. Единое окно наблюдения за всей телеметрией.

2. Расчёт здоровья каждого компонента в реальном времени.

3. Быстрое определение причин аварий и текущего урона.

4. Контроль SLA. 

5. Автоматизация процессов мониторинга и управление событиями на основе сценариев.

6. Взгляд на сервисы со стороны пользователей (кстати, подробно про синтетический мониторинг написано тут).

7. Сокращение «шума» от систем мониторинга, дедупликация и гибкие инструменты логики корреляции данных. 

8. Сбор и анализ метрик (подробнее можно узнать тут), событий, логов, технологических журналов и прочих текстовых данных из разрозненных источников в одном инструменте.

9. Ролевое управление процессами работы со сбоями.

Словарь

Конфигурационная единица (КЕ) в Monq – любая сущность (компонент), которая принимает участие в правилах расчета статуса или здоровья на основе поступающих в систему данных. Пример конфигурационной единицы: сервер, виртуальная машина, база данных, кластер, сервис, приложение, коммутатор, порт, СХД, контейнер, бизнес-процесс, тест-кейс. Она же является объектом лицензирования. В бесплатной версии доступно использование до 25 активных КЕ.

Полезные ссылки

1. Платформой Monq можно пользоваться бесплатно. Во free-версии доступен весь функционал, единственное ограничение – количество конфигурационных единиц, которые можно подключить (до 25 КЕ). Скачать установщик можно по ссылке. 

2. Если появились вопросы о работе платформы – добро пожаловать в коммьюнити. 

3. Если хочется узнать больше – запишитесь на ближайший вебинар с обзором возможностей платформы, где вы сможете задать вопросы.