2. Elastic技术栈选型与版本规划

Elastic技术栈并不是单一产品，而是一组围绕搜索、分析、采集与可视化协同工作的组件集合。做选型时，最容易犯的错误是“先选组件，再想数据怎么流”。更合理的顺序是：先明确数据从哪来、要经过哪些处理、最终以什么形式被查询和展示，再决定每个环节由哪个组件承担。Elasticsearch是存储与检索核心，Kibana负责可视化与交互，Logstash承担重加工与多源汇聚，Beats负责轻量采集，Elastic Agent则把采集、保护与集中管理整合到统一策略下。它们之间不是替代关系，而是按数据流位置分工。

从数据流角度看，一条日志或指标通常经历“采集 → 缓冲/传输 → 解析/富化 → 索引 → 查询/可视化”几个阶段。Beats适合部署在边缘节点，资源占用低，擅长文件、系统指标、网络流量等采集；Elastic Agent在8.x之后成为官方主推的采集入口，通过Fleet集中下发策略，可同时运行Filebeat、Metricbeat、Osquery等集成，适合节点数量多、策略需要统一管理的场景。Logstash位于更靠后的处理层，插件生态丰富，适合做grok解析、字段映射、条件分支、多路输出和与外部系统对接。若采集端已经能完成结构化，且吞吐压力不大，也可以让Beats直接写入Elasticsearch，减少一跳。

版本规划是选型之后最容易踩坑的环节。Elastic官方对版本兼容性的基本要求是：Elasticsearch、Kibana、Beats、Logstash、Elastic Agent应尽量保持同一主版本，例如统一使用8.x系列。跨主版本混用虽然在某些小版本间可以工作，但会带来API行为差异、索引模板不兼容、安全配置变化等问题。特别是7.x到8.x的升级，涉及安全默认开启、REST API部分废弃、索引模板从legacy template迁移到composable template，必须提前评估。

升级策略上，推荐“先存储、再展示、后采集”的顺序。先升级Elasticsearch集群，采用滚动升级方式逐节点重启，确保分片分配和副本恢复完成后再操作下一个节点；Kibana随后升级，注意保存对象和空间权限的兼容性；最后升级Beats和Elastic Agent，因为采集端版本通常可以向后兼容写入较新版本的Elasticsearch。对于Logstash，若使用了自定义插件，需要先确认插件是否支持目标版本，再执行升级。

下面给出一份可参考的版本规划检查表，用于升级前逐项确认。表中字段可根据实际环境调整，但核心判断项不应省略。

在具体操作层面，升级前应先在测试环境用真实索引和查询做兼容性验证。例如，将生产索引的快照恢复到测试集群，运行常用查询和聚合，观察是否有字段类型冲突、查询语法报错或性能明显下降。对于使用Elastic Agent的场景，还要确认Fleet Server与Agent版本匹配，策略下发是否正常。升级完成后，重点观察集群健康状态、JVM堆内存、查询延迟和采集延迟四项指标，确认无异常后再逐步扩大流量。

选型与版本规划不是一次性工作，而是随业务规模和数据量持续调整的过程。初期数据量小，可以用Beats直写Elasticsearch加Kibana展示，快速上线；当解析逻辑变复杂、需要多路输出时，再引入Logstash；当节点数量增长到几十上百台，手工管理采集配置成本过高时，再切换到Elastic Agent加Fleet集中管理。版本上则保持“小步快跑、同主版本对齐、升级前必验证”的原则，才能让整个技术栈长期稳定运行。