干货｜EasyMR 基于 Kubernetes 应用的监控实践

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

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

传统采集方案的痛点

在主机模式下，EasyMR 使用 Prometheus 监控的配置主要依赖于 static_configs 和 file_sd_configs。因为在这种部署方案下，节点与应用的稳定性较高，涉及到的变更与不确定性较小，除非出现节点宕机这样的极端情况，我们才需要手动去修改对应采集 Job 配置。

file

但是在云原生时代的背景下，监控作为可观察性实践中的关键部分，相对于传统架构下的系统和应用监控发生了一些重大的变化：

· 微服务和应用容器化导致监控对象和指标的指数级增加

· 监控对象的生命周期更加短暂，导致监控数据量和复杂度成倍增加

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

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

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 的应用。

EasyMR 对 K8S 应用的监控实践

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

创建 Prometheus 配置文件

Prometheus 自动发现的核心之处在于 relabel_configs 的相关配置，首先是通过 source_labels 配置以 _meta 开头的这些元数据标签，声明要匹配的资源，然后通过 regex 匹配规则找到相关的资源对象，最后再对采集过来的指标做二次处理，比如保留、过来、替换等操作。

file

创建 ServiceAccount/Role/RoleBinding

由于 Prometheus 是需要访问 Kubernetes 资源的，而且 Kubernetes 有详细的 RBAC 权限控制机制，所以在部署 Prometheus 之前需要创建对应的账号，并为该账号赋予对应接口的权限。出于安全考虑，EasyMR 只需要获取对应 namespace 的权限，所以我们不需要全局的 ClusterRole 权限。

file

创建 Prometheus Deployment

由于 Prometheus 是需要存储数据的，所以事先需要创建对应 PV，官方建议使用 localpv，这里不做描述。在 Deployment 的配置文件中我们只需指定 PVC 名称即可，这里把关键配置展示出来。

file
file

部署 MySQL Statefulset、MySQL Exporter、MySQL Service

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

● MySQL Statefulset

file