초록불인데 요청 77건이 사라졌다

목표

샘플 제한, 라벨 삭제, 지표 제외, 소스 계측 변경을 실제 Prometheus로 비교하고 정보가 보존됐는지 설명합니다.

왜 중요한가

업무가 정상인데 수집이 실패할 수도 있고, up=1인데 필요한 데이터가 사라질 수도 있습니다.
개인 VM 안의 Prometheus 3.14.0, 합성 익스포터, 독립 대조 대상만 사용합니다.
최대 13샘플의 작은 실험이지 대규모 부하·OOM·성능 시험이 아닙니다. 실제 개인정보는 넣지 마세요.
서비스는 loopback에서만 듣고 nobody로 실행합니다. 운영 LabHub나 외부 Prometheus를 변경하지 않습니다.
기존 PCA의 Kubernetes 실습과 달리 이 실습은 실제 로컬 프로세스의 스크레이퍼와 TSDB를 사용합니다.
55분 실습이며 만료 전에 필요하면 연장하세요. 세션 종료 시 VM·TSDB·학생 파일이 회수됩니다.

준비된 환경

Prometheus는 http://127.0.0.1:9098, 익스포터는 http://127.0.0.1:9911, 대조 대상은 9912입니다.
설정은 /etc/pca-cardinality/prometheus.json이며 Prometheus가 읽는 YAML의 JSON 표현입니다.
익스포터 모드는 /etc/pca-cardinality/exporter.json, 학생 답안과 관측은 /root/pca-cardinality에 있습니다.
초기 관측은 initial.json입니다. 시스템 서비스를 재시작하거나 TSDB를 지우지 마세요.
관측된 MainPID와 InvocationID를 기준선과 비교하여 재시작으로 문제를 숨기지 않았는지 확인합니다.

python3 /opt/fixtures/pca_cardinality_lab.py observe는 현재 설정·원 응답·질의를 읽습니다.
complete N은 작성한 답안을 확인하고 한정된 변경과 실제 관측을 보존합니다.
2는 합성 사용자 증가, 3은 한도 상향, 4는 구별 라벨 삭제, 5는 요청 지표 제외, 6은 소스 집계와 한도 복귀입니다.
1·7·8은 관측 단계입니다. 지시문의 key=value는 설명이며 JSON 형식 예시에 맞춰 파일을 작성하세요.
관측에는 실제 loaded 설정과 config 선언이 함께 있습니다. 원문과 현재 적용 결과를 나란히 읽으세요.
solve N은 정답 보기와 같으며 없는 답안만 만듭니다. 기존 오답·부분 답안은 직접 수정해야 합니다.
prepare N은 앞 단계만 준비합니다. 현재 답안을 만들지 않습니다. grade N은 읽기만 합니다.

단계

