适用场景

可观测性成本涨得最快的地方通常不是数据量，而是「基数」：一个标签塞进用户 ID，指标数量翻几万倍。治理顺序是：先砍高基数，再谈保留期，最后才考虑换存储。

配置步骤（保留策略与成本分摊）

# 保留策略模板
ERROR / 审计日志：90-180 天（合规要求优先）
WARN：30 天
INFO / 访问日志：7-15 天
DEBUG：不采集或 1-3 天（按需开启）

# 分流标签（便于按来源统计成本）
service、env、log_type（access/app/audit/security）

# 成本分摊报表字段
数据源 | 日均量 | 保留天数 | 存储占用 | 月成本 | 环比 | 负责人

# 治理动作
1) Top1 数据源专项治理（通常是访问日志或某个啰嗦服务）
2) 关闭无人查询的索引
3) 冷数据转归档

关键参数与建议

  • 成本构成：采集与传输、存储、查询计算、商业 License 四块分开算
  • 基数治理：禁止把 user_id/order_id/URL 全路径等无界值做标签
  • 采样与聚合：明细降采样保留，聚合指标长期保留
  • 保留期分级：核心服务 30 天、边缘服务 7 天、调试数据 3 天
  • 查询优化：看板刷新频率与查询复杂度要受控
  • License 管理：按节点/数据量计费的授权要核对实际使用量
  • 月度报表：按环境/服务/数据源拆成本，找出增长最快的来源
  • 验收：成本环比稳定，且没有因为省钱丢掉关键可观测能力

容易踩的坑

  • 全部日志统一保留 180 天，成本高但没人看
  • 审计日志与调试日志同策略，合规与成本都没兼顾
  • 没有按来源分摊，谁在烧钱不知道
  • 关闭索引时把还在用的字段一起删了
  • 归档后没有索引入口，等于数据丢了
  • 成本报表只有总额，没有环比与责任人

验证与巡检

# 保留与分摊检查
1) 每类日志有明确保留天数与依据
2) 成本报表按数据源拆分且含环比
3) Top1 数据源有治理记录
4) 归档数据可恢复（半年演练一次）
  • 巡检：策略与合规要求一致、报表按月出具、治理动作有闭环

小结

可观测性成本验收：能说清钱花在哪三类数据上、哪一项增长最快、砍掉哪些数据不影响排障。答不上来就是没治理。

> 说明：文中命令为通用写法，不同型号/版本可能略有差异，落地前请对照设备实际版本的官方文档；带外管理与安全设备变更建议先在测试设备验证。