마스킹했는데 이메일이 저장소에 남았다

목표

같은 스팬 6개를 처리기 순서·파이프라인 구성만 바꿔 실제 컬렉터에 흘리고, 결과 스팬 수·남은 이메일·커넥터가 센 값이 어떻게 달라지는지 확인한 뒤 운영용 파이프라인 한 벌을 완성합니다.

왜 중요한가

컬렉터 설정은 문법이 맞아도 순서가 틀리면 조용히 다른 일을 합니다. 속성을 만드는 처리기보다 그 속성으로 거르는 처리기가 앞에 서면 거르기가 아무것도 못 하고, 키 이름으로 지운 개인정보는 다른 속성 값에 남으며, 여러 파이프라인에 붙은 리시버는 각자 사본을 넘깁니다. 개인정보 가리기와 비용 지표가 파이프라인 어느 자리에 있느냐로 결과가 갈리므로, 설정을 읽는 눈과 실제로 흘려 확인하는 습관이 함께 필요합니다.

준비된 환경

python3 /opt/fixtures/otca_order_lab.py init 이 /root/otca-order/ 에 spans.json(스팬 6개), processors.yaml(처리기 정의 모음), base.yaml(처리기 없는 기준 설정)을 둡니다. python3 /opt/fixtures/otca_order_lab.py run 설정.yaml 은 lab-k8s 이미지의 otelcol-contrib 0.116.0 을 실제로 띄워 스팬을 OTLP/HTTP 로 보내고, file 익스포터가 쓴 결과를 요약해 /root/otca-order/out/ 에 복사한 뒤 컬렉터를 끕니다. 여러분이 따로 띄운 컬렉터와 부딪히지 않도록 사본에서 리시버 포트와 file 경로만 바꿉니다. 처리기와 순서는 그대로입니다. 채점기도 같은 방식으로 여러분의 설정을 다시 돌립니다.

단계

1. python3 /opt/fixtures/otca_order_lab.py init 으로 재료를 만든 뒤 python3 /opt/fixtures/otca_order_lab.py run /root/otca-order/base.yaml 을 실행합니다. 실제 otelcol-contrib 가 뜨고 spans.json 의 스팬을 받아 file 익스포터로 씁니다. 요약을 보고 /root/otca-order/01-baseline.txt 에 spans=, spans_with_user_email=, spans_with_any_email=(어느 속성 값에든 이메일이 든 스팬 수)를 적으세요.
2. /root/otca-order/filter-first.yaml 을 만듭니다. base.yaml 에 processors.yaml 의 filter/health 와 transform/route 정의를 그대로 복사하고, traces 파이프라인 처리기를 [filter/health, transform/route] 순서로 둡니다(file 경로는 out/filter-first.json). run 결과를 /root/otca-order/02-filter-first.txt 에 spans= 와 routes=(요약의 routes 값 그대로)로 적으세요.
3. 같은 두 정의로 /root/otca-order/transform-first.yaml 을 만들되 순서를 [transform/route, filter/health] 로 바꿉니다(out/transform-first.json). /root/otca-order/03-transform-first.txt 에 spans= 와 routes= 를 적고 02 단계와 비교하세요.
4. /root/otca-order/redact.yaml 에 03 단계 순서 뒤로 attributes/redact 를 붙입니다([transform/route, filter/health, attributes/redact], out/redact.json). /root/otca-order/04-redact.txt 에 spans_with_user_email=, spans_with_any_email=, leaked_attribute=(이메일이 남은 속성 키)를 적으세요.
5. /root/otca-order/mask.yaml 에 redact.yaml 의 세 처리기 뒤로 가리기 처리기 하나를 더합니다. transform 처리기의 OTTL replace_all_patterns(attributes, "value", 정규식, "***") 로 모든 속성 값 안의 이메일 모양을 가리세요. 채점기는 스팬 4개가 남고, 어디에도 이메일이 없고, url.query 속성이 notify= 앞부분과 함께 남아 있는지 봅니다.
6. /root/otca-order/fanout.yaml 에 파이프라인 두 개를 둡니다. traces/raw 는 처리기 없이 file/raw 로, traces/clean 은 05 단계의 처리기 네 개를 거쳐 file/clean 으로 내보내고, 둘 다 같은 otlp 리시버를 받습니다. /root/otca-order/06-fanout.txt 에 raw_spans=, clean_spans=, raw_spans_with_any_email= 를 적으세요.
7. /root/otca-order/count.yaml 에서 count 커넥터를 traces 파이프라인(처리기 [transform/route, filter/health])의 익스포터이자 metrics 파이프라인의 리시버로 둡니다. metrics 파이프라인은 file 익스포터(예: file/metrics)로 내보냅니다. /root/otca-order/07-count.txt 에 span_count_metric=(trace.span.count 값)과 counted_after=(traces 파이프라인의 마지막 처리기 이름)를 적으세요.
8. /root/otca-order/final.yaml 을 씁니다. traces 파이프라인은 memory_limiter 로 시작해 batch 로 끝나고, 그 사이에서 경로 정규화 → 헬스체크 버리기 → user.email 지우기 → 값 속 이메일 가리기를 합니다. 스팬은 file 익스포터 하나로, count 커넥터가 센 trace.span.count 는 metrics 파이프라인을 거쳐 다른 file 익스포터로 내보냅니다. 채점기는 otelcol-contrib validate 와 실제 실행으로 스팬 4개·이메일 0개·경로 두 종류·trace.span.count 4 를 확인합니다.

참고

• 처리기 정의(processors:)의 위치가 아니라 service.pipelines.<이름>.processors 목록 순서가 실행 순서입니다.
• 흔한 실수: 정규화보다 거르기를 앞에 두는 것, 키 삭제만으로 개인정보 제거를 끝냈다고 보는 것, 커넥터 앞 처리기가 센 값에 영향을 준다는 것을 잊는 것.
• 이 실습의 가리기 정규식은 연습용입니다. 실제 개인정보 제거는 필드 목록과 검증이 따로 필요합니다.
• [Collector configuration](https://opentelemetry.io/docs/collector/configuration/) · [Transforming telemetry](https://opentelemetry.io/docs/collector/transforming-telemetry/)

단계 8개

1. 처리기 없이 흘린 스팬 6개
2. 거르기를 먼저 두면
3. 정규화를 먼저 두면
4. 키를 지웠는데 이메일이 남았다
5. 속성은 남기고 값만 가리기
6. 같은 리시버, 다른 파이프라인
7. 커넥터는 무엇을 세는가
8. 운영에 올릴 파이프라인 한 벌