集群有狀態(tài)重啟包括哪些內(nèi)容？

集群有狀態(tài)重啟包括RM Restart和NM Restart兩部分，ResourceManager（簡稱RM）負責維護應(yīng)用級基礎(chǔ)信息與狀態(tài)，NodeManager（簡稱NM）負責維護運行時的Container信息與狀態(tài)，它們持續(xù)將相關(guān)狀態(tài)同步至外部存儲（Zookeeper、LevelDB和HDFS等），并在重啟后重新加載狀態(tài)自行恢復(fù)，保證集群升級或重啟后應(yīng)用自動恢復(fù)，通常情況下可以做到應(yīng)用無感知。

如何啟用RM HA？

如何配置熱更新？

1. 開啟關(guān)鍵配置。

   您可以在EMR控制臺YARN服務(wù)的配置頁簽，檢查或者配置以下參數(shù)。

   參數(shù)	描述	參數(shù)值（推薦）
   yarn.scheduler.configuration.store.class	使用的后備存儲的類型。例如，設(shè)置為fs，表示使用FileSystem類型存儲。	fs
   yarn.scheduler.configuration.max.version	保留歷史版本的最大數(shù)量，超出自動清理。	100
   yarn.scheduler.configuration.fs.path	capacity-scheduler.xml文件存儲路徑。 不存在存儲路徑時，則自動創(chuàng)建。不指定前綴時，則默認defaultFs的相對路徑。	/yarn/<集群名>/scheduler/conf 重要 將<集群名>替換為集群名稱以便區(qū)分，可能有多個YARN集群對應(yīng)同一分布式存儲的情況。

2. 查看capacity-scheduler.xml配置。

   • 方式一（REST API）：http://<rm-address>/ws/v1/cluster/scheduler-conf。

   • 方式二（HDFS文件）：${yarn.scheduler.configuration.fs.path}/capacity-scheduler.xml.<timestamp>，其中后綴<timestamp>值最大的文件是最新的配置文件。

3. 更新配置。

   示例：更新一個配置項yarn.scheduler.capacity.maximum-am-resource-percent，并刪除配置項yarn.scheduler.capacity.xxx，刪除某配置項只需去掉其Value值。

   curl -X PUT -H "Content-type: application/json" 'http://<rm-address>/ws/v1/cluster/scheduler-conf' -d '
   {
     "global-updates": [
       {
         "entry": [{
           "key":"yarn.scheduler.capacity.maximum-am-resource-percent",
           "value":"0.2"
         },{
           "key":"yarn.scheduler.capacity.xxx"
         }]
       }
     ]
   }'

如何處理Queue內(nèi)應(yīng)用分配不均？

如何查看隊列資源使用情況？

要查看隊列資源使用情況，您可以在YARN WebUI頁面查看Used Capacity參數(shù)。Used Capacity參數(shù)表示該隊列已使用的資源占該隊列整體資源的百分比，分別計算Memory和vCores占總體的比例，并選取最大值作為隊列整體資源使用的比例。具體查看操作如下：

1. 訪問YARN UI，詳情請參見訪問鏈接與端口。

2. 在All Applications頁面，單擊目標作業(yè)的ID。

3. 單擊Queue行的隊列。

   在Application Queues區(qū)域，可以查看隊列資源使用情況。

   

YARN服務(wù)組件.out日志為何會大量堆積且無法自動清理？

• 問題原因：Hadoop組件部分依賴庫使用Java Logging APIs來生成日志記錄，不支持使用log4j配置的日志輪轉(zhuǎn)。目前這些daemon組件的stderr輸出被重定向到.out文件中，沒有自動清理機制，長時間積累可能導致數(shù)據(jù)盤存儲空間被占滿。

• 處理方法：可以使用head和tail命令結(jié)合日志中生成的時間戳信息，來判斷是否由于Java Logging APIs生成的日志導致存儲空間占用過大。通常情況下，這些依賴庫產(chǎn)生的都是INFO級別日志，不影響組件正常功能使用，但為了避免數(shù)據(jù)盤存儲空間被占用，可以采取修改配置的方式禁用此類日志的生成。

  例如，在優(yōu)化TimelineServer組件以關(guān)閉jersey依賴庫的日志生成時，操作步驟如下：

  1. 通過以下命令，監(jiān)控YARN日志路徑中與hadoop-timelineserver-相關(guān)的.out日志文件。DataLake集群的日志路徑為/var/log/emr/yarn/，Hadoop集群日志路徑為/mnt/disk1/log/hadoop-yarn。

     tail /var/log/emr/yarn/*-hadoop-timelineserver-*.out

     觀察到輸出日志中包含由com.sun.jersey組件產(chǎn)生的記錄。

     

  2. 為了禁止組件輸出Jersey庫的INFO級別日志到.out 文件，創(chuàng)建并配置一個文件來關(guān)閉其日志生成。在運行有TimelineServer組件的EMR節(jié)點上，可以通過執(zhí)行以下命令以root權(quán)限創(chuàng)建并編輯配置文件。

     sudo su root -c "echo 'com.sun.jersey.level = OFF' > $HADOOP_CONF_DIR/off-logging.properties"

  3. 在EMR控制臺中YARN服務(wù)的配置頁面，查找YARN_TIMELINESERVER_OPTS參數(shù)（Hadoop集群為yarn_timelineserver_opts），并在此參數(shù)值后添加-Djava.util.logging.config.file=off-logging.properties，指定剛剛創(chuàng)建的配置文件位置。

     

  4. 保存上述配置更改后，重啟TimelineServer組件使新設(shè)置生效。持續(xù)觀察一段時間，如果TimelineServer組件正常啟動，并且.out日志中不再出現(xiàn)任何與com.sun.jersey相關(guān)的日志信息，則說明關(guān)閉jersey依賴庫日志的操作已成功完成。

如何檢查ResourceManager服務(wù)是否正常？

如何了解應(yīng)用運行狀況？

應(yīng)用問題排查流程

1. 檢查App狀態(tài)，通過App詳情頁或App REST API檢查App狀態(tài)。

   • 未找到App狀態(tài)，可能原因：

     • 客戶端向YARN提交之前失敗退出：客戶端組件問題（檢查提交客戶端日志：BRS、flowagent等組件）。

     • 客戶端無法連接YARN RM：檢查連接RM地址是否正確、網(wǎng)絡(luò)是否存在問題。如有網(wǎng)絡(luò)問題，客戶端可能存在報錯：com.aliyun.emr.flow.agent.common.exceptions.EmrFlowException: ###[E40001,RESOURCE_MANAGER]: Failed to access to resource manager, cause: The stream is closed。

   • NEW_SAVING：該狀態(tài)處于Zookeeper State Store寫入應(yīng)用信息階段。持續(xù)該狀態(tài)可能原因如下：

     • Zookeeper存在問題，檢查Zookeeper服務(wù)是否正常。

     • Zookeeper讀寫數(shù)據(jù)問題，處理方法請參見RM處于Standby狀態(tài)，無法自動恢復(fù)Active狀態(tài)，該如何處理？。

   • SUBMITTED：該狀態(tài)極少遇到，可能原因為Node Update請求太多造成Capacity Scheduler內(nèi)部搶鎖堵塞，通常發(fā)生在大規(guī)模集群，需優(yōu)化相關(guān)流程。相關(guān)案例，請參見YARN-9618。

   • ACCEPTED：檢查Diagnostics。請根據(jù)提示信息，選擇相應(yīng)的處理方式。

     • 報錯提示Queue's AM resource limit exceeded。

       • 可能原因：Queue AM已使用資源和AM資源之和超出了Queue AM資源上限，UI條件為${Used Application Master Resources} + ${AM Resource Request} < ${Max Application Master Resources}。

       • 處理方法：上調(diào)該Queue的AM資源上限。例如，設(shè)置參數(shù)yarn.scheduler.capacity.<queue-path>.maximum-am-resource-percent為0.5。

     • 報錯提示User's AM resource limit exceeded。

       • 可能原因：Queue user AM已使用資源和AM資源之和超出了Queue user AM資源上限。

       • 處理方法：提高user-limit比例。您可以修改參數(shù)yarn.scheduler.capacity.<queue-path>.user-limit-factor和yarn.scheduler.capacity.<queue-path>.minimum-user-limit-percent的參數(shù)值。

     • 報錯提示AM container is launched, waiting for AM container to Register with RM。

       • 可能原因：AM已啟動，內(nèi)部初始化未完成（例如，Zookeeper連接超時等）。

       • 處理方法：需要根據(jù)AM日志進一步排查問題。

     • 報錯提示Application is Activated, waiting for resources to be assigned for AM。

       執(zhí)行步驟3，檢查AM資源分配為何未滿足。

   • RUNNING：執(zhí)行步驟2，檢查Container資源請求是否完成。

   • FAILED：檢查diagnostics。請根據(jù)提示信息，選擇相應(yīng)的處理方式。

     • 報錯提示Maximum system application limit reached,cannot accept submission of application

       • 可能原因：集群內(nèi)運行中的總應(yīng)用數(shù)超過上限（配置項：yarn.scheduler.capacity.maximum-applications，默認值：10000）。

       • 處理方法：檢查JMX Metrics，確認各隊列運行的應(yīng)用數(shù)是否符合預(yù)期，找出并處理有大量重復(fù)提交的問題應(yīng)用。如果應(yīng)用都正常，可以根據(jù)集群水位情況適當調(diào)大上述配置。

     • 報錯提示Application XXX submitted by user YYY to unknown queue: ZZZ

       • 可能原因：提交到不存在的queue。

       • 處理方法：提交到已存在的leaf queue。

     • 報錯提示Application XXX submitted by user YYY to non-leaf queue: ZZZ

       • 可能原因：提交到parent queue。

       • 處理方法：提交到已存在的leaf queue。

     • 報錯提示Queue XXX is STOPPED. Cannot accept submission of application: YYY

       • 可能原因：提交到STOPPED或DRAINING queue（已下線或正在下線的queue）。

       • 處理方法：提交到RUNNING queue（工作狀態(tài)正常的queue）。

     • 報錯提示Queue XXX already has YYY applications, cannot accept submission of application: ZZZ

       • 可能原因：queue應(yīng)用數(shù)達到上限。

       • 處理方法：

         1. 檢查queue內(nèi)是否有大量重復(fù)提交的問題應(yīng)用。

         2. 調(diào)整配置：yarn.scheduler.capacity.<queue-path>.maximum-applications。

     • 報錯提示Queue XXX already has YYY applications from user ZZZ cannot accept submission of application: AAA

       • 可能原因：user應(yīng)用數(shù)達到上限。

       • 處理方法：

         1. 檢查該user是否有大量重復(fù)提交的問題應(yīng)用。

         2. 調(diào)整配置：yarn.scheduler.capacity.<queue-path>.maximum-applications、yarn.scheduler.capacity.<queue-path>.minimum-user-limit-percent、yarn.scheduler.capacity.<queue-path>.user-limit-factor。

2. 確認YARN資源分配還未完成。

   1. 在apps列表頁，單擊appID進入AM頁面。

   2. 單擊下方列表的AM-ID，進入AM-Attempt頁面。

   3. 查看Total Outstanding Resource Requests列表中是否有Pending資源（也可以通過PendingRequests REST API查詢）：

      • 沒有Pending資源：說明YARN已分配完畢，退出該檢查流程，檢查AM情況。

      • 有Pending資源：說明YARN資源分配未完成，繼續(xù)下一步檢查。

3. 資源限制檢查。

   檢查集群或Queue資源，查看資源信息，例如，Effective Max Resource和Used Resources。

   1. 檢查集群資源或所在Queue資源或其父Queue資源是否已用完。

   2. 檢查葉子隊列某維度資源是否接近或達到上限。

   3. 當集群資源接近用滿時（例如85%以上），應(yīng)用的分配速度可能會變慢，因為大部分機器都沒有資源了，分配的機器沒有資源就會reserve，reserve到一定個數(shù)后分配就會變慢，另外也可能是由于內(nèi)存資源和CPU資源不成比例，例如，有的機器上內(nèi)存資源有空閑但CPU資源已經(jīng)用滿，有的機器上CPU資源有空閑但內(nèi)存已經(jīng)用滿。

4. 檢查是否存在Container資源分配成功但啟動失敗的情況，YARN UI的App Attempt頁面可以看到已分配的Container數(shù)（間隔一小段時間觀察是否變化），如果有Container啟動失敗，查看對應(yīng)的NM日志或Container日志進一步排查失敗原因。

5. 動態(tài)修改日志級別：在YARN UI的logLevel頁面（http://RM_IP:8088/logLevel），將org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity（CapacityScheduler調(diào)度邏輯所在的package）參數(shù)的日志級別改為DEBUG，如下圖所示。

   重要

   您需要在復(fù)現(xiàn)問題的同時打開，持續(xù)幾十秒（由于日志刷新的很快，無需持續(xù)太長時間），日志級別改回INFO即可恢復(fù)。

單任務(wù)/容器（Container）最大可用資源由哪些配置項決定？

YARN配置修改未生效，如何處理？

• 可能原因

  • 非熱更新配置，配置關(guān)聯(lián)的組件未重啟。

  • 熱更新配置，配置生效所需的指定操作未執(zhí)行。

• 解決方案：請確保相關(guān)配置修改的后續(xù)操作正確執(zhí)行。

  配置集	配置類型	更新后續(xù)操作
  capacity-scheduler.xml fair-scheduler.xml	調(diào)度器配置。	熱更新配置，需要執(zhí)行RM組件的refresh_queues操作。
  yarn-env.sh yarn-site.xml mapred-env.sh mapred-site.xml	YARN組件運行配置。	重啟配置關(guān)聯(lián)組件。例如： 修改配置yarn-env.sh中的YARN_RESOURCEMANAGER_HEAPSIZE、yarn-site.xml中的yarn.resourcemanager.nodes.exclude-path等配置項后，需重啟RM。 修改配置yarn-env.sh中的YARN_NODEMANAGER_HEAPSIZE、yarn-site.xml中的yarn.nodemanager.log-dirs等配置項后，需重啟NM。 修改配置mapred-env.sh中的MAPRED_HISTORYSERVER_OPTS、mapred-site.xml中的mapreduce.jobhistory.http.policys等配置項后，需重啟MRHistoryServer。

客戶端異常，提示Exception while invoking getClusterNodes of class ApplicationClientProtocolPBClientImpl over rm2 after 1 fail over attempts. Trying to fail over immediately

• 問題現(xiàn)象：無法正常訪問Active ResourceManager。ResourceManager日志異常，提示信息：WARN org.apache.hadoop.ipc.Server: Incorrect header or version mismatch from 10.33.**.**:53144 got version 6 expected version 9。

• 問題原因：Hadoop版本太舊，導致客戶端RPC版本不兼容。

• 處理方法：使用匹配的Hadoop版本。

RM處于Standby狀態(tài)，無法自動恢復(fù)Active狀態(tài)，該如何處理？

RM組件OOM如何處理？

為什么節(jié)點啟動任務(wù)時Localize失敗或任務(wù)日志無法采集與刪除？

• 問題現(xiàn)象：NM日志異常，提示java.io.IOException: Couldn't create proxy provider class org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider。

• 可能原因：HDFS配置異常。

• 處理方法：

  1. 以上是封裝后的異常，非根因，需要打開DEBUG級別日志查看：

     • hadoop客戶端命令行環(huán)境（例如執(zhí)行hadoop fs -ls /命令），開啟DEBUG調(diào)試信息。

       export HADOOP_LOGLEVEL=DEBUG

     • 有Log4j配置的運行環(huán)境，Log4j末尾增加log4j.logger.org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider=DEBUG。

  2. 以下示例的根因是用戶曾修改過NameServices配置，將emr-cluster修改為了hadoop-emr-cluster，但是擴容節(jié)點時使用了修改前的配置。

  3. 在EMR控制臺HDFS服務(wù)的配置頁面，檢查各項配置是否正確。

資源本地化異常，該如何處理？

• 問題現(xiàn)象：

  • Job AM Container啟動失敗，異常信息如下。

    Failed job diagnostics信息為：Application application_1412960082388_788293 failed 2 times due to AM Container for appattempt_1412960082388_788293_000002 exited with exitCode: -1000 due to: EPERM: Operation not permitted

  • 在資源本地化過程中（下載后解壓時）報錯，NodeManager日志信息如下。

    INFO org.apache.hadoop.yarn.server.nodemanager.containermanager.localizer.ResourceLocalizationService: Failed to download rsrc { { hdfs://hadoopnnvip.cm6:9000/user/heyuan.lhy/apv/small_apv_20141128.tar.gz, 1417144849604, ARCHIVE, null },pending,[(container_1412960082388_788293_01_000001)],14170282104675332,DOWNLOADING}
    EPERM: Operation not permitted
            at org.apache.hadoop.io.nativeio.NativeIO$POSIX.chmodImpl(Native Method)
            at org.apache.hadoop.io.nativeio.NativeIO$POSIX.chmod(NativeIO.java:226)
            at org.apache.hadoop.fs.RawLocalFileSystem.setPermission(RawLocalFileSystem.java:629)
            at org.apache.hadoop.fs.DelegateToFileSystem.setPermission(DelegateToFileSystem.java:186)
            at org.apache.hadoop.fs.FilterFs.setPermission(FilterFs.java:235)
            at org.apache.hadoop.fs.FileContext$10.next(FileContext.java:949)
            at org.apache.hadoop.fs.FileContext$10.next(FileContext.java:945)
            at org.apache.hadoop.fs.FSLinkResolver.resolve(FSLinkResolver.java:90)
            at org.apache.hadoop.fs.FileContext.setPermission(FileContext.java:945)
            at org.apache.hadoop.yarn.util.FSDownload.changePermissions(FSDownload.java:398)
            at org.apache.hadoop.yarn.util.FSDownload.changePermissions(FSDownload.java:412)
            at org.apache.hadoop.yarn.util.FSDownload.changePermissions(FSDownload.java:412)
            at org.apache.hadoop.yarn.util.FSDownload.call(FSDownload.java:352)
            at org.apache.hadoop.yarn.util.FSDownload.call(FSDownload.java:57)
            at java.util.concurrent.FutureTask.run(FutureTask.java:262)
            at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
            at java.util.concurrent.FutureTask.run(FutureTask.java:262)
            at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
            at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
            at java.lang.Thread.run(Thread.java:744)

• 問題原因：壓縮包內(nèi)含有軟鏈接導致資源本地化異常。

• 處理方法：刪除該壓縮包內(nèi)包含的軟鏈接。

Container啟動失敗或運行異常，報錯提示No space left on device，該如何處理？

節(jié)點NM服務(wù)或任務(wù)運行時無法正常解析域名，該如何處理？

• 問題現(xiàn)象：報錯提示java.net.UnknownHostException: Invalid host name: local host is: (unknown)。

• 問題原因及處理方法：

  • 查看是否正確配置了DNS服務(wù)器。

    通過以下命令，檢查配置信息。

    cat /etc/resolv.conf

  • 查看防火墻是否設(shè)置了53端口的相關(guān)規(guī)則。

    如果設(shè)置了，請關(guān)閉防火墻。

  • 查看是否開啟了DNS的NSCD緩存服務(wù)。

    通過以下命令，檢查服務(wù)狀態(tài)。

    systemctl status nscd

    如果開啟了DNS的NSCD緩存服務(wù)，可以執(zhí)行以下命令，停止緩存服務(wù)。

    systemctl stop nscd

NM組件OOM如何處理？

ECS實例重啟后NM啟動失敗：cgroup目錄丟失，如何處理？

• 詳細異常信息：ResourceHandlerException: Unexpected: Cannot create yarn cgroup Subsystem:cpu Mount point:/proc/mounts User:hadoop Path:/sys/fs/cgroup/cpu/hadoop-yarn

• 原因：ECS異常重啟可能是ECS內(nèi)核缺陷（已知問題版本：4.19.91 -21.2.al7.x86_64）導致的。重啟后CPU cgroup失效問題，原因是重啟后cgroup的內(nèi)存數(shù)據(jù)會被銷毀掉。

• 解決方案：修改存量集群節(jié)點執(zhí)行和擴容節(jié)點的引導腳本，在當前環(huán)境中創(chuàng)建cgroup目錄并且用rc.local在以后ECS啟動的時候創(chuàng)建目錄。

  # enable cgroups
  mkdir -p /sys/fs/cgroup/cpu/hadoop-yarn
  chown -R hadoop:hadoop /sys/fs/cgroup/cpu/hadoop-yarn
  # enable cgroups after reboot
  echo "mkdir -p /sys/fs/cgroup/cpu/hadoop-yarn" >> /etc/rc.d/rc.local
  echo "chown -R hadoop:hadoop /sys/fs/cgroup/cpu/hadoop-yarn" >> /etc/rc.d/rc.local
  chmod +x /etc/rc.d/rc.local

修改NM resource配置，保存重啟后未生效，如何處理？

• 報錯說明：修改yarn.nodemanager.resource.cpu-vcores和yarn.nodemanager.resource.memory-mb參數(shù)，保存重啟NM后，NM資源數(shù)未修改。

• 問題原因：由于機器組可能使用不同CPU內(nèi)存規(guī)格的實例，所以修改yarn.nodemanager.resource.cpu-vcores和yarn.nodemanager.resource.memory-mb參數(shù)，需要修改節(jié)點組維度的配置才能生效。

• 解決方案：在EMR控制臺，選擇節(jié)點組維度，選擇需要配置的NM所在節(jié)點組修改資源數(shù)的配置，具體操作請參見管理配置項。

節(jié)點出現(xiàn)Unhealthy問題，如何處理？

• 原因：

  • 磁盤檢查發(fā)現(xiàn)異常：當正常目錄數(shù)或總目錄數(shù)比率低于磁盤健康比例（yarn-site.xml配置項yarn.nodemanager.disk-health-checker.min-healthy-disks，默認值：0.25）時，將節(jié)點標記為UnHealthy。例如NM節(jié)點使用4塊磁盤，當4塊磁盤上的目錄均不正常時節(jié)點才會標記為UnHealthy，否則只在NM狀態(tài)報告中顯示local-dirs are bad或log-dirs are bad，參見節(jié)點磁盤問題：local-dirs are bad/log-dirs are bad，如何處理？。

  • NM健康檢查腳本發(fā)現(xiàn)異常：該項檢查默認未啟用，需要主動配置健康檢查腳本（yarn-site.xml配置項yarn.nodemanager.health-checker.script.path）才能開啟。

• 解決方案

  • 磁盤問題，請參見節(jié)點磁盤問題：local-dirs are bad/log-dirs are bad，如何處理？中的解決方案。

  • 健康檢查腳本問題，請根據(jù)自定義腳本處理。

節(jié)點磁盤問題：local-dirs are bad/log-dirs are bad，如何處理？

• 原因：磁盤檢查發(fā)現(xiàn)異常。該項檢查默認開啟，周期性檢查local-dirs（任務(wù)運行緩存目錄，包括任務(wù)運行依賴的各類文件、中間數(shù)據(jù)文件等）與log-dirs（任務(wù)運行日志目錄，包含全部日志運行）是否滿足以下條件，只要有一項不滿足就會被標記為bad。

  • 可讀

  • 可寫

  • 可執(zhí)行

  • 磁盤空間使用率是否低于配置閾值（yarn-site.xml配置項yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage，默認：90%）

    磁盤剩余可用空間是否大于磁盤最小可用空間的配置值（yarn-site.xml配置項yarn.nodemanager.disk-health-checker.min-free-space-per-disk-mb，默認：0）

• 解決方案

  • 一般都是磁盤空間不足引起，如果確認存在下述場景之一，建議擴容磁盤：

    • NM節(jié)點規(guī)格較大，可運行任務(wù)數(shù)較多。

    • 磁盤空間相對較小。

    • 任務(wù)運行所依賴的數(shù)據(jù)或文件較大。

    • 任務(wù)運行產(chǎn)生的中間數(shù)據(jù)較多。

    • 任務(wù)日志相對較大（磁盤空間占比高）。

  • 檢查yarn-site.xml配置項yarn.nodemanager.localizer.cache.target-size-mb，如果相對磁盤比例過大會造成歷史任務(wù)緩存占用磁盤空間過多（超出配置值后才能自動清理）。

  • 壞盤問題，請參見自助壞盤維修流程更換集群損壞的本地盤。

報錯提示User [dr.who] is not authorized to view the logs for application ***，該如何處理？

• 問題現(xiàn)象：打開日志頁面時，提示信息如下。

• 問題原因：訪問NodeManager Log頁面時會檢查ACL規(guī)則。如果啟用了ACL規(guī)則，遠程用戶就要符合以下任一個條件：

  • 是admin用戶。

  • 是app owner。

  • 滿足app自定義ACL規(guī)則。

• 處理方法：檢查是否滿足以上條件中的任一條。

報錯提示HTTP ERROR 401 Authentication required或HTTP ERROR 403 Unauthenticated users are not authorized to access this page，該如何處理？

• 問題現(xiàn)象：訪問UI或REST API時報錯HTTP ERROR 401或HTTP ERROR 403。HTTP ERROR 401詳細信息如下圖。

  

• 問題原因：YARN啟用了Simple認證且不允許匿名訪問，詳情請參見Authentication for Hadoop HTTP web-consoles。

• 處理方法：

  • 方式一：URL參數(shù)中顯示指定遠程用戶，例如，user.name=***。

  • 方式二：您可以在E-MapReduce控制臺的HDFS服務(wù)的配置頁簽，在搜索區(qū)域搜索參數(shù)hadoop.http.authentication.simple.anonymous.allowed，修改其參數(shù)值為true允許匿名訪問，參數(shù)含義請參見Authentication for Hadoop HTTP web-consoles。然后重啟服務(wù)，請參見重啟服務(wù)。

為什么TotalVcore顯示值不準確？

在YARN UI右上方，Cluster或Metrics REST API結(jié)果中，TotalVcore顯示值不準確。此問題是由于社區(qū)2.9.2之前版本TotalVcore計算邏輯有問題，詳情請參見https://issues.apache.org/jira/browse/YARN-8443。

EMR-3.37.x和EMR-5.3.x及后續(xù)版本已修復(fù)此問題。

TEZ UI展示的應(yīng)用信息不全，該如何處理？

為什么YARN UI頁面有一個正在運行的Spark Thrift JDBC/ODBC Server任務(wù)？

如果您在創(chuàng)建集群時選擇了Spark服務(wù)，集群會自動啟動一個默認的Spark Thrift Server服務(wù)。該服務(wù)會占用一個YARN Driver的資源。在Spark Thrift Server中運行的任務(wù)，默認會通過該Driver向YARN申請所需的資源。

yarn.timeline-service.leveldb-timeline-store.path是否支持使用OSS地址？

yarn.timeline-service.leveldb-timeline-store.path參數(shù)不支持使用OSS地址。

如果您創(chuàng)建的是Hadoop集群，則yarn.timeline-service.leveldb-timeline-store.path的默認值與hadoop.tmp.dir參數(shù)相同。請不要修改HDFS的hadoop.tmp.dir參數(shù)，因為這會影響yarn.timeline-service.leveldb-timeline-store.path的配置。

Timeline Server連接超時、CPU或Memory占用異常高問題，該如何處理？

在Tez任務(wù)特別多的情況下，寫入YARN的Timeline Server時，可能會出現(xiàn)連接超時的問題。這是因為Timeline Server進程占用大量CPU導致節(jié)點CPU使用率達到極限，進而影響到了作業(yè)開發(fā)和其他非核心業(yè)務(wù)（例如報表生成），所以臨時停止TimelineServer進程來減輕節(jié)點的CPU負載。您可以通過修改以下配置項來解決此問題。

在EMR控制臺修改Tez和YARN服務(wù)的相應(yīng)配置，新增或修改配置的具體操作，請參見管理配置項。

1. 在EMR控制臺Tez服務(wù)的配置頁面的tez-site.xml頁簽，新增參數(shù)為tez.yarn.ats.event.flush.timeout.millis，參數(shù)值為60000的配置項，該參數(shù)用來設(shè)置Tez任務(wù)將事件寫入YARN的Timeline Server時的超時時間。

2. 在EMR控制臺YARN服務(wù)的配置頁面的yarn-site.xml頁簽，新增或修改以下配置項。修改完配置項后需要在YARN服務(wù)的狀態(tài)頁面重啟下TimelineServer。

   參數(shù)	參數(shù)值	說明
   yarn.timeline-service.store-class	org.apache.hadoop.yarn.server.timeline.RollingLevelDBTimelineStore	用于指定YARN Timeline Server的事件存儲類。
   yarn.timeline-service.rolling-period	daily	用于設(shè)置YARN Timeline Server的事件滾動周期
   yarn.timeline-service.leveldb-timeline-store.read-cache-size	4194304	用于設(shè)置YARN Timeline Server LevelDB存儲的讀取緩存大小。
   yarn.timeline-service.leveldb-timeline-store.write-buffer-size	4194304	用于設(shè)置YARN Timeline Server LevelDB存儲的寫入緩沖區(qū)大小。
   yarn.timeline-service.leveldb-timeline-store.max-open-files	500	用于設(shè)置YARN Timeline Server LevelDB存儲的最大打開文件數(shù)。