阿里云容器Kubernetes监控(七) - Prometheus监控方案部署

前言

Prometheus是一款面向云原生应用程序的开源监控工具，作为第一个从CNCF毕业的监控工具而言，开发者对于Prometheus寄予了巨大的希望。在Kubernetes社区中，很多人认为Prometheus是容器场景中监控的第一方案，成为容器监控标准的制定者。在本文中，我们会为大家介绍如何快速部署一套Kubernetes的监控解决方案。

Prometheus方案的解析

在解析Prometheus容器监控方案之前，我们先要确定在Kubernetes中需要监控的对象包含什么？对于一个监控系统而言，常见的监控维度包括：资源监控和应用监控。资源监控是指节点、应用的资源使用情况，在容器场景中就延伸为节点的资源利用率、集群的资源利用率、Pod的资源利用率等。应用监控指的是应用内部指标的监控，例如我们会将应用在线人数进行实时统计，并通过端口进行暴露来实现应用业务级别的监控与告警。那么在Kubernetes中，监控对象会细化为哪些实体呢？

系统组件
kubernetes集群中内置的组件，包括apiserver、controller-manager、etcd等等。
静态资源实体
主要指节点的资源状态、内核事件等等
动态资源实体
主要指Kubernetes中抽象工作负载的实体，例如Deployment、DaemonSet、Pod等等。
自定义应用
主要指需要应用内部需要定制化的监控数据以及监控指标。

对于静态资源实体和系统组件而言，大家可能非常好理解，他们的监控方式也比较简单，只需要在配置文件中指明即可。那么如何处理动态的资源实体监控呢？对于这种需要动态感知监控端点的场景，prometheus提出了自己的解决方案 - prometheus operator。prometheus operator是 CoreOS 开源的一套用于管理在 Kubernetes 集群上的 Prometheus 控制器，它是为了简化在 Kubernetes 上部署、管理和运行 Prometheus 和 Alertmanager 集群。

简单的讲，prometheus operator的作用通过CRD的方式将需要动态监听的实体进行定义，并通过监听apiserver中实体的变化，实现prometheus中动态更新配置与报警规则。用更通俗的话讲就是，通过prometheus operator的方案，可以让prometheus的监控对象变成自动生成的，开发者无需额外配置监控任务，即可实现动态实体的监控。

prometheus监控方案的主体是prometheus operator，为了满足Kubernetes中的监控场景，Prometheus方案在prometheus之上作了很多的扩展，主要包含如下组件：

prometheus-server：数据存储以及监控数据聚合
prometheus-config-reloader：动态更新prometheus配置
rules-configmap-reloader：动态更新prometheus报警配置
alert manager：报警组件
node-exporter：节点资源信息采集组件
kube-state-metrics：动态发现endpoint，三方监控的核心组件
prometheus-operator：prometheus配置的operator
grafana：数据展现

部署Prometheus监控方案

1. 在集群的master节点执行代码下载

git clone https://github.com/AliyunContainerService/prometheus-operator

和社区的prometheus-operator相比，阿里云的版本做了少许的定制，并会定期同步最新版本。

2. 部署Prometheus监控方案

cd contrib/kube-prometheus
kubectl apply -f manifests

3. 查看部署结果

默认情况下由于安全的原因，Prometheus、AlertManager与Grafana都没有开放公网访问，开发者可以通过本地的Proxy方式查看。具体方式如下：首先在容器服务控制台下载kubeconf到本地。

访问prometheus可以在本地执行如下命令

kubectl --namespace monitoring port-forward svc/prometheus-k8s 9090

此时访问本地的localhost:9090，即可使用prometheus。

选择Status下的Target查看所有采集任务，如果所有的状态都是up，表明采集任务都已经运行。

4. 查看数据聚合与展现

访问grafana可以在本地执行如下命令，默认的用户名密码为admin/admin，访问本地的localhost:3000，登陆并选择相应的dashboard，即可查看相应的聚合内容。

kubectl --namespace monitoring port-forward svc/grafana 3000

5. 查看告警规则与告警压制

在Prometheus的Alerts类目中可以查看当前的报警规则，红色的规则表示正在触发报警，绿色的规则表示状态正常，默认prometheus operator会自动创建一批报警规则。

