Elastic Stack 和 IBM Platform EGO 的集成与实战（1）

look_w

目前，大数据和云计算可谓是如火如荼，大部分 IT                技术和方案都朝着这两个方向积极靠拢，随着大数据和云计算平台的功能越来越强大，其结构也越来越复杂，一个基本的大数据平台，仅组件就多达数十种，这还不包括用户的上层应用和广泛的物联网的系统组件。这么庞大的系统整合在一起，对于运维来说，是十分头疼的事情。如此复杂的系统，“不得病”是不可能的。那么，一旦“得病”，如何快速准确的找到“病因”，并有效的对症下药，则显得极为重要。如何为大数据和云计算平台“治病”呢？在这种背景和需求下，日志处理分析系统和监控模块应运而生。
目前，日志分析工具多达数十种，其中应用较多的有 Splunk、Elastic、AWStats、Graphite、LogAnalyzer、Rsyslog、Log watch、Open Web Analytics 等等，其中，Splunk 是一款顶级的日志分析软件，从收集、处理、展现一条线服务，基本的日志分析监控都支持，其属于商业运营产品。AWStats 是在                 上发展很快的一个基于 Perl的WEB 日志分析工具。Graphite 是一个用于采集网站实时信息并进行统计的开源项目，可用于采集多种网站服务运行状态信息。LogAnalyzer 是一个 Web 前端工具，提供简单易用的日志浏览、搜索和基本分析以及图表显示。Rsyslog 可以理解为 syslogd 工具的多线程增强版。Open Web Analytics 是一个开源的网站流量统计系统。Logwatch，顾名思义，是一款专门监测 Linux log 文件（日志文件）的软件。这些工具（除了 Splunk 外），在功能上都有些欠缺，或者上，在特定的场合，可以大展身手，但并不能适用于所有的场合。而 Elastic Stack 方案则不同，功能相对来说比较完善，性能比较稳定。由于其开源性，使得 Elastic Stack 在最近两年迅速崛起，成为机器数据分析和实时日志处理领域的第一选择。
最开始，将 Elastic Stack 称之为 ELK，ELK 是 Elasticsearch, Logstash, Kibana 的简称，各取这三个核心套件的首字母。这三个软件均是开源的。本文着重讨论 Elastic Stack 方案，并详细阐述 Elastic Stack 和 Platform EGO 来深度集成.从功能上来说，二者可以相辅相成，让 Platform EGO（Enterprise Grid Orchestrator）来为 Elastic 分配运行的资源和服务管理，与此同时，用 Elastic 来监控 Platform EGO 的运行情况。
一、Elastic Stack                 结构体系 Elastic Stack 的体系结构如图1 所示。从下图可以看出，在 Elastic Stack 中，除了我们上文中提到的 Elasticsearch, Logstash, Kibana “三大金刚” 之外，还有一个主要的部分: Beats。
Beats 是一个轻量级的工具，主要功能是在客户端收集日志和数据（比如网络数据，机器性能数据等。其轻量性，是相对于 Elasticsearch 和 logstash 来说，占用的 CPU 和内存资源较少，基本不会影响到用户的上层应用的正常运行。目前官方已经有好几种 Beats, 比如最常用的 Filebeat, Metricbeat, Packetbeat，Winlogbeat 等。Beats 支持用户自己开发，而且在开源社区里，我们可以找到更多的 Beats。
Logstash 负责接收从 Beats 发送过来的数据，并实时分析和处理，并实时转发给Elasticsearch，Logstash 本身不具有存储功能，只是一个管道而已。Logstash 主要有三个部分，也可以说是三种 Plugin: Input，Filter 和 Output。Input 部分配置的是数据源，可以是文件，也可以是 Beats 等输入源。Filter 对日志经过过滤和处理。Output 配置的是输出的目的地，可以是一个文件，也可以是 Elasticsearch（本文中的示例）。
ElasticSearch 在 Elastic Stack 中最为复杂、最主要的一个组件，具有全文搜索和分析引擎，提供搜集，分析，存储数据三大功能。
Kibana 是一个基于 Web 的图形界面，用于搜索、分析和可视化存储在 Elasticsearch 中的日志和数据。
在此，值得一提的是，Logstash 也有 Filebeat 的功能，其 Input plugin 的功能非常强大，有数十个之多，但是笔者不建议将 Logstash 直接部署到客户端来收集数据，因为 Logstash 会占用部分系统资源，可能会影响到上层应用的正常，得不偿失。Logstash 可以部署到管理节点上来收集数据，一来很多数据和日志都在管理节点上（只需要配置 Input plugin ），二来一般情况下，管理节点比较强大，可以很好的支持 Logstash 的满负荷运行。
图1     Elastic的体系结构 从此体系结构图中，我们可以看出，Elastic Stack 工作的主要流程为：各种 Beats 部署在客户端，用来收集、解析、转换数据。如图所示，我们将 Elasticsearch、Logstash、Kibana 部署在集群的管理节点上，或者专门部署一个（在高可用环境下，可能有数台）服务器上。Beats    收集到数据之后，可以直接发给 Elasticsearch ,但一般情况下，先发送给 Logstash 来进行日志的处理和优化。其实， Beats 本身也有处理日志的功能，但相对于 Logstash 来说，较为简单，不能满足大部分处理需求，另外一个原因是，尽可能的降低 Beats 端的负载，有利于集群性能的提升。日志经过 Logstash 这个管道之后，再插入到 Elasticsearch 中存储和检索，最后由 Kibana 展示出来。
目前 Elastic 官方已经推出了 5.0 版本。Logstash 支持了 Cluster 模式，也就是说 Logstash 本身具有的负载均衡和高可用性等特点，并且在资源利用率上，也作出了很大的优化，使得性能和处理日志的速度都有了很大程度的提高。