Трейсинг

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

Трейсинг

Представьте ситуацию: пользователь пожаловался, что не смог оформить заказ, а запрос на самом деле завершился тайм-аутом где-то в недрах микросервисной архитектуры. Если такое место не было обложено логами, как решать ситуацию?
Скорее всего, никак: разработчик оценит ситуацию, поймёт, что воспроизвести её сложно, а логов нет. И раз случай не массовый — просто предложит закрыть такую ошибку. С точки зрения имеющихся данных и потенциальных затрат на поиск проблемы с непонятным исходом разработчик будет прав.
Создавать логи на все места дорого: получится очень много информации, а хранилище стоит денег. Но ситуации, когда нужно понять, кто, когда и в какой последовательности вызывал сервис, встречаются довольно часто.
Дешевле в таком случае воспользоваться трейсингом — методом отслеживания запросов в приложении.
Трейсинг начинается с точки входа запроса в приложение: он запускается для запроса и имеет уникальный идентификатор, сгенерированный для этого запроса. По мере того как трафик переходит от сервиса к сервису, каждый сервис добавляет информацию (например, время поступления запроса в сервис и время, затраченное на его обработку). 
По итогу получается список вызовов, представленных в виде дерева. По ним можно понять, где и чем оборвалась цепочка вызовов.
Трейсинг помогает быстро находить причины, например, медленной работы сервиса. Вместо просмотра всей цепочки вызовов, которую нужно к тому же раскрутить, разработчик может посмотреть, сколько, где и с какими параметрами прошёл вызов. У трейсинга как средства устранения неполадок есть дополнительные преимущества, поскольку любое исключение или ошибка обычно фиксируется вместе со всем контекстом запроса.
До погружения в реализацию стоит познакомиться с OpenTelemetry.

OpenTelemetry

✏️ OpenTelemetry (OTel) — это платформа наблюдения с открытым исходным кодом, которая предоставляет стандартизированный способ сбора, обработки и экспорта телеметрических данных-сигналов (метрик, трассировок и журналов) из распределённых систем. По факту OTel является отраслевым стандартом, то есть большинство sdk и фреймворков умеют работать именно с ним.
В приложение (code) встраивается sdk OTel, которое добавляет необходимые сигналы по мере распространения вызовов и отправляет их в приёмник (receivers), который передаёт обработчикам коллектора. Приёмники поддерживают либо HTTP-, либо gRPC-протокол. 
Задача коллектора — обработать, отфильтровать и агрегировать телеметрию, а затем отправить её через экспортёры в хранилище телеметрии и средства визуализации.
OpenTelemetry вводит понятие контекста операции, который может содержать:
  • Статическую информацию, или resource, — в её число входит, например, называние ноды, в которой развёрнуто приложение, или называние окружения, в котором запущен сервис. Эти данные прикрепляются к каждому логу, метрике или трассировке, чтобы их было удобно искать.
  • Динамическую информацию — например, идентификатор текущего эндпоинта ("http_path": "GET /product/:id"). Эту информацию можно привязывать к группам логов, метрик или трассировок.
Основных атрибутов контекста два. Это trace_id — идентификатор текущей операции и span_id — идентификатор подзапроса. При повторных попытках выполнения операции (например, при ошибках) каждый подзапрос должен иметь уникальный идентификатор span_id.
Контексты OpenTelemetry можно передавать между различными приложениями с использованием механизма распространения контекста (context propagation). Этот процесс реализуется через специальные заголовки, которые добавляются в каждый HTTP- или gRPC-запрос, а также в заголовки сообщений для очередей.
Такая передача контекста позволяет нижестоящему приложению восстановить информацию о предыдущих операциях и в итоге собрать полную распределённую трассировку, охватывающую все этапы обработки запроса.
Контекст и идентификаторы запросов позволяют инструментам с открытым исходным кодом, таким как Jaeger, визуализировать весь поток вызовов.

Немного про Jaeger

