日志存储概述

日志这玩意儿，说白了就是系统自己写日记。你想想看，每个请求、每次报错、每条数据变更，它都会记下来。我做运维那会儿，最怕的就是系统出问题却没日志——那才叫两眼一抹黑。

什么是日志

日志是应用程序、操作系统或硬件设备按时间顺序生成的事件记录。它不是普通的文本，而是有“身份证”的：时间戳、事件级别（INFO/WARN/ERROR）、事件源、具体描述。我记得刚入行时，前辈丢给我一句：“日志就是系统的黑匣子，出事全靠它还原现场。”

日志有三个核心特征：

• 不可变性：一旦写入，不应该被修改。改日志等于销毁证据。
• 有序性：天然按时间排列，这是排查问题的根基。
• 时效性：价值随时间衰减。24小时内的日志还是“热”的，一个月后基本只有审计用。

日志的重要性

很多人觉得日志可有可无，留个一两周就行。我的经验是：日志的价值在出事时才体现，但事出之前你无法预判需要多老的日志。

日志在三个场景中不可或缺：

1. 故障排查：按时间线回放事件，定位根因。80%的线上故障通过日志就能锁定。
2. 安全审计：谁在什么时候访问了什么数据、做了哪些操作。合规要求（如GDPR、PCI-DSS）强制保留特定日志。
3. 业务分析：用户行为路径、系统调用链、性能瓶颈分析——日志是最真实的数据源。

我搞过一个客户，他们网站被爬虫刷接口，连续亏损两个月才发现。为什么？因为日志只保留了7天，攻击流量又是缓慢增加，回溯时已找不到最早的痕迹。后来我帮他们把访问日志改到了90天，配合冷存储，才抓住那个爬虫。

存储演进

日志存储的演变，其实就是从“省钱省事”到“好查好用”的妥协史。我分了四个阶段：

阶段	存储方式	典型工具	痛点
本地文件时代	text文件按日滚动	logrotate、syslog	分散在各机器，查一个错要ssh十台服务器
集中式日志系统	nfs、日志服务器	rsyslog、syslog-ng	格式混乱，检索慢，扩展性差
结构化存储时代	倒排索引 + 列存	ELK、Splunk	成本高，索引膨胀，冷热分层难
云原生日志时代	对象存储 + 流处理	Loki、Elasticsearch + 冷热分离	架构复杂，需要权衡实时性与存储成本

第一阶段：本地文件。最原始的做法，每台机器写自己的文件，用logrotate按天压缩。我早期维护50台服务器时，查一个日志平均花15分钟——先猜在哪台，再ssh过去，再用grep。效率极低。

第二阶段：集中式接收。用syslog或rsyslog统一收日志到一台服务器。解决了“去哪找”的问题，但格式和查询依然是噩梦。有一次我要查一个错误关键字，在几个G的纯文本里grep，跑了半小时。

第三阶段：结构化+索引。ELK（Elasticsearch, Logstash, Kibana）出现后，日志变得可搜索、可可视化。但代价是存储成本飙升——Elasticsearch默认三副本，一份日志可能占6倍原始空间。我个人习惯对源日志做行式存储，对搜索字段只建必要索引，能省60%的存储。

第四阶段：云原生+冷热分离。现在更流行把热日志放在SSD上，温日志用普通磁盘，冷日志扔到对象存储（S3/minio）。Loki这种只建元数据索引的方案，更是把成本打到了极致。不过要注意：检索冷日志会有几秒延迟，不是实时的。

日志存储核心逻辑图

下面这张图总结了我对日志存储演进的理解：从产生到落地，再到检索与分析，每个阶段都面临成本与效率的博弈。

嗯，这张图你们可以保存下来。我在设计存储策略时，首先会画类似的逻辑图，确定每一层的吞吐和容量边界，再定具体方案。

小结：从“有什么”到“怎么省”

日志存储不是买硬盘那么简单。你要想清楚：

• 日志产生速度（每秒多少条？）
• 每条日志平均大小（几十字节还是几KB？）
• 规划保留周期（按等级分层）
• 查询频率与延迟要求（热数据需要秒级还是分钟级？）

我记得有一次评估一个新项目的日志量，开发说每天500GB，我坚持压测了一周，实际只有80GB——他多算了一个数量级。所以，永远先实测，再规划。这个原则在后面的章节中会反复用到。