企业官网建设流程全解析

你打开YARN集群的ResourceManager Web UI，面对那一排标签页，最常见的反应是先看两眼Dashboard，然后一头扎进Applications列表，之后基本就不知道往哪点了。尤其是集群规模上来之后，任务失败、节点异常、队列卡住这类问题，几乎每个都能在这个界面上找到线索，但前提是你得知道每个页面到底在说什么。

这篇文字版的UI地图，就是写给两类人看的：一是刚接手集群、还不熟悉RM页面的大数据开发或运维，二是已经会看基本状态、但遇到问题总感觉“信息就在眼前却抓不住”的人。我会把RM Web UI从上到下、从首页到调度器再到节点日志的页面逐个拆开讲，不光是告诉你“这个字段叫什么”，更会解释“这个数字变了说明什么”“什么情况下该盯哪里”。全程按Apache YARN原生界面来说，发行版（比如CDH、HDP这些）界面做了二次封装，但底层信息和排查逻辑基本一致。

1. 从集群总览到任务状态：UI面板先看这四样东西

1.1 访问入口：端口、路径和主备切换的坑

RM的Web界面默认监听在yarn.resourcemanager.webapp.address配置的地址上，最典型的是0.0.0.0:8088，访问路径是/cluster。看到登录页后，第一眼往往是一块集群总览信息，包括Cluster ID、RM状态是Active还是Standby、节点总数、应用总数、已用内存和核数等等。

这里有个很多人第一次接触HA集群时会踩的坑：如果你的集群配了两个RM，浏览器地址栏里写的是某个固定RM节点的IP或域名，那当这个节点变成Standby时，页面可能会直接白屏、跳转失败，或者显示“This is standby RM. Redirecting...” 但一直转圈。原因是新版RM的Web UI在Standby状态下会自动跳转去Active节点，但很多浏览器对跨端口重定向比较敏感，尤其当两个RM不在同一台机器时。

我的建议是，直接用负载均衡或虚拟IP访问RM Web UI；就算没有LB，也尽量写一个指向Active RM的短域名。判断当前谁是Active，除了看页面左上角的状态标识，更稳妥的是通过REST API查：GET /ws/v1/cluster/info，返回的JSON里有haState字段，那个才是命令行层面最权威的状态。

1.2 首页总览卡片，别只盯着“绿色就是正常”

首页的Cluster Summary区域有一串数字：Active Nodes、Lost Nodes、Unhealthy Nodes、Rebooted Nodes、Shutdown Nodes。这几项里，只有Active Nodes是健康的，其余每一项都不是小事。

• Lost Nodes：NM节点失联，常见于网络分区、NM进程假死或者机器宕机，这类节点上运行中的Container会被RM重新调度；
• Unhealthy Nodes：NM健康检查失败，比如磁盘写爆、负载过高，这类节点会被RM移出调度池，直到恢复健康；
• Rebooted Nodes：NM重启之后重新注册的节点，如果短时间内大量出现，通常说明集群有过大面积重启；
• Shutdown Nodes：NM被正常关闭。

很多运维习惯只看节点总数没变化就放心了，但架不住一种场景：节点数没少，可其中有几十个是Unhealthy状态，这些节点跑不了任何新任务，等于集群可用容量已经悄悄缩水。所以首页这一排数字，你应当每天看一次，尤其是大任务提交前后，主动把Healthy比例记下来。一个经验值：正常情况下Healthy节点占比应当在95%以上，低于这个线就要看是不是某个机架集体出问题。

1.3 Dashboard和菜单栏的隐藏入口

除了总览卡片，RM页面顶部有一排菜单入口：About、Dashboard、Applications、Scheduler、Nodes、Tools，以及针对单应用的列表页面。Tools里面有时会有Configuration和Server信息，这里能直接查看集群生效的配置项，包括队列配置、资源计算参数、ACL权限等。很多调试场景下，你不想登机器翻yarn-site.xml，可以直接在Tools的Configuration页面搜索关键词，比如搜scheduler、queue，比自己上服务器grep快不少。

不过，Dashboard上的信息粒度太粗，真正干活要看的是Applications、Scheduler和Nodes这三块。下面，我按日常排查任务的路径把它们串起来讲。

2. Applications列表：一个作业从提交到退场的全部线索

