前面已经把 Prometheus、Flink 指标和 Grafana 看板都串起来了。到这里，监控链路已经能看到指标，但还缺少最关键的一步：指标异常时不能只靠人工查看，而应该由 Prometheus 主动计算规则并触发告警。 Flink 作

上一篇已经把 Flink 的 JobManager 和 TaskManager 指标暴露给了 Prometheus。到这一步，指标已经能被采集，但是直接在 Prometheus 里写 PromQL 更适合排查问题，不适合长期观察。 监控体系

前面已经把 Prometheus、Node Exporter、Pushgateway 和 PromQL 的基础用法整理了一遍。到这里，Prometheus 已经能采集主机指标和短任务指标，但还没有接入真正的大数据计算组件。 这篇开始把 Fl

前两篇已经把 Prometheus Server、Node Exporter 和 Pushgateway 都接起来了。现在 Prometheus 里至少有三类指标： Prometheus 自身指标。 Linux 主机指标。 Pushgat

上一篇已经把 Prometheus Server 部署起来了，并且让 Prometheus 先采集了自己的 /metrics 接口。这个最小闭环可以证明 Prometheus 的配置、启动、抓取和查询链路是通的，但它还不能回答主机

前面整理 YARN 的时候，更多关注的是 ResourceManager、NodeManager、Application、Container 这些对象本身。通过 Web UI 和命令行可以看到应用状态、队列资源、节点健康和日志，但是这种方式

YARN 命令行是 Web UI 的重要补充，也是日常排查里更稳定的入口。Web 页面适合看整体状态，命令行更适合做三件事：第一，快速确认应用、队列、节点和日志的真实状态；第二，把一次排查过程沉淀成可以复用的脚本；第三，在页面打不开、代理跳

YARN 最容易被误解的地方，是把它当成某一种计算框架的附属品。早期使用 Hadoop 的时候，MapReduce 和集群资源管理绑得太紧，用户提交作业、调度资源、启动任务、查看历史，几乎都围绕 MapReduce 展开。YARN 把这个关

Distributed-Shell 是理解 YARN 应用模型的一个好工具。它本身不复杂：用户提交一个 shell 命令，ApplicationMaster 通过 ResourceManager 申请若干 Container，真正执行命令的

YARN Client 把应用提交给 ResourceManager 以后，真正决定应用如何运行的是 ApplicationMaster。Client 提交的是 ApplicationSubmissionContext，其中包含 AM Co

理解 YARN 应用，第一步不是写 ApplicationMaster，而是先理解客户端到底提交了什么。很多人把 yarn jar 或 hadoop jar 看成一个普通命令：命令发出去，集群就开始跑任务。这个理解太粗。YARN Clien

MapReduce 运行在 YARN 上以后，最容易产生的误解是：YARN 只是把原来的 MapReduce 作业搬到另一套资源管理器上运行。这个理解只对了一半。真正重要的变化，是 MapReduce 不再独占集群调度模型。它退回成 YAR