可观测性数据：既要降本，也别把有用信号丢了

——Echo_Wish，运维那点事儿，聊得明白，写得接地气

先说结论：可观测性（metrics、logs、traces）不是堆数据的游戏，是把可用信号用对地方的艺术。降本不是把数据统统扔掉——是聪明地缩减频率、压缩表示、分层存储，在保证故障排查和SLO追踪能力不受损的前提下，把账单砍下来。

下面我把这些实战经验按“为什么/怎么办/怎么做”的逻辑来讲，配点代码示例，让你看完就能牵着工程师上手改造。

一、先问三个问题（决定策略的三把尺子）

1. 这个数据用于什么？（告警？容量规划？事后取证？）
2. 最差能接受的精度是多少？（比如 1s → 10s、直方图 bins 粗化）
3. 查询/排查的常见场景是什么？（按时间范围、按主机、按trace id）

这三问能帮你把数据分成：热路径信号 / 冷路径信号 / 可抛弃噪声。别用一把尺子量所有数据，那就完了。

二、策略一：分级/分层存储 —— 热数据近端，冷数据归档

思路：短期内（比如 7/14/30 天）把高精度原始数据保留在高性能（高成本）存储，超过保留期后降精度或移动到廉价对象存储。

实现要点：

• 热层：高分辨率 metrics、最近 7 天索引化日志、Trace 原始样本（100% 或采样率高）
• 冷层：降采样 metrics（分钟粒度）、日志压缩成文本块（Parquet/ORC）、Trace 只保留 span 索引 & 关键错误样本

示例策略（伪配置）：

metrics.retention:
  - hot: resolution=1s retention=7d store=tsdb-fast
  - warm: resolution=10s retention=30d store=tsdb-cheap
  - cold: resolution=60s retention=365d store=object-storage

三、策略二：智能采样（不是简单抽样）

对 traces、日志、甚至高频 metrics，用“条件采样”远比固定比例好。核心思想：

• 错误/异常：100%保留
• 高延迟/高错误率的事务：全部保留
• 正常低价值事务：按概率采样（比如 0.1%），或按每分钟 N 个采样

示例：简单的 trace 采样器（Python 风格伪码）：

import random

def should_keep_trace(trace):
    if trace.is_error(): return True
    if trace.duration_ms > 2000: return True
    # 基线抽样：按服务名与环境分层
    base_rate = {"payment": 0.01, "web": 0.001}.get(trace.service, 0.001)
    return random.random() < base_rate

这种“规则 + 随机”的混合采样能保留关键事件，同时把一般噪声砍掉很多。

四、策略三：压缩与表达替代（少量比特表达更多信息）

• Metrics：使用 delta-encoding + run-length 或时序专用压缩（Gorilla-like），节省网络与存储。
• Logs：转结构（JSON → columnar Parquet），把常见字段列化，重复内容字典化。
• 分布/直方图：用 t-digest 或 HDR histogram 表示分位数，不必保留所有样本。
• 标签稀疏化：把高基数标签（user_id）从主时间序列表剥离，存为索引表或按需要联查。

示例：把日志批量写成 Parquet（伪代码）：

# 假设 batch 是 dict list
import pyarrow as pa, pyarrow.parquet as pq
table = pa.Table.from_pylist(batch)
pq.write_table(table, 'logs/2025-12-01/part-000.parquet', compression='SNAPPY')

Parquet 的列式存储、字典编码，能把重复键值压缩好几倍，查询也能更快。

五、策略四：保留关键索引、删减原文

很多时候查问题是基于“索引（timestamp, trace_id, service, error_code）+ 少量上下文”，原文可以只保留头尾（first/last N lines）或按需展开。

• 保存一条错误日志的 hash + context_snippet，需要时按 hash 去冷层拉取全文。
• 日志全文入廉价对象存储，并保留索引用于快速定位。

六、策略五：TTL、压缩作业与延迟合并

定时 batch job 做两件事：

1. 对超过 XX 天的数据按规则降采样/合并（例如把 1s → 60s 聚合）
2. 把旧数据打包成压缩块并迁移到冷存（对象存储），同时保留少量索引元数据

示例：Spark/Presto 上的离线合并 SQL（伪）：

INSERT INTO metrics_60s PARTITION(day)
SELECT floor(ts/60) as ts60, host, avg(value) as avg_val
FROM metrics_1s
WHERE ts < date_sub(current_date, 7)
GROUP BY floor(ts/60), host;

七、监控与验证：降本不能降可观测性

任何改动都要 可量化验证：

• 对比降采样前后的 SLI/SLO 报告（例如 95% 响应时是否变化）
• 用 A/B 或 shadow 路径：一部分流量走新策略，评估告警误报/漏报率
• 保存“回滚点”：如果某个压缩策略导致问题排查效率下降，要能快速还原

八、实战小结（二十句话版）

1. 先把数据按用途分类，再制定不同保留策略。
2. 热冷分层存储，热用高IO，冷用对象存储。
3. 智能采样（规则+概率）比盲目抽样效果好。
4. 列式/Parquet 能显著降低日志成本并加速查询。
5. 用直方图/tdigest 表示分位数，替代全部样本。
6. 移除或归档高基数标签的原始列，保留索引。
7. 定期合并老数据并降采样。
8. 所有变更都通过指标验证，避免盲目压缩导致排查失效。

最后几句掏心话

降本并不是“把数据都删了”。真正的艺术在于理解信号的价值，用工程化的方式把“有用的少量信息”从海量噪声中提炼出来。做到这点，你既能把云费单砍下去，也能在凌晨三点遇到事故的时候，依然有可靠的数据把你带出坑。