APM (мониторинг производительности приложений)

Обзор

Когда приложение состоит из нескольких сервисов, найти причину замедления или ошибки бывает непросто. Запрос пользователя проходит через цепочку вызовов, и непонятно, на каком именно участке возникает проблема.

APM (мониторинг производительности приложений) решает эту задачу. Платформа собирает данные о каждом запросе, автоматически анализирует время ответа и ошибки по сервисам и показывает, где именно возникает проблема.

Чем APM отличается от просмотра трассировок и логов по отдельности

Платформа позволяет просматривать трассировки и логи и без APM — через раздел «Обзор данных», где вы пишете запросы вручную и получаете сырые данные. Однако для этого нужно заранее знать, что именно искать.

APM работает иначе: платформа сама анализирует все поступающие трассировки, рассчитывает показатели по каждому сервису и показывает общую картину. Вместо того чтобы перебирать отдельные трассировки, вы сразу видите, какие сервисы работают штатно, а у каких возникли проблемы. Оба подхода дополняют друг друга: APM показывает общую картину и ведёт к проблемному запросу, а ручной просмотр данных позволяет детально исследовать конкретную ситуацию.

Что вы получаете

• Сводка по всем сервисам — какой сервис работает штатно, у какого увеличилось время ответа, где возникают ошибки.
• Карта зависимостей — какие сервисы взаимодействуют между собой, на каком участке цепочки возникает проблема.
• Детальный разбор запроса — путь конкретного запроса через все сервисы с временем каждого шага.
• Связь с логами — от проблемного запроса к логам конкретного сервиса в момент ошибки.
• Настраиваемые пороги — вы определяете, что для вашего сервиса считается допустимым временем ответа.

Функция находится в стадии alpha.

Быстрый старт

1. Убедитесь, что APM включён администратором.
2. Откройте проект в платформе и перейдите в раздел Инструкции.
3. Выберите способ подключения:
   • Если ваше приложение ещё не отправляет данные трассировки, выберите «Инструментация приложений» и следуйте пошаговой инструкции для вашего языка программирования. Адрес платформы и токен подставятся автоматически.
   • Если у вас уже настроен сбор трассировок (например, через OpenTelemetry Collector), выберите «Настройка стриминга трейсов» и укажите адрес платформы в качестве получателя.
4. Запустите приложение и выполните несколько запросов к нему.
5. Откройте раздел APM в боковом меню проекта. Через одну-две минуты ваш сервис появится в списке.

Если сервис не появился, обратитесь к разделу Решение проблем.

Основные понятия

Трассировка

Представьте, что пользователь нажимает кнопку «Оплатить». Запрос проходит через API-шлюз, сервис заказов, сервис платежей и базу данных. Трассировка — это запись всего этого пути: какие сервисы участвовали в обработке запроса, сколько времени занял каждый шаг, где произошла ошибка.

В разделе APM вы можете найти нужную трассировку по имени сервиса, времени, статусу или другим параметрам и просмотреть её в виде временной диаграммы — последовательности шагов с их длительностью.

Операция

Один шаг внутри трассировки. Например: обработка HTTP-запроса, вызов другого сервиса или SQL-запрос к базе данных. Каждая операция содержит имя, длительность, статус и дополнительные атрибуты.

Индекс производительности (Apdex)

Оценка того, насколько пользователи довольны скоростью работы сервиса. Выражается числом от 0 до 1: значение 0,95 означает, что подавляющее большинство запросов обработано за приемлемое время.

Вы сами определяете, какое время ответа считать приемлемым. По умолчанию это 512 миллисекунд. Запросы, уложившиеся в этот порог, считаются быстрыми; запросы, превысившие четырёхкратный порог, считаются неприемлемо долгими.

В обзоре сервисов индекс производительности отображается в отдельном столбце. Вы можете изменить порог для каждого сервиса — например, для фонового сервиса обработки отчётов допустимое время ответа может быть больше, чем для API пользовательского интерфейса.

Состояние здоровья сервиса

