Tracing: что это такое и в каких случаях его применять для отладки производительности приложений

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

Для целей отладки производительности приложений, в том числе развернутых в виде микросервисов, можно выделить два метода - использование трассировки приложений (tracing) или профилирование (profiling). Эти два подхода играют важную роль в анализе работы цифровых сервисов, но предназначены для разных целей и сценариев.

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

Tracing (трассировка) — это метод наблюдения за выполнением операций в программном обеспечении, который помогает отслеживать путь запросов как внутри системы, так и между различными ее компонентами и внешними сервисами. Трассировка предоставляет детальную видимость о том, как обрабатываются вызовы, где возникают задержки и ошибки.Чтобы лучше понять, что такое Tracing, давайте рассмотрим его ключевые элементы.

Ключевые элементы Tracing

1. Trace – полный путь прохождения запроса через систему, в том числе распределенную. Содержит набор связанных span'ов, представляющих все шаги обработки запроса.

2. Span – отдельная операция или шаг внутри trace, например, вызов базы данных или HTTP-запрос к микросервису. Включает в себя уникальный идентификатор (Span ID), временные метки (начало и конец выполнения), метки (tags) и логи (logs) для детальной информации.

3. Parent-Child Relationship – иерархическая связь между span'ами, показывающая последовательность выполнения операций (например, вызов одного микросервиса другим).

4. Идентификаторы

• Trace ID – уникальный идентификатор, связывающий все span'ы в рамках одного trace (запроса).

• Span ID – уникальный идентификатор конкретного span (шага операции).

• Parent Span ID – идентификатор родительского span (для отображения вложенности).

5. Временные метки (Timestamps) – указывают время начала и завершения span'а, что помогает измерять задержки и длительность.

• Start Time – время начала выполнения span.

• End Time – время завершения выполнения span.

• Duration – длительность выполнения span (рассчитывается на основе start и end time).

6. Метки (Tags) – это статические или динамические ключ-значения, описывающие контекст span'а. Часто используются для фильтрации и поиска операций.

Пример: http.method=GET, db.statement=SELECT * FROM users.

7. Пользовательские данные – дополнительные поля, специфичные для приложения и содержащие информацию о пользователе.

Пример: user.id=12345.

8. Состояние операции – статус span (например, status=success или status=error), HTTP или GRPC статус-коды (http.status_code=200).

9. Логи, записанные в процессе выполнения операции – это набор событий или сообщений, записанных во время исполнения span, которые дают дополнительную информацию о состоянии, ошибках или ключевых этапах. Они помогают понять, что именно происходило во время выполнения определенного шага запроса.

Пример: error=true, exception="TimeoutException: database query exceeded limit", execution_time=45ms, result_size=128KB.

Работу трейсинга можно условно разбить на следующие этапы:

1 этап. Идентификация вызова

Генерируется уникальный Trace ID, идентифицирующий всю транзакцию. Он сохраняется на протяжении всего пути выполнения вызова.Далее создается первый Span ID, представляющий начальный этап обработки вызова.

2 этап. Запись данных начального этапа

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

3 этап. Генерация Span ID для следующих этапов

В момент, когда вызов передается к следующим по цепочке компонентам (например, к контейнеру), создается новый Span ID для каждого такого этапа. Span ID связывается с Trace ID и происходит запись родительского идентификатора (Parent Span ID) для построения иерархии вызовов.

4 этап. Захват данных о контексте

На этом этапе происходит идентификация всех компонентов участвующих в выполнении вызова. Фиксируются IP-адреса, тип операции, названия хостов, сервисов, микросервисов и остальных элементов, которые участвуют в вызове и другие метаданные (например, User ID).

5 этап. Обработка ошибок

Если на каком-либо этапе выполнения возникает ошибка, Trace ID сохраняет о ней информацию – тип ошибки (например, timeout, connection error), сообщение, статус код и другие данные.

6 этап. Завершение обработки

Все этапы выполнения объединяются под одним Trace ID. Полный путь транзакции (с родительскими и дочерними Spans) фиксируется в виде иерархии или графа.

7 этап. Визуализация транзакции

Данные транзакции визуализируются в виде дерева или временной шкалы в инструменте трассировки (Proto Observability Platform, Jaeger, Zipkin).

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

1. Определение временных задержек на каждом этапе операции

Что показывает Tracing:

• Время обработки запросов каждым микросервисом, базой данных, очередью сообщений, внешним сервисом.

• Время ожидания между вызовами (например, задержки в сети).

Пример:

Общая длительность транзакции у пользователя 714 мс.

Web-Frontend (117 мс) → nginx-proxy (1 мс) → shipping (596 мс) из которых запрос в MySQL 587 мс. Трассировка показывает, что 82% времени обработки уходит на вызов MySQL.

2. Выявление проблем с вызовами внешних API

Что показывает Tracing:

• Длительность и результат вызовов внешних сервисов (например, API сторонних поставщиков).

• Ошибки, возвращаемые внешними сервисами.

Пример:

Сервис Payment bank вызывает внешний API (paypal.com) для проведения платежа, и трассировка показывает задержки до 0.8 секунд. Это говорит о проблеме на стороне внешнего API или в логике повторных запросов (retries).

3. Поиск ошибок или исключений

Что показывает Tracing:

• Какие этапы цепочки завершились с ошибкой.

• Контекст выполнения ошибки: какой сервис, какой вызов, какой статус (например, HTTP 500).

Пример:

Вызов из сервиса Payment bank к сервису User завершается ошибкой с кодом 500, что видно из трейса транзакции. Ошибка в сервисе User связана с истощение пула соединений базы данных MongoDB, что указывает на проблему производительности базы данных.

4. Выявление потерянных или некорректных запросов

Что показывает Tracing:

• Запросы, которые не дошли до нужного сервиса или завершились некорректно.

• Нарушения порядка передачи данных между сервисами.

Пример:

API Gateway передает запросы в Data Aggregation Service. Трассировка показывает, что часть запросов теряется из-за сетевых ошибок.

5. Определение неэффективного распределения нагрузки

Что показывает Tracing:

• Увеличенные задержки в пиковое время из-за перегрузки сервисов.• Неравномерное распределение нагрузки между инстансами микросервисов.

Пример:

Трассировка показывает, что один из инстансов Data Aggregation Service обрабатывает 90% запросов, в то время как другие практически не загружены.

6. Поиск неоптимальных цепочек вызовов

Что показывает Tracing:

• Избыточные вызовы между сервисами.

• Лишние или дублирующиеся запросы.

Пример:

Service A вызывает Service B, который делает три идентичных запроса к базе данных, которые видны благодаря трассировке.

7. Выявление проблем в конфигурации

Что показывает Tracing:

• Ошибки, вызванные некорректными параметрами, такими как тайм-ауты, размеры пулов соединений или лимиты на запросы.

Пример:

Трассировка показывает, что Service C выдает ошибки rate limit exceeded, которые говорят о необходимости пересмотреть конфигурацию лимитов или настроить автоскейлинг.

8. Определение проблем масштабирования

Что показывает Tracing:

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

Пример:

При увеличении числа запросов задержка на Service A вырастает до 3 секунд. Трейсинг показывает, что узкое место — пул соединений к базе данных. Это указывает на необходимость увеличения пула соединений или масштабирования сервиса.

9. Выявление проблем с взаимозависимостями

Что показывает Tracing:

• Циклические зависимости между микросервисами, которые могут приводить к взаимоблокировкам или увеличению задержек.

Пример:

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

Трассировка является важным инструментом для обеспечения наблюдаемости и диагностики как монолитных, так и микросервисных приложений. Она позволяет разработчикам и DevOps-инженерам улучшать производительность цифровой системы и пользовательский опыт благодаря отслеживанию полного пути транзакции от frontend к backend с выявлением узких мест и причин ошибок.