1. 课程导入与体系总览
Elasticsearch 在生产环境中很少以“单机软件”的形态出现，它更像一套由多个角色节点、外部协调组件、采集链路和可视化入口共同构成的分布式数据平台。理解这套平台的全貌，是后续所有故障诊断与运维动作的前提。本课程的目标不是记住零散命令，而是建立一条从“架构认知”到“故障定位”再到“体系化运维”的完整能力链。
一、生产集群的典型架构
一个中等规模的生产 Elastic 集群，通常包含以下角色与外部组件：
- Master 节点：负责集群状态管理、索引元数据、分片分配决策。生产环境建议至少 3 个专用 Master 节点，避免与数据节点混部导致选举抖动。
- Data 节点：存储分片、执行读写与聚合。按热、温、冷分层时，可进一步划分为 hot/warm/cold 数据节点。
- Coordinating 节点：只做请求分发与结果归并，不存数据、不参与选举，用于隔离查询压力。
- Ingest 节点：在写入前执行 pipeline 预处理，如字段解析、时间戳提取、富化。
- Kibana：可视化与运维入口，同时承担部分监控展示。
- Beats / Logstash：采集与传输层，决定数据进入集群前的形态与速率。
- 快照仓库：通常对接 S3、NFS 或 HDFS，用于备份与恢复。
这些角色之间不是简单的“上下级”关系，而是通过传输层（Transport）和 HTTP 层形成一张有向连接网。下图给出一个典型生产集群的拓扑关系，重点标出数据流方向与关键控制面。
这张拓扑图揭示了三个关键认知：第一，控制面与数据面分离，Master 不直接处理用户请求，数据节点不参与选举；第二，写入路径经过 Ingest 与 Coordinating，任何一段拥塞都会表现为写入延迟；第三，快照仓库是独立于集群的外部依赖，恢复能力取决于它而非集群本身。
二、故障诊断与运维体系的全貌
生产故障从来不是单一原因。一个“查询变慢”的现象，可能同时涉及 JVM GC、分片不均、慢查询、磁盘 IO 和协调节点过载。因此，诊断体系必须分层：
- 集群层：健康状态、节点存活、分片分配、主分片选举。
- 节点层：JVM 堆、GC 频率、线程池队列、文件描述符、磁盘水位。
- 索引层：分片数、副本数、段合并、refresh 间隔、mapping 膨胀。
- 查询层：慢日志、profile API、缓存命中率、聚合内存。
- 写入层：bulk 拒绝率、pipeline 耗时、translog 刷盘。
运维体系则对应地分为四个闭环：可观测性建设（指标、日志、链路）、日常巡检（容量、水位、快照）、变更管理（滚动重启、扩缩容、mapping 变更）、应急响应（故障树、止损、恢复、复盘）。这四个闭环不是并列的，而是以可观测性为底座，巡检和变更在其上运行，应急响应在最上层兜底。
三、学习路径与实战目标
本课程共 30 章，按“认知—工具—诊断—治理”四段推进。前几章建立架构与指标基线；中间章节深入 JVM、分片、查询、写入、快照等具体故障域；后段进入容量规划、滚动升级、安全与多集群治理。每一章都要求你能回答三个问题：这个对象正常时长什么样？异常时先看哪个指标？看到异常后第一步做什么？
cluster health 为 yellow，先确认是副本未分配还是主分片未分配；再查 _cat/shards 定位具体索引；最后结合 _cluster/allocation/explain 判断是磁盘水位、节点离线还是分配规则冲突。这条路径比记住十几个 API 更有价值。
接下来的章节会反复使用本节建立的拓扑视角：任何一次故障，先把它映射到图中的某个角色或某条链路上，再决定去看哪一层指标。这样，诊断就从“凭感觉试”变成“按结构查”。