上周在新街口跟之前做运维的老陈拼鸭血粉丝，他刚咬了一口鸭肠就开始吐槽，说上个月公司的日志分析平台账单直接跳了三倍，老板把他叫到办公室，连他上个月加班调休的申请都给打回来了。
我当时第一反应是，是不是最近业务量涨了？他翻了个白眼，说业务量连10%都没涨，账单倒是涨了三倍，鬼才知道钱花哪了。
账单跳涨的根源根本不是日志量太大
后来陪他拉了三天的账单明细，才发现问题出在哪。90%的成本浪费，都来自于无差别的全字段索引和无差别的留存周期，跟你实际产生的日志量关系真没那么大。
他们是做本地外卖配送的，高峰集中在午晚两个时段，结果之前的配置里，把网关日志、业务日志、甚至前端埋点的所有日志，全留了180天，而且所有字段都建了keyword索引。
就这一个字段。
网关日志里的用户UA全量字符串，根本没人会搜，但是之前默认开了全字段索引，光这个字段的索引大小，就占了整个日志索引的25%。
我当时看到这个数据直接拍桌子，这不是纯纯给云厂商送钱吗？他也懵，说之前部署的时候直接抄了网上的默认配置，根本没注意过这个细节。
很多人一看到账单涨了，第一反应就是把日志留存时间砍到7天，结果后来出了个线上问题，要查10天前的日志，直接抓瞎，又得去云厂商的冷存储里捞，花的钱更多。
别上来就搞冷热分层那套标准答案
说实话，网上教日志成本控制的教程，十篇有八篇在讲冷热分层。热数据存SSD，温数据存普通云盘，冷数据存对象存储，听着逻辑特别顺。
但你算过没有？
你要写生命周期规则，要做索引迁移，要搞查询路由，小团队哪有这个精力？算下来省的钱，还不够付运维的人工成本。
我见过的团队里，日志其实可以粗暴分成三类，根本不需要搞那么复杂的分层。核心排障用的错误日志、核心链路trace日志，留30天足够，没人会翻30天之前的单条错误日志，除非是出了合规问题。业务统计用的接口QPS、耗时数据，直接每5分钟聚合一次存下来，原始日志存7天就够。剩下的健康检查日志、定时任务心跳日志，直接在采集端滤掉，根本不用进平台。
采集端前置过滤，是成本控制里投入产出比最高的动作，没有之一。
老陈后来就在Filebeat的配置里加了一行drop_event的规则，把所有健康检查的日志直接在采集端丢了，就这一下，直接砍掉了35%的日志写入量。他说改完配置的那天下午，看着写入速率的曲线直接掉了一个台阶，差点在工位上跳起来。
别为了用不上的查询需求买单
还有个特别容易踩的坑，就是当初上日志平台的时候，拍脑袋说要支持”任意字段查询”，所以把所有字段都建了索引。结果上线半年，大家查的字段就那么十来个，剩下90%的字段从来没人搜过。
之前我接触过一个南京本地的电商团队，他们把商品详情页的所有埋点日志全字段索引，结果运营从来没查过”用户在商品页停留时的设备亮度”这种字段，光这个字段的索引成本每个月就多花了两千多。
很多人买日志平台的时候，总觉得功能越全越好，就像你买个手机，总觉得要支持红外、支持NFC、支持100倍变焦，结果买回来一年都用不上一次，最后多花的钱全是冤枉钱。
索引的成本是写入时就要付的，查询的成本是用到时才付的，这个账一定要算明白。
你完全可以先拉一个近3个月的查询日志，统计下哪些字段被频繁搜索，只给这些字段建索引，其他的字段就存原始文本就行，需要查的时候用全文检索，慢一点没关系，反正一年也查不了几次。
老陈后来统计了他们平台3个月的查询记录，发现大家查的最多的就是traceId、errorCode、userId这三个字段，其他的字段一年到头没几个人搜，他直接把其他所有字段的keyword索引全删了，光索引成本就砍了40%。
上周他又跟我约鸭血粉丝，说这个月的账单比上个月少了快60%，老板还夸他会过日子，之前打回来的调休申请也批了。
说真的，日志平台这东西，从来不是越全越好，够用来就行。你省下来的钱，拿去给团队加个鸡腿不好吗？