Налаштування Zipkin у Kubernetes: трасування для мікросервісів

Коли запит проходить через кілька мікросервісів і падає з помилкою, знайти винуватця без розподіленого трасування — майже нездійсненне завдання. Ми налаштовуємо 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, щоб обмежити кількість трейсів за секунду, незалежно від ймовірності. Економія на зберіганні становить десятки тисяч гривень на місяць.

Пошук проблем, коли трейси не доходять

Перша причина — не вказано 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