原创

Log Aggregation Status TIME_OUT的缘起

版权声明:本文为博主原创文章,遵循 CC 4.0 BY 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://lidong.blog.csdn.net/article/details/78761603
在spark on yarn运行中,有时会发现spark程序运行完毕后,spark的运行界面没有信息,或者找不到相关的运行信息了,经仔细查看NodeManager UI
,出现如下信息:
Log Aggregation Status TIME_OUT

原来NodeManager可以在应用结束后将日志安全地移动到分布式文件系统HDFS,当应用(application)结束时,用户能通过 YARN 的命令行工具、网页端或者HDFS中来查看这些日志
当打开yarn.log-aggregation-enable为true时,会启用聚合,如果为false,NodeManager会把日志存储在节点本地(${yarn.nodemanager.log-dirs}/application_${appid} )下

日志聚合的相关配置:
yarn.nodemanager.remote-app-log-dir: 这是 NodeManager将日志聚合后存放在HDFS 上的地址.
yarn.nodemanager.remote-app-log-dir-suffix: 日志目录会这样创建 {yarn.nodemanager.remote-app-log-dir}/${user}/{thisParam}
yarn.log-aggregation.retain-seconds: 聚合后的日志文件在多久后被删除, 配置成 -1 或者一个负值不会删除
yarn.log-aggregation.retain-check-interval-seconds: 多长时间去检查一次哪些聚合日志需要删除.
yarn.log.server.url: 应用结束后NodeManager会将网页访问自动跳转到聚合日志的地址, 指向的是 JobHistory上的地址.

回到“Log Aggregation Status TIME_OUT”这个问题上来,如果有1个控制超时的参数就可以解决这个问题了,遗憾的是,hadoop2.8.0版本才出现了下面这个参数,我们来看官方的注释:

<property>
    <name>yarn.log-aggregation-status.time-out.ms</name>
    <value>600000</value>
    <description>
        How long for ResourceManager to wait for NodeManager to report its
        log aggregation status. If waiting time of which the log aggregation
        status is reported from NodeManager exceeds the configured value, RM
        will report log aggregation status for this NodeManager as TIME_OUT
    </description>
</property>

在更低的hadoop版本中如果要修复这个问题,通过打patch即可解决

备注:
要打印出一个给定应用的所有日志, 命令如下
> yarn logs -applicationId <application ID>



展开阅读全文

djyos缘起

01-20

rn 一直不敢公开这篇东西,怕别人笑我,笑一个毫无软件经验的硬件工程师居然不自量力地向uclinux(是uclinux而不是linux)、vworks、wince等巨头们挑战。然而,计算机界是需要奇迹的,也是孕育奇迹的天堂,辍学的盖茨能盖起微软王国,21岁的linus能够成就linux的世界,我、一个多年经验的硬件工程师、为什么就不能撑起嵌入式操作系统的天空!!!rn 自1996年从西电应用物理系毕业后,到2001年底的5年半时间里,我一直是个单纯硬件工程师,而且是一个出色的硬件工程师,也有一些得意的硬件作品。在此期间,软件方面就是用51的汇编写过几个程序,大学学过pascal,看过几天谭浩强的C语言书,仅此而已。在那之前,对于操作系统,全部经历就是安装并使用过windows,连做梦都没有想过自己会写一个操作系统出来。2008年,多事的祖国,多事的秋,毫无征兆地发生了汶川大地震,不能亲赴灾区我在哀伤中继续为djyos奋斗,也算我对祖国、对灾区人民的支持吧!与地震不可预测一样,2001年无端地发生了一件注定要改变中国无操作系统格局的事!在那一年的年底,公司有一个项目,要写一个软件,而我刚刚完成了一个硬件项目,软件方面又刚好人手紧张,于是任务就落到我这个毫无软件经验的人头上了。这个软件要涉及到另一门很高深的学科的许多专业知识,这些专业知识我一无所知。当时公司的软件开发管理水平比较低,没有架构设计、系统设计的说法,一上来就动手写程序,连个设计文档都没有的阶段,也没有任何流程来控制这些。我实际上负责的是软件系统结构方面的工作,以及写一些界面、通信、模块管理和底层驱动方面的代码。当时最大的目的,就是设计一个好的结构,使之能够容纳我写的部分代码和另外一些我一无所知的专业算法程序。抱着谭浩强的那本《C程序设计》教材,痛苦地写了几千行核心程序,为整个软件(超过2万行)划分好了模块,设计了模块之间互操作以及交换数据的架子,然后交给专业工程师添加血肉。不觉中,该软件成了公司最好的软件之一,后来的移植到别的平台,只花了很少的时间,后来被移植到许多型号的产品上,该部分代码根本无需修改。直至今天,公司还没有一个有一点规模的软件模块能做到这点,今天的djyos特别强调软件在相同平台的不同产品间移植,与此有关。我完成这个项目后,就又回到自己的老本行————硬件设计上继续工作。连我自己都没有想到的是,这个软件的设计思想会成为djyos的最原始的萌芽。也正因为我是硬件工程师,所以在djyos的设计中,特别强调并支持软硬件一体设计。rn 后来,由于要上网络,公司决定用vxworks,于是要把现有代码移植到vxworks,在购买vxworks后,接受了windriver公司为期2天的培训,这是我首次接触嵌入式操作系统,说是培训,其实效果很差,那些操作系统的专业名词对我来说就如同天书。说是移植,其实就是在人家写好BSP,安装好操作系统的情况下,做一个大任务,把原来的main函数改个名,做任务入口函数而已,啥也没干。这就是迄今为止我使用实时操作系统做项目的全部经验。rn 因这个项目,我对软件产生了一些兴趣,开始看一些操作系统的书,并把邵贝贝翻译的《UC/OS-II嵌入式实时操作系统》看了一遍,了解了实时操作系统的设计原理。也就是看书,但没有实际写过ucosii下运行的例程。因与工作无关,也就没有压力和动力,东瞧瞧西瞅瞅而已。后来,因为要做一个linux下的PCI卡驱动程序,根据网上的推荐,买了《LINUX设备驱动程序》和《LINUX内核设计与实现》两本书看,但写出来的驱动程序老有bug,后来这个项目还被取消了,算是学了点linux的皮毛,就没有下文了。这就是我做的与桌面操作系统内核相关的软件开发的全部经历。rn 时间转眼到了2004年,发生了一件注定值得纪念的事,又一个比原来大的软件项目想让我试试。我当然地在第一个项目为蓝图进行系统架构构思,但不幸的是,这个项目还没有开始就夭折了。然而,我的设计思想可没有因此夭折,我看到了它的闪光点,经搜索发现目前并无操作系统使用相同的设计思路(也许我的搜索不全面),决定用业余时间把它用操作系统的形式实现,并把我的设计思想写成书,于是,就有了今天的djyos和《都江堰操作系统和嵌入式系统设计》一书。也就有了这5年的苦旅,说实话,当初是低估了这东西的复杂度和工作量,否则的话,我是否有这种勇气还很难说。rn 开发历程是艰难而且曲折的,由于是一个全新的设计思想,现成的东西中没有什么可参考的,一切都需要自己从头探索,自己缺乏软件经验也成了前进路上的拦路虎,开始的时候抱的是谭浩强的《C程序设计》,但很快那本书不够用了,根据网络的推荐,换成《C Primer Plus中文版》了,这本书我电子版和纸版都有。我看书有个习惯,先找电子版,发现是本好书的话,一定会买一个纸版的,即使从来不看,以示对作者的尊重。在开发的过程中,多次大规模地推翻原来的方案,你现在看到的是2万行代码,408页文档,实际上的工作量,你乘个1.5后就差不多了。rn 5年怀胎,一朝分娩,让我们共同呵护djyos,期待他能茁壮成长。rn rn djyos代码和文档,全部在 www.djyos.com 中共享,去看看吧,你会有所收获的。rn 论坛

没有更多推荐了,返回首页