Всем привет, меня зовут Сергей Прощаев, и в этой статье я расскажу про инструмент, который помогает всем разработчикам бэкенда . Я добавляю его в каждый проект на стадии «написания первой строчки кода». Речь пойдет о Spring Boot Actuator.

Мы часто, как разработчики, фанатеем от фичей: «А давайте сделаем асинхронную обработку через Kafka», «Подключим реактивное программирование». Но когда приложение выкатывается в прод, самое страшное — это состояние «черного ящика». Оно работает? Оно дышит? Почему пользователи жалуются на тормоза, а на мониторинге все зелено?

Actuator — это тот самый «кардиомонитор» для вашего приложения, который позволяет заглянуть внутрь работающего кода без дебаггера и без остановки сервера. В этой статье мы разберем, как перестать гадать на кофейной гуще и начать реально понимать, что творится в продакшене.

Зачем он вообще нужен? Или история про «упавший» кэш

Пару лет назад я консультировал команду, которая выкатила микросервис авторизации. В тестах всё было идеально: нагрузка 50 RPS проходилась «на ура». Через час после релиза в прод началась вакханалия: таймауты, падение запросов, пользователи не могли залогиниться.

Разработчики полдня ковырялись в логах. Оказалось, что кто-то из админов случайно отключил Redis (кэш сессий) через консоль, а приложение продолжало пытаться ходить в него синхронно, накапливая потоки в ожидании ответа. Если бы в том сервисе был настроен Actuator с эндпоинтом /health и проверкой состояния внешних сервисов, проблема была бы видна сразу: статус приложения переключился бы на DOWN, а в дашборде мониторинга загорелась бы красная лампочка до того, как начали сыпаться звонки от клиентов.

Spring Boot Actuator решает три фундаментальные задачи:

  1. Мониторинг состояния (Health): жив ли сервис, тянется ли он к базе данных, доступен ли кэш.

  2. Метрики (Metrics): сколько запросов обработано, какое среднее время ответа, сколько свободной памяти.

  3. Управление (Management): возможность динамически менять уровень логирования или посмотреть список бинов в работающем приложении.

Это не просто набор эндпоинтов. Это мост между вашим кодом и современными системами observability (наблюдаемости), такими как Prometheus, Grafana или Zabbix.

Базовая настройка: убираем лишнее и оставляем нужное

Первое, что делают новички — просто добавляют зависимость и радуются, что появилась куча эндпоинтов. Но в реальной работе так делать нельзя. Actuator — это мощный инструмент, который может стать дырой в безопасности, если его не настроить.

Чтобы начать, достаточно добавить в pom.xml:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-registry-prometheus</artifactId>
</dependency>

Обратите внимание: вместе со стартером actuator мы подключаем micrometer-registry-prometheus. Это необходимо, чтобы в приложении появился эндпоинт /actuator/prometheus, который отдаёт метрики в формате, поддерживаемом Prometheus.

Без этой зависимости Prometheus не сможет собирать данные — вы получите 404 при попытке обратиться к этому эндпоинту.

По умолчанию Actuator включен, но доступ к большинству «вкусностей» (например, /beans или /env) закрыт. Их нужно открывать осознанно.

Вот моя базовая конфигурация для application.yml, которую я использую в 90% проектов (пакет ru.otus):

management:
  endpoints:
    web:
      exposure:
        include: health,info,metrics,prometheus
      base-path: /actuator
  endpoint:
    health:
      show-details: always
      probes:
        enabled: true
    prometheus:
      enabled: true
  server:
    port: 8081

Почему именно так?

  1. Порт 8081: я выношу управление на отдельный порт. Это позволяет изолировать административный трафик от бизнес-трафика. Если ваш основной API лежит на 8080, то DDoS-атака на бизнес-логику не помешает вам зайти в Actuator и посмотреть метрики.

  2. exposure: я открываю только четыре ключевых эндпоинта. health — для проверок, info — для версии приложения, metrics и prometheus — для сбора данных. Эндпоинт beans или env я открываю только на короткое время в тестовых средах, но никогда в проде без жесткой авторизации.

Диаграмма взаимодействия: как это работает

Чтобы было нагляднее, посмотрим, как Actuator встраивается в архитектуру. Представьте, что у нас есть микросервис (USER-сервис), который взаимодействует с базой данных (PostgreSQL) и кэшем (Redis). Вот как выглядит поток мониторинга:

Рис. 1. Схема интеграции Spring Boot Actuator с внешними системами и оркестрацией.
Рис. 1. Схема интеграции Spring Boot Actuator с внешними системами и оркестрацией.

Ключевой момент здесь — разделение Liveness и Readiness. Liveness проверяет, не пора ли перезапустить приложение (если оно зависло). Readiness проверяет, готов ли сервис принимать трафик (если база данных упала, приложение живо, но трафик пускать на него нельзя, иначе все запросы упадут с ошибкой).

Разбор ключевых метрик: что значат эти цифры?

Когда вы заходите на http://localhost:8081/actuator/metrics, вы видите огромный JSON. Глаза разбегаются. Но я выделяю три группы, которые реально спасают жизнь:

1. Метрики JVM и памяти

