Elasticsearch 集群运维

• 主/副本分片规划
• 分片数量与容量估算
• 分片过多的代价

ES 索引由主分片（primary shard）与副本分片（replica shard）组成，主分片承担读写，副本分片提供容灾与读扩展。分片数量规划：取决于数据量、单分片容量与查询性能，通常按"总数据量 / 单分片目标容量（如 20-50GB）"估算主分片数，副本数按容灾与读需求设置（至少 1）。分片过多：每个分片都有元数据与开销，过多分片导致资源浪费、集群管理开销大、查询聚合开销增加、rebalance 慢。分片过少：单分片过大，查询与迁移慢，无法有效利用多节点并行，扩容受限。分片数量需在创建索引时确定（一旦创建不可改主分片数）。运维上需合理规划分片，避免过多或过少。

分片是 ES 的并行单元与容灾单元。主分片数决定数据切分粒度，副本数决定容灾与读扩展。分片过多/过少都是性能隐患，需按数据量与容量估算。主分片数创建后不可改，规划要谨慎。

• 磁盘水位线（low/high/flood）
• 触发行为
• read-only index 解除

ES 通过磁盘水位线保护磁盘：low threshold（默认 85%）触发分片分配策略，避免把分片分配到低磁盘节点；high threshold（默认 90%）触发分片迁移，将分片迁移到磁盘更充足的节点；flood threshold（默认 95%）触发 flood stage，将索引设为 read-only（index.blocks.read_only_allow_delete），停止写入以保护磁盘。当磁盘水位恢复正常后，需手动解除 read-only（移除 index.blocks.read_only_allow_delete 设置）。磁盘治理：清理或归档过期索引（删除/ILM 迁移到冷存储）、扩容磁盘、压缩数据。运维上需监控磁盘水位，及时治理避免进入 flood。

水位线是 ES 的磁盘保护机制，分级触发。flood 阶段索引只读是保护动作，需在磁盘恢复后解除。治理是"清理 + 扩容 + 归档"组合，避免磁盘写满。

• green/yellow/red 健康状态
• 主分片与副本分片的状态
• unassigned shards 定位

ES 集群健康状态：green 表示所有主分片与副本分片都分配且正常；yellow 表示所有主分片已分配但至少一个副本分片未分配（一般因副本数 > 可用节点数或副本分配失败）；red 表示至少一个主分片未分配（数据不可用）。unassigned shards 定位：通过 _cluster/health 查看 unassigned_shards 数量，通过 _cat/shards 查看未分配分片及原因。修复：yellow 通常是副本分配问题（节点数不足、磁盘水位、分片分配过滤），增加节点或调整副本数；red 是主分片丢失，需从备份恢复或通过 reallocated 强制分配（有数据风险）。运维上需监控健康状态，及时处理 unassigned。

健康状态是集群可用性的第一信号。yellow 是容灾降级（副本缺失），red 是数据不可用（主分片缺失）。定位 unassigned 需看分片分配原因与节点资源，修复要区分副本丢失与主分片丢失。

• ILM 阶段（hot/warm/cold/frozen）
• rollover 滚动
• 归档与删除自动化

ILM（Index Lifecycle Management）管理索引生命周期，定义阶段（phase）：hot（热，频繁读写，SSD）、warm（温，只读或低频更新，可降低副本与磁盘）、cold（冷，只读，可合并分片降低存储）、frozen（冻结，极低频，只查元数据）。rollover 用于滚动写入：当索引达到一定大小/文档数/时间时，自动创建新索引并切换写入，避免单索引过大。归档与删除自动化：通过 phase 的 min_age 与 actions（如 delete）在指定时间后自动归档或删除过期索引，配合冷热存储。运维上通过 ILM policy 配置数据生命周期，实现"写入-滚动-降温-归档-删除"的自动化。

