mobile wallpaper 1mobile wallpaper 2mobile wallpaper 3mobile wallpaper 4
2684 字
7 分钟
可观测性平台设计
2025-11-07

当可观测性从”几个工具”变成”一个平台”,你需要考虑的问题就从技术选型变成了平台工程——如何让 50 个团队自助使用可观测性工具?如何防止一个团队的错误配置影响其他团队?如何管理数据的生命周期和成本?

一、从工具到平台#

1.1 工具 vs 平台#

维度工具平台
用户运维/SRE所有开发者
入口命令行/APIWeb UI/自助服务
配置手动声明式/自动化
隔离多租户
成本不可见可分配/可追踪
治理策略/配额/审计

1.2 平台架构#

graph TB subgraph 用户层[" 用户层"] DEV["开发者"] SRE["SRE"] PM["产品经理"] end subgraph 接口层[" 接口层"] GRAFANA["Grafana<br/>统一可视化"] API["Platform API<br/>自助服务"] CLI["CLI<br/>开发者工具"] end subgraph 平台层[" 平台层"] IAM["身份与权限"] QUOTA["配额管理"] LIFECYCLE["数据生命周期"] COST["成本追踪"] end subgraph 数据层[" 数据层"] METRIC["指标<br/>Mimir/VM"] TRACE["追踪<br/>Tempo"] LOG["日志<br/>Loki"] PROFILE["性能<br/>Pyroscope"] end DEV --> GRAFANA SRE --> API PM --> GRAFANA GRAFANA --> IAM API --> QUOTA IAM --> METRIC QUOTA --> TRACE LIFECYCLE --> LOG COST --> PROFILE style 用户层 fill:#e8eaf6,stroke:#283593 style 接口层 fill:#e0f2f1,stroke:#00695c style 平台层 fill:#fff3e0,stroke:#e65100 style 数据层 fill:#fce4ec,stroke:#880e4f

1.3 统一平台架构详解#

上面的架构图展示了四层模型。深入每一层的设计:

用户层:不同角色有不同的需求

角色核心需求使用频率典型操作
开发者快速排障、服务监控每天查看面板、搜索日志、查看追踪
SRESLO 管理、告警配置每周配置 SLO、管理告警、容量规划
产品经理业务指标、SLO 报告每月查看 SLO 报告、业务 Dashboard
平台工程师平台运维、成本治理每天管理配额、监控平台健康

接口层:统一入口,多种访问方式

接口适用场景说明
Grafana日常使用面板、Explore、告警管理
Platform API自动化CI/CD 集成、自动注册
CLI开发者工具快速查询、本地调试
Terraform Provider基础设施即代码声明式管理数据源、面板

二、Grafana 统一可视化#

2.1 Grafana 作为平台核心#

Grafana 是可观测性平台的统一可视化层,它连接所有存储后端:

功能说明
统一查询一个界面查询指标/追踪/日志/性能
数据源关联Exemplar、TraceID、ProfileID 跳转
面板管理团队共享、版本控制
告警管理统一告警规则和通知渠道
SLO 管理SLO 定义、错误预算、燃烧率
报表自动化日报/周报

2.2 Grafana 配置#

# Grafana 生产配置
apiVersion: 1
providers:
- name: 'default'
orgId: 1
folder: ''
type: file
disableDeletion: false
editable: true
options:
path: /var/lib/grafana/dashboards
foldersFromFilesStructure: true
datasources:
- name: Mimir
type: prometheus
uid: mimir
url: http://mimir:9009/prometheus
jsonData:
httpHeaderName1: X-Scope-OrgID
secureJsonData:
httpHeaderValue1: ${TENANT_ID}
exemplarTraceIdDestinations:
- name: trace_id
datasourceUid: tempo
- name: Tempo
type: tempo
uid: tempo
url: http://tempo:3200
jsonData:
tracesToMetrics:
datasourceUid: mimir
tracesToLogs:
datasourceUid: loki
filterByTraceID: true
- name: Loki
type: loki
uid: loki
url: http://loki:3100
jsonData:
derivedFields:
- name: TraceID
matcherRegex: '"trace_id":"(\w+)"'
datasourceUid: tempo

