从kube-prometheus定制k8s监控(一) Prometheus Operator

Prometheus 是一套完整的监控告警解决方案。 主要包括：

• prometheus服务： 定时对监控的各个目标进行扫描(scrape)，把获取的metrics存入时序数据库(tsdb)。另一方面，服务对外提供查询的API服务，使用PromQL进行一些高级查询。
• alert manager： 保存告警的当前状态，配置每一类告警所触发的动作。 可以进行分组，或者有条件的过滤告警。
• *exporter： 用来从各类目标输出metrics， 严格的说，这不是prometheus的一部分。针对不同的监控对象，可以选择使用官方的，第三方的，或者自定义。

所有收集到的指标，都可以在grafana上使用合适的图表进行呈现。

什么是Kubernetes Operator？

Kubernetes 1.17引入了CRD(Custom Resource Definitions)，通过CRD添加新组件用来扩展功能， 这些新组件可以和原生组件一样被使用。

Operator是CoreOS开发的，扩展了原生API，同时又完善了CRD的使用。Operator可以监控修改一系列组件的状态，这样就能封装一个复杂的应用。应用可以包括多个组件，通过一些规则协同工作，大大减少了部署和管理的复杂度。

为什么使用Prometheus Operator?

在传统的服务监控体系中，被监控的目标是一组固定的endpoint，Prometheus把这些target写到配置文件里。 而在kubernetes环境中，目标的endpoint不再固定，需要借助动态的服务发现。

Prometheus Operator for Kubernetes 的目标，就是让prometheus使用k8s的方式为它服务。 作为Operator， Prometheus Operator主要监控和操作下面几个CRD：

• Prometheus： 定义prometheus部署。
• AlertManager： 定义alert manager部署。
• ServiceMonitor： 用来发现被监控的服务。
• PrometheusRule： 定义告警和规则。

所有的配置文件都通过configmap来保存，相应pod中负责reload的容器会自动加载配置。

大体的关系如图：

Operator workflow and relationships

图片来源The Prometheus Operator: Managed Prometheus setups for Kubernetes

这里，和传统Prometheus相比，ServiceMonitor是个新概念，需要理解它的作用。 Prometheus通过ServiceMonitor定义的label去匹配service，对匹配到的相关pod的endpoint进行扫描，从而达到动态发现目标的目的。 在这个过程中，收集到的metrics的label可以转换和重新定义。metrics的label的作用，是通过PromQL对metrics进行过滤。

下面是一个ServiceMonitor的例子：

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: tulip
  namespace: wbox-product
spec:
  endpoints:
  - interval: 60s
    path: /core/health.api
    relabelings:
    - action: replace
      regex: (.*)
      replacement: $1
      sourceLabels:
      - __meta_kubernetes_endpoint_node_name
      targetLabel: instance
    - action: labeldrop
      regex: (pod|instance)
    targetPort: 80
  jobLabel: tulip-metrics
  selector:
    matchLabels:
      wbox-product: tulip

1. 我们看到，这个资源的类型kind: ServiceMonitor，它并不是原生的， 是Operator定义的一个CRD。
2. ServiceMonitor要和监控的service在同一个表空间。
3. matchLabels是匹配目标的label。 这里我们去匹配label含有wbox-product: tulip的service。
4. path: /core/health.api和targetPort: 80定义了要扫描的端口和路径，targetPort是service中已经设置的，可以是数字或者名字。
5. interval: 60s是扫描间隔时间，对这个target每60秒扫描一次。
6. relabelings:是对metrics的label的重定义，这里不详细展开了。 例子里，我们把instance和pod这两个label删掉，并把__meta_kubernetes_endpoint_node_name重命名为instance，原因以后再说。

现在我们了解了为什么要用Prometheus Operator对k8s进行监控。 那问题是，要如何部署？收集哪些数据？定义哪些监控指标？如何呈现？是不是要一个个自己来写？ 答案是否定的， 在下一篇我们将介绍kube-prometheus这个项目。