ILM 是 ES 数据治理的自动化工具。阶段定义了数据随温度变化的存储策略，rollover 控制索引大小，delete 实现归档清理。配置 min_age 与 actions 实现全自动生命周期，减少人工干预。

• 堆内存规划
• circuit breaker（熔断器）
• fielddata 内存

ES 依赖 JVM 堆内存，堆内存建议不超过物理内存的 50%（剩余留给 OS page cache），且不超过 32GB（避免压缩指针失效）。circuit breaker 是 ES 的内存保护机制，防止查询/聚合/fielddata 等操作消耗过多内存导致 OOM：当估算内存超过阈值（如 request breaker 默认 60% 堆，fielddata breaker 默认 40% 堆）时，请求被拒绝并返回 CircuitBreakingException。fielddata 用于聚合/排序等需加载字段值到内存，可通过 fielddata 大小限制与 breaker 防护。查询内存溢出防护：合理限制聚合大小、避免过大分页、使用 breaker 阈值。运维上需规划堆内存、配置 breaker、监控堆使用与 fielddata。

堆内存是 ES 的性能与稳定性核心。堆过大挤占 page cache，且超 32GB 失效。circuit breaker 是"内存保护伞"，防止 OOM 拖垮节点。fielddata 是内存大户，需 breaker 与限制。运维需平衡堆与 page cache。

• bulk 批处理
• refresh 与 translog 配置
• 副本数与写入吞吐

bulk 批处理：把多条文档合并为一次请求写入，显著提升写入吞吐，bulk 大小需测试找到最优（如几百到几千条/批）。refresh 与 translog：refresh 控制索引在内存中可见的频率（默认 1s），提高 refresh 间隔可提升写入吞吐但降低可见性；translog 是写前日志，保证数据安全，可将 translog 的 fsync 改为异步（index.translog.durability=async）提升吞吐但增加宕机丢数据风险。副本数与写入：每个副本都要写入，副本数越多写入开销越大，降低副本数（如 0）可提升初始写入吞吐（副本可后续补）。写入调优需权衡吞吐、可见性与数据安全。

写入是"批处理 + 异步刷新 + 降低副本"的组合。bulk 提升吞吐，refresh 频率与 translog 决定可见性与安全，副本数影响写入放大。调优要根据实时性、可靠性与吞吐需求权衡。

• snapshot 仓库配置
• snapshot 分类
• 备份策略

ES 通过 snapshot 实现备份，需先注册仓库（repository），支持 filesystem、S3、HDFS 等类型。snapshot 可全量或增量，按索引/集群进行。备份策略：定期（如每日）执行 snapshot，保留多个版本，结合 ILM 管理 snapshot 生命周期；snapshot 需在仓库中留存足够份额。恢复演练：定期执行 restore 验证备份可用性，模拟故障恢复流程，确认数据完整；恢复支持从任意索引 snapshot 恢复。运维上需配置仓库、制定备份策略、演练恢复，RPO/RTO 需满足 SLA。

备份是数据安全的最后防线。snapshot 仓库配置是基础，备份策略决定 RPO，恢复演练保障 RTO。恢复演练要验证备份可实际恢复、数据无损，避免"备份不可用"。

• 节点 OOM
• GC 频繁
• master 选举异常

节点 OOM：多为堆内存不足或大量数据加载，需检查堆使用、circuit breaker、fielddata 与聚合，调整堆或限制查询。GC 频繁：堆内存压力大或 GC 配置不当，表现为 GC 时间长、频繁 Full GC，需优化堆、减少内存占用、检查查询。master 选举异常：master 节点故障或网络分区导致无法选举，需检查 master 节点健康、网络与 quorum 配置。恢复卡住：分片恢复慢或卡住，多因磁盘 IO 慢、node 数不足、副本数配置不合理，需检查恢复进度与资源。运维上需监控堆、GC、master 与恢复进度，及时处置。

排障要看"资源 + 集群状态"。OOM 与 GC 是内存问题，master 选举是协调问题，恢复卡住是 IO/资源问题。定位需结合日志、集群状态与系统指标，恢复需先解决根因。

