LabHub
배우기 러닝패스 코스

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

라벨을 지우면 정말 합쳐질까

LabHub 에서 이어서 보기

한 줄 요약

라벨 삭제는 합산이 아니고, up=1은 필요한 정보가 모두 보존됐다는 증명이 아닙니다. 원 데이터의 의미와 질의 결과를 대조해야 합니다.

왜 이게 필요했나

지표가 너무 많으니 사용자 라벨만 지우면 해결될 것 같습니다. 열두 개의 카운터가 하나로 보이면 저장 비용도
줄었고 작업도 끝난 것처럼 보입니다. 그런데 합계가 78이어야 하는 실험에서 결과가 1이 됐습니다. 대상 상태는
여전히 up이고 최근 오류 문자열도 비어 있습니다. 화면을 초록으로 만드는 것과 운영자가 묻는 질문을 유지하는
것은 다른 목표입니다. 이 차이는 실제 수집기를 거치기 전에는 놓치기 쉽습니다.

어떻게 동작하나

metric_relabel_configs는 수집한 샘플의 라벨을 바꾸거나 일부 샘플을 제외합니다. labeldrop은 지정된 라벨
이름을 없애는 동작입니다. 서로 다른 user_id가 구별하던 샘플에서 그 라벨을 지우면 같은 이름·같은 나머지
라벨의 주소가 충돌합니다. 이 작업은 여러 counter 값을 더하는 집계 연산이 아닙니다. 공식 문서도 라벨 제거
후에 시계열의 고유성이 유지되는지 주의하라고 합니다.

이번 고정 입력은 사용자별 값이 1부터 12까지이고 합은 78입니다. 실제 Prometheus 3.14.0 탐침에서는
user_id를 지운 뒤 현재 시계열 수가 1, 질의 합계도 1이 됐습니다. up은 1이고 lastError는 비어 있었습니다.
이 결과를 “충돌하면 언제나 첫 값이 보존된다”라는 API 계약으로 일반화하지 않습니다. 버전과 입력·시각을
고정한 이번 관측의 핵심은 labeldrop이 78을 합산해 주지 않았다는 것입니다. 다른 입력이나 버전에서는
다른 오류·거절 형태가 나올 수 있으므로 원 응답과 실제 결과를 직접 확인해야 합니다.

이번 실험의 첫 판정기는 충돌이면 반드시 up=0이 될 것이라고 가정해 실패했습니다. 실제 결과가 예상과
다르다고 서버를 강제로 down으로 바꾸지 않았습니다. 당시 코드와 읽기 전용 관측을 남기고 새 VM에서
입력과 결과를 다시 대조했습니다. 좋은 검증은 자신이 기대한 상태를 만드는 일이 아니라 실제로 일어난 일을
설명하는 일입니다. 시험이 틀렸을 때는 시험의 가정도 수정 대상입니다.

다음 수선은 문제의 요청 지표 전체를 drop하는 것입니다. 원 응답은 여전히 13샘플이지만 수집 후에는 업무
gauge 하나만 남아 한도 안에 들어갑니다. up도 다시 정상입니다. 그러나 요청 카운터 질의는 빈 벡터가 됩니다.
이것을 요청이 0건이라고 보고하면 안 됩니다. 관측해야 할 정보가 없는 것과 값이 0인 표본이 있는 것은
다릅니다. 필터가 의도한 제외인지 장애로 인한 결손인지 질의만으로는 구별하기 어려울 수 있습니다.

| 변경 | 화면에서 좋아 보이는 점 | 반드시 확인할 손실 |
| --- | --- | --- |
| sample_limit 상향 | 수집이 다시 성공한다 | 높은 라벨 조합 수가 그대로 남는다 |
| 구별 라벨 삭제 | 현재 시계열 수가 줄어든다 | 서로 다른 값의 합산과 의미 보존이 보장되지 않는다 |
| 지표 family 전체 제외 | 한도 이내이고 up이 정상이다 | 필요한 업무 질문에 답할 지표가 사라질 수 있다 |
| 소스에서 차원을 설계하고 집계 | 필요한 합계를 적은 시계열로 노출한다 | 삭제한 세부 차원의 질문은 더 이상 답할 수 없다 |

마지막에는 익스포터의 계측 모델을 바꿉니다. 합성 사용자별 상세 값 대신 route 수준에서 집계한 카운터
78을 노출하고 user_id 라벨을 처음부터 내보내지 않습니다. 요청 counter 하나와 업무 gauge 하나이므로
원 응답부터 두 샘플입니다. 임시 필터를 제거하고 sample_limit을 8로 되돌려도 수집이 성공하며 요청 합계는
78로 유지됩니다. 필터 뒤에서 조용히 버리는 것과 원천에서 필요한 차원을 설계하는 것을 구별하는 단계입니다.

현장에서 만나는 모습

대시보드의 sum은 질의 결과를 합산합니다. 그 질의를 저장했다고 이미 수집한 사용자별 시계열이 TSDB에서
지워지는 것은 아닙니다. 실습에서는 현재 시계열 수와 과거 평가 시점의 질의를 나란히 봅니다. 개선 후 현재는
한 시계열이지만, 제한을 올려 12개를 수집했던 시각을 지정하면 당시 12개와 합계 78을 다시 확인할 수 있습니다.
series API의 라벨 목록만으로 그 시간에 실제 표본이 있었다고 단정하지 않고, 평가 시각을 명시한 실제
PromQL 결과를 함께 남깁니다. 메타데이터 목록과 시계열 샘플은 같은 증거가 아닙니다.

이 실습은 TSDB 삭제 API를 켜거나 데이터를 삭제하지 않습니다. 소스 계측 수정이 과거 민감 정보를 자동으로
지운다고 주장하지 않기 위해서입니다. 운영에서 보존 정책이나 삭제를 다룰 때는 별도의 권한·백업·감사·영향
범위를 검토해야 합니다. 여기서는 사용자 ID가 모두 합성 값이며 현재의 계측 수정과 과거 데이터 보존이라는
서로 다른 문제를 안전하게 구분하는 데 집중합니다.

현재 정보가 제대로 보존되는지도 단일 숫자로 끝내지 않습니다. 익스포터의 원 응답, 현재 적용 설정, 최근
스크레이프 시각, 현재 counter 합계, 독립 대조군을 함께 읽습니다. 서비스 프로세스의 실행 식별자가 유지되는지
확인해 재시작으로 상태를 초기화하지 않았음을 기록합니다. 단기 표본에서 정상인 것과 장기간의 성능·손실률을
검증한 것은 다르며, 이 작은 실험은 대규모 부하 시험을 대신하지 않습니다.

다음 실습에서 할 것

한도 상향, 충돌하는 라벨 삭제, 지표 제외, 소스 집계를 차례로 비교합니다. 최종 보고서에는 up만으로
정보 보존을 보장할 수 없는 이유, 유지한 업무 질문, 의도적으로 버린 상세 차원, 현재 수정으로 과거가 지워지지
않는다는 점을 적습니다. “수집 성공”과 “의미가 맞는 관측”을 따로 검증하는 습관이 이번 실습의 산출물입니다.

공식 문서