问候大家！ 我在
Onlanta担任系统工程师。 在我们的一个项目中，我参与了Elastic Stack的实施和维护。 从虚拟地手工收集日志到集中化的自动化流程。 两年来，我们几乎没有改变解决方案的体系结构，并计划在其他项目中使用便捷的工具。 我将与您分享其实施的历史，以及本帖子中的一些优点和缺点。
来源可以这么说，在2016年初，我们的管理员和开发人员的日志“在您的指尖”，也就是说，工程师与他们一起通过SSH连接到他感兴趣的服务所在的主机，从而发现了tail / grep / sed的通用集。 / awk，并希望有可能在此主机上找到必要的数据。
来源我们还拥有一台单独的服务器，其中所有服务器的日志目录都通过NFS挂载，有时人们对于每个人都希望对日志进行处理的想法被考虑了很长时间。 好吧，tmux的一些面板在自动更新的原木上尾部排列，这对于大型显示器上的局外人来说非常令人印象深刻，并且营造了一种参与生产圣餐的令人兴奋的氛围。
所有这些甚至都有效，但是恰好在必须快速处理大量数据之前，而这恰恰是在产品掉落时需要的。
有时调查事件花费的时间不雅。 其中很大一部分花在了手动聚集日志，使用Bash和Python启动各种脚本的
拐杖 ，等待日志上传到某处进行分析等方面。
一言以蔽之，这一切都是非常缓慢的，受到沮丧的启发，并明确暗示该是时候参加日志的集中存储了。
老实说，没有一个复杂的过程可以为我们提供技术堆栈的角色选择候选人：那时ELK捆绑包已经很流行了，有很好的文档，Internet上有很多关于所有组件的文章。 决定是即时的：您需要尝试。
来源在三个虚拟机上观看了“ Logstash：60中的0-60”网络研讨会之后，就完成了堆栈的首次安装，每个虚拟机都启动了Elasticsearch，Logstash和Kibana的实例。
此外，我们在将日志从最终主机传送到Logstash服务器时遇到了一些问题。 事实是，那时Filebeat（用于从文本文件传递日志的标准堆栈解决方案）在处理大型且快速更新的文件时效果要差得多，这些文件经常在RAM中泄漏，对于我们而言，整个情况下它无法应付其任务。
此外，还需要找到一种从运行IBM AIX的机器上交付应用程序服务器日志的方法：然后，我们的大部分应用程序都在WebSphere Application Server中启动，该服务器专门在此OS下工作。 Filebeat是用Go编写的，2016年没有用于AIX的高效Go编译器，我真的不想使用Logstash作为交付的代理。
我们测试了几种日志传递代理：Filebeat，logstash-forwarder-java，
log-courier ，python-beaver和NXLog。 从代理中，我们期望有高性能，低系统资源消耗，易于与Logstash集成以及在代理的作用下执行基本数据操作的能力（例如，多行事件的组合）。
关于多行事件的组装，值得一提。 实际上，它只能在读取特定文件的代理程序一侧执行。 尽管Logstash曾经有一个多行过滤器，现在有了一个多行编解码器，但是我们所有尝试将多个Logstash服务器之间的事件平衡与多行处理结合在一起的所有尝试都失败了。 这种配置几乎不可能实现有效的事件平衡，因此，对于我们来说，选择代理程序时最重要的因素是多线支持。
优胜者如下：Linux机器的日志快递，AIX机器的NXLog。 通过这种配置，我们生活了将近一年没有出现任何问题：日志已交付，代理没有跌倒（很好，几乎），每个人都很高兴。
2016年10月，发布了Elastic Stack组件的第五个版本，其中包括Beats 5.0。 在此版本中，所有Beats代理都做了很多工作，并且我们可以用Filebeat替换日志传递器（当时它有其自身的问题），我们仍然使用Filebeat。
迁移到5.0版时，我们不仅收集日志，而且还收集一些指标：Packetbeat在这里和那里开始使用，替代了将HTTP请求日志写入文件的方法，Metricbeat收集了系统指标和某些服务的指标。
至此，我们的工程师使用日志的工作变得更加简单：现在无需知道要去查看您感兴趣的日志的服务器，简化了信息交换，只需将链接转移到聊天室或邮件中的Kibana以及以前生成的报告即可。在几小时内，几秒钟内开始创建。 不能说这只是一个安慰问题：我们注意到工作质量，已完成任务的数量和质量以及对我们展位的问题响应速度的变化。
在某个时候，我们开始使用Yelp的ElastAlert实用程序将警报发送给工程师。 然后我们想到：为什么不将其与我们的Zabbix集成在一起，以使所有警报具有标准格式并集中发送？ 解决方案很快找到了：ElastAlert使您可以运行任何命令，而不必发送警报，而这是我们使用过的。
现在，我们的ElastAlert规则在被触发时会在几行上执行一个bash脚本，从触发该规则的事件的参数中将必要的数据传递到该脚本，然后从脚本中调用zabbix_sender，该脚本会将数据发送到所需节点的Zabbix。
由于有关事件产生者和地点的所有信息在Elasticsearch中始终可用，因此集成没有困难。 例如，我们以前有一种自动检测WAS应用程序服务器的机制，并且在它们生成的事件中，总是写入服务器，集群，单元等的名称。 这使我们可以在ElastAlert规则中使用query_key选项，以便分别为每个服务器处理规则的条件。 然后，带有zabbix_sender的脚本将获取服务器的确切“坐标”，并将数据发送到相应节点的Zabbix。
我们真正喜欢的另一个解决方案是，通过集中收集日志，该解决方案得以实现，它是一个脚本，用于在JIRA中自动创建任务：每天一次，它会清除日志中的所有错误，如果还没有任务，则启动它们。 同时，从具有唯一请求ID的不同索引中，所有对调查有用的信息都将被放入任务中。 结果是一种具有必要最小信息的标准工件，然后工程师可以在必要时进行补充。
当然，我们面临着监视堆栈本身的问题。 这部分使用Zabbix实施，部分使用相同的ElastAlert实施，并且使用堆栈中内置的标准监视（X-Pack中的监视组件）获得Elasticsearch，Logstash和Kibana的主要性能指标。 另外，在具有堆栈服务本身的服务器上，我们已经安装了
Firehol的netdata。 当您需要实时，高分辨率地查看当前特定节点的情况时，此功能很有用。
曾几何时，Elasticsearch监视模块在其中被稍微破坏了，我们找到了它，进行了修复，添加了各种有用的指标并提出了拉取请求。 因此，现在netdata可以监视Elasticsearch的最新版本，包括基本JVM指标，索引，搜索性能指标，事务日志统计信息，索引段等。 我们喜欢Netdata，并且很高兴我们能够为此做出一点贡献。
今天，将近三年后，我们的弹性堆栈看起来像这样：
工程师通过三种主要方式使用堆栈：
- 查看和分析Kibana中的日志和指标；
- Grafana和Kibana中的仪表板；
- 使用SQL或内置查询DSL直接向Elasticsearch查询。
总共分配了所有这些资源：为Elasticsearch数据仓库分配了146个CPU，484GB RAM，17TB。
共有13台虚拟机作为Elastic Stack的一部分工作：4台用于“热” Elasticsearch节点的计算机，4台用于“热”节点，4台具有Logstash的计算机和一台平衡机。 在每个热节点上，Elasticsearch运行一个Kibana实例。 它从一开始就发生了，到目前为止，我们还没有必要将Kibana转移到单独的汽车上。
但是，最终决定将Logstash带到单独的机器上是栈操作期间最正确，最高效的决定之一：JVM Elasticsearch和Logstash之间CPU时间的激烈竞争导致负载突增期间的效果不是很令人满意。 垃圾收集者受害最多。
来源我们将最近30天的数据存储在集群中：现在大约有120亿个事件。 每天，热节点都会以最大压缩率（包括分片副本数据）向400-500 GB磁盘写入新数据。 我们的Elasticsearch集群具有热/热架构，但是我们是在最近才切换到该架构的，因此与“热”节点相比，“热”节点上存储的数据仍然较少。
我们的典型工作量：
- 索引-平均13,000 rps，峰值可达30,000（不包括复制到副本碎片中的索引）；
- 搜索-5200 rps。
我们试图在Elasticsearch热节点上维持40-50％的CPU余量，以便我们可以轻松地体验到索引事件数量的突然激增以及来自Kibana / Grafana或外部监控系统的大量请求。 具有Elasticsearch节点的主机上约有50％的RAM始终可用于JVM的页面缓存和堆外需求。
在第一个集群启动以来的一段时间内，我们设法为自己确定了Elastic Stack的某些正面和负面方面，以此作为汇总日志和搜索与分析平台的一种手段。
我们特别喜欢堆栈：- 一个产品生态系统可以很好地相互集成，几乎可以满足您的所有需求。 Beats曾经不是很好，但是现在我们对此没有任何抱怨。
- Logstash具有所有怪异之处，是一种非常灵活且功能强大的预处理器，可让您处理大量原始数据（如果某些操作不允许这样做，则始终可以用Ruby编写一个代码段）。
- 带有插件的Elasticsearch（最近才提供）支持将SQL作为查询语言，从而简化了与其他软件以及更接近SQL作为查询语言的人们的集成。
- 高质量的文档，可让您快速地将新员工介绍给项目。 因此，堆栈的操作不会成为拥有某些特定经验和“秘密知识”的人的业务。
- 无需太多了解接收数据的结构就可以开始收集它们：您可以按原样开始聚合事件，然后，当您了解可以从中提取哪些有用信息时，可以更改处理它们的方法而不会失去“向后兼容性”。 为此，在堆栈上有许多方便的工具：索引中的字段别名，脚本字段等。
来源我们不喜欢的是：- X-Pack组件仅根据订阅模型进行分发，而没有其他内容：例如，如果从Gold那里，仅支持RBAC或PDF报表，那么您将不得不为Gold所拥有的一切付费。 例如，当您仅需要Platinum的Graph并可以购买机器学习以及其他您可能不需要的其他功能时，这尤其令人沮丧。 大约一年前，我们与Elastic销售部门就许可单个X-Pack组件进行沟通的尝试并没有带来任何结果，但是从那以后也许有所改变。
- 相当频繁的发行版本，它们（每次都是新的）破坏了向后兼容性。 您必须非常仔细地阅读变更日志，并事先准备进行更新。 每次需要选择时：保持稳定运行的旧版本，或者尝试升级以获得新功能和性能。
总的来说，我们对2016年的选择感到非常满意，我们计划将操作Elastic Stack的经验转移到我们的其他项目中：堆栈提供的工具已紧密集成到我们的工作流程中，现在很难拒绝它们。