В реализации трейсинга вы будете использовать Jaeger — один из популярных инструментов трейсинга. Он помогает расследовать инциденты и выявлять узкие места в производительности микросервисной архитектуры.
Jaeger — удобный инструмент и для визуализации трассировок в распределённых системах. Одним из компонентов Jaeger является Jaeger-UI — веб-интерфейс для поиска и просмотров трейсов.
Jaeger поддерживает OpenTelemetry. Нужно лишь поднять Jaeger и настроить свои приложения, микросервисы, чтобы они отправляли туда данные о своей жизнедеятельности. У Jaeger есть хранилище, где эти данные записываются.

Реализация трейсинга: практика

Представьте следующую архитектуру: приложение разделено на три сервиса — корзину, биллинг и заказы, — из приложения будут уходить метрики благодаря OpenTelemetry, а Jaeger будет их отображать.
  1. Сделайте директории под три сервиса: cart, billing и order — и в каждой директории создайте файлы app.py, requirements.txt и Dockerfile.
requirements.txt:
Flask
requests
Dockerfile (во втором Dockerfile порт 8000 замените на 8001, а в третьем — на 8002):

DOCKER

FROM python:3.12
COPY app.py requirements.txt /
RUN apt-get update && apt-get install -y g++ 
RUN /usr/local/bin/python -m pip install --upgrade pip
RUN pip install -r requirements.txt
EXPOSE 800(0/1/2)
CMD ["flask", "run", "-h", "0.0.0.0", "-p", "800(0/1/2)"]
  1. В cart/app.py добавьте простой код:

PYTHON

from flask import Flask
import requests

app = Flask(__name__)

@app.route("/buy")
def buy():
    res = requests.get("http://billing:8000")
    return res.text
  1. Вызовите сервис оплаты для покупки. В billing/app.py добавьте код:

PYTHON

from flask import Flask
import requests

app = Flask(__name__)

@app.route("/")
def pay():
    res = requests.get("http://order:8002")
    return "Payed"+res.text
После оплаты и создания заказа вернётся номер заказа.
  1. Сделайте то же и в order/app.py:

PYTHON

from flask import Flask
import random
import time

app = Flask(__name__)

@app.route("/")
def order():
    random_order_number = random.randint(1, 500)
    time.sleep(random_order_number*0.001) #задержка
    return str(random_order_number)
Так всё будет работать. Но лучше, если будет наглядно отображаться, не произошёл ли тайм-аут между биллингом и заказами и был ли вообще вызов.
  1. Добавьте включение телеметрии в сервисы:

PYTHON

from opentelemetry import trace
from opentelemetry.exporter.jaeger.thrift import JaegerExporter
from opentelemetry.sdk.resources import SERVICE_NAME, Resource
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.instrumentation.flask import FlaskInstrumentor
from opentelemetry.instrumentation.requests import RequestsInstrumentor

#tracer
trace.set_tracer_provider(
   TracerProvider(
       resource=Resource.create({SERVICE_NAME: "имя сервиса"})
   )
)
jaeger_exporter = JaegerExporter( #jaeger
   agent_host_name="jaeger",
   agent_port=6831,
)
trace.get_tracer_provider().add_span_processor(
   BatchSpanProcessor(jaeger_exporter) #span creator
)

app = Flask(__name__)
FlaskInstrumentor().instrument_app(app) #flask instrumentation
RequestsInstrumentor().instrument() #request instrumentation
  1. И оберните вызовы в сервисах конструкцией:

PYTHON

with trace.get_tracer(__name__).start_as_current_span("pay"):

Полный код cart/app.py

PYTHON

from flask import Flask
import requests
from opentelemetry import trace
from opentelemetry.exporter.jaeger.thrift import JaegerExporter
from opentelemetry.sdk.resources import SERVICE_NAME, Resource
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.instrumentation.flask import FlaskInstrumentor
from opentelemetry.instrumentation.requests import RequestsInstrumentor

trace.set_tracer_provider(
   TracerProvider(
       resource=Resource.create({SERVICE_NAME: "cart"})
   )
)
jaeger_exporter = JaegerExporter(
   agent_host_name="jaeger",
   agent_port=6831,
)
trace.get_tracer_provider().add_span_processor(
   BatchSpanProcessor(jaeger_exporter)
)

app = Flask(__name__)
FlaskInstrumentor().instrument_app(app)
RequestsInstrumentor().instrument()

@app.route("/buy")
def buy():
    with trace.get_tracer(__name__).start_as_current_span("buy"):
        res = requests.get("http://billing:8000")
        return res.text

Полный код billing/app.py

PYTHON


from flask import Flask
import requests
from opentelemetry import trace
from opentelemetry.exporter.jaeger.thrift import JaegerExporter
from opentelemetry.sdk.resources import SERVICE_NAME, Resource
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.instrumentation.flask import FlaskInstrumentor
from opentelemetry.instrumentation.requests import RequestsInstrumentor

trace.set_tracer_provider(
   TracerProvider(
       resource=Resource.create({SERVICE_NAME: "billing"})
   )
)
jaeger_exporter = JaegerExporter(
   agent_host_name="jaeger",
   agent_port=6831,
)
trace.get_tracer_provider().add_span_processor(
   BatchSpanProcessor(jaeger_exporter)
)

app = Flask(__name__)
FlaskInstrumentor().instrument_app(app)
RequestsInstrumentor().instrument()

@app.route("/")
def pay():
    with trace.get_tracer(__name__).start_as_current_span("pay"):
        res = requests.get("http://order:8002")
        return "Payed"+" "+res.text

Полный код order/app.py

PYTHON

from flask import Flask
import random
import time
from opentelemetry import trace
from opentelemetry.exporter.jaeger.thrift import JaegerExporter
from opentelemetry.sdk.resources import SERVICE_NAME, Resource
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.instrumentation.flask import FlaskInstrumentor

trace.set_tracer_provider(
   TracerProvider(
       resource=Resource.create({SERVICE_NAME: "order"})
   )
)
jaeger_exporter = JaegerExporter(
   agent_host_name="jaeger",
   agent_port=6831,
)
trace.get_tracer_provider().add_span_processor(
   BatchSpanProcessor(jaeger_exporter)
)
app = Flask(__name__)
FlaskInstrumentor().instrument_app(app)

@app.route("/")
def order():
    with trace.get_tracer(__name__).start_as_current_span("order"):
        random_order_number = random.randint(1, 500)
        time.sleep(random_order_number*0.001) #задержка
        return str(random_order_number)
  1. Теперь добавьте зависимости в requirements.txt:

PYTHON

opentelemetry-api  #api otel
opentelemetry-sdk #sdk otel
opentelemetry-instrumentation-flask #framework instrumentation
opentelemetry-instrumentation-requests #framework instrumentation
opentelemetry-exporter-jaeger
В этом примере инструментация будет автоматическая.
  1. Создайте docker-compose.yml:

YAML

version: "3"

services:

  jaeger:
    image: jaegertracing/all-in-one
    hostname: jaeger
    ports:
      - 6831:6831/udp # accept jaeger.thrift in compact Thrift protocol used by most current Jaeger clients
      - 6832:6832/udp # accept jaeger.thrift in binary Thrift protocol used by Node.js Jaeger client (because thriftrw npm package does not support compact protocol)
      - 5775:5775/udp # accept zipkin.thrift in compact Thrift protocol (deprecated; only used by very old Jaeger clients, circa 2016)
      - 5778:5778 # serve configs, sampling strategies
      - 4317:4317 # OpenTelemetry Protocol (OTLP) over gRPC
      - 4318:4318 # OpenTelemetry Protocol (OTLP) over HTTP
      - 16686:16686 # UI port
      - 14269:14269 # collector admin port: health check at / and metrics at /metrics
      - 9411:9411 # Zipkin compatible endpoint
    environment:
      - COLLECTOR_ZIPKIN_HOST_PORT=:9411

  cart:
    image: cart
    build:
      context: cart
      dockerfile: ./Dockerfile
    ports:
      - target: 8001
        published: 8001

  billing:
    image: billing
    build:
      context: billing
      dockerfile: ./Dockerfile
    ports:
      - target: 8000
        published: 8080

  order:
    image: order
    build:
      context: order
      dockerfile: ./Dockerfile
    ports:
      - target: 8002
        published: 8002
  1. Сделайте build:

PYTHON

docker-compose build
  1. Запускайте:

PYTHON

docker-compose up -d
  1. Всё запустилось! Откройте Jaeger UI по адресу http://localhost:16686/search. Jaeger UI будет собирать свои метрики и сохранять их по умолчанию в своей памяти. Или вы можете настроить базы данных Elasticsearch, Cassandra:
Здесь можно посмотреть дефолтные трейсы:
  1. Вызовите ваш сервис корзины:

PYTHON

curl -X GET localhost:8001/buy
  1. Обновите Jaeger UI и вы увидите вызванный сервис:
  1. Выберите cart и нажмите Find Traces, чтобы увидеть ваш вызов:
  1. Можно провалиться ещё и увидеть трассировку:
  1. А если выбрать один из спанов, вы увидите контекст, куда из приложения можно добавлять кастомные параметры.
Трейсинг настроен! Но, возможно, в процессе настройки у вас возник вопрос: где тут коллектор? Дело в том, что Jaeger поставляется с готовым Docker-образом «all-in-one», который содержит все необходимые компоненты для его работы.
✏️ All-in-one — это исполняемый файл, предназначенный для быстрого локального тестирования, который запускает Jaeger UI, коллектор, запрос и агент, используя компонент хранения в оперативной памяти.
Весь код и настройки доступны здесь: https://github.com/db-exp/trace.
А теперь предлагаем вспомнить, о чём шла речь в уроке.

Задание 1

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

Задание 2

Вы работаете инженером по DevOps в компании, поддерживающей крупное e-commerce приложение. В приложении в последнее время увеличилось время ответа на запросы при оформлении заказов. Вы внедрили OpenTelemetry для мониторинга системы и анализа трейсинга. Что поможет быстро выявить источник проблемы? Выберите один правильный ответ.

Задание 3

Вы являетесь инженером по DevOps и работаете с распределённой системой микросервисов. Недавно пользователи начали жаловаться на периодические задержки при выполнении запросов. Вы уже настроили OpenTelemetry для сбора телеметрии и используете Jaeger для визуализации трассировок. Какой из следующих подходов наиболее эффективен для использования Jaeger при анализе проблемы? Выберите один правильный ответ.

Задание 4

Вы работаете разработчиком в компании, поддерживающей веб-приложение на микросервисной архитектуре. Один из микросервисов написан на Flask, и вам нужно настроить трейсинг для мониторинга цепочки вызовов с использованием OpenTelemetry. Какие шаги необходимо выполнить, чтобы успешно интегрировать трейсинг в ваше Flask-приложение?

Задание 5

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

Сергей

Подведём итоги

Что почитать про трейсинг?

info_habr OpenTelemetry на практике
JaegerTracing Jaeger: open source, distributed tracing platform
Trace Context
https://dzone.com/articles/distributed-tracing-with-zipkin-and-elk
https://grafana.com/blog/2023/12/18/opentelemetry-best-practices-a-users-guide-to-getting-started-with-opentelemetry/
https://signoz.io/blog/opentelemetry-vs-prometheus/
Ivan Kurchenko

Итоги

  • Когда источников событий слишком много, как, например, в микросервисной архитектуре, и для понимания всей картины нам необходимо сначала найти, а затем проанализировать логи из множества источников, удобнее использовать трейсинг. Он позволяет отслеживать путь запроса по уникальному идентификатору.
  • Наиболее популярной платформой реализации трейсинга является OpenTelemetry. В этой системе собираются и обрабатываются все трейсы и метрики, которые существуют внутри контекста. Контексты можно передавать от приложения к приложению, что делает возможным преемственность и визуализацию.
  • Визуализация трейсинга эффективно реализуется с помощью инструмента Jaeger. Он поддерживает OpenTelemetry, достаточно настроить приложения и микросервисы, чтобы они отправляли в Jaeger данные.