企业官网建设流程全解析

做 Hadoop 集群运维的人，大概都经历过这样的场面：业务方火急火燎跑过来说任务不跑了，你第一反应不是翻日志，而是打开那个 8088 端口页面，也就是 YARN 集群的 ResourceManager UI。这个界面看起来像个朴素的监控面板，但它其实是整个集群的“前台调度窗口”：节点活着没有、队列剩多少资源、应用卡在哪一步、为什么失败，大部分问题都能在这里快速定位。这篇就专门把它从头到尾拆一遍，不只是告诉你每个 Tab 叫什么，而是讲清楚每个数字背后的含义，以及我们在实际排障时是怎么用这些信息的。

如果你刚接触 YARN，或者一直在用命令行但没养成看 UI 的习惯，这篇文章会很适合你。下面所有内容都基于常见的 Hadoop 3.x 版本页面来讲，不同发行版和版本之间会有轻微的差异，但核心字段和交互逻辑基本一致。

1. 先理解 YARN UI 的定位：不是监控页面，是调度系统的一扇窗

1.1 不同角色看 UI 的侧重点完全不同

YARN 的 ResourceManager UI 不是给“参观”用的，它直接暴露了调度器的内部状态。开发人员打开页面，最关心的是自己的 ApplicationMaster 起来了没有、Tracking UI 能不能跳转到 Spark 或 Flink 的作业页面；运维人员最关心的是节点有没有 Unhealthy、队列资源是不是被打满；管理员则要通过 Scheduler 页面确认队列容量配置是否生效、用户配额是否正确。这三种视角完全不同，所以看 UI 的方式也不同。

我见过不少开发同学打开页面只盯着自己那个 App 的状态，一旦卡在 ACCEPTED 就反复刷新，却不知道去点开队列的 Scheduler 页。其实 YARN UI 的设计逻辑是“从集群到应用、从应用到容器”层层递进的：先看全局仪表盘，再看节点和队列，最后定位到具体 Application 和 Container。只有按这个链路去读页面，排障效率才会高。

1.2 UI 上的数据到底是从哪里来的

很多刚接触集群的人会误以为 UI 是去查数据库或者日志文件，其实不是。RM 页面数据主要来自两个地方：一是 ResourceManager 内存中维护的集群状态，包括节点心跳上报的总资源和已用资源、应用状态机的流转记录；二是调度器内部的数据结构，比如 Capacity Scheduler 的队列使用量、Fair Scheduler 的公平份额等。

NodeManager 会周期性向 RM 发送心跳，默认间隔是 1 秒左右，心跳里携带节点上每个容器的最新状态和资源使用情况。RM 收到之后把它并到内存状态里，UI 每次刷新时再重新渲染。这里就有一个隐含意义：你看到的页面其实是“RM 视角”的世界，不是真实机器的最终状态。比如一个容器进程已经挂了但心跳还没来得及上报，页面上这个容器可能还显示 RUNNING。理解这一点，就不会因为 UI 展示和实际不一致而误判。

1.3 入口和端口：别找错地方

YARN ResourceManager UI 的默认地址是http://<rm-host>:8088/cluster。在启用了 RM HA 的集群里，一般有两个 RM 节点，但只有 Active 的那个提供完整的调度和页面服务。你直接访问 Standby 的 8088 端口时，页面往往只显示集群状态或提示“Standby”，有的版本会自动跳转到 Active RM。所以拿到集群地址后，先确认页面右上角显示的 Active RM 是哪台机器。

另外，8088 端口不要和 Application History Server 的 19888 端口搞混。8088 展示的是当前运行中的任务和集群实时状态，一旦应用结束，关于这个应用的调度信息、AM 地址等就不再由 RM 保留了；而 19888 是历史任务的服务入口，用来查看已经结束的应用的详情和日志。实际排障中经常有人问“为什么这个应用在 8088 上找不到了”，其实就是它已经跑完，应该去 History Server 找。

2. 首页仪表盘：Cluster Metrics 才是高频阅读区

2.1 指标的正确阅读顺序

RM 主页最显眼的部分是 Cluster Metrics，它通常分为几组：Apps Submitted / Running / Pending / Completed / Killed / Failed，Memory Total / Used / Reserved，VCores Total / Used / Reserved，以及 Active Nodes / Unhealthy Nodes / Decommissioning Nodes / Lost Nodes 等节点统计。

