1. 日志存储成本概述
先问一个问题：你的公司一年为日志存储花了多少钱？
我见过太多团队，日志量每月翻一番，成本却跟着翻倍。有一天财务拿着账单过来问：“这个月日志存储又涨了20%，你们到底存了什么？”
说实话，日志这东西，不痛不痒。平时没人管，出了问题又急得要命。可成本就这么悄悄溜走了。我在某电商公司做过一次排查，发现光是ELK集群的存储开销，一年就占了基础设施预算的15%。
所以控制日志存储成本，不是可选项，而是必修课。
为什么日志存储成本会失控？
说白了，三个原因：
- 数据量暴增：微服务、容器化、IoT，随便一个系统每天就能吐出几十GB日志。
- 保存周期过长：默认保留30天？很多团队直接设成90天甚至180天。
- 盲目全量索引：每一条日志都建全文索引，存储和计算都烧钱。
我记得有一次帮一家金融客户做审计，他们要求所有交易日志保存7年。结果你猜怎么着？单是2019年的日志就占了120TB，里面80%的数据从来没被查询过。嗯，这不是存储，是埋单。
常见的日志存储方案
市面上方案不少，但归根结底就是三大类。我整理了一张对比表，你看看心里就有数了。
| 方案 | 典型产品 | 成本特点 | 扩展性 | 查询性能 |
|---|---|---|---|---|
| 本地磁盘 | 服务器本地SATA/SSD | 一次性硬件投入，容量固定 | 差，加盘要停机 | 高 |
| 网络附加存储(NFS) | NFS Server, GlusterFS | 中等，按TB付费 | 中等 | 中等 |
| 对象存储 | S3, MinIO, Ceph | 极低，按实际用量计费 | 优秀，无限扩展 | 较低（需配合缓存） |
| 云日志服务 | ELK PaaS, SLs, Logz.io | 高，按写入量+存储量+查询收费 | 优秀，托管 | 高 |
| 时序数据库 | InfluxDB, TimescaleDB | 中等，适合结构化日志 | 好 | 高（针对时间范围） |
你会问：哪个方案最好？说实话，没有银弹。我在不同的项目里都试过，最后发现大多数场景都是混合方案——热数据用高性能存储，冷数据丢对象存储。这个思路我们后面会细讲。
日志存储成本的构成
成本不是一笔糊涂账。拆开来看，主要有这些部分：
- 存储介质成本：硬盘、SSD、云存储的每GB单价。
- 传输带宽成本：日志从业务服务器传到存储系统的网络流量。跨机房或跨云时尤其贵。
- 索引计算成本：搭建全文索引需要消耗CPU和内存，这部分经常被忽略。
- 冗余备份成本：副本、快照、异地容灾。为了高可用，至少多花50%-200%的存储。
- 管理运维成本：人工维护集群、故障恢复、升级迁移的时间成本。
我曾经帮一个SaaS公司做成本核算，发现他们每月花在日志上的钱里，33%是存储，27%是索引计算，20%是跨区域同步的网络费，剩下20%是人工和备份。你想想看，如果能把索引策略优化一下，成本是不是直接降四分之一？
成本构成一览（SVG图）
下面这张图把日志存储成本的各个部分梳理清楚了。你可以把它当成一个检查清单，对照自己的系统算一笔账。
一个真实的成本失控案例
前年我接手一个游戏公司的日志项目。他们的ELK集群每天接收200GB日志，索引策略是全字段全文索引，副本数设成3。我问运维为什么要3副本？他说“默认配置就这样”。
你猜结果怎样？
每月存储成本70万元，其中80%的日志从没被查询过。我们只做了三件事：
- 把副本数从3降到2（非关键日志降到1）
- 对历史超过7天的日志禁用全文索引
- 超过30天的日志自动迁移到对象存储（只保留压缩文件）
三个月后，月成本降到了28万元。60%的节省。说白了，很多成本都是“默认配置”和“懒得改”造成的。
核心误区：日志不是越多越好
新手运维容易犯一个错：把日志当成安全绳，存得越多越保险。其实不然。日志存储的成本，本质上是在为“未来的可能性”买单——你存着它，是为了以后可能查得到。
但现实是，99%的日志在保存期内永远不会被查询。那为什么还要全量存？
我个人习惯的做法是：先问业务方三个问题——
- 哪些日志必须在线查询？
- 查询的频次是多少？（每天？每周？）
- 最长能接受多久的恢复时间？（比如冷数据从对象存储拉回来要多久）
把答案理清楚，存储策略就能定下来。我曾经因为没问清楚，给一个团队设计了180天全量在线存储的方案，结果对方实际只需要7天在线查询，后面只需要归档保留。多花了四个月的成本，都是教训啊。
好了，这一章我们聊了为什么日志存储成本会失控，常见方案有哪些，成本到底花在哪儿。接下来要做的，就是拿起计算器，算一算你自己的系统。别急，后面几章我会手把手教你怎么算、怎么砍、怎么落地。