日志分析平台的成本控制踩坑记录
上个月帮杭州一家做直播电商的团队查云账单，看到日志分析平台那栏的数字的时候，我盯着屏幕愣了三秒。18.7万。三个月的存储+计算费用，占了整个云成本的快40%。
他们运维小哥坐在对面挠头，说当初搭ELK的时候就怕出问题查不到日志，把所有服务的访问日志、业务日志、甚至前端埋点的debug日志全量接了进来，统一存90天，谁知道越跑越贵，每个月的账单都比上个月涨一截，老板已经找他谈过两次了。
直播电商团队ELK集群成本账单截图
很多人碰到这种成本超支的情况，第一反应就是删日志。
我之前见过更极端的，直接把日志保留周期从90天改成7天，结果半个月后出了个交易链路的异常，查不到之前的日志，折腾了三天才找到问题，最后赔了客户好几万。
说实话，全量砍是最蠢的办法。你得先搞清楚，你存的这些日志里，到底有多少是真的有人用的。
就拿这家直播电商的团队来说，我翻了他们过去三个月的日志查询记录，总共才127次查询，其中89次是查接口的错误日志，22次是查交易链路的trace日志，剩下16次查的是推广渠道的访问日志。剩下的那些debug日志、前端点击埋点的详细日志、甚至nginx记录的每个静态资源的访问日志，一次都没被查过。
真的没必要留着。
我让他们先把debug日志的默认采集关掉，只有排查问题的时候才临时开，采集到的日志只存3天，用完就删。就这一项，直接把每天的日志写入量砍了40%。
很多人算日志平台的成本，只会算存储的钱。
错了。
计算成本才是大头。
他们之前的ES集群索引是按周切的，每次有人要查最近一天的日志，集群要扫整整一周的分片，光CPU开销就占了整个集群的60%。上次大促的时候，有个运营要查过去24小时的用户访问路径，跑了个聚合查询，直接把集群打挂了，后来临时扩容了3个计算节点，花了快两万，这笔钱之前根本没人算在日志平台的成本里。
还有索引副本的配置，他们照着开源教程的默认配置，每个索引都设了1个副本，也就是一份日志存两份。其实对于那些非核心的访问日志来说，就算丢个百分之几也根本不影响，副本数设成0都没问题。就这一项调整，又省了三分之一的存储成本。
日志平台冷热分层存储架构示意图
很多人觉得要控制成本就得换轻量的日志平台，其实真不用。
说白了不用搞复杂的日志分级规则，就先把日志分成三类：核心类的比如交易错误日志、trace日志，保留90天，放热存储；普通类的比如接口访问日志，保留7天热存，之后自动转存到对象存储，需要的时候再捞；临时类的比如debug日志，保留3天就删。
改完分级之后，他们每个月的存储费用直接从12万降到了4万多。
还有个很容易被忽略的细节：日志内容本身的冗余。他们之前的接口日志里，把整个请求的body全打了进去，一个普通的商品详情接口的日志就有3KB，其实大部分时候排查问题只需要知道用户ID、接口返回码、响应时间就够了，根本不需要整个body。后来他们把日志的内容做了精简，写入量又砍了30%。
改完策略的第二个月，账单出来的时候，运维小哥直接给我发了个88块的红包，说终于不用每个月挨骂了。
当然，这些方法也不是万能的。如果你是做金融或者医疗行业，合规要求日志必须存满半年甚至更久，那缩短存储周期的方法就不适用，这时候就得靠冷热分层、压缩存储、索引优化这些方式来省。
上周跟那个团队的运维小哥吃饭，他说现在每个月的日志平台成本稳定在3万出头，比之前少了快15万。老板再也不追着他问云成本的事了。
其实很多时候日志平台的成本高，根本不是技术问题，是大家搭的时候只顾着能跑、能查，从来没想着要结合自己的业务实际去调整。毕竟，能用和好用、省钱，从来都不是一回事。
他们运维小哥坐在对面挠头，说当初搭ELK的时候就怕出问题查不到日志，把所有服务的访问日志、业务日志、甚至前端埋点的debug日志全量接了进来，统一存90天，谁知道越跑越贵，每个月的账单都比上个月涨一截，老板已经找他谈过两次了。
别上来就全量砍日志
很多人碰到这种成本超支的情况，第一反应就是删日志。
我之前见过更极端的，直接把日志保留周期从90天改成7天，结果半个月后出了个交易链路的异常，查不到之前的日志，折腾了三天才找到问题，最后赔了客户好几万。
说实话，全量砍是最蠢的办法。你得先搞清楚，你存的这些日志里，到底有多少是真的有人用的。
就拿这家直播电商的团队来说，我翻了他们过去三个月的日志查询记录，总共才127次查询，其中89次是查接口的错误日志，22次是查交易链路的trace日志，剩下16次查的是推广渠道的访问日志。剩下的那些debug日志、前端点击埋点的详细日志、甚至nginx记录的每个静态资源的访问日志，一次都没被查过。
真的没必要留着。
我让他们先把debug日志的默认采集关掉，只有排查问题的时候才临时开，采集到的日志只存3天，用完就删。就这一项，直接把每天的日志写入量砍了40%。
藏在明细里的隐性开销
很多人算日志平台的成本，只会算存储的钱。
错了。
计算成本才是大头。
他们之前的ES集群索引是按周切的，每次有人要查最近一天的日志，集群要扫整整一周的分片，光CPU开销就占了整个集群的60%。上次大促的时候，有个运营要查过去24小时的用户访问路径，跑了个聚合查询，直接把集群打挂了，后来临时扩容了3个计算节点，花了快两万，这笔钱之前根本没人算在日志平台的成本里。
还有索引副本的配置，他们照着开源教程的默认配置，每个索引都设了1个副本，也就是一份日志存两份。其实对于那些非核心的访问日志来说，就算丢个百分之几也根本不影响，副本数设成0都没问题。就这一项调整，又省了三分之一的存储成本。
不用换工具就能落地的调整
很多人觉得要控制成本就得换轻量的日志平台，其实真不用。
说白了不用搞复杂的日志分级规则，就先把日志分成三类：核心类的比如交易错误日志、trace日志，保留90天，放热存储；普通类的比如接口访问日志，保留7天热存，之后自动转存到对象存储，需要的时候再捞；临时类的比如debug日志，保留3天就删。
改完分级之后，他们每个月的存储费用直接从12万降到了4万多。
还有个很容易被忽略的细节：日志内容本身的冗余。他们之前的接口日志里，把整个请求的body全打了进去，一个普通的商品详情接口的日志就有3KB，其实大部分时候排查问题只需要知道用户ID、接口返回码、响应时间就够了，根本不需要整个body。后来他们把日志的内容做了精简，写入量又砍了30%。
改完策略的第二个月，账单出来的时候，运维小哥直接给我发了个88块的红包，说终于不用每个月挨骂了。
当然，这些方法也不是万能的。如果你是做金融或者医疗行业，合规要求日志必须存满半年甚至更久，那缩短存储周期的方法就不适用，这时候就得靠冷热分层、压缩存储、索引优化这些方式来省。
上周跟那个团队的运维小哥吃饭，他说现在每个月的日志平台成本稳定在3万出头，比之前少了快15万。老板再也不追着他问云成本的事了。
其实很多时候日志平台的成本高，根本不是技术问题，是大家搭的时候只顾着能跑、能查，从来没想着要结合自己的业务实际去调整。毕竟，能用和好用、省钱，从来都不是一回事。