原因分析 HDFS未启动或故障。 查看Flume运行日志： 2019-02-26 11:16:33,564 | ERROR | [SinkRunner-PollingRunner-DefaultSinkProcessor] | opreation the hdfs file errors. | org.apache.flume.sink.hdfs.HDFSEventSink.process(HDFSEventSink.java:414) 2019-02-26 11:16:33,747 | WARN | [hdfs-CCCC-call-runner-4] | A failover has occurred since the start of call #32795 ClientNamenodeProtocolTranslatorPB.getFileInfo over 192-168-13-88/192.168.13.88:25000 | org.apache.hadoop.io.retry.RetryInvocationHandler$ProxyDescriptor.failover(RetryInvocationHandler.java:220) 2019-02-26 11:16:33,748 | ERROR | [hdfs-CCCC-call-runner-4] | execute hdfs error. {} | org.apache.flume.sink.hdfs.HDFSEventSink$3.call(HDFSEventSink.java:744) java.net.ConnectException: Call From 192-168-12-221/192.168.12.221 to 192-168-13-88:25000 failed on connection exception: java.net.ConnectException: Connection refused; For more details see: http://wiki.apache.org/hadoop/ConnectionRefused HDFS Sink未启动。 查看Flume运行日志，发现“ flume current metrics”中并没有Sink信息： 2019-02-26 11:46:05,501 | INFO | [pool-22-thread-1] | flume current metrics:{"CHANNEL.BBBB":{"ChannelCapacity":"10000","ChannelFillPercentage":"0.0","Type":"CHANNEL","ChannelStoreSize":"0","EventProcessTimedelta":"0","EventTakeSuccessCount":"0","ChannelSize":"0","EventTakeAttemptCount":"0","StartTime":"1551152734999","EventPutAttemptCount":"0","EventPutSuccessCount":"0","StopTime":"0"},"SOURCE.AAAA":{"AppendBatchAcceptedCount":"0","EventAcceptedCount":"0","AppendReceivedCount":"0","MonTime":"0","StartTime":"1551152735503","AppendBatchReceivedCount":"0","EventReceivedCount":"0","Type":"SOURCE","TotalFilesCount":"1001","SizeAcceptedCount":"0","UpdateTime":"605410241202740","AppendAcceptedCount":"0","OpenConnectionCount":"0","MovedFilesCount":"1001","StopTime":"0"}} | org.apache.flume.node.Application.getRestartComps(Application.java:467)

原因分析 在Driver端打印异常如下，打印连接两个ResourceManager主备节点的26004端口均被拒绝： 15/08/19 18:36:16 INFO RetryInvocationHandler: Exception while invoking getClusterMetrics of class ApplicationClientProtocolPBClientImpl over 33 after 1 fail over attempts. Trying to fail over after sleeping for 17448ms. java.net.ConnectException: Call From ip0 to ip1:26004 failed on connection exception: java.net.ConnectException: Connection refused. INFO RetryInvocationHandler: Exception while invoking getClusterMetrics of class ApplicationClientProtocolPBClientImpl over 32 after 2 fail over attempts. Trying to fail over after sleeping for 16233ms. java.net.ConnectException: Call From ip0 to ip2:26004 failed on connection exception: java.net.ConnectException: Connection refused; 在 MRS Manager页面查看ResourceManager此时是否功能正常，如果Yarn服务状态故障或某个Yarn服务的实例出现未知之类的异常说明此时集群的ResourceManager可能异常。 排查使用的客户端是否是集群最新的客户端。 排查集群是否做过实例ResourceManager迁移相关操作（先卸载某个ResourceManager实例，然后在其他节点添加）。 在MRS Manager页面查看审计日志，是否有相关操作的记录。 使用ping命令，查看IP是否可连通。

原因分析 备NameNode会周期性做合并editlog，生成fsimage文件的过程叫做checkpoint。备NameNode在新生成fsimage后，会将fsimage传递到主NameNode。 由于“备NameNode会周期性做合并editlog”，因此当备NameNode异常时，无法合并editlog，因此主NameNode在下次启动的时候，需要加载较多editlog，需要大量内存，并且耗时较长。 合并元数据的周期由以下参数确定，即如果NameNode运行30分钟或者HDFS操作100万次，均会执行checkpoint。 dfs.namenode.checkpoint.period：checkpoint周期，默认1800s。 dfs.namenode.checkpoint.txns：执行指定操作次数后执行checkpoint，默认1000000。