如果需要设置报警压制，需要访问Alter Manager，可以在本地执行如下命令，访问本地的localhost:9093

kubectl --namespace monitoring port-forward svc/alertmanager-main 9093

点击Silence可以设置报警压制的内容。

定制Prometheus监控方案

看到这里很多开发者会提出一个疑问，这么多内容是否可以进行定制？答案是肯定的，标准的Prometheus是通过配置文件来实现，传统中对于容器中的配置文件变化处理是非常麻烦的，因为配置的变化需要重启应用甚至容器，而且还需要提前将文件拷贝到主机上。我们先抛开Prometheus这件事情，先想想Kubernetes中是怎么解决的，在Kubernetes中所有的实体操作都可以通过Yaml变更来进行实现。那么Prometheus的配置是否可以通过类似的方式下发呢？

答案是肯定的，这就是Prometheus operator做的事情，他将操作Promtheus的一些动作变得更有kubernetes的味道。

我们回到最开始部署的命令：

kubectl apply -f manifests

manifests是本次部署的所有内容文件，当我们深入到目录中的具体文件时，就会发现一些熟悉的内容。例如prometheus-rules.yaml这个文件，内容如下：

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:labels:prometheus: k8srole: alert-rulesname: prometheus-k8s-rulesnamespace: monitoring
spec:groups:- name: k8s.rulesrules:- expr: |sum(rate(container_cpu_usage_seconds_total{job="kubelet", image!="", container_name!=""}[5m])) by (namespace)record: namespace:container_cpu_usage_seconds_total:sum_rate

此处有一个特殊的抽象叫PrometheusRule，这就是prometheus-operator定义的的CRD，在rules字段中是定义的具体的报警规则与方式。因此，如果要修改prometheus中的报警规则，只需要修改这个yaml，并重新apply即可。

Prometheus不是“银弹”

Prometheus的方案相比社区中Heapster(Metrics Server)的方案而言更加强大。但是也并非没有缺点，常常被开发者诟病的缺点主要有如下几个。

性能差
首先对于Prometheus而言，是一个拉取模式的采集系统，而拉取式的系统通常会有一个通病，就是数据提供方的数据量级问题。推送数据的时候，我们可以根据数据的量级分批，分次进行推送。而拉取通常是全量数据的同步。此外相比传统的监控系统的数据存储Prometheus自身的存储数据格式性能还是很低下的。这会导致在集群量级比较大的情况下，Prometheus的CPU、内存、磁盘、网络都存在较高的利用率。Prometheus本身是单点的架构，虽然社区中已经有集群的模式，但是依然不够成熟，使用Promehteus的开发者要做好热备多活的思想准备，使用资源冗余的方式来保证系统稳定。
组件过多
刚才我们已经看到一个标准的Prometheus方案会涉及的组件部分，这些组件大部分都是不可缺少的，这也会导致部署这个方案后，需要额外维护很多监控相关的组件，维护的成本较高。
学习成本高
Kubernetes的风格固然能够成为一种标准表达和执行的范式，但是对于监控而言，后续有些过于激进，本身Prometheus的学习成本已经较高，加入CRD的方式，会使学习的成本变得更高。
扩展性差
表面上看Prometheus定义了CRD可以进行扩展，但是从Prometheus本身而言，缺乏插件的机制进行扩展，从代码外直接扩展则会增加整体架构的复杂，相比zabbix、grafana或者heapster等等监控相关工具的扩展方式，Prometheus还有很长的路要走。
监控指标不准确
这个问题是从Prometheus监控制定开始就存在的问题，由于kubelet的数据指标不是实时的，而Prometheus的数据采集会丢失时间戳，这会导致非常异常的利用率曲线。具体的描述，可以参考如下两个PR 2059与2028

最后

虽然Prometheus有很多的缺点，但是他依然是Kubernetes社区中监控领域的重要一环，开发者可以根据自己的需求来选择合适的方案。对于大部分的开发者而言，内置的Heapter（Metrics Server)与云监控集成的方案已经可以解决80%的基础问题了，未尝不是一个便捷的选择。Prometheus的未来依然是光明的，阿里云也会和社区一起，推进Prometheus的演进，提供更好的Prometheus监控方案。