原因分析 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是否可连通。

解决办法 在重启前，主动执行异常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是否是当前时间的，若是则表示已经合并完成

原因分析 备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。

原因分析 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有效。

通过管理控制台查看节点状态 登录MRS管理控制台。 选择“现有集群”，选中一个运行中的集群并单击集群名称，进入集群信息页面。 在集群详情页，单击“节点管理”。 展开节点组名称，可查看节点基本信息、节点状态、CPU使用率、内存使用率、磁盘使用率等信息。 在主机列表单击指定的主机名称，可查看更详细的节点信息。 表1 MRS集群节点信息 参数 参数说明 节点组名称 集群节点组名称。 节点类型 节点组对应的节点类型，可参考MRS集群节点类型说明。 单击节点组名称前方的，显示该节点组包含的节点，单击节点名称，使用创建集群时配置的密码或者密钥对远程登录弹性云服务器。节点参数说明请参见查看MRS集群组件监控指标。 节点数 对应节点组中包含的节点数量。 付费类型 显示购买集群时的付费类型，包含“按需计费”和“包年/包月”。