监控与可观测性平替：开源栈组合
商业可观测性平台按主机、日志量和自定义指标计费，成本容易失控。本文给出用开源组件组合替代的思路，并说明自建的运维投入与数据保留策略。
核心要点
- 商业可观测性成本主要随日志量和自定义指标增长，需先做数据治理。
- 开源栈通常由指标、日志、链路三个部分组合而成。
- 自建的代价是存储与运维，需要规划保留期和采样策略。
- 先降噪再换工具，往往能省下大部分费用。
一句话结论：可观测性降本，先砍无用日志和高基数指标，再考虑换成开源栈；否则换工具只是换个地方花钱。
为什么现在值得关注
可观测性平台多按采集的主机数、日志量或自定义指标数量计费，随着服务数量增长，账单常常超过计算资源本身。与此同时，开源方案已经能覆盖指标、日志和链路追踪三类需求，通过组合可以搭出基本可用的技术栈。但自建获得的自由，代价是存储成本、集群运维和查询性能调优。
怎么判断
- 数据量：每天产生多少日志、指标和链路数据，需要保留多久。
- 查询需求：是排障时的临时查询，还是长期趋势分析。
- 成本结构：商业方案的计费维度中，哪些增长最快。
- 自建成本：存储、计算、运维人力和高可用设计。
- 保留策略：热数据与冷数据如何分层，采样率如何设置。
新项目可以在架构阶段就控制日志基数，避免后期被动。一个实用的原则是：只采集将来真的会查询的字段，把详细日志留在本地按需开启，而不是默认全部上送长期保存。
常见坑
- 把所有日志原样采集，成本随流量线性上升。
- 指标标签基数过高，存储和查询迅速膨胀。
- 只算软件成本，忽略自建集群的运维人力。
- 没有采样和保留策略，冷数据长期占用高价存储。
行动清单
- 统计日志量与高基数指标来源，先做降噪和采样，砍掉明显无用的部分。
- 明确保留期，做冷热分层，把老数据移到更便宜的存储。
- 选一组开源组件做小范围试点，对比查询体验和运维负担。
- 设定成本与容量的定期复盘机制，每月看一次增长趋势，提前发现异常。
- 把排障常用查询整理成模板，确保换工具后团队的上手成本不会太高。
注意事项
- 具体计费规则与产品能力会变化，请以公开页面为准。
- 涉及生产系统稳定性，请咨询专业人士或查看官方信息。
参考资料
本文参考以下公开信息源，具体数据与表述以原始来源为准。