Scarab 진단 현장 테스트 #033 - Prometheus Remote-Write 레이블 순서 경계

대상: prometheus/prometheus

이슈: prometheus/prometheus#11505

풀 리퀘스트 (Pull request): prometheus/prometheus#18978

현장 연구 (Field Lab) 기록: Prometheus #11505

이번 현장 테스트는 Prometheus의 작지만 중요한 remote-write 경계에 관한 것이었습니다:

레이블 (labels)은 사전식 순서 (lexicographically)로 정렬되어야 하지만, 유입되는 remote-write 레이블이 해당 요구 사항이 강제되기 전의 변환 경로를 통과할 수 있었습니다.

그 범위가 좁기 때문에 좁게 들릴 수 있습니다.

하지만 이것이 바로 Scarab이 가시화하고자 하는 바로 그 유형의 사례입니다.

"remote-write 서브시스템이 고장 났다"가 아닙니다.

"rewrite ingestion"도 아닙니다.

"에이전트가 사냥을 떠나게 두는 것"도 아닙니다.

질문은 더 작았습니다:

저장소의 진실 (repo truth)이 유효하지 않은 입력이 멈춰야 한다고 말하는 지점은 어디이며, 그 진실이 흐려지는 것을 허용하는 실제 경계는 어디였는가?

현장 연구 (Field Lab) 기록

이 사례에 대한 공개 현장 연구 기록은 여기에 있습니다:

https://github.com/scarab-systems/scarab-field-lab/tree/main/field-tests/prometheus-prometheus-11505

기록에는 공개 이슈, 공개 풀 리퀘스트, 수정 범위 (repair scope), 검증 요약 (validation summary), 그리고 비주장 사항 (non-claims)이 포함되어 있습니다.

이 기록은 공개 링크, 상태, 검증, 그리고 주장 경계 (claim boundaries)만을 포함합니다. SDS 소스 코드나 비공개 제품 자료는 포함하지 않습니다.

그 차이가 중요합니다.

공개된 결과물은 현장 기록이지, SDS 자체가 아닙니다.

SDS 결과

SDS는 remote-write 레이블 순서와 관련된 경계 불일치를 드러냈습니다.

공개 이슈는 이미 예상되는 규칙을 식별했습니다:

remote-write 레이블은 사전식 순서 (lexicographically)로 정렬되어야 합니다.

의미 있는 진단 결과는 단순히 "레이블을 정렬하라"가 아니었습니다.

사실, 수정 사항은 유입되는 데이터를 정렬하는 것이 아닙니다.

결과적으로, 유효하지 않은 remote-write 입력은 이후의 변환 경로 (conversion path)를 통해 수용 가능한 것처럼 보이기 전에 거부되어야 한다는 것이었습니다.

그것이 바로 경계 (boundary)입니다.

입력 계약 (input contract)은 remote-write 요청이 해석되는 가장자리 (edge)에 위치해야 합니다.

만약 유효하지 않은 입력이 이 경계를 넘어온 뒤에 정규화 (normalized)된다면, 시스템은 유효한 호출자 (caller)의 동작과 수정된 호출자의 동작을 구분할 수 있는 능력을 상실할 수 있습니다.

실패 양상 (Failure shape)

실패 양상은 미묘했습니다:

1. 레이블 이름이 유효하지 않은 순서로 포함된 remote-write 입력이 도착합니다.
2. Prometheus는 레이블이 정렬되어 있어야 한다는 공개적 및 내부적 기대를 가지고 있습니다.
3. 변환 경로 (conversion path)는 정렬된 형태의 Prometheus 레이블을 생성할 수 있습니다.
4. 이는 유효하지 않은 입력이 변환 후에 깨끗한 상태로 보일 수 있음을 의미합니다.

우려되는 점은 정렬이 기술적으로 불가능하다는 것이 아닙니다.

우려되는 점은 잘못된 계층 (layer)에서 정렬을 수행하면 수신자 (receiver)가 호출자 (caller)에게 전달하는 메시지가 변한다는 것입니다.

만약 remote-write 송신자가 유효하지 않은 데이터를 보낸다면, 수신자는 해당 데이터를 유효하지 않은 입력으로서 거부할 수 있어야 합니다.

만약 수신자가 이를 조용히 정규화해 버린다면, 호출자는 다른 계약을 받게 됩니다:

"어떤 순서로 보내든 상관없습니다. 수신자가 알아서 수정할 것입니다."

