Когда мы говорим об APM-мониторинге, сразу вспоминаются трассировки запросов, мониторинг CPU и памяти, Real User Monitoring. Это логично (почему для этого нужна именно APM-платформа, а не связка Prometheus + Grafana, мы уже разбирали отдельно), но современный мониторинг давно вышел за рамки классического APM и оброс инструментами для самых разных пользователей: бизнеса, аналитиков и продуктологов, DevSecOps, DBA. Такое расширение функционала и принято называть Observability (наблюдаемость).
Я работаю с APM-мониторингом уже 12 лет и хочу поделиться опытом: что обычно подключают к «золотому набору» в первую очередь, в каком порядке и какой эффект это даёт. Примеры буду показывать на Ключ-АСТРОМ, хотя сама логика расширения применима к любой системе наблюдаемости.
Если вы до сих пор используете только APM-часть, то функционал платформы задействован наполовину. Давайте разберёмся, что ещё можно (и нужно) мониторить и как это обогащает картину происходящего.
Observability ≠ APM. В чем разница?
APM закрывает вопросы производительности самого приложения: трейсы, метрики, информация о коде. Observability расширяет этот контекст — добавляет логи, состояние инфраструктуры, данные о сетевом оборудовании, состояние баз данных и брокеров сообщений, а также бизнес-контекст.
Если совсем упрощать: APM показывает, как работает приложение, а полный набор сигналов observability помогает быстро понять, почему оно работает именно так. Упрощение, конечно, но суть передаёт: именно совокупность сигналов помогает сразу выйти на первопричину.
А теперь по порядку — в той последовательности, в которой расширение обычно и происходит на практике.
1. Логи: от отладки к бизнес-аналитике
Расширение почти всегда начинают с подключения логов: это быстро, а эффект виден сразу. Логи, пожалуй, самый недооценённый источник данных в observability. Многие воспринимают их как «мусор» для отладки, но на самом деле логи содержат колоссальный объём информации, в том числе бизнес-события.
Мониторинг бизнес-событий
С помощью парсинга логов и создания метрик можно на лету извлекать бизнес-данные и превращать их в бизнес-события.
Например, компания обрабатывает заявки на страховку, и в логах каждого сервиса есть статус обработки заявки. Ключ-АСТРОМ автоматически парсит логи и позволяет строить на их основе собственные метрики и дашборды. В результате в реальном времени мониторятся не только технические, но и бизнес-показатели: сколько заявок в работе, сколько зависло, на каком шаге.
Привязка логов к трассировкам
На мой взгляд, самый интересный сценарий совместной работы трейсов и логов. Когда в логе появляется ошибка или нестандартный статус, мониторинг автоматически привязывает этот лог к полному пути прохождения запроса в трейсе. Вы видите, что не просто «упал запрос», а весь путь: какой микросервис, какой метод, какие параметры, какие вызовы БД. Комплексный анализ инцидента из одного окна — без ручного поиска корреляций между разными системами.
2. Оборудование: сетевые устройства под контролем
Обычно, второй этап расширения — подключение оборудования. Приложение может быть идеально написано, но если где-то «упал» маршрутизатор или перегружен файервол, в трейсах будут видны только таймауты.
Для полноты картины нужен мониторинг оборудования и привязка этих данных к событиям с уровня приклада. Проблемы на сетевом уровне — частая причина деградаций, и видеть их нужно в той же системе, что и проблемы приложений.
Ключ-АСТРОМ мониторит сетевое оборудование через расширения, работающие на Активных Шлюзах — универсальном компоненте, который выступает точкой опроса. Основной протокол сбора данных — SNMP, реже используются vendor-API.
Что именно можно мониторить:
Маршрутизаторы, коммутаторы, файерволы — любые SNMP-совместимые устройства
Health-статус устройств, доступность интерфейсов
Аппаратные метрики — загрузка CPU, память, температура, состояние блоков питания и вентиляторов
Утилизация сети — загруженность каналов, насыщенные интерфейсы
Автоматическое обнаружение устройств работает через расширение SNMP Autodiscovery: задаёте диапазоны IP-адресов, и система сама сканирует сеть и добавляет устройства в мониторинг.
Эффект. Когда ИИ обнаруживает проблему, он может указать конкретное сетевое устройство как корневую причину. Вместо гаданий «это приложение тормозит или сеть?» получаем чёткий ответ: «перегружен интерфейс на маршрутизаторе Cisco такой-то». Это заметно сокращает среднее время восстановления после сбоя (MTTR).
3. Базы данных: видимость на уровне запросов
Базы данных — традиционное узкое место в производительности приложений. Из коробки система даёт автоматический end-to-end трейсинг вплоть до отдельного SQL- или NoSQL-запроса. Но observability на этом не заканчивается.
Расширения для конкретных СУБД дают доступ к внутренним метрикам, которые недоступны с уровня приложения: состояние кэшей, пулы соединений, I/O-статистика, блокировки, использование буферов. Это помогает находить корневую причину на уровне СУБД, а не просто констатировать «БД медленно отвечает». При этом агенты на хосты с БД ставить не нужно — метрики, аналитика запросов и кастомные SQL-данные собираются удалённо.
Покрытие на сегодня: MySQL (KPI и детали медленных запросов), PostgreSQL (полная observability, анализ планов выполнения), Microsoft SQL Server (AIOps-возможности), Oracle (мониторинг на уровне движка БД), Cassandra (метрики исключений, failed requests, состояние узлов), а также Sybase ASE, IBM Informix, SAP HANA и другие.
Эффект. Классическая ситуация: приложение тормозит на запросах к базе. Разработчики видят в трейсах медленный вызов БД и уверены, что проблема на стороне базы. DBA смотрит в свои инструменты, видит нормальные показатели СУБД и отвечает: «база в порядке, оптимизируйте запросы». Каждый прав в рамках своих данных — и разбирательство тянется днями, потому что команды смотрят в разные системы и сопоставить их картины напрямую невозможно.
Когда метрики СУБД живут в той же системе, что и трейсы приложений, этот спор заканчивается за минуты: рядом с медленным запросом из трейса видно, что происходило в базе в тот же момент — блокировка, исчерпанный пул соединений или действительно неоптимальный план выполнения, и другие исключения, о которых сообщает база данных. Причина видна обеим командам сразу.
4. Брокеры сообщений и корпоративные сервисы
Современные архитектуры немыслимы без очередей сообщений — самые популярные сегодня ActiveMQ, IBM MQ, RabbitMQ, Apache Kafka. Мониторинг даёт для них асинхронные сквозные end-to-end трейсы для продюсеров и консьюмеров, метрики очередей, задержки и ошибки — и всё это без изменения кода, благодаря автоматической инструментации.
5. Мониторинг внутренних сервисов.
Корпоративные сервисы тоже не остаются без внимания:
Active Directory — мониторинг доступности и производительности
DNS — отслеживание резолвинга и задержек
Сертификаты — контроль сроков истечения и оповещения заранее
Платформы виртуализации — мониторинг хостов, виртуальных машин и их ресурсов
Эти сервисы редко попадают в зону внимания APM, но именно они отвечают за работу «внутренней кухни» компании: истёкший сертификат или деградировавший DNS кладут приложения ничуть не хуже, чем баг в коде.
Сводим всё вместе: как observability обогащает APM
Конкретный пример. Пользователь жалуется на медленную работу.
С чистым APM мы видим, что какой-то запрос выполняется долго. Копаем трейс, видим вызов к БД, но не знаем, почему БД тормозит — возможно, из-за сетевой задержки, возможно, из-за блокировки, или вообще, из-за перегрузки самого хоста.
С полноценной observability картина полная:
Трейс — какой именно запрос, какой метод, какие параметры
Логи — бизнес-контекст запроса: возможно, там была аномалия
Метрики БД — количество активных соединений, блокировки, I/O
Состояние сети — загрузка интерфейса маршрутизатора между приложением и БД
Аппаратные метрики — загрузка CPU на хосте с БД
Ключ-АСТРОМ автоматически коррелирует эти данные, анализирует и показывает корневую причину — без гипотез понятно, что нужно чинить.
Заключение
Современный мониторинг — это гораздо больше, чем APM-инструмент. Это платформа, которая объединяет метрики, трейсы, логи, события, бизнес-данные и инфраструктурный мониторинг в едином контексте. С расширениями закрываются практически любые сценарии наблюдения — от сетевого оборудования до кастомных бизнес-приложений.
Расскажите, какие сценарии observability сверх APM используете вы? С чего начинали и что дало наибольший эффект? «Растягивали» ли вы мониторинг на соседние подразделения: бизнес, аналитику, безопасность?