За полдня можно собрать observability в Spring Boot 3 без экзотики и тяжелой платформенной магии. Речь о вполне прикладочном наборе: метрики через Prometheus, трейсы через Zipkin, логи с traceId и единый экран в Grafana, чтобы не угадывать причину тормозов по косвенным признакам.
Такой сценарий разбирает OTUS в материале Сергея Прощаева, Tech Lead и руководителя направления Java/Kotlin-разработки в FinTech и e-commerce, сообщает Habr / Карьера. Фокус у статьи правильный для любой команды, у которой микросервис формально «жив», CPU не горит, логи молчат, а пользователи уже пишут в поддержку, что запросы внезапно идут по пять секунд.
Автор начинает не с теории, а с типичной для продакшена проблемы: сервис периодически подвисал, команда долго перебирала гипотезы про сеть и базу, а причина в итоге оказалась в повторном запросе к внешнему API без таймаута и без корректного propagation trace-контекста. Это хороший пример того, почему observability в Spring Boot 3 уже сложно считать факультативной настройкой. В микросервисной архитектуре старый подход «зайти на хост, открыть логи и надеяться на озарение» работает все хуже, особенно когда запрос проходит через несколько сервисов, очереди и внешние интеграции.
Дальше идет вполне конкретный набор входных условий. Берется Spring Boot 3.2.x и новее, Java 17 или 21, обычное веб-приложение со spring-boot-starter-web и spring-boot-starter-actuator, плюс Docker Compose для локального запуска обвязки. Важное ограничение автор тоже проговаривает без маркетингового тумана: это не инструкция для нагруженных инсталляций на десятки тысяч запросов в секунду. Для больших систем все равно понадобятся сэмплирование трейсов, отдельные решения по масштабированию и, вероятно, другая архитектура хранения телеметрии. Но для команды с парой десятков микросервисов такой стек выглядит реалистичным компромиссом между ценой внедрения и пользой.
Первый блок посвящен зависимостям и базовой конфигурации. В проект добавляются actuator, реестр Micrometer для Prometheus, bridge для Micrometer Tracing на базе Brave и репортер Zipkin. Здесь есть важная деталь, на которой многие спотыкаются после обновления со старых версий Spring: в ветке 3.x больше нет Spring Cloud Sleuth как привычного инструмента по умолчанию. Вместо него используется Micrometer Tracing, а значит, меняются и зависимости, и конфиг, и ментальная модель интеграции. Для разработчиков это не просто переименование. Любой копипаст из старых гайдов начинает быстро ломаться, особенно если проект пережил миграцию с Boot 2.x и в репозитории до сих пор лежат устаревшие настройки.
Второй и третий шаги закрывают метрики и трейсы. Метрики отдаются через /actuator/prometheus, Prometheus их периодически забирает, а разработчик сразу получает стандартный набор вроде JVM-показателей и HTTP-метрик. С трейсингом история интереснее. Автор отдельно подчеркивает, что для Boot 3 нужен endpoint /api/v2/spans на стороне Zipkin, а вероятность сэмплирования в демонстрации выставляется в 1.0, то есть в трассировку уходит каждый запрос. Для локальной проверки это нормально: сделал HTTP-запрос, открыл интерфейс Zipkin, увидел trace. Но в продакшене такая щедрость быстро превращается в накладные расходы, поэтому в статье честно говорится о более низком sampling, например 0.1. Там же есть и полезная оговорка про рынок инструментов: Zipkin выбран как самый простой вариант для локального старта, хотя в более современных production-стэках все чаще смотрят в сторону Grafana Tempo или OTel Collector.
Отдельно полезен кусок про логи, потому что именно здесь у многих «вроде все настроено», а потом traceId в строках логов почему-то нет. Прощаев предлагает не надеяться на неявную магию, а явно добавить MDC-корреляцию через бины конфигурации и прописать шаблон в logback-spring.xml, где рядом с уровнем лога и именем логгера выводятся traceId и spanId. Причем автор не ограничивается happy path: если используется bridge на Brave, нужен один вариант корреляции, если команда переходит на OpenTelemetry bridge, нужен уже другой класс. Для практикующего Java-разработчика это, пожалуй, самая ценная часть материала. Она экономит не часы, а иногда дни бессмысленного поиска по форумам на тему «почему в Zipkin trace есть, а в логах его нет».
Следующий уровень - инфраструктурная сборка. Для Prometheus предлагаются два сценария: быстрый, через host.docker.internal для Windows и macOS, и нормальный, через общую docker-сеть, где приложение и мониторинг живут рядом. Это как раз тот случай, когда учебная статья не притворяется production-гайдом, но и не бросает читателя на полпути. Разработчику показывают минимальный путь до рабочего результата: поднять приложение, подключить Prometheus, дальше связать логи с Loki и собрать дашборд в Grafana. Для команд это важный сигнал: observability - не отдельный многомесячный проект, который сначала надо «защитить» перед менеджментом. Базовый контур можно собрать быстро, а дальше уже решать, где хватает стандартных метрик, а где нужно более глубокое профилирование, алерты или переход на OpenTelemetry-экосистему.
Для бизнеса и технических руководителей из этой публикации вывод тоже довольно прямой. Наблюдаемость не делает сервис быстрее сама по себе, но резко сокращает стоимость расследования инцидента. Когда в одном месте видны метрики, трассировка и логи, команда тратит меньше времени на гадание и быстрее находит реальный узкий участок: зависший внешний вызов, неочевидный retry, проблемный downstream или кривую конфигурацию таймаутов. На рынке, где даже небольшая задержка в e-commerce или финтехе быстро превращается в потерю денег и нервов, такая инженерная гигиена давно перестала быть роскошью.
Observability в Spring Boot 3 в 2026 году выглядит уже не как модный термин из конференционных слайдов, а как базовая часть зрелого Java-стека. Вопрос теперь не в том, нужно ли это внедрять, а в том, сколько команд еще продолжают чинить микросервисы по логам одного контейнера, хотя связать traceId, метрики и дашборд можно за несколько вполне земных шагов.