开发者学堂课程【企业运维训练营之大数据 EMR 原理与实践：视频-《 EMR 集群运维与排障》】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1242/detail/18464
EMR 集群运维与排障
五、EMR 诊断工具
在我们 EMR 产品的发展过程中，目前我们也是推出了 EMR 2.0，2.0一个重要的功能就是 EMR 全局的一个诊断工具， EMR Doctor 是提供了一站式的智能诊断和优化服务的，通过这个工具可以高效的运维我们的集群的健康状态，然后也提供了一个对于集群的计算资源，包括存储资源的分析，使我们的运维同学可以针对输出的一些异常的报告来进行调整我们的集群服务。
这里 EMR Doctor 主要包含两个部分，一个是实时诊断，这个就是你即点即承的诊断。我们可以来看一下。
回到我们的 EMR 集群，这里提供了一个实时诊断，集群集群日报的方式。之前我是诊断过，可以看一下它提供了一些哪些功能？实时诊断可以实时分析你的计算任务的引擎，这里可以看到有三个方面：一个是 Spark 任务的信息分析，为什么会需要这个分析？因为在此之前我们在任务、集群的分析过程运维过程中有一些比如说大的、超额、慢的任务，大量的占用了我们的资源，但是我们很难来进行实时的分析出来到底是哪个任务进行的占用。这里我们的 EMR doctor提供的实时的计算资源的分析，就可以从提交上来的任务来进行快速的获取到到底是哪个任务是不健康的状态，占用资源比较多，或者是资源比较少，耗时长的一个状态。我们通过这个页面就可以快速的获取到具体的任务是哪个任务，然后把这个任务反馈到数据开发的同学，让他进行SQL的一些调整等等，这个是实时健康状态的一个探测。所以说实时任务的探测对于我们数据开发的同学是一个很好的功能，因为这样的话可以协助数据开发的同学去调整 MapReduce 的任务，比如说 HIVE 的任务或者是基于Tez 的任务，或者基于 Spark 任务、SQL 的任务，或者是具体的 Spark 的任务来进行调优，最大化的调整资源的使用率。
除此之外也是提供了健康日报的方式。
这个就是每天我们的 EMR Doctor 在集群上去分析获取 HDFS 资源的资源分析， HIVE 存储资源的分析以及 HBASE 资源的分析的情况。具体到提供了哪些功能？应用到哪些方面？我们可以从我们的控制台来具体看一下。
这是集群的昨日的报告，那对于HDFS资源，它主要是分析什么？
这个过程主要是获取到 HDFS 存储资源所有的数据总量的分析。那这种情况下，比如我这个集群会用的就是小文件占比比较多，那小文件占比比较多，会会导致什么问题？我们大家都知道 HDFS 是默认的存储资源是一个Block，默认的是128兆，大量的小文件存储的话，就是虽然达不到128兆，几十K的文件这样进行存储，那导致文件的数量很多，在我们计算过程中去便利这些所有的表存储的小文件的时候、实际数据文件的时候会导致读取大量的文件，占用磁盘大量的 IO ，以及网络的占用等等，这些情况会导致我们的任务主要的耗时会放在磁盘的 IO和网络 IO 上，影响任务执行的耗时。所以对我们的运维同学来说，可以通过我们的 HDFS 存储资源的日报的情况，来快速的定位到我具体哪些资源是存储目录有大量的小文件等等这些异常信息来进行优化。
除了HDFS之外，还是有其他的 HIVE 的存储资源的，这个我们可以也可以看一下，
除了 HDFS 之外，还是计算资源的检查日报，这主要是对于所有的 My SQL以及具体的队列包括 YARN 的队列使用情况的诊断，这里这边因为集群比较健康，所以没诊断出来什么信息。但是对于我们的运维同学计算的计算资源的监控，我们可以看到具体到每个 YARN 的队列的资源的使用情况，是否是要调整资源的大小，来来满足 YARN 队列的需求，可以通过计算资源的分析来进行获取到。所以整体来看， EMR Doctor 实现的功能是什么？相对于没有 EMR Doctor 的之前，我们对于任务的分析都是case，相当于发现问题、去找问题、定位问题的一个过程。那有了 EMR Doctor 实时诊断或者是日报形式的诊断，我们就可以通过 EMR 输出的这个报告来直接定位到占有资源的任务，以及 YARN 队列资源的使用情况，以及小文件的情况来进行一个分析。所以是省了大量人力的，因为之前比如说我要返一个小文件的问题，它返过来是怎么的过程，比如数据开发同学反馈了我这个任务越来越慢，为什么？反馈任务越来越慢，分析慢那就要分析比如说数据有没有精写，有没有大量小文件。精写是一方面，大量小文件就会发现磁盘的 IO 读写比较高，这个文件在 HDFS 的存储的表格数据是大量的小文件来呈现的，那存储 IO 比较高，磁盘压力比较大，然后耗时也比较多，网络负载也是比较高，那会导致这个任务执行慢这个情况。有了这个 EMR Doctor 之后，我们不需要通过数据开发的同学反馈过来，作为运维的同学，我直接获取日报或者截取日志，发现这个读写 IO 比较短的同时，我发现对任务读取的表格对应的存储目录有大量的小邮件的存在，严重影响了集群的健康状态，我就可以拿出去让运维开发的同学把这些数据进行合并一下。这个就是对于我们运维同学在们运维过程中的一个很大的省劲的地方。 EMR 诊断是提供了一个整体的、宏观的集群健康状态的诊断，包括给出了一个评分。
六、组件异常排查
在我们实际使用过程中，如果说出现组件异常的排查，我们要执行哪个思路？
这也是我们开始讲的就是组件异常我们要怎么排查，或者对 EMR 来说有一个最好的实践来实现它。我们先看一下组件的执行情况，比如说组件的启动也可以通过控制台和API来进行操作，然后调用到我们管控后台的一个 Server，接收到之后下发到用户的客户集群来执行一个脚本，大体是这样一个操作。
我们可以看一下，从这里的截图可以看到这个具体的执行的一个组件执行启动 HDFS 的流程。从这里可以看一下，回到一个我们的控制台，可以看一下具体这个命令它到底执行了什么东西，因为平常我们 HADOOP 自己的集群是自己用命令起的，换到我们的控制台，它的流程是怎么样的，那我以 HDFS 为例，找一个 DataNode 的节点来停止启动一下，然后看一下它的脚本到底是怎么样的。触发一下停止，在这里操作日志中我们就可以判断你停止了 HDFS ，用两个 std，一个是err一个是out。翻过来看一下这个具体执行的逻辑：首先是加载一些环境变量，包括参数、一些对象，然后走到这之后主要关注的就是我们具体提出来是什么任务，把这个 HDFS 停掉了，可以看一下。这个 HDFS daemon在下发的指令，stop datanode具体停止的指令就是这个。为什么要关注这一点？因为在我们组件的维护过程中，很多情况下有可能会出现启动失败，或者是停止失败的一个情况，我们关注一下如果启动失败，这里会打印出来具体一些loading日志，如果loading不具体那怎么办？我们就可以把这个日志脚本复制过来，然后直接登录到我们的集群上，这个就是我的 NameNode 集群，把这个集群命令复制进去，实时看一下它的输出错误具体是什么，来方便来排查组件的异常。这个截图也是体现了可以将这个命令来进行我们实际体系上来进行执行，看主要的一个异常。除此之外，我们 EMR 也是提供了一些常用路径的展示，比如组件安装，我们所有组件是按照这个命令下的/opt/apps/，组件日志的目录是在这个命令下的/mnt/disk1/log/，配置文件目录是这个/ect/emr/，我们可以实施具体的看一下，这里我是进入到我们 HIVE 组件之间的日志目录，我退出一下，这里是 EMR 所有组件的日志目录。
比如说 HIVE 启动异常，我们就可以从这里进入 HIVE Server项目的日志，所以组件启动失败或者停止失败或者组件服务的状态，其实这种场景下我们最佳的实践途径是首先第一点，我们要在控制台上看一下这个组件的监控状态，比如说我尝试启动一下，如果启动还是失败，就可以通过日志来分析挖掘日志具体什么报错，通知管理的同时也可以在这里来进行查询的，这两个其实是同样的，只不过是一个在集群图上直接获取到看连贯，然后这里是通过SSL 方式通过关键字来进行查看。
我先演示我造一个报错，然后把它恢复了，演示一下这个快速排障的流程。我这里用 HIVE 来进行一个做报错的流程。 HIVE MetaStore 。 HIVE MetaStore 是管理源数据的，但是我这个集群是用的DRF的源数据，所以这里 MetaStore 其实没有用途的，它主要的用途是什么？就是提供给其他的Store按照指标的服务。 MetaStore 是有我们的集群初始上的配置，是数据库利用的集群上本地内置的 My SQL，上节课程管理员数据介绍过，那如果不用这个本地数据库，这里MySQL 的作用主要是什么？就是提供 HIVE ，就说还有还有 YARN 来使用存储这些相关的一些信息的。那我这里做个报错，默认的数据库接口是3306，我写的3300，然后保存一下。保存完成之后，我将这个 HIVE MetaStore 的服务来重新启动一下。看一下报错。 EMR 直接停止中，这个健康状态，因为是我们集群上监控组件的服务的、有时间监控的，所以显示的并不是那么及时，所有的组件状态已经停止，我尝试把它启动一下。那在这里操作历史中就可以看到我所有的组件包括配置的操作.
还没启动完。我们来看一下他的日志，我可以从这里直接拖一下日志来进行看一下。可以看到时间应该是刚刚启动的，20:17启动的，这时候就是 MetaStore 其中的一个异常。我看一下 Caused by 通过什么原因导致的？可以看到这个报错是数据库连接的报错，因为我刚才修改了它的端口，所以 HIVE MetaStore 启动的时候，连接这个本地 My SQL 的时候连接不上会导致报错。那这里是整个组件就是 HIVE Meta对于 HIVE MetaStore 来说其中异常排查的过程，对于其他的组件，其实大概也是这样的过程。组件我发现异常之后，比如说其中的异常要在对应的日志下看一下具体的报错是什么，进行进一步的分析。在这里报错就可以听到 jdbc 连接的时候连接失败，也可以看到我们管控台发现 HIVE MetaStore 的一个异常。我可以把它恢复过来，另外在我们的日志管理中，我去看 HIVE 的日志也是可以看到的，过一段时间可以给他演示一下。这个是看到 HIVE 的日志，我们可以过一下 Caused by 。这里可以看到跟我们的组件服务节点、组件服务的日志是一致的，
连接数据库的异常。在这个排查的过程，其实都代表了我们组件服务异常的时候它的流程，对于相对于自建 HADOOP 它也是有自己的日志的，包括你用命令起也可以实时的看到它的或者启动前台或者启动后台，都可以看到它的实时日志的。这里和这两个 HADOOP 其实就是流程上是大致类似的。但是对于我们使用 HADOOP 的一个应用程序，其实我们要在刚才的研究之前，要把这些工作就做一个分析，这样的话就是找到具体的错误日志或者错误点之后，才能根据这个错误来判断到底是什么原因导致的。另外我们 EMR 也是提供了各个产品的一些空间的一个A&Q 包括异常的诊断等等，可以上 EMR 的官网来实时的匹配一下到底是有没有调优或者调参的一些手段。以上就是组件排查的过程或者是最佳的实践。
这里我也是举了几个其他组件的一些异常排查，比如这个 zk的异常。
zk主要是使用选取的像我们在高可用集群的情况下，作为result managee，或者 Name Node 同步选取信息都会遇到，可以结合这个日志来看一下。就是 zk将它的本地磁盘的目录写满了，也会导致zk的启动失败，这个过程其实也是一样的，就是我们启动失败之后去对应的zk的目录去找一下，或者是ssh找一下具体影响或者可以启动的报错，然后根据这个报错来进行下一步的操作。
那这里 YARN 也是提供了一个排查方法，这里是resourcemanager的一个异常。
那我通过日志具体的拿到具体的resourcemanager的日志去看，就是发现这个端口被可能被其他的应用占用了，导致了这个resourcemanager其中的一个异常，这个端口可能是一个无关紧要进程，我就把它杀掉，然后把这个resourcemanager重新拉起来。
那以上就是组织要排查的一个异常，所以对于我们运维的同学来看，我们只需要哪些功能？首先第一点来说，第一点就是我要对于整个集群所有使用的组件有一个了解，第二点就是我可以对于这些关心的组件配置的告警。第三点如果说组件出现异常，我通过这个告警来快速的定位，定位到报错就是刚才的流程，可以通过组件的异常进入抓取具体组件服务的日志，比如说这个resourcemanager，或者通过ssl来做resourcemanager的报错是什么，或者一些开源的方式、方法快速的修复进行服务。组件运行的异常量，这是总结了一个最佳的排查方案。
