2.3 采样、脱敏与留存

2.3 采样、脱敏与留存

本节摘要：观测系统自己也会成为成本与合规问题。本节处理三件事：其一，记什么不记什么——原则是"元数据全量、正文抽样、错误全采"，头部采样与尾部采样的差别决定了你保住的是统计代表性还是故障现场；其二，PII 脱敏必须在入库前完成，本节给出手机号/邮箱/证件号的正则脱敏示意代码，并强调黑名单字段法的局限；其三，留存分级——热（可下钻全量，714 天）、温（抽样正文，3090 天）、冷（仅聚合指标，一年以上），三档对存储成本的影响是数量级的。这三件事分别对应能力清单 L3 的第 19 问与 L1 的第 7 问，也是第 6 章选型时要拿去问工具的硬指标。

学习目标

• 制定"记什么/不记什么"清单，区分元数据、正文与错误三类数据
• 理解头部采样与尾部采样保住的东西不同，会组合出分层采样方案
• 会写入库前的 PII 脱敏（正则示意），并知道它的适用边界
• 给观测数据设计热/温/冷三档留存与对应的存储成本估算

一、记什么不记什么：三条原则

第 2.1 节定了 span 属性边界（身份/版本/计量/状态/时间全记，正文不记）。这里把它落成数据分层：

采样率参考：正文抽样 1%~5%（社区经验值，示意）；抽样概率必须记录在数据里（sampled=true, rate=0.02），否则第 4 章的在线统计与事后估算全会偏。

头部采样 vs 尾部采样：头部采样在请求进来时就决定记不记（省资源，但故障若发生在没采样的请求上就白瞎）；尾部采样在请求结束时决定（可保住"慢的、错的"再抽样放行，代价是全程都要先缓存）。工程上的常见组合（社区实践）：

（文字流程图）
请求 ──▶ 元数据全量入库
     ──▶ 正文：随机 2% 抽样入库（头部）
     ──▶ 结束时判断：出错 or 耗时>P99 or 被点踩 ──▶ 正文强制入库（尾部补采）
​

二、脱敏：在入库之前，而不是之后

观测库的读写面比业务库宽得多（工程师人手一个查询入口），所以 PII 处理的时点只有一个：入库前。出库再脱敏等于没有脱敏——导出的 CSV、复制的日志、截图的 Dashboard 都是漏点。

# mask_pii.py —— 入库前脱敏：手机号/邮箱/证件号（写法示意，勿当完整方案）
import re

# 规则顺序=匹配优先级：长号段（证件）在前，短号段（手机）在后，
# 并用 (?<!\d)/(?!\d) 边界断言防止手机规则匹配到证件号的中间一段。
RULES = [
    # 18 位身份证：整体替换（先于手机号，否则会被切成"部分脱敏"）
    (re.compile(r"(?<!\d)\d{17}[\dXx]"), lambda m: "<id-masked>"),
    # 11 位大陆手机号：保留前 3 后 2，够排查、认不出人
    (re.compile(r"(?<!\d)1[3-9]\d{9}(?!\d)"), lambda m: m.group()[:3] + "****" + m.group()[-2:]),
    # 邮箱：整体替换，保留域名可判断业务场景（可按需收紧）
    (re.compile(r"[\w.+-]+@[\w-]+\.[\w.]+"), lambda m: "<email@" + m.group().split("@")[1] + ">"),
]


def mask(text: str) -> str:
    for pat, repl in RULES:
        text = pat.sub(repl, text)
    return text


if __name__ == "__main__":
    print(mask("联系 13812345678 或 tom@example.com，证件 11010119900101123X"))
    # → 联系 138****78 或 <email@example.com>，证件 <id-masked>（示意输出）
​

三点必须说破：

1. 正则脱敏是下限不是上限。姓名、地址、病历这类非结构化 PII 靠正则兜不住；高风险场景要上 NER 识别或"以摘要代正文"（只存长度、哈希与实体统计）。另外注意规则冲突：长号段（证件）必须先于短号段（手机）匹配并加数字边界断言，否则手机规则会把证件号"腰斩"成部分脱敏——上面代码的注释就是踩过这个坑的痕迹。
2. 保留可排查性：脱敏后仍要能对齐——138****78 比"统一占位符"好，因为能匹配"同一用户多次出现"。
3. 键名别撒谎：脱敏字段要标记 masked=true，防止下游把它当原文做质量评测输入。

⚠️ 更彻底的顺序是先脱敏再决定留存：若正文抽样样本已脱敏，留存期限可以放长；反之要短。脱敏策略与留存策略是一件事的两面。

三、留存：热、温、冷三档

观测数据的访问模式极度偏斜：99% 的查询发生在数据产生后的几天内，而合规与趋势分析只需要聚合值。按访问模式分档：

存储量级感（示意估算，用于建立直觉）：日调用量 100 万次、每次 span 元数据约 1 KB，则元数据约 1 GB/天；若全量存正文（均值 20 KB/次）就是 20 GB/天，是元数据的 20 倍。抽样 2% 后正文只有 0.4 GB/天——分层数据量差出一个数量级，这就是"元数据全量、正文抽样"的全部理由。

期限确定的两条依据：业务上，与故障复盘周期对齐（多数事故在一周内复盘完，故热档 7~14 天）；合规上，与法务确认用户数据留存上限（脱敏后的聚合指标通常不受限，原文受限）。写进一页纸的《观测数据留存策略》，就是能力清单第 19 问"成文并自动执行"的答案——过期删除要靠任务自动执行，靠人记的制度等于没有。

四、把三件事写成一页策略

建议产出物：一张《观测数据策略表》，每个数据域一行（元数据/正文/错误/反馈/评分），四列（采样、脱敏、留存、负责人）。示例行：

正文层  采样=随机2%+尾部补采(错误/P99/点踩)  脱敏=手机/邮箱/证件正则+摘要化
        留存=热7天→温30天(仅0.1%)→删除      负责人=平台组
​

这张表在第 6 章选型时直接变成对工具的硬性提问：能否按数据域分别配置采样？脱敏发生在采集端还是服务端？留存能否按域设置自动过期？（Langfuse、Phoenix 等的对应能力以官方文档为准。）

本节要点回顾

• 三条原则：元数据全量、正文抽样（1%~5%，社区经验值）、错误全采；抽样率必须随数据记录。
• 头部采样省资源、尾部采样保现场，组合使用；故障样本靠尾部补采兜底。
• PII 脱敏只发生在入库前；正则是下限，保留可排查性，标记 masked。
• 留存热 714 天、温 3090 天、冷聚合一年以上；分层数据量差一个数量级；过期删除必须自动化。

Trace 支柱至此成型：有树（2.1）、有线（2.2）、有闸门（2.3）。下一章沿这条线到钱——token 三本账怎么记、怎么摊、怎么管，第 3 章把"现金流"变成看得见的账本。