1. ELK Stack 概述与架构
ELK 这个缩写，干这行的都熟。Elasticsearch、Logstash、Kibana 三件套，说白了就是一套日志处理流水线。我最早接触它是在一家电商公司，每天几亿条用户行为日志，MySQL 根本扛不住，老板一拍桌子说上 ELK，这才入了坑。
1.1 三个组件，各管一摊
先拆开看每个组件到底干嘛的，别被官方文档绕晕。
| 组件 | 角色 | 一句话理解 |
|---|---|---|
| Elasticsearch | 存储 + 搜索 | 一个分布式 JSON 文档数据库，全文检索快得离谱 |
| Logstash | 采集 + 加工 | 从各种源拽数据，过滤、清洗、转格式，再吐给 ES |
| Kibana | 可视化 + 管理 | 把 ES 里的数据画成图表，顺便查查索引、调调查询 |
嗯，这里要注意：Logstash 不是唯一的数据摄入方式。Beats（轻量采集器）后来也成了标配，但我个人习惯把 Beats 算作 Logstash 的补充，不算打破 ELK 的概念。
1.2 它们怎么协同的？
想象一条流水线：数据源 → Logstash（预处理） → Elasticsearch（索引与存储） → Kibana（展示）。
举个例子。我在项目中遇到过 Nginx 日志的采集场景：
- Nginx 写日志到文件 → Filebeat 嗅探并转发 → Logstash 解析成结构化 JSON → ES 建索引 → Kibana 画请求趋势图。
- 如果 Logstash 挂了怎么办？Filebeat 有内部队列和重试机制，数据不会丢，这在生产环境里很重要。
为什么会这样设计？因为解耦。日志采集、处理、存储、展示各自独立，你改 Kibana 的面板不用重启 Logstash，修 Logstash 的过滤规则也不影响 ES 的数据。我当初把这套逻辑讲给运维同事听，他说“这不就是微服务思想吗？”——对，就是这个理。
1.3 常见部署模式
部署方式不是拍脑袋定的，得看你的数据量、可用性要求和运维成本。我用表格列一下最常见的三种：
| 模式 | 节点角色 | 适用场景 | 踩过的坑 |
|---|---|---|---|
| 单机 All-in-One | 单台服务器跑 ES + Logstash + Kibana | 开发测试、小日志量（< 10GB/天） | 我曾经图省事直接用单机，结果 Logstash 吃满 CPU，ES 索引响应也变慢——别在生产环境用 |
| 标准三节点集群 | 3 台 ES 数据节点 + 1 台 Logstash + 1 台 Kibana | 中小规模生产，日均 10~100GB 日志 | Logstash 默认堆内存 1GB，我忘了改，半夜直接 OOM，日志全卡在管道里 |
| 大型分离集群 | ES 集群（单独 Master/Data/Ingest 节点）+ 独立 Logstash 集群 + 多个 Kibana + 消息队列（Kafka） | 企业级，日均 TB 级日志，要求高可用 | 加 Kafka 后日志链路变长，调优时得盯每个环节的堆积量，不然日志延迟高了没人知道 |
1.4 架构总览：一张图说清
下面这张 SVG 图把核心流程和组件关系画出来了。重点看数据流方向和组件间的依赖：
这张图里我特意加了两条虚线：Kibana 查询 ES 时其实走了 HTTP REST 接口，这不是简单的“展示”，而是 Kibana 发起 DSL 查询，ES 返回结果。你如果遇到 Kibana 图表加载慢，先去查 ES 查询耗时，别第一时间怪网络。
1.5 核心协同关系，记住这三点
- Logstash 是承重墙。 解析过滤做得不好，ES 里存的就是垃圾数据，Kibana 面板再漂亮也没用。我建议在 Logstash 里做好字段映射和类型转换，别把数字存成字符串。
- Elasticsearch 的索引设计决定查询速度。 分片数、副本数、映射模板，这些要在数据接入前规划好。我曾经接手一个项目，ES 索引用了默认 5 分片 1 副本，结果半年后查询慢成狗，重新索引才救回来。
- Kibana 不仅是画图工具。 它自带 Dev Tools，可以直接查 ES 的 _cat API、调 Query DSL，排查问题时比 curl 方便太多。我调试脚本告警集成时，90% 的时间在 Kibana 里敲命令。
一句话总结： ELK 的威力在“流水线协同”。Logstash 把原料洗好，ES 把货架摆整齐，Kibana 把商品展示出来。你只要维护好管道通畅，剩下的事交给它们自己玩。
1.6 我的架构选择建议
如果你现在要搭一套 ELK，我给个通用参考（来自我踩过的坑）：
- 日均日志量小于 5GB → 单机 All-in-One 足够，但记得给 ES 和 Logstash 分别分配独立 JVM 堆（ES 不超过物理内存 50%，Logstash 给 2~4GB）。
- 日均 5~50GB → 标准三节点集群，Logstash 独立部署，加一个 Filebeat 作为采集端。为什么要加 Filebeat？因为它比 Logstash 轻，资源消耗只有 Logstash 的十分之一，而且自带背压机制。
- 日均 > 100GB → 必须上 Kafka。Logstash 处理能力有限，突发流量时 Kafka 能缓冲。我见过某公司没加 Kafka，大促时日志直接冲垮 Logstash，ES 写入排队，最终数据丢失。
嗯，这个架构话题挺长，但第 1 章你只要理解“三个组件各自干什么、怎么连到一块”就够了。后面的章节我们会拿真实脚本，把巡检和告警一步步集成进去。