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

某公司用一套 Grafana + Loki 服务全公司 8 个业务团队。某天 HR 同事排查入职流程 bug，在 Loki 搜索结果里看到一条 Debug 日志——含候选人手机号和身份证号。不是因为 HR 有特殊权限，而是平台没有做租户隔离：任何人能在 Grafana 里去掉 label filter，看到全部日志。

当可观测性从「一团队一 Grafana」成长为全公司共享基础设施，四件事同时变成刚需：查询隔离（Team A 不可见 Team B）、写入隔离（超量写入不拖垮他人）、标签治理（软隔离的载体）、PII 清洗（合规底线）。成本分摊与存储与成本共用同一套 per-tenant 计量指标。

本文不展开 RBAC 的通用 IAM 实现（见身份与访问控制系列），聚焦可观测性数据平面。

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

1.1 硬隔离

每租户独立 Prometheus + Loki + Tempo + Grafana（或独立 cell）。隔离最强，成本最高。

优点	缺点
故障域独立	运维套数 × N
合规边界清晰	无法跨租户关联 Trace
无 noisy neighbor	资源利用率低

适用：支付、财务、医疗等监管域；或租户间存在竞争对手关系。

1.2 软隔离

共享后端，用 tenant_id / X-Scope-OrgID + 查询层 RBAC 做逻辑隔离。Grafana LGTM 栈默认形态。

1.3 混合隔离

关键租户硬隔离，其余软隔离——国内中大型平台常见。

flowchart TB
  subgraph hard [硬隔离 Cell]
    P1[Prometheus/Mimir]
    L1[Loki]
  end
  subgraph soft [软隔离共享池]
    P2[Mimir multi-tenant]
    L2[Loki multi-tenant]
  end
  GF[Grafana] --> hard
  GF --> soft

二、Grafana Mimir / Loki / Tempo 多租户机制

2.1 X-Scope-OrgID

HTTP header X-Scope-OrgID: <tenant> 标识租户。Distributor、Ingester、Querier 全链路传递。禁止客户端自选 tenant——由网关或 Grafana 注入。

2.2 Mimir overrides

# mimir-runtime/overrides.yaml
overrides:
  team-checkout:
    ingestion_rate: 50000
    ingestion_burst_size: 100000
    max_global_series_per_user: 500000
    max_label_names_per_series: 30
  team-hr:
    ingestion_rate: 10000
    max_global_series_per_user: 100000

2.3 Loki limits

limits_config:
  ingestion_rate_mb: 10
  ingestion_burst_size_mb: 20
  max_streams_per_user: 10000
  max_query_series: 500

2.4 Tempo

同样支持 multi-tenant；trace 写入按 tenant 分 block。

2.5 Grafana 数据源

每个 Team 绑定固定 X-Scope-OrgID；Data Source Permissions 限制可见数据源。

三、Thanos 与 VictoriaMetrics 租户方案

3.1 Thanos

Query Frontend 注入 label tenant="X"；object store 按 prefix 分目录。

3.2 VictoriaMetrics cluster

accountID + projectID 两级；适合超大规模。

3.3 选型

已用 Grafana 云原生栈 → Mimir/Loki/Tempo；已有 Prometheus 联邦 → Thanos multi-tenant。

四、标签治理

4.1 必填 Resource Attributes

team, env, app（OpenTelemetry 语义约定对齐）。

4.2 禁止 label

user_id, request_id, session_id, ip（Metrics）；Logs 中 IP 视 GDPR 场景处理。

4.3 白名单

OTel Collector attributes processor 删除非白名单 label。

4.4 命名空间

com.example.checkout.order_id 避免跨团队冲突。

4.5 审批流程

新 label 提案 → 平台审核等价属性 → 文档登记 → CI 检查。

4.6 基数监控

topk(10, count by (team, label_name) ({__name__=~".+"}))

五、PII 清洗

5.1 哪些算 PII

