Yarn聚合日志, 过期清除配置不生效

在Yarn上开启了日志聚合, 并设置了过期清除的时间, 但是没有生效, 导致在HDFS上聚合后的日志数据过大( /tmp/logs/hdfs/logs ), 造成磁盘空间不足

前提: 配置了Jobhistory Server, 并处于启动中

Jobhistory Server使用的是mapred用户

hadoop fs chown -R mapred:supergroup /tmp/logs/hdfs

原本怀疑是Flink的log4j的配置问题, 错误日志太多导致无法回滚(这个问题在低版本的logback有出现过), 事实验证并不是

那么是否是Yarn运行中的application出现了异常, 而异常重启的次数配置的比较大, 导致不断启动新的container, 通过模拟的确会出现这个问题, 在Yarn NodeManager的 /yarn/container-logs 可看到, 但是该文件会在application停止之后进行清除, 所以也可以暂时忽略这个问题

yarn的组成可以从两个角度看待：

其中，在master node上运行 ResourceManager 。

每个datanode上运行一个 NodeManager 。

并把该dataNode上的所有计算资源（CPU、内存）视为一个/多个 Container ，而Container可以被分配执行一个task(ApplicationMaster、map task、reduce task等)。

具体可看下图：

可结合上文的理解

Container是Yarn框架的计算单元，是具体执行应用task（如map task、reduce task）的基本单位。

Container和集群节点的关系是： 一个节点会运行多个Container，但一个Container不会跨节点 。

一个Container就是一组分配的系统资源，现阶段只包含两种系统资源（之后可能会增加磁盘、网络等资源）：

既然一个Container指的是具体节点上的计算资源，这就意味着Container中必定含有计算资源的位置信息：计算资源位于哪个机架的哪台机器上。 所以我们在请求某个Container时，其实是向某台机器发起的请求，请求的是这台机器上的CPU和内存资源 。

任何一个job或application必须运行在一个或多个Container中 。在Yarn框架中，ResourceManager只负责告诉ApplicationMaster哪些Containers可以用，ApplicationMaster还需要去找NodeManager请求分配具体的Container。

NodeManager进程运行在集群中的节点上，每个节点都会有自己的NodeManager。NodeManager是一个slave服务：

通过和ResourceManager配合，NodeManager负责整个Hadoop集群中的资源分配工作。

NodeManager只负责管理自身的Container，它并不知道运行在它上面应用的信息。负责管理应用信息的组件是ApplicationMaster，在后面会讲到。

ResourceManager主要有两个组件：Scheduler和ApplicationManager。

另一个组件ApplicationManager的功能如下：

ApplicationMaster运行在Container中。

ApplicationMaster的主要作用是 向ResourceManager申请资源并和NodeManager协同工作来运行应用的各个任务 然后跟踪它们状态及监控各个任务的执行，遇到失败的任务还负责重启它。

1client向yarn提交job，首先找ResourceManager分配资源，

2ResourceManager开启一个Container,在Container中运行一个Application manager

3Application manager找一台nodemanager启动Application master，计算任务所需的计算

4Application master向Application manager（Yarn）申请运行任务所需的资源

5Resource scheduler将资源封装发给Application master

6Application master将获取到的资源分配给各个nodemanager

7各个nodemanager得到任务和资源开始执行map task

8map task执行结束后，开始执行reduce task

9map task和 reduce task将执行结果反馈给Application master

10Application master将任务执行的结果反馈pplication manager。

各个组件的功能

一个Job的提交过程

>

右键 我的电脑/计算机/这台电脑>属性；进入高级系统设置>启动和故障恢复里的设置；取消勾选 将事件写入系统日志；在发生系统错误的时候，就不会有日志产生了。注：过多的系统日志说明电脑当前由于 硬件 or 软件 错误处在异常状态，关闭系统日志并不能根除 运行卡顿 的问题，推荐使用安全软件的系统修复功能，查看是否系统存在异常；另外推荐进入 控制面板\所有控制面板项\管理工具，点击 事件查看器，查看 错误 项的日志描述的是哪方面问题，方便对症下药。

如何收集SparkSteaming运行日志实时进入kafka中

我是攻城师

用过sparkstreaming的人都知道，当使用sparkstreaming on yarn模式的时候，如果我们想查看系统运行的log，是没法直接看的，就算能看也只是一部分。

这里的log分：

（1）Spark本身运行的log

（2）代码里面业务产生的log

spark on yarn模式，如果你的Hadoop集群有100台，那么意味着你的sparkstreaming的log有可能会随机分布在100台中，你想查看log必须登录上每台机器上，一个个查看，如果通过Hadoop的8088页面查看，你也得打开可能几十个页面才能看到所有的log，那么问题来了？

能不能将这个job运行所有的log统一收集到某一个目录里面呢？ 如果收集到一起的话排查log就非常方便了。

答案是很遗憾，在sparkstreaming里面没法做到，因为sparkstreaming程序永远不停机，就算你开启hadoop的log聚合也没用，只有当sparkstreaming程序停掉，hadoop的log聚合才能把所有的log收集到一个目录里面，所以其他的非sparkstreaming程序，比如MR,Spark 运行完后，如果开启log聚合，hadoop会负责把运行在各个节点上的log给统一收集到HDFS上，这样的话我们查看log就非常方便了。

现在的问题是sparkstreaming不能停机，那么还能集中收集log到指定的地方吗？答案是可以的，我们使用log4j收集日志然后异步发送至kafka里面，最后再通过logstash收集kafka里面的日志进入es即可，这样一条龙服务打通之后，出现任何异常都可以非常快和方便的在es中排查问题，效率提升。至于使用logstash从kafka收集到es里面，不是本文的重点，有兴趣的参考散仙前面的文章：>

以上就是关于Yarn聚合日志, 过期清除配置不生效全部的内容，包括:Yarn聚合日志, 过期清除配置不生效、yarn详解、怎么spark on yarn的日志写文件等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！