이는 해당 이슈에서 설명한 경계가 아니었습니다.

경계 (Boundary)

이번 현장 테스트에서의 경계는 다음과 같았습니다:

유입되는 레이블 데이터가 Prometheus의 내부 레이블 표현 (internal label representation)으로 변환되기 전에 remote-write 요청의 유효성을 검사해야 합니다.

이것은 코드의 경계이기도 하지만, 계약의 경계이기도 합니다.

한쪽에는 외부 remote-write 요청이 있습니다.

다른 한쪽에는 Prometheus의 내부 표현 (internal representation)이 있습니다.

수정 (repair) 작업은 이 교차점 (crossing point)에 위치해야 합니다.

요청이 내부 표현으로 넘어오고 나면, 데이터가 이미 재구성되었을 수 있기 때문에 유효성 검사 실패를 증명하기가 더 어려워질 수 있습니다.

이것이 바로 패치 (patch)가 의도적으로 append 동작 이전, 그리고 변환 경로가 원래의 순서 문제를 지워버리기 전에 배치된 이유입니다.

변경 사항 (What changed)

이 패치는 수정 사항이 적용되는 지원되는 두 가지 remote-write 경로 모두에 대해 명시적인 레이블 순서 검증 (label-order validation)을 추가합니다:

• v1 샘플이 추가(append)되기 전에 remote-write v1 레이블 이름(label names)을 확인합니다.
• v2 샘플이 추가(append)되기 전에 remote-write v2 레이블 참조(label references)를 확인합니다.
• v1의 정렬되지 않은 레이블 시계열 (unsorted-label series)은 기존의 잘못된 레이블 건너뛰기 (invalid-label skip) 경로를 따릅니다.
• v2의 정렬되지 않은 레이블 시계열 (unsorted-label series)은 기존의 부분 쓰기 잘못된 요청 (partial-write bad-request) 경로를 따릅니다.
• 두 가지 요청 형태 (request shapes) 모두에 대해 회귀 테스트 커버리지 (regression coverage)가 추가되었습니다.

풀 리퀘스트 (pull request) 링크는 다음과 같습니다:

https://github.com/prometheus/prometheus/pull/18978

변경 된 파일은 공개되어 있습니다:

• storage/remote/write_handler.go
• storage/remote/write_handler_test.go

이 패치는 remote-write 수집 (ingestion) 구조를 재설계하지 않습니다.

remote-read를 변경하지 않습니다.

새로운 검증 프레임워크 (validation framework)를 도입하지 않습니다.

현장 테스트 (field test)를 통해 식별된 특정 경계 (boundary)에 수정을 유지합니다.

이것이 광범위한 재작성이 아닌 이유

이것은 Scarab 현장 테스트에서 반복되는 교훈 중 하나입니다:

경계가 명확할 때, 수정 사항은 더 커지는 것이 아니라 더 작아져야 합니다.

코드 에이전트 (code agent)는 매우 빠르게 대규모 패치를 생성할 수 있습니다.

그것은 더 이상 어려운 부분이 아닙니다.

어려운 부분은 패치가 무엇을 주장할 수 있는지 결정하는 것입니다.

이 사례의 경우, 주장은 다음과 같지 않습니다:

"이제 remote-write 검증은 완벽합니다."

주장은 다음과 같습니다:

"사전적 순서 (lexicographic order)에서 벗어난 유입 remote-write 레이블들이 내부 레이블 표현 (internal label representation)으로 정규화 (normalized)되기 전에 확인됩니다."

이것은 훨씬 더 좁은 범위의 진술입니다.

또한 리뷰하기에도 더 용이합니다.

진단 결과가 중요했던 이유

실질적인 버그는 레이블 순서 (label ordering)에 관한 것입니다.

더 큰 현장 테스트의 가치는 방법론에 관한 것입니다.

현대의 코드 에이전트들은 저장소 (repository)를 탐색하고 편집 사항을 생성하는 데 매우 능숙합니다. 그것은 유용할 수 있지만, 의도가 불분명할 경우 패치를 의심스럽게 만들 수도 있습니다.

Scarab의 입장은 다릅니다:

먼저 진실의 경계 (truth boundary)를 찾은 다음, 오직 그 경계만을 수정합니다.

이 경우, 저장소(repo)의 진실은 레이블(labels)이 정렬되어야 한다는 것이었습니다.

경계 실패(boundary failure)는 remote-write 입력이 원래의 잘못된 순서가 더 이상 보이지 않는 표현(representation) 영역으로 넘어갈 수 있었다는 점이었습니다.

