Пять микросервисов, запрос проходит через каждый — и вдруг 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 и поиску аномалий
Процесс внедрения и сроки
- Аудит текущей архитектуры и точек интеграции.
- Развёртывание Zipkin в staging и production.
- Инструментирование сервисов (обычно 3–5 за первый спринт).
- Тестирование: проверка, что все трейсы долетают, корректно отображаются зависимости.
- Передача знаний команде.
Типовой проект занимает 2–3 дня. Стоимость рассчитывается индивидуально — свяжитесь с нами, мы оценим ваш проект за 1 день. Свяжитесь с нами для консультации по вашему проекту.
Типичные ошибки при настройке
- Не настроен sampling на клиенте — все трейсы льются, перегрузка хранилища.
- Использование in-memory хранилища в production — потеря данных при перезапуске.
- Отсутствие health endpoint: Zipkin может лежать, а вы не видите, что трейсы не доходят.
- Игнорирование retention: индексы растут бесконечно, стоимость хранения выходит из-под контроля.
Наши инженеры имеют сертификаты AWS и Kubernetes, гарантируем стабильную работу системы. Мы внедрили Zipkin на 15+ проектах, среднее время настройки — 2 дня.
Закажите внедрение Zipkin под ключ — получите консультацию уже сегодня.







