4. 日志存储与检索：Elasticsearch 存储原理、索引生命周期管理、Kibana 可视化查询
日志存进去，还得能快速翻出来。Elasticsearch 就是干这个的。我刚开始接触它时，觉得就是个“高级搜索框”。后来线上日志量一上来，才发现里面门道不少。今天咱们就聊聊 ES 怎么存数据、怎么管索引、以及怎么用 Kibana 把日志“看”明白。
4.1 Elasticsearch 存储原理：倒排索引与分片
ES 为什么搜得快？核心秘密是倒排索引。传统数据库像一本书的目录，告诉你“第几页有什么”。倒排索引反过来，它记录“某个词出现在哪些文档里”。
举个例子。你搜“服务器宕机”，ES 不会去全文扫描。它直接查倒排索引表：
| 关键词 | 出现文档ID |
|---|---|
| 服务器 | doc1, doc3, doc7 |
| 宕机 | doc1, doc5 |
| 内存 | doc2, doc3 |
你看，一查“服务器”和“宕机”，交集就是 doc1。秒级返回。这就是倒排索引的威力。
再说分片。ES 会把一个索引拆成多个分片，分散到不同节点上。我个人习惯，分片数一般设为节点数的 1-2 倍。比如 3 个节点，分片设 5-6 个。太多分片反而增加管理开销。
核心要点：每个分片本质上是一个 Lucene 实例。分片数一旦设定，不能减少。只能增加。所以初期别设太大，我建议先小后大。
4.2 索引生命周期管理：别让日志撑爆磁盘
日志是源源不断的。如果不加管理，磁盘迟早被撑爆。我记得有一次线上告警，ES 集群磁盘使用率飙到 95%。查了半天，发现半年前的日志还在热节点上躺着。从那以后，我强制要求所有日志索引必须配置 ILM。
ILM 分四个阶段：
- Hot（热阶段）：频繁写入和查询。用 SSD 磁盘。
- Warm（温阶段）：不再写入，偶尔查询。用 HDD 或冷存储。
- Cold（冷阶段）：很少查询。可以压缩存储。
- Delete（删除阶段）：到期自动删除。
配置起来很简单。下面是我常用的策略：
PUT _ilm/policy/log_retention_policy
{
"policy": {
"phases": {
"hot": {
"min_age": "0ms",
"actions": {
"rollover": {
"max_size": "50GB",
"max_age": "1d"
}
}
},
"warm": {
"min_age": "7d",
"actions": {
"allocate": {
"require": {
"data_type": "warm"
}
}
}
},
"cold": {
"min_age": "30d",
"actions": {
"freeze": {}
}
},
"delete": {
"min_age": "90d",
"actions": {
"delete": {}
}
}
}
}
}这段配置的意思是：
- 热阶段：索引超过 50GB 或超过 1 天，自动滚动新索引。
- 温阶段：7 天后移到温节点。
- 冷阶段：30 天后冻结。
- 删除阶段：90 天后自动删除。
避坑指南：我曾经把 max_age 设成 30d，结果索引一直不滚动。后来发现 rollover 必须满足所有条件才会触发。所以建议 max_size 和 max_age 都设，哪个先到就滚。
4.3 Kibana 可视化查询：把日志变成图表
日志存好了，怎么查？Kibana 就是 ES 的“脸面”。我个人最喜欢用它的 Discover 和 Dashboard。
4.3.1 Discover：快速定位问题
打开 Discover，选好索引模式。搜索框里写：
status: 500 AND response_time: > 3000这行查询的意思是：找出所有状态码为 500 且响应时间超过 3 秒的请求。你想想看，平时排查慢接口，这个查询一秒钟就能定位到问题日志。
还可以用 KQL（Kibana Query Language）：
error_code: "E1001" and host: "web-01"嗯，这里要注意：KQL 的字段名必须和 ES mapping 里的一致。否则查不出结果。
4.3.2 Dashboard：监控大盘
我习惯把常用查询做成 Dashboard。比如：
- 过去 24 小时 5xx 错误趋势图
- 各接口平均响应时间排名
- 错误日志来源 IP 分布
怎么做？很简单：
- 在 Visualize 里创建图表（柱状图、折线图、饼图都行）。
- 拖拽到 Dashboard 里。
- 设置时间范围，比如“Last 7 days”。
有一次线上出故障，我打开 Dashboard，一眼就看到某个接口的 5xx 曲线突然飙升。点进去看日志，发现是数据库连接池满了。前后不到 5 分钟就定位了问题。这就是可视化的价值。
注意：Dashboard 里的查询会消耗 ES 资源。如果数据量很大，建议设置查询超时和结果限制。否则一个复杂查询可能拖垮集群。
4.4 知识体系总览
下面这张图，把本章的核心逻辑串起来了。你可以看到日志从写入到检索的完整链路。
说白了，ES 存储原理让你知道数据怎么组织，ILM 让你知道怎么管理数据生命周期，Kibana 让你知道怎么用好数据。三者缺一不可。
个人建议：刚开始用 ES 时，别追求完美配置。先跑起来，再根据实际数据量调整分片和 ILM 策略。我见过太多人一开始就纠结分片数，结果上线后根本用不上。
好了，这一章就聊到这儿。记住：日志不只是存起来，更要能查得快、看得懂。这才是日志排查的真功夫。