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
- 我们看到，这个资源的类型
kind: ServiceMonitor，它并不是原生的， 是Operator定义的一个CRD。 -
ServiceMonitor要和监控的service在同一个表空间。 -
matchLabels是匹配目标的label。 这里我们去匹配label含有wbox-product: tulip的service。 -
path: /core/health.api和targetPort: 80定义了要扫描的端口和路径，targetPort是service中已经设置的，可以是数字或者名字。 -
interval: 60s是扫描间隔时间，对这个target每60秒扫描一次。 -
relabelings:是对metrics的label的重定义，这里不详细展开了。 例子里，我们把instance和pod这两个label删掉，并把__meta_kubernetes_endpoint_node_name重命名为instance，原因以后再说。
现在我们了解了为什么要用Prometheus Operator对k8s进行监控。 那问题是，要如何部署？收集哪些数据？定义哪些监控指标？如何呈现？是不是要一个个自己来写？ 答案是否定的， 在下一篇我们将介绍kube-prometheus这个项目。
网友评论