《Elastic Stack 实战手册》——三、产品能力——3.1.理解 Elastic Stack——3.1.1.从 Elasticsearch 到 Elastic Stack(上) https://developer.aliyun.com/article/1231738
最初发展的问题
早期，Elastic 开发和发布软件时采用的是工程师各自为战的方法：工程师可以在任何时候推出
任何喜欢的版本，唯一的要求就是产品要好。Kibana 有公测版，Logstash 采用里程碑，
Elasticsearch 则采用数字编号。如果工程师高兴，还可以推出插件。尽管十分混乱，但是一切
还算行得通，直到最后无法使用。
随着用户通过产品来完成越来越多的任务，Elastic 需要开发更好的产品来为用户提供更多帮
助，所以添加了更多功能，开发了新插件和扩展。产品的确变得越来越好了，然而也越来越复
杂，技术栈变得越来越混乱。
例如，如果运行的 Elasticsearch 是 1.7 版本，而运行的其他插件是 2.3 版本，则软件不能自
动检测二者是否兼容，也无法验证插件是否在无预警的情况下已不能正常使用。
在 Elastic，也开始听到内部员工说：“如果想使用 Shield，需要使用 Elasticsearch 1.4.2，
但前提是不能使用 Watcher。如果使用 Watcher 的话，则需要使用 Elasticsearch 1.5.2。而
如果使用 Elasticsearch 1.5.2 的话，其仅能与 Kibana 4.0.x、Logstash1.4.x、Shield 1.2.x
和 Watcher 1.0.x 兼容。”
Elastic 的版本控制做得一团糟，必须得研究对策；同时，支持矩阵也表现欠佳。
调整业务步伐，推出 Beats就在产品团队为版本编号忙得团团转的时候，另外一个产品故事正在拉开序幕。Elastic 在 2015 年迎来了 Packetbeat，这是一家夫妻档公司，致力于开发一种轻量化方式来将网络数据发送至 Elasticsearch。
这启发了当时的 Elastic：如果开发一系列单一用途的轻量化数据传送工具，将网络数据、日志、
指标、审计数据等从边缘机器传输到 Logstash 和 Elasticsearch，结果会怎样？就这样，
Beats 应运而生了。
同步推出新产品版本
2015 年 10 月对 Elastic 来说是一个重大转折点，因为解决了产品版本编号问题，同时也降低
了兼容性的复杂程度。
这一发布版本又称为“Bonanza 同步版”，是 Elastic 第一次在同一天面向公众发布全部产品：
Elasticsearch2.0、Logstash 2.0、Watcher2.0、Shield 2.0 和 Kibana 4.2。
通过这次调整，用户得以更轻松地启用产品，同时也提高了产品的可靠性，帮助用户出色地完
成任务。
一键部署，Elastic Cloud 隆重推出
几个月后，“Bonanza 同步版”不再仅仅局限于供人们下载的产品，通过 Elastic Cloud（即
之前的 Found），在 AWS 上推出了 Elasticsearch 和 Kibana 服务。
2016 年
Elastic Stack 5.0
Elastic 致力于推出更为成熟的产品系列，通过发布 Elasticsearch 2.0 来统一发布步调就是第
一步，5.0 的发布则是第二步。与之前的所有版本相比，用户通过这一版本可以体验集成性能
更强，经过更严格测试且更加易于入门的产品。
5.0 发行版本的同时还将所有商用插件（当时被称为 Shield、Marvel 和 Watcher）整合为单一
扩展，即 X-Pack，其包含了核心产品，诸如 security、monitoring 和 alerting 等的功能，并
且随着 Prelert 公司也加入 Elastic，machine learning 也开始纳入其中。
模块应运而生
在 5.3 版本中，Filebeat 正式引入了“模块”的概念，可以将模块理解为用于在 Elastic
Stack 中传输、解析、存储、分析常用日志格式（例如 Apache、Nginx 和 MySQL 等），并
实现可视化的一组安全配置，它简化了用户从数据集至仪表板的入门体验。
Metricbeat 和 Packetbeat 的模块都各具特色，几个月后，Logstash 也将针对 ArcSight 和
NetFlow 数据引入自身模块。
《Elastic Stack 实战手册》——三、产品能力——3.1.理解 Elastic Stack——3.1.1.从 Elasticsearch 到 Elastic Stack(下) https://developer.aliyun.com/article/1231736
