Лекция 253: Интеграция Spring Boot с Zipkin и Sleuth

Настало время углубиться в практическую магию Spring Boot, Sleuth и Zipkin, чтобы трассировка стала нашим лучшим другом в микросервисной археологии.

Обзор Spring Cloud Sleuth

Spring Cloud Sleuth — это библиотека, интегрированная в Spring Boot, которая добавляет распределённую трассировку в микросервисы, словно вы дали своим сервисам возможность оставлять следы в каждом запросе.

Она автоматически добавляет идентификаторы трассировок (traceId) и спанов (spanId) в ваши логи. Таким образом, вы сможете понять, как ваш запрос путешествует по микросервисной системе, какие сервисы он посещает, и где именно он задерживается.

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

Почему это важно?

• Логи без контекста – как кусочки случайного пазла. Sleuth добавляет единый traceId, который связывает логи воедино.
• Вы можете отследить "задержки" запросов до конкретного сервиса.
• Удобно использовать с системами трассировки, такими как Zipkin или Jaeger.

Основные возможности Sleuth

• Встроенные идентификаторы traceId и spanId.
• Интеграция с логированием.
• Автоматическое отслеживание времени выполнения запросов.
• Поддержка HTTP, Kafka, RabbitMQ и других транспортов.

Настройка Sleuth в Spring Boot

Перейдём к практике! Создадим простой Spring Boot микросервис и интегрируем Sleuth.

Добавление зависимости

Для интеграции Sleuth необходимо добавить зависимость в ваш pom.xml (или build.gradle, если используете Gradle). Кроме того, мы добавим Zipkin, чтобы визуализировать трассировку запросов.

<dependencies>
    <!-- Spring Cloud Sleuth -->
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-sleuth</artifactId>
    </dependency>
    <!-- Zipkin -->
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-zipkin</artifactId>
    </dependency>
</dependencies>

Конфигурация

В application.yml добавляем базовую настройку для включения трассировки и Zipkin.

spring:
  application:
    name: microservice-a
  sleuth:
    sampler:
      probability: 1.0 # 100% запросов будут трассироваться
  zipkin:
    base-url: http://localhost:9411 # URL вашего Zipkin-сервера

Эта конфигурация делает следующее:

1. Настраивает имя вашего сервиса как microservice-a.
2. Задаёт sampler.probability: 1.0, что означает, что все запросы будут трассироваться (на проде лучше уменьшить значение).
3. Указывает URL Zipkin-сервера.

Интеграция с Zipkin

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

Zipkin работает с traceId и spanId, которые Sleuth автоматически передаёт.

1. Самый простой способ запустить Zipkin — использовать Docker:

   docker run -d -p 9411:9411 openzipkin/zipkin
   

2. После запуска Zipkin будет доступен по адресу: http://localhost:9411.

Демонстрация: Трассировка в микросервисах

Шаг 1. Создаём два микросервиса

Создадим два микросервиса: Service A и Service B. Service A вызывает Service B через REST. Наша цель — увидеть, как запрос путешествует между ними.

Основной контроллер Service A:

@RestController
@RequestMapping("/service-a")
public class ServiceAController {

    private final RestTemplate restTemplate;

    public ServiceAController(RestTemplate restTemplate) {
        this.restTemplate = restTemplate;
    }

    @GetMapping("/call-service-b")
    public String callServiceB() {
        String response = restTemplate.getForObject("http://localhost:8081/service-b/endpoint", String.class);
        return "Response from Service B: " + response;
    }
}

Конфигурация для RestTemplate:

@Configuration
public class AppConfig {

    @Bean
    public RestTemplate restTemplate() {
        return new RestTemplate();
    }
}

Контроллер Service B выглядит так:

@RestController
@RequestMapping("/service-b")
public class ServiceBController {

    @GetMapping("/endpoint")
    public String endpoint() {
        return "Hello from Service B!";
    }
}

Шаг 2. Подключение Sleuth и Zipkin

Оба сервиса используют те же зависимости Sleuth и Zipkin, что мы настроили ранее. Также нужно убедиться, что у них настроены разные имена:

Для Service A:

spring:
  application:
    name: service-a

Для Service B:

spring:
  application:
    name: service-b

Шаг 3. Проверка трассировки

1. Запустите оба сервиса (на портах 8080 и 8081).
2. Вызовите Service A, чтобы инициировать запрос:

   curl http://localhost:8080/service-a/call-service-b
   

3. Перейдите в UI Zipkin по адресу http://localhost:9411.

Вы увидите трассировку запроса с двумя спанами:

• Первый спан: вызов контроллера в Service A.
• Второй спан: вызов Service B из Service A.

Пример логирования с Sleuth

Когда вы включаете Sleuth, в логи автоматически добавляются traceId и spanId.

Пример лога:

2023-10-25 12:00:00.123  INFO [service-a,traceId=1ab23cd4,spanId=2ef56gh7] Request initiated
2023-10-25 12:00:00.456  INFO [service-b,traceId=1ab23cd4,spanId=3ij89kl0] Processing request

На что обратить внимание

1. Самплирование (Sampling): С помощью spring.sleuth.sampler.probability вы можете настроить, какой процент запросов будет трассироваться. Например, для продакшена лучше использовать 0.1 (10%).
2. Контекст запросов: Sleuth автоматически передаёт заголовки трассировки, такие как X-B3-TraceId, между сервисами. Убедитесь, что ваш код не затирает эти заголовки.
3. Ошибки трассировки: Если Zipkin не отображает данных:
   • Проверьте URL Zipkin-сервера в конфигурации.
   • Убедитесь, что Sleuth включён (spring.sleuth.enabled=true).

Реальное применение

• В продакшене Sleuth + Zipkin помогает быстро находить "узкие места". Например, если запрос долго обрабатывается, вы сразу видите, какой сервис виноват.
• Также популярным инструментом является OpenTelemetry, который более гибкий, но сложнее в настройке.
• Вы можете интегрировать трассировку с логированием на уровне ELK для полного наблюдения.

На этом этапе вы теперь не просто добавили Sleuth и Zipkin в свои проекты, но и знаете, как отследить запросы, словно хищник на охоте за багами. В следующей лекции мы углубимся в централизованное логирование с ELK. Надеюсь, ваши микросервисы встретятся там снова!