日志分析平台的成本控制 别为无效日志掏冤枉钱

上周在新街口巷口的鸭血粉丝汤店，做电商运维的老陈刚坐下就把手机往桌上一摔。

“你看这账单。”

我凑过去扫了一眼，上个月的日志分析平台账单，比前一个月翻了整整两倍还多。

“大促刚过，财务追着我要解释，说是不是我把平台拿去跑私活了。”

我懂这种冤屈。

很多人都觉得日志平台就是个查问题的工具，能花几个钱？真等账单跳起来的时候，才知道这里面的坑有多深。

那些藏在账单里的成本黑洞

老陈说，他大促的时候怕排查问题不够，临时把所有网关日志的保留期从7天调到了30天，大促结束忙着处理售后的问题，完全忘了调回去。还有个测试组的小孩，为了测新上的支付接口，把所有debug级别的日志全采了，连每个请求的参数都完整存下来，还没加任何过滤规则。这俩加起来，存储费用涨了两倍多，连查询的计算成本都跟着翻了——毕竟你搜“支付失败”的时候，系统要扫几个T的debug日志才能出结果。

很多人对日志成本的认知，还停留在“买几台服务器装个开源软件”的阶段。实际上现在的日志平台，不管是开源的ELK还是商业的SaaS产品，成本都拆得很细：采集的带宽费、存储的磁盘费、查询的计算费、甚至你配的告警规则，每发一条短信、每推一次webhook，都是要算钱的。

真的，上个月还有个朋友跟我吐槽，说他配了个全量错误日志的告警，结果业务线有个接口抽风，一天报了八千多个错误，光短信费就花了四百多。谁能想到？

为什么你总控不住成本

说白了，就是权责没捋清楚。

运维管着平台的账号，但是业务方的人随时可以加采集规则、改保留期。出了问题查不到日志，全是运维的锅；但是谁开了多余的采集、谁把保留期拉到了90天，没人管。等账单出来的时候，大家都懵了，反正钱是公司出的，谁也不心疼。

还有个很常见的误区，就是觉得日志存的越多越好。

我见过有团队，把前端用户的点击埋点日志全存了半年，连用户点了哪个轮播图、停了几秒都记下来。问他们谁会查这些日志，没人说话。真的，谁没事翻半年前用户点了哪个按钮的日志啊？闲的吗？

还有的人，部署日志平台的时候，直接用了默认配置。很多产品为了让你刚部署完就能查到日志，默认给你开全量采集、保留30天，甚至有的直接默认永久保留。你刚用的时候觉得挺方便，等跑个三五个月，一堆没用的日志堆在那里，成本自然就上去了。

落地就能用的控本方法

老陈后来折腾了一周，下个月的账单直接砍了60%，财务都过来问他是不是把平台给停了。我问他怎么弄的，其实都是些很简单的事。

先给日志分个级。日志分级保留是最直接的成本砍半手段。比如核心支付链路的错误日志，你保留90天甚至更久都没问题；普通的网关访问日志，保留7天足够排查最近的问题；那种debug级别的日志，平时直接关，只有出问题的时候临时开采集，查完就停。

再把过滤规则往前移。别等日志传到平台了再过滤，直接在agent端就把没用的日志扔掉——比如那种每10秒发一次的健康检查日志，还有系统启动的时候刷的一堆没用的启动信息，直接在采集端就扔了，根本不用传到平台，带宽和存储都省了。

另外搞冷热分层。超过7天的不常用日志，别放在高性能的SSD节点上，直接转存到低成本的对象存储里。真要查的时候，再临时拉回来就行。这个操作做完，存储成本直接降70%都不止。

还有个很容易被忽略的操作，就是每个季度做一次“日志大扫除”。看看有没有早就没人用的日志源，有没有过期的告警规则，有没有开了之后从来没查过的索引。这些东西看着不起眼，堆在一起都是隐形的成本。

哦对，老陈他们还给每个业务线设了个月度成本预算，每个月超了的话，得写个说明为啥超，不然系统自动把超出的采集规则给停了。现在再也没人随便开debug日志了。

不过话说回来，控成本也不是让你把日志全砍了。该存的核心日志还是要存，不然出了线上问题查不到，锅还是你背。

真的，很多时候你掏的冤枉钱，都是当初图省事留的烂摊子。多花十分钟理清楚哪些日志真的有用，比你事后对着账单头疼强多了。