사용자별 지연을 보고 싶어 메트릭 라벨에 사용자 ID를 넣었습니다. 어떤 문제가 생기고 개별 요청은 어떻게 분석하나요?

라벨 조합마다 별도의 시계열이 만들어지는 메트릭 시스템에 사용자 ID·주문 ID·원문 URL을 넣으면 시계열 수가 빠르게 증가합니다. service, route, status와 사용자 수를 곱하면 수집기 메모리, remote write, 저장 인덱스, 대시보드 조회 비용이 함께 커지고, 사용자가 계속 늘어나는 동안 비용도 계속 증가합니다. 자유로운 오류 메시지까지 label로 사용하면 작은 문구 차이도 새로운 시계열이 됩니다. 이 문제를 고카디널리티라고 합니다.

메트릭과 개별 사건의 역할을 나눕니다

서비스·정규화한 route·method·status class·오류 분류처럼 bounded label로 지연 분포와 SLO를 집계합니다. /users/123/orders는 /users/{id}/orders로 바꾸고, 오류 원문은 구조화 로그의 안전한 필드나 제한된 분류로 보냅니다. 사용자별 원인을 알고 싶다면 메트릭에 모든 ID를 곱하는 대신 trace ID와 로그 상관 ID를 사용하고, 일부 메트릭 표본에서 trace로 이동하는 exemplar를 제한적으로 사용하겠습니다. 개인 식별자와 비밀값은 비용과 별개로 수집·보관 위험이 있으므로 원문을 무조건 남기지 않습니다.

classic histogram은 bucket 수만큼 저장할 시계열이 늘고, 각 label 조합에 bucket·sum·count 시계열이 곱해질 수 있으므로 label 수와 bucket 수를 함께 예산화해야 합니다. 테넌트별 SLO가 정말 필요하다면 상위 테넌트만 허용하거나 별도 집계·샘플링·예산을 둡니다. label을 모두 없애면 원인 분류와 알람의 유용성이 사라지므로, 질문에 필요한 구분과 조합 상한을 먼저 정의합니다. 배포 전 예상 series 수와 신규 생성률을 계산하고 배포 후 메모리·수집 지연·remote write 실패를 관찰하겠습니다.

관측 설계를 검증합니다

전체 요청 메트릭은 낮은 카디널리티로 유지하고, 특정 느린 요청은 trace·로그에서 원인과 입력을 확인합니다. 동적 URL 정규화, 오류 분류, exemplar 샘플률을 적용한 뒤 같은 진단 질문에 답할 수 있는지 대조합니다. 사용자별 지표가 필요해도 익명화·상위 집계·기간 제한을 적용하고, 저장 기간과 접근 권한을 분리합니다. 좋은 관측성은 모든 값을 메트릭에 넣는 것이 아니라 각 신호가 감당 가능한 비용으로 답할 질문을 갖는 것입니다.

고카디널리티는 비용뿐 아니라 장애 때 수집기 자체를 압박하는 문제입니다. 예를 들어 사용자 100만 명, route 20개, status 5개에 histogram bucket 10개를 곱하면 잠재 조합이 급격히 늘어나며, 실제 사용자가 계속 바뀌면 series 생성도 계속됩니다. 사용자 ID·주문 ID·원문 URL·자유 오류 문구는 label이 아니라 로그나 trace의 제한된 필드로 보내겠습니다.

route는 /users/{id}/orders처럼 정규화하되, 서로 다른 동작을 하나로 합치지 않는지 검증합니다. 장애 때 허용 목록 밖 값은 bounded한 other로 보내고 신규 series 생성률을 경보로 두되, trace·로그 샘플링도 저장소가 포화되면 낮추는 보호 정책을 둡니다. 메트릭에는 service·route·status class 같은 집계 질문만 남기고, 개별 요청은 상관 ID와 trace에서 확인하겠습니다.

예를 들어 사용자 100만 명에 route 20개, status 5개, bucket 10개를 곱하면 잠재 series 조합이 급격히 커집니다. 실제로 모든 조합이 생성되지 않아도 신규 사용자와 오류 문구가 계속 유입되면 수집기 메모리와 remote write가 압박됩니다. bounded label과 trace·로그의 개별 분석을 분리하겠습니다.