理解OpenShift（7）：基于 Prometheus 的集群监控

理解OpenShift（1）：网络之 Router 和 Route

理解OpenShift（2）：网络之 DNS（域名服务）

理解OpenShift（3）：网络之 SDN

理解OpenShift（4）：用户及权限管理

理解OpenShift（5）：从 Docker Volume 到 OpenShift Persistent Volume

理解OpenShift（6）：集中式日志处理

理解OpenShift（7）：基于 Prometheus 的集群监控

 

** 本文基于 OpenShift 3.11，Kubernetes 1.11 进行测试 ***

 

和日志系统同样，监控系统也是平台一大不可或缺的组成部分。在敏态的OpenShift 和 Kubernetes 平台之中，运行平台组件及业务应用的Pod 时刻都处于变化之中，并且数量可能会巨大。在这种状况下，对监控系统的要求会更高。当前，基于 Prometheus 和 Granfana 的监控系统，对于OpenShfit 和 Kubernetes 这样的平台来讲，是一个比较好的选择。可是，Prometheus 自己就至关复杂，再加上复杂的容器云平台，复杂性成倍提升。本文试着对它的原理进行梳理，但确定没法面面俱到。更多更详细的信息，还请查阅更多资料。

1. Prometheus 概述

关于 Prometheus 的文档很是多，这里不会详细说明，只是一个概述。

它是什么：

• 一个带时序数据库（TSDB）的监控系统。SoundCloud 在2012年开始开发，2015年开源，如今是 CNCF 继 Kuebernetes 以后的第二个项目。
• 经过拉取（pull）方式收集测量数据，并将其保存在TSDB 中。
• 提供计量数据查询功能，实现了相似于 SQL 的查询语法PromSQL。
• 提供告警功能，能根据已定义的告警规则向外输出告警。
• 虽然它本身实现了一个面板，但还比较简陋。如今主流的作法是将它和 Grafana 结合，由 Grafana 提供面板。

它不是什么：

• 它不处理日志或跟踪（tracing），只处理计量数据。
• 它自己不是专门的具备良好扩展性的持久存储。它自身的存储，被设计为用于短期保存数据。

它的基本架构：

关于架构的简单说明：

• 左侧是被监控的对象（target）。若是监控对象自身提供知足Prometheus要求的测量数据的 HTTP API（好比cAdvisor，https://github.com/google/cadvisor），则能够直接和 Prometheus 对接；不然，能够借助 exporter 来实现对接（好比 node exporter，https://github.com/prometheus/node_exporter）。exporter 会从应用中获取测量数据，而后提供HTTP API，再和 Prometheus 对接。
• 中下部分是 Prometheus。它的开源项目地址是 https://github.com/prometheus。它是监控系统的中心，负责策略数据收集、存储、告警、查询等。
• 中上部分是服务发现，用于动态对象的监控。在不少现代系统中，被监控对象不是静态的，好比 K8S 中的Pod。对于动态目标，按照静态目标那种监控方式就很难了，所以 Prometheus 提供了服务发现功能。它能动态地发现被监控的对象，而后对它们作监控。
• 右上是 AlertManager。其开源项目地址是 https://github.com/prometheus/alertmanager。它接受 Prometheus 根据所配置的告警规则发过来的告警，而后作去重、分组和路由等处理，而后发给外部的接口组件，好比 PageDuty、邮件系统等。
• 右下是 Grafana。其开源项目地址是 https://github.com/grafana/grafana。它以Prometheus 为后端（它支持对接不少种后端），根据配置，从中获取数据，而后以很是漂亮的界面（Dashboard）将数据呈现出来。

网上有不少不少的关于 Prometheus 的文档，好比 https://yunlzheng.gitbook.io/prometheus-book/ 。

2. 利用 Prometheus 对 OpenShfit 集群进行监控

2.1 OpenShfit 集群的监控需求

上图整理了OpenShift 集群的监控需求。它包括两大部分：

• 一部分是对OpenShift 平台进行监控，确保它稳定运行。这是平台运维团队的需求。这部分又包括不少内容，包括节点监控（节点的CPU、内存、网络、存储等）、容器监控（每一个容器所消耗的资源，包括cpu、内存、网络、文件系统等），以及 OpenShift 核心组件等。
• 另外一部分是运行在OpenShfit 平台上的业务服务，确保业务服务稳定运行，这是应用开发和运维团队的需求。

2.2 基于 Prometheus 的 OpenShift 监控系统的实现

为了知足上述监控需求，OpenShift 提供了基于 Prometheus + Grafana 的监控系统。针对每一个须要被监控的目标（target），都利用了Prometheus提供的某个功能来实现对它的监控。

先上一张官方的架构图：

 

我画的逻辑图：

 具体每一个部分在后文会有相关介绍。

2.3 基于 Prometheus 的 OpenShift 监控系统的部署和维护