Платформа автоматически определяет состояние каждого сервиса на основе его метрик:

Пороги можно изменить для каждого сервиса индивидуально (см. Как задать допустимое время ответа для сервиса).

Виртуальные зависимости

Не все компоненты системы отправляют трассировки. Базы данных, кеши и очереди сообщений обычно не инструментированы, но платформа распознаёт их автоматически по атрибутам исходящих вызовов из ваших сервисов. На карте зависимостей такие компоненты отображаются как отдельные узлы с соответствующим типом: база данных, кеш, очередь или внешний сервис.

Область видимости

Если в платформу отправляют данные несколько кластеров Kubernetes или несколько пространств имён (namespace), вы можете сфокусировать обзор на конкретном кластере и пространстве имён Kubernetes с помощью переключателя в верхней части страницы. Сервисы, работающие вне Kubernetes, отображаются в отдельной группе.

Подключение приложений

Новое приложение

Если ваше приложение ещё не отправляет данные трассировки, воспользуйтесь встроенными инструкциями:

1. Откройте проект в платформе и перейдите в раздел Инструкции.
2. Выберите «Инструментация приложений».
3. Выберите язык программирования. Поддерживаются: Java, Python, Node.js, Go, .NET, Ruby, PHP, C++, Elixir, Rust.
4. Следуйте пошаговой инструкции. Адрес платформы и токен авторизации подставляются автоматически. Доступны варианты установки для виртуальных машин, Kubernetes, Docker и Windows.

Инструкции включают проверку работоспособности и раздел устранения неполадок для каждого языка.

Существующий сбор трассировок

Если у вас уже настроен сбор трассировок (OpenTelemetry Collector, Jaeger, Zipkin или Grafana Alloy), достаточно направить данные в платформу. При использовании инструментов, отличных от OpenTelemetry, убедитесь, что трассировки содержат необходимые атрибуты — подробнее в разделе Какие данные нужны для полноценной работы.

• Адрес: https://api.<домен вашей установки>
• Авторизация: заголовок Authorization: Bearer <токен>. Токен должен иметь право «Запись трассировки». Создать токен можно в настройках проекта в разделе «API-токены».

Поддерживаемые протоколы:

Для подробных инструкций по настройке OpenTelemetry Collector, Jaeger и Alloy откройте раздел Инструкции в проекте и выберите «Настройка стриминга трейсов» или «OpenTelemetry Collector».

Какие данные нужны для полноценной работы

APM анализирует атрибуты операций внутри трассировок. Для корректной работы каждой функции необходим определённый набор атрибутов.

Обязательные атрибуты:

Рекомендуемые атрибуты:

Если обязательные атрибуты отсутствуют, трассировки будут доступны в поиске (раздел «Трассировки»), но обзор сервисов и карта зависимостей будут пустыми.

При использовании инструментов, отличных от OpenTelemetry (Jaeger SDK, Zipkin), убедитесь, что ваши трассировки содержат перечисленные атрибуты. Jaeger и Zipkin поддерживают span.kind и имя сервиса, но атрибуты Kubernetes и типы зависимостей могут отсутствовать.

Подключение логов

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

Для работы этой связи логи должны содержать идентификатор трассировки (trace_id). При использовании OpenTelemetry SDK идентификатор добавляется автоматически.

Для настройки отправки логов перейдите в раздел Инструкции и выберите подходящий способ (Vector, Promtail или OpenTelemetry Collector).

Работа с APM

Как найти сервис с увеличенным временем ответа

1. Откройте раздел APM в боковом меню проекта. На странице «Обзор» отображается таблица всех сервисов с ключевыми показателями: количество запросов в секунду, процент ошибок, время ответа (медиана и перцентили), индекс производительности.
2. При необходимости выберите нужный кластер и пространство имён в переключателе области видимости.
3. Включите фильтр «Только проблемные» — в таблице останутся сервисы в состоянии «Предупреждение» или «Критическое».
4. Таблица по умолчанию отсортирована по степени влияния на пользователей: сервисы с высоким трафиком и низким индексом производительности отображаются первыми.
5. Нажмите на имя сервиса, чтобы перейти к его детальной информации.

