我遇到Hadoop在$ HADOOP_LOG_DIR / userlogs中生成太多日志文件的问题（Ext3文件系统只允许32000个子目录），在这个问题中看起来像是同样的问题： Hadoop MapReduce出错
我的问题是：有没有人知道如何配置Hadoop滚动日志目录或以其他方式防止这种情况？我试图避免只设置“mapred.userlog.retain.hours”和/或“mapred.userlog.limit.kb”属性，因为我想实际保留日志文件。
我也希望在log4j.properties中配置它，但是看看Hadoop 0.20.2源代码，它直接写入日志文件而不是实际使用log4j。也许我不明白它是如何完全使用log4j的。
任何建议或澄清将不胜感激。
不幸的是，没有一种可配置的方法可以防止这种情况发生。作业的每个任务都会在history / userlogs中获取一个目录，该目录将保存stdout，stderr和syslog任务日志输出文件。保留时间将帮助保留太多的积累，但你必须编写一个好的日志轮换工具来自动tar它们。
当我们写入NFS挂载时，我们也遇到了这个问题，因为所有节点都将共享相同的history / userlogs目录。这意味着一项有30,000个任务的工作就足以打破FS。当您的集群实际开始处理大量数据时，本地登录实际上是可行的方法。
如果您已经在本地登录并且仍然设法在不到一周的时间内在一台计算机上处理30,000多个任务，那么您可能创建了太多的小文件，从而导致为每个作业生成太多的映射器。
不幸的是，没有一种可配置的方法可以防止这种情况发生。作业的每个任务都会在history / userlogs中获取一个目录，该目录将保存stdout，stderr和syslog任务日志输出文件。保留时间将帮助保留太多的积累，但你必须编写一个好的日志轮换工具来自动tar它们。
当我们写入NFS挂载时，我们也遇到了这个问题，因为所有节点都将共享相同的history / userlogs目录。这意味着一项有30,000个任务的工作就足以打破FS。当您的集群实际开始处理大量数据时，本地登录实际上是可行的方法。
如果您已经在本地登录并且仍然设法在不到一周的时间内在一台计算机上处理30,000多个任务，那么您可能创建了太多的小文件，从而导致为每个作业生成太多的映射器。
我有同样的问题。在启动Hadoop之前设置环境变量“HADOOP_ROOT_LOGGER = WARN，console”。
export HADOOP_ROOT_LOGGER="WARN,console"
hadoop jar start.jar
配置hadoop以使用log4j和设置
log4j.appender.FILE_AP1.MaxFileSize=100MB
log4j.appender.FILE_AP1.MaxBackupIndex=10
喜欢描述 这个维基页面 不起作用？
看着 LogLevel源代码，似乎hadoop使用commons日志记录，并且它将尝试默认使用log4j，或者如果log4j不在类路径上则使用jdk logger。
顺便说一下，可以在运行时更改日志级别，看看 命令手册。
根据文件， Hadoop使用log4j进行日志记录。也许你在找错了地方......
我也遇到了同样的问题.... Hive会生成大量日志，当磁盘节点已满时，不能再启动容器了。在Yarn中，目前没有禁用日志记录的选项。一个特别庞大的文件是syslog文件，在我们的案例中几分钟内生成GB的日志。
在“yarn-site.xml”中配置属性yarn.nodemanager.log.retain-seconds到一个小值没有帮助。无法将“yarn.nodemanager.log-dirs”设置为“file：/// dev / null”，因为需要一个目录。删除写入ritght（chmod -r / logs）也不起作用。
一种解决方案可能是“null blackhole”目录。点击这里： https://unix.stackexchange.com/questions/9332/how-can-i-create-a-dev-null-like-blackhole-directory
另一个为我们工作的解决方案是在运行作业之前禁用日志。例如，在Hive中，通过以下行启动脚本正在工作：
set yarn.app.mapreduce.am.log.level=OFF;
set mapreduce.map.log.level=OFF;
set mapreduce.reduce.log.level=OFF;