정상 로그인도 공통 지연 경보를 만들었습니다

9월 25일 ZITADEL의 SessionService.SetSession 요청을 조사했습니다. 정상적인 자격 증명 검증에도 공통 API 지연 기준보다 긴 시간이 걸려 로그인할 때마다 p95 경보가 발생하는 상황이었습니다.

이 요청을 long polling이나 스트리밍 응답으로 설명하는 것은 맞지 않습니다. 이번에 확인한 사실은 정상 인증 처리 시간이 일반 API의 공통 지연 기준과 달랐다는 점입니다. 특정 암호 알고리즘이 원인이라고 확정하는 별도 profiling 결과는 없으므로 그렇게 기록하지 않습니다.

지연 쿼리에서 SessionService 경로만 제외합니다

아래는 Beyla HTTP histogram의 공통 p95에서 해당 gRPC 경로를 제외하는 핵심 조건입니다. 예제에서는 다른 health, streaming 제외 조건과 최소 요청량 조건을 생략했습니다. 실제 경보에는 기존 조건을 함께 유지합니다.

PROMQL
histogram_quantile(0.95,
  sum by (service_namespace, service_name, le) (
    rate(http_server_request_duration_seconds_bucket{
      http_route!~"/zitadel\\.session\\.v2\\.SessionService.*"
    }[5m])
  )
)

필터는 SessionService 경로에만 적용합니다. ZITADEL의 다른 API 지연은 공통 경보에 남깁니다. 모든 서비스의 지연 임계값을 올리면 느려진 다른 API까지 함께 허용하므로 요청 특성에 맞는 선택 조건으로 범위를 좁혔습니다.

일반 API, 스트리밍, long polling, 인증 검증은 같은 완료 시간 분포를 가진다고 가정하지 않습니다. 다만 이번 경로 제외는 서비스 전용 인증 SLO를 완성한 작업은 아니므로 별도의 지연 목표와 수집 범위는 후속 점검 대상입니다.

SessionService의 5xx는 계속 집계합니다

지연 경보에서 제외한 요청도 실패 여부는 확인해야 합니다. 다음 예제의 5xx 집계에는 SessionService 제외 조건을 넣지 않습니다.

PROMQL
sum by (service_namespace, service_name) (
  increase(http_server_request_duration_seconds_count{
    http_response_status_code=~"5.."
  }[5m])
)

실제 규칙은 요청량과 오류 비율 및 지속 시간도 함께 평가합니다. 정상 인증 지연을 구분하려는 변경이 인증 서버의 실패를 감추는 변경이 되지 않도록 latency selector와 error selector를 따로 확인했습니다.

promtool로 정상 지연과 실제 실패를 대조합니다

Prometheus 규칙 테스트에는 SessionService의 정상 지연이 공통 p95를 올리지 않는 경우, 같은 경로의 5xx는 오류 집계에 남는 경우, ZITADEL의 다른 API 지연은 여전히 포함되는 경우를 둡니다. 임계값을 바꾼 결과만 보는 대신 포함과 제외의 경계를 검사합니다.

대시보드에서는 낮은 요청량에서도 측정값을 보여주고, 경보에는 최소 표본 조건을 적용합니다. 경보가 조용하다는 사실만으로 모든 TLS 트래픽의 계측이나 인증 시스템 전체의 정상을 보장하지 않습니다.