Hadoop集群常見報錯匯總
作者：尹正傑
版權聲明：原創作品，謝絕轉載！否則將追究法律責任。
一.org.apache.hadoop.security.KerberosAuthException: Login failure for user: hdfs/hadoop101.yinzhengjie.com@YINZHENGJIE.COM from keytab /yinzhengjie/softwares/hadoop/etc/hadoop/conf/hdfs.keytab javax.security.auth.login.LoginException: Unable to obtain password from user
1>.錯誤復現
2>.錯誤原因分析
如上圖所示，/yinzhengjie/softwares/hadoop/etc/hadoop/conf/hdfs.keytab文件是存在的，報錯是"Unable to obtain password from user"。這就需要我們去檢查"hdfs.keytab"文件是否有對應主體(本案例是"hdfs/hadoop101.yinzhengjie.com@YINZHENGJIE.COM")的信息。
3>.解決方案
檢查hdfs.keytab文件是否有對應的服務主體。若沒有就需要去KDC服務器重新抽取新的keytab文件並分發到Hadoop集群各節點，若有對應主體就得手動驗證登錄，驗證該主體是否可以成功登錄。
二.java.io.IOException: Security is enabled but block access tokens (via dfs.block.access.token.enable) aren't enabled. This may cause issues when clients attempt to connect to a DataNode. Aborting NameNode
1>.錯誤復現
2>.錯誤原因分析
錯誤原因以及很明顯了，是由於沒有啟用"dfs.block.access.token.enable"，其值默認為"false"。在配置Kerberos集群時必須將其值設置為"true"。 溫馨提示: 塊訪問令牌確保只有授權用戶訪問DataNodes上的HDFS數據。客戶端從NameNode接收到塊ID后，將從DataNodes中檢索數據。Namenode還發放客戶端發送到DataNode的塊訪問令牌以及數據塊訪問請求，以用於數據訪問。
3>.解決方案
如下所示，將上圖報錯的參數設置為"true"問題得到解決。別忘記修改hdfs-site.xml文件后，要同步到集群的其它節點喲~ <property> <name>dfs.block.access.token.enable</name> <value>true</value> <description>如果為"true"，則訪問令牌用作訪問數據節點的功能。如果為"false"，則在訪問數據節點時不檢查訪問令牌。默認值為"false"</description> </property>
三.java.lang.RuntimeException: Cannot start secure DataNode without configuring either privileged resources or SASL RPC data transfer protection and SSL for HTTP. Using privileged resources in combination with SASL RPC data transfer protection is not supported.
1>.錯誤復現
2>.錯誤原因分析
如果不配置特權資源或SASL RPC數據傳輸保護和HTTP的SSL，則無法啟動secure DataNode。不支持將特權資源與SASL RPC數據傳輸保護結合使用。此時我們需要配置"dfs.http.policy"屬性。
3>.解決方案
如下所示，修改hdfs-site.xml配置文件中的"dfs.data.transfer.protection"和"dfs.http.policy"屬性即可。 <!-- DataNode SASL配置,若不指定可能導致DataNode啟動失敗 --> <property> <name>dfs.data.transfer.protection</name> <value>integrity</value> <description>逗號分隔的SASL保護值列表，用於在讀取或寫入塊數據時與DataNode進行安全連接。可能的值為:"authentication"(僅表示身份驗證，沒有完整性或隱私), "integrity"(意味着啟用了身份驗證和完整性)和"privacy"(意味着所有身份驗證，完整性和隱私都已啟用)。如果dfs.encrypt.data.transfer設置為true，則它將取代dfs.data.transfer.protection的設置，並強制所有連接必須使用專門的加密SASL握手。對於與在特權端口上偵聽的DataNode的連接，將忽略此屬性。在這種情況下，假定特權端口的使用建立了足夠的信任。</description> </property> <property> <name>dfs.http.policy</name> <value>HTTPS_ONLY</value> <description>確定HDFS是否支持HTTPS(SSL)。默認值為"HTTP_ONLY"(僅在http上提供服務),"HTTPS_ONLY"(僅在https上提供服務,DataNode節點設置該值),"HTTP_AND_HTTPS"(同時提供服務在http和https上,NameNode和Secondary NameNode節點設置該值)。</description> </property>
四.java.io.IOException: java.security.GeneralSecurityException: The property 'ssl.server.keystore.location' has not been set in the ssl configuration file.
1>.錯誤復現
2>.錯誤原因分析
未給HTTPS SSL配置的密鑰庫位置。指定該熟悉的值在"${HADOOP_HOME}/etc/hadoop/ssl-server.xml"文件中指定即可。
3>.解決方案
檢查Hadoop集群是否配置了https，若未配置可參考我之前寫的筆記即可。 博主推薦閱讀: https://www.cnblogs.com/yinzhengjie/p/13461151.html
五.javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Clock skew too great (37) - PROCESS_TGS)]
1>.錯誤復現
2>.錯誤原因分析
這個錯誤已經很明顯了，是因為當前節點機器和KDC機器的時間差太大了，您可用登錄一下KDC服務器查看一下時間，再登錄DataNode節點查看一下時間。
事實上你會發現這個差距的確不小，如下圖所示(很抱歉哈，當時的命令行被我敲擊的"history"命令給覆蓋了，但下圖配置chrony進行時間同步后，從結果上來看差距還是蠻大的，直接相差接近16個小時喲~)，我的DataNode和KDC服務器之間的時間差的確很大。
3>.解決方案
知道錯誤原因在哪里了，那么解決起來就不是事情了，畢竟您已經找到要解決的方向了，關於集群時間同步的組件比如nptd或者chrony均可以解決該問題。我推薦大家使用chrony組件來進行集群內時間同步。 博主推薦閱讀: https://www.cnblogs.com/yinzhengjie/p/12292549.html
六.ls: Failed on local exception: java.io.IOException: javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)]; Host Details : local host is: "hadoop102.yinzhengjie.com/172.200.6.102"; destination host is: "hadoop101.yinzhengjie.com":9000;
1>.錯誤復現
2>.錯誤原因分析
從上圖想必大家已經看出端倪了，沒錯，就是未提供有效憑據。這是我們啟用了Kerberos認值后，若再想要使用命令行進行訪問的話，就必須先做Kerberos認證才行！
3>.解決方案
如下圖所示，進行Kerberos驗證即可訪問HDFS集群啦~關於如何基於Kerberos的KDC服務器創建主體以及keytab文件，可以參考我之前的筆記。 博主推薦閱讀: https://www.cnblogs.com/yinzhengjie2020/p/13616881.html
[root@hadoop102.yinzhengjie.com ~]# klist klist: No credentials cache found (filename: /tmp/krb5cc_0) [root@hadoop102.yinzhengjie.com ~]# [root@hadoop102.yinzhengjie.com ~]# [root@hadoop102.yinzhengjie.com ~]# kinit -kt /yinzhengjie/softwares/hadoop/etc/hadoop/conf/hdfs.keytab dn/hadoop101.yinzhengjie.com@YINZHENGJIE.COM [root@hadoop102.yinzhengjie.com ~]# [root@hadoop102.yinzhengjie.com ~]# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: dn/hadoop101.yinzhengjie.com@YINZHENGJIE.COM Valid starting Expires Service principal 10/06/2020 16:57:26 10/07/2020 16:57:26 krbtgt/YINZHENGJIE.COM@YINZHENGJIE.COM renew until 10/13/2020 16:57:26 [root@hadoop102.yinzhengjie.com ~]# [root@hadoop102.yinzhengjie.com ~]# [root@hadoop102.yinzhengjie.com ~]# hdfs dfs -ls / Found 4 items drwxr-xr-x - root admingroup 0 2020-08-21 16:40 /bigdata drwxr-xr-x - root admingroup 0 2020-08-20 19:26 /system drwx------ - root admingroup 0 2020-08-14 19:19 /user drwxr-xr-x - root admingroup 0 2020-09-16 10:50 /yinzhengjie [root@hadoop102.yinzhengjie.com ~]# [root@hadoop102.yinzhengjie.com ~]#
六.Exception in thread "main" java.lang.IllegalArgumentException: Can't get Kerberos realm
1>.錯誤復現
2>.錯誤原因分析
從上圖Java的堆棧的報錯信息可以看出，獲取不到默認的Kerberos領域(realm)信息。這種情況大多數都是由於配置文件未放置到正確的路徑導致的。 我們按照Kerberos習慣性將Kerberos的配置文件放置在"C:\ProgramData\MIT\Kerberos5"路徑，但Hadoop查找Kerberos文件並不會去該路徑找，它會去"C:\Windows\krb5.ini"找，若找不到就會報錯！
3>.解決方案
如下圖所示，將"C:\ProgramData\MIT\Kerberos5\krb5.ini"拷貝一份到"C:\Windows\krb5.ini"即可解決問題。
七.mkdir: Permission denied: user=root, access=WRITE, inode="/":nn:yinzhengjie:drwxr-xr-x
1>.錯誤復現
2>.錯誤原因分析
很明顯，這是權限問題導致的，它說當前用戶是root，而根節點的超級用戶是nn，超級用戶組是yinzhengjie。很明顯，root用戶既不屬於HDFS的超級用戶，也不屬於HDFS的超級用戶組。因此權限創建目錄時權限被拒絕。
3>.解決方案
找到錯誤原因就可以對症下葯啦，解決方法很簡單，如下圖所示，我們只需要將Kerberos認證用戶更換為HDFS的超級用戶即可。
八.The ServiceName: mapreduce.shuffle set in yarn.nodemanager.aux-services is invalid.The valid service name should only contain a-zA-Z0-9_ and can not start with numbers
1>.錯誤復現
2>.錯誤原因分析
從報錯信息估計很多小伙伴已經定位問題了，說是yarn.nodemanager.aux-services配置參數無效。yarn.nodemanager.aux-services的值應該設置為"a-zA-Z0-9_"。 於是，我檢查了自己的配置文件(${HADOOP_HOME}/etc/hadoop/yarn-site.xml)，發現的確是出現問題了，如下圖所示。
3>.解決方案
如下圖所示，將對應的value修改后分發到Hadoop節點即可。
九.Aggregation is not enabled. Try the nodemanager at hadoop104.yinzhengjie.com:31424
1>.錯誤復現
2>.錯誤原因分析
這個錯誤原因是由於我們沒有啟用日志聚合功能導致的，想要解決該問題，可以開啟日志聚合功能，即將"yarn.log-aggregation-enable"的值設置為true。 溫馨提示： 如果你將"yarn.log-aggregation-enable"的值設置為其他值，例如"ture"，你依舊會發現日志功能沒有啟動喲~
3>.解決方案
如下所示，將"yarn.log-aggregation-enable"的值設置為"true"即可。 <property> <name>yarn.log-aggregation-enable</name> <value>true</value> <description> 每個DataNode上的NodeManager使用此屬性來聚合應用程序日志。默認值為"false"，啟用日志聚合時，Hadoop收集作為應用程序一部分的每個容器的日志，並在應用完成后將這些文件移動到HDFS。 可以使用"yarn.nodemanager.remote-app-log-dir"和"yarn.nodemanager.remote-app-log-dir-suffix"屬性來指定在HDFS中聚合日志的位置。 </description> </property>
十.Failed while trying to construct the redirect url to the log server. Log Server url may not be configured
1>.錯誤復現
2>.錯誤原因分析
我們知道開啟日志聚合不僅僅要將"yarn.log-aggregation-enable"的值設置為true，還需指定正確的"yarn.log.server.url"參數。 根據錯誤提示信息，想必大家也大概定位問題了，說是連接聚合日志服務器失敗了，此時請檢查"yarn-site.xml"配置文件中的"yarn.log.server.url"屬性值是否配置正確，即是否指向了正確的日志聚合服務器呢？
3>.解決方案
如下所示，我們只需為"yarn.log.server.url"配置JobHistoryServer的URL即可。 <property> <name>yarn.log.server.url</name> <value>http://hadoop105.yinzhengjie.com:19888/yinzhengjie/history_logs/aggregation</value> <description>指定日志聚合服務器的URL，若不指定，默認值為空。</description> </property> 溫馨提示: 當我們配置好yarn.log-aggregation-enable和yarn.log.server.url屬性后，建議重啟一下YARN和HistoryServer服務，使得配置立即生效。 如果您也能在ResourceManager Web UI看到類型下面的日志信息，說明您的日志聚合功能配置是正確的喲~
十一.Error: Could not find or load main class org.apache.hadoop.mapreduce.v2.app.MRAppMaster
1>.錯誤復現
2>.錯誤原因分析
從上圖的報錯信息("Could not find or load main class org.apache.hadoop.mapreduce.v2.app.MRAppMaster")可得知，這是由於找不到主類導致的，解決方案上圖已經給出來了，需要我們手動指定Hadoop的環境變量。
3>.解決方案
我參考其提示信息，分別將"yarn.app.mapreduce.am.env","mapreduce.map.env"和"mapreduce.reduce.env"的值設置成"HADOOP_MAPRED_HOME=${HADOOP_HOME}"，發現並沒有解決問題。 於是我又將這3個值改值改為絕對路徑"HADOOP_MAPRED_HOME=/yinzhengjie/softwares/hadoop"(改成絕對路徑我是懷疑過mapred-site.xml識別不了"$HADOOP_HOME變量的")，發現依舊解決不了問題。 目前給出兩個解決方案: 方案一(修改"${HADOOP_HOME}/etc/hadoop/yarn-site.xml"配置文件)： 要么就不設置"yarn.application.classpath"的值，即將其設置為空。 如下圖所示，建議將"yarn.application.classpath"的值設置為:"yarn classpath"命令的執行結果。 方案二(修改"${HADOOP_HOME}/etc/hadoop/mapred-site.xml"配置文件): 要么就不設置"yarn.app.mapreduce.am.env","mapreduce.map.env"和"mapreduce.reduce.env"的值，即將其設置為空。 若要設置，若要設置，建議將"mapreduce.application.classpath"的值設置為"mapred classpath"命令的執行結果。
十二.Container exited with a non-zero exit code 1. Error file: prelaunch.err.
1>.錯誤復現
2>.錯誤原因分析
不得不說，這個問題的確困擾了我一個上午，我還去網上嘗試了幾乎所有的解決方案，沒有一種能解決的，我當時很郁悶啊。 但仔細看看錯誤輸出，其中"prelaunch.err "是啟動前錯誤，也就是在container啟動之前就出問題了，這個時候我終於得到了啟發，問題應該定位跟啟動JVM相關的參數上。 如下圖所示，我檢查了"${HADOOP_HOME}/etc/hadoop/mapred-site.xml"的參數，下面有關於"mapreduce.map.java.opts"的值我設置為"-Xmx1536"。 可能有的小伙伴已經發現錯誤了，我少寫了一個計量單位(比如KB,MB,GB等)，問題就出在這里，應該寫的值為"-Xmx1536m"，問題得到解決。
3>.解決方案
如下圖所示，我們在指定JVM啟動參數時，一定要加上單位，否則就容易拋出"Container exited with a non-zero exit code 1. Error file: prelaunch.err."異常喲~
排除問題的方案:
我這里有個方法雖然笨，但無論遇到任何問題都可以用該方法來定位問題，那就是用排除法，即將配置正確的項保留，把配置不確定的項注釋掉，如上圖所示，我就是采用該方法來定位問題的。
十三.java.lang.IllegalArgumentException: Illegal capacity of -1.0 for queue root.yinzhengjie
1>.錯誤復現
2>.錯誤原因
我們都知道Apache Hadoop的調度器默認是容量調度，因此我們需要為咱們定義的隊列按照百分比配置其容量大小，若沒有配置就會拋出異常。
3>.解決方案
既然知道錯誤原因在哪里了，那解決起來相對來說就比較簡單了。如下所示，我為容量調度器指定了2個自頂級隊列，分別為："default"和"yinzhengjie"。 <property> <name>yarn.scheduler.capacity.root.queues</name> <value>default,yinzhengjie</value> <description>這是為root頂級隊列定義子隊列，默認值為:"default"</description> </property> 但光配置上面是不夠的，我們還需要為隊列分配容量，假設讓"yinzhengjie"隊列的容量是"default"隊列容量的4倍，我們可以這樣配置： <property> <name>yarn.scheduler.capacity.root.yinzhengjie.capacity</name> <value>80</value> <description>指定"yinzhengjie"隊列的大小,這里指定的是一個"yinzhengjie"隊列占"root"隊列的百分比，即80%的資源</description> </property> <property> <name>yarn.scheduler.capacity.root.default.capacity</name> <value>20</value> <description>指定"default"隊列大小,占root隊列的20%的資源</description> </property>
十四.refreshQueues: java.io.IOException: Failed to re-init queues : Can not convert the leaf queue: root.yinzhengjie to parent queue since it is not yet in stopped state. Current State : RUNNING
1>.錯誤復現
2>.錯誤原因
眾所周知，我們僅能向容量調度器的葉子隊列提交Job，而不能向父隊列提交Job。
那么問題已經很明顯了，是由於我們將現有的葉子隊列更改為父隊列導致的錯誤，因為葉子隊列正在運行(其隊列狀態為：RUNNING)，要想將一個隊列設置為父隊列，則其狀態必須為STOPPED。
3>.解決方案
如果單純解決該錯誤的話比較簡單，要么還原配置，要么使得現有配置生效。
我們應該仔細檢查配置文件，是否真的要按照配置文件執行，要使得現有配置文件生效，則必須讓父隊列由RUNNING狀態變為STOPPED狀態，最簡單的辦法就是重啟YARN集群。
當然，通過檢查配置文件發現，是由於你"手誤"把配置文件配錯了(也就是說配置語法沒問題，但並不符合你之前設計的邏輯)，這時候應該及時還原之前的配置，避免重啟YARN集群導致此配置真的生效啦~
十五.Failed to re-init queues : The parent queue:yinzhengjie state is STOPPED, child queue:operation state cannot be RUNNING.
1>.錯誤復現
2>.錯誤原因分析
錯誤原因已經提示的很明顯了，說是父隊列狀態為STOPPED狀態，而子隊列的狀態為RUNNING狀態。 仔細檢查了文檔"${HADOOP_HOME}/etc/hadoop/capacity-scheduler.xml"的配置內容如下(果真是將父隊列設置為了STOPPED狀態，而子隊列設置為了"RUNNING"狀態)： [root@hadoop101.yinzhengjie.com ~]# vim ${HADOOP_HOME}/etc/hadoop/capacity-scheduler.xml ... <property> <name>yarn.scheduler.capacity.root.yinzhengjie.state</name> <value>STOPPED</value> <description>將"root.yinzhengjie"隊列的狀態設置為"RUNNING"狀態</description> </property> <property> <name>yarn.scheduler.capacity.root.yinzhengjie.operation.state</name> <value>RUNNING</value> <description></description> </property> ... [root@hadoop101.yinzhengjie.com ~]#
3>.解決方案
解決方案就是仔細檢查"${HADOOP_HOME}/etc/hadoop/capacity-scheduler.xml"的配置內容，觀察你配置的隊列其父隊列是否為STOPPED狀態。 若真想啟用當前隊列為RUNNING狀態，則需要將其父隊列改為RUNNING狀態，當然，如果父隊列為RUNNING狀態，則子隊列依舊是可以設置為STOPPED狀態的喲~ [root@hadoop101.yinzhengjie.com ~]# vim ${HADOOP_HOME}/etc/hadoop/capacity-scheduler.xml ... <property> <name>yarn.scheduler.capacity.root.yinzhengjie.state</name> <value>RUNNING</value> <description>將"root.yinzhengjie"隊列的狀態設置為"RUNNING"狀態</description> </property> <property> <name>yarn.scheduler.capacity.root.yinzhengjie.operation.state</name> <value>RUNNING</value> <description></description> </property> ... [root@hadoop101.yinzhengjie.com ~]#
十六.Logs not available for job_1604871808583_0020. Aggregation may not be complete.
1>.錯誤復現
2>.錯誤原因分析
出現此錯誤可能有以下兩種情況：
(1)配置日志聚合的參數可能出現錯誤;
(2)日志聚合的參數配置正確，但未重啟YARN和HistoryServer服務。
溫馨提示:
當配置啟用日志聚合功能后，需要重啟服務才能生效喲~
3>.解決方案
檢查日志聚合相關參數是否配置正確，若配置正確請重啟YARN集群和HistoryServer服務即可。
十七.
十八.
十九.ls: Failed on local exception: java.io.IOException: javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)];
1>.錯誤復現
2>.錯誤原因分析
錯誤原因已經很明顯了，說是找不到Kerberos憑證，但我的字符終端已經進行了Kerberos驗證。首先排除時間同步問題，因為我的Windows主機和KDC服務器時間是同步的！其次排除票據過期問題，因為我的票據距離過期還有24小時！
於是我上網上找了很多文章，基本上解決思路如下面2個連接所示：
https://community.cloudera.com/t5/Community-Articles/Alternate-days-why-do-i-see-GSSException-No-valid/ta-p/248378
https://aws.amazon.com/cn/premiumsupport/knowledge-center/kerberos-expired-ticket-emr/
基本套路都是一樣的，都是讓先進性Kerberos認證，可問題在於我已經認證過了，依舊出現該問題！因此，本錯誤案例我沒有找到錯誤原因，我初步懷疑和操作系統有關！因為同樣的配置文件在Linux上做相同的操作的確是可以訪問到數據的喲~
3>.解決方案
建議使用Linux操作系統進行嘗試，因為Linux操作系統經過Kerberos驗證成功后就可以正常訪問HDFS集群，但是window操作系統目前還沒有找到靠譜的解決方案。
有該問題的解決方案科請不吝賜教。可在博客出留言，謝謝~