这期内容当中小编将会给大家带来有关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 是 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 的架构
在大数据处理部署过程中，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 集群中，一般采用分布式文件系统的方式来存储日志和数据的，故而要注意避免日志重复性的问题。
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 的监控
网络吞吐量也会影响 Spark 集群的性能，网络方面的参数主要有 Packetbeat 来收集，可以统计 Spark 集群中节点网卡的发送和收到的吞吐量，如下图所示。
图 5 ELK 对 Spark 集群网络的监控
以上，我们展示了对 Spark 集群性能的监控几个关键的指标，用户还可能利用 Kibana 的灵活性来定义感兴趣的 Dashboard。如果现有在 Beat 不能满足需求，可以更具 libbeat 来开发自己的 Beat,或者写一些简单的脚本来收集，写入文件，然后由 FileBeat 读取，发送给 Logstash 进行格式的处理，或者由 Logstah 直接读取。
在实际应用中，Spark 集群可能包括上百台，甚至更多的节点，作为管理员，首先需要只要的是节点的分配情况和节点的状态。如下图所示，此数据一般来自于资源调度平台，Spark 资源调度大体上可以分为两大类，一类的自带的资源调度模块，另外一类是外部的资源调度框架，比如 Mesos、YARN 和 IBM Platform EGO 等。构建 Spark Application 的运行环境，创建 SparkContext 后， SparkContext 向资源管理器注册并申请资源。如下图中列举出了 Spark 集群中，总的节点数和未分配的节点数，已经失败的节点数。此数据是 PERF Loader 从 IBM Platform EGO 模块中加载到 Elasticsearch 数据库中，然后在 Kibana 检索展示。
图 7 ELK 对 Spark 集群节点的监控
在 EGO Cluster 模式下，通过 sbin/spark-submit 来提交 Application（一般为.jar 或者.py 文件），EGO 分配一个 Container 来启动 Driver。Driver 一旦启动后，将在 Cluster 中的 node 上启动 Executor 的进程，并在此 Executor 上执行 task。各种模式下，资源调度器的调度单位是不同的，图 9 以 IBM Platform EGO 为例，展示资源的分配和使用情况。
图 9 ELK 对资源分配情况的监控
如果想更进一步的了解错误日志或者告警信息，可以在 Kibana 的 Discover tab 下，输入相应的判断条件，即可检索出用户感兴趣的日志。
图 11 Kibana 对日志的检索<img src="https://cache.yisu.com/upload/information/20200706/149/73588.png" class="ibm-downsize" height="220" width="553" font-size:14px;white-space:normal;background-color:#FFFFFF;height:auto !important;" />
通常，日志被分散的储存在不同的设备上。如果管理大规模的集群，还使用依次登录每台机器的传统方法查阅日志，这样会使得效率极其低下，而且工作繁琐，集中化的日志管理就显得越来越重要，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 等产品中。
上述就是小编为大家分享的ELK 在 Spark集群的应用是怎样的了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注亿速云行业资讯频道。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