2.3 Grafana 生态系统#

Grafana 不仅仅是一个可视化工具,它是一个完整的可观测性生态:

graph TB subgraph Grafana生态["Grafana 生态系统"] GRAFANA["Grafana<br/>可视化平台"] MIMIR["Mimir<br/>指标存储"] TEMPO["Tempo<br/>追踪存储"] LOKI["Loki<br/>日志存储"] PYRO["Pyroscope<br/>性能分析"] ONCALL["OnCall<br/>事件响应"] IRON["IRM<br/>事件管理"] SM["Synthetic Monitoring<br/>合成监控"] FARO["Faro<br/>前端 RUM"] end GRAFANA --- MIMIR GRAFANA --- TEMPO GRAFANA --- LOKI GRAFANA --- PYRO GRAFANA --- ONCALL GRAFANA --- IRON GRAFANA --- SM GRAFANA --- FARO style Grafana生态 fill:#e8f5e9,stroke:#2e7d32 style GRAFANA fill:#c8e6c9,stroke:#2e7d32
组件功能开源Cloud
Grafana可视化
Mimir指标存储
Tempo追踪存储
Loki日志存储
Pyroscope性能分析
OnCall事件响应
IRM事件管理
Faro前端 RUM

三、多租户#

3.1 多租户模型#

模型隔离级别成本适用场景
共享集群 + 标签过滤逻辑隔离小型组织
共享集群 + Org ID数据隔离中型组织
独立集群物理隔离大型/合规要求

3.2 Mimir 多租户#

# Mimir 多租户配置
multitenancy_enabled: true
limits:
# 每租户限制
max_global_series_per_user: 5000000
ingestion_rate: 250000
ingestion_burst_size: 500000
# 按租户覆盖
per_tenant_override_config: /etc/mimir/overrides.yaml
# overrides.yaml — 租户覆盖
overrides:
tenant-payment:
max_global_series_per_user: 10000000
ingestion_rate: 500000
tenant-experimental:
max_global_series_per_user: 100000
ingestion_rate: 10000

3.3 Loki 多租户#

# Loki 多租户
auth_enabled: true
limits_config:
max_streams_per_user: 10000
max_global_streams_per_user: 50000
ingestion_rate_mb: 20
ingestion_burst_size_mb: 30

3.4 多租户的 RBAC 设计#

Grafana 的 RBAC(基于角色的访问控制)是多租户平台的关键:

# Grafana RBAC 配置
# 组织角色
roles:
- name: viewer
permissions:
- dashboards:read
- datasources:query
- explore:use
- name: editor
permissions:
- dashboards:read
- dashboards:write
- datasources:query
- explore:use
- alerts:read
- name: admin
permissions:
- dashboards:read
- dashboards:write
- datasources:query
- datasources:write
- explore:use
- alerts:read
- alerts:write
- users:manage
- org:manage
# 团队级权限
teams:
- name: order-team
members: ["alice", "bob", "charlie"]
role: editor
folders:
- order-service # 只能编辑 order-service 文件夹下的面板
- name: sre-team
members: ["dave", "eve"]
role: admin
folders:
- "*" # 所有文件夹
RBAC 层级说明示例
组织级全局角色(Viewer/Editor/Admin)Admin 可以管理所有数据源
文件夹级限制到特定文件夹order-team 只能编辑 order-service 面板
数据源级限制查询特定数据源某团队只能查询自己租户的数据
面板级限制查看/编辑特定面板产品经理只能查看业务面板
Note

RBAC 的最小权限原则:大多数开发者只需要 Editor 角色(查看+编辑面板),只有 SRE 团队需要 Admin 角色。避免给所有人 Admin 权限——一个误操作的数据源配置变更可能影响整个平台。

四、数据生命周期管理#

4.1 生命周期策略#