解决办法 在重启前，主动执行异常checkpoint合并主NameNode的元数据。 停止业务。 获取主NameNode的主机名。 在客户端执行如下命令： source /opt/client/bigdata_env kinit 组件用户 说明：“/opt/client”需要改为实际客户端的安装路径。 执行如下命令，让主NameNode进入安全模式，其中linux22换为主NameNode的主机名。 hdfs dfsadmin -fs linux22:25000 -safemode enter 执行如下命令，在主NameNode，合并editlog。 hdfs dfsadmin -fs linux22:25000 -saveNamespace 执行如下命令，让主NameNode离开安全模式。 hdfs dfsadmin -fs linux22:25000 -safemode leave 检查是否真的合并完成。 cd /srv/BigData/namenode/current 检查先产生的fsimage是否是当前时间的，若是则表示已经合并完成

原因分析 Driver端异常: 16/05/11 18:10:56 INFO Client: client token: N/A diagnostics: Application application_1462441251516_0024 failed 2 times due to AM Container for appattempt_1462441251516_0024_000002 exited with exitCode: 10 For more detailed output, check the application tracking page:https://hdnode5:26001/cluster/app/application_1462441251516_0024 Then click on links to logs of each attempt. Diagnostics: Exception from container-launch. Container id: container_1462441251516_0024_02_000001 在ApplicationMaster日志中，异常如下: 2016-05-12 10:21:23,715 | ERROR | [main] | Failed to connect to driver at 192.168.30.57:23867, retrying ... | org.apache.spark.Logging$class.logError(Logging.scala:75) 2016-05-12 10:21:24,817 | ERROR | [main] | Failed to connect to driver at 192.168.30.57:23867, retrying ... | org.apache.spark.Logging$class.logError(Logging.scala:75) 2016-05-12 10:21:24,918 | ERROR | [main] | Uncaught exception: | org.apache.spark.Logging$class.logError(Logging.scala:96) org.apache.spark.SparkException: Failed to connect to driver! at org.apache.spark.deploy.yarn.ApplicationMaster.waitForSparkDriver(ApplicationMaster.scala:426) at org.apache.spark.deploy.yarn.ApplicationMaster.runExecutorLauncher(ApplicationMaster.scala:292) … 2016-05-12 10:21:24,925 | INFO | [Thread-1] | Unregistering ApplicationMaster with FAILED (diag message: Uncaught exception: org.apache.spark.SparkException: Failed to connect to driver!) | org.apache.spark.Logging$class.logInfo(Logging.scala:59) Spark-client模式任务Driver运行在客户端节点上(通常是集群外的某个节点)，启动时先在集群中启动AppMaster进程，进程启动后要向Driver进程注册信息，注册成功后，任务才能继续。从AppMaster日志中可以看出，无法连接至Driver，所以任务失败。

解决办法 请检查Driver进程所在的IP是否可以ping通。 启动一个Spark PI任务，会有类似如下打印信息。 16/05/11 18:07:20 INFO Remoting: Remoting started; listening on addresses :[akka.tcp://sparkDriver@192.168.1.100:23662] 16/05/11 18:07:20 INFO Utils: Successfully started service 'sparkDriver' on port 23662. 在该节点，也就是2中示例的192.168.1.100上执行netstat - anp | grep 23662看下此端口是否打开，如下打印标明，相关端口是打开的。 tcp 0 0 ip:port :::* LISTEN 107274/java tcp 0 0 ip:port ip:port ESTABLISHED 107274/java 在AppMaster启动的节点执行telnet 192.168.1.100 23662看下是否可以连通该端口，请使用root用户和omm用户都执行一遍。 如果出现Escape character is '^]'类似打印则说明可以连通，如果出现connection refused则表示失败，无法连接到相关端口。 如果相关端口打开，但是从别的节点无法连通到该端口，则需要排查下相关网络配置。 23662这个端口每次都是随机的，所以要根据自己启动任务打开的端口来测试。

原因分析 原因：由于参数设置不当，数据量大时数据处理时间过长，导致频繁发生balance，此时offset无法正常提交，导致重复消费数据。 原理：每次poll的数据处理完后才提交offset，如果poll数据后的处理时长超出了session.timeout.ms的设置时长，此时发生rebalance导致本次消费失败，已经消费数据的offset无法正常提交，所以下次重新消费时还是在旧的offset消费数据，从而导致消费数据重复。

解决办法 建议用户在Manager页面调整以下服务参数： request.timeout.ms=100000 session.timeout.ms=90000 max.poll.records=50 heartbeat.interval.ms=3000 其中： request.timeout.ms要比session.timeout.ms大10s。 session.timeout.ms的大小设置要在服务端参数group.min.session.timeout.ms和group.max.session.timeout.ms之间。 以上参数可以根据实际情况进行适当的调整，特别是max.poll.records，这个参数是为了控制每次poll数据的records量，保证每次的处理时长尽量保持稳定。目的是为了保证poll数据以后的处理时间不要超过session.timeout.ms的时间。

问题背景与现象 当数据量较大时会频繁地发生rebalance导致出现重复消费的情况，关键日志如下： 2018-05-12 10:58:42,561 | INFO | [kafka-request-handler-3] | [GroupCoordinator 2]: Preparing to restabilize group DemoConsumer with old generation 118 | kafka.coordinator.GroupCoordinator (Logging.scala:68) 2018-05-12 10:58:43,245 | INFO | [kafka-request-handler-5] | [GroupCoordinator 2]: Stabilized group DemoConsumer generation 119 | kafka.coordinator.GroupCoordinator (Logging.scala:68) 2018-05-12 10:58:43,560 | INFO | [kafka-request-handler-7] | [GroupCoordinator 2]: Assignment received from leader for group DemoConsumer for generation 119 | kafka.coordinator.GroupCoordinator (Logging.scala:68) 2018-05-12 10:59:13,562 | INFO | [executor-Heartbeat] | [GroupCoordinator 2]: Preparing to restabilize group DemoConsumer with old generation 119 | kafka.coordinator.GroupCoordinator (Logging.scala:68) 2018-05-12 10:59:13,790 | INFO | [kafka-request-handler-3] | [GroupCoordinator 2]: Stabilized group DemoConsumer generation 120 | kafka.coordinator.GroupCoordinator (Logging.scala:68) 2018-05-12 10:59:13,791 | INFO | [kafka-request-handler-0] | [GroupCoordinator 2]: Assignment received from leader for group DemoConsumer for generation 120 | kafka.coordinator.GroupCoordinator (Logging.scala:68) 2018-05-12 10:59:43,802 | INFO | [kafka-request-handler-2] | Rolled new log segment for '__consumer_offsets-17' in 2 ms. | kafka.log.Log (Logging.scala:68) 2018-05-12 10:59:52,456 | INFO | [group-metadata-manager-0] | [Group Metadata Manager on Broker 2]: Removed 0 expired offsets in 0 milliseconds. | kafka.coordinator.GroupMetadataManager (Logging.scala:68) 2018-05-12 11:00:49,772 | INFO | [kafka-scheduler-6] | Deleting segment 0 from log __consumer_offsets-17. | kafka.log.Log (Logging.scala:68) 2018-05-12 11:00:49,773 | INFO | [kafka-scheduler-6] | Deleting index /srv/BigData/kafka/data4/kafka-logs/__consumer_offsets-17/00000000000000000000.index.deleted | kafka.log.OffsetIndex (Logging.scala:68) 2018-05-12 11:00:49,773 | INFO | [kafka-scheduler-2] | Deleting segment 2147948547 from log __consumer_offsets-17. | kafka.log.Log (Logging.scala:68) 2018-05-12 11:00:49,773 | INFO | [kafka-scheduler-4] | Deleting segment 4282404355 from log __consumer_offsets-17. | kafka.log.Log (Logging.scala:68) 2018-05-12 11:00:49,775 | INFO | [kafka-scheduler-2] | Deleting index /srv/BigData/kafka/data4/kafka-logs/__consumer_offsets-17/00000000002147948547.index.deleted | kafka.log.OffsetIndex (Logging.scala:68) 2018-05-12 11:00:49,775 | INFO | [kafka-scheduler-4] | Deleting index /srv/BigData/kafka/data4/kafka-logs/__consumer_offsets-17/00000000004282404355.index.deleted | kafka.log.OffsetIndex (Logging.scala:68) 2018-05-12 11:00:50,533 | INFO | [kafka-scheduler-6] | Deleting segment 4283544095 from log __consumer_offsets-17. | kafka.log.Log (Logging.scala:68) 2018-05-12 11:00:50,569 | INFO | [kafka-scheduler-6] | Deleting index /srv/BigData/kafka/data4/kafka-logs/__consumer_offsets-17/00000000004283544095.index.deleted | kafka.log.OffsetIndex (Logging.scala:68) 2018-05-12 11:02:21,178 | INFO | [kafka-request-handler-2] | [GroupCoordinator 2]: Preparing to restabilize group DemoConsumer with old generation 120 | kafka.coordinator.GroupCoordinator (Logging.scala:68) 2018-05-12 11:02:22,839 | INFO | [kafka-request-handler-4] | [GroupCoordinator 2]: Stabilized group DemoConsumer generation 121 | kafka.coordinator.GroupCoordinator (Logging.scala:68) 2018-05-12 11:02:23,169 | INFO | [kafka-request-handler-1] | [GroupCoordinator 2]: Assignment received from leader for group DemoConsumer for generation 121 | kafka.coordinator.GroupCoordinator (Logging.scala:68) 2018-05-12 11:02:49,913 | INFO | [kafka-request-handler-6] | Rolled new log segment for '__consumer_offsets-17' in 2 ms. | kafka.log.Log (Logging.scala:68) 其中Preparing to restabilize group DemoConsumer with old generation表示正在发生rebalance。

原因分析 使用以下命令统计节点进程的线程数并排序。 ps -efT | awk '{print $2}' |sort -n |uniq -c |sort -n 执行后结果如下： 查看启动线程数最多的进程，案例中进程2346为NameNode进程，启动了5.4万线程，且持续增长。 多次打印对应进程的jstack日志，根据jstack日志信息发现，NameNode存在大量线程处于WAITING，且长期不释放。 结合以上问题分析如下：NameNode存在内置机制，根据WARN日志信息自动开启DEBUG日志，在环境中由于选择副本失败，导致一直启动Debug日志，不停地修改log4j，修改组件的log4j后进程会自动加载该配置文件，此时就会有新的线程自动产生，长时间后就会触发该告警。 出现这种情况时，将内置机制关闭，禁止自动修改日志级别即可恢复。

原因分析 问题1：Spark提交任务默认不会加载kafka的相关包，所以需要在启动命令中增加--jars来指定对应kafka版本的jar包 问题2：连接Kafka无法使用Spark的认证信息，需要将相关的认证使用JVM的参数设置进去。 问题3：Spark默认使用当前客户端的认证信息提交任务，也可以使用代码login的方式。但是这两种认证方式都无法更新任务使用的Token，当提交的时候生成的Token信息过期以后就无法再使用，因此报错。解决办法是使用--keytab和--principal将keytab文件和对应用户带入任务中。

处理步骤 问题1：启动命令中增加--jars来指定对应kafka版本的jar包，一般是在Spark客户端目录/jars/streamingClient（0.8版本Kafka）和Spark客户端目录/jars/streamingClient010（0.10版本Kafka）。 问题2：参考指导文档编辑并运行程序。 问题3：使用--keytab和--principal将keytab文件和对应用户带入任务中。如果此处的keytab文件和之前Kafka的jaas.conf中配置的是同一个，则Spark会报一个文件多次上传的问题。解决办法是复制一份keytab文件，使得--files和--keytab上传不同的文件。

原因分析 PostgreSQL缓存：除了常见的执行计划缓存、数据缓存，PostgreSQL为了提高生成执行计划的效率，还提供了catalog，relation等缓存机制。长连接场景下这些缓存中的某些缓存是不会主动释放的，因此可能导致长连接占用大量的内存不释放。 PMS是MRS的监控进程，此进程会经常创建表分区或者新表，由于PostgreSQL会缓存当前会话访问过的对象的元数据，且PMS的数据库连接池连接会长时间存在，所以连接占用的内存会逐渐上升。

处理步骤 Hive在执行SQL语句前，可以通过set命令来设置Map/Reduce相关客户端参数。 以下为与Map/Reduce内存相关的参数： set mapreduce.map.memory.mb=4096;// 每个Map Task需要的内存量 set mapreduce.map.java.opts=-Xmx3276M; // 每个Map Task 的JVM最大使用内存 set mapreduce.reduce.memory.mb=4096; // 每个Reduce Task需要的内存量 set mapreduce.reduce.java.opts=-Xmx3276M; // 每个Reduce Task 的JVM最大使用内存 set mapred.child.java.opts=-Xms1024M -Xmx3584M;//此参数为全局参数，即对Map和Reduce统一设置 参数设置只对当前session有效。

通过Manager页面查看节点状态（MRS 2.x及之前版本） 登录MRS Manager。 单击“主机管理”，看所有主机状态。 主机操作状态和健康状态分别如下表所示。 表5 主机操作状态 状态 描述 正常 主机及主机上的服务角色正常运行。 已隔离 主机被用户隔离，主机上的服务角色停止运行。 表6 主机健康状态 状态 描述 良好 主机心跳检测正常。 故障 主机心跳超时未上报。 未知 执行添加操作时，主机的初始状态。 单击列表中指定的主机名称，查看单个主机状态及指标。 定制、导出监控图表。 在“图表”区域框中，单击“定制”自定义服务监控指标。 在“时间区间”选择查询时间，单击“查看”显示该时间段内的监控数据。 单击“导出”，导出当前查看的指标数据。