上周跟软件大道某电商公司的运维老周吃皮肚面，他把筷子一摔，说上个月日志平台账单出来，多了三万二，财务追着问了三圈。
他说这话的时候，皮肚面的油花还在碗里飘。
真的蠢。
很多团队刚上ELK或者云厂商的SaaS日志平台的时候，总觉得”多存点总没坏处”，反正排查问题的时候少了日志才是大麻烦，没人会去算每GB的存储费、索引费、查询费加起来到底有多吓人，等到账单出来的时候才傻眼，原来平时随手打几行日志，每个月要花出去大几千。
你以为的日志成本根本不是真的成本
之前老周为了压成本，干过最蠢的事，就是直接把生产日志的存储周期从30天砍到7天，觉得反正大部分问题当天就能排查完，存那么久没用。结果没过半个月，有个用户投诉上个月买的生鲜没发货，翻遍了平台都找不到当时的订单创建日志，被运营追着骂了两天，最后还是找云厂商的客服从冷备份里扒出来的，花的服务费比省下来的存储费还多。
大部分人对日志成本的认知，还停留在”存多少GB花多少钱”，根本没算过索引费、查询费、甚至跨可用区的流量费。很多时候你以为只是存了100GB日志，光给这些日志建的索引，就占了200GB的存储，钱直接翻了倍都不止。
别上来就砍存储先清干净垃圾日志
说实话，大部分团队的日志里，至少有40%是根本没人会看的垃圾。
比如Nginx的健康检查日志，每隔10秒一次，一天下来几十GB，查问题的时候从来没人翻。还有开发上线后忘了关的Debug级别日志，满屏的”进入方法””参数为xxx”，半毛钱用都没有。之前见过更离谱的，有个开发在循环里打日志，每循环一次打一行”正在处理”，跑了十万次，出来十万条一模一样的日志，占了快20GB存储。
就这操作，我都想顺着网线过去揍人。
最划算的操作根本不是砍存储周期，是采集端前置过滤，别把没用的日志传到平台里。比如在Filebeat的配置里直接把健康检查的日志drop掉，生产环境直接把Debug级别调成INFO，合规要存的敏感日志比如用户手机号、身份证号，直接在采集端脱敏，既省存储又避合规风险。老周这么干了之后，光清垃圾日志第一个月就省了两万多，他自己都没想到。
剩下的日志按价值分层存更划算
清完垃圾日志，剩下的也不是都要存在最贵的热SSD存储里。
比如核心链路的支付、订单错误日志，这些出了问题要随时查，存在热存储里存30天没问题。剩下的普通访问日志、非核心链路的INFO日志，存7天热的就够，之后直接转冷存储，成本能降到原来的十分之一都不到，够满足大部分行业的合规留存要求就行。
还有个很多人忽略的点：无用索引清理。很多人建日志模板的时候，所有字段都勾上建索引，根本不管用不用得到。要知道索引的存储成本比原始日志还高，对吧？很多人根本没算过这笔账。比如你一年都查不了一次的User-Agent字段，还有请求头里的各种杂七杂八的参数，建索引纯纯浪费钱。老周之前的平台，光删掉20多个没用的索引，每个月又省了一万八。
还有查询的时候也要注意，别随便搜全量的ERROR日志，一次大范围扫描的查询费，够你存好几天的日志了。要是真的要查大范围的日志，先加个时间范围或者具体的过滤条件，别让集群无意义的扫全量数据。
老周现在每个月跟开发团队开半小时的小会，过一遍哪些日志没人用，哪些索引没人查，上个月的账单比最开始少了四万多，也没耽误过排查问题。
反正我是觉得，搞成本控制从来不是抠门，是别花冤枉钱。