요청 기준 잡기
라우트, method, status, tenant 같은 label로 요청 latency를 나눠 본다.
평균보다 p95와 p99가 운영 체감을 말한다
지표 선택
latency, throughput, error rate 중 사용자 영향이 큰 축을 먼저
고른다
trace/profile
request id, span, flamegraph로 병목 위치를 증거로 좁힌다
대응 기준
SLO, alert, 회귀 점검으로 개선 뒤에도 지켜볼 기준을 둔다
경계별 시간 분리
controller, service, DB, cache, 외부 API 호출 시간을 span으로 나눈다.
한 숫자만 있으면 원인을 찾기 어렵다로그 연결
request id를 로그와 trace, error report에 같이 남긴다.
분산 환경에서는 한 요청을 이어 보는 능력이 중요하다프로파일링
CPU flamegraph, heap snapshot, event loop delay로 코드 내부 병목을 확인한다.
추측으로 최적화하지 않는다알림 기준
SLO와 오류 예산을 기준으로 알림 기준값를 잡고 배포 전후를 비교한다.
너무 예민한 알림은 결국 무시된다Latency
응답 시간 분포
p50, p95, p99를 나눠 일부 사용자 지연을 놓치지 않는다.
평균은 긴 꼬리를 숨긴다
Trace
경계별 시간
DB, cache, message broker, external API 호출 시간을 요청
흐름으로 연결한다.
N+1이나 느린 의존성을 찾는다
Profile
프로세스 내부 병목
CPU 사용, heap 증가, event loop block을 실제 부하에서
측정한다.
로컬 idle 상태는 근거가 약하다
Alert
운영 반응 기준
사용자 영향이 있는 지표와 지속 시간을 기준으로 알림을
만든다.
단일 spike와 지속 장애를 나눈다