Настройка Zipkin в Kubernetes: Distributed Tracing для микросервисов

Когда запрос проходит через несколько микросервисов и падает с ошибкой, найти виновника без распределённой трассировки — почти невыполнимая задача. Мы настраиваем Zipkin в Kubernetes, чтобы вы видели полный путь каждого запроса и быстро выявляли узкие места. Наша команда реализует проект под ключ — от развёртывания до инструментирования сервисов, обеспечивая стабильную работу и последующую поддержку.
Часто задаваемые вопросы

Пять микросервисов, запрос проходит через каждый — и вдруг 500-я ошибка. Какой из них упал? Без распределённой трассировки ответа нет. Анализ логов по одному занимает часы. Мы настраиваем Zipkin — проверенный инструмент, который собирает трейсы и показывает полную картину запроса. В этой статье — практический опыт внедрения для команд, которые хотят быстро получить observability. На примере реального проекта покажем, как за два дня развернуть Zipkin в Kubernetes и инструментировать Spring Boot сервисы. Измерить производительность каждого вызова, найти медленный SQL-запрос или узнать, какой сервис потерял пакет — всё это становится рутиной.

Почему Zipkin подходит для Spring Boot проектов?

Zipkin имеет нативную интеграцию со Spring Boot через Micrometer Tracing (ранее Spring Cloud Sleuth). Для Java-команд это означает минимум кода: достаточно добавить зависимости и указать spring.zipkin.baseUrl. Настройка одного сервиса занимает 15 минут, включая деплой в staging. Из коробки поддерживаются все популярные HTTP-клиенты, JDBC и асинхронные вызовы. В отличие от более тяжёлых решений, Zipkin не требует отдельного агента или коллектора — всё работает в одном процессе.

Как разворачиваем Zipkin в Kubernetes?

Zipkin распространяется как исполняемый JAR и Docker-образ. Для локальной разработки достаточно:

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

В Kubernetes Zipkin деплоится проще Jaeger — нет разделения на агент/коллектор/query, всё в одном процессе. Обычно ставим 2 реплики с antiaffinity для отказоустойчивости. Пример Deployment с хранилищем Elasticsearch:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: zipkin
spec:
  replicas: 2
  selector:
    matchLabels:
      app: zipkin
  template:
    spec:
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: app
                  operator: In
                  values:
                  - zipkin
              topologyKey: kubernetes.io/hostname
      containers:
      - name: zipkin
        image: openzipkin/zipkin:3
        ports:
        - containerPort: 9411
        env:
        - name: STORAGE_TYPE
          value: elasticsearch
        - name: ES_HOSTS
          value: "http://elasticsearch:9200"

Выбор хранилища и настройка retention

По умолчанию Zipkin хранит трейсы в памяти — после перезапуска данные теряются. Для production нужно задать STORAGE_TYPE. Согласно документации Zipkin, Elasticsearch — рекомендуемый вариант. Таблица сравнения:

Хранилище Когда использовать Масштабируемость
Elasticsearch Стандартный выбор; автоматическое создание индексов Хорошая
Cassandra3 Очень высокий write throughput (>50k spans/sec) Отличная
MySQL Низкая нагрузка, если Elasticsearch недоступен Ограниченная

Retention настраивается через ILM или скриптом zipkin-dependencies — отдельным Spark-джобом, который также строит граф зависимостей между сервисами. Для typical retention в 7 дней достаточно одной ноды Elasticsearch с настройкой ILM.

Настройка sampling под высокую нагрузку

При высокой нагрузке отправка всех трейсов перегружает хранилище. Для Spring Boot с Micrometer используется параметр management.tracing.sampling.probability. Рекомендуемые значения:

  • Development/Staging: 0.5–1.0 (50–100% трейсов)
  • Production (RPS < 1000): 0.05–0.1 (5–10%)
  • Production (RPS > 10 000): 0.01 (1%)

Можно также настроить rate limiting через Sampler bean, чтобы ограничить количество трейсов в секунду, независимо от вероятности. Экономия на хранении составляет около $90–130 в месяц.

