我当时第一反应是，是不是被刷库了？
他翻个白眼，说上周刚做过全量安全扫描，啥异常都没有。
真的疼。
账单跳涨的真凶根本不是流量
老周他们上个月刚上了新的订单系统，研发同学图方便，把所有请求报文、响应报文全塞进了日志里，连用户的收货地址、手机号这些敏感字段，都一股脑存了。更离谱的是，为了查问题快，他们给所有日志字段都建了索引，哪怕是那种一天都不会被检索一次的，比如前端传来的user_agent具体版本号。
还有，日志保留策略还是刚上平台时默认的30天，不管有用没用全留着。
就这三个操作——全字段索引+超长保留期+无差别采集，直接把成本推到了之前的三倍。
很多人第一反应是，流量涨了嘛，成本自然涨。真不是。老周他们上个月的业务流量，比上上个月只涨了15%。
他一开始想直接把保留期改成7天，结果上周出了客诉，用户说上个月的订单被重复扣款，要查30天前的日志，找不到，又被业务部门追着骂了半小时。他当时拍着桌子跟我吐槽，合着我两头不是人是吧？
别上来就砍日志，先做分层
说实话，我见过太多团队遇到这种事，第一反应就是砍日志量，要么直接把保留期砍到3天，要么干脆停掉几个服务的日志采集。
这都是懒办法。
谁遇到谁知道。
日志的核心作用是排障，不是为了存而存。你得先把手里的日志分个层，哪些是必须留的，哪些是可留可不留的，哪些是根本没必要采的。
老周他们后来花了三天时间梳理，把所有日志分成了三层：
第一层是核心链路日志，比如支付回调、用户登录、订单创建这些，这些要留90天，但只给订单号、用户ID、错误码这几个核心字段建索引，报文里的冗余字段直接删掉，敏感字段全脱敏。
第二层是普通业务日志，比如商品浏览、加购、分享这些，留7天就够了，索引只建商品ID、用户ID两个字段。
第三层是调试日志，就是研发打debug级别的信息，这些上线的时候直接在采集端过滤掉，根本不往平台送。
就这一套操作下来，他们的日志采集量直接降了62%，索引存储成本砍了41%，上个月的账单直接回到了之前的水平，还没耽误排障。
不过话说回来，分层的时候也别太抠，比如支付相关的日志，多留两个月也没多少钱，真出了资金类的问题，查不到日志的锅，可不是那点存储成本能cover的。
这些隐性成本才是真的吞金兽
很多人算日志成本，只看存储和计算的账单，其实还有一堆看不见的成本，才是真的悄咪咪吞钱。
比如索引重建成本。老周他们之前想优化索引结构，结果全量重建一次索引，花了整整两天的计算资源，光这一项就花了八千多，之前根本没算过这笔账。
还有跨可用区流量成本。他们的ES集群跨了两个可用区，每个节点之间的同步流量，每个月就要扣三千多，之前看账单的时候只看了存储和计算，根本没注意到流量那栏的数字。
最离谱的是冷数据搬运成本。他们之前为了省热存储的钱，把超过7天的日志全搬到了OSS冷归档存储，结果上次要查30天前的刷单日志，得先把数据从冷存储解冻，解冻一次要等四个小时，还花了两百多的搬运费，前后折腾了一天才拿到数据。
还有那种临时开的集群。上个月还有个做社区电商的朋友跟我吐槽，他们为了查一次大促期间的刷单日志，临时开了个16核32G的ES节点，查完忘了关，整整跑了21天，最后账单出来的时候他差点把键盘砸了。
其实要控成本，根本不用搞什么复杂的架构调整，先做这几件事就行：
先把过去一个月的日志账单拉出来，拆成存储、计算、索引、流量四个部分，哪个占比最高先砍哪个，别瞎忙活。
给采集端加几条简单的过滤规则，debug日志直接不采，敏感字段脱敏，冗余字段直接删，这一步不用改代码，花个半天就能搞定。
按生命周期管索引，7天内的热数据放在SSD上，该建索引的建，7到30天的温数据放在普通存储上，只留必要的索引，30天以上的冷数据，真要留就存在对象存储里，别建索引，真要查的时候再临时导出来。
临时开的集群，一定要设自动销毁时间，到期直接删，别等着财务找你谈话才想起来。
真的，做运维久了就知道，日志平台的成本从来不是省出来的，是抠出来的。