很多人一上来就看“还剩多少内存”，我觉得顺序应该反过来：先看应用状态，再看节点状态，最后看资源。因为资源数字只是在某个时间点的快照，而应用状态能够告诉你趋势。比如 Running 应用数量持续下降但 Completed 没有变化，那大概率是有不少应用在反复失败；再点进去看 Failed 和 Killed，结合具体日志基本就能定位问题。

下面是我平时看首页时习惯性的一个阅读顺序表：

2.2 从数字背后读出集群真实状态

只看数字本身意义不大，关键是看数字之间的关系。举几个常见组合：

如果 Used VCores 接近 Total，但 Running 应用数不高，说明不是没有任务，而是有任务占着资源但没在有效计算，典型情况是某个 Spark 作业申请了巨量 Executor 却在空转，或者容器内业务代码卡在外部依赖上。

如果 Reserved 资源长期很高，需要留意。Reserved 是指调度器为了满足某个等待中的资源请求而临时预留出来的资源块，它既不是已分配，也不是已使用。在一个节点上碎片化较严重、或者调度器为了满足本地性要求而等待时，Reserved 可能升高。长期高 Reserved 往往意味着资源分配效率不高，可以考虑检查yarn.scheduler.capacity.reservations-continue-look-all-nodes这类参数，或者调整节点内存与容器最小申请规格。

如果 Unhealthy Nodes 突然增加，最常见的健康检查失败原因是磁盘使用率超过阈值。YARN 默认的 NodeManager 磁盘健康检查器会对本地目录做检查，超过配置比例后节点就被标记为 Unhealthy。这种节点不会消失，除非恢复健康后再次上报心跳，RM 才会把它重新置为 Active。

2.3 Active / Standby RM 的判断

集群启用 HA 后，首页上会明显标出当前 RM 是 Active 还是 Standby。Active 状态的 RM 才能真正调度应用，Standby 只是热备，它的页面数据是不完整的。排查问题时一定要先确认你连的是不是 Active，很多“UI 显示异常”的问题，其实只是因为访问到了 Standby 节点。

有一些运维实践是把 8088 端口挂在一个负载均衡后面，统一对外提供服务。这种做法本身没问题，但最好在负载均衡层做一下指向 Active RM 的检测或路由，否则你随时可能被转到一个不能调度的 Standby 页面上，产生严重的排查误导。

3. 核心 Tab 逐个拆解：Nodes、Applications、Scheduler

3.1 Nodes：节点状态不是只看 Alive 和 Dead

进入 Nodes 页面后，会看到所有 NodeManager 的列表。每个节点有状态、机架、资源、使用的 CPU 和内存等。这里最容易踩的坑是把“节点只有 Alive 和 Dead 两种状态”，其实 YARN 里节点状态要复杂得多：

排障时尤其要注意 Unhealthy 和 Lost 的区别。Unhealthy 是进程还活着、心跳还在，只是自身健康状态不好，YARN 不会把新容器调度上去；Lost 则可能是机器宕机、网络中断或者 NodeManager 进程被 kill 了。对 Lost 节点，如果进程还在，它重新启动后会自动注册回来，不用手动删除。

每个节点行里有一个节点日志链接，通常会跳转到该节点的 8042 端口页面，也就是 NodeManager 的 Web UI。在 RM 页面看到节点 Unhealthy 时，直接点进去看 NodeManager 页面，能更快确认是磁盘问题还是健康脚本问题。

3.2 Applications：状态机和字段含义是关键

Applications 页面是所有排障的核心入口。它默认显示运行中的应用，也可以通过过滤条件看 Pending、Failed、Killed 等不同状态。列表里常见的字段包括 Application ID、User、Name、Application Type、Queue、StartTime、FinishTime、Progress、FinalState、Tracking UI、Diagnostics。

很多人在这个页面只关注自己那个 App 的状态，却忽略了两个非常重要的字段：Queue和Diagnostics。Queue告诉你这个应用被提交到了哪个队列，这决定了它可用的资源范围；Diagnostics字段则直接给出了应用为什么失败或为什么还没启动的概要信息。比如 AM 容器反复被杀、资源不足、队列没有可用容量，这些问题往往在 Diagnostics 里一句话就能点破。

