Actuator

애플리케이션의 운영 정보를 HTTP 엔드포인트로 노출하는 Spring Boot 모듈.

주요 엔드포인트

• /actuator/health — 살아 있나 (쿠버네티스 liveness/readiness 프로브)
• /actuator/metrics — JVM · HTTP · DB 풀 등의 지표
• /actuator/prometheus — Prometheus 가 긁어 가는 형식
• /actuator/loggers — 로그 레벨을 재시작 없이 바꾼다
• /actuator/conditions — 자동 설정 조건 평가 리포트
• /actuator/env — 설정값 (민감 정보 주의)

management:
  endpoints.web.exposure.include: health,info,prometheus
  endpoint.health.show-details: when-authorized
  health.livenessstate.enabled: true
  health.readinessstate.enabled: true

기본은 health·info만 노출된다. 전부 여는 설정(include: "*")은 운영에서 위험하다 — /env·/heapdump가 민감 정보를 흘린다.

liveness와 readiness를 구분한다

• liveness — 프로세스가 살아 있나 → 실패하면 재시작한다

• readiness — 트래픽을 받을 준비가 됐나 → 실패하면 로드밸런서에서 뺀다

• 둘을 같게 두면

  • DB 가 잠깐 끊겼을 때 재시작 루프에 빠진다
  • DB 의존성은 readiness 에만 넣는다

메트릭의 공통어 — Micrometer

@Timed("order.create")
void createOrder(...) { ... }

meterRegistry.counter("order.created", "status", status).increment();

Micrometer는 벤더 중립 파사드다(로깅의 SLF4J 같은 위치). Prometheus·Datadog 등으로 내보내는 구현만 갈아 끼운다.

카디널리티 폭발 — 가장 비싼 실수

// ❌ 태그에 고유값을 넣었다
meterRegistry.counter("order.created", "userId", userId).increment();

시계열 하나 = 지표명 + 태그 조합 하나

사용자 100만 명 → 시계열 100만 개

• 모니터링 시스템의 메모리·저장소가 터진다
• 쿼리가 느려지고 비용이 폭증한다

태그에 넣어도 되는 것: 값의 종류가 유한하고 적은 것 status · method · uri(템플릿) · 결과코드 태그에 넣으면 안 되는 것 userId · orderId · email · 원본 URL(경로 변수 포함)

분산 추적

요청 하나에 traceId 를 부여하고 서비스 경계를 넘어 전파한다

• 흩어진 로그를 하나의 여정으로 묶는다

Micrometer Tracing + OpenTelemetry (Boot 3+) 로그 패턴에 %X{traceId} 를 넣으면 로그와 트레이스가 연결된다

세 가지 눈

• 메트릭 — 숫자 추세 — "지금 느린가?" (가볍다·장기 보관)
• 로그 — 사건의 기록 — "무슨 일이 있었나?" (무겁다)
• 트레이스 한 요청의 여정 — "어디서 느린가?" (샘플링해서 수집)

면접 함정

• ❌ "Actuator를 전부 열어 두면 편하다" → /env·/heapdump가 민감 정보를 노출한다.
• ❌ "메트릭 태그는 자세할수록 좋다" → 카디널리티 폭발로 모니터링이 죽는다.