日志分析平台的成本控制要算清每笔糊涂账

上周跟南京河西某SaaS公司的运维负责人吃鸭血粉丝，他吐槽说上个月刚收到云厂商的账单，光日志服务的费用就超了3倍，本来季度预算12万，最后干到38万，被CFO堵在会议室问了半小时，脸都绿了。 没人对账。 这钱花得冤不冤？

先搞清楚钱到底花在了哪

很多人对日志成本的认知还停留在“存储费用”上，真拆开账单看就会发现完全不是那么回事。超过70%的非必要日志成本，根本不是存储占的，是无意义的高频写入和全量查询。 就说那个被CFO堵的哥们的团队，之前把所有Nginx的健康检查请求日志，包括每一次负载探活的200返回，全量往ES集群里灌，还有业务侧的debug日志，本来上线前要统一关闭的，结果有个开发发版的时候忘了改配置，debug模式连续跑了半个月，每天的日志写入量直接翻了5倍。等运维发现的时候，光这半个月的额外写入费用就已经花了6万多。

说实话，很多团队的账单拉出来，写入成本占比能到60%，存储只占25%，剩下15%全是查询产生的费用。大部分人连这个比例都没算过，一看到超支就喊着要砍存储周期，纯纯是拆东墙补西墙。

别一上来就砍日志留存周期

我见过太多运维遇到成本超支的第一反应：把原来30天的日志留存改成7天。 结果呢？三个月后线上出了个资金对账的问题，要查当时的交易日志，啥都找不到，最后只能背锅。 其实根本不用这么极端。把日志分层留存就行。核心交易链路的日志，留180天没问题，毕竟涉及资金的问题追溯周期本来就长；普通的业务操作日志，留30天足够排查大部分线上问题；那些健康检查、心跳上报的日志，根本不需要进实时分析平台，直接扔对象存储的冷归档层，成本差了快10倍。 那个被CFO堵的哥们后来做的第一件事，就是把所有健康检查的日志从日志平台里剔除，光这一项每个月就省了8万。比砍留存周期的效果好太多，还完全不影响日常排查问题。

还有高并发接口的日志采样，比如每秒上万请求的商品详情接口，根本不需要把每一条请求日志都存下来，按1%的比例采样，足够定位99%的问题，写入成本直接降一个数量级。

查询环节的隐形账单最容易被忽略

很多人到现在都不知道，你在日志平台上点一次查询，扫过的日志量产生的费用，可能比存一个月的日志还贵。 之前有个运营同学，为了找某一个用户的投诉记录，直接搜了全量的日志字段，既没有加明确的时间范围过滤，也没有加用户ID的精准匹配，一次查询就扫了12T的日志，直接扣了1200多块的查询费，他自己到现在都不知道还有这收费项。 这真不是个例。大部分团队的日志平台根本没有做查询权限的管控，谁都能随便搜，有人甚至为了写周报，直接把过去一个月的全量日志导出来，光这一次导出的费用就够普通员工一天的工资了。 所有的日志查询必须强制加时间范围过滤，默认只允许查最近7天的内容，超过7天的查询要走简单的审批流程，再给每个部门设置固定的查询配额，超过配额的要单独申请。就这么个简单的规则，那个团队落地之后，光查询相关的成本就降了40%。 对吧，你想啊，开发随便打日志，运营随便查日志，最后账单全是运维部扛，换谁谁不闹心。 之前在徐庄软件园遇到的一个团队，甚至连每个业务线对应多少日志写入量都没打标签，到了月底算成本的时候，根本不知道该找哪个部门要钱，只能从运维的公共预算里扣。久而久之大家更没有节约的意识，反正不是自己的钱，打多少、查多少都无所谓。 其实日志分析平台的成本控制，根本不需要你急着换更便宜的开源方案，也不需要你把日志全删了。就是把每一笔糊涂账算清楚，谁产生的成本谁负责，该留的留，该砍的砍，别让那些没用的健康检查日志、忘关的debug日志占着你的存储和查询资源就行。 要是你也在南京的IT圈被日志账单搞的头大，下次吃鸭血粉丝的时候可以一起唠唠，大家踩过的坑摆出来，总比自己摸着石头过河强。