Современная ИТ-инфраструктура организации может включать физические серверы, виртуальные машины, рабочие станции, сетевое оборудование, базы данных, контейнерные платформы и прикладные сервисы. Отдельные компоненты связаны между собой, поэтому проблема на одном уровне нередко отражается на работе других систем. Для ИТ-службы важно не только узнать о факте сбоя, но и определить, где он возник, какие сервисы затронуты и что происходило непосредственно перед инцидентом.
Для решения таких задач используются системы мониторинга и платформы наблюдаемости. Их назначение состоит в централизованном сборе и анализе технической информации о состоянии инфраструктуры. "Астра Мониторинг" относится к этому классу решений и предназначен для наблюдения за физической и виртуальной инфраструктурой, приложениями, системными и бизнес-сервисами, а также программными продуктами экосистемы "Группы Астра". Платформа объединяет работу с метриками, журналами событий и трассировками.
Чем наблюдаемость отличается от обычного мониторинга
Классический мониторинг обычно отвечает на вопрос, находится ли контролируемый объект в нормальном состоянии. Например, система проверяет загрузку процессора, свободную память, доступность сетевого узла или время ответа сервиса. При выходе показателя за установленную границу формируется предупреждение.
Наблюдаемость рассматривает инфраструктуру несколько шире. Задача заключается не только в фиксации заранее известных отклонений, но и в предоставлении данных, по которым инженер способен исследовать состояние сложной системы. Для этого одновременно анализируются разные типы телеметрии: числовые показатели, журналы событий и последовательности прохождения запросов через компоненты приложения.
Такой подход становится особенно важным в распределённых системах. Если пользователь сообщает, что корпоративное приложение работает медленно, причиной могут быть база данных, сеть, нехватка ресурсов виртуальной машины, ошибка приложения или один из промежуточных сервисов. Отдельный график загрузки процессора не всегда позволяет установить источник проблемы.
"Астра Мониторинг" построен вокруг объединения различных данных в общем интерфейсе. На официальной странице продукта отдельно указана работа с метриками, логами и трейсами, а также централизованное представление состояния объектов инфраструктуры.
Какие уровни инфраструктуры можно контролировать
Для полноценного наблюдения недостаточно отслеживать только физические серверы. Современный сервис может зависеть сразу от нескольких технологических уровней. На серверном оборудовании работает виртуальная среда, внутри неё размещены операционные системы, контейнеры и базы данных, а поверх них - прикладные и бизнес-сервисы.
В перечень объектов мониторинга "Астра Мониторинг" входят серверное и сетевое оборудование, виртуальные машины, рабочие станции на Linux и Windows, Kubernetes, Docker, базы данных, бизнес-приложения и продукты "Группы Астра". Таким образом, платформа ориентирована на наблюдение за инфраструктурой разных типов, а не только за одним технологическим стеком.
Для организации это важно с точки зрения анализа взаимосвязей. Например, высокая задержка пользовательского приложения может совпадать с ростом нагрузки на базу данных или нехваткой ресурсов конкретного узла. Если информация собирается в одной системе, специалисту проще сопоставлять события во времени.
При этом наличие поддержки определённой категории инфраструктуры ещё не означает одинаковой глубины мониторинга для любого оборудования или приложения. Перед внедрением необходимо определить, какие метрики требуются организации, существуют ли подходящие агенты и экспортёры и насколько полно конкретная версия продукта поддерживает используемую систему.
Метрики как источник информации о состоянии системы
Метрики - это числовые значения, которые регулярно измеряются и сохраняются с отметками времени. На сервере такими значениями могут быть загрузка процессора, использование оперативной памяти, объём свободного дискового пространства и сетевой трафик.
Для приложений набор показателей будет другим. Можно контролировать время выполнения операций, количество запросов, число ошибок и другие характеристики. Для базы данных важны активные соединения, блокировки, состояние репликации или продолжительность запросов.
В документации "Астра Мониторинг" для базового серверного наблюдения упоминаются сведения о CPU, RAM, дисках, сети и температуре. Для сетевого оборудования предусмотрен сбор данных о трафике, ошибках и загрузке интерфейсов, а для PostgreSQL, Redis и MySQL - специализированные показатели состояния баз данных.
Польза метрик заключается прежде всего в возможности анализировать динамику. Одно значение загрузки процессора мало что говорит о состоянии системы. График за несколько часов или дней позволяет увидеть устойчивый рост нагрузки, периодические пики или связь с определёнными операциями.
Логи и анализ событий
Метрики показывают, что произошло изменение, но далеко не всегда объясняют его причину. Для более подробного расследования используются журналы, или логи.
Лог содержит записи о событиях в операционной системе, приложении или оборудовании. Это могут быть сведения о запуске сервиса, ошибке подключения, неуспешной авторизации или проблеме при обработке запроса.
Если журналы хранятся только на отдельных серверах, диагностика распределённого приложения усложняется. Инженеру приходится подключаться к нескольким машинам и вручную сопоставлять временные отметки. Централизованный сбор позволяет искать события из разных источников через одну систему.
"Астра Мониторинг" предусматривает сбор и анализ логов, их поиск и фильтрацию, а также категоризацию ошибок по уровням критичности. В документации приводятся примеры системных журналов, логов Nginx, Apache и HAProxy, событий безопасности и журналов приложений.
Для практической эксплуатации важна настройка сроков хранения. Чем больше серверов и приложений подключено, тем быстрее растёт объём данных. Поэтому необходимо заранее определить, какие журналы действительно нужны, насколько подробно их собирать и сколько времени хранить.
Трассировки запросов
Третий тип данных наблюдаемости - распределённые трассировки, или трейсы. Они особенно полезны для приложений, состоящих из нескольких взаимодействующих сервисов.
Пользовательский запрос может пройти через веб-сервер, сервис авторизации, прикладной модуль и базу данных. Если итоговая операция выполняется медленно, требуется выяснить, на каком участке появилась задержка.
Трассировка отображает путь запроса между компонентами и время отдельных этапов его обработки. Благодаря этому можно обнаружить сервис, который стал узким местом, даже если остальные части инфраструктуры продолжают работать нормально.
В функциональности "Астра Мониторинг" заявлена трассировка пользовательских запросов, отображение результатов отправки и получения запросов и использование этих сведений для поиска узких мест бизнес-операций.
Трейсы особенно полезны вместе с метриками и логами. Сначала инженер может увидеть увеличение времени ответа на графике, затем найти медленный участок по трассировке и после этого изучить журналы соответствующего компонента.
Агенты и экспортёры данных
Платформа наблюдаемости должна каким-либо способом получать данные с контролируемых объектов. Для этого применяются агенты, экспортёры и стандартные протоколы взаимодействия.
Агент обычно устанавливается непосредственно в операционной системе и собирает сведения о её состоянии. Экспортёр выполняет более специализированную задачу: получает показатели конкретной системы и представляет их в формате, понятном платформе мониторинга.
В документации "Астра Мониторинг" приводятся node_exporter для системных метрик, process_exporter для наблюдения за процессами, snmp_exporter для сетевого оборудования, blackbox_exporter для проверки доступности, а также специализированные экспортёры PostgreSQL, Redis и MySQL. Для Kubernetes используется kube-state-metrics.
В выпуске Astra Monitoring 0.7 разработчик также переработал управление агентами и экспортёрами. Их настройку перенесли в интерфейс платформы, а система получила средства просмотра статусов и перехода к журналам конкретного хоста. Предусмотрена работа как с подготовленными экспортёрами продукта, так и со сторонними Open Source-компонентами.
Наблюдение за сетевым оборудованием
Сеть является одним из основных слоёв инфраструктуры. Сервер может работать исправно, но приложение всё равно будет недоступно из-за проблемы маршрутизатора, коммутатора или сетевого канала.
Для получения данных от сетевого оборудования широко применяется SNMP. Через этот протокол можно собирать сведения о состоянии интерфейсов, объёме переданного трафика и сетевых ошибках.
В документации "Астра Мониторинг" для подобных задач указан snmp_exporter. Кроме того, в версии 0.10 была реализована возможность получать SNMP-метрики с нескольких источников с использованием разных учётных записей, что ориентировано на распределённые инфраструктуры.
Другой подход заключается в активной проверке доступности сервиса. Например, система может периодически обращаться к HTTP-адресу или проверять узел по ICMP и фиксировать время ответа. В документации для таких проверок указан blackbox_exporter с поддержкой HTTP, ICMP и TCP.
Мониторинг виртуальных и контейнерных сред
Виртуализация значительно увеличивает число объектов, которые приходится учитывать администраторам. Один физический сервер способен размещать множество виртуальных машин, каждая из которых содержит собственные сервисы.
Контейнерная инфраструктура добавляет ещё один динамический уровень. Контейнеры могут автоматически запускаться, перемещаться и завершать работу, поэтому ручное добавление каждого такого объекта в систему мониторинга становится непрактичным.
"Астра Мониторинг" заявляет контроль виртуальных машин, Docker и Kubernetes. Документация платформы отдельно содержит разделы для контейнерной инфраструктуры и интеграций с различными технологическими компонентами.
При построении такого мониторинга полезно разделять уровни. Состояние физического сервера, виртуальной машины, контейнера и приложения - разные категории данных. Если все они представлены только одной общей метрикой доступности, диагностическая ценность системы значительно снижается.
Дашборды и визуализация
Собрать данные недостаточно - специалистам требуется быстро интерпретировать их. Поэтому существенной частью платформ наблюдаемости являются панели визуализации.
Дашборд объединяет графики, таблицы, индикаторы и другие элементы, связанные с определённой системой или задачей. Например, панель базы данных может одновременно отображать количество подключений, нагрузку, ошибки и продолжительность запросов.
"Астра Мониторинг" предоставляет единый веб-интерфейс для наблюдения за инфраструктурой и поддерживает визуализацию метрик. На официальной странице продукта также описана "Карта хостов" - представление подключённых объектов с информацией об агентах, логах и проблемах, фильтрацией и группировкой по тегам.
Карта хостов была добавлена в версии 0.10. В этом же выпуске были доработаны комплексные графики и механизм автоматического обновления данных в интерфейсе.
Для крупной инфраструктуры визуальная карта удобна как верхний уровень обзора, однако для диагностики всё равно необходим переход к детальным метрикам и событиям отдельного объекта.
Пороговые значения и обнаружение отклонений
Одной из базовых задач мониторинга является определение момента, когда состояние системы требует внимания специалиста.
Простейший вариант - статический порог. Например, при достижении заданной загрузки ресурса формируется событие. Такой механизм понятен, однако подходит не для всех ситуаций. Для некоторых систем нормальная нагрузка сильно меняется в течение суток.
В функциональности "Астра Мониторинг" предусмотрена работа со статическими и динамическими порогами, а среди сценариев использования разработчик указывает контроль состояний, генерацию алертов и обнаружение аномалий.
Настройка порогов требует практического анализа. Слишком чувствительное правило создаёт большое количество предупреждений, большинство которых не требует действий. Слишком высокий порог, напротив, может привести к тому, что инженер узнает о проблеме уже после нарушения работы сервиса.
Поэтому после внедрения мониторинга правила оповещения необходимо регулярно корректировать на основе накопленной статистики.
Уведомления и управление инцидентами
Обнаруженное системой событие должно своевременно попасть к ответственному сотруднику. Иначе даже хорошо настроенный сбор данных не позволит сократить время реакции.
"Астра Мониторинг" предусматривает настройку уведомлений и интеграцию с системами регистрации инцидентов. В документации также перечислены варианты алертинга через электронную почту, Telegram, Slack и ITSM. Конкретный набор интеграций необходимо сверять с документацией используемой версии.
В версии 0.10 была доработана система уведомлений: появилась возможность включать несколько типов получателей в один канал и фиксировать подтверждение получения важных сообщений.
На практике схема оповещения должна учитывать важность сервиса. Некритичное предупреждение может быть отправлено в общий канал, тогда как недоступность ключевой системы требует немедленной эскалации дежурному инженеру.
Распределённый и зонтичный мониторинг
Инфраструктура крупной компании может быть распределена между несколькими дата-центрами, филиалами и изолированными сегментами. Если все данные напрямую отправляются в единственную точку через медленные или нестабильные каналы, система мониторинга сама становится зависимой от качества связи.
Для таких случаев используются распределённые схемы сбора. Локальные компоненты получают информацию внутри своего сегмента, после чего необходимые данные передаются на центральный уровень.
"Астра Мониторинг" поддерживает распределённый подход, а на странице продукта отдельно обозначена функция зонтичного мониторинга и централизованного сбора данных от внешних систем.
Зонтичная модель полезна и тогда, когда в организации уже существуют отдельные системы мониторинга. Вместо немедленной замены всех инструментов можно организовать центральный уровень представления данных. Возможности конкретной интеграции необходимо проверять отдельно для каждого источника.
Масштабирование платформы
Количество объектов существенно влияет на архитектуру мониторинга. Несколько серверов создают несопоставимо меньший поток данных, чем тысячи рабочих станций, сетевых устройств, виртуальных машин и контейнеров.
В актуальной документации "Астра Мониторинг" заявлена масштабируемость от небольших конфигураций примерно на десять объектов до инфраструктур более чем с десятью тысячами узлов. Платформа рассчитана на локальные, гибридные и облачные среды.
Однако само заявленное количество объектов не является достаточным расчётом производительности. Два сервера способны генерировать совершенно разный объём телеметрии в зависимости от числа метрик, частоты опроса и количества журналов.
Перед крупным внедрением следует провести нагрузочное проектирование: определить число временных рядов, скорость поступления журналов, сроки хранения, необходимую производительность дисковой подсистемы и резерв по вычислительным ресурсам.
Экспертный мониторинг продуктов "Группы Астра"
Отдельным направлением платформы является наблюдение за другими программными продуктами того же разработчика.
Для них предусматриваются подготовленные метрики, пороговые значения и панели визуализации. Идея заключается в том, что разработчик платформы мониторинга одновременно обладает информацией о внутреннем устройстве наблюдаемого продукта.
В технической документации присутствуют отдельные разделы для ряда продуктов экосистемы, в том числе средств виртуализации, резервного копирования, баз данных и других компонентов.
Для администратора готовый шаблон может уменьшить объём первоначальной настройки. Однако даже преднастроенный мониторинг желательно адаптировать к конкретной инфраструктуре, поскольку допустимая нагрузка и критичность сервисов у разных организаций различаются.
Работа с базами данных
Состояние базы данных часто напрямую влияет на производительность бизнес-приложений. При этом простая проверка того, запущен ли процесс СУБД, не позволяет определить большинство проблем производительности.
Для полноценного мониторинга анализируются соединения, запросы, блокировки, память, репликация и другие показатели. В документации "Астра Мониторинг" перечислена поддержка мониторинга PostgreSQL, Redis и MySQL посредством специализированных экспортёров. В структуре документации также присутствуют MongoDB, Microsoft SQL Server, MariaDB и ClickHouse.
Сопоставление метрик базы данных с показателями приложения помогает определить, действительно ли задержка связана с СУБД. Например, рост времени ответа может совпасть с увеличением числа блокировок или ресурсоёмких запросов.
Но интерпретация этих данных требует понимания конкретной СУБД. Система наблюдаемости предоставляет информацию, тогда как решение о настройке индексов, запросов или архитектуры принимает специалист.
Информационная безопасность платформы мониторинга
Система наблюдаемости сама является важным элементом корпоративной инфраструктуры. В ней сосредоточена информация об адресах серверов, конфигурации сервисов, журналах и возникающих ошибках. Поэтому доступ к ней должен контролироваться не менее внимательно, чем доступ к наблюдаемым системам.
При первом выпуске Astra Monitoring разработчик указывал на использование ролевой модели, позволяющей предоставлять сотрудникам доступ только к необходимой им информации.
В версии 0.10 также были внесены изменения в механизм хранения данных учётных записей: разработчик сообщил о переходе от SHA-1 к более современному варианту SHA.
При внедрении необходимо дополнительно учитывать сетевую сегментацию, правила доступа к интерфейсу управления, хранение учётных данных для SNMP и других источников, резервное копирование самой платформы и защиту каналов передачи телеметрии.
Самомониторинг системы наблюдаемости
Мониторинг имеет смысл только тогда, когда сама система сбора данных исправна. Если агент перестал передавать показатели, отсутствие тревог может ошибочно восприниматься как отсутствие проблем.
Поэтому платформа должна контролировать состояние собственных компонентов. В Astra Monitoring 0.7 разработчик представил концепцию самомониторинга, в рамках которой журналы системы были разделены на серверные и клиентские. Также появились более наглядные сведения о точках подключения агентов и статусах экспортёров.
Практически это позволяет отличать ситуацию "система работает нормально" от ситуации "данные перестали поступать". Для критически важных сервисов такое различие особенно существенно.
Как планировать внедрение платформы
Внедрение системы наблюдаемости целесообразно начинать с определения наиболее важных сервисов, а не с попытки собрать максимальное количество показателей со всего оборудования.
Сначала следует определить, какие системы критичны для пользователей и бизнеса, от каких компонентов они зависят и какие признаки позволяют оценивать их работоспособность. Затем формируется минимальный набор метрик, логов и проверок доступности.
После подключения источников полезно подготовить дашборды для разных ролей. Системному администратору требуются подробные сведения о ресурсах серверов, специалисту базы данных - показатели СУБД, а руководителю эксплуатации - общий статус сервисов и активные инциденты.
Следующим этапом становится настройка уведомлений и проверка сценариев аварий. Искусственно созданный тестовый сбой помогает убедиться, что система действительно обнаруживает проблему, сообщение приходит нужным сотрудникам, а данные позволяют определить причину.
Только после этого стоит расширять охват и увеличивать сроки хранения телеметрии. Такой порядок помогает избежать ситуации, когда платформа собирает огромный массив данных, но ИТ-команда не знает, какие из них использовать при реальном инциденте.
Что учитывать при выборе платформы наблюдаемости
При сравнении решений необходимо оценивать не только количество поддерживаемых технологий. Важны удобство подключения источников, качество поиска по логам, возможности построения запросов и графиков, работа уведомлений, масштабирование и управление правами.
Следует учитывать и уже существующую инфраструктуру. Если предприятие использует Kubernetes, виртуализацию, несколько типов баз данных и разнообразное сетевое оборудование, необходимо проверить каждый значимый сценарий на пилотном стенде.
"Астра Мониторинг" построен с использованием как собственных компонентов, так и технологий с открытым исходным кодом. При первоначальном выпуске разработчик указывал ClickHouse, VictoriaMetrics и PostgreSQL; в актуальной технической документации также описывается использование инструментов экосистемы Prometheus, Grafana и Vector.
Для заказчика это означает необходимость рассматривать продукт как целостную платформу, а не как один графический интерфейс. При расчёте инфраструктуры важны объём поступающих данных, политика резервного копирования, требования к отказоустойчивости и доступные компетенции команды эксплуатации.
Заключение
Платформа наблюдаемости ИТ-инфраструктуры помогает объединить технические данные, которые в сложной информационной системе поступают из множества источников. Метрики показывают изменение состояния и производительности, журналы позволяют изучать события и ошибки, а распределённые трассировки помогают проследить прохождение запросов между компонентами. Совместный анализ этих данных даёт больше информации для диагностики, чем изолированный контроль отдельных серверов.
"Астра Мониторинг" предназначен для наблюдения за различными слоями инфраструктуры: физическими и виртуальными серверами, сетевым оборудованием, рабочими станциями, контейнерными платформами, базами данных, приложениями, бизнес-сервисами и продуктами "Группы Астра". Для работы предусмотрены метрики, логи, трейсы, дашборды, карта хостов, пороги, уведомления и распределённый сбор данных.
При этом внедрение платформы само по себе не обеспечивает бесперебойную работу информационных систем. Результат зависит от того, какие объекты подключены, насколько корректно выбраны показатели, настроены ли пороги и уведомления и способен ли персонал интерпретировать собранные данные.
Поэтому систему наблюдаемости целесообразно строить вокруг практических эксплуатационных задач: обнаружения сбоев, диагностики причин, контроля производительности и оценки доступности сервисов. При таком подходе "Астра Мониторинг" становится единым источником технической информации о состоянии ИТ-ландшафта, а данные платформы используются не только для фиксации уже произошедших проблем, но и для анализа изменений инфраструктуры и более раннего выявления отклонений.