• filter 缓存
• fielddata 优化
• 聚合优化

filter 缓存：filter 查询（bool 中的 filter）会被缓存，被频繁使用的 filter 能显著提升查询性能，应尽量用 filter 而非 query 做过滤。fielddata：聚合/排序需要 fielddata，内存开销大，应使用 doc_values 代替 fielddata（doc_values 是磁盘上的列式存储，避免内存加载），并限制 fielddata 大小。聚合优化：避免过大聚合、合理设置聚合大小、使用 composite 聚合分页、减少聚合字段数量。slowlog：配置慢查询日志（search slowlog 与 index slowlog），记录超过阈值的慢查询，定位性能瓶颈。运维上需配置 slowlog、优化 filter 与聚合、监控查询延迟。

查询优化围绕"缓存命中 + 减少内存 + 定位慢查询"。filter 缓存提升命中，doc_values 替代 fielddata 减少内存，聚合优化降低开销，slowlog 定位问题。优化目标是降低查询延迟与资源占用。

• 集群/节点/索引三级指标
• CPU 与 heap 指标
• search/indexing 延迟

ES 监控分三级：集群级（健康状态、节点数、分片数、未分配分片、集群吞吐）、节点级（CPU、堆内存、GC、磁盘 IO、网络、search/indexing 延迟）、索引级（索引大小、文档数、search/indexing 速率、segment 数）。告警设计：CPU 使用率过高（如 >85%）、堆内存过高（如 >80%）、GC 频繁、search/indexing 延迟超阈值、磁盘水位、健康状态变化、未分配分片。告警分级：健康状态、磁盘水位、OOM 为高优先；CPU、堆、延迟为中优先。通过 Prometheus（elasticsearch_exporter）采集指标，在 Grafana 建立大盘并设置告警。

监控是"资源 + 性能 + 健康"三个维度。集群级看整体健康，节点级看资源与性能，索引级看单索引行为。告警需分级，避免风暴，重点关注数据安全与可用性指标。

• 索引模板与动态 mapping
• 动态 mapping 陷阱
• 字段类型冲突

索引模板（index template）定义新索引的 settings 与 mapping，实现统一管理。动态 mapping：ES 默认自动推断字段类型，虽然方便但可能误判（如数字被当作 text、日期格式错误），导致后续查询/聚合错误，这是动态 mapping 的陷阱。规避：显式定义 mapping（结合模板）、关闭 dynamic 或设置 dynamic 为 strict。字段类型冲突：同一字段在不同索引/文档中出现不同类型会导致查询失败，需在 mapping 层统一类型。reindex 迁移：当 mapping 需变更（如字段类型改）时，用 reindex 将旧索引数据搬运到新索引（新 mapping），再切别名。运维上需合理使用模板、显式 mapping、reindex 处理变化。

mapping 是 ES 数据模型的核心。动态 mapping 省事但易误判，显式 mapping + 模板是规范。字段类型冲突需建模层统一。reindex 是"类型变更"的唯一路径，配合别名实现无缝切换。

• 节点角色划分
• master 专用节点
• 水平扩容

ES 节点可按角色划分：master（专用主节点，负责集群元数据与协调，建议独立部署，避免与 data 混合导致资源争抢）、data（数据节点，存储分片，分为 hot/warm/cold）、ingest（预处理节点，处理文档管道）、coordinating（协调节点，只做请求路由与聚合协调，不存数据）。节点角色划分用于资源隔离与性能优化。水平扩容：增加 data 节点分散分片与 IO，增加 coordinating 节点提升查询并发。分片再平衡：新增节点后 ES 自动将分片迁移到新节点平衡，可配置 rebalance 的并发与流量控制（cluster.routing.allocation）。运维上需按规模选择节点角色，扩容后观察再平衡。

