了解Prometheus Operator
Prometheus Operator
我们使用ConfigMap了管理Prometheus配置文件。每次对Prometheus配置文件进行升级时，，我们需要手动移除已经运行的Pod实例，从而让Kubernetes可以使用最新的配置文件创建Prometheus。 而如果当应用实例的数量更多时，通过手动的方式部署和升级Prometheus过程繁琐并且效率低下。
Prometheus Operator的工作原理
在Kubernetes基本的Resource和controller概念上,以扩展K8Sapi的形式,帮助用户创建，配置和管理复杂的有状态应用程序。从而实现特定应用程序的常见操作以及运维自动化。
使用Service，Ingress来管理应用的访问方式，使用ConfigMap和Secret来管理应用配置。我们在集群中对这些资源的创建，更新，删除的动作都会被转换为事件(Event)，Kubernetes的Controller Manager负责监听这些事件并触发相应的任务来满足用户的期望。这种方式我们成为声明式，用户只需要关心应用程序的最终状态，其它的都通过Kubernetes来帮助我们完成，通过这种方式可以大大简化应用的配置管理复杂度。
架构图:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-XesW6DGD-1672054702942)(./images/2022-12-21-17-09-35.png)]
Prometheus Operator能做什么,
Prometheus Operator给定义出的目前提供的4类资源:
-
Prometheus: 声明式创建和管理Prometheus server实例
是定义了一种新的promtheus的自定义资源,声明了在K8S集群中运行的Prometheus的期望设置,副本数等等,持久化存储等,以及实例发送告警的alertmanage的配置选项,
每一个Prometheus资源,Operator都会在相同的namespace下部署为一个statefulset的资源类型,同时prometheus 的 Pod 都会挂载一个名为 的 Secret
里面包含了Prometheus的配置,operator会根据包含的servicemonitor生成配置,并且包含有配置的secret,无论是serviceMonitors或者Prometheus的修改,都会持续不断的按照前面步骤更新, -
ServiceMonitor 负责声明式的管理告警配置,
serviceMonitor 自定义资源CRD能够声明如何监控一组动态服务的定义,它使用标签选择定义一组需要被监控的服务,这样就允许,组织引入如何暴露,metric的规定,只要符合这些规定新服务就会列监控,
要使用Prometheus Operator监控kubernets集群中的应用,Endpoints 对象必须存在,Endpoints 对象本质是一个ip地址列表,通常,Endpoints 对象是由service构建的,service对象通过对象选择器发现pod并将他们添加到Endpoints 资源对象当中去,
Prometheus Operator 引入 ServiceMonitor 对象,它发现了Endpoints对象,并配置Prometheus 去监控这些pods,
ServiceMonitorSpec 的 endpoints 部分用于配置需要收集 metrics 的 Endpoints 的端口和其他参数。在一些用例中会直接监控不在服务 endpoints 中的 pods 的端口
ServiceMonitor 和发现的目标可能来自任何namespace中,对于跨namespace的监控十分重要,
使用 PrometheusSpec下的ServiceMonitorNamespaceSelector,通过各自Prometheus server限制ServiceMonitors 作用的namespace,使用ServiceMonitorSpec 下的namespaceSelector 可以现在允许发现 Endpoints 对象的命名空间。要发现所有命名空间下的目标，namespaceSelector 必须为空。
kind: ServiceMonitor
metadata:labels:k8s-app: node-exporter # 这个 ServiceMonitor 对象带有 k8s-app=node-exporter 标签，因此会被 Prometheus 选中name: node-exporternamespace: default
spec:selector:matchLabels: # 定义需要监控的 Endpoints，带有 app=node-exporter 且 k8s-app=node-exporter标签的 Endpoints 会被选中app: node-exporterk8s-app: node-exporterendpoints:- bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/tokeninterval: 30s # 定义这些 Endpoints 需要每 30 秒抓取一次targetPort: 9100 # 定义这些 Endpoints 的指标端口为 9100scheme: httpsjobLabel: k8s-app
-
alertmanager: 声明式的创建和管理alertmanager实例.
Alertmanager 自定义资源(CRD)声明在 Kubernetes 集群中运行的 Alertmanager 的期望设置。它也提供了配置副本集和持久化存储的选项。
每一个 Alertmanager 资源，Operator 都会在相同 namespace 下部署成一个正确配置的 StatefulSet。Alertmanager pods 配置挂载一个名为 的 Secret， 使用 alertmanager.yaml key 对作为配置文件。
当有两个或更多配置的副本时，Operator 可以高可用性模式运行Alertmanager实例。 -
PrometheusRule: 负责声明式的管理告警配置,
在Kubernetes集群中部署Prometheus Operator
https://www.prometheus.wang/operator/what-is-prometheus-operator.html
为了能够让Prometheus能够采集部署在Kubernetes下应用的监控数据，在原生的Prometheus配置方式中，我们在Prometheus配置文件中定义单独的Job,同时使用kubernetes_sd定义整个服务发现过程,而在Prometheus Operator,则可以直接在声明中一个serviceMonitor对象,通过这个对象,通过特定端口,
通过selector中的标签定义选择监控目标的pod对象,同时在endpoints中指定port名称为web的端口,这个端口是之前在service中定义好的访问端口收集数据的端口,
默认情况下,ServiceMonitor和监控对象必须是在相同的命名空间下的,可以使用namespaceselector定义让其可以跨命名空间关联ServiceMonitor资源
关联Promethues与ServiceMonitor
之间的关联关系,是通过serviceMonitorSelector定义的,在Prometheus中通过标签选择当前需要监控的
ServiceMonitor对象,修改prometheus-inst.yaml中Prometheus的定义如下所示
由于默认创建的Prometheus实例使用的是monitoring命名空间下的default账号，该账号并没有权限能够获取default命名空间下的任何资源信息。
为了修复这个问题，我们需要在Monitoring命名空间下为创建一个名为Prometheus的ServiceAccount，并且为该账号赋予相应的集群访问权限。
第一个问题: 如何将Prometheus和被监控的pod绑定起来:
根据官方文档实例中,通过deployment和svc绑定了三个采集的pod实例,通过一个svc绑定到三个pod,也就有了三个endpoint资源对象,
然后通过访问svc的8080/metric 地址,就会获取到应用程序的样本数据,(为什么会直接获取到样本数据,)
为了获取到这个样本数据,原生的Prometheus是通过单独定义的job的方式进行获取的,同时使用kubernetes_sd定义整个服务发现过程,但是在promtheus operator中,是通过直接声明一个serviceMonitor对象的方式:
通过定义ServiceMonitor资源对象:
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:name: example-appnamespace: monitoring ## 指定资源所在命名空间labels:team: frontend ## 定义自己的标签,后面要引用
spec:namespaceSelector: ## 定义可以跨命名空间进行调用matchNames: - defaultselector: ## 定义获取的绑定的标签是pod的标签,matchLabels:app: example-appendpoints: ## 指定监控的pod的对应的端口,- port: web
以上就是将pod和ServiceMonitor资源绑定关联起来的,然后就是将ServiceMonitor资源和Prometheus资源绑定起来,
他们之间的定义关系是通过 serviceMonitorSelector定义,通过标签选择当前需要监控的serviceMonitor对象,
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:name: instnamespace: monitoring
spec:serviceAccountName: prometheus ## 这里绑定serviceAccount的nameserviceMonitorSelector: ## 就是这里进行标签定义,matchLabels:team: frontend ## 这里绑定上面的ServiceMonitor的标签,resources: ## 这里定义资源限制,requests:memory: 400Mi
同时还需要定义获取资源访问的权限,就需要定义serviceAccount,给Prometheus定义一个命名空间下的访问pod的资源权限,用来收集数据,然后将这个权限给到Prometheus资源,
最终就是通过serviceMonitorSelector来绑定对应ServiceMonitor,ServiceMonitor通过标签绑定后端的pod对象,
这种是指定了serviceMonitorSelector,做出了限制,但一般情况下,是不需要进行限制的,所以一般都是采用{}
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Aij5AN6g-1672054702945)(./images/2022-12-23-16-08-11.png)]
这种方式下,就会将所有命名空间下的 ServiceMonitor进行自动发现和绑定上去,
第二个问题: 普通的pod如何获取监控数据信息,
对于需要获取普通的一个pod占用的资源信息,就需要通过kubelet来进行获取到pod占用的资源信息,
而需要获取pod内部服务的相关信息,则需要改服务将数据暴露出来,然后获取,
监控告警:
Alertmanager配置概述:
Alertmanager主要负责对Prometheus产生的告警进行统一处理，因此在Alertmanager配置中一般会包含以下几个主要部分：
全局配置（global）：用于定义一些全局的公共参数，如全局的SMTP配置，Slack配置等内容；
模板（templates）：用于定义告警通知时的模板，如HTML模板，邮件模板等；
告警路由（route）：根据标签匹配，确定当前告警应该如何处理；
接收人（receivers）：接收人是一个抽象的概念，它可以是一个邮箱也可以是微信，Slack或者Webhook等，接收人一般配合告警路由使用；
抑制规则（inhibit_rules）：合理设置抑制规则可以减少垃圾告警的产生
在全局配置中需要注意的是: resolve_timeout,该参数定义了alertmanager持续多长时间未接收到告警后标记告警为resolved已解决的状态,
该参数的定义可能会影响到告警恢复的通知接收时间,默认5分钟,
基于标签的告警处理路由:
在Alertmanager的配置中会定义一个基于标签匹配规则的告警路由树，以确定在接收到告警后Alertmanager需要如何对其进行处理：
route:
其中router中则定义了告警的路由匹配规则,以及alertmanager需要将匹配的告警发送给哪一个receiver,
route:group_by: ['alertname']receiver: 'web.hook'
receivers:
- name: 'web.hook'webhook_configs:- url: 'http://127.0.0.1:5001/'
上面的情况中按照alertname进行分组,
在真实环境中,需要根据告警不同的级别,定义不同子router,这些router通过标签匹配告警的处理方式,
路由匹配
每个告警都会从配置文件中顶级的router进入路由数中,需要注意的是,顶级的router必须匹配所有告警,
每个路由都可以定义自己的接受人以及匹配规则,默认情况下,告警进入到顶级router后会遍历,所有的子节点,直到找到最深的匹配router,
并将告警送到该router定义的receive中,但是如果router中的设置continue的值为false,那么告警在匹配到第一个子节点后就直接停止了,
如果continue为true，报警则会继续进行后续子节点的匹配。如果当前告警匹配不到任何的子节点，那该告警将会基于当前路由节点的接收器配置方式进行处理。
告警的匹配有两种方式:
- 第一种基于字符串验证,通过设置match规则判断当前告警中是否存在标签labelname并且其值等于labelvalue,
- 第二种方式基于正则表达式,通过设置match_re验证当前告警标签的值是否满足,
告警分组:
alertmanager可以对告警通知进行分组,将多条告警合并为一个通知,这里我们可以使用group_by来定义分组规则。基于告警中包含的标签，如果满足group_by中定义标签名称，那么这些告警将会合并为一个通知发送给接收器。
为了等待能够一次收集和发送更多的相关信息时,可以通过group_wait参数设置等待时间,这些获取到告警会通知会合并为一个通知向receive发送,
group_interval设置: 用于定义相同的group之间发送告警通知的时间间隔,
inhibit_rules: 表示抑制器相关设置,(也就是抑制重复发送相同告警,)
-source_match: #源标签警报触发时抑制含有目标标签的警报,在当前警报匹配 status: ‘High’ ,此处的标签抑制匹配一定是在router中进行了配置的,否则会报错找不到key,;
“source_match source_match_re”
这参数是用来抑制target_math匹配的到的报警,
总体来说，就是只要有source匹配到的报警，就不发送target匹配到的报警了。比如，发现报警级别很高的，就抑制级别低的。
但是只是这样还不够，比如都不是同一台机器的报警，还抑制个什么劲，所以还有下面这个参数。
target_match:
status: warning :
可以被抑制的目标。匹配到的就是可以被抑制的。只是可以，是否抑制还要下面的source_match参数。
match不支持正则，直接等于。 match_re支持正则。
"equal"这个里面指定的labelname的值必须是在source与target里面都相同,只有满足定义的几个labelname都相同的情况下才会触发抑制,
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-KuZ6938b-1672054702946)(./images/2022-12-23-16-55-12.png)]
这个是线上告警配置
使用PrometheusRule定义告警规则
通过声明PrometheusRule的资源类型,实现管理
线上告警规则配置:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-x9WV6Kfg-1672054702947)(./images/2022-12-26-11-25-24.png)]
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:labels:prometheus: examplerole: alert-rulesname: prometheus-example-rules
spec:groups:- name: ./example.rules ## 告警分组,rules:- alert: ExampleAlert ##告警标题服务完成内容, annotations: ##定义告警说明description: Adx Ingress Nginx check 5xx code is {{$value}},above 1000 ##告警描述summary: High Nginx 5xx code ##告警标题expr: vector(1) ##告警判断表达式,for: 5m ##告警持续时间后触发告警,labels: ##定义告警标签,serverity: critical
然后创建对应的PrometheusRule的资源对象,然后将这个PrometheusRule资源对象与Prometheus进行绑定,添加绑定标签即可:
ruleSelector:matchLabels:role: alert-rulesprometheus: example
自定义Alertmanager配置和管理
添加好规则后,需要配置告警策略,需要创建Alertmanager的资源类型,然后通过secret方式将配置文件进行挂载到Alertmanager上面.
apiVersion: monitoring.coreos.com/v1
kind: Alertmanager
metadata:name: instnamespace: monitoring
spec:replicas: 1创建对应的secret资源:
global:resolve_timeout: 5m
route:group_by: ['job']group_wait: 30sgroup_interval: 5mrepeat_interval: 12hreceiver: 'webhook'
receivers:
- name: 'webhook'webhook_configs:- url: 'http://alertmanagerwh:30500/'
创建对应的secret资源:
kubectl create secret generic alertmanager-inst --from-file=alertmanager-secret.yaml
以上就是将Alertmanager配置完成了,然后需要将它和Prometheus资源进行绑定,.
Alertmanager和Prometheus资源进行绑定
只需要在yaml中添加alerting的标签内容绑定:
alerting:alertmanagers:- name: alertmanager-example ##定义的Alertmanagernamespace: monitoring ##alert所在的命名空间port: web ## alert所使用的端口,