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

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

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

传统采集方案的痛点

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

干货|EasyMR 基于 Kubernetes 应用的监控实践_第1张图片

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

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

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

通俗来说,就是我们的 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 匹配规则找到相关的资源对象,最后再对采集过来的指标做二次处理,比如保留、过来、替换等操作。

干货|EasyMR 基于 Kubernetes 应用的监控实践_第2张图片

创建 ServiceAccount/Role/RoleBinding

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

干货|EasyMR 基于 Kubernetes 应用的监控实践_第3张图片

创建 Prometheus Deployment

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

干货|EasyMR 基于 Kubernetes 应用的监控实践_第4张图片 干货|EasyMR 基于 Kubernetes 应用的监控实践_第5张图片

部署 MySQL Statefulset、MySQL Exporter、MySQL Service

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

● MySQL Statefulset

干货|EasyMR 基于 Kubernetes 应用的监控实践_第6张图片

● MySQL Service

在 Service 配置的 annotations 下添加两个配置:

· prometheus.io/port: 9104

· prometheus.io/scrpae: true

干货|EasyMR 基于 Kubernetes 应用的监控实践_第7张图片 干货|EasyMR 基于 Kubernetes 应用的监控实践_第8张图片

查看 Prometheus Targets 配置

干货|EasyMR 基于 Kubernetes 应用的监控实践_第9张图片 能看到 Prometheus 已经动态发现了部署上去的 MySQL 服务暴露的监控数据,状态是 UP,无需手动干预。

查看 EasyMR Grafana 仪表盘

干货|EasyMR 基于 Kubernetes 应用的监控实践_第10张图片

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

结语

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

《数栈产品白皮书》下载地址:https://www.dtstack.com/resources/1004?src=szsm

《数据治理行业实践白皮书》下载地址:https://www.dtstack.com/resources/1001?src=szsm

想了解或咨询更多有关大数据产品、行业解决方案、客户案例的朋友,浏览袋鼠云官网:https://www.dtstack.com/?src=szcsdn

你可能感兴趣的:(大数据)