2.1 状态筛选和那排让人眼花缭乱的标签

Applications页面是大家最熟悉的页面，默认展示活跃应用，包含Application ID、用户、名称、队列、任务类型、状态、进度、最终状态、诊断信息、启动时间等列。初次打开的时候，页面上部有不少过滤条件：状态、用户、队列、标签、是否只显示运行中的任务、按时间范围筛应用等等。

我常用的组合是这个：先按时间范围选最近1小时，然后状态选RUNNING、FAILED、KILLED，这样能快速聚焦“刚出了哪些问题”；等要追某个具体任务时，直接按Application ID搜，如果ID记不住，至少能记住提交用户名或者队列名。

这里要特别提一下YARN应用的状态机。一个作业落地后，大体经过这几个状态：SUBMITTED、ACCEPTED、RUNNING、FINISHED/FAILED/KILLED。很多新手看到应用显示ACCEPTED很久没进入RUNNING，第一反应是集群资源不够，这通常是对的，但不全面——还需要看队列中是否有活动任务占满名额、用户是否被用户限额卡住、是否有足够的AM容器可分配。这些线索都可以在后面的Scheduler页面看到。

2.2 点进一个应用详情页，重点看哪里

点击列表中的应用ID，进入应用详情页。这个页面加载的信息很多，但真正要紧的是三块：

• 应用级别信息：用户、队列、当前状态、诊断信息（Diagnostics）、提交时间、启动时间、完成时间。注意，不是所有状态下诊断信息都有内容，但如果应用FAILED或KILLED，诊断信息里十有八九写着为什么被终止。比如常见的Application is shutdown by the scheduler、或者AM container was killed，这些字符串对定位问题有决定性的方向指引；
• Application Master信息：页面上通常会给出AM所在节点的地址、节点的HTTP地址、AM容器的ID和启动命令。你是可以直接点到AM所在节点去查日志的；
• 相关快捷链接：如果集群开了日志聚合，页面上有Logs入口；如果任务类型是MapReduce，还有链接到JobHistory的入口；Spark任务则会跳转到Spark History Server的对应页面。

我见过太多人一进详情页，直接点Logs，结果看到“No logs found”就说日志丢了。其实这里有个前置条件：宿主机上NM是否开启了日志聚合。如果yarn.log-aggregation-enable是false，日志不会上传到HDFS，Logs按钮自然也没内容。更麻烦的是，很多生产集群为了安全默认关闭了日志聚合，这种情况下想看日志得手动去NM节点上的yarn.nodemanager.log-dirs对应目录里找。

2.3 列表页里容易被忽略的“Diagnostics”列

回到应用列表页，我特别想强调的是最后一列Diagnostics。这一列在任务很多、页面被刷得密不透风时，常常直接被横向滚动条挡在屏幕外。可排障时它是优先级最高的信息源，因为YARN已经帮你在进程退出时捕获了大概原因。

举例来说，当某个应用一直FAILED，Diagnostics列可能会提示Application is killed by the scheduler或Queue <queue-name> is full。前者意味着调度器主动杀了你的应用，后者说明队列资源满了导致AM反复被拒绝。拿到这两条，你再往后查的方向就非常明确，而不是漫无目的地翻日志。

另外，如果集群开了Timeline Service（YARN应用时间线服务），列表页还可以按时间维度展示应用的资源使用曲线。这个功能对“任务占了多少资源、是不是发生了资源倾斜”有直观帮助，但很多集群默认没开，不用强求。

我在实际维护中养成的一个习惯是：不管什么任务失败，先截取Applications列表页带Diagnostics列的截图，再进详情页看完整诊断信息和日志入口。这一步做扎实了，至少能把60%的问题定位到“应用层失败”还是“资源层失败”。

3. Scheduler页面：读懂队列配额与资源分配的真相

3.1 队列树视图：叶子队列才是真正的配额单元

Scheduler页面展示的是ResourceManager调度器的实时视图。常见的调度器是Capacity Scheduler，页面上用一棵树的方式，把根队列、子队列、叶子队列逐层展开。每个队列都会显示当前使用量（Used）、配置最大容量（Max），以及百分比等。