1. initial.json의 실제 기준선에서 원 응답 5샘플, 요청 시계열 4개, 업무 HTTP 200을 확인하세요. baseline.json에 job=pca-cardinality 문자열과 raw_samples=5, current_series=4, business_http=200 정수를 적고 complete 1을 실행합니다. 독립 pca-sentinel 대상의 값은 7, up은 1이어야 합니다.
2. overflow.json에 sample_limit=8, raw_samples=13 정수와 whole_scrape_failed=true, business_failed=false 불리언을 적고 complete 2를 실행하세요. 도우미가 합성 사용자를 4명에서 12명으로 늘립니다. 원 HTTP는 200인데 해당 job의 up=0과 sample limit 오류가 생기는 새 스크레이프를 관측합니다. 일부 8개만 성공했다고 보고하지 마세요.
3. budget.json에 sample_limit=16, current_series=12, total=78 정수와 fixes_instrumentation=false 불리언을 적고 complete 3을 실행하세요. 도우미가 sample_limit을 잠시 올려 promtool 검사와 reload를 수행합니다. 실제 적용 설정과 원 샘플 13개, 현재 요청 시계열 12개, 합계 78을 비교하세요.
4. collision.json에 dropped_label=user_id 문자열, aggregates_values=false 불리언, reported_total=1과 up=1 정수를 적고 complete 4를 실행하세요. metric relabeling에서 구별 라벨만 지웠을 때의 세 표본을 봅니다. 이번 고정 입력에서 원 합계는 78인데 현재 질의는 1입니다. labeldrop을 합산으로 간주하거나 반드시 up=0일 것이라고 추측하지 마세요.
5. drop.json에 dropped_metric=pca_checkout_requests_total 문자열, requests_missing=true와 up_implies_complete=false 불리언을 적고 complete 5를 실행하세요. 요청 지표 family를 제외한 실제 설정을 읽습니다. 원 응답 13개 중 업무 gauge 하나만 남고 up=1이지만 요청 질의는 빈 벡터입니다. 이를 값 0과 구별하세요.
6. instrument.json에 mode=aggregate 문자열, sample_limit=8, current_series=1, total=78 정수와 user_id_removed_at_source=true 불리언을 적고 complete 6을 실행하세요. 익스포터가 route 합계 78을 소스에서 노출하고 임시 필터를 제거합니다. 원 샘플부터 2개이며 합계가 보존되는 세 표본을 확인합니다. 두 서비스의 실행 식별자는 초기와 같아야 합니다.
7. observation-3.json의 result.snapshot.at 숫자를 그대로 읽으세요. history.json에 historical_time=그 숫자, historical_series=12, current_series=1 정수와 deletes_history=false 불리언을 적고 complete 7을 실행합니다. 과거 시각의 실제 질의 count=12, sum=78과 현재 count=1을 비교하세요. series 메타데이터 목록만으로 과거 샘플을 증명하지 않습니다.
8. report.json에 sample_limit=8, semantic_total=78 정수와 unsafe_identifiers=false, zero_loss_from_up=false 불리언을 적고 complete 8을 실행하세요. 현재 정보 보존과 독립 대조군, 서비스 재시작 없음, 과거 샘플 조회를 확인합니다. 8이라는 실습 한도를 모든 서비스의 권장값으로 일반화하거나 개인정보가 자동 삭제됐다고 주장하지 마세요.

참고와 한계

수정은 도우미가 검토한 선언 범위에서만 수행합니다. pending 저널이 남으면 같은 요청을 자동 반복하지 않습니다.
선언 변경과 reload가 완료되고 관측만 실패했다면, 저장된 변경과 선언이 같은지 확인하고 관측만 재시도합니다.
완료 답안·관측·저널을 직접 바꾸면 이후 단계도 실패합니다. 해시는 실수에 의한 덮어쓰기를 탐지하는 장치이며
같은 VM root의 모든 위조를 막는 보안 보증은 아닙니다. 채점은 60초, 이전 단계 준비는 90초 예산입니다.
라벨 삭제에서 보인 합계 1은 고정 버전·입력의 관측입니다. 항상 첫 값이 남는다는 일반 계약이 아닙니다.
빈 벡터는 값 0과 다릅니다. 현재 집계는 TSDB의 과거 샘플 삭제가 아닙니다. 관리용 데이터 삭제 API는 켜지 않습니다.
원 카운터 값은 합성 누적 횟수이며 초당 처리율이 아닙니다. 지표 차원을 줄이면 잃는 상세 질문도 기록하세요.
세 번의 짧은 관측이 장기간의 성능이나 손실률을 보장하지 않습니다. 8·16은 실습값이지 운영 권장 한도가 아닙니다.
[설정 공식 문서](https://prometheus.io/docs/prometheus/latest/configuration/configuration/) ·
[HTTP API](https://prometheus.io/docs/prometheus/latest/querying/api/)

단계 8개

1. 원 샘플과 현재 시계열의 기준선 읽기
2. 업무가 정상인데 수집만 실패하는 상태 만들기
3. 한도 상향과 계측 개선 구별하기
4. 구별 라벨을 지웠을 때 합계 검증하기
5. 지표를 버려 얻은 초록불 진단하기
6. 소스 계측에서 의미를 보존하며 줄이기
7. 현재 질의와 과거 샘플 구별하기
8. 수집 예산과 정보 보존의 범위 보고하기