LabHub
배우기 러닝패스 코스

PCA — 프로메테우스 인증 어소시에이트 · 수집 예산과 정보 보존: 라벨이 만든 함정 · 이론

업무는 정상인데 수집기가 거절한다

LabHub 에서 이어서 보기

한 줄 요약

라벨은 설명을 덧붙이는 메모가 아니라 시계열의 주소입니다. 샘플 한도는 수집 예산을 지키지만, 어떤 정보를 잃었는지까지 판단해 주지는 않습니다.

왜 이게 필요했나

결제 서비스를 개선하면서 요청 지표에 사용자 식별자를 붙였습니다. 특정 고객의 문제를 찾기 편할 것 같았습니다.
작은 개발 환경에서는 잘 보였는데 사용자가 늘자 모니터링 대상이 down으로 표시됩니다. 서비스의 상태 확인
주소는 HTTP 200이고 결제 프로세스도 살아 있습니다. 네트워크 장애라고 생각해 재시작하면 잠시 나아진 것처럼
보이지만, 같은 라벨 조합이 다시 쌓이면 문제도 돌아옵니다. 먼저 어느 단계에서 수집을 거절했는지 읽어야 합니다.

Prometheus의 한 시계열은 지표 이름과 전체 라벨 집합으로 구별됩니다. 같은 이름의 카운터라도 user_id가
다르면 다른 시계열입니다. route가 같다는 이유로 자동 합산되지 않습니다. 사람이 라벨 열 하나를 추가했다고
생각하는 변경이 저장소에서는 주소 수의 증가가 됩니다. 사용자 수뿐 아니라 경로·상태 코드·인스턴스와의
실제 조합도 중요합니다. 가능한 조합의 곱은 상한을 추정하는 출발점이지 항상 관측되는 정확한 수는 아닙니다.

어떻게 동작하나

이번 실습은 최대 열두 개의 합성 사용자만 사용합니다. 실제 개인정보를 수집하지 않고 과도한 메모리 부하도
만들지 않습니다. 기준 익스포터는 사용자 네 명의 요청 카운터와 업무 상태 gauge 하나를 노출합니다. 한 번의
응답에는 다섯 샘플이 있습니다. 사용자 수를 열두 명으로 늘리면 같은 지표 이름이라도 카운터 열두 샘플과
gauge 하나, 총 열세 샘플이 됩니다. 별도의 고정 대조 대상은 끝까지 같은 값을 내보냅니다.

| 관측 위치 | 이번 실험에서 답하는 질문 |
| --- | --- |
| 익스포터의 /healthz와 /metrics | 프로세스가 정상 응답하고 어떤 원 데이터를 제공하는가? |
| 현재 적용된 scrape 설정 | 어떤 대상과 제한·필터를 실제로 사용하는가? |
| 대상 API의 health와 lastError | 최근 수집이 성공했으며 실패했다면 이유가 무엇인가? |
| 현재 PromQL 결과 | 저장된 샘플을 어떤 라벨과 값으로 읽고 있는가? |

sample_limit은 한 번의 스크레이프에서 받아들일 샘플 수를 제한합니다. metric relabeling 뒤의 수가 한도를
넘으면 그 스크레이프 전체가 실패하는 설정입니다. 앞에서 여덟 개만 저장하고 나머지를 정상적으로 잘라 주는
페이지 크기가 아닙니다. 실습의 한도를 8로 두면 다섯 샘플의 기준선은 통과하지만 열세 샘플 응답은 거절됩니다.
한도를 넘겼다는 최근 오류와 up=0을 연결하되, 업무 HTTP 200과 대조 대상의 up=1도 같이 남깁니다.

sample_limit을 16으로 올리면 이번 작은 응답은 다시 들어옵니다. 이것은 원인을 좁히는 유용한 실험이지만
계측 설계가 좋아졌다는 증거는 아닙니다. 현재 요청 시계열은 여전히 열두 개입니다. 사용자가 계속 늘어나는
운영 환경에서 제한만 올리면 다음 한도에 도달하는 시점만 미룰 수 있습니다. 8과 16은 원리를 관측하기 위한
실습 숫자이며 모든 서비스에 적용할 운영 권장값이 아닙니다. 실제 예산은 수집 주기·대상 수·지표 종류·보존
기간·질의 패턴과 함께 측정해야 합니다.

지표 이름도 신호의 단위를 전달합니다. 요청 횟수는 누적 counter이고 이름은 pca_checkout_requests_total입니다.
현재 업무 정상 여부는 gauge인 pca_business_ok입니다. 누적 카운터 값의 합계는 이 실험의 정보 보존을 확인하기
위한 값이지 초당 처리량이 아닙니다. 초당 처리량을 구할 때는 각 카운터의 reset을 고려한 rate를 먼저 계산한
후 집계하는 별도의 문제를 풀어야 합니다. 작은 정적 입력으로 두 개념을 섞지 않는 것이 이번 설계의 의도입니다.

현장에서 만나는 모습

사용자 ID, 주문 번호, 전체 URL처럼 값의 범위가 커지는 라벨은 편리한 검색 기능처럼 보입니다. 그러나
메트릭은 모든 사건의 세부 기록을 보관하는 저장소와 역할이 다릅니다. 경로 템플릿이나 제한된 상태 분류처럼
운영 질문에 필요한 차원을 먼저 설계하고, 개별 사건의 맥락은 적절한 로그·트레이스와 연결하는 방법을 검토하세요.
민감한 식별자가 지표에 들어가면 접근 제어와 보존·삭제 범위도 복잡해집니다. 이번의 u1 같은 합성 값은
실제 개인정보를 넣어도 괜찮다는 뜻이 아닙니다.

장애 보고에는 down이라는 단어만 적지 마세요. “업무 HTTP는 정상, 대조군 수집도 정상, 해당 job의 원 응답은
13샘플이고 적용 한도 8 때문에 스크레이프가 실패했다”라고 쓰면 다음 행동이 달라집니다. 프로세스를 재시작할지,
네트워크를 조사할지, 계측 설계를 고칠지 판단할 근거가 생깁니다. 한 번의 관측이 일치하더라도 확인 시각과
최근 스크레이프 시각을 함께 보아야 이전 결과를 새 변경의 결과로 오해하지 않습니다.

다음 실습에서 할 것

정상 기준선부터 원 응답·적용 설정·수집 결과를 보존합니다. 라벨 수를 늘려 한도 거절을 관측하고, 제한을
잠시 높여 같은 원 데이터가 실제로 들어오는지 확인합니다. 이후 두 가지 잘못된 수선과 소스 계측 수정을
비교합니다. 모든 서비스는 개인 VM의 loopback에만 바인딩하고 다른 사람의 모니터링 서버나 운영 설정은
건드리지 않습니다. 실습이 끝나면 VM과 TSDB는 회수되므로 필요한 관측은 만료 전에 따로 보관하세요.

공식 문서