阿凯是南京本地一家中型电商的运维负责人，他们团队用日志平台快五年了，之前业务量小，账单每个月都是几千块，没人在意。这半年业务翻了倍，账单直接跳到了每月四万多，还蹭蹭往上涨。
超支的钱都花在哪了
我当时拿过他的手机翻了下后台的费用明细，差点把刚喝的冰可乐喷出来。
真的离谱。
光DEBUG级别的调试日志，就占了总存储成本的62%。
这玩意除了线上出问题的时候临时抓一下上下文，平时谁会主动翻啊？
剩下的成本里，有20%是前端的console报错日志——很多前端同学为了调试方便，把所有的warn信息甚至路由跳转的埋点日志全量传到了平台上，存了整整180天。还有15%是莫名其妙的查询费用，有人随便选个最近30天的时间范围跑聚合统计，一次查询就能烧掉小两百块的计算资源。
真的没必要。
别上来就换便宜的云服务
阿凯一开始的想法特别直接：现在用的这家日志平台太贵了，不然迁到另一家报价低30%的服务商去。
我劝他先打住。
之前帮苏州的一个客户做过类似的评估，算下来迁移的工作量、数据同步的成本、后续的定制化开发费用，比第一年能省下来的钱还多。更别说迁移期间可能出现的日志丢失、查询延迟的问题，业务团队根本不买账。
说白了，绝大多数团队的日志成本超支，根本不是服务商的定价问题，是数据从采集端进平台的时候，就没做任何筛选。对吧？
阿凯他们的订单服务就是个典型，DEBUG日志里全是循环打印的数据库连接池信息，一次接口请求能打20多条无关内容，一天下来就是几十G的无效数据。
之前有个客户没换任何服务商，只是在采集端加了几行过滤规则，把非生产环境的DEBUG日志全量拦截了，当月的账单直接降了40%，连后端的存储架构都没动。
落地的时候别搞太复杂
很多人一提到成本优化，就觉得要搞大动作，拉个项目组改造三个月，其实根本不用。
先从最容易改的地方入手。
不要所有日志都用同一份存储策略。
DEBUG级别的日志，只存7天就够了——真要出问题，7天的时间足够你排查完，存再久也是占地方。INFO级别的日常业务日志，存30天，满足日常的审计和问题定位需求。ERROR级别的核心报错日志，存180天甚至更久，这个钱不能省。
还有个特别容易被忽略的点，就是查询权限的限制。很多团队为了方便，给所有开发都开了全量时间范围的查询权限，有人图省事，随便拉个半年的日志跑统计，一次就能烧掉好几百的计算费用。不如加个简单的规则：默认查询的时间范围最多7天，要查更长时间范围的，走个简单的审批流程就行，既不影响正常排查，也能避免无意义的资源消耗。
如果还有预算压力，就把超过30天的非核心冷日志，转存到低成本的对象存储里，别放在高性能的ES节点上。真要查的时候，按需加载就行，查询体验虽然会慢个几秒钟，但成本能降60%以上。
说实话，我见过太多团队为了所谓的“全量可观测”，无限制往日志平台塞数据，最后账单出来了才肉疼。
不过话说回来，也别为了省钱把关键的ERROR日志给过滤了，那才是捡了芝麻丢了西瓜。
上周阿凯给我发消息，说按照这个方法改了半个月，这个月的账单已经降了45%，老板还夸他会省钱。
他说要请我再吃一碗皮肚面，加双倍的腰花。