发展历程

在 Elasticsearch Inc. 成立前后，另外两个开源项目也正在跨越式发展。

Jordan Sissel 当时在开发 Logstash，这是一款开源的可插拔数据采集工具，可将日志文件发送至用户选择的 “储藏库” 。除此之外，他当时还在开发一款 UI 以实现日志数据的可视化，然而这一产品的稳定性却实在让人难以恭维。

幸运的是，还有其他人也在潜心钻研可视化这个难题。这个人就是 Rashid Khan，他当时在开发一款名为 Kibana 的开源 UI。

Shay、Jordan 和 Rashid 彼此都已认识一段时间，对各自的产品也颇为了解，所以他们最终决定携手共同发展，ELK Stack 正式面世，即：Elasticsearch、Logstash 和 Kibana Stack。

不久之后，我们就推出了两个商用插件：一是用于监测的 Marvel，二是用于防护的 Shield。

在 2015 年于旧金山举行的 Elastic{ON} 大会上，我们宣布了两项重要内容。第一点：我们将公司品牌更名为 Elastic。新的品牌名称能够更好地代表我们逐渐扩大的产品生态系统和用例套件。第二：我们与在 AWS 上提供 Elasticsearch 主机托管服务的公司 Found 实现了合作。通过这一合作，我们能够提供市场上最简单、最全面的产品组合。

早期，Elastic 开发和发布软件时采用的是工程师各自为战的方法：可在任何时候推出任何喜欢的版本，唯一要求就是产品要好。Kibana 有公测版， Logstash 采用里程碑，Elasticsearch 则采用数字编号。如果工程师高兴，还可以推出插件。尽管十分混乱，但是一切还算行得通……直到最后无法使用。

随着用户通过产品来完成越来越多的任务，我们需要开发更好的产品来为用户提供更大帮助。我们添加了更多功能，开发了新插件和扩展。产品的确变得越来越好了，然而也越来越复杂，我们的技术栈变得越来越混乱了。

举个例子吧，如果您运行的 Elasticsearch 是 1.7 版本，而运行的其他插件是 2.3 版本，则软件不能自动检测二者是否兼容，也无法验证插件是否在没有预警的情况下已不能正常使用。这是软件故障。

我们也开始听到内部员工说：“如果想使用 Shield，您需要使用 Elasticsearch 1.4.2……但前提是您不能使用 Watcher。如果使用 Watcher 的话，则您需要使用 Elasticsearch 1.5.2。而如果您使用 Elasticsearch 1.5.2 的话，其仅能与 Kibana 4.0.x、Logstash 1.4.x、Shield 1.2.x 和 Watcher 1.0.x 兼容。”

我们的版本控制做得一团糟，必须得研究对策；而且我们的支持矩阵也表现欠佳。是时候做出改变了。

就在产品团队为版本编号忙得团团转的时候，另外一个产品故事正在拉开序幕。Elastic 的大家庭在 2015 年迎来了位于柏林的 Packetbeat，这是一家夫妻档公司，致力于开发一种轻量化方式来将网络数据发送至 Elasticsearch。

这启发了我们：如果我们开发一系列单一用途的轻量化数据传送工具以将网络数据、日志、指标、审计数据等从边缘机器传输到 Logstash 和 Elasticsearch，结果会怎样呢？就这样，Beats 应运而生了。

2015 年 10 月是一个重大转折点，因为我们解决了产品版本编号问题，同时也降低了兼容性复杂程度。

这一发布版本又称为 “发布宝藏” ，这是我们第一次在同一天面向公众发布我们的全部产品：Elasticsearch 2.0、Logstash 2.0、Watcher 2.0、Shield 2.0 和 Kibana 4.2。（Beats 1.0 仍在酝酿中，还要再过一个月才能发布。）

协调完成这一重大举措并不是一件简单的事情。工程师团队需要改变合作方式以开发和测试产品。然而，这一切付出都是值得的。通过这次调整，用户得以更轻松地启用我们的产品，同时这也提高了我们产品的可靠性，帮助人们出色地完成任务。

几个月后，“发布宝藏” 不再仅仅局限于供人们下载的产品。我们通过 Elastic Cloud（即之前的 Found），在 AWS 上推出了 Elasticsearch 和 Kibana 服务。

我们致力于推出更为成熟的产品系列，通过发布 Elasticsearch 2.0 来统一发布步调便是第一步。5.0 的发布则是第二步。与之前的所有版本相比，用户通过这一版本可以体验集成性能更强、经过更严格测试且更加易于入门的产品。

5.0 发行版本同时还将我们的所有商用插件（当时我们称为 Shield、Marvel 和 Watcher）整合为单一扩展，即 X-Pack。其包括我们核心产品的诸如 security、monitoring 和 alerting 等功能，并且随着我们将位于伦敦的 Prelert 公司也吸纳入 Elastic 的大家庭，我们将 machine learning 也开始纳入其中。

在 5.3 版本（于 2017 年 3 月发布）中，Filebeat 正式引入了 “模块” 的概念，可以将模块理解为用于在 Elastic Stack 中传输、解析、存储、分析常用日志格式（例如 Apache、Nginx 和 MySQL 等）并实现可视化的一组安全配置。模块简化了用户从数据集至仪表板的入门体验。

Metricbeat 和 Packetbeat 的模块都各具特色，在几个月之后，Logstash 也将针对 ArcSight 和 NetFlow 数据引入自身模块。

从成立之初，我们就有一个愿景，即简化用户在他们的公司 / 组织部署 Elastic 的体验。我们采纳了管理自身 Elastic Cloud 服务时所用的技术，并发布了 Elastic Cloud Enterprise（又称 ECE），让所有规模的公司均能下载我们全部的托管产品，并独自运行，享受其带来的益处。有了 ECE，无论是一个集群，还是数千个集群，用户都能够顺利地对其进行管理，而且其还可以简化在任何环境中对 Elastic 产品和解决方案的管理和编排工作。

随着模块数量的成倍增加，使用 Elastic Stack 来处理特定用例（例如日志或指标）开始变得越来越简单。几个月后，我们并购了位于哥本哈根的应用程序性能监测 (APM) 公司 Opbeat 和位于旧金山的站点和企业搜索公司 Swiftype，由于这两家公司都加入了 Elastic 的大家庭与我们携手共进，因此我们业务发展的冲劲仍在继续酝酿。

此时，我们公司的发展已经日趋成熟，可以提供解决常见问题的精简方式，所以我们开始思考正式推出解决方案。尽管我们的解决方案从 DIY 体验到更加一站式的体验应用仅有，但是每套解决方案在背后都有真实的产品作为支撑，而且在短短几分钟内即可部署完毕。

从开放源码到开放沟通，公开透明一直是我们所有业务的核心。正因如此，我们决定开放商用 X-Pack 功能的源码，从而加速开发周期，提高社区互动，并让每个人都能够贡献源码、对源码添加评论并对其进行检查。

因此，用户能够更加轻松地开始使用 Elastic Stack，所有的 X-Pack 功能现在都默认提供 Elasticsearch、Kibana、Beats 和 Logstash。然而，这一改变并未删除任何 Apache 2.0 源码。恰恰相反，我们在开放源码的发展道路上加大了力度。

东部时间 10 月 5 日上午 9:30 整，纽约证券交易所的铃声响起，这标志着 Elastic 正式成为一家上市公司。交易大厅里有多达 230 名 Elastic 员工聚在这里（创下了纪录），而且在全球各地还有数百名员工也在密切关注着这一活动。作为一家分布式公司，各地员工共同庆祝这一重要时刻。虽然这只是我们漫长发展旅程中的一天而已，但是这一天却具有极其重大的意义。

我们的发展历程还在继续。我们的探索发现之旅会越来越精彩，敬请关注。