节点角色分离是 ES 规模化部署的关键。专用 master 保障元数据稳定，data 分离存储，ingest/coordinating 提升处理与查询。扩容是加节点，再平衡是自动迁移，需控制再平衡流量。

• 分片分配过滤（allocate）
• 机架感知（rack awareness）
• 手动 reroute

分片分配过滤：通过 cluster.routing.allocation.* 或 index.routing.allocation.* 配置，将分片分配到特定节点（如按节点名、属性），用于节点隔离、迁移或维护。机架感知（rack awareness）：通过 node.attr 与 cluster.routing.allocation.awareness.attributes 配置，让副本分片分布在不同机架/AZ，避免单机架故障导致副本全丢。手动 reroute：通过 _cluster/reroute 手动移动、分配或取消分片，用于故障恢复或手动均衡。再平衡流量控制：通过 cluster.routing.allocation.cluster_concurrent_rebalance、node_concurrent_recoveries 等配置控制再平衡的并发与带宽，避免迁移冲击业务。运维上需结合过滤、机架感知与流量控制管理分片分配。

分片分配控制是"数据放置策略"。allocate 过滤隔离节点，rack awareness 实现容器容灾，reroute 手动干预，再平衡流量控制保障平滑。运维需在维护、扩容、故障时合理使用这些机制。

• 冷热数据架构
• data stream 概念
• 索引模板与别名

冷热数据架构：按数据访问频率将索引分布在 hot（热，SSD，高频读写）、warm（温）、cold（冷，低成本存储）节点，老年数据迁移到冷节点降低成本。data stream：管理时序数据（如日志），它由多个后备索引组成，配合 ILM 与索引模板自动滚动创建新索引，读写通过 data stream 名称（统一别名）进行，支持按时间滚动。索引模板与别名作用：模板为 data stream 的每个后备索引定义 settings 与 mapping，别名（data stream 名称）提供统一的读写入口，无需关心具体索引。滚动写入：ILM 的 rollover 在索引达到阈值时自动创建新后备索引，写入切到新索引。运维上通过 data stream + ILM + 模板 + 冷热节点实现时序数据全生命周期管理。

data stream + ILM + 模板 + 别名是 ES 时序数据治理的标准组合。冷热架构降低存储成本，data stream 提供统一入口与滚动，模板定义结构，别名屏蔽索引细节。适合日志/指标类数据。

• 写入速率限制
• 分段合并（merge）的 IO 影响
• 段数控制

写入背压：ES 通过队列与熔断机制在写入压力过大时拒绝或降速，保护节点避免 OOM。分段合并（merge）：ES 将小段合并为大段提升查询性能，但 merge 是 IO 密集操作，会与查询争抢 IO，需控制 merge 的并发与速率（indices.store.throttle.type/throttle.max_bytes_per_sec）。段数控制：段数过多会降低查询性能、增加内存与 merge 开销，应通过合理 merge 策略与 flush 控制段数。避免写放大拖垮查询：高频写入会频繁触发 merge，占满 IO，导致查询变慢，需控制写入速率、合并策略、分片大小，并监控 merge 与查询延迟。运维上需平衡写入与查询的 IO 资源。

写放大（merge 与刷新）会挤占 IO 影响查询。写入背压与 merge 限流是保护手段，段数控制降低查询开销。运维需监控 merge 指标、IO 与查询延迟，合理配置避免写入拖垮查询。

• 远程集群配置（CCS）
• 跨集群复制（CCR）
• 容灾场景

跨集群搜索（CCS）：通过 remote cluster 配置，让一个集群可以跨集群搜索其他集群的索引，用于多集群统一检索。跨集群复制（CCR）：通过 follower index 将 leader index 的数据复制到其他集群，实现容灾与分中心部署。容灾场景：跨集群复制用于主备/多活容灾，本地集群故障时切换到有复制数据的集群。一致性边界：CCR 是异步复制，有复制延迟，跨集群数据是最终一致（leader 数据先变，follower 滞后）；CCS 是实时跨集群查询，但网络延迟与可用性影响。运维上需配置远程集群、CCR 复制、监控复制延迟与一致性。