YARN 应用有一个状态机：NEW → NEW_SAVING → SUBMITTED → ACCEPTED → RUNNING → FINISHED / FAILED / KILLED。UI 上显示的 Success、Failed 等是“最终状态”，而State才是应用当前状态。排查时要区分这两者：一个应用可能 State 是 RUNNING，但 FinalState 是空；如果 State 是 FAILED，页面通常还会给出失败阶段和原因。

点进某个 Application ID 后，会看到更详细的信息：AM 所在节点、申请的资源规格、Container 列表、Resource Requests 等。如果任务已经结束，Tracking UI 会跳转到 History Server，这时候就可以去看任务的聚合日志和各个 Container 的详细日志。

3.3 Scheduler：容量队列怎么读才不出错

Scheduler 页面是运维和管理员最需要认真研究的页面。如果是 Capacity Scheduler，会看到一棵队列树，每个队列有 Capacity、Used Capacity、Max Capacity、Max Applications、Max AM Resource 等字段。

这里有个很常见的误解：Capacity显示的是这个队列相对于“父队列”的容量占比，而不是相对于整个集群的占比。根队列下一般有多个子队列，根队列容量是 100%。如果一个子队列 Capacity 是 50%，同时它下面又有一个叶子队列 Capacity 是 50%，那这个叶子队列实际能用到集群总资源的 25%。看 Scheduler 页面时，要把树形结构一层一层算清楚。

用量怎么判断？主要看Used Capacity和Max Capacity。如果某个队列的 Used Capacity 已经达到 Capacity 设定的上限，说明这个队列“额度”用完了，新提交到这个队列的应用只能等。如果 Used Capacity 还没到 Capacity，但应用还是卡着，就要看Max AM Resource或Max Applications这类限制条件，它们会单独限制 AM 容器资源和并发应用数。

如果是 Fair Scheduler，页面字段会变成 Steady Fair Share、Instantaneous Fair Share、Max Resources、Used Resources 等。Steady Fair Share 是根据权重算出的稳定份额，Instantaneous Fair Share 是考虑了当前活跃应用之后的实时公平份额。看到 Used 明显低于 Fair Share，但应用又跑不动，通常就需要查一下队列里是否有maxResource、用户或者应用级别上下限限制。

3.4 Tools、Configs 和其他入口：容易被忽略的小细节

RM 页面顶部通常还有 Tools、Configs 这类入口。Configs 页面可以查看当前生效的配置值，排障时非常有用，比如确认yarn.scheduler.maximum-allocation-mb是多少、队列的${capacity}到底配了没、yarn.resourcemanager.nm.liveness-monitor.expiry-interval-ms是多少等。

Tools 里不同发行版差异较大，有的提供 Resource Usage、JMX 等入口，有的则是一些运维辅助功能。我建议至少学会用 JMX 或 Metrics 入口来查看 RM 自身的 JVM 内存、GC 情况。很多集群 UI 打不开或页面响应慢，其实是 RM 进程自身资源吃紧，这时候光看业务指标是不够的，还要看 JVM 层面的数据。

新版本 Hadoop 还引入了 UI2，页面更现代，能展示时间维度的趋势图，并且在一定程度上支持离线数据浏览。但 UI2 在部分发行版里默认没有启用，或者样式上仍有差异。我的建议是：UI2 可以日常使用，但排障时还是要熟悉旧版 UI 的字段，因为很多社区文档和视频教程仍然基于旧版界面。

4. 实战排查：用界面定位三类高频故障

4.1 应用一直卡在 ACCEPTED 不动

ACCEPTED 表示应用已经被 RM 接受了，但 ApplicationMaster 的容器还没有成功分配。遇到这种状态，先去 Scheduler 页面看队列的Used Capacity和Max Capacity。如果队列资源已经满了，那就不是单个应用的问题，而是整个队列或集群资源不够。

还有一种容易被忽略的情况：队列资源明明有剩余，但Max AM Resource已经用完。Capacity Scheduler 里 AM 资源是单独限制的，默认大约是队列容量的 10% 到 20%。当队列里运行了大量小应用时，AM 会把配额占满，新的应用即使有计算资源也进不来。这时候去 Applications 页面看 ACCEPTED 状态的应用有多少，很快能判断出是不是这个原因。