OpenShfit 利用 ansible 在某个project（个人是 openshift-monitoring）中部署包括 Prometheus 和 Granfana 在内的监控系统。这里面主要用到两个开源项目：

• 一个是 Cluster Monitoring Operator。它的开源项目地址是 https://github.com/openshift/cluster-monitoring-operator。它负责在 OpenShfit 环境中部署基于 Prometheus 的监控系统。
• 另外一个是 Prometheus Operator。 它的开源项目地址是 https://github.com/coreos/prometheus-operator。它负责在 Kubernetes 环境中部署基于 Prometheus 的监控系统。

关于这两个 Operator 的更多信息，请查阅有关文档。下面只介绍某些重点部分。

Cluster Monitoring Operator 只是很薄的一层，可是它是入口。它的主要任务是负责把 Prometheus Operator 建立出来。

Prometheus Operator 是 CoreOS 开源的项目，它就很复杂了。如下图为参照，它负责建立和管理三种东西：

• 第一种是 Prometheus 及相关的服务。默认包括 alertmanager 服务、Prometheus 服务、Grafana 服务、kube-state-metrics 服务、node-exporter 服务。
• 第二种是4个 CRD 类型（实际上有6个，但另两个的用途不明），包括 AlterManager，Prometheus、PrometheusRule 和 ServiceMonitor。
• 每个 CRD 都是一个相似 Deployment 配置，从名字上能够看出与实体的对应关系。
• Prometheus Operator 会监控这些实例。若是发现有更改，则会对相应的实体作变动。好比若 PrometheusRule 的内容被修改，那么新的监控和告警规则会被 Prometheus 从新加载。
• 所以，定义这些 CRD 类型的目的，是为了简化对 Prometheus 系统的管理。管理员只须要对这些 CRD 实例作管理，系统就会自动对实例作变动。
第三类是这四个 CRD类型的实例。在部署监控系统时，若干个实例会被自动建立出来，对应第一种里面的那些服务。
• 1 个 alertmanager 实例对应 alertmanager 服务，每一个服务默认3 个副本，也就是有3个 Pod。
• 1 个 Prometheus 实例对应 Prometheus 服务，每一个服务默认2个副本，也就是有2个 Pod。
• 1 个 PrometheusRule 实例对应当前 Prometheus 实例所使用的监控和告警规则。
• 9 个 ServiceMonitor 实例，对应对 Prometheus 所监控的9个目标，这里的每一个目标都是一个 OpenShift 服务。下面会详细说明

 2.4 ServiceMonitor 实例

ServiceMonitor 是 Prometheus Operator 向运维人员暴露出来的被监控的目标。在部署完成后，默认建立了9个 ServiceMonitor 对象，对应9个须要被 Prometheus 监控的核心平台服务：

2.4.1 alertmanager

AlterManager 是一个 Prometheus 套件中的独立组件，它自身实现了符合 Prometheus 要求的计量信息接口。

2.4.2  cluster-monitoring-operator 

这是 OpenShift cluster monitoring opeator 服务。它也实现了计量接口。

2.4.3  kube-apiserver 

这是 OpenShift 的 API 和 DNS 服务。

2.4.4 kube-controllers

这是 K8S master controllers 服务。 

2.4.5 kube-state-metrics

这是一个开源项目，地址在  https://github.com/kubernetes/kube-state-metrics。它从 K8S API Server 中获取数据，好比：

ksm_resources_per_scrape{resource="node",quantile="0.99"} 7
ksm_resources_per_scrape_sum{resource="node"} 255444
ksm_resources_per_scrape_count{resource="node"} 36492
ksm_resources_per_scrape{resource="persistentvolume",quantile="0.5"} 15
ksm_resources_per_scrape{resource="persistentvolume",quantile="0.9"} 15

2.4.6 kubelet

kubelet 服务包含多个Static Pod，每一个Pod运行在集群的每一个节点上。它除了自身提供 kublet 的计量信息外，还内置了 cAdvisor 服务，所以也提供 cAdvisor 信息。 cAdvisor 对 Node机器上的资源及容器进行实时监控和性能数据采集，包括CPU使用状况、内存使用状况、网络吞吐量及文件系统使用状况。cAdvisor集成在Kubelet中，当kubelet启动时会自动启动cAdvisor，一个cAdvisor仅对一台Node机器进行监控。

2.4.7 node-exporter     

 node-exporter 服务包含多个 DaemonSet Pod，每一个 Pod 运行在一个集群节点上。  它主要用于 Linux 系统监控，其开源项目地址为  https://github.com/prometheus/node_exporter。

 

2.4.8 prometheus

这是 Prometheus 服务，它可有多个 StatefulSet Pod，每一个 Pod 中运行一个 Prometheus 进程。

 

2.4.9 prometheus-operator 

这是 Prometheus Operator 服务，只有一个pod。

 

2.5 基于OpenShift ServiceMonitor 和 Prometheus Service Discovery（服务发现）的监控的实现