패치(patch)는 거기서부터 도출되었습니다.

에이전트(agent)가 수정 사항을 추측했기 때문이 아닙니다.

공개된 이슈(public issue), 코드 표면(code surface), 그리고 검증 경계(validation boundary)가 좁은 범위의 수리(repair)를 가리켰기 때문입니다.

이것이 제가 공개적으로 테스트하고 있는 전환점입니다:

코드 에이전트(code-agent)의 작업은 "무엇을 생성할 수 있는가?"로 시작해서는 안 됩니다.

"저장소가 이미 참이라고 명시한 내용을 어디서부터 강제하기를 멈췄는가?"에서 시작해야 합니다.

검증 (Validation)

수리 사항은 공개 PR(pull request)에 사용된 Prometheus 테스트 워크플로(workflow)를 사용하여 Linux arm64 컨테이너에서 검증되었습니다.

현장 실험실(Field Lab)에 기록된 검증 내용:

• make test 통과
• make lint 통과
• go test ./storage/remote -count=1 통과

이 초안이 작성된 2026년 6월 19일 당시, 공개 풀 리퀘스트(pull request)는 열려 있었으며 리뷰를 받을 준비가 되어 있었습니다.

공개 상태는 다음과 같습니다:

• PR 오픈됨
• DCO 통과
• Netlify 배포 미리보기(deploy-preview) 성공 또는 정보 제공
• 업스트림(upstream) 리뷰 필요

그 상태 또한 중요합니다.

이 현장 보고서는 업스트림 수락을 주장하지 않습니다.

이것은 공개적인 진단 기록, 좁은 범위의 수리, 그리고 제출된 PR을 주장하는 것입니다.

패치가 업스트림에 포함될지 여부는 메인테이너(maintainers)가 결정합니다.

현장 테스트 결과 (Field test result)

결과:

진단 증거 및 수리 사항 제출됨.

현장 테스트를 통해 다음이 생성되었습니다:

• 공개 이슈-경계 기록 (public issue-to-boundary record)
• 좁은 범위의 수리 패치 (narrow repair patch)
• 수리된 동작에 대한 회귀 테스트 커버리지 (regression coverage)
• 검증 요약 (validation summary)
• 공개 업스트림 PR (public upstream PR)

패치는 의도적으로 지루합니다.

그것이 핵심입니다.

흥미로운 점은 코드 변경이 존재한다는 사실이 아닙니다.

흥미로운 점은 독점적인 진단 로직을 노출하거나 메인테이너에게 블랙박스(black box)를 믿어달라고 요구하지 않고도 수리 경계(repair boundary)를 설명할 수 있다는 것입니다.

공개 주장 (Public claim)

이 현장 테스트는 다음과 같은 좁은 범위의 공개 주장을 뒷받침합니다:

SDS는 Prometheus에서 remote-write 레이블 순서 경계 (label-order boundary)를 식별했습니다. 이 경계에서는 변환 (conversion)을 통해 정규화 (normalize)하기 전에 유효하지 않은 입력값을 확인해야 했으며, 해당 경계에 대해 사람이 제출한 수정 사항 (repair)이 준비되었습니다.

다음 사항은 주장하지 않습니다:

• Prometheus가 해당 패치를 수락했다는 점
• 모든 remote-write 검증 (validation) 문제가 해결되었다는 점
• Scarab이 스스로 프로젝트를 수정한다는 점
• SDS의 출처나 제품 상세 정보가 공개되어 있다는 점
• 메인테이너 (maintainer)들이 Scarab 또는 Field Lab을 지지한다는 점

Field Lab은 이러한 주장들을 분리하여 유지하기 위해 존재합니다.

공개 (Disclosure)

이 현장 보고서는 공개된 현장 테스트 노트, 공개된 이슈 (issue) 및 PR (Pull Request) 기록, 그리고 공개된 Field Lab 기록을 바탕으로 AI 지원 편집을 통해 작성되었습니다. 진단 주장 (diagnostic claim), 수정 경계 (repair boundary), 그리고 최종 문구는 사람이 검토하였습니다.

Scarab Diagnostic Suite는 독점적 (proprietary) 자산입니다. Field Lab은 공개 사례 기록, 이슈 링크, 검증 요약, 그리고 주장 경계만을 공개합니다.

SDS는 증거를 찾습니다. 사람들은 주장을 합니다. 메인테이너는 결정합니다.