可观测性数据：既要降本，也别把有用信号丢了
——Echo_Wish，运维那点事儿，聊得明白，写得接地气
先说结论：可观测性（metrics、logs、traces）不是堆数据的游戏，是把可用信号用对地方的艺术。降本不是把数据统统扔掉——是聪明地缩减频率、压缩表示、分层存储，在保证故障排查和SLO追踪能力不受损的前提下，把账单砍下来。
下面我把这些实战经验按“为什么/怎么办/怎么做”的逻辑来讲，配点代码示例，让你看完就能牵着工程师上手改造。
一、先问三个问题（决定策略的三把尺子）
- 这个数据用于什么？（告警？容量规划？事后取证？）
- 最差能接受的精度是多少？（比如 1s → 10s、直方图 bins 粗化）
- 查询/排查的常见场景是什么？（按时间范围、按主机、按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 做两件事：
- 对超过 XX 天的数据按规则降采样/合并（例如把 1s → 60s 聚合）
- 把旧数据打包成压缩块并迁移到冷存（对象存储），同时保留少量索引元数据
示例：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 路径：一部分流量走新策略，评估告警误报/漏报率
- 保存“回滚点”：如果某个压缩策略导致问题排查效率下降，要能快速还原
八、实战小结（二十句话版）
- 先把数据按用途分类，再制定不同保留策略。
- 热冷分层存储，热用高IO，冷用对象存储。
- 智能采样（规则+概率）比盲目抽样效果好。
- 列式/Parquet 能显著降低日志成本并加速查询。
- 用直方图/tdigest 表示分位数，替代全部样本。
- 移除或归档高基数标签的原始列，保留索引。
- 定期合并老数据并降采样。
- 所有变更都通过指标验证，避免盲目压缩导致排查失效。
最后几句掏心话
降本并不是“把数据都删了”。真正的艺术在于理解信号的价值，用工程化的方式把“有用的少量信息”从海量噪声中提炼出来。做到这点，你既能把云费单砍下去，也能在凌晨三点遇到事故的时候，依然有可靠的数据把你带出坑。