最后一个可能性是资源碎片。比如集群总内存还有 20GB，但每个节点的可用内存只有 5GB，而应用申请了 10GB 的 AM 容器，调度器等不到一个足够大的“连续资源块”，应用就一直处于 ACCEPTED。这种情况下要结合 Nodes 页面看单节点的可用资源，如果很多节点都残留小块不可分配内存，就该考虑调整容器最大规格或者排查是否存在超卖。

4.2 节点反复 Unhealthy 或 Lost

节点 Unhealthy 的排查链路很固定：先在 RM 首页或 Nodes 页确认有哪些节点是 Unhealthy，再点进节点日志链接，看 NodeManager 健康检查结果。最常见原因就是磁盘使用率超过阈值，健康检查脚本会认为磁盘已经不适合继续写入容器日志。

如果节点没到 Unhealthy，而是直接 Lost，优先怀疑网络抖动或进程异常。Lost 的判定依据是 RM 在超时时间内没收到该节点心跳，默认超时是 3 个心跳周期乘以心跳间隔，具体配置是yarn.resourcemanager.nm.liveness-monitor.expiry-interval-ms。节点被标记为 Lost 后，之前分配在它上面的容器会被 RM 当作失败重新调度，如果你的应用没有重启 AM 容器的能力，就会出现大范围 Task 重跑。

这里提醒一个实操细节：不要看到 Lost 就立刻把 NodeManager 进程杀掉重启。如果机器本身没问题，只是短暂网络抖动导致的 Lost，NM 恢复心跳后会自动重新注册，节点会重新变成 Alive。盲目重启反而会打断正在运行的 Container。正确做法是先登录节点看进程、看心跳日志，再决定重不重启。

4.3 应用失败率突增，怎么快速定位

在 Applications 页面把状态过滤到 Failed，查看失败时间是否集中。如果集中在一个时间段，优先去看集群当时是否发生了资源抢占、节点宕机或者队列配置变更。如果失败是零散的，则逐个点开失败应用看 Diagnostics。

常见失败信息有两类：一类是 AM 容器被抢占或杀掉，比如队列 Max Capacity 收缩、其他队列需要资源、节点进入 Decommissioning；另一类是应用自身资源申请过大，超出了yarn.scheduler.maximum-allocation-mb或yarn.scheduler.maximum-allocation-vcores，RM 直接拒绝分配，页面会给出 Resource request 不合法之类的描述。遇到后一种，不要把锅甩给集群资源不够，先看申请规格本身是不是写错了，这也是做大数据平台支持时最常遇到的问题。

如果应用自身带了 Web UI，例如 Spark 或 Flink，Applications 列表里的Tracking UI会给出链接。进入里面看 Executor 或 Task 的失败原因，通常比在 YARN 日志层面更直接。YARN UI 只能告诉你“容器在哪个节点被终止”，具体业务异常还是要靠应用自身的日志。

5. 进阶技巧：UI 与 REST API 对照着用

5.1 页面背后的 JSON 接口

YARN 的 UI 本质上是一层网页壳，它背后的数据接口是 REST API。排障时如果页面加载不出来，或者需要自动化巡检，直接用 REST API 是最可靠的方式。常用接口如下：

需要说明的是，REST API 返回的是最原始的数据，字段可能和 UI 上不完全一一对应，但对自动化脚本非常友好。我平时写巡检脚本时，大部分数据都从这里拿，页面反而只是人工确认时用。

5.2 用 curl 快速抓指标

比如我想知道当前集群节点状态和内存使用情况，可以先这样：

curl -s 'http://rm-host:8088/ws/v1/cluster/metrics' | python3 -m json.tool

返回的clusterMetrics里可以看到 totalMB、usedMB、availableMB、totalVirtualCores、usedVirtualCores 等字段。如果系统里装了jq，可以把输出压缩得更紧凑：

curl -s 'http://rm-host:8088/ws/v1/cluster/metrics' \ | jq '.clusterMetrics | {usedMB, totalMB, usedVirtualCores, totalVirtualCores, activeNodes, unhealthyNodes}'

