日志分析平台的成本控制别乱花冤枉钱

上周去南京本地一家做生鲜电商的公司，运维总监拉着我吐槽，上个月云账单打出来，日志平台那栏占了小二十万，财务直接把他的审批权限给停了，说要查清楚钱花哪了。 我当时翻了下他们的账单明细，差点笑出来——30%的钱花在根本没人用的冷存储上，40%的钱是因为查询没做限制，白白多扩容了三个节点，剩下30%是跨可用区传日志的流量费，全是没必要花的冤枉钱。

先搞懂你花的钱到底去了哪

很多团队一听到要控成本，第一反应就是找运维删日志、缩留存，连钱花在哪都没搞清楚，纯纯瞎折腾。 日志平台的成本从来不是一笔糊涂账，拆开来就三块：存储、计算、流量。 你以为你存的都是有用的排障日志？我见过最离谱的团队，把前端用户每次点击按钮的埋点日志，全默认存了180天，光这部分数据占了总存储的62%，但实际上排障的人从来不会去翻前端点击日志，那部分是产品分析组要的，可人家根本没提过要存180天，最多要30天的趋势数据就够了。 还有的团队，日志查询没有任何限制，随便一个开发都能写个不带时间范围的全量查询，一次查询就能把集群CPU打到100%，运维为了不影响线上业务，只能不停加节点扩容，钱全花在了没必要的算力上。

我上次碰到的那个电商客户就是，之前日志查询慢，运维二话不说加了三个SSD节点，花了快十万，后来查了一周的慢查询日志才发现，有个后端开发写的接口统计脚本，每天凌晨跑一次全量索引扫描，根本没加时间范围，把这个脚本的查询限制改了之后，集群CPU直接降到了20%，多买的三个节点闲到现在，纯纯冤大头。

别上来就删日志先做分级

不要一上来就一刀切缩留存时间。我见过太多团队为了省成本，把所有日志的留存时间从30天改成7天，结果过了俩月，出了个合规问题，要查三个月前的用户操作日志，根本查不到，最后罚的钱比省的那点成本多十倍都不止。 正确的做法是先给日志做分级，不同等级的日志对应不同的留存周期和存储介质。 比如核心交易类的日志，像支付回调、订单创建、用户实名认证这些，涉及合规要求的，至少存90天，重要的甚至要存半年以上，这部分数据放在SSD热存储里，保证查询速度。 普通业务日志，比如接口请求日志、服务运行日志，存30天就够了，平时排障足够用。 那些调试用的debug日志，直接在生产环境关了不就完了？真要开的时候再临时开，不然攒一堆没用的，占空间还拖慢查询速度。 还有个很多人忽略的点：索引的副本数。ES默认每个分片存1个副本，也就是一份数据存两份，要是冷数据的话，副本数直接改成1甚至0，反正冷数据就算丢了也不影响业务，光这一项就能砍一半的存储成本。

那个生鲜电商的客户，后来把超过7天的日志全转去了对象存储，冷数据转对象存储的成本只有SSD的十分之一，光这一项每个月就省了八万多。平时排障都是查最近7天的热数据，真要查老日志的时候，再临时把对应的索引拉回热存储就行，谁没事天天翻三个月前的日志啊？对吧。

那些没人跟你说的隐性成本

很多人算日志平台的成本，只算买服务器、买云盘的钱，根本不算隐性成本，这才是最可怕的。 比如权限成本。很多团队的日志平台查询权限随便开，随便一个运营都能写个复杂的聚合查询，把整个集群打满，导致线上排障的运维查不了日志，耽误的那几个小时，损失的订单可能比一年的日志平台费用都高。 还有预处理成本。很多团队不做日志清洗，把所有请求头、Cookie、User-Agent这些没用的字段全存在索引里，日志预处理清洗无效字段之后，索引体积能直接小一半，查询速度还能提30%，存储成本直接砍半，何乐而不为？ 还有那个跨可用区的流量费。之前有个做短视频的团队，把华东区域的日志全传到华北的日志集群里，跨可用区的流量费每个月就有四万多，后来改成本地可用区采集，本地存，需要同步的时候再走专线，每个月流量费直接省了三万多，没人注意到这个钱花的有多冤。 说实话，我见过太多团队，日志平台刚搭起来的时候，恨不得把所有数据都往上堆，美其名曰”数据资产”，真到交账单的时候，全傻了。 其实日志平台的成本控制，根本不是要你抠抠搜搜什么都不让存，而是把钱花在该花的地方，别为那些没人用的索引、没人看的日志、没必要的算力买单。 毕竟省下来的预算，拿去给团队发奖金，或者多买两个新的测试服务器，不好吗？