ELK结合Spark构建高可用架构及监控spark集群
1. ELK 系统是如何进行架构的？
2. 为什么ELK 在 Spark 集群中是高可用性构架？
3. ELK 可以监控 Spark 集群的哪些性能？
4. ELK 可以监控 Spark 集群的哪些作业？
解决方案：
概述
大数据处理技术越来越火,云计算平台也如火如荼,二者犹如 IT 列车的两个车轮,相辅相成,高速发展。如果我们将大数据处理平台比作一个可能会得病的人的话，那么日志分析系统就是给病人诊断的医生。由于集群甚大，几百台机器都是起步价，甚至可能会有上千台、上万台机器同时协作运行。如此大的集群，不可能一点问题都不出,就像一个人不可能不得病一样。如果出现问题，如何快速的找到问题的根源并对症下药，则显得至关重要。在这样的背景下，日志分析和监控系统也犹如雨后春笋，得到了空前的发展。
目前，日志分析工具多达数十种，其中应用较多的有 Splunk、ELK、AWStats、Graphite、LogAnalyzer、Rsyslog、Log watch、Open Web Analytics 等等，其中，领头羊的当属 Splunk 和 ELK，其中 Splunk 属于商业运营产品，而 ELK 属于开源产品。本文着重讨论 ELK 方案，并详细阐述 ELK 如何应用到 Spark 集群中。事实上，ELK 官方已称之为 Elastic,考虑行业内对此系统已经熟识，故而继续延用 ELK 来代替。
ELK 的应用大致可以分为两大类，一类是系统和应用的监控,可以通过 Kibana 做出不同的 Dashboard 来实时的监控集群的状况，比如 CPU 利用率，内存的使用情况，集群的 Job/Task 完成情况等；另一大用处在于快速的故障排查,运行中的集群在时时刻刻的打印日志，我们可以通过 ELK 系统来收集、存储和检索日志，然后通过关键字或者日志类型等查询条件来快速的查看用户感兴趣的 Log,以便快速的找出问题的根源。
一、ELK 系统架构
那么什么是 ELK 呢？ELK 是 Elasticsearch, Logstash, Kibana 的简称，是最初的 ELK 的三大核心套件，随着该系统的发展，多出了另外一个组件，我们称之为 Shipper 端，专门用来收集终端（集群中的机器）上日志和数据。其实 Logstash 本身就有收集功能，那么为什么还需要发展处另外一个 Shipper 端呢？主要是因为 Logstash 并非轻量级的工具，在运行过程中，占用了较多的资源（比如 CPU 和内存等），对于集群的整体性能来说无疑是一种损耗。所以，一般在终端上只运行轻量级的 Shipper 来收集日志。起初的 shipper 为 Logstash-forwarder,后来发展到了 Beats。下面对这四种工具逐一做简单介绍。
Logstash 是一个用来搜集，分析，过滤日志的工具。它支持几乎任何类型的日志，包括系统日志、错误日志和自定义应用程序日志。它可以从许多来源接收日志，这些来源包括 syslog、消息传递（例如 rabbitmq）和 jmx，它能够以多种方式输出数据，包括电子邮件、websockets 和 Elasticsearch。
Elasticsearch 是实时全文搜索和分析引擎，提供搜集，分析，存储数据三大功能；是一套开放 REST 和 JAVA API 等结构提供高效搜索功能，可扩展的分布式系统。它构建于 Apache Lucene 搜索引擎库之上。
Kibana 是一个基于 Web 的图形界面，用于搜索、分析和可视化存储在 Elasticsearch 指标中的日志数据。它利用 Elasticsearch 的 REST 接口来检索数据，不仅允许用户创建他们自己的数据的定制仪表板视图，还允许他们以特殊的方式查询和过滤数据。
Beats 负责在终端收集日志和数据，目前 Beats 有好几种，包括：Filebeat, Packetbeat, Metricbeat, Winlogbeat, Topbeat 等，用户还可以借助 Libbeat 来开发自己的 Beat。Filebeat 功能相当于 Logstash-forwarder，用在收集文件日志。 Packetbeat 用来收据网络方面的数据。Topbeat 已经合并到 Metricbeat 里面，用来收集系统或者某个指定的服务所占用的 Metrics, Winlogbeat 用来收集 Windows 系统上的日志信息。目前，已经有数十种 Community Beats，可供下载使用。
在不同的应用场景，ELK 系统的构架略有不同，比如说有的场景运用到了 Redis 或者 Kafka 来做消息队列，以减轻 Logstash 的压力，以防数据丢失。此文只讨论最为经典的构架。如图 1 所示。
图 1 ELK 的架构
其大致工作流程为：Beats 从终端机器收集到各种数据之后，发送给 Logstash 进行解析和格式化处理之后，再插入到 Elasticsearch 中存储，然后通过 Kibana 展示给用户。从上图中，我们可以看出，Beats 也可以直接将数据发送给 Elasticsearch，省略掉 Logstash 环节（假如所收集的数据不需要进一步的解析处理的话）。当然，在一般情况下，都需要用 Logstash 对数据进行解析加工，方便于 Kibana 图形化的展示。
二、ELK 在 Spark 集群中高可用性构架
为了便于分析，我们将 Spark 集群分为管理节点（Master Node）和计算节点（Slave Node）。管理节点（Master Node）可能有多个节点，分别安装 Beat,Logstash, Elasticsearch 和 Kibana。计算节点上，只需要安装 Beats 来收集日志即可。下图是 ELK 在 Spark 集群中 HA 构架。
图 2 ELK 在 Spark 集群中 HA 构架
在大数据处理部署过程中，HA 是很重要的一个环节。就 Elasticsearch 而言，其本身就具备 HA 能力。大体上讲，HA 可以分为两个，一种是主备模式（Active-standby）模式，另外一种是负载均衡（Load Balance）模式。二者的区别在在于，Active-standby 模式是主节点（主要干活的）垮了，备用节点才启用，继续接着主节点的进程去干活；Load Balance 模式是，大家一起上，谁空闲了或者谁的资源多了，就把活分给谁干。如果把这二者结合起来，达到双璧合一的效果。作为 ELK 的集群监控系统，最好的方式是采用二者的结合。其中 Elasticsearch 最好是采用 Load Balance 模式，在 Master node 上进行负载均衡。Logstash 当然也可以采用负载均衡的方式，但是由于前文中讲过，Logstash 运行起来后，占用资源（CPU 利用率和内存）比较厉害，所以，笔者建议，如果 Master 节点比较繁忙的话，不建议在所有 Master 上启动 Logstash,当然在资源允许的情况下,启动 Logstash 也可以使得整个 ELK 系统的处理速度变快。Kibana 当然无须全部启动了，采用 Active-standby 模式，只需在一个管理节点上启动即可。Beats 在所有节点上都启动，因为要收集所有节点上的日志，但是需要注意的是，在 Spark 集群中，一般采用分布式文件系统的方式来存储日志和数据的，故而要注意避免日志重复性的问题。
三、ELK 监控 Spark 集群的性能
1、CPU 利用率的监控
CPU 是系统中的首要资源，CPU 利用率的监控的至关重要。CPU 利用率一般分为两种，用户态 CPU 利用率（User CPU Usage）和系统态 CPU 利用率(System CPU Usage)。其中用户态 CPU 利用率是指执行应用程序代码的时间占总 CPU 时间的百分比，系统态 CPU 利用率是指应用执行操作系统调用的时间占总 CPU 时间的百分比。
利用 ELK 监控 Spark 集群中的 CPU 利用率的大致流程为：用 TopBeat 来收集各个节点的内存资源，然后存储到 Elasticsearch 当中，由 Kibana 展示出来。下图为例，展示了 Spark 集群中的 CPU 监控，同时也监控了系统负载情况（Jin Chi He2016-11-04T09:36:00.18JCH System Load）。如果 Spark 集群中的节点可能较多，可以使用 Kibana 的功能，来展示出 CPU 利用率最高的几个节点，以便了解哪些节点的负载较重。
图 3 ELK 对 Spark 集群 CPU 的监控
2、内存利用率的监控
我们知道，Spark 是一种内存利用率非常高的技术，换句话说，Spark 集群对内存的要求较高。Spark 集群的管理者需要实时的掌握内存的使用情况。收集方式和 CPU 利用率的方式类似，用 Topbeat 或者 Metricbeat 来收集。一般来统计总的内存，已经使用和内存和平均的内存利用率。如下图所示。
图 4 ELK 对 Spark 集群内存的监控
3、网络的监控
网络吞吐量也会影响 Spark 集群的性能，网络方面的参数主要有 Packetbeat 来收集，可以统计 Spark 集群中节点网卡的发送和收到的吞吐量，如下图所示。
图 5 ELK 对 Spark 集群网络的监控
4、磁盘的监控
磁盘的监控只要分为两个方面，一是的磁盘的使用率，以便监控而防止因磁盘不够而影响应用的运行。二是磁盘的 IO 吞吐量，吞吐量是指每秒传输的 MB 字节数来衡量，常用于衡量 OLAP 型数据块的 IO 性能。如下图所示。
图 6 ELK 对 Spark 集群磁盘的监控
以上，我们展示了对 Spark 集群性能的监控几个关键的指标，用户还可能利用 Kibana 的灵活性来定义感兴趣的 Dashboard。如果现有在 Beat 不能满足需求，可以更具 libbeat 来开发自己的 Beat,或者写一些简单的脚本来收集，写入文件，然后由 FileBeat 读取，发送给 Logstash 进行格式的处理，或者由 Logstah 直接读取。
四、ELK 监控 Spark 集群的作业
1、对节点的监控
在实际应用中，Spark 集群可能包括上百台，甚至更多的节点，作为管理员，首先需要只要的是节点的分配情况和节点的状态。如下图所示，此数据一般来自于资源调度平台，Spark 资源调度大体上可以分为两大类，一类的自带的资源调度模块，另外一类是外部的资源调度框架，比如 Mesos、YARN 和 IBM Platform EGO 等。构建 Spark Application 的运行环境，创建 SparkContext 后， SparkContext 向资源管理器注册并申请资源。如下图中列举出了 Spark 集群中，总的节点数和未分配的节点数，已经失败的节点数。此数据是 PERF Loader 从 IBM Platform EGO 模块中加载到 Elasticsearch 数据库中，然后在 Kibana 检索展示。
图 7 ELK 对 Spark 集群节点的监控
2、对 Task 运行情况的监控
在 Spark 集群中，资源管理器根据预先设定的算法，在资源池里面分配合适的 Executor 运行资源，在运行过程中，Executor 运行情况将随着心跳发送到资源管理器上。SparkContext 构建 DAG 图，作业调度模块 DAGScheduler 将 DAG 图分解成 Stage。Executor 向 SparkContext 申请 Task，TaskScheduler 维护着所有 TaskSet，当 Driver 收到 Executor 的心跳的时候，Task Scheduler 会根据其资源剩余情况分配相应的 Task 到 Executor 运行，同时 SparkContext 将应用程序代码发放给 worker。随后 Task 便开始 worker 上开始运行。在此期间，TaskScheduler 还维护着所有 Task 的运行状态，重试失败的 Task。当 Task 运行结束，反馈给 SparkContext，并释放资源。
在 Application 提交之后，监控 Task 运行状态，可以得知 Application 的完成情况，下图中，展示了正在运行的 Task 数量和已经完成的 Task 数量，以及各个节点完成 Task 的数量。此数据获取的方式比较灵活，可以通过 RESTful API 直接获取，或者配置 Spark 集群中的 log4j，将这些信息打印到日志中，由 Logstash 来收集。
图 8 ELK 对 Task 的监控
3、对资源分配情况的监控
在 EGO Cluster 模式下，通过 sbin/spark-submit 来提交 Application（一般为.jar 或者.py 文件），EGO 分配一个 Container 来启动 Driver。Driver 一旦启动后，将在 Cluster 中的 node 上启动 Executor 的进程，并在此 Executor 上执行 task。各种模式下，资源调度器的调度单位是不同的，图 9 以 IBM Platform EGO 为例，展示资源的分配和使用情况。
图 9 ELK 对资源分配情况的监控
4、对错误和告警的监控
在对日志的收集过程中，根据 LOG LEVEL 的不同，可以将 ERROR 或者 WARN 的日志分离出来，直观的展示到 Dashboard 中，如图 10 所示。
图 10 ELK 对错误和告警的监控
如果想更进一步的了解错误日志或者告警信息，可以在 Kibana 的 Discover tab 下，输入相应的判断条件，即可检索出用户感兴趣的日志。
图 11 Kibana 对日志的检索
五、结束语
通常，日志被分散的储存在不同的设备上。如果管理大规模的集群，还使用依次登录每台机器的传统方法查阅日志，这样会使得效率极其低下，而且工作繁琐，集中化的日志管理就显得越来越重要，ELK 无疑是目前最火的日志收集、处理、存储、Web 展现为一身的技术，更有利者，ELK 是开源的。本章阐述了 ELK 的部署形式和使用案例。事实上，ELK 已经应用到了各种场合，包括 Hadoop 集群的监控，Spark 集群的监控等。在平时的使用中，如果因为某种缺陷而无法达到用户的需求，可以根据 ELK 官方的方法，来开发自己的插件。
本文所展示的构架和展示图为 IBM Platform 团队在使用 ELK 系统过程中的实战案例和总结，同时 IBM Platform 团队来 ELK 系统做了很多改善和提升，比如和 IBM Platform EGO 集成，扩展 Beats 的收集范围，监控 IBM Spectrum Storage 系统，ELK 的自动部署和管理等方面。并且，默认情况下 ELK 系统不支持 IBM JAVA，为此，IBM Platform 团队通过完善 ELK 系统，来完美的支持和 IBM JAVA 和 Power 系统，并将 ELK 产品应用到了 IBM Spectrum Conductor with Spark 和 IBM Spectrum Cluster Foundation 等产品中。
转自：IBM-中国
作者：何 金池, 李 峰, 王 占伟, 和 李 婷
2. 为什么ELK 在 Spark 集群中是高可用性构架？
3. ELK 可以监控 Spark 集群的哪些性能？
4. ELK 可以监控 Spark 集群的哪些作业？
解决方案：
概述
大数据处理技术越来越火,云计算平台也如火如荼,二者犹如 IT 列车的两个车轮,相辅相成,高速发展。如果我们将大数据处理平台比作一个可能会得病的人的话，那么日志分析系统就是给病人诊断的医生。由于集群甚大，几百台机器都是起步价，甚至可能会有上千台、上万台机器同时协作运行。如此大的集群，不可能一点问题都不出,就像一个人不可能不得病一样。如果出现问题，如何快速的找到问题的根源并对症下药，则显得至关重要。在这样的背景下，日志分析和监控系统也犹如雨后春笋，得到了空前的发展。
目前，日志分析工具多达数十种，其中应用较多的有 Splunk、ELK、AWStats、Graphite、LogAnalyzer、Rsyslog、Log watch、Open Web Analytics 等等，其中，领头羊的当属 Splunk 和 ELK，其中 Splunk 属于商业运营产品，而 ELK 属于开源产品。本文着重讨论 ELK 方案，并详细阐述 ELK 如何应用到 Spark 集群中。事实上，ELK 官方已称之为 Elastic,考虑行业内对此系统已经熟识，故而继续延用 ELK 来代替。
ELK 的应用大致可以分为两大类，一类是系统和应用的监控,可以通过 Kibana 做出不同的 Dashboard 来实时的监控集群的状况，比如 CPU 利用率，内存的使用情况，集群的 Job/Task 完成情况等；另一大用处在于快速的故障排查,运行中的集群在时时刻刻的打印日志，我们可以通过 ELK 系统来收集、存储和检索日志，然后通过关键字或者日志类型等查询条件来快速的查看用户感兴趣的 Log,以便快速的找出问题的根源。
一、ELK 系统架构
那么什么是 ELK 呢？ELK 是 Elasticsearch, Logstash, Kibana 的简称，是最初的 ELK 的三大核心套件，随着该系统的发展，多出了另外一个组件，我们称之为 Shipper 端，专门用来收集终端（集群中的机器）上日志和数据。其实 Logstash 本身就有收集功能，那么为什么还需要发展处另外一个 Shipper 端呢？主要是因为 Logstash 并非轻量级的工具，在运行过程中，占用了较多的资源（比如 CPU 和内存等），对于集群的整体性能来说无疑是一种损耗。所以，一般在终端上只运行轻量级的 Shipper 来收集日志。起初的 shipper 为 Logstash-forwarder,后来发展到了 Beats。下面对这四种工具逐一做简单介绍。
Logstash 是一个用来搜集，分析，过滤日志的工具。它支持几乎任何类型的日志，包括系统日志、错误日志和自定义应用程序日志。它可以从许多来源接收日志，这些来源包括 syslog、消息传递（例如 rabbitmq）和 jmx，它能够以多种方式输出数据，包括电子邮件、websockets 和 Elasticsearch。
Elasticsearch 是实时全文搜索和分析引擎，提供搜集，分析，存储数据三大功能；是一套开放 REST 和 JAVA API 等结构提供高效搜索功能，可扩展的分布式系统。它构建于 Apache Lucene 搜索引擎库之上。
Kibana 是一个基于 Web 的图形界面，用于搜索、分析和可视化存储在 Elasticsearch 指标中的日志数据。它利用 Elasticsearch 的 REST 接口来检索数据，不仅允许用户创建他们自己的数据的定制仪表板视图，还允许他们以特殊的方式查询和过滤数据。
Beats 负责在终端收集日志和数据，目前 Beats 有好几种，包括：Filebeat, Packetbeat, Metricbeat, Winlogbeat, Topbeat 等，用户还可以借助 Libbeat 来开发自己的 Beat。Filebeat 功能相当于 Logstash-forwarder，用在收集文件日志。 Packetbeat 用来收据网络方面的数据。Topbeat 已经合并到 Metricbeat 里面，用来收集系统或者某个指定的服务所占用的 Metrics, Winlogbeat 用来收集 Windows 系统上的日志信息。目前，已经有数十种 Community Beats，可供下载使用。
在不同的应用场景，ELK 系统的构架略有不同，比如说有的场景运用到了 Redis 或者 Kafka 来做消息队列，以减轻 Logstash 的压力，以防数据丢失。此文只讨论最为经典的构架。如图 1 所示。
图 1 ELK 的架构
其大致工作流程为：Beats 从终端机器收集到各种数据之后，发送给 Logstash 进行解析和格式化处理之后，再插入到 Elasticsearch 中存储，然后通过 Kibana 展示给用户。从上图中，我们可以看出，Beats 也可以直接将数据发送给 Elasticsearch，省略掉 Logstash 环节（假如所收集的数据不需要进一步的解析处理的话）。当然，在一般情况下，都需要用 Logstash 对数据进行解析加工，方便于 Kibana 图形化的展示。
二、ELK 在 Spark 集群中高可用性构架
为了便于分析，我们将 Spark 集群分为管理节点（Master Node）和计算节点（Slave Node）。管理节点（Master Node）可能有多个节点，分别安装 Beat,Logstash, Elasticsearch 和 Kibana。计算节点上，只需要安装 Beats 来收集日志即可。下图是 ELK 在 Spark 集群中 HA 构架。
图 2 ELK 在 Spark 集群中 HA 构架
在大数据处理部署过程中，HA 是很重要的一个环节。就 Elasticsearch 而言，其本身就具备 HA 能力。大体上讲，HA 可以分为两个，一种是主备模式（Active-standby）模式，另外一种是负载均衡（Load Balance）模式。二者的区别在在于，Active-standby 模式是主节点（主要干活的）垮了，备用节点才启用，继续接着主节点的进程去干活；Load Balance 模式是，大家一起上，谁空闲了或者谁的资源多了，就把活分给谁干。如果把这二者结合起来，达到双璧合一的效果。作为 ELK 的集群监控系统，最好的方式是采用二者的结合。其中 Elasticsearch 最好是采用 Load Balance 模式，在 Master node 上进行负载均衡。Logstash 当然也可以采用负载均衡的方式，但是由于前文中讲过，Logstash 运行起来后，占用资源（CPU 利用率和内存）比较厉害，所以，笔者建议，如果 Master 节点比较繁忙的话，不建议在所有 Master 上启动 Logstash,当然在资源允许的情况下,启动 Logstash 也可以使得整个 ELK 系统的处理速度变快。Kibana 当然无须全部启动了，采用 Active-standby 模式，只需在一个管理节点上启动即可。Beats 在所有节点上都启动，因为要收集所有节点上的日志，但是需要注意的是，在 Spark 集群中，一般采用分布式文件系统的方式来存储日志和数据的，故而要注意避免日志重复性的问题。
三、ELK 监控 Spark 集群的性能
1、CPU 利用率的监控
CPU 是系统中的首要资源，CPU 利用率的监控的至关重要。CPU 利用率一般分为两种，用户态 CPU 利用率（User CPU Usage）和系统态 CPU 利用率(System CPU Usage)。其中用户态 CPU 利用率是指执行应用程序代码的时间占总 CPU 时间的百分比，系统态 CPU 利用率是指应用执行操作系统调用的时间占总 CPU 时间的百分比。
利用 ELK 监控 Spark 集群中的 CPU 利用率的大致流程为：用 TopBeat 来收集各个节点的内存资源，然后存储到 Elasticsearch 当中，由 Kibana 展示出来。下图为例，展示了 Spark 集群中的 CPU 监控，同时也监控了系统负载情况（Jin Chi He2016-11-04T09:36:00.18JCH System Load）。如果 Spark 集群中的节点可能较多，可以使用 Kibana 的功能，来展示出 CPU 利用率最高的几个节点，以便了解哪些节点的负载较重。
图 3 ELK 对 Spark 集群 CPU 的监控
2、内存利用率的监控
我们知道，Spark 是一种内存利用率非常高的技术，换句话说，Spark 集群对内存的要求较高。Spark 集群的管理者需要实时的掌握内存的使用情况。收集方式和 CPU 利用率的方式类似，用 Topbeat 或者 Metricbeat 来收集。一般来统计总的内存，已经使用和内存和平均的内存利用率。如下图所示。
图 4 ELK 对 Spark 集群内存的监控
3、网络的监控
网络吞吐量也会影响 Spark 集群的性能，网络方面的参数主要有 Packetbeat 来收集，可以统计 Spark 集群中节点网卡的发送和收到的吞吐量，如下图所示。
图 5 ELK 对 Spark 集群网络的监控
4、磁盘的监控
磁盘的监控只要分为两个方面，一是的磁盘的使用率，以便监控而防止因磁盘不够而影响应用的运行。二是磁盘的 IO 吞吐量，吞吐量是指每秒传输的 MB 字节数来衡量，常用于衡量 OLAP 型数据块的 IO 性能。如下图所示。
图 6 ELK 对 Spark 集群磁盘的监控
以上，我们展示了对 Spark 集群性能的监控几个关键的指标，用户还可能利用 Kibana 的灵活性来定义感兴趣的 Dashboard。如果现有在 Beat 不能满足需求，可以更具 libbeat 来开发自己的 Beat,或者写一些简单的脚本来收集，写入文件，然后由 FileBeat 读取，发送给 Logstash 进行格式的处理，或者由 Logstah 直接读取。
四、ELK 监控 Spark 集群的作业
1、对节点的监控
在实际应用中，Spark 集群可能包括上百台，甚至更多的节点，作为管理员，首先需要只要的是节点的分配情况和节点的状态。如下图所示，此数据一般来自于资源调度平台，Spark 资源调度大体上可以分为两大类，一类的自带的资源调度模块，另外一类是外部的资源调度框架，比如 Mesos、YARN 和 IBM Platform EGO 等。构建 Spark Application 的运行环境，创建 SparkContext 后， SparkContext 向资源管理器注册并申请资源。如下图中列举出了 Spark 集群中，总的节点数和未分配的节点数，已经失败的节点数。此数据是 PERF Loader 从 IBM Platform EGO 模块中加载到 Elasticsearch 数据库中，然后在 Kibana 检索展示。
图 7 ELK 对 Spark 集群节点的监控
2、对 Task 运行情况的监控
在 Spark 集群中，资源管理器根据预先设定的算法，在资源池里面分配合适的 Executor 运行资源，在运行过程中，Executor 运行情况将随着心跳发送到资源管理器上。SparkContext 构建 DAG 图，作业调度模块 DAGScheduler 将 DAG 图分解成 Stage。Executor 向 SparkContext 申请 Task，TaskScheduler 维护着所有 TaskSet，当 Driver 收到 Executor 的心跳的时候，Task Scheduler 会根据其资源剩余情况分配相应的 Task 到 Executor 运行，同时 SparkContext 将应用程序代码发放给 worker。随后 Task 便开始 worker 上开始运行。在此期间，TaskScheduler 还维护着所有 Task 的运行状态，重试失败的 Task。当 Task 运行结束，反馈给 SparkContext，并释放资源。
在 Application 提交之后，监控 Task 运行状态，可以得知 Application 的完成情况，下图中，展示了正在运行的 Task 数量和已经完成的 Task 数量，以及各个节点完成 Task 的数量。此数据获取的方式比较灵活，可以通过 RESTful API 直接获取，或者配置 Spark 集群中的 log4j，将这些信息打印到日志中，由 Logstash 来收集。
图 8 ELK 对 Task 的监控
3、对资源分配情况的监控
在 EGO Cluster 模式下，通过 sbin/spark-submit 来提交 Application（一般为.jar 或者.py 文件），EGO 分配一个 Container 来启动 Driver。Driver 一旦启动后，将在 Cluster 中的 node 上启动 Executor 的进程，并在此 Executor 上执行 task。各种模式下，资源调度器的调度单位是不同的，图 9 以 IBM Platform EGO 为例，展示资源的分配和使用情况。
图 9 ELK 对资源分配情况的监控
4、对错误和告警的监控
在对日志的收集过程中，根据 LOG LEVEL 的不同，可以将 ERROR 或者 WARN 的日志分离出来，直观的展示到 Dashboard 中，如图 10 所示。
图 10 ELK 对错误和告警的监控
如果想更进一步的了解错误日志或者告警信息，可以在 Kibana 的 Discover tab 下，输入相应的判断条件，即可检索出用户感兴趣的日志。
图 11 Kibana 对日志的检索
五、结束语
通常，日志被分散的储存在不同的设备上。如果管理大规模的集群，还使用依次登录每台机器的传统方法查阅日志，这样会使得效率极其低下，而且工作繁琐，集中化的日志管理就显得越来越重要，ELK 无疑是目前最火的日志收集、处理、存储、Web 展现为一身的技术，更有利者，ELK 是开源的。本章阐述了 ELK 的部署形式和使用案例。事实上，ELK 已经应用到了各种场合，包括 Hadoop 集群的监控，Spark 集群的监控等。在平时的使用中，如果因为某种缺陷而无法达到用户的需求，可以根据 ELK 官方的方法，来开发自己的插件。
本文所展示的构架和展示图为 IBM Platform 团队在使用 ELK 系统过程中的实战案例和总结，同时 IBM Platform 团队来 ELK 系统做了很多改善和提升，比如和 IBM Platform EGO 集成，扩展 Beats 的收集范围，监控 IBM Spectrum Storage 系统，ELK 的自动部署和管理等方面。并且，默认情况下 ELK 系统不支持 IBM JAVA，为此，IBM Platform 团队通过完善 ELK 系统，来完美的支持和 IBM JAVA 和 Power 系统，并将 ELK 产品应用到了 IBM Spectrum Conductor with Spark 和 IBM Spectrum Cluster Foundation 等产品中。
转自：IBM-中国
作者：何 金池, 李 峰, 王 占伟, 和 李 婷