数据类型热数据温数据冷数据
指标0-7 天 (15s)7-30 天 (5m)30+ 天 (1h)
追踪0-7 天7-14 天14+ 天 (删除)
日志0-3 天3-14 天14+ 天 (删除)
性能分析0-7 天7-30 天30+ 天 (删除)

4.2 自动化生命周期#

# Tempo 保留策略
compactor:
compaction:
block_retention: 720h # 30 天
compaction_window: 1h
max_block_bytes: 100MB
block_ranges:
- 2h
- 12h
- 24h

4.3 数据生命周期分层设计#

数据生命周期不只是”保留多少天”——它是一个分层存储策略:

graph LR HOT[" 热数据<br/>内存/SSD<br/>0-7 天<br/>15s 分辨率"] --> WARM[" 温数据<br/>SSD/HDD<br/>7-30 天<br/>5m 分辨率"] WARM --> COLD[" 冷数据<br/>对象存储<br/>30-365 天<br/>1h 分辨率"] COLD --> DELETE[" 删除<br/>365+ 天"] style HOT fill:#ffcdd2,stroke:#c62828 style WARM fill:#fff3e0,stroke:#e65100 style COLD fill:#e3f2fd,stroke:#1565c0 style DELETE fill:#e0e0e0,stroke:#757575
层级存储介质访问延迟成本/GB适用数据
内存/SSD< 100ms$0.10-0.50最近 7 天的原始数据
SSD/HDD< 1s$0.03-0.107-30 天的降采样数据
对象存储1-10s$0.005-0.0330+ 天的降采样数据

4.4 各信号的生命周期配置#

# Mimir 生命周期
blocks_storage:
bucket_store:
# 对象存储配置
type: s3
s3:
endpoint: s3.amazonaws.com
bucket_name: mimir-blocks
tsdb:
# 本地数据保留(热数据)
retention_period: 7d
compactor:
# 降采样和压缩
compaction_interval: 30m
downsampling:
- resolution: 5m
retention: 30d
- resolution: 1h
retention: 365d
# Loki 生命周期
schema_config:
configs:
- from: 2024-01-01
store: tsdb
object_store: s3
schema: v13
compactor:
working_directory: /loki/compactor
compaction_interval: 10m
retention_enabled: true
retention_delete_delay: 2h
delete_request_cancel_period: 24h
limits_config:
# 日志保留策略
retention_period: 14d # 14 天后删除
# 按流保留
max_query_length: 720h
# Tempo 生命周期
compactor:
compaction:
block_retention: 720h # 30 天
compaction_window: 1h
max_block_bytes: 100MB
storage:
trace:
backend: s3
s3:
bucket: tempo-traces
# 本地缓存
cache: 1GB

五、自助服务 vs SaaS#

5.1 三种模式对比#

维度自建平台Grafana Cloud混合模式
初始成本高(人力+基础设施)低(按量付费)
运维负担
定制性
数据主权完全控制依赖供应商部分控制
扩展性需要自己管理自动扩展按信号选择
升级维护需要自己管理自动更新部分自动

5.2 选型决策#

graph TB START{团队规模?} --> |"< 20 人"| CLOUD["Grafana Cloud"] START --> |"> 20 人"| Q1{合规要求?} Q1 -->|"数据不能出域"| SELF["自建平台"] Q1 -->|"无限制"| Q2{可观测性是核心竞争力?} Q2 -->|"是"| SELF Q2 -->|"否"| HYBRID["混合模式"] style START fill:#e3f2fd,stroke:#1565c0 style CLOUD fill:#c8e6c9,stroke:#2e7d32 style SELF fill:#fff3e0,stroke:#e65100 style HYBRID fill:#e1bee7,stroke:#6a1b9a
场景推荐理由
初创公司(< 20 人)Grafana Cloud无需运维,按量付费
中型公司(20-200 人)混合模式核心信号自建,非核心用 Cloud
大型公司(> 200 人)自建平台定制性、数据主权、成本控制
金融/医疗自建平台合规要求