如果要看调度器队列状态，关键是/ws/v1/cluster/scheduler。Capacity Scheduler 下，队列的 capacity、maxCapacity、usedCapacity 都会返回成带小数点的比例值，注意它是 0 到 1 之间的小数，不是百分数。比如返回 0.25，对应的是 25%，这一步经常有人踩坑。

5.3 日志聚合入口与 yarn logs 命令

UI 上能看到应用状态，但容器级日志还是要配合命令。当日志聚合开启后，可以用：

yarn logs -applicationId application_1234567890_0001 -appOwner hadoop

命令会从集群的日志聚合目录拉取该应用的所有 Container 日志。如果你不指定-appOwner，不少版本会直接报错，所以最好一开始就加上。如果日志聚合没有开启，就只能去 NodeManager 所在节点的logs/userlogs目录下翻，排障难度会明显上升，这也是我建议生产环境务必开启日志聚合的原因。

在应用详情页里，通常能看到一个 Containers 列表，每个 Container 记录中有日志链接。但页面跳转能不能成功，往往取决于 History Server 是否配置正确。优先用命令行拉日志，反而更稳。

5.4 UI 打不开时的替代排查

UI 打不开不代表集群挂了。先确认 RM 进程还在不在，再确认 8088 端口是否监听，然后看防火墙和网络策略是否放行了这个端口。很多“页面白屏”其实是反向代理配置问题，不是 YARN 本身问题。

如果确认 RM 进程正常但页面响应很慢，有可能是 RM 内部状态过大，比如积累了海量历史应用或容器信息。这时候用 REST API 也能绕开页面渲染的开销，直接拿 JSON。我之前就遇到过 RM 页面卡到加载不出图表，但 REST API 还能正常返回数据的情况，通过 API 完成了整个问题定位。UI2 页面如果是静态资源加载失败导致白屏，也可以先设置浏览器缓存或直接访问旧版/cluster路径。

6. 这里有几个我踩过坑后的实操心得

6.1 我常看的字段组合

我现在排查一个“任务跑不起来”的问题时，一般按这个固定组合看：首页的 Unhealthy Nodes 和 Reserved 资源，Scheduler 页面里所在队列的 Used Capacity / Max Capacity，Applications 列表里目标应用的状态和 Diagnostics。这三个组合能覆盖绝大多数资源不足、节点异常、队列限制的问题。

一个值得反复强调的细节是：UI 上的“已完成”应用，不一定表示成功。Completed 包含 FINISHED、FAILED 和 KILLED 三种最终状态，列表里会有一个 FinalState 字段区分。判断业务到底成功没有，一定要看 FinalState，而不是只看 Completed 这个计数。

6.2 我在界面排查时固定的动作顺序

如果到了一个新的陌生集群，我不会急着点各种 Tab，而是先做几个固定动作：第一，确认访问的是 Active RM；第二，在首页看节点状态里有没有 Unhealthy；第三，打开目标应用所在队列的 Scheduler 页面，看容量和最大容量；第四，再回到 Applications 页面看具体应用。这个顺序看起来多一步，但能避免在错误方向上浪费大量时间。

刚接手一个集群时，我还习惯拿 RM 页面和节点真实资源做一次对比。比如页面上显示节点总内存 128GB，但机器实际只有 96GB，那就要检查 NodeManager 的yarn.nodemanager.resource.memory-mb配置。YARN 页面上的资源是注册时上报的配置值，不是从操作系统自动获取的，这个偏差在不少野生产品里都存在。

6.3 界面只是入口，别把 UI 当唯一真相

UI 反映的是 RM 内存里维护的集群视图，所以它和真实世界之间一定有时延，也一定有看不到的层面。比如容器内 JVM 是否在频繁 GC、磁盘 IO 是否跑满、业务代码是否在空转，这些都是 UI 上看不到的。正确姿势是把 YARN UI 当成第一道过滤器，用它快速缩小范围，然后立刻转到节点日志、应用自身监控去确认。

最后再分享一个经验：做集群排障记录时，不要只截图首页，要把 Scheduler 页面的队列参数、应用 Diagnostics、节点状态一起保留下来。很多时候问题不是一次就能复现，完整保留现场数据比事后猜原因有用得多。YARN UI 是运维和开发之间的共同语言，学会读它，能让你在集群出问题时不慌不乱。