Как определить причину замедления конкретного запроса

1. В детальной информации о сервисе найдите раздел «Ключевые операции». Операции с высоким временем ответа или низким индексом производительности указывают на проблемные участки.
2. Нажмите «Открыть трассировки» — откроется поиск трассировок с фильтром по выбранному сервису.
3. Выберите трассировку с большой длительностью и откройте её.
4. На временной диаграмме вы увидите все операции запроса в виде дерева. Каждая полоска — одна операция с её длительностью. Раздел «Анализ задержки» показывает собственное время каждой операции (без учёта дочерних вызовов) и выделяет самую затратную.

Как найти причину ошибок

1. В обзоре сервисов найдите сервис с высокой долей ошибок.
2. Откройте детальную информацию о сервисе и найдите операцию с ошибками.
3. Нажмите «Открыть трассировки» и примените фильтр по статусу «ошибка».
4. Откройте трассировку с ошибкой. На вкладке «Атрибуты» будет информация об ошибке, на вкладке «События» — стек вызовов (если инструментация его записала).
5. При подключённых логах нажмите «Логи», чтобы увидеть записи журнала сервиса в момент выполнения этого запроса.

Как посмотреть, от каких сервисов зависит мой сервис

1. Откройте раздел APM → Карта. На ней отображаются все обнаруженные сервисы и связи между ними.
2. Узлы — сервисы. Рёбра — вызовы между ними. Базы данных, кеши, очереди и внешние сервисы показаны как отдельные узлы с соответствующими обозначениями.
3. Нажмите на узел, чтобы увидеть показатели сервиса. Нажмите на ребро, чтобы увидеть показатели связи: количество вызовов в секунду, процент ошибок, время ответа.
4. В детальной информации о сервисе кнопка «Показать на карте» фокусирует карту на выбранном сервисе и его окружении.

Как задать допустимое время ответа для сервиса

По умолчанию все сервисы используют одинаковые пороги. Если для конкретного сервиса стандартные значения не подходят (например, фоновый сервис обработки отчётов может отвечать дольше, чем API):

1. Откройте детальную информацию о сервисе.
2. Нажмите «Пороги сервиса».
3. Измените нужные значения:

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

Допустимое время ответа выбирается из фиксированного набора значений: 32, 64, 128, 256, 512, 1024, 2048 или 4096 миллисекунд.

Как найти конкретную трассировку

Раздел APM → Трассировки предоставляет два способа поиска:

• Конструктор фильтров — визуальный подбор параметров: имя сервиса, имя операции, статус, длительность, произвольные атрибуты.
• Язык запросов TraceQL — для сложных запросов с комбинацией условий.

Примеры запросов на TraceQL:

{ resource.service.name = "checkout-api" && status = error }
{ duration > 1s }
{ span.http.status_code >= 500 }

Также доступен быстрый переход к трассировке по её идентификатору.

В детальной информации о трассировке:

• Временная диаграмма — дерево всех операций запроса с их длительностью.
• Пламенная диаграмма — визуализация вложенности и пропорций.
• Анализ задержки — собственное время каждой операции и выделение наиболее затратной.
• Вкладки «Атрибуты», «События», «Связи» — дополнительная информация об операции.

Как посмотреть логи для проблемного запроса

Раздел доступен, если в платформу отправляются логи.

В разделе APM → Логи доступен поиск логов двумя способами:

• Конструктор фильтров — подбор параметров: сервис, уровень важности, пространство имён, текст сообщения.
• Язык запросов LogQL — для сложных условий фильтрации.

Для перехода от трассировки к логам: в детальной информации о трассировке нажмите «Логи» — откроется журнал записей, отфильтрованных по идентификатору этой трассировки.

Для перехода от лога к трассировке: в строке журнала нажмите «Просмотр трассировки» — откроется детальная информация о соответствующем запросе.

Решение проблем

Сервис не появляется в обзоре

