多租户与安全：数据隔离、标签治理、PII 清洗

某公司用一套 Grafana + Loki 给全公司 8 个业务团队共用。某天 HR 部门的同事在排查一个入职流程 bug 时，在 Loki 的搜索结果中看到了一条 Debug 日志——里面包含了某个候选人的完整简历信息，包括手机号和身份证号。不是因为 HR 有特殊权限——是因为 Loki 没有做任何多租户隔离，任何人只要知道 Grafana 的 URL 就能看到所有团队的日志。

当可观测性平台从”一个团队一个 Grafana”变成”全公司共享基础设施”，三个新问题同时出现。第一，数据隔离——Team A 能不能看到 Team B 的日志/Trace/指标？第二，成本分摊——每个人的账单怎么算？第三，PII/安全合规——敏感信息怎么在写入存储之前就被拦截？

一、多租户的三种隔离层次

硬隔离：每个租户独立部署一套完整的可观测性栈。最安全——但成本最高。每个团队一个 Prometheus + Loki + Tempo + Grafana 实例——在有 50 个团队的公司中完全不现实。

软隔离：共享基础设施，通过 label/tenant_id 做逻辑过滤 + 查询层访问控制。Grafana Mimir/Loki/Tempo 的原生多租户机制基于 X-Scope-OrgID header——每个请求携带一个 tenant ID，后端根据这个 ID 做数据隔离。Grafana 的 Data Source Permissions 可以限制特定 Team 只能查询特定 tenant。

混合隔离：关键租户（如支付、财务）硬隔离，其他租户软隔离。用最小的额外成本实现最大的安全覆盖面。

二、各主流方案的多租户实现

Grafana Mimir/Loki/Tempo：所有请求必须携带 X-Scope-OrgID header。Ingester/Distributor 根据 tenant ID 做数据分片和隔离。Query Frontend 根据 tenant ID 限制查询范围。Per-tenant limit 配置在 runtime overrides 文件中——每个 tenant 的 ingestion rate、series limit、query QPS 都可以独立配置。

Thanos：通过 Query Frontend 的 label 注入实现软隔离——为每个租户的查询自动追加一个 tenant="X" label filter。

VictoriaMetrics：-cluster 模式下通过 accountID 和 projectID 实现两级多租户隔离（类似于 AWS 的 account → project 结构）。

三、标签治理

标签治理是多租户的基础——没有规范的标签，软隔离就失去了载体。三个最低要求：

• 必填标签：每个服务必须暴露 team、env、app 三个 Resource Attribute。这三个标签是多租户过滤和成本分摊的最小集。
• 标签白名单：哪些标签可以出现在 Prometheus label 中、哪些可以出现在 Loki label 中——由平台团队维护和审批。
• 标签命名空间：不同团队的 attribute 用前缀区分（checkout.order.id vs payment.order.id），避免冲突。

四、PII 清洗

可观测性数据是 PII 泄露的高风险管道——日志正文、Span attribute、Metric label 都可能无意中包含敏感信息。

清洗在采集/Collector 层做，不在存储层做。原因：数据一旦写入存储，即使在 ES mapping 中关了索引、在 Loki 中关了 label——数据已经在磁盘上。而且备份、compaction、副本都可能导致 PII 的二次残留。

清洗策略：

• 正则 blocking：匹配已知 PII pattern（邮箱、手机号、身份证号、信用卡号）→ 替换为 <REDACTED> 或哈希。在 Collector 的 redaction processor 或 Fluent Bit/Vector 的 filter 中实现。
• 字段级 redaction：指定某些已知字段（password、token、secret、authorization header）——无论值是什么，全部删除或替换。
• 截断（truncation）：对高风险的自由文本字段（message、description）做截断——超过 1KB 的部分不进入可观测性管道。

合规审计：定期（每季度）对已存储的可观测数据做抽样扫描——用同样的 PII 正则对 Loki/Tempo/Mimir 做查询，确认没有任何 PII pattern 出现在不应该出现的地方。

五、成本分摊（Chargeback / Showback）

每个租户的存储和查询成本可以通过以下指标计算：

• Mimir/Loki/Tempo 的 per-tenant ingestion rate：cortex_distributor_received_samples_total（Mimir）、loki_distributor_bytes_received_total（Loki）
• Per-tenant query QPS 和扫描数据量：cortex_query_frontend_queries_total、loki_query_frontend_retries_total
• Grafana Usage Insights：每个 Team 的 Dashboard 使用频率和活跃用户数

用这些指标按比例分摊总存储和计算成本。Showback（只展示不扣钱）通常就足够驱动团队优化埋点行为——当 Team A 看到自己占了 35% 的总存储成本时，他们会主动去查是不是有人打了太多 label。

六、关键概念回顾

• 三种隔离：硬隔离（独立栈，成本高）、软隔离（共享 + label/tenant_id 过滤，成本低）、混合（关键租户硬隔离）。
• Grafana 生态的原生机制：X-Scope-OrgID + per-tenant overrides。
• PII 清洗铁律：在采集/Collector 层做，不在存储层做。防止磁盘残留。
• 成本分摊：用 per-tenant ingestion rate + query QPS 按比例分摊。

七、工程坑点

Loki 中用 label filter 做”伪隔离”但没有真正的 query 级别限制。Team A 只要主动去掉 label filter 就能看到全部数据。必须用 Grafana Data Source Permissions 或 LB 层做强制 tenant ID 注入。

PII 在 ES index mapping 中被自动索引。即使删除了 _source 字段——Lucene 的倒排索引中仍保留了词条。必须在写入 ES 之前做 PII 清洗。

多租户 limit 在半夜被某个 Bug 打爆。一个租户的 bug 产生了几十倍正常量的日志——per-tenant ingestion rate limit 触发——但其他租户的查询也因为共享基础设施的 I/O 饱和而变慢。需要 per-tenant 的 circuit breaker（不仅仅限流，还要隔离故障半径）。

八、下一步

多租户和安全治理就绪后，最后一个治理主题——混沌工程。下一篇 混沌工程：ChaosBlade、Chaos Mesh 与可观测性闭环。

上一篇：可观测性存储与成本

下一篇：混沌工程：ChaosBlade、Chaos Mesh 与可观测性闭环

参考资料

1. Grafana Mimir, Multi-tenancy, https://grafana.com/docs/mimir/latest/operators-guide/architecture/multi-tenancy/
2. Grafana Loki, Multi-tenancy, https://grafana.com/docs/loki/latest/operations/multi-tenancy/
3. OpenTelemetry, Collector — Redaction Processor, https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/redactionprocessor