5.3 混合模式架构#

混合模式是最常见的选择——核心信号自建,非核心用 Cloud:

信号自建Cloud理由
指标数据量大,自建成本更低
追踪Tempo Cloud 免运维
日志数据敏感,需要数据主权
性能分析Pyroscope Cloud 免运维
前端 RUMFaro Cloud 免运维

六、平台工程实践#

6.1 自助服务#

功能实现方式说明
服务注册GitOps + CRD声明式注册新服务
面板生成Grafonnet/JSON模板化生成标准面板
告警配置Sloth + GitOps声明式 SLO 和告警
数据源配置Platform API自动配置数据源关联
成本查看Grafana 面板每团队可观测性成本

6.2 GitOps 工作流#

graph LR DEV["开发者"] --> PR["提交 PR<br/>slo.yaml"] PR --> CI["CI 验证<br/>语法检查 + 基数检查"] CI --> MERGE["合并到 main"] MERGE --> SYNC["同步到<br/>Prometheus/Grafana"] SYNC --> VERIFY["验证<br/>SLO 面板 + 告警"] style DEV fill:#e8eaf6,stroke:#283593 style CI fill:#e0f2f1,stroke:#00695c style SYNC fill:#fff3e0,stroke:#e65100 style VERIFY fill:#e8f5e9,stroke:#2e7d32
Note

平台工程的核心原则是自助服务——开发者不需要提交工单等待运维配置,而是通过声明式配置自助完成。这减少了运维的瓶颈,也提高了开发者的满意度。

6.3 自定义面板管理#

在大规模组织中,面板管理是一个容易被忽视但非常重要的问题。50 个团队可能有上千个面板,如果没有管理策略,面板质量会急剧下降:

面板管理策略

策略说明工具
模板化使用 Grafonnet 生成标准面板Jsonnet/Grafonnet
版本控制面板定义存储在 Git 中Grafana Terraform Provider
审批流程新面板需要审核GitOps PR Review
自动化测试验证面板查询是否有效CI/CD 集成
标签分类按服务/团队/类型分类Grafana 文件夹 + 标签

Grafonnet 面板模板

grafonnet/dashboard.jsonnet
local grafonnet = import 'grafonnet/grafonnet.libsonnet';
local dashboard = grafonnet.dashboard;
local row = grafonnet.row;
local panel = grafonnet.panel;
// 标准服务面板模板
local serviceDashboard(serviceName, sloTarget='99.9') = dashboard.new(
title='%s Service Dashboard' % serviceName,
tags=[serviceName, 'service'],
).addRow(
row.new(title='SLO Overview')
.addPanel(
panel.stat.new(
title='Availability SLO',
datasource='Mimir',
targets=[
{
expr: '1 - (sum(rate(http_requests_total{service="%s",status=~"5.."}[5m])) / sum(rate(http_requests_total{service="%s"}[5m])))' % [serviceName, serviceName],
legendFormat: 'Current',
},
],
thresholds=[
{ value: parseFloat(sloTarget) / 100, color: 'green' },
{ value: parseFloat(sloTarget) / 100 - 0.001, color: 'red' },
],
)
)
);

6.4 平台团队组织#

可观测性平台团队的组织方式直接影响平台的成功:

模式团队规模职责适用场景
嵌入式0(SRE 兼任)无专职团队< 50 人公司
专职团队3-5 人平台运维+开发50-500 人公司
平台工程5-15 人平台+工具+培训500-5000 人公司
独立部门15+ 人完整平台产品5000+ 人公司

平台团队的职责矩阵

职责嵌入式专职团队平台工程
平台运维SRE 兼任
工具开发有限
用户培训有限
成本治理有限
SLO 咨询
自助服务有限

七、成本治理#

7.1 成本分配#

成本维度分配方式说明
按团队标签 team=xxx每个团队的可观测性成本
按服务标签 service=xxx每个服务的可观测性成本
按信号指标/追踪/日志每种信号的成本占比
按环境env=prod/staging/dev不同环境的成本

