Этап 9 - Observability, Actuator и production diagnostics
Приложение не становится production-ready только потому, что запускается на машине разработчика. Production означает, что кому-то придется под давлением отвечать на практические вопросы: service живой, готов ли он принимать traffic, почему requests стали медленными, не забился ли database connection pool, какой release принес проблему? Observability - это набор инструментов и привычек, которые помогают отвечать на эти вопросы без угадывания.
Зачем нужен Actuator
Spring Boot Actuator открывает operational information через специальные endpoints под /actuator. Это не business API endpoints. Customer не вызывает их, чтобы создать order. Infrastructure, monitoring tools и developers используют их, чтобы понять состояние service. Самый частый endpoint - /actuator/health: он показывает, живо ли приложение и, если настроено, доступны ли важные dependencies вроде database.
Без Actuator команды часто придумывают слабые health checks вроде GET /api/orders и считают, что успешный response означает нормальное состояние service. Это недостаточно точно. Service может стартовать, но не подключиться к database. Он может быть alive, но еще не ready для traffic во время startup. Он может отвечать на один endpoint, пока background dependency сломана. Actuator дает стандартное место для таких signals.
| Signal | Endpoint или источник | На какой вопрос отвечает |
|---|---|---|
| Health | /actuator/health | Service живой и доступны ли required dependencies? |
| Readiness | /actuator/health/readiness | Можно ли отправлять traffic в этот instance сейчас? |
| Metrics | /actuator/metrics, /actuator/prometheus | Сколько requests, errors, memory pressure и DB pool usage? |
| Logs | Application logs с request id | Что произошло внутри одного request? |
| Traces | Distributed tracing system | Какие services участвовали в медленном request? |
Минимальная конфигурация
management.endpoints.web.exposure.include=health,info,metrics,prometheus
management.endpoint.health.probes.enabled=true
management.endpoint.health.show-details=when_authorized
Не открывай все actuator endpoints в public internet. Некоторые endpoints могут раскрыть environment details, configuration или operational internals. В production actuator endpoints обычно ограничивают network rules, Spring Security или обоими способами. Public load balancer может нуждаться в health и readiness, но ему не нужны полные metric details или environment dumps.
Реальная последовательность диагностики
Представь, что users жалуются: checkout стал медленным. Полезное расследование идет по шагам. Сначала смотри dashboards: выросла ли p95 latency или проблема только у одного user? Потом смотри error rate: растут ли 5xx responses? Затем проверь database pool metrics: не закончились ли connections? Потом по logs с correlation id пройди один медленный request через controller, service, repository и external calls. Если есть tracing, проверь, где ушло время: в этом service, database или другом service.
Главная идея: logs, metrics и traces - не отдельные игрушки. Metrics показывают, что что-то изменилось. Logs объясняют, что случилось в конкретном request. Traces показывают, где было потрачено время между boundaries. Actuator и Micrometer дают Spring Boot приложению стандартный способ публиковать эти signals.
Частые ошибки
- Воспринимать
/actuator/healthкак public debug page, а не infrastructure signal. - Мониторить только CPU и memory, игнорируя latency, error rate и database pool usage.
- Писать logs без request ids, из-за чего incident investigation становится медленным.
- Добавлять dashboards, но не делать alerts, поэтому о проблеме узнают только от users.
Чеклист понимания
- Я могу объяснить разницу между business endpoints и actuator endpoints.
- Я понимаю, почему health, readiness, metrics, logs и traces отвечают на разные вопросы.
- Я могу описать базовую последовательность диагностики медленного или падающего request.