Трассировки

Что такое транзакционны мониторинг

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

Транзакционный мониторинг — это подход к наблюдению за выполнением операций в распределённой системе, при котором отслеживается полный путь запроса через все сервисы, компоненты и инфраструктурные уровни. Каждая операция представлена в виде трассы (trace), состоящей из отдельных шагов (spans), отражающих действия внутри сервисов. Такой функционал мониторинга позволяет точно определить, где возникают задержки, ошибки или отклонения в производительности и отслеживать активность пользователей.

Компоненты трейсинга

Trace (трейс)

Trace — представляет собой уникальную запись о выполнении одной транзакции (например, HTTP-запроса пользователя), проходящей через один или несколько сервисов. Каждая трасса имеет уникальный идентификатор (trace_id) и состоит из спанов, отражающих шаги выполнения.

../../_images/example_trace.png

Span (Спан)

Span — это атомарное действие внутри запроса, например:

  • Обработка HTTP-запроса

  • Вызов метода

  • SQL-запрос

  • Публикация в очередь и др.

Каждый спан имеет уникальный SpanID и ссылается на родительский спан (ParentSpanID), что формирует дерево вызовов.

../../_images/2025-07-10175211.png

У каждого спана есть:

  • span_id — уникальный идентификатор

  • parent_span_id — ID родительского спана

  • Временные метки начала и окончания

  • Набор атрибутов (метаданные) Атрибуты (или метаданные) — это дополнительные ключ-значения, которые описывают свойства операции внутри спана. Они помогают понять контекст выполнения, отфильтровать или сгруппировать трейсы при анализе.

../../_images/20250710175506.png

Роли спанов (Kind)

  • Server — спан на входящей стороне запроса

  • Client — спан при исходящем вызове

  • Internal — используется для обозначения внутренних операций внутри одного сервиса без сетевого взаимодействия

Визуализация и анализ

Для визуализации и анализа распределённых трейсов в системе используется Grafana. При помощь данного инструмента визуализации можно:

  • просматривать дерево спанов в рамках одного запроса (trace)

  • анализировать длительность каждого этапа,

  • выявлять ошибки и точки задержки,

  • строить дашборды для мониторинга ошибок и производительности.

../../_images/20250710180015.png

Для просмотра трейсов используются режим Explore. В данном режиме пользователь может осуществлять мониторинг трейсов, просматривать дерево спанов, выставлять необходимые фильтры по атрибутам трейса и спанов.

При необходимости вы можете построить собственный дашборд на основе собранных трейсов

Настройка фильтров и поиск трейсов

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

Для начала необходимо выставить временной диапазон, за который вы хотите отобразить данные о трейсах. Настройка временного промежутка осуществился в правом верхнем углу системы. Обратите внимание: для корректной работы фильтрации необходимо убедиться, что в параметре Time установлено значение Time = Within dashboard time range

../../_images/2025-07-11102326.png

Для корректной работы отображения трейсов необходимо убедиться, что в разделе Columns включена опция Use OTel

Для поиска трейсов по содержащийся в них информации воспользуйтесь фильтрами:

../../_images/20250711103857.png

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

Поле фильтра

Назначение

TraceId

Поиск конкретного трейса по его идентификатору

SpanId

Поиск отдельного спана

SpanName

Название выполняемой операции или путь запроса

SpanKind

Тип спана: входящий (Server), исходящий (Client), внутренний (Internal)

ServiceName

Имя сервиса, сгенерировавшего трейс (значение из ResourceAttributes[])

Duration

Длительность выполнения операции (в микросекундах)

SpanAttributes[]

Гибкий набор атрибутов, описывающих конкретную операцию: метод, код ответа, параметры запроса и т.п. Используется для детальной фильтрации по содержимому спана. Состав атрибутов зависит от типа действия и инструмента сбора.

ResourceAttributes[]

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

StatusCode

Обобщённый статус выполнения спана

Фильтрация по атрибутам спанов (SpanAttributes) и ресурсов (ResourceAttributes) предоставляет пользователю гибкий инструмент для поиска и анализа трейсов. Эти поля содержат структурированную информацию о контексте операции и окружении, в котором она выполнялась.

  • SpanAttributes содержат информацию о самой операции — например, параметры HTTP-запроса, статус ответа, используемый протокол или тип действия. Эти атрибуты позволяют фильтровать по содержимому спана: находить ошибки, выделять отдельные методы, запросы или сообщения.

  • ResourceAttributes описывают окружение, в котором был собран трейс: имя сервиса, хост, язык приложения, используемый агент. Фильтрация по этим полям помогает анализировать данные по конкретным сервисам, хостам или средам выполнения.