7.2 配额与限流#

# 每租户配额
limits:
tenant-default:
max_global_series_per_user: 5000000
ingestion_rate: 250000
max_query_length: 720h
tenant-payment:
max_global_series_per_user: 10000000
ingestion_rate: 500000
Warning

配额不是惩罚,而是保护——它防止一个团队的错误配置(如高基数指标)影响整个平台的稳定性。配额应该基于历史使用量 + 合理增长来设定,而不是随意设定。

7.3 成本可视化#

为每个团队创建成本面板,让成本透明化:

# 按团队的指标序列数
count by (team) ({__name__=~".+"})
# 按团队的日志写入速率
sum by (team) (rate(loki_distributor_lines_received_total[5m]))
# 按团队的追踪写入速率
sum by (team) (rate(tempo_distributor_spans_received_total[5m]))
# 估算成本(按序列数)
count by (team) ({__name__=~".+"}) * 0.0001 # $0.1/千序列/月
成本面板查询说明
序列数趋势count by (team)每团队的序列数趋势
写入速率rate(received_total)每团队的写入速率
查询频率rate(queried_total)每团队的查询频率
成本估算序列数 × 单价每团队的月度成本估算

八、动手实践#

8.1 配置多租户#

# 配置 Mimir 多租户
# 在 HTTP 头部中传递 X-Scope-OrgID
curl -H "X-Scope-OrgID: team-order" http://localhost:9009/prometheus/api/v1/query?query=up

8.2 配置 RBAC#

# 创建团队
curl -X POST http://localhost:3000/api/teams \
-H "Authorization: Bearer $GRAFANA_API_KEY" \
-H "Content-Type: application/json" \
-d '{"name": "order-team", "email": "order-team@company.com"}'
# 添加成员
curl -X POST http://localhost:3000/api/teams/1/members \
-H "Authorization: Bearer $GRAFANA_API_KEY" \
-H "Content-Type: application/json" \
-d '{"userId": 2}'
# 设置文件夹权限
curl -X POST http://localhost:3000/api/folders/order-service/permissions \
-H "Authorization: Bearer $GRAFANA_API_KEY" \
-H "Content-Type: application/json" \
-d '{"items": [{"role": "Editor", "permission": 2}]}'

8.3 验证清单#

检查项验证方式预期结果
多租户隔离不同租户查询数据隔离
配额生效超过配额写入被拒绝
数据源关联Grafana 跳转正常跳转
成本面板查看成本 Dashboard数据正确
RBAC 生效不同角色操作权限正确

九、本章小结#

上一章深入探讨了可观测性规模与成本控制。 以上就是可观测性平台设计的核心内容。

主题核心要点关键词
从工具到平台自助服务、多租户、成本追踪是平台的核心能力。四层模型(用户层→接口层→平台层→数据层)是平台架构的基础。从工具到平台
Grafana 统一可视化连接所有存储后端,提供统一的查询和关联体验。Grafana 生态系统覆盖了指标、追踪、日志、性能分析、事件响应、合成监控等完整场景。Grafana 统一可视化
多租户共享集群 + Org ID 是性价比最高的方案。RBAC 确保最小权限原则。多租户
数据生命周期热→温→冷,降采样降低长期存储成本。不同信号有不同的保留策略。数据生命周期
自助服务 vs SaaS小团队用 Cloud,大团队自建,混合模式是常见选择。自助服务 vs SaaS
平台工程GitOps + 声明式配置,让开发者自助使用可观测性。面板管理、团队组织是平台成功的关键。平台工程
成本治理配额保护平台稳定性,成本可视化让每团队了解自己的可观测性开销。成本治理

支持与分享

如果这篇文章对你有帮助,欢迎支持作者或分享给更多人

可观测性平台设计
https://blog.souloss.com/posts/observability/observability-platform/
作者
Souloss
发布于
2025-11-07
许可协议
CC BY-NC-SA 4.0

部分信息可能已经过时