在之前的内容中，我们深入探讨了 EasyMR 如何利用 Kubernetes 进行部署。大家已经了解到，在 EasyMR 的整体架构中，我们使用 Prometheus 进行节点和服务监控数据的采集、查询和存储。同时，Grafana 作为强大的可视化工具，将 Prometheus 中的监控数据以多样化的方式展示出来。

在本文中，我们将详细探讨在 EasyMR 中如何动态采集 Kubernetes 应用监控数据。

通俗来说，就是我们的 Kubernetes 集群中会有很多 Node/Service/Pod 等资源，这些资源会随着需求规模的变化而动态变化，同一个应用 Pod 的 IP、名称也会随着应用的重启、滚动更新而发生改变。

所以当 Kubernetes 资源创建或者更新时，如果一个个去修改 Prometheus 中的 Job 任务会是一个非常庞大的工作量，因为你无法判断 Pod 重启的时间（Kubernetes 有自己的 scheduler，可能 Pod 当前所在主机 CPU/内存/磁盘压力过大，可能 Pod 达到设置资源限制等等，这些都会导致 Pod 的重新调度）。在这个背景下，我们就需要 Prometheus 拥有服务自动发现的功能。

对于上述无法使用静态采集配置static_configs 和 file_sd_configs 的场景，Prometheus 自身提供了一个解决方案：引入一个服务注册中心。这个注册中心掌握着当前所有监控目标的访问信息，Prometheus 只需要向它询问有哪些监控目标即可。Prometheus 查询到需要监控的 Target 列表，然后轮训这些 Target 获取监控数据。

Prometheus 支持多种服务发现机制：文件、DNS、Consul、Kubernetes、OpenStack、EC2 等，本文以 Kubernetes 服务发现机制为例详细讨论。

在 Kubernetes 下，Prometheus 通过与 Kubernetes API 集成主要支持5种服务发现模式：Node、Service、Pod、Endpoints、Ingress。

不同的服务发现模式适用于不同的场景，例如：Node 适用于与主机相关的监控资源，如节点中运行的 Kubernetes 组件状态、节点上运行的容器状态等；Service 和 Ingress 适用于通过黑盒监控的场景，如对服务的可用性以及服务质量的监控；Endpoints 和 Pod 均可用于获取 Pod 实例的监控数据，如监控用户或者管理员部署的支持 Prometheus 的应用。

Prometheus 使用 pull 模式来获取指标，所以对需要监控的目标应用来说需要暴露/metrics 接口。接下来我们从部署 Prometheus 的步骤开始，以采集 MySQL 的监控信息来具体描述 EasyMR 是如何运用 Prometheus 的服务发现机制的。

由于同一个 Pod 是共享网络跟存储的，所以在部署架构中我们将 MySQL Exporter 作为一个单独的 Container 与 MySQL 的 Container 部署在同一个 Pod 中，只需要将 MySQL Exporter 的监控端口暴露给 Prometheus 的注册中心即可，部分重要配置如下：

能看到 Prometheus 已经动态发现了部署上去的 MySQL 服务暴露的监控数据，状态是 UP，无需手动干预。

经过上述操作，我们可以很轻松地在 EasyMR 页面上看到丰富的 MySQL 监控信息，其余的服务也可以通过类似的步骤完成。

在云原生时代，Promtheus+Grafana 的组合已经成为了可观测性工具中不可或缺的一部分，但是怎么将它们的作用最大化还是需要大家深度去探索。未来 EasyMR 还会在可观测性的其他领域（logging、tracing）做出自己的探索。