Prometheus Pod 中，除了 Prometheus 容器外，还有一个 prometheus-config-reloader 容器。它负责导入在须要的时候让Prometheus 从新加载配置文件。配置文件被以 Secret 形式建立并挂载给 prometheus-config-reloader Pod。一旦配置有变化，它会调用 Prometheus 的接口，使其从新加载配置文件。

配置文件中定义了被监控的目标为这些 ServiceMonitor 对象所对应的服务：

 

每一个 job 都采用 endpoints 类型的 Prometheus 服务发现机制。这种机制下，Prometheus 会调用 OpenShift 的API，首先找到每一个 job 所配置的 OpenShift 服务，而后找到这服务的端点（endpoint）。每一个 OpenShfit endpoint 是一个 Prometheus target（目标），能够在 Prometheus 界面上看到目标列表。而后在每一个目标上，调用 metrics HTTP API，以拉取（GET）形式，得到该服务的计量数据。

 

关于 Premetheus 对 OpenShift/Kubernetes 平台所作的监控的详细状况，下面这一系列文章作了比较详细的解释：https://blog.freshtracks.io/a-deep-dive-into-kubernetes-metrics-b190cc97f0f6。

3. 利用 Prometheus 对部署在 OpenShift 平台上的应用进行监控

3.1 技术实现

3.1.1 监控框架总结

把前面的内容再总结一下，就有了下面的监控框架图：

3.1.2 监控一个运行在OpenShift 中的应用

Prometheus 对容器云平台作监控时，已经能够采集到容器的一些资源使用计量数据了，好比CPU、内存、网络、存储、文件系统等。但这还不够，由于没有应用自身的计量信息。要使得Prometheus 能采集到应用自身的监控信息，须要知足一些条件，并作一些配置。

首先，应用的计量数据是应用本身产生的，只不过是被Prometheus获取了。一个应用要可以被Prometheus 监控，须要知足几个条件：

• 首先的要求是，应用要暴露出它的计量数据。若是它不提供计量数据，也就不须要被监控了。
• 其次，须要知足 Prometheus 的数据格式和数据获取要求。Prometheus 定义了计量数据的规范，同时定义了获取方式（经过HTTP Get 获取）。若是应用须要直接被Prometheus 监控，那么就得知足这些要求。
• 若是应用自己有数据，可是不知足Prometheus 的要求，也有一些办法。其中一个办法是实现一个 sidecar exporter。它负责以应用特有的格式去获取应用的计量数据，而后按照 Prometheus 的要求将数据暴露出来。Prometheus 项目中已经有了一些实现，好比 HAProxy 的 exporter 在 https://github.com/prometheus/haproxy_exporter。

其次，须要作一些配置，使得 Prometheus 知道如何去获取应用的计量数据。从上图能够看出，经过使用 Prometheus Operator，配置监控的过程被大大简化了。基本上大体步骤为：

• 部署应用服务，检查它的或他的 exporter 的 metrics HTTP API 可否正确运行
• 为该应用服务建立一个 ServiceMonitor 对象
• 修改 PrometheusRule 对象，为应用添加监控和告警规则

而后，Prometheus 就会自动地将这些变更应用到 Prometheus 和 AlterManager 实例中，而后该应用就会被监控到了。

3.2 产品相关

对这套基于 Prometheus 的OpenShift/Kubernetes 监控系统，到目前为止，我认为它还不够成熟，在不少地方有待改进。好比Prometheus高可用，目前尚未很好的方法；好比Prometheus 的存储，从设计上它就只能做为短时间存储，若是应用于大型的生产环境，短期内就会产生大量数据，那该怎么办？；好比监控和告警规则配置，还不够灵活和方便；好比服务发现，若是被监控的目标量很大并且变化很快，Prometheus 可否可以及时响应？Grafana 如何作多租户实现？等等。

所以，当前，我认为它仍是更加适合于平台监控，也就是面向平台运维人员的。由于此时不少要求均可以被妥协，好比稳定性、扩展性、多租户、灵活性、用户友好等。

若是要用于用户应用的监控，从产品和技术层面，那还有大量工做须要作，包括但不限于：

• 用户如何配置其应用监控（如何建立和管理 CRD 对象等）
• 用户如何建立和管理监控和告警规则
• Grafana 如何实现多租户
• Prometheus 如何支持大量的被监控对象和计量信息 

参考连接：

• http://supergiant.io/blog/introduction-to-kubernetes-monitoring-architecture/
• http://www.javashuo.com/article/p-rgfygqxm-hd.html
• https://yunlzheng.gitbook.io/prometheus-book/part-iii-prometheus-shi-zhan/readmd/service-discovery-with-kubernetes
• https://sysdig.com/blog/kubernetes-monitoring-prometheus/
• https://blog.freshtracks.io/a-deep-dive-into-kubernetes-metrics-66936addedae

 

感谢您的阅读，欢迎关注个人微信公众号：