邮箱、手机号、身份证、信用卡、精确地理位置；user_id 在部分业务场景算 PII。

5.2 为什么在采集层

写入后 compaction、backup、ES 倒排索引均可能残留——见下图管道。

5.3 OTel redaction processor

processors:
  redaction:
    allow_all_keys: false
    allowed_keys: [team, env, app, http.method, http.status_code]
    blocked_values:
      - "(?i)password=.*"
      - "\\b\\d{17}[\\dXx]\\b"

5.4 Vector/Fluent Bit

VRL redact() 或 lua filter；日志正文正则替换。

5.5 自由文本难点

message/description 内嵌 PII——截断 + 正则 + 采样审计。

5.6 季度合规扫描

对 Loki/Tempo 抽样 LogQL/trace 搜索 PII pattern，留审计记录。

六、查询层访问控制

6.1 错误做法

仅靠 LogQL {team="A"}——用户可在 Explore 删掉 filter。

6.2 正确做法

Grafana RBAC + 数据源级固定 header；或 query-frontend 强制注入 tenant。

6.3 跨租户关联

平台团队只读「meta-tenant」；业务租户默认不可跨查。

6.4 API 密钥

每租户独立 service account；轮换与审计。

七、成本分摊（Chargeback / Showback）

7.1 计量指标

cortex_distributor_received_samples_total, loki_distributor_bytes_received_total, query 扫描字节。

7.2 公式

\[\text{TenantShare}_i = \frac{\text{Ingest}_i}{\sum_j \text{Ingest}_j} \times \text{TotalCost}\]

7.3 Showback

Dashboard 展示占比即可驱动行为——Team A 占 35% 时会自查高基数。

7.4 与 20 篇联动

保留期、采样策略按租户 tier 分级——见存储与成本。

八、工程坑点

8.1 伪隔离

无 query 层强制 tenant → 数据泄露。

8.2 user_id label

每用户一条时间序列 → Prometheus OOM。

8.3 ES mapping 自动索引 PII

删 _source 倒排仍在；必须写入前清洗。

8.4 noisy neighbor

单租户日志风暴拖慢共享 Querier——需 per-tenant circuit breaker。

8.5 备份跨租户

S3 bucket 按 prefix 隔离；恢复演练验证不会 cross-tenant restore。

8.6 Trace 中的 PII

span attribute 里的 http.url 可能带 query token——OTel semconv 过滤。

九、落地清单

9.1 隔离

选定硬/软/混合
X-Scope-OrgID 网关注入
Grafana Team 与 tenant 映射表

9.2 治理

标签白名单文档
CI 检查禁止 label
新服务 onboarding checklist

9.3 合规

PII redaction 在 Collector
季度扫描记录
事故泄露 runbook

9.4 成本

per-tenant ingest Dashboard
Top10 租户月报

十、关键概念回顾

软隔离依赖 tenant header + 查询 RBAC，不是 label filter alone。
PII 必须在采集/Collector 层处理。
标签治理是多租户与成本控制的基础。 ## 十一、常见误解

误解	事实
Mimir 多租户开箱安全	必须配 overrides + Grafana 权限
日志里打 user_id 方便排障	高基数 + PII 双违规
存储层删除即合规	backup/索引可能残留

十二、下一步

多租户与安全就绪后，用混沌工程验证隔离与告警在故障注入下是否仍有效。

参考资料

Grafana Mimir, Multi-tenancy, https://grafana.com/docs/mimir/latest/operators-guide/architecture/multi-tenancy/
Grafana Loki, Multi-tenancy, https://grafana.com/docs/loki/latest/operations/multi-tenancy/
OpenTelemetry Collector Contrib, redactionprocessor
GDPR, Article 4(1) personal data definition
本站存储与成本
本站埋点哲学
本站日志管道
本站 IAM 系列

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

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

读完这篇，下一步读什么

优先读同系列或同问题的下一篇，把单篇消费变成主题集群。

2026-06-18 · architecture / observability

文章导航

目录