Поиск проблем, когда трейсы не доходят

Первая причина — не указан endpoint Zipkin или сетевые проблемы. Проверьте, что Zipkin доступен по zipkin:9411. Вторая — неправильные зависимости: убедитесь, что Micrometer Tracing bridge и Zipkin reporter добавлены. Третья — слишком агрессивное sampling: если вероятность 0, трейсов не будет. Добавьте health endpoint для мониторинга: Zipkin отправляет метрики в Prometheus, и можно настроить алерт на отсутствие новых трейсов за последние 5 минут.

Инструментирование Spring Boot

Для Spring Boot 3.x с Micrometer Tracing интеграция минимальна:

<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.yml
management:
  tracing:
    sampling:
      probability: 0.1
  zipkin:
    tracing:
      endpoint: http://zipkin:9411/api/v2/spans

При такой конфигурации 10% запросов будут трассироваться. Для продакшена снизьте до 0.01–0.05.

Сравнение Zipkin и Jaeger

Критерий Zipkin Jaeger
Java/Spring экосистема Нативная интеграция Требует OTLP/OpenTracing
Операционная сложность Ниже (один процесс) Выше (агент + коллектор + query)
UI и возможности Базовый, но удобный Богаче: adaptive sampling, SPM
OpenTelemetry Поддерживается Нативная поддержка
Масштабируемость Достаточно до ~50k spans/sec Лучше при очень высокой нагрузке

Если стек на Spring Boot и нет планов выходить за пределы JVM-мира — Zipkin настраивается быстрее. Если в системе несколько языков или нужен adaptive sampling — Jaeger или Tempo предпочтительнее.

Что входит в работу

  • Деплой Zipkin в Kubernetes с нужным хранилищем (Elasticsearch/Cassandra)
  • Инструментирование ваших сервисов (Java, Python, Go, Node.js)
  • Настройка стратегии sampling под нагрузку
  • Конфигурация retention и алертов на потерю трейсов
  • Документация для команды разработки
  • Обучение работе с UI и поиску аномалий

Процесс внедрения и сроки

  1. Аудит текущей архитектуры и точек интеграции.
  2. Развёртывание Zipkin в staging и production.
  3. Инструментирование сервисов (обычно 3–5 за первый спринт).
  4. Тестирование: проверка, что все трейсы долетают, корректно отображаются зависимости.
  5. Передача знаний команде.

Типовой проект занимает 2–3 дня. Стоимость рассчитывается индивидуально — свяжитесь с нами, мы оценим ваш проект за 1 день. Свяжитесь с нами для консультации по вашему проекту.

Типичные ошибки при настройке

  • Не настроен sampling на клиенте — все трейсы льются, перегрузка хранилища.
  • Использование in-memory хранилища в production — потеря данных при перезапуске.
  • Отсутствие health endpoint: Zipkin может лежать, а вы не видите, что трейсы не доходят.
  • Игнорирование retention: индексы растут бесконечно, стоимость хранения выходит из-под контроля.

Наши инженеры имеют сертификаты AWS и Kubernetes, гарантируем стабильную работу системы. Мы внедрили Zipkin на 15+ проектах, среднее время настройки — 2 дня.

Закажите внедрение Zipkin под ключ — получите консультацию уже сегодня.

Наши компетенции:

Последние работы

  • Разработка сайта компании B2B ADVANCE
    Разработка сайта компании B2B ADVANCE
    1542
  • Разработка веб-приложения для компании FEEDME
    Разработка веб-приложения для компании FEEDME
    1393
  • Разработка веб-сайта для компании БЕЛФИНГРУПП
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    1081
  • Разработка интернет магазина для компании FURNORO
    Разработка интернет магазина для компании FURNORO
    1368
  • Разработка логотипа компании B2B Advance
    Разработка логотипа компании B2B Advance
    815
  • Разработка веб-приложения для компании Enviok
    Разработка веб-приложения для компании Enviok
    1139