jvm.memory.used, jvm.gc.pause.Однажды у нас было приложение, которое стабильно падало раз в сутки. В логах был OutOfMemoryError. Я посмотрел на график jvm.memory.used в Grafana и увидел классическую «пилу»: память растет, сборщик мусора срабатывает, падает, но каждый раз поднимается чуть выше, чем в прошлый раз. Это указало на утечку памяти в кэшировании сущностей Hibernate. Без Actuator нам пришлось бы несколько дней снимать heap dump и анализировать его вручную.

2. Метрики HTTP-запросов

http.server.requests.Здесь скрывается ответ на вопрос «почему тормозит?». Actuator автоматически считает количество запросов, их статусы (200, 400, 500) и, самое главное, перцентили времени ответа (p95, p99).Если я вижу, что p99 времени ответа для /api/login вырос с 200 мс до 5 секунд — это верный признак, что либо база данных легла, либо в коде появился медленный запрос.

3. Кастомные метрики: ваше конкурентное преимущество

Стандартные метрики хороши, но сильный аналитик (и разработчик) знает, что нужно измерять бизнес-показатели. Actuator позволяет это делать.

В одном финтех-проекте мы добавили кастомную метрику для подсчета количества успешных транзакций и количества отклоненных. Когда мы выкатили новый алгоритм антифрода, мы наблюдали за метрикой fraud.rejected.count. Как только она резко пошла вверх, мы поняли, что алгоритм «перекрутил» и начал блокировать легитимных пользователей. Мы откатили настройки за 5 минут, не дожидаясь звонков в техподдержку.

Пример кода кастомной метрики:

package ru.otus.service;

import io.micrometer.core.instrument.MeterRegistry;
import org.springframework.stereotype.Service;

@Service
public class UserRegistrationService {

    private final MeterRegistry meterRegistry;

    public UserRegistrationService(MeterRegistry meterRegistry) {
        this.meterRegistry = meterRegistry;
    }

    public void register(String email) {
        // ... логика регистрации
        meterRegistry.counter("user.registrations", "status", "success").increment();
    }
}

Реальный кейс: Как мы ускорили приложение на 40% с помощью метрик

Это история про один проект, где была сложная бизнес-логика расчета рейтинга сотрудников. Приложение работало, но было очень медленным. Мы настроили Actuator + Prometheus + Grafana. Глядя на дашборд, мы увидели странную картину: время ответа эндпоинта /rating/calculate было нормальным (100мс), но при этом график hikaricp.connections.active (активные соединения с базой) постоянно был на максимуме, а среднее время получения соединения из пула (hikaricp.connections.acquire) составляло 300мс.

То есть само приложение работало быстро, но 75% времени оно ждало, пока освободится соединение с БД! Мы поняли, что разработчики забыли закрывать транзакции в некоторых местах (аннотация @Transactional висела на всем подряд, даже на методах, которые только читали данные). После рефакторинга (снятия транзакций с read-only методов и увеличения пула соединений) время ответа упало на 40%. И мы это доказали цифрами, а не домыслами.

Best Practices: Чек-лист для продакшена

За годы работы я выработал для себя несколько правил использования Actuator, которые помогут не попасть впросак:

  1. Безопасность прежде всего. Никогда не выставляйте Actuator на тот же порт, что и бизнес-логика, без прокси. Используйте management.server.port и настройте firewall так, чтобы доступ к 8081 порту был только у внутренних систем мониторинга.

  2. Используйте кастомные индикаторы здоровья (HealthIndicator). Если ваше приложение работает по очереди из RabbitMQ, сделайте свой индикатор, который проверяет, есть ли соединение с очередью. Стандартный health этого не покажет, пока вы сами не напишете проверку.

  3. Следите за размером метрик. Если у вас REST API с динамическими путями (например, /user/{id}), Actuator создаст отдельную метрику под каждый ID, что приведет к взрывному росту памяти. Используйте фильтрацию или объединяйте теги (tags).

  4. Включайте Info. В эндпоинте /info я всегда передаю версию приложения (app.version) и последний коммит (git.commit.id). Это невероятно помогает, когда в прод выкачено 10 микросервисов, и вы точно хотите знать, какая версия сейчас крутится на сервере.

Заключение: Actuator — это не опция, а стандарт

Разбор Spring Boot Actuator — это не просто очередная тема из учебника. Это симуляция реальной работы, где ваша ценность как разработчика измеряется не количеством написанных строчек кода, а тем, насколько быстро вы можете найти проблему в продакшене и доказать, что приложение работает стабильно.

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

Если этот разбор показался вам полезным и вы хотите научиться не просто использовать инструменты, а понимать архитектуру и глубже разбираться в экосистеме Spring, приглашаю вас на курс «Разработчик на Spring Framework» в OTUS. Мы разберем реальные кейсы, посмотрим на тонкую настройку контекста и поговорим о том, как проходить собеседования на уверенного специалиста и старшего специалиста.

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

А чтобы узнать больше о формате обучения и познакомиться с преподавателями, приходите на бесплатные уроки:

  • 30 марта в 20:00. «Spring Boot Actuator: основы наблюдения за состоянием и управления приложением». Записаться

  • 15 апреля в 20:00. «OpenAPI и Spring». Записаться