Если трассировки вашего приложения доступны в поиске (раздел «Трассировки»), но сервис не отображается в обзоре, возможны следующие причины:

1. Отсутствуют серверные операции. В обзоре отображаются только сервисы, которые обрабатывают входящие запросы (HTTP, gRPC, сообщения из очередей). Если приложение только вызывает другие сервисы, но не принимает входящих вызовов, оно не попадёт в обзор. Убедитесь, что инструментация создаёт серверные операции для обработчиков входящих запросов.

2. Выбрана другая область видимости. Переключатель области видимости в верхней части страницы фильтрует сервисы по кластеру и пространству имён. Убедитесь, что выбрана область, соответствующая вашему приложению.

3. Прошло недостаточно времени. Данные появляются в обзоре через одну-две минуты после первой трассировки.

Платформа пишет «Данные не поступают»

Это сообщение означает, что платформа не получает данных трассировки для текущего проекта. Проверьте:

• Приложение запущено и инструментация настроена. Перейдите в раздел Инструкции для проверки конфигурации.
• Токен авторизации имеет право «Запись трассировки».
• Адрес платформы и протокол указаны правильно.

На карте нет зависимостей

Карта зависимостей строится на основе пар «вызывающий — вызываемый». Если карта пуста:

• Убедитесь, что исходящие вызовы (HTTP-клиенты, драйверы баз данных, клиенты очередей) инструментированы. При использовании автоинструментации OpenTelemetry это происходит автоматически.

Если на карте отображаются узлы с IP-адресами вместо осмысленных имён — инструментация не передаёт атрибуты типа зависимости. Добавьте инструментацию для соответствующих библиотек.

Сервис отображается с двумя разными именами

Разные экземпляры одного сервиса передают разное имя в данных трассировки. Убедитесь, что переменная окружения OTEL_SERVICE_NAME имеет одинаковое значение во всех экземплярах и средах развёртывания.

Часть спанов трассировки отсутствует

В детальном просмотре трассировки появляется значок предупреждения «Отсутствующие спаны», если у некоторых операций родительский спан не найден внутри трассировки. Это означает, что часть данных трассировки не доехала до платформы или была отброшена по пути.

Возможные причины:

• Сэмплирование. SDK или OpenTelemetry Collector настроены отбрасывать часть спанов (head sampling, tail sampling, probabilistic). Если разные сервисы используют разные политики сэмплирования, в трассировке окажется только часть пути запроса.
• Сбои или перезагрузки коллектора. Спаны могут теряться, если коллектор не успел отправить накопленный батч до перезапуска или превысил лимит памяти.
• Истечение срока хранения. Если трассировка старше срока хранения, часть её спанов уже удалена в платформе.

Что проверить:

1. Согласованность сэмплирования: одинаковые правила во всех инструментированных сервисах (или используется только один уровень сэмплирования — в SDK либо в коллекторе, но не в обоих).
2. Стабильность OpenTelemetry Collector: нет частых перезапусков, есть запас по памяти, очередь экспортёров не переполняется.
3. Возраст трассировки: если она старше срока хранения, отсутствие спанов — ожидаемое поведение.

Как быстро появятся данные после подключения

Данные в обзоре сервисов появляются через одну-две минуты после того, как платформа получит первую трассировку от вашего приложения.

Ошибки при отправке данных

Сообщения rate_limited, trace_too_large или live_traces_exceeded означают, что превышены ограничения проекта. Для увеличения ограничений обратитесь к администратору или измените значения в настройках проекта (см. Лимиты трейсов).

Не работает подключение по gRPC

На некоторых конфигурациях сетевого окружения подключение по gRPC может не работать. В этом случае используйте протокол OTLP по HTTP: установите переменную окружения OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf.

Не отображаются логи

Если раздел «Логи» в APM недоступен или пуст, проверьте:

• Хранилище логов включено на уровне платформы.
• Приложение отправляет логи в платформу (см. раздел Инструкции → настройка стриминга логов).
• Логи содержат идентификатор трассировки для связывания с запросами.