Представьте, endpoint на Spring Boot иногда отвечает за секунды вместо миллисекунд. Как вы будете искать причину?

Диагностика нестабильной латентности endpoint-а

Endpoint, который иногда отвечает секунды вместо миллисекунд — классический случай нерегулярного spike latency. Причин несколько десятков; важен систематический подход от общего к частному.

Шаг 1: Воспроизвести и измерить паттерн

# Запустить 1000 запросов и посмотреть p50/p95/p99
wrk -t4 -c50 -d30s --latency http://localhost:8080/api/endpoint

# Или с hey
hey -n 1000 -c 20 http://localhost:8080/api/endpoint

Смотрите: spike происходит каждые N секунд (GC?), при определённом числе конкурентных запросов (pool exhaustion?), или случайно (внешний сервис?).

Шаг 2: GC — первый подозреваемый

# Включить GC logging в JVM opts
-Xlog:gc*:file=/tmp/gc.log:time,uptime:filecount=5,filesize=20m

# Посмотреть STW паузы
grep "Pause" /tmp/gc.log | awk '{print $NF}' | sort -n | tail -20

Stop-the-world паузы G1 GC >200ms — явная причина spike. Решение: увеличить heap (-Xmx), переключиться на ZGC (-XX:+UseZGC) или Shenandoah для Java 17+.

# ZGC для низких задержек (Java 17+)
java -XX:+UseZGC -Xmx4g -jar app.jar

Шаг 3: Hikari connection pool

# Метрики пула в реальном времени
curl http://localhost:8080/actuator/metrics/hikaricp.connections.pending
curl http://localhost:8080/actuator/metrics/hikaricp.connections.acquire

spring:
  datasource:
    hikari:
      maximum-pool-size: 20        # default 10 — часто мало
      connection-timeout: 3000     # ms, после этого HikariPool exception
      idle-timeout: 600000
      max-lifetime: 1800000
      leak-detection-threshold: 2000  # поймает незакрытые соединения

Если hikaricp.connections.pending > 0 в момент spike — пул исчерпан. Увеличьте maximum-pool-size, но помните: PostgreSQL по умолчанию ограничен 100 соединениями.

Шаг 4: Медленные SQL-запросы

# PostgreSQL slow query log
alter system set log_min_duration_statement = '100';  -- логировать запросы > 100ms
select pg_reload_conf();

# Посмотреть текущие долгие запросы
select pid, now() - query_start as duration, query
from pg_stat_activity
where state = 'active'
order by duration desc;

Если длинный запрос коррелирует со spike — смотрите EXPLAIN ANALYZE, проверяйте индексы, возможный lock wait.

Шаг 5: Distributed tracing

// Spring Boot 3 + Micrometer Tracing
// build.gradle
implementation 'io.micrometer:micrometer-tracing-bridge-otel'
implementation 'io.opentelemetry.instrumentation:opentelemetry-spring-boot-starter'

management:
  tracing:
    sampling:
      probability: 0.1  # 10% в prod, 1.0 при расследовании

В Jaeger или Zipkin откройте медленный trace и посмотрите, какой span занял большую часть времени: HTTP call к внешнему сервису? Redis timeout? S3 upload?

Шаг 6: Thread starvation и blocking code в WebFlux

// ПЛОХО: блокирующий вызов в reactive pipeline
public Mono<Response> handle(Request req) {
    return Mono.fromCallable(() -> jdbcRepo.findById(req.id()))  // блокирует reactor thread!
        .map(this::transform);
}

// ХОРОШО: вынести на boundedElastic
public Mono<Response> handle(Request req) {
    return Mono.fromCallable(() -> jdbcRepo.findById(req.id()))
        .subscribeOn(Schedulers.boundedElastic())
        .map(this::transform);
}

Шаг 7: Внешние зависимости без таймаутов

// RestTemplate с таймаутами
@Bean
public RestTemplate restTemplate() {
    HttpComponentsClientHttpRequestFactory factory =
        new HttpComponentsClientHttpRequestFactory();
    factory.setConnectTimeout(1000);
    factory.setReadTimeout(3000);
    return new RestTemplate(factory);
}

// WebClient (WebFlux)
@Bean
public WebClient webClient() {
    return WebClient.builder()
        .clientConnector(new ReactorClientHttpConnector(
            HttpClient.create()
                .responseTimeout(Duration.ofSeconds(3))
        ))
        .build();
}

Подводные камни

• GC spike невидим без JVM-логов. Actuator не показывает GC-паузы напрямую — нужно либо JVM флаг, либо JMX/JFR.
• Connection pool size * количество реплик. 3 инстанса с pool-size=20 = 60 соединений к PostgreSQL. При default max_connections=100 остаётся мало запаса.
• @Transactional держит соединение до конца метода. Длинный метод с транзакцией + медленный внешний HTTP внутри = соединение из пула заблокировано на всё время HTTP-вызова.
• Kotlin coroutines + Spring MVC. Blocking coroutine dispatcher на I/O-операциях без Dispatchers.IO блокирует общий пул потоков.
• Lazy loading JPA вне транзакции = LazyInitializationException или N+1. Неожиданная загрузка коллекции при сериализации ответа тихо добавляет десятки запросов.
• Scheduled задачи (@Scheduled) делят потоки с Tomcat. По умолчанию Spring использует один поток для всех @Scheduled — долгая задача задерживает остальные, а не HTTP-запросы, но косвенно влияет на состояние системы.
• Кэш без TTL растёт бесконечно. @Cacheable с ConcurrentMapCacheManager без eviction policy приводит к OutOfMemoryError после нескольких часов работы под нагрузкой.
• Распределённый трейсинг не покрывает @Async методы без правильного executor. Trace context теряется при переключении потоков без TaskDecorator, передающего MDC.

• Сразу обвинять Spring Boot, не проверив соседние слои системы
• Чинить симптом без минимального воспроизведения и evidence
• Не учитывать версии, конфигурацию, окружение и recent changes

• Умеет локализовать проблему вокруг Spring Boot
• Двигается от симптома к гипотезам и проверкам
• Отличает баг инструмента от ошибки использования или окружения