Пример: Ниже на скриншоте преведён пример фильтрации трейсов в которых содержется ошибка 401 Фильрация установлена следующим образом:

monitoring/traces/2025-07-111046303.png

Статус-код http запроса находиться в атрибутах спана SpanAttributes[]. Внутри этого набора выделяется значение http.response.status_code, которому в данном случае соответствует 401, указывающее на ошибку 401.

Архитектура трейсинга в системе

Архитектура

Сбор трассировочных данных осуществляется при помощи экспортера с поддержкой технологии eBPF автоматически перехватывающего запросы на уровне ядра без вмешательства в код, либо через OpenTelemetry SDK. Оба источника данных (Beyla и SDK) экспортируют трейсы в OpenTelemetry Collector по протоколу OTLP. Коллектор обрабатывает входящие данные и сохраняет трейсы в базу данных ClickHouse. База данных ClickHouse выступает в роли основного хранилища трейсов. Для визуализации и анализа трейсов используется Grafana. ClickHouse в данном случае выступает источником данных.

Сбор трейсов в системе «Астра мониторинг»

Система предполагает сбор трейсов реализуется двумя способами:

  1. Автоматический сбор трейсов при помощи eBPF экспортера. Экспортер с поддержкой технологии eBPF работает на уровне ядра Linux и автоматически собирает данные о входящих и исходящих HTTP/gRPC-запросах без необходимости изменения приложений. Он способен:

  • определять начало и конец запроса на основе сетевых операций,

  • извлекать и передавать контекст трассировки из заголовков (traceparent, baggage),

  • формировать спаны с типами Server и Client,

  • экспортировать трейсы напрямую в бекенд по протоколу OTLP (HTTP/gRPC).

Данный метод позволяет провести быструю настройку сбора трейсов в системе не прибегая к изменением в кодовой базе приложения либо покрыть функционалом транзакционного мониторинга области инфраструктуру, в которые невозможно встроить SDK

  1. Ручной сбор при помощи OpenTelemetry SDK В сервисах, где требуется более точный контроль над структурой и содержимым трейсов, используется OpenTelemetry SDK. Такой подход позволяет:

  • вручную создавать иерархию спанов (parent / child),

  • добавлять пользовательские атрибуты и события (например, user_id, order_id, sql.query),

  • передавать контекст между асинхронными вызовами,

  • обеспечивать полный охват бизнес-логики, недоступный для eBPF. SDK-инструментация используется в сервисах, обрабатывающих критически важные операции или взаимодействующих с нестандартными протоколами

OpenTelemetry SDK официально поддерживает экспорт трейсов в OTLP Collector в следующих языках программирования:

  • Go

  • Java

  • Python

  • JavaScript / TypeScript (Node.js)

  • .NET (C#)

  • C++

  • Ruby

  • PHP

  • Erlang / Elixir

Хранение трейсиов в системе «Астра мониторинг»

Astra Monitoring использует высокопроизводительную масштабируемую базу данных ClickHouse для хранения трейсов

Структура хранения

Трейсы сохраняются в виде таблиц с разделением по типам данных Основные поля:

  • Timestamp - Время начала спана

  • TraceId - Уникальный идентификатор всей трассы

  • SpanId - Уникальный идентификатор текущего спана

  • ParentSpanId - Идентификатор родительского спана (при наличии)

  • SpanName - Название операции (например, POST /api)

  • SpanKind - Тип спана (Server, Client, Internal и др.)

  • Duration - Время выполнения операции в микросекундах

  • StatusCode - Статус выполнения

  • StatusMessage - Дополнительное текстовое описание статуса (может быть пустым) Атрибуты в структуре хранения трейсов представлены в виде пар ключ-значение и условно делятся на два типа:

  • SpanAttributes — Атрибуты конкретной операцию (например, HTTP-запрос, SQL-запрос, вызов RPC)

  • ResourceAttributes — описывают окружение, в котором выполняется спан (сервер, контейнер, агент) Набор атрибутов не является фиксированным. Он может отличаться между различными спанами в зависимости от типа выполняемой операции. Атрибуты, такие как SpanAttributes и ResourceAttributes, хранятся в ClickHouse в виде два параллельных массива: Key и Value. Пример представления SpanAttributes:

SpanAttributes.Key

SpanAttributes.Value

["http.request.method", "http.response.code"]

["POST", "404"]

Пример представления ResourceAttributes:

ResourceAttributes.Key

ResourceAttributes.Value

["host.id", "os.type", "service.name"]

["vm123", "linux", "my_service"]