spark无法查看stdout:hadoop about "Container does not exist."

本文介绍了解决Hadoop集群中查看Node日志时出现“Containerdoesnotexist”错误的方法。通过配置日志聚合功能并调整JobHistoryServer设置,可以有效避免此问题。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

转载来自:https://blog.youkuaiyun.com/stark_summer/article/details/47616773

场景描述:

hadoop集群中正在运行的任务,点击“application_1438756578740_5947”链接,然后能看到ApplicationMaters信息,有N个Node节点在运行,然后点击任一个Node的logs链接,会报错如下:“Container does not exist.”

hadoop jira上貌似是2.3的一个bug,2.4fix了

 added comment in ContainerLogsUtils.getContainerLogDirs() as below.
"It is not required to have null check for container ( container == null ) and throw back exception.Because when container is completed, NodeManager remove container information from its NMContext.Configuring log aggregation to false, container log view request is forwarded to NM. NM does not have completed container information,but still NM serve request forreading container logs."
  • 1
  • 2

https://issues.apache.org/jira/browse/YARN-1206 
PS: 经过测试,当我启动日志聚合功能(log aggregation to true),然后再启动 hadoop history server(端口是19888)进程,就不会再报“Container does not exist.”

之前也遇到这个问题

Failed redirect for container_1412602970010_0037_01_000002 
Failed while trying to construct the redirect url to the log server. Log Server url may not be configured 
Container does not exist. 
但在yarn-site.xml下增加如下内容:

<property> 
<name>yarn.log.server.url</name> 
<value>http://hnn002.dev.com:19888/jobhistory/logs/</value> 
</property> 

by default logs from hdfs://user/history/* are not accessible through JobHistory server. 
When I changed the permission on hdfs://user/history/ 
hadoop fs -chmod -R 777 /user/history/

参考链接: 
https://groups.google.com/a/cloudera.org/forum/#!topic/cdh-user/HBGzj_NG9_s 
https://issues.apache.org/jira/browse/YARN-1206

### 解决方案分析 `java.io.FileNotFoundException: File does not exist` 是 Hadoop 生态系统中常见的错误之一,通常发生在尝试访问 HDFS 上不存在的文件或目录时。以下是针对该问题的具体解决方案: #### 1. **确认路径是否存在** 需要验证指定的 HDFS 路径是否真实存在。可以通过 `hdfs dfs -ls` 命令来检查目标路径的状态[^1]。 ```bash hdfs dfs -ls /user/liveme/facebook/ ``` 如果路径不存在,则需要重新上传所需的文件至正确的路径下。 --- #### 2. **临时文件清理** 错误日志显示 `/user/liveme/facebook/_temporary/` 文件夹下的某些中间文件丢失。这可能是由于任务失败后未正确清理所致。可以手动删除 `_temporary` 文件夹并重试作业运行[^2]。 ```bash hdfs dfs -rm -r /user/liveme/facebook/_temporary/ ``` --- #### 3. **检查权限设置** 权限不足也可能导致无法找到文件的情况。通过以下命令查看当前用户的权限配置,并确保其具有读取和写入目标路径的权利[^3]。 ```bash hdfs dfs -getfacl /user/liveme/facebook/ ``` 如需调整权限,可执行如下操作: ```bash hdfs dfs -chmod 755 /user/liveme/facebook/ ``` --- #### 4. **YARN 应用程序管理器 (AM) 的诊断信息** 日志提到应用程序多次失败 (`Application ... failed 2 times`) 并返回退出码 `-1000`。此情况可能由多种原因引起,例如资源分配不足、依赖 jar 包缺失等。建议重点排查以下几个方面: - 确认所有必要的 JAR 文件已成功上传到 HDFS。 - 检查 YARN 和 ResourceManager 的日志以获取更详细的上下文信息。 --- #### 5. **Tez 引擎优化** Tez 引擎在 Hive 查询过程中扮演重要角色。如果查询涉及大量数据处理,可能会因内存溢出或其他资源配置不当而引发异常。可通过增加容器大小或调整并发度参数缓解此类问题: ```properties set tez.am.resource.memory.mb=4096; set tez.task.resource.memory.mb=2048; ``` --- #### 6. **Sqoop 数据同步校验** Sqoop 同步 MySQL 至 HDFS 过程中的错误表明源表结构与目标存储不匹配的可能性较大。应仔细核对两者之间的字段定义以及分区策略的一致性。 --- ### 示例代码片段 以下是一个简单的脚本用于检测 HDFS 中的目标路径状态: ```python from subprocess import Popen, PIPE def check_hdfs_path(path): command = f"hdfs dfs -test -e {path}" process = Popen(command.split(), stdout=PIPE, stderr=PIPE) output, error = process.communicate() if process.returncode == 0: print(f"Path exists: {path}") else: print(f"Path NOT found: {path}") check_hdfs_path("/user/liveme/facebook/") ``` --- ### 总结 上述方法涵盖了从基础路径验证到高级资源配置等多个层面的内容。实际应用时可根据具体场景灵活选用合适的措施加以应对。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值