明明做了脱敏，邮箱还是进了存储

目标

让同样的 6 个跨度（span）只在处理器顺序和管道配置上有所不同，送入真实的 Collector，确认结果中的 span 数、残留的邮箱以及 connector 统计的值会有怎样的变化，最后完成一套可用于生产环境的管道。

为什么重要

Collector 配置即使语法正确，顺序错了也会悄悄做出不同的事。如果按某个属性过滤的处理器排在生成该属性的处理器之前，过滤就什么也做不了；按键名删除的个人信息仍会留在其他属性值里；挂在多个管道上的 receiver 会各自传递一份副本。个人信息脱敏和成本指标处在管道中的哪个位置，会直接决定结果，因此既要会读配置，也要养成实际送入数据来验证的习惯。

已准备的环境

python3 /opt/fixtures/otca_order_lab.py init 会在 /root/otca-order/ 中放入 spans.json（6 个 span）、processors.yaml（处理器定义汇总）、base.yaml（没有处理器的基础配置）。python3 /opt/fixtures/otca_order_lab.py run 설정.yaml（占位符为配置文件名）会真正启动 lab-k8s 镜像中的 otelcol-contrib 0.116.0，通过 OTLP/HTTP 发送 span，把 file exporter 写出的结果汇总后复制到 /root/otca-order/out/，然后关闭 Collector。为避免与你另外启动的 Collector 冲突，只会在副本中修改 receiver 端口和 file 路径，处理器和顺序保持不变。评分器也会以同样的方式重新运行你的配置。

步骤

用 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 中的 span，并通过 file exporter 写出。查看汇总，在 /root/otca-order/01-baseline.txt 中写入 spans=、spans_with_user_email=、spans_with_any_email=（任意属性值中含有邮箱的 span 数）。
创建 /root/otca-order/filter-first.yaml。把 processors.yaml 中的 filter/health 与 transform/route 定义原样复制到 base.yaml，并把 traces 管道的处理器按 [filter/health, transform/route] 的顺序放置（file 路径为 out/filter-first.json）。把 run 的结果以 spans= 与 routes=（原样使用汇总中的 routes 值）的形式写入 /root/otca-order/02-filter-first.txt。
用相同的两个定义创建 /root/otca-order/transform-first.yaml，但把顺序改为 [transform/route, filter/health]（out/transform-first.json）。在 /root/otca-order/03-transform-first.txt 中写入 spans= 与 routes=，并与第 2 步比较。
在 /root/otca-order/redact.yaml 中，把 attributes/redact 接到第 3 步的顺序之后（[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=（仍残留邮箱的属性键）。
在 /root/otca-order/mask.yaml 中，在 redact.yaml 的三个处理器之后再加一个脱敏处理器。用 transform 处理器的 OTTL replace_all_patterns(attributes, "value", 정규식, "***")（占位符为正则表达式）遮盖所有属性值中形似邮箱的内容。评分器会检查：保留 4 个 span，任何地方都没有邮箱，url.query 属性连同 notify= 之前的部分一起保留下来。
在 /root/otca-order/fanout.yaml 中放置两个管道。traces/raw 不经过处理器，导出到 file/raw；traces/clean 经过第 5 步的四个处理器，导出到 file/clean；两者接收同一个 otlp receiver。在 /root/otca-order/06-fanout.txt 中写入 raw_spans=、clean_spans=、raw_spans_with_any_email=。
在 /root/otca-order/count.yaml 中，把 count connector 同时设为 traces 管道（处理器 [transform/route, filter/health]）的 exporter 和 metrics 管道的 receiver。metrics 管道导出到 file exporter（例如 file/metrics）。在 /root/otca-order/07-count.txt 中写入 span_count_metric=（trace.span.count 的值）与 counted_after=（traces 管道中最后一个处理器的名称）。
编写 /root/otca-order/final.yaml。traces 管道以 memory_limiter 开头、以 batch 结尾，中间依次进行路径规范化、丢弃健康检查、删除 user.email、遮盖值中的邮箱。span 通过一个 file exporter 导出，count connector 统计出的 trace.span.count 则经由 metrics 管道，导出到另一个 file exporter。评分器会用 otelcol-contrib validate 和实际运行来确认：4 个 span、0 个邮箱、两种路径、trace.span.count 为 4。

参考

决定执行顺序的是 service.pipelines.<이름>.processors（占位符为管道名称）列表中的顺序，而不是处理器定义（processors:）所在的位置。
常见错误：把过滤放在规范化之前；以为只删除键就完成了个人信息清除；忘记 connector 之前的处理器会影响它统计出的值。
本实验的遮盖正则只是练习用。真正清除个人信息，需要另行制定字段清单并进行验证。
Collector configuration、Transforming telemetry

不经过任何处理器送入的 6 个 span

用 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 中的 span，并通过 file exporter 写出。查看汇总，在 /root/otca-order/01-baseline.txt 中写入 spans=、spans_with_user_email=、spans_with_any_email=（任意属性值中含有邮箱的 span 数）。

即使没有 user.email 键，其他属性值里也可能带有邮箱。请逐行阅读汇总下方每个 span 的属性。

把过滤放在前面会怎样

创建 /root/otca-order/filter-first.yaml。把 processors.yaml 中的 filter/health 与 transform/route 定义原样复制到 base.yaml，并把 traces 管道的处理器按 [filter/health, transform/route] 的顺序放置（file 路径为 out/filter-first.json）。把 run 的结果以 spans= 与 routes=（原样使用汇总中的 routes 值）的形式写入 /root/otca-order/02-filter-first.txt。

filter/health 检查的是 http.route 属性。这个属性由谁、在什么时候生成？

把规范化放在前面会怎样

用相同的两个定义创建 /root/otca-order/transform-first.yaml，但把顺序改为 [transform/route, filter/health]（out/transform-first.json）。在 /root/otca-order/03-transform-first.txt 中写入 spans= 与 routes=，并与第 2 步比较。

管道的 processors 列表是执行顺序，而不是声明顺序。定义块所在的位置无关紧要。

键删掉了，邮箱却还在

在 /root/otca-order/redact.yaml 中，把 attributes/redact 接到第 3 步的顺序之后（[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=（仍残留邮箱的属性键）。

attributes 处理器的 delete 按键名删除。它并不知道其他键的值里混进了邮箱。

保留属性，只遮盖值

在 /root/otca-order/mask.yaml 中，在 redact.yaml 的三个处理器之后再加一个脱敏处理器。用 transform 处理器的 OTTL replace_all_patterns(attributes, "value", 정규식, "***")（占位符为正则表达式）遮盖所有属性值中形似邮箱的内容。评分器会检查：保留 4 个 span，任何地方都没有邮箱，url.query 属性连同 notify= 之前的部分一起保留下来。

delete 会删除整个属性。只想改动值的一部分，就需要模式替换函数。正则表达式会放进 YAML 字符串里，请确认引号。

同一个 receiver，不同的管道

在 /root/otca-order/fanout.yaml 中放置两个管道。traces/raw 不经过处理器，导出到 file/raw；traces/clean 经过第 5 步的四个处理器，导出到 file/clean；两者接收同一个 otlp receiver。在 /root/otca-order/06-fanout.txt 中写入 raw_spans=、clean_spans=、raw_spans_with_any_email=。

处理器只会修改自己所属管道中的数据。receiver 挂在多个管道上时，每个管道都会各自收到同一份数据。

connector 统计的是什么

在 /root/otca-order/count.yaml 中，把 count connector 同时设为 traces 管道（处理器 [transform/route, filter/health]）的 exporter 和 metrics 管道的 receiver。metrics 管道导出到 file exporter（例如 file/metrics）。在 /root/otca-order/07-count.txt 中写入 span_count_metric=（trace.span.count 的值）与 counted_after=（traces 管道中最后一个处理器的名称）。

connector 在一个管道的末端（exporter 的位置）接收数据，再交给另一个管道的起点（receiver 的位置）。它之前的处理器已经执行完毕。

可用于生产环境的一套管道

编写 /root/otca-order/final.yaml。traces 管道以 memory_limiter 开头、以 batch 结尾，中间依次进行路径规范化、丢弃健康检查、删除 user.email、遮盖值中的邮箱。span 通过一个 file exporter 导出，count connector 统计出的 trace.span.count 则经由 metrics 管道，导出到另一个 file exporter。评分器会用 otelcol-contrib validate 和实际运行来确认：4 个 span、0 个邮箱、两种路径、trace.span.count 为 4。

memory_limiter 只有在负载集中时最先拒绝数据才有意义，batch 则必须把所有变换结束后的结果打包。count 要放在丢弃之后，生产环境的指标才准确。