02.03.2026 11:02
🕸️ Распределенная Трассировка: Ищем "бутылочное горлышко" (Zipkin & Jaeger) Если логи это текст, а метрики это графики,
🕸️ Распределенная Трассировка: Ищем "бутылочное горлышко" (Zipkin & Jaeger)
Если логи это текст, а метрики это графики, то трассировка это диаграмма Ганта (каскад) для каждого отдельного HTTP-запроса.
🧩 Главные понятия: Trace и Span
Вся магия строится на двух терминах:
1. Trace (След/Трасса): Это весь путь запроса от клика пользователя в браузере до самого глубокого ответа от базы данных. У него есть единый Trace ID.
2. Span (Пролет/Отрезок): Это один конкретный шаг внутри Трассы. Например, "поход в базу данных" - это один Span. "HTTP-запрос в сервис оплаты" - это другой Span. У каждого спана есть свой Span ID и информация о том, сколько миллисекунд он выполнялся.
🕵️♂️ Как сервисы передают ID друг другу?
Когда Gateway принимает запрос, он генерирует Trace ID (например, abc-123) и кладет его в HTTP-заголовки (обычно используется стандарт W3C traceparent или b3).
Когда Gateway вызывает OrderService, он передает эти заголовки дальше. OrderService читает их и понимает: "Ага, я часть большой трассы abc-123".
Вам не нужно писать этот код руками! В Spring Boot 3 за это отвечает библиотека Micrometer Tracing. Она автоматически перехватывает все вызовы через RestTemplate, WebClient, Feign и запросы к БД, вклеивая туда нужные ID.
🛠 Настройка (Spring Boot 3 + Zipkin)
Вам нужно добавить всего пару зависимостей в pom.xml:
<dependency>
<groupId>io.micrometer</groupId>
<artifactId>micrometer-tracing-bridge-brave</artifactId>
</dependency>
<dependency>
<groupId>io.zipkin.reporter2</groupId>
<artifactId>zipkin-reporter-brave</artifactId>
</dependency>
В application.yaml указываем адрес сервера Zipkin:
management:
tracing:
sampling:
probability: 1.0 # Отправлять 100% запросов (на проде обычно ставят 0.1, чтобы не грузить сеть)
zipkin:
tracing:
endpoint: "http://localhost:9411/api/v2/spans"
Ваши микросервисы в фоновом режиме отправляют данные о спанах (время старта и конца) в специальный сервер. Самые популярные решения это Zipkin (написан на Java, проще) или Jaeger (от Uber, написан на Go, мощнее).
Вы заходите в веб-интерфейс Jaeger, вбиваете Trace ID (который вы скопировали из логов в Kibana) и видите красивую цветную лесенку:
🟦 Gateway (Всего: 5.0s)
🟩 OrderService.create() (4.9s)
🟨 DB: INSERT order (0.05s)
🟧 PaymentService.pay() (4.8s) 👈 АГА! ВОТ КТО ТОРМОЗИТ!
🟥 External Bank API (4.75s)
За 5 секунд вы поняли, что проблема не в вашем коде и не в вашей базе данных, а в том, что API стороннего банка отвечает почти 5 секунд. Вы сэкономили часы дебага!
🔥 Итог: "Святая Троица" Observability
Теперь у вас есть полный набор инструментов Senior-разработчика:
1. Метрики (Prometheus/Grafana): Говорят ЕСТЬ ЛИ проблема. (У нас всплеск 500-х ошибок!).
2. Трассировка (Jaeger/Zipkin): Говорит ГДЕ проблема. (Ошибки летят из Payment Service при походе в банк).
3. Логи (ELK): Говорят В ЧЕМ проблема. (Смотрим логи Payment Service по Trace ID и видим: ConnectionTimeoutException).
#DevOps #Jaeger #Zipkin #Tracing #Microservices #SpringBoot
👉 @BookJava
Если логи это текст, а метрики это графики, то трассировка это диаграмма Ганта (каскад) для каждого отдельного HTTP-запроса.
🧩 Главные понятия: Trace и Span
Вся магия строится на двух терминах:
1. Trace (След/Трасса): Это весь путь запроса от клика пользователя в браузере до самого глубокого ответа от базы данных. У него есть единый Trace ID.
2. Span (Пролет/Отрезок): Это один конкретный шаг внутри Трассы. Например, "поход в базу данных" - это один Span. "HTTP-запрос в сервис оплаты" - это другой Span. У каждого спана есть свой Span ID и информация о том, сколько миллисекунд он выполнялся.
🕵️♂️ Как сервисы передают ID друг другу?
Когда Gateway принимает запрос, он генерирует Trace ID (например, abc-123) и кладет его в HTTP-заголовки (обычно используется стандарт W3C traceparent или b3).
Когда Gateway вызывает OrderService, он передает эти заголовки дальше. OrderService читает их и понимает: "Ага, я часть большой трассы abc-123".
Вам не нужно писать этот код руками! В Spring Boot 3 за это отвечает библиотека Micrometer Tracing. Она автоматически перехватывает все вызовы через RestTemplate, WebClient, Feign и запросы к БД, вклеивая туда нужные ID.
🛠 Настройка (Spring Boot 3 + Zipkin)
Вам нужно добавить всего пару зависимостей в pom.xml:
<dependency>
<groupId>io.micrometer</groupId>
<artifactId>micrometer-tracing-bridge-brave</artifactId>
</dependency>
<dependency>
<groupId>io.zipkin.reporter2</groupId>
<artifactId>zipkin-reporter-brave</artifactId>
</dependency>
В application.yaml указываем адрес сервера Zipkin:
management:
tracing:
sampling:
probability: 1.0 # Отправлять 100% запросов (на проде обычно ставят 0.1, чтобы не грузить сеть)
zipkin:
tracing:
endpoint: "http://localhost:9411/api/v2/spans"
Ваши микросервисы в фоновом режиме отправляют данные о спанах (время старта и конца) в специальный сервер. Самые популярные решения это Zipkin (написан на Java, проще) или Jaeger (от Uber, написан на Go, мощнее).
Вы заходите в веб-интерфейс Jaeger, вбиваете Trace ID (который вы скопировали из логов в Kibana) и видите красивую цветную лесенку:
🟦 Gateway (Всего: 5.0s)
🟩 OrderService.create() (4.9s)
🟨 DB: INSERT order (0.05s)
🟧 PaymentService.pay() (4.8s) 👈 АГА! ВОТ КТО ТОРМОЗИТ!
🟥 External Bank API (4.75s)
За 5 секунд вы поняли, что проблема не в вашем коде и не в вашей базе данных, а в том, что API стороннего банка отвечает почти 5 секунд. Вы сэкономили часы дебага!
🔥 Итог: "Святая Троица" Observability
Теперь у вас есть полный набор инструментов Senior-разработчика:
1. Метрики (Prometheus/Grafana): Говорят ЕСТЬ ЛИ проблема. (У нас всплеск 500-х ошибок!).
2. Трассировка (Jaeger/Zipkin): Говорит ГДЕ проблема. (Ошибки летят из Payment Service при походе в банк).
3. Логи (ELK): Говорят В ЧЕМ проблема. (Смотрим логи Payment Service по Trace ID и видим: ConnectionTimeoutException).
#DevOps #Jaeger #Zipkin #Tracing #Microservices #SpringBoot
👉 @BookJava