OpenTelemetry і eBPF для Python-мікросервісів: як працює distributed tracing і з чого почати

Мікросервісна архітектура приносить гнучкість і масштабованість, але водночас ускладнює відстеження запитів, що проходять через десятки сервісів. OpenTelemetry став стандартом де-факто для розподіленого трасування, і це не дивно. Платформа надає єдину, незалежну від постачальників бібліотеку інструментування з підтримкою як автоматичної, так і ручної інтеграції OpenTelemetry. Крім того, eBPF-моніторинг дозволяє командам DevOps і SRE отримувати миттєве розподілене трасування для мікросервісів Python без жодних змін у коді.

У цій статті ми розглянемо практичне налаштування трейсингу, автоматичний збір метрик у Python та інтеграцію обох технологій для ефективного моніторингу вашої системи.

Основні поняття: trace, span та context

Розподілене трасування (distributed tracing) показує повний шлях запиту через розподілену систему. Трейс (trace) представляє весь життєвий цикл запиту, який складається з одного або кількох спенів (spans). Кожен спен відображає окрему операцію всередині трейсу.

Спен інкапсулює кілька компонентів. Ім'я спену стисло ідентифікує виконувану роботу, наприклад, назву RPC-методу або функції. Кожен спен містить незмінний SpanContext, який однозначно ідентифікує його в системі.

Батьківський спен вказується у формі Span, SpanContext або null для кореневих спенів. Крім того, спен включає мітки часу початку та завершення, атрибути у вигляді пар ключ-значення, список подій з мітками часу, посилання на інші спени та статус виконання.

SpanContext містить Trace ID, який є спільним для всіх спенів у трейсі, унікальний Span ID, прапорці трейсу (trace flags) та стан трейсу (trace state) для передачі специфічної інформації постачальників. Коли сервіс А викликає сервіс Б, сервіс А передає trace ID та span ID як частину контексту. Сервіс Б використовує ці значення для створення нового спену, який належить до того ж трейсу, встановлюючи спен із сервісу А як батьківський.

Пропагація (propagation) є механізмом переміщення контексту між сервісами та процесами. Вона серіалізує або десеріалізує об'єкт контексту. OpenTelemetry використовує заголовки, визначені специфікацією W3C TraceContext. Таким чином, коли Frontend викликає Product Catalog через HTTP-ендпоінт, контекст передається через заголовок traceparent у форматі: <version>-<trace-id>-<parent-id>-<trace-flags>.

Переваги трейсингу у мікросервісній архітектурі

Пропагація контексту дозволяє трейсам будувати причинно-наслідкову інформацію про систему незалежно від того, де генеруються сигнали. Завдяки цьому два виклики до ендпоінту GET /product можна співвіднести з їхніми вихідними викликами у Frontend шляхом вилучення віддаленого контексту з заголовка traceparent.

Крім того, SDK OpenTelemetry автоматично корелює логи з трейсами, вставляючи контекст у записи логів. У випадку метрик пропагація контексту дозволяє агрегувати вимірювання в цьому контексті, отримуючи метрики для комбінацій викликів між сервісами.

Проблеми, які виникають без системи трейсингу

Без розподіленого трасування команди не можуть відстежити повний шлях запиту через мікросервіси Python. Відсутність спільного trace ID унеможливлює з'ясування, який сервіс спричинив затримку або помилку. Дебагінг перетворюється на перегляд логів десятків окремих сервісів без можливості побачити загальну картину взаємодії компонентів системи.

Встановлення бібліотек OpenTelemetry

Для початку роботи встановіть базові пакети OpenTelemetry через pip. Базовий SDK включає opentelemetry-api та opentelemetry-sdk, які надають фундаментальну функціональність для створення трейсів. Додатково встановіть opentelemetry-exporter-otlp для відправки даних до колектора. Якщо працюєте з конкретними фреймворками, використовуйте відповідні пакети інструментування: opentelemetry-instrumentation-django для Django, opentelemetry-instrumentation-fastapi для FastAPI або opentelemetry-instrumentation-flask для Flask. Альтернативний спосіб передбачає використання команди opentelemetry-bootstrap з прапорцем -a install, яка автоматично виявляє встановлені фреймворки та додає необхідні пакети інструментування.

Конфігурація TracerProvider та Resource

Resource є незмінним представленням спостережуваної сутності, для якої генерується телеметрія, вираженим через атрибути. SDK дозволяє створювати ресурси та асоціювати їх з телеметрією. Коли Resource асоціюється з TracerProvider, всі спени, створені будь-яким трейсером від цього провайдера, автоматично отримують цей ресурс. SDK витягує інформацію зі змінної середовища OTEL_RESOURCE_ATTRIBUTES та об'єднує її з ресурсом, наданим користувачем. Ця змінна приймає список пар ключ-значення у форматі key1=value1,key2=value2. Наприклад, для налаштування імені сервісу та ідентифікатора інстансу встановіть OTEL_RESOURCE_ATTRIBUTES="service.namespace=my-namespace,service.instance.id=my-instance".

Створення та експорт spans

BatchSpanProcessor буферизує спени та надсилає їх пакетами до експортера. Він приймає параметри max_export_batch_size (максимальний розмір пакета), export_timeout_millis (таймаут експорту) та schedule_delay_millis (затримка між відправками). OTLPSpanExporter відправляє дані до OpenTelemetry Collector через gRPC-протокол. Після налаштування провайдера викличте trace.set_tracer_provider, щоб встановити глобальний провайдер трейсингу.

Автоматична інструментація популярних фреймворків

FastAPI автоматично інструментується через FastAPIInstrumentor.instrument_app(app). Для Django достатньо викликати DjangoInstrumentor().instrument() після налаштування провайдера. Автоматична інструментація створює спени для HTTP-запитів з атрибутами маршруту, методу та статус-коду, а також запитів до баз даних з текстом запиту та тривалістю виконання.

Ручна інструментація критичних частин коду

Для бізнес-логіки отримайте трейсер через trace.get_tracer(name, "1.0.0"). Створюйте спени за допомогою конструкції with tracer.start_as_current_span("operation.name"). Додавайте атрибути через span.set_attribute("order.id", order_id), події через span.add_event("inventory.empty"), а помилки — через span.set_status(Status(StatusCode.ERROR)) і span.record_exception(e).

Що таке eBPF та як він працює

eBPF (extended Berkeley Packet Filter, розширений фільтр пакетів Берклі) дозволяє безпечно запускати код у ядрі Linux без написання модулів ядра або перезавантаження системи. Технологія була інтегрована в Linux у 2014 році, і з того часу її можливості значно зросли. eBPF працює через систему точок підключення (hook points), які відкривають «двері в ядро» щоразу, коли відбувається подія: виклик функції, отриманий пакет або системний виклик.

Програма eBPF являє собою невеликий, захищений фрагмент коду, який безпечно працює всередині ядра. Перед запуском кожна програма проходить верифікатор, який виконує статичний аналіз коду та відхиляє програми, що спричиняють збої або зависання. Верифікатор гарантує відсутність довільного доступу до пам'яті, циклів без обмежень та неможливість «повісити» ядро. Після перевірки програми компілюються за допомогою JIT-компіляції для досягнення високої продуктивності.

Переваги eBPF для Python-застосунків

OpenTelemetry eBPF Instrumentation (OBI) автоматично інспектує виконувані файли застосунків та мережевий рівень операційної системи, захоплюючи спени трейсів та RED-метрики (Rate, Errors, Duration) для HTTP/S та gRPC сервісів. Весь збір даних відбувається без модифікації коду застосунку або конфігурації.

OBI підтримує широкий спектр мов, зокрема Python, Java, .NET, Go, Ruby, Node.js, C, C++ та Rust. Інструментування відбувається через eBPF-зонди з мінімальними накладними витратами, зазвичай споживаючи менше 1-2% CPU. Крім того, OBI автоматично збагачує JSON-логи контекстом трейсів для кореляції.

Налаштування eBPF-агента для збору метрик у Python

OBI вимагає Linux з ядром версії 5.8+ або RHEL-сімейства 4.18+ з необхідними eBPF-бекпортами. Підтримувані архітектури процесорів включають amd64 та arm64. Для роботи потрібні root-привілеї або Linux capabilities, які вимагаються увімкненими функціями OBI.

Інтеграція eBPF з OpenTelemetry Collector

OBI може працювати як компонент-приймач (receiver) OpenTelemetry Collector. У Kubernetes OBI розгортається як DaemonSet з одним подом на вузол. Під запускається з правами адміністратора з hostPID для підключення через eBPF до процесів застосунків на вузлі. OBI відправляє дані за OTLP, тому на колекторі потрібно ввімкнути OTLP receiver на портах 4317 (gRPC) або 4318 (HTTP).

Підготовка демо-застосунку з мікросервісами

Створіть базовий застосунок із двох FastAPI-сервісів. Перший сервіс приймає замовлення через ендпоінт /api/orders, другий обробляє дані клієнтів через /api/customers. Використайте Kafka або NATS для асинхронної комунікації між сервісами, де перший публікує події, а другий їх споживає.

Додавання трейсингу до Flask/FastAPI сервісів

Після налаштування провайдера викличте FastAPIInstrumentor.instrument_app(app) для автоматичної інструментації. Цей виклик захоплює всі HTTP-запити, створюючи спени з атрибутами маршруту, методу та статус-коду. Для ручної інструментації бізнес-логіки отримайте трейсер через trace.get_tracer(__name__) та створюйте спени конструкцією with tracer.start_as_current_span("enrich_order"). Додавайте атрибути через span.set_attribute("order.id", order_id) для збагачення контексту.

Передача контексту між сервісами

Контекст передається через HTTP-заголовок traceparent у форматі <version>-<trace-id>-<parent-id>-<trace-flags>. OpenTelemetry автоматично серіалізує контекст у вихідні запити та десеріалізує його з вхідних, забезпечуючи єдиний trace ID для всього ланцюга викликів між мікросервісами Python.

Налаштування Jaeger або Grafana Tempo

Jaeger використовує Cassandra або Elasticsearch для індексації трейсів, забезпечуючи потужний пошук за тегами. Tempo уникає баз даних, зберігаючи трейси в об'єктному сховищі (S3, GCS), що знижує операційні витрати. Візуалізація Tempo відбувається через Grafana, тоді як Jaeger має власний UI.

Візуалізація та аналіз трейсів

Трейси відображаються каскадом (waterfall), де кожен спен показує тривалість операції. Аналізуйте, де витрачається час: 10 мс у застосунку + 900 мс у базі даних чи 400 мс на зовнішньому сервісі.

Налаштування sampling стратегій

TraceIdRatioBased(0.1) збирає 10% трейсів за trace ID. ParentBased поважає рішення батьківського спену, забезпечуючи цілісність трейсів. Встановіть змінну OTEL_TRACES_SAMPLER="parentbased_traceidratio" та OTEL_TRACES_SAMPLER_ARG="0.1" для вибіркового збирання у продакшені.

Обмеження eBPF при роботі з HTTPS-трафіком

Хоча eBPF дає змогу ефективно відслідковувати мережеві події, варто враховувати обмеження при роботі з HTTPS-трафіком. Через шифрування даних eBPF не може безпосередньо аналізувати вміст зашифрованих пакетів. Це означає, що детальний аналіз HTTP-запитів та відповідей можливий лише після розшифрування трафіку на рівні застосунку або за допомогою додаткових інструментів, які інтегруються з eBPF. Тому для повноцінного distributed tracing у середовищах із HTTPS рекомендується комбінувати eBPF із механізмами розшифрування або інструментами на рівні застосунку.

Розподілене трасування в мікросервісах Python стає простішим завдяки OpenTelemetry та eBPF. Якщо правильно налаштуєте автоматичне інструментування, ви отримаєте повну видимість запитів без змін у коді. Почніть з базової інтеграції OpenTelemetry для ваших FastAPI або Django-застосунків, а потім додайте eBPF-моніторинг для критичних компонентів. Комбінація обох технологій дає найкращі результати для production-середовищ з мінімальними накладними витратами.