开发者学堂课程【企业运维训练营之大数据 EMR 原理与实践：视频-《 EMR 集群运维与排障》】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1242/detail/18464
EMR 集群运维与排障
三、EMR 开源组件管理平台
YARN 是一个资源的调度工具，它管理整个集群的计算资源，那这里也是由resource和nodemanager来进行master和Server方式来进行管理的。那 YARN WebUI 上应该关注哪些东西？来看一下。从这里可以进入到 YARN UI 的操作，那对于 Spark 任务或者是 Hue 任务或者是自己写的 HBASE个任务，平均到集群之后都是依赖 YARN 来进行资源的统一调度的。
在这里可以看到有哪些需要关注的信息，第一个就是当前APP的一个提交量，第二个就是资源，就是对 YARN 来说管理资源是它最主要的一个任务。这里可以看到 Memory Total就是管理的所有 NameNode 的节点，可管理内存的总和，那相应的 Vcores 、 CPU 也是 NameNode 所管理节点的总和。具体要提交的任务，比如这个 Spark的一个任务，这个是 SQL 的，我们看一个finish的任务。可以看一下 Spark SQL 的任务，这里就可以点进去看到具体的任务信息。
首先第一点就是APP ID，这个其实是需要的。包括任务的异常或者是通过命令查看日志都是需要这个信息的。第二点要关注的是如果说有些用户会在提交的时候生成 appattempt 的时候出现异常，那这里这个任务需要在这里来确定。
通过这里看它是 YARN给它分配的是在 core-1-2这个节点上来运行到 appattempt 的。具体的日志是在哪里看，就就可以通过log，这个 log 是可以进去的。这里是运行任务的所有的 log ，包括加载的环境信息、运行、输出等等都在这里可以看到。这里属于需要关注的点，第一个就是 logs 如果任务一旦影响，需要进行排查。第二个如果可以通过这里 Spark 的任务来看具体的 Spark 任务情况。Spark 这个 UI 后面会来进行介绍。
回过头来，除了任务之外还是可以看到 YARN 其他的情况。一个是 Node Manager 的节点的情况，还有就是一个队列的情况，这里我没有创建队列，例如默认的一个 Before 队列：队列是在哪里可以建的？为什么需要队列呢？因为在很多公司的运营过程中，一个集群是对应的多个部门来用的，那每个部门就可以通过队列的方式来区分，比如说我的财务部来提交到对应的一个队列，或者是其他部门提交到其他的部门一个队列，以区分资源的使用，同时队列也提供了多种的调度方式的，这个是需要关注的点。
那回过头来，在 YARN 的运营过程当中可能会遇到什么问题，那比如说有一个用户的真实的案例，用户的实际资源管理，它是有 core节点和 task 节点的，但是他在使用过程中会发现，每天在凌晨的时候 core节点的CPU会突然突然增到百分之百的情况，但具体他 task 节点的CPU并没有很多的消耗，最多也是用百分之五十。那为什么会出现这种情况？我们就针对它的一个集群来进行分析。首先有一点要明确的是，所有的资源分配都是通过节点上的nodemanager部署，来获取到每个节点的可使用的 CPU 和内存的。这里就可以根据它的集群来看，从我这个集群也是可以看到的。
它在 YARN 的配置过程中是哪个参数来具体控制资源，可以从这里来看： yarn-nodemanager -resourcer-memory-mb资源其实是代表着我的 YARN 在具体的这个nodemanager 所在的 core 节点上所能获取到的最大一个管理的内存，这里大概是12G的。你可以看一下我的集群的整体内存是多少，我集群大概是16G 那我给他分配了12G。为什么不能顶格用？这是另外一个问题。因为我们的节点除了部署nodemanager、运行任务之外，还部署比如说Hue服务等其他的服务，所以一般对于nodemanager所管理的内存，我们建议是对应的ECS的内存乘以80%这样的样子给到nodemanager做计算来使用。用户侧这个问题，它是由 core 的集群组和对应的task的集群组在集群组里面选择。我们可以看一下。我这里面有 core 节点和 task 节点，因为我这边选择的 core 节点和 task 节点的所有服务器都是同一类型的，但是用户侧它的选择，task节点的内存是 core 节点的两倍，但是他在管理task节点对应的manager和CPU的时候，是复用了 core 节点的一个配置，这样的话会导致什么问题？打个比方来说，这个集群是32G的一个配置，但是我 task节点这个集群是32G，这个配置，但是我这里只给他分配了12G，就会有将近20G的内存，我 YARN 是无法用到的，同时CPU也是一样的，那将近一半的CPU我 YARN 是没办法用到的。 task 点主要是计算节点，用户在夜间任务数上来之后，那 YARN 是nodemanager根据这个配置分配到 ccore 节点和task的节点来进行运行的任务，就会导致nodemanager的节点最多运用一半的情况下来进行使用，分配到 core 点的一个任务，就会存在存在CPU用满的情况。所以归纳来看，这个其实是我们作为运维同学需要关注的一个问题：就是说实际 YARN 管理的资源， CPU是怎么计算的？是 task 节点的个数乘以recore，task 节点组和 core 节点组的集群规格有可能存在不一致的情况，这是一个需要我们注意的问题，来规避用户的情况，使得集群可以高质量的使用，避免一些资源的浪费。以上是 YARN UI 包括问题的介绍，下面介绍一下Spark UI。
Spark UI 在我们的日常用语中也是经常学到的，主要体现在这里。
我举的是 Spark 3版本的相当对于 Spark 2有些版本就是UI的不同。它主要是由 Jobs 来汇统一下，就是 Spark 收到的所有正在运行的任务以及compete，就是运行完成的任务。同时 Stages 具体到分所有的 Stages 来进行执行，然后 Strorage 这个是任务中任务执行中有没有使用 cache 的体现，以及任务的执行环境environment等等。这些可以通过 Spark UI来看一下。
可以从这里进入Spark 3的UI的接口，这里就是我之前测试的一些 Spark的任务
Timeline可以看到这个 Spark 个任务，它执行从开始提交到具体执行完的耗时。
这里你可以点进去看一下具体的 Spark 任务的 Details for Stage它是怎么规划的，然后分了几个 task 来进行执行这些信息。这里需要我们关注什么？如果说一旦出现某个 task 异常，那我们通过log的日志来进行判断和分析。Environment主要是体现的我们要检查一下，比如说我提到这个任务的参数有没有生效，可以通过 Environment来快速过一下我所有设置的参数信息。
这里可以看到整个的执行信息，包括 Summary 阶段的情况，我这个是读的数据，所以没有 suffer 。
四、EMR 监控与告警介绍
对于以上三大件Spark 和 HDFS 、 YARN UI 也进行了一些介绍，那组件的除了我们管控平台和一些开源平台，如果说一旦组件出现问题或者是服务器出现问题，我们通过哪些指标来进行快速的一个介入。这里就来介绍一下我们 EMR 提供的一些监控服务以及告警服务。
首先监控服务分两项，一个是具体的硬件的监控，像CPU、内存、磁盘、网络等等，是基于底层的服务器，也就是 ECS 服务状态的监控。那为什么会讲到这个监控？因为所有的任务数据都是依赖底层的，如果底层出现了异常，比如说CPU标高或者内存标高的情况，肯定会影响到我们上层的数据计算和运算的，所以这里重点介绍一下我们提供的一个基于节点的介绍。
在集群监控里面，HOST 是我对于所有节点的介绍，包括 master 节点、 core 节点以及 task 节点都是有介绍，这里面我们应该关注哪些东西？主要关注的指标刚才有讲第一个就是 CPU ，我这边 CPU 是否有利用的标高，上面的案例也是讲过的，就是说用户出现CPU标高的情况下，肯定会导致这个机器卡住的，也会影响任务的。所以如果出现 CPU 标高的情况下，我们需要去关注一下具体在这个节点上是哪些进程占用我们 CPU 的标高，这就需要我们对于底层的 ECS 有一些应用情况，比如 Tob或者是使用 Ps的方式来定位到具体占用 CPU 标高的进程来进行进一步分析，包括内存也是，还有磁盘。刚才也讲到，如果说在数据的均衡过程中磁盘的负载标高，包括任务载海量的结构，会导致任务的标高、磁盘的负载比较大，也会导致触发数据的失败，这些都是需要通过我们底层的硬件监控来进行排查的。除了节点的监控之外， EMR 也是提供了组件的一些监控，像刚才介绍的 YARN 、 HDFS 、 Spark 、Hive等等这些基本的常用一些组件，我们的平台也是提供了对应具体事件上的一个监控。这边我重点介绍一下，我们在经常的运维过程中哪些指标需要重点关注，可能遇到什么问题。从 YARN 开始， YARN 这里就是采集了所有的 YARN resource manager的情况，包括提交过来的 Application 任务的总量，运行的终端信息等这些信息都可以通过来看，这里我们重点关注一下就是 Appspending，就是任务提交后等待排队的状况这个指标，如果说这个指标标高，那有可能是一方面这个时间段的任务执行比较大，第二个就是我们的集群压力比较高，第三个就是 YARN 的资源调度存在不合理的情况，导致资源没有很好的用上。第二个要关注的就是 YARN 的组件resource manager 的情况，这里主要是要关注两点：一个是我们内存的使用量，因为resource manager 是管理的所有的埋点进行分配的，如果任务量过大，我们相应的要提高resource manager 的运行内存的，这是第一个；第二个就是 Gc 的情况，这个也是和内存有很大的关系的，因为我们内存如果设置过小，那 resource manager 里的 Gc 耗时会非常大，也会导致任务提交运行缓慢，所以导致任务失败的情况；第三个就是 YARN Node Manager 的监控，这里主要关注一下我们每个节点的内存使用情况，有可能任务非常巨大，会导致 Node Manager 的使用内存标高的一个情况。以上是 YARN 的介绍。HDFS 我们要关注哪些？指标主要主要体现在HDFS HOME 主要是要看一下 MissinBlocks 。就是数据块的情况。因为如果说是服务器的情况，有可能出现比如服务器的异常down掉或者异常下线，会导致出现 MissingBlocks ，就是数据块的一个情况。这个时候就要注意了，要谨慎的操作，就是如果说出现 MissingBlocks 的情况，我们就要去通过 HDFS 的一些命令去查一下这些 MissingBlocks 具体是什么，一般情况下 MissingBlocks 的数据块是没办法进行恢复的，所以这个指标也是违反监控的。第二个就是 UnderReplicatedBlocks ,这个就是 UnderReplicatedBlocks 的数据块，这个指标一般我们在什么情况下关注？就是我打算下一个节点，要看一下这个指标，如果说有些指标很多，那我就要等待不同的数据块等 HDFS 来自动完成恢复之后，因为常规情况下 HDFS 是三副本的操作、三副本的存储，如果说这个量比较巨大，还没恢复过来，我就要下节点，那会导致MissinBlocks l。所以这个指标在我们在日常运维下节点过程中是一定要关注的。
然后就是 HDFS Name Node的一个监控，这里主要也是关注一下一些内存和Gc的Gc指标情况。
Spark 这里指标我们提供的是 Spark Name Server，这个就是它历史的 Spark 任务的一个入口的组件服务。
然后 HIVE 这里重点介绍一下 HIVE 的指标，因为我们机群大多是用离散数据分析，用 HIVE 的场景是很多的，这里要关注的指标主要也是两个：一个是运行的内存，一个是Gc的情况。运行的内存这里出现过什么问题？有些用户在使用 HIVE 的时候，它是用客户端或者是 DW或者是 EMR Staydue或者Datatway 集群来提交的 HIVE 任务。提交的 HIVE 任务、连接 HIVE 都是通过 HIVE Server来进行的。这里之前出现的问题就是用户对于这个 HIVE Server的使用是所有的数据开发同学，数据开发同学对于一些 SQL 进行测试的时候是没有太多的顾忌，所以他会一次性的查询，比如说查几年的数据，会导致一个现象就是说把 HIVE Server的内存通报。之前用户有个反馈，它的 HIVE Server的运行类别 HIVE science一直提高，从2G提高到6G提供到10G，但是 HIVE Server一直出现大量的Gc limit 的情况，就是Gc程度很高，内存使用量很大，他那边分析也是没有分析出来什么问题。这种情况下我们就是通过 JVM 在用户的机器上进行抓包 HIVE Server的线程，通过JVM 来分析看，最终发现它有大量对于某一个表海量分区的查询，查询有几年的数据，会导致大量的数据在传输过程中占用 HIVE Server 的内存，最终是反馈给这个数据的开发同学，让他尽量的用 limit 的方式来进行小量多次获取，HIVE SQL 的数据来规避了HIVE Server和Gc的一个情况。这个是需要我们注意的一点，因为 HIVE Server日常使用我们一般都是使用 HIVE Server来连接hab使用的，包括很多客户端。以上是重点组件和机器节点的介绍。
之前我们介绍的一些组件的监控，那对于这些组件监控的异常信息，我们如何来进行监控，?
EMR 平台提供了一个对于异常监控，包括组件的异常监控以及数据任务的异常指标，还有就是底层的 ECS 服务器硬件这些指标的监控的推送，具体是怎么实现的？实现的逻辑是我们在集群的各个节点部署的实时的异常监测的服务，通过组件的接口来获取组件的状态，然后把这些状态推送到云监控。这里依赖着我们另一款云产品：云监控服务，是我们的基于云，云就是云上的所有的产品和服务的监控推送工具。推送到云监控之后，通过之前你需要订阅的组件的异常匹配之后，来进行触发到用户的告警。那告警形式也是有多样的，比如说钉钉、电话、短信等等这些方式，第一时间通知到集群的运维同学或者关注的同学来进行紧急的介入来进行止血。
我们来演示一下这个过程具体是怎么实现的。回到我们的控制台，这里的监控事件中是有很多的之前我测试的异常，比如 HIVE 任务的异常。我们可以通过这里来进入到实际的监控服务台，在事件报警规则过程中我们可以加一些配置。选定了具体的我们的 EMR 产品全部事件类型、意见等级一些严重的SQL 的信息，事件就会包含很多像集群创建成功失败的，以及具体的所有的组件指标提供一个异常。这里是需要我们用户重点关注的，因为依赖这个告点的配置，我们可以比如说实时的进入到我们组件的状态。比如说很多公司的大量的离散数据的运行都是在凌晨，肯定不可能就是有人时刻盯着，所以就可以使用这个云监控提供的组件这个异常告警，来订阅到我们的组件服务的状态。比如说我配置一个 YARN 的resource manager的增大，是对于集群是很重要的一个服务。可以用电话、短信、邮件、webhook 钉钉或者是微信都可以。这样配置之后，我们可以通过这个配置来直接订阅到我们组件的异常，可以实现自动化的、人性化的、应用化的运营的操作，那这里也是我们 EMR 提供的一个很好的告警方式，对于运维是相对于其他的自建的集群要集成或者是使用一些第三方的告警软件等等，是一个很硬化的功能。以上是整个 EMR 监控和告警的介绍。
