Трасування: що це, принципи та збір даних

Що таке трасування в моніторингу

Трасування — це метод розподіленого спостереження, при якому кожен вхідний запит відстежується через всі сервіси та компоненти системи. На відміну від метрик, які показують агреговані значення (середній час відповіді, кількість помилок), трасування зберігає повний контекст одного конкретного запиту.

Кожен крок обробки — виклик бази даних, HTTP-запит до іншого мікросервісу, виконання фонового завдання — фіксується як окрема одиниця з міткою часу, статусом та атрибутами. За даними Google Dapper (оригінальна публікація 2010 року), трасування дозволяє локалізувати затримки в розподілених системах з точністю до одного виклику.

Трасування особливо важливе для мобільних застосунків, де бекенд складається з десятків мікросервісів. Дія користувача — наприклад, вхід в акаунт — може пройти через API Gateway, сервіс автентифікації, базу даних та Push-сервіс. Без трасування визначити, який саме компонент гальмує відповідь, практично неможливо.

Spans та traces: базова структура даних

Основна одиниця трасування — span. Кожен span представляє одну логічну операцію: HTTP-запит, SQL-запит, виклик gRPC, серіалізацію JSON. Span містить унікальний ідентифікатор, батьківський ідентифікатор, назву операції, час початку, тривалість, статус та набір атрибутів.

Ієрархія spans у trace

Всі spans, що належать до одного кореневого запиту, об'єднуються в trace. Кореневий span (root span) представляє точку входу — HTTP-запит від мобільного клієнта до API. Дочірні spans утворюють дерево, де кожен span посилається на батька через поле parent_span_id.

Тривалість trace дорівнює сумі тривалостей унікальних часових відрізків всіх spans. Якщо два дочірніх span виконуються паралельно, їх час не підсумовується — це критично важливо для правильного аналізу затримок, спричинених паралельними викликами мікросервісів.

Атрибути та події span

Кожен span може містити атрибути — пари ключ-значення з мета-інформацією: URL запиту, ID користувача, версія API, ім'я хоста. Атрибути використовуються для фільтрації та групування трас. Крім атрибутів, span підтримує події — часові мітки з текстовим описом, наприклад "кеш-промах" або "повторна спроба з'єднання".

Як працює distributed tracing

Distributed tracing вирішує проблему зв'язування spans, які створюються в різних процесах та на різних машинах. Механізм заснований на контекстній передачі: при виклику сервісу B з сервісу A в вихідний запит додається заголовок з ідентифікатором поточного trace та батьківського span.

Стандартні протоколи передачі контексту — W3C Trace Context (заголовки traceparent та tracestate) та Zipkin B3 (заголовки X-B3-TraceId, X-B3-SpanId). W3C Trace Context прийнятий як стандарт консорціумом W3C у 2021 році та підтримується всіма основними провайдерами телеметрії.

При отриманні запиту сервіс B витягує trace_id з заголовка та створює дочірній span з цим trace_id. Таким чином, після завершення запиту всі spans з різних сервісів об'єднуються в один trace на стороні колектора. Для цього потрібно, щоб кожен сервіс був інструментований однією і тією ж бібліотекою трасування.

Контекстна передача в мікросервісах

У мобільній розробці контекстна передача охоплює не лише бекенд, але й клієнт-серверну взаємодію. Мобільний застосунок може надсилати trace_id в заголовку кожного API-запиту, дозволяючи пов'язати дію клієнта з серверною обробкою. OpenTelemetry SDK для iOS та Android підтримує автоматичне створення та передачу trace-контексту через HTTP-клієнти.

import io.opentelemetry.api.trace.Span
import io.opentelemetry.api.trace.Tracer
import io.opentelemetry.context.Context

class TracingInterceptor : Interceptor {
    private val tracer: Tracer = OpenTelemetry.getTracer("mobile-app")

    override fun intercept(chain: Interceptor.Chain): Response {
        val span = tracer.spanBuilder("HTTP POST /api/login")
            .setParent(Context.current())
            .startSpan()

        return chain.proceed(chain.request())
            .also { span.end() }
    }
}

Представлений перехоплювач на Kotlin створює span для кожного HTTP-запиту до сервера. Батьківський контекст передається з коду, що викликає, через Context.current(), що дозволяє пов'язати клієнтське трасування з серверним.

Впровадження трасування через OpenTelemetry

OpenTelemetry — стандарт де-факто для збору трасувальних даних. Він надає єдиний API для генерації spans, автоматичну інструментацію популярних бібліотек та гнучкий механізм експорту даних в різні бекенди: Jaeger, Zipkin, Grafana Tempo, Datadog, New Relic.

Автоматична інструментація

OpenTelemetry підтримує автоматичне створення spans для популярних фреймворків: Spring Boot, Ktor, Flask, Express, gRPC. Розробнику достатньо додати залежність в проєкт, і бібліотека самостійно перехоплює вхідні та вихідні запити. Auto-instrumentation для Java використовує javaagent, який модифікує байт-код на льоту без зміни вихідного коду.

Для мобільних платформ OpenTelemetry надає Swift SDK та Kotlin SDK. Вони автоматично створюють spans для мережевих запитів (URLSession, OkHttp), роботи з базою даних (CoreData, Room) та фонових завдань. Розробник може додавати кастомні spans для бізнес-логіки.

Експорт даних

Зібрані spans надсилаються до колектора через протокол OTLP (OpenTelemetry Protocol). Колектор може буферизувати, фільтрувати та перенаправляти дані в одну або кілька систем зберігання. За даними документації OpenTelemetry, типова затримка від генерації span до його відображення в дашборді становить 2–5 секунд при використанні gRPC-експорту.

import OpenTelemetryApi
import OpenTelemetrySdk
import URLSessionInstrumentation

let instrumentation = URLSessionInstrumentation()
instrumentation.enable()

let tracer = OpenTelemetry.instance.tracerFactory
    .get("mobile-monitoring")

let span = tracer.spanBuilder("fetch-user-profile")
    .setAttribute(key: "user.id", value: userId)
    .startSpan()
span.end()

Код на Swift активує автоматичну інструментацію мережевого шару та створює кастомний span для операції отримання профілю користувача. Атрибут user.id дозволяє згодом фільтрувати траси за конкретним користувачем.

Стратегії семплювання трас

У високонавантажених системах трасувати кожен запит неможливо — це створює неприйнятне навантаження на сховище та мережу. Семплювання вирішує цю проблему, зберігаючи лише частину трас. Вибір стратегії безпосередньо впливає на повноту даних та вартість інфраструктури.

Head-based sampling

Рішення про збереження траси приймається в момент її створення — в кореневому span. Найпростіший і найпоширеніший підхід: фіксований відсоток запитів (наприклад, 5%) зберігається, решта відкидаються. Недолік — неможливо гарантувати, що рідкісні помилки будуть захоплені. Probability sampler в OpenTelemetry підтримує налаштування ймовірності від 0.0 до 1.0.

Tail-based sampling

Рішення відкладається до завершення всіх spans траси. Аналізатор оцінює, чи містить траса помилки, перевищення часу або цікаві атрибути, і тільки тоді зберігає її. Цей підхід вимагає буферизації всіх spans в колекторі, що збільшує споживання пам'яті. За даними Grafana Labs, tail-based sampling на 40–60% ефективніший за співвідношенням "ціна за корисні дані" в системах з рідкісними, але критичними помилками.

Відмінність трасування від логування

Логування фіксує окремі події з рівнем важливості (info, warn, error), але не пов'язує їх в контекст одного запиту. Трасування, навпаки, створює структуроване дерево операцій, що належать одному наскрізному запиту. На практиці ці два підходи не взаємовиключні, а доповнюють один одного.

Логи ефективні для детального аналізу конкретної помилки: розробник бачить точне повідомлення, стектрейс, значення змінних. Трасування дає відповідь на питання "чому запит виконується 5 секунд" — показує, який саме мікросервіс або виклик зайняв найбільше часу. За даними Honeycomb (2024), команди, що використовують трасування разом з логуванням, знаходять кореневу причину інцидентів у 2.3 рази швидше.

Сучасний підхід — observability — об'єднує трасування, метрики та логи в єдину систему. OpenTelemetry підтримує кореляцію між цими трьома сигналами: кожен span може містити посилання на пов'язані логи, а метрики можуть бути розмічені за trace_id для переходу до конкретних трас.