CCS 与 CCR 是 ES 多集群能力。CCS 用于"跨集群统一查询"，CCR 用于"跨集群数据复制容灾"。CCR 是异步的，有延迟与最终一致性，容灾需考虑 RPO。运维需监控复制延迟。

• ELK 架构与 ES 角色
• 容量规划
• 写入放大

ELK 中 ES 承担日志与搜索的存储检索。容量规划：根据日志量、索引保留时长、副本数、分片数估算存储与节点规模，预留 IO 与内存。写入放大：日志场景写入量大，bulk 写入、refresh/merge 会产生写放大，需控制写入速率与 merge。成本控制：通过数据流 + ILM 冷热分层将老数据迁移到廉价存储或删除，控制索引数量与副本数，使用压缩与精简 mapping。运维上需结合日志场景规划容量与成本，避免无限增长。

ELK 场景是写多读少，容量规划与成本控制是重点。冷热分层、ILM 归档、副本与分片控制是降低成本的关键。写入放大需管理 merge 与 refresh 避免 IO 瓶颈。

• RBAC 角色权限
• 索引级权限
• 字段级安全

ES 通过 X-pack 安全实现多租户：RBAC（基于角色的访问控制）定义角色（role）与权限，角色绑定到用户，用户拥有角色权限。索引级权限：通过角色授予对特定索引的 read/write/delete 等操作权限，实现索引级隔离。字段级安全：通过 field_security 在角色中限制用户可访问的字段，实现字段级脱敏。审计日志：记录认证、授权、访问事件，用于安全审计。运维上需设计角色与权限模型、配置索引与字段级权限、开启审计日志。

ES 多租户安全的层级是"集群/索引/字段"。RBAC 管理用户与角色，索引级权限隔离租户，字段级安全脱敏敏感字段，审计日志追溯。需按租户设计权限模型。

• 版本升级兼容性
• 全集群重启与滚动重启差异
• 升级前检查

ES 滚动升级：逐个节点升级，期间集群保持可用。与全集群重启（全部节点同时重启，集群短暂不可用）相对，滚动升级保证在线。版本兼容性：升级需遵循版本间兼容性（major/minor 升级路径），跨大版本升级需分步，且需关注 breaking changes（如节点角色、licensing、配置变化）。升级前检查：备份（snapshot）、检查 breaking changes、确认兼容性、检查健康状态、禁用 shard 分配（避免恢复冲击）、升级后逐步恢复。升级风险：版本不兼容、配置变更、数据格式变化可能导致故障。运维上需在低峰升级、演练、回退预案。

滚动升级是 ES 在线升级的标准方式，但有版本兼容性约束。升级前检查（备份、breaking changes、健康）是必须，升级后恢复 shard 分配。全集群重启仅适用可停机场景。升级高风险需演练。

• SSD/HDD 节点角色取舍
• 冷热分层存储成本模型
• 快照归档

磁盘选型：hot 节点（高频读写、查询）用 SSD，保证 IO 与查询性能；warm/cold 节点（低频访问）用 HDD，降低成本；master 节点不需要大容量，普通 SSD 即可。冷热分层存储成本模型：通过节点角色（hot/warm/cold）放置不同磁盘，老数据迁移到冷节点用 HDD，存储成本低但查询慢，形成"热快冷省"的成本模型。快照归档：将不常访问或不需 ES 检索的数据通过 snapshot 归档到低成本存储（S3 等），并从 ES 移除释放资源，需要时再恢复。运维上需按数据访问频率选择磁盘，结合冷热分层与快照归档控制成本。

存储选型是"性能 vs 成本"的权衡。SSD 用于热数据保障性能，HDD 用于冷数据降低成本，快照归档释放 ES 资源。冷热分层 + 归档是 ES 存储成本优化的核心。