很多人看这个页面容易犯一个错误：只盯着根队列或者一级子队列看，发现整体使用率不高就以为集群很闲。实际上，YARN分配资源时是优先在叶子队列里操作的，如果某个叶子队列自己满了，父队列再空也没用。举个例子，根队列下面有A、B两个子队列，A队列整体使用率只有20%，但A下面的两个叶子队列中有一个已经达到了100%，那提交到那个叶子队列上的作业就会一直卡在ACCEPTED状态，而这个状态从整棵树上很难一眼看出来。

所以看Scheduler页面的要点是：按叶子队列查容量和瞬时使用量，并同时看该队列内是否有用户级限制（Maximum Applications per User、Max Resources per User等）。用户配额导致的调度卡顿非常隐蔽，因为队列本身明明空着，但具体某个用户的任务就是起不来。

3.2 两种“卡住”的区分：队列满 vs 应用配额满

在Scheduler页面里，你会看到每个队列和每个用户都有两类资源限制：一类是内存和CPU总量，一类是同时运行的应用数量。我排查任务“提交后一直ACCEPTED不运行”时，通常先看队列资源占用，再看活动应用数量是否触及上限。

• 如果队列Used/Max已经是 1.0，那说明该队列确实满了，你需要等队列里的任务释放资源，或者临时调整队列配置；
• 如果队列资源还有剩余，但页面提示Maximum applications reached，那就不是资源问题，而是该队列或用户的应用数量到了上限。这种情况在生产集群里也不少，尤其是多用户共享队列时，某个人一次提交几百个小任务，直接把人家的名额占满了。

这类信息在Scheduler页面上都有显示，但需要展开每个队列节点。页面上方通常有一排过滤器，可以只显示有活动的队列，也会有一排 “Resources” 汇总，整体查看很方便。顺便说一句，不同的调度器界面细节不一样，但Capacity Scheduler是绝大多数公司用的，先把这个看清是最划算的。

3.3 调度器页面和“抢占”之间的关系

很多文章会提Scheduler页面上的Preemption设置，但对大多数人来说，生产环境默认都是关闭抢占的，至少在一台机器上跑任务时不要让YARN自动杀人。如果你在页面上看到某个队列大量任务状态为KILLED，且诊断信息里带着“preempted”字样，说明你或集群管理员开启了资源抢占。这种情况下，低优先级队列的任务会被调度器强行终止，把资源让给高优先级队列，页面里会看到较高频率的失败记录。

我说这个是想提醒大家：Scheduler页面不是只看“队列满没满”，它同时反映了整个调度策略设计的合理性。比如你规定了“实时任务队列可以抢占离线任务队列的资源”，那页面上离线队列的任务失败就不是bug，而是你制定的策略在生效。区分这两者，是运维排障时避免误判的重要基础。

4. Nodes与日志：定位节点异常和容器日志的关键入口

4.1 Nodes页面里的节点状态列

Nodes页面列出所有注册到RM的NodeManager节点，每行包含Rack、节点状态、节点地址、节点HTTP地址、运行中的容器数、内存使用、虚拟核数使用等。这个页面本身不复杂，但它承担着一个很重要的功能：快速识别哪些机器有问题。

节点状态分为Active、Unhealthy、Lost、Rebooted这几种。Active当然最好，Unhealthy意味着健康检查失败，Lost意味着节点彻底失联。你在这个页面里点开一个节点的详情，能看到Last Update时间、Health Report（健康检查报告），以及该节点上各容器的情况。

健康检查很值得一提。NM的默认健康检查机制主要看磁盘可用空间、某些关键目录是否可写等。生产环境里很多公司会挂自定义脚本，把CPU负载、内存余量、inode使用率这些也纳入检查。配置项是yarn.nodemanager.health-checker.script.path，脚本返回非零或输出ERROR信息时，NM会被标记为Unhealthy，并停止接收新容器。但注意，Unhealthy节点上正在运行的容器不会被立刻杀掉，RM会等待AM本身判断是否需要重新调度。这个细节对排查“任务明明失败了很多次，节点却一直没有重启”很有用。

4.2 穿越到NM页面看单个节点日志的路径

Nodes页面有一个关键入口：节点列表里的Node HTTP Address列，点击后会跳到对应NM的Web UI，默认端口一般是8042。这里能看到该节点上运行的所有容器列表，以及每个容器的日志入口。如果日志聚合没开启，这个页面就是你看日志的主战场。

我有一次排查一个长期挂在某台机器上的MapReduce任务，就是从RM节点的Nodes页面点进去，看到该节点的物理内存使用率超过80%，然后顺藤摸瓜找到某个容器正在疯狂刷日志，把磁盘打满，最终导致该节点上所有任务OOM或者执行超时。如果没有这个穿越入口，你要先找到机器IP再SSH上去，效率差很多。

另外要留意：如果你开了日志聚合，点击容器日志通常会跳到HDFS上聚合日志的页面；如果你没开，点击后一般直接显示容器在本地的日志文件内容。这两者的差别，决定了你排查时是看历史日志还是只能看当前进程日志，搞清楚之后才不会对着空页面发呆。

4.3 节点黑名单和排障联动

RM还有一个隐性机制叫“节点黑名单（Blacklisting）”。当一个节点上容器反复启动失败时，RM会把该节点加入黑名单，在一段时间内不再为新应用分配容器。这个机制不会大张旗鼓地出现在UI上，但如果你点开一个失败应用的详情，诊断信息偶尔会提到某个节点被排除在外。

排查这类问题时，最容易绕弯的地方在于：你以为任务失败是代码bug，实际上是同一批节点反复出问题导致任务被反复调度然后失败。此时应该做的事是同时打开Nodes页面，筛选出处于黑名单或频繁出问题的节点，确认这些节点的健康状态和系统资源。UI的Nodes页面虽然没有专门的“黑名单”列，但通过按节点名字排序，观察哪些节点的任务失败数集中，也能判断出规律来。

5. 一次真实排障：UI信息如何一步步帮我找到问题根源

5.1 场景：凌晨批处理任务集体失败，但节点看起来“正常”

假设你所在的集群，每天凌晨有个大批量的数据清洗任务。某天突然有几十个任务在几乎同一时间失败，Applications列表满屏红色。第一直觉是机器出问题，但你打开Nodes页面，节点总数没变，失联的也没有，看起来都正常。

这时正确的做法是回到Applications列表，先看失败的Application ID之间有没有共同点。比如它们是不是都在同一个用户、同一个队列下？它们的AM是不是都被分配到了同一批节点？如果没有规律的共同点，那就继续往下看诊断信息。

我遇到过的典型情况是：失败任务的Diagnostics栏里写着Application is shutdown by the scheduler，这个信息直接指向调度器而非代码异常。于是从Applications跳到Scheduler页面，发现某一个离线队列的资源被另一个测试任务占满，而且该队列上积压了大量任务，占用到了上限。再回头看那些失败任务，恰恰全部是在这个队列里。

5.2 顺着Scheduler一眼锁定Unhealthy节点群

再举一个从UI链路定位根因的例子。某次集群出现大面积应用重试，页面看第一眼时所有节点都是Active，我以为只是波峰流量，但重新用“1小时内失败应用”过滤列表，发现失败应用集中在少数几台机器上。点进Nodes页面，选中这些机器对应的NM地址，发现它们均处于Unhealthy状态，健康检查报告显示磁盘写满。

这个情况的向导是：UI上不仔细看会忽略Unhealthy这类“半健康”状态，因为节点列表默认将Active排在前面，Unhealthy节点数量少时容易被挤到后面。我后来养成了一个习惯：在Nodes页面顶部按健康状态筛选，把Unhealthy和Lost单列出来，每次巡检先保证这两类清零。那次磁盘写满的故障，就是因为某个业务日志目录被塞满，健康检查脚本又恰好没校验该目录，结果容器持续报错。

5.3 页面交叉验证的正确顺序

从这两个场景能总结出一个有价值的排查顺序：先看Applications的失败分布和诊断信息，再看Scheduler的队列使用情况，然后回到Nodes确认节点健康状态，最后根据需要进入NM页面或日志聚合页面取实际日志。这套顺序的核心逻辑是：YARN的UI页面本来就有层级关系，调度器决定任务能不能启动，节点决定任务能不能稳定运行，应用内部才轮到业务代码的锅。按这个顺序做筛选，90%的集群级问题都能定位到具体的队列、节点或用户上。

有个反例是，不少同行一上来就点Logs读堆栈，读半天发现是YARN框架把任务杀掉了，根本不是业务代码的问题。这既浪费时间，也容易被表面异常带偏。用UI做问题域筛选，是排障的捷径，不是绕远路。

6. REST API与HTTPS：把UI能力移植到脚本监控里的操作细节

6.1 从Human View到API View的切换

RM Web UI并不是只能通过浏览器看。YARN为集群状态、应用列表、节点信息、队列状态等都提供了REST API，路径默认就是Web页面的根地址/ws/v1/cluster。换句话说，你在页面上看到的那些信息，几乎都能用HTTP请求拿回来，只是JSON结构和HTML页面不一样。

几个最常用的接口：

• GET /ws/v1/cluster/info：集群基本信息，包括RM状态、版本、资源总额；
• GET /ws/v1/cluster/metrics：集群整体指标，比如活跃节点数、内存使用、应用提交数；
• GET /ws/v1/cluster/apps?states=RUNNING：按状态筛选应用列表，也能传user、queue等参数；
• GET /ws/v1/cluster/nodes?states=UNHEALTHY：只拿异常节点；
• GET /ws/v1/cluster/scheduler：调度器队列状态和配额使用。

用curl加管道配合jq，就能快速做一次巡检，比如看看当前所有处于FAILED状态的应用ID和诊断信息：

curl -s 'http://rm-address:8088/ws/v1/cluster/apps?states=FAILED' | jq '.apps.app[] | {id, name, user, queue, diagnostics}'

如果只想查某个队列的当前资源使用率：

curl -s 'http://rm-address:8088/ws/v1/cluster/scheduler' | jq '.scheduler.schedulerInfo.queues.queue[] | select(.queueName=="your_queue")'

这些命令可以放进定时任务里，一旦发现FAILED数量或Unhealthy节点数量超过阈值就报警。说实话，我后来对集群的“监控”多半依赖这类脚本，而不是每天手动刷页面，但脚本的过滤规则、阈值设定，完全源自对UI页面上各字段含义的理解，所以REST API和Web UI是相辅相成的。

6.2 HTTPS_ONLY模式下UI的访问变化

安全生产环境通常会把yarn.http.policy设为HTTPS_ONLY，这时候默认的8088端口的HTTP页面就不再可用，RM的Web UI会改走HTTPS端口，常见的是8090。改动之后，浏览器访问会出现证书不信任的警告页，需要把RM的HTTPS证书导入到客户端的信任库中，或者在内网访问时处理一下证书告警。

如果是走代码调用REST API，也要记得用https://前缀，并关闭或配置SSL证书校验。这部分的细节虽然和“详解UI”的主题听起来关系不大，但实际工作中这是最常被忽略的一环：很多运维页面打不开，第一反应是端口问题，结果发现是配置了HTTPS_ONLY而自己一直在访问HTTP。

6.3 API权限的兜底意识

最后提一句安全边界：RM的REST API默认情况下没有很细粒度的认证控制，只要你网络能到达8088端口，就能读到集群大部分状态。所以在对内网环境开放UI和API时，至少要依赖防火墙限制来源IP，或者叠加集群本身的ACL配置和生产环境的网络隔离策略。我见过不少团队为了方便，把RM UI地址放到办公网里随意访问，结果内部泄漏了大量队列信息和运行中的任务情况。这类问题UI层面没有直观体现，但维护者应该心里有数。

另外一个长期有用的技巧是：把常用查询封装成一个小脚本库，比如yarn-ui-cluster.sh、yarn-ui-apps.sh、yarn-ui-nodes.sh，参数化封装状态和队列。这样即使哪天换了一个新集群，只需要改一下RM地址，其他逻辑可以继续复用，省去了每次敲一长串curl和jq的麻烦。

我在实际使用中发现，YARN集群UI就像一个聚合了“资源调度、任务生命周期、节点健康、日志入口”的中枢面板，很多人用不好它，不是界面藏得深，而是没有把界面信息与YARN的调度原理打通。先把每个页面上字段的含义弄明白，再把它们串成一条问题排查链路，这个UI就能从“看得见”变成“用得着”。每次遇到任务异常时，我都建议先让UI信息帮你缩小范围，再决定上哪台机器、翻哪份日志，这比一上来就到处查日志要高效得多。最后再分享一个小技巧：巡检时坚持把Applications、Scheduler、Nodes三个页面截图存档，一段时间后你会惊讶地发现，很多看起来很随机的问题，其实都呈现着可预测的周期规律。