1. 为什么YARN命令和API不是“查文档就能用”的工具而是集群运维的呼吸节奏很多人第一次接触YARN是在跑一个Spark任务失败后被日志里那句“Application application_1678901234567_0012 failed with state FAILED”卡住——既不知道去哪看这个application到底卡在哪也不知道是资源不够、队列满了还是Container被NodeManager悄悄杀掉了。这时候翻Hadoop官方文档看到yarn application -list、yarn logs -applicationId这些命令照着敲一遍结果返回空、报错、或一堆看不懂的JSON反而更懵了。我带过的几个刚转大数据运维的同事头两周几乎每天都在重复这件事查命令、试参数、看报错、再查、再试……像在黑箱里摸开关。这不是命令本身难而是YARN的命令体系和Rest API天然带着三层“语境依赖”第一层是集群部署语境——你用的是CDH还是Apache原生启用了Kerberos认证还是简单认证ResourceManager是单点还是HA模式第二层是资源调度语境——你用的是CapacityScheduler还是FairScheduler队列配额是按内存硬限还是弹性权重有没有启用NodeLabel或Queue ACL第三层是运行时语境——ApplicationMaster是自己写的还是框架如Flink/YARN Session托管的日志聚合是否开启Timeline Server是否独立部署这三层语境不厘清同一个yarn application -status命令在A集群返回完整状态树在B集群可能只返回“ACCEPTED”就卡住因为AM根本没起来而你还在等RUNNING。所以这篇内容不叫“YARN命令速查表”它是一份基于真实故障场景反向推导的操作手册。我不罗列所有命令参数那该去看man yarn而是聚焦四类高频刚需查状态、捞日志、控生命周期、诊断瓶颈。每个命令都绑定一个典型现场问题告诉你为什么必须加那个参数、不加会掉进什么坑、返回结果里哪几个字段真正决定你下一步该做什么。Rest API部分也一样——不讲HTTP方法和URL结构而是拆解三个最常被误用的Endpoint/ws/v1/cluster/apps的分页陷阱、/ws/v1/cluster/nodes里healthStatus和nodeState的区别、以及/ws/v1/cluster/scheduler中usedResources与absoluteUsedCapacity的数学关系。这些细节文档里不会写但你在凌晨三点排查一个卡死的ETL任务时它们就是你唯一能抓住的绳子。关键词自然嵌入在这里YARN常用命令、YARN Rest API、ResourceManager、ApplicationMaster、NodeManager、CapacityScheduler、日志聚合、资源调度、集群诊断。它们不是标签而是你打开YARN黑箱时手电筒该照向的每一个螺丝口。2. 查状态从“application_开头的ID”到定位具体Container崩溃点的完整链路当开发同学甩给你一个application ID说“任务挂了帮忙看看”别急着敲yarn application -status。这个命令返回的信息量取决于你问得有多准。我见过太多人只输这一条命令看到State: FINISHED, Final-State: FAILED就截图回邮件结果开发反问“失败原因是什么哪个Stage崩的GC日志有OOM吗”——你才发现-status只给状态不给病因。2.1yarn application -status的隐藏字段与必加参数先看基础命令yarn application -status application_1678901234567_0012默认返回约15个字段但其中真正有用的只有5个State、Final-State、Tracking-URL、Diagnostics、Started-Time。重点在Diagnostics——它不是每次都有内容只有AM主动上报错误时才填充。如果为空别指望这里找到线索。必须加的参数是-appStates和-appTypesyarn application -status application_1678901234567_0012 -appStates ALL -appTypes SPARK-appStates ALL强制返回所有状态阶段包括NEW_SAVING、SUBMITTED、ACCEPTED这能帮你确认AM是否成功注册。曾有个案例State显示ACCEPTED但Tracking-URL是http://rm-host:8088/proxy/application_.../点开却报404。加了-appStates ALL后发现实际状态是ACCEPTED但AM-Resource-Request为0说明AM容器根本没被调度——根源是队列default的maximum-capacity被设为0资源池被锁死了。-appTypes SPARK则过滤出Spark应用特有的字段比如spark.driver.memory、spark.executor.instances这些在排障时比通用字段更有指向性。如果你不加返回的Application-Type只是YARN信息颗粒度太粗。提示-appStates参数值不是任意字符串。合法值为ALL、NEW、NEW_SAVING、SUBMITTED、ACCEPTED、RUNNING、FINISHED、FAILED、KILLED。用错会报Invalid application state但错误提示不告诉你哪些值合法只能查源码或反复试。建议直接记ALL最稳妥。2.2 从Application到Attempt再到Container三级穿透式诊断-status只到Application层。要定位具体崩溃点必须下钻两级第一步查Application Attemptyarn applicationattempt -list application_1678901234567_0012返回类似Total number of application attempts :1 ApplicationAttempt-Id State AM-Container-Id Tracking-URL appattempt_1678901234567_0012_000001 FAILED container_e08_1678901234567_0012_01_000001 http://nm-host:8042/node/containerlogs/container_e08_...关键看State和AM-Container-Id。如果State是FAILED说明AM容器自己崩了如果是RUNNING但Application整体FAILED说明AM活着但子任务全挂了。第二步查Container详情yarn container -status container_e08_1678901234567_0012_01_000001这才是真相所在。返回字段中State:COMPLETE或RUNNING但注意COMPLETE不等于成功要看Exit-CodeExit-Code:核心指标。0是正常退出137是OOM被Linux OOM Killer干掉143是被YARN主动kill如超内存限额-1000是Container启动失败Diagnostics: 启动失败时的堆栈比如Exception in thread main java.lang.OutOfMemoryError: Java heap space我踩过最深的坑是混淆Exit-Code和Final-State。某次Exit-Code为143Final-State却是SUCCEEDED——因为AM在Container被Kill后自己捕获异常并上报了成功状态。这时必须看Exit-Code而不是信Final-State。2.3 Rest API替代方案/ws/v1/cluster/apps/{appid}的深度解析命令行适合快速交互但自动化脚本或监控系统必须用API。对应yarn application -status的是GET http://rm-host:8088/ws/v1/cluster/apps/application_1678901234567_0012返回JSON中以下字段比命令行更丰富amContainerLogs: 直接给出AM日志URL格式为http://nm-host:8042/node/containerlogs/container_e08_.../application_.../syslogdiagnostics: 比命令行更长包含AM启动时的完整JVM参数和环境变量快照startedTime,finishedTime,elapsedTime: 精确到毫秒用于计算SLA达标率但API有严重陷阱默认不返回finalStatus字段。必须显式加参数GET http://rm-host:8088/ws/v1/cluster/apps/application_1678901234567_0012?anonymoustruefieldsfinalStatus,diagnosticsanonymoustrue是绕过Kerberos认证的调试参数生产禁用fields指定返回子集否则大JSON解析慢且网络开销高。很多监控脚本没加fields结果一次请求拉回2MB JSON把Prometheus抓取搞垮。注意/ws/v1/cluster/apps的分页参数limit和from极易误用。limit100不是取前100个App而是取状态为RUNNING的前100个默认statesRUNNING。要查所有App必须显式传statesALL否则漏掉大量FINISHED/FAILED任务。3. 捞日志为什么yarn logs经常返回“Log Not Available”以及三套兜底方案yarn logs -applicationId application_1678901234567_0012是新人最常敲的命令也是抱怨最多的——90%的情况返回Log not available at /tmp/logs/yarn/logs/application_1678901234567_0012 Log aggregation has not completed or is not enabled.这不是命令错了而是YARN日志聚合机制的默认行为在“保护”你日志聚合是异步的且默认关闭。AM和Container的日志先存在各NodeManager本地磁盘路径如/var/log/hadoop-yarn/containers/...再由后台线程定期上传到HDFS。这个过程可能耗时数分钟期间yarn logs必然失败。3.1 日志聚合开关与配置验证检查是否启用聚合看yarn-site.xml两个关键属性property nameyarn.log-aggregation-enable/name valuetrue/value /property property nameyarn.log-aggregation.retain-seconds/name value604800/value !-- 7天 -- /property但光配置true不够。还必须确认HDFS路径可写yarn.nodemanager.remote-app-log-dir默认是/tmp/logs需确保该HDFS目录存在且yarn用户有写权限。曾因HDFS配额满导致日志上传静默失败。NodeManager服务重启修改yarn-site.xml后必须滚动重启所有NodeManageryarn logs才生效。只重启ResourceManager无效。验证聚合是否工作用这个命令yarn logs -applicationId application_1678901234567_0012 -am ALL-am ALL表示拉取所有AM尝试的日志包括失败重试的。如果返回日志内容说明聚合已通如果仍报错检查yarn.nodemanager.log-dirs本地路径磁盘空间——这是另一个隐形杀手/var/log分区满会导致日志写本地失败进而无法上传。3.2 三套兜底方案当聚合失效时如何抢回日志方案一直连NodeManager查本地日志最快从yarn application -status拿到Tracking-URL如http://nm-host:8042/node/containerlogs/container_e08_.../application_.../stdout。这个URL本质是NodeManager的Web UI接口只要NM进程活着就能实时访问。缺点是需知道具体NM主机名且跨集群时DNS可能不通。方案二用hdfs dfs -cat读HDFS聚合日志最稳聚合日志最终存于HDFS路径由yarn.nodemanager.remote-app-log-diryarn.nodemanager.remote-app-log-dir-suffix拼成。典型路径hdfs dfs -cat /tmp/logs/yarn/logs/application_1678901234567_0012/**会匹配container_e08_.../stdout、container_e08_.../stderr等。注意/tmp/logs是默认路径生产环境常改为/var/log/hadoop-yarn/aggregated-logs需查配置确认。方案三SSH到NodeManager机器查磁盘日志终极手段当HDFS不可用或聚合完全失败时登录任一NM节点# 找到该Application的Container目录 find /var/log/hadoop-yarn/containers -name *application_1678901234567_0012* -type d # 进入后查看stdout/stderr cat stdout stderr/var/log/hadoop-yarn/containers是yarn.nodemanager.log-dirs的默认值。此方案快但侵入性强需运维权限且日志可能已被logrotate轮转。实操心得我写了一个一键诊断脚本yarn-log-rescue.sh按顺序执行先调yarn logs失败则自动curlNM Web UI再失败则hdfs dfs -ls查HDFS路径最后输出SSH命令模板。脚本里硬编码了公司内部NM主机名列表和HDFS路径新人复制粘贴就能用。这种“傻瓜化”设计比教一百遍原理更有效。4. 控生命周期kill、moveToQueue和updatePriority背后的资源博弈逻辑YARN不是无脑杀进程的工具。yarn application -kill看似简单但执行时机和后续影响直接决定集群资源利用率。我管理的一个中型集群200节点曾因误用-kill导致连续三天资源碎片化——任务被杀后其占用的Container未被及时回收新任务排队等待而旧Container的内存还在NodeManager上挂着直到心跳超时默认10分钟才释放。这10分钟里集群显示“资源充足”实际“有资源不能用”。4.1yarn application -kill的三种执行模式与选择依据命令本身只有一种写法但背后有三种底层行为取决于Application当前状态AM已启动StateRUNNING发送KILL事件给AMAM收到后自行清理子Container并上报KILLED。这是最干净的方式资源秒级释放。适用场景Spark Streaming作业卡死AM还在心跳。AM未启动StateACCEPTEDResourceManager直接取消调度请求不通知任何组件。资源立即释放但AM进程从未存在。适用场景提交后发现参数写错AM还没拉起。AM已崩溃StateFAILED/KILLED命令无效返回Application not found。此时需用yarn application -list -appStates FAILED找残留记录再手动清理HDFS上的聚合日志目录。关键判断依据是yarn application -status返回的State字段。不要凭经验猜必须查。曾有同事看到Tracking-URL能打开就认为AM活着结果-kill后AM没响应资源卡住——因为Tracking-URL是RM生成的静态链接AM崩溃后URL依然有效只是点开会404。4.2yarn application -movetoQueue动态调队列的边界与风险这个命令常被当作“优先级加速键”但实际是双刃剑。语法yarn application -movetoQueue application_1678901234567_0012 -queue high_priority前提条件极其苛刻目标队列high_priority必须在capacity-scheduler.xml中定义且state为RUNNING当前队列和目标队列必须属于同一父队列。例如root.default不能移到root.high_priority除非root是父队列默认是移动后Application的usedResources会计入新队列但已分配的Container不会迁移。新Container按新队列配额调度老Container继续运行直到结束最大风险是资源抢占。假设default队列配额30%high_priority配额70%。一个在default运行的大任务占集群50%资源被移到high_priority瞬间high_priority使用率从20%飙到70%触发CapacityScheduler的抢占逻辑——它会Kill其他high_priority队列的小任务腾出资源给这个大任务。结果是你想加速一个任务却让十个任务陪葬。因此我们团队定下铁律-movetoQueue只允许用于StateACCEPTED的任务AM还没起且目标队列剩余配额 该任务申请资源的150%。用脚本自动校验# 先查目标队列剩余资源 curl -s http://rm-host:8088/ws/v1/cluster/scheduler | \ jq .scheduler.schedulerInfo.queues.queue[] | select(.queueNamehigh_priority) | .resources.used # 再查任务申请资源从-status的AM-Resource-Request解析4.3yarn application -updatePriority数字游戏背后的调度器真相-updatePriority命令形同虚设。YARN的CapacityScheduler和FairScheduler都不支持运行时修改Application优先级。执行后返回Success但yarn application -status里Priority字段不变调度器也完全无视。这是官方文档埋的坑——它只对FIFO Scheduler有效而FIFO在生产环境基本不用太简单无法多租户。真正影响调度顺序的是Application提交时间戳和队列内资源竞争。想让任务“插队”唯一可靠方式是提交到更高配额的队列如-queue high_priority在capacity-scheduler.xml中为该队列设置minimum-user-limit-percent100禁止用户间资源共享确保该队列maximum-capacity足够大避免被其他用户挤占踩坑实录某次紧急修复运维同学执行-updatePriority 10后信心满满结果任务在队列里排了40分钟。查/ws/v1/cluster/scheduler发现high_priority队列usedResources已达98%而maxCapacity是100%但absoluteUsedCapacity绝对使用率计算公式为used/max98/1000.98未触发抢占。根本解法是调高maxCapacity到120释放弹性空间。5. 诊断瓶颈从yarn node -list到/ws/v1/cluster/metrics的立体监控视图当用户抱怨“集群变慢了”别急着查CPU。YARN的瓶颈从来不在单一维度而在资源、网络、磁盘、调度策略四者的耦合效应。我见过最诡异的案例集群CPU平均负载30%但任务排队时间从1分钟涨到15分钟。最后发现是NodeManager的yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage被设为90%而某台NM的/var/log分区恰好90.1%满导致该NM被标记为UNHEALTHY所有新Container拒绝调度到它上面——200台机器突然少1台排队雪崩。5.1yarn node -list不只是看State更要盯Health-Status命令yarn node -list -all返回表格中State列有RUNNING、DECOMMISSIONING等但致命字段是Health-StatusHealthy一切正常Unhealthy磁盘或内存健康检查失败如/var/log满、/tmp满UnknownNodeManager进程僵死但心跳未超时常见于GC停顿Health-Status为Unhealthy时Node-Http-Address列的端口如nm-host:8042通常打不开因为NM进程已停止响应HTTP请求。此时必须登录该机器查yarn-nm进程和磁盘ps aux | grep nodemanager df -h /var/log /tmp修复后NM会自动恢复Healthy状态无需重启。但若State是DECOMMISSIONING则需手动yarn rmadmin -refreshNodes刷新节点列表。5.2/ws/v1/cluster/metrics读懂集群水位的五个黄金指标这个API返回JSON核心是clusterMetrics对象。新手只看totalMB和availableMB但真正决定性能的是以下五个衍生指标指标计算公式健康阈值业务含义资源碎片率(totalMB - usedMB) / totalMB - availableMB / totalMB 15%可用资源分散在小块内存中大任务无法分配Container密度numContainers / totalNodes 50单节点Container过多网络/磁盘IO争抢AM存活率numActiveApplications / (numActiveApplications numCompletedApplications) 5%大量AM崩溃反映代码或资源配置问题心跳延迟中位数median(nodeHeartbeatIntervalMs) 3000msNM与RM网络延迟高调度指令下发慢日志聚合延迟currentTimestamp - lastAggregatedLogTime 300000ms (5min)日志上传慢影响故障定位速度这些指标不能靠肉眼算我用Python脚本每5分钟抓取一次存入InfluxDBGrafana画看板。当“资源碎片率”曲线突升我就知道该强制yarn rmadmin -refreshQueues刷新队列配额释放被小Container碎片占据的内存。5.3yarn top实时进程视角下的隐形杀手yarn top是YARN版的top命令但它显示的不是Linux进程而是YARN Container的资源消耗快照。运行后界面类似YARN Top - 12:34:56, up 3 days, 2:15, 200 active nodes: Node-Id Node-State Containers Memory-Usage CPU-Usage nm-host:8041 RUNNING 42 128.5 / 256GB 12.3% / 32 ...关键在Memory-Usage列128.5 / 256GB表示该NM上所有Container已用内存128.5GB总可用256GB。但注意——这个“可用内存”是YARN配置的yarn.nodemanager.resource.memory-mb不是物理内存。如果配置为256GB但物理内存只有192GBLinux OOM Killer随时可能干掉Container。所以yarn top真正的用途是交叉验证当yarn node -list显示某NMHealth-StatusUnhealthy立刻yarn top看它的Memory-Usage是否接近100%。如果是说明是内存超配如果不是再查磁盘。这种“命令组合拳”比单看一个命令高效十倍。经验技巧yarn top默认每3秒刷新太耗资源。生产环境我改成yarn top -interval 3030秒刷一次配合watch -n 30 yarn top -interval 30既看清趋势又不压垮RM。6. Rest API安全实践为什么curl直接调用/ws/v1/cluster/apps在生产环境是危险操作Rest API是自动化基石但裸调用如同在雷区跳舞。我负责的集群曾因一个监控脚本curl http://rm-host:8088/ws/v1/cluster/apps?statesALL每10秒执行一次导致ResourceManager GC频繁响应延迟从200ms飙升到5s所有yarn application命令超时。问题不在脚本逻辑而在API设计本身的“贪婪性”。6.1/ws/v1/cluster/apps的三个性能炸弹炸弹一statesALL的隐式开销statesALL不是简单返回所有状态的应用而是触发ResourceManager扫描全量Application历史数据库。YARN默认将ApplicationHistory存储在内存yarn.resourcemanager.applicationhistory.enabledfalse时ALL状态会强制加载所有历史记录到内存。一个运行半年的集群历史App超10万ALL查询直接OOM。炸弹二limit参数的误导性limit100看似安全但它只限制返回结果数量不限制扫描范围。如果集群有50万Applimit100仍需扫描全部50万条记录才能选出前100个CPU吃满。炸弹三缺失startedTimeBegin的暴力扫描不加时间过滤API默认查所有时间。正确姿势是GET /ws/v1/cluster/apps?statesRUNNINGlimit100startedTimeBegin1678901234000startedTimeEnd1678901294000startedTimeBegin/End单位是毫秒限定最近1分钟提交的应用扫描量从50万降到百级别。6.2 Kerberos认证下的API调用范式生产集群必开Kerberos裸curl会返回401。正确流程是三步获取票据kinit -kt /etc/security/keytabs/yarn.service.keytab yarn/rm-hostREALM提取Tokencurl -k --negotiate -u : https://rm-host:8090/ws/v1/cluster/info响应头含Set-Cookie: hadoop.auth...带Token请求curl -b hadoop.auth... https://rm-host:8090/ws/v1/cluster/apps但步骤2的--negotiate在某些Linux发行版如CentOS 7需安装krb5-workstation包且curl版本必须≥7.38。更稳的方案是用curlkinitcookiejar# 第一次请求获取cookie并存文件 curl -k --negotiate -u : -c /tmp/yarn-cookie https://rm-host:8090/ws/v1/cluster/info # 后续请求复用cookie curl -k -b /tmp/yarn-cookie https://rm-host:8090/ws/v1/cluster/apps?statesRUNNING6.3 生产API调用的黄金守则基于血泪教训我们制定了四条铁律守则一永远用fields参数裁剪返回体?fieldsappId,state,user,finalStatus,startedTime,finishedTime去掉diagnostics等大字段JSON体积从2MB压到2KB。守则二limit必须配合startedTimeBegin单独limit是定时炸弹时间范围是保险丝。守则三读写分离GET /apps用于监控PUT /apps/{id}/statekill等写操作必须走独立高权限账号且加审计日志。守则四熔断机制脚本中加入超时和重试curl --max-time 10 --retry 2 --retry-delay 1 ...避免单点故障拖垮整个监控链路。最后分享一个真实技巧我们用Nginx做API网关在location /ws/v1/cluster/apps里加limit_req zoneyarnapi burst5 nodelay;限制每秒最多5次请求。超出的请求直接503保护RM。这个配置比改YARN源码简单十倍且所有客户端无感。7. 附一份可直接落地的YARN运维检查清单含命令与API这张清单不是理论而是我每天晨会前花5分钟执行的实操项。它覆盖了90%的突发故障场景且每一条都标注了“命令行”和“API”两种执行方式适配不同环境。检查项命令行操作Rest API操作预期结果异常处理1. RM服务健康curl -I http://rm-host:8088/ws/v1/cluster/infoGET /ws/v1/cluster/infoHTTP 200haState为ACTIVEHA模式或NOT_AVAILABLE非HA若404检查RM进程ps aux | grep ResourceManager若503查RM日志tail -100 /var/log/hadoop-yarn/yarn-yarn-resourcemanager-*.log2. NM在线率yarn node -list -all | grep -c RUNNINGGET /ws/v1/cluster/nodes?statesRUNNING数值 ≥ 总节点数×0.95若低于阈值用yarn node -list -all查Health-StatusUnhealthy的节点登录后df -h查磁盘3. 队列资源水位yarn queue -status rootGET /ws/v1/cluster/schedulerusedCapacitycapacity×0.8且absoluteUsedCapacity 0.95若超限用yarn application -list -queue queue -appStates RUNNING查占用大户评估是否-movetoQueue4. 运行中任务数yarn application -list -appStates RUNNING | wc -lGET /ws/v1/cluster/apps?statesRUNNINGlimit1数值 ≤ 集群总vCore×2经验值若超标用yarn top查Container密度密度50则需扩容或优化任务并行度5. 日志聚合延迟hdfs dfs -ls /tmp/logs/yarn/logs/ | tail -10GET /ws/v1/cluster/metrics最新目录名中的时间戳距当前5分钟若延迟查yarn.nodemanager.log-aggregation.roll-monitoring-interval-seconds配置默认3600秒可调小至600这张表印在我们运维组的工位墙上。新人入职第一天导师就指着它说“记住YARN没有玄学只有这五件事。每天扫一遍80%的问题在发生前就被掐灭。”我自己用这个清单十年从最初手忙脚乱查文档到现在闭着眼都能敲出命令。技术没有捷径但有路径——把每一次故障变成 checklist 上的一行字就是最扎实的进步。