k8s1.28.8版本配置prometheus监控告警

本文主要是介绍k8s1.28.8版本配置prometheus监控告警，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

文章目录

- - - - 官方架构图
      - 组件的具体介绍
      - kube-prometheus包含的组件
      - 简介：
        文件存储路径：
    - 结构分析
    - - 官网自带的一些规则
      - 自己总结流程
- 1-创建规则
- - - - 磁盘使用率报警规则
  - 详解上面rule流程
  - - Alertmanagerg查看
- 2-报警接收器
- - - 2.1-邮件报警
    - - 修改Alertmanager配置
      - 查看现有的secret alertmanager-main
      - 源配置文件
      - 修改 secret alertmanager-main
      - 参数详解
    - 总结
    - - 查看生成的 secret alertmanager-main
- 3-AlertmanagerConfig 配置
- - - - 3.1-创建alertmanagerconfig.yaml 邮件版本
      - 3.2-修改alertmanager-alertmanager.yaml
- 4-告警模板
- - - 4.1-Alertmanager CRD 支持 `configMaps` 参数, 会自动挂载到 `/etc/alertmanager/configmaps` 目录, 我们可以将模板文件配置成 configmap，创建模板文件 email.tmpl
    - 4.2-创建 configmap
    - 4.3-更新 Alertmanager 示例, 添加 configmap
    - 4.4-修改 AlertmanagerConfig 配置文件, 指定模板文件
- 企业微信报警
- - - 1告警规则这个自定义的有点长，我后面单独发一篇博客
    - 2-修改Alertmanager配置
    - 3-AlertmanagerConfig 配置
    - 企业微信告警模板
- 什么是热更新
- - 怎么热更新
  - - 查看prometheus的pod的ip地址

参考文档

[Kubernetes集群监控-使用Alertmanager报警配置-腾讯云开发者社区-腾讯云 (tencent.com)](https://cloud.tencent.com/developer/article/2377069)

官方架构图

上图是`Prometheus-Operator`官方提供的架构图，其中`Operator`是最核心的部分，作为一个控制器，他会去创建`Prometheus`、`ServiceMonitor`、`AlertManager`以及`PrometheusRule`4个`CRD`资源对象，然后会一直监控并维持这4个资源对象的状态。其中创建的`prometheus`这种资源对象就是作为`Prometheus Server`存在，而`ServiceMonitor`就是`exporter`的各种抽象，是用来提供专门提供`metrics`数据接口的工具，`Prometheus`就是通过`ServiceMonitor`提供的`metrics`数据接口去 pull 数据的，当然`alertmanager`这种资源对象就是对应的`AlertManager`的抽象，而`PrometheusRule`是用来被`Prometheus`实例使用的报警规则文件。这样我们要在集群中监控什么数据，就变成了直接去操作 Kubernetes 集群的资源对象了，是不是方便很多了。上图中的 Service 和 ServiceMonitor 都是 Kubernetes 的资源，一个 ServiceMonitor 可以通过 labelSelector 的方式去匹配一类 Service，Prometheus 也可以通过 labelSelector 去匹配多个ServiceMonitor。

组件的具体介绍

Operator： Operator 资源会根据自定义资源（Custom Resource Definition / CRDs）来部署和管理 Prometheus Server，同时监控这些自定义资源事件的变化来做相应的处理，是整个系统的控制中心。
Prometheus： Prometheus 资源是声明性地描述 Prometheus 部署的期望状态。
Prometheus Server： Operator 根据自定义资源 Prometheus 类型中定义的内容而部署的 Prometheus Server 集群，这些自定义资源可以看作是用来管理 Prometheus Server 集群的 StatefulSets 资源。
ServiceMonitor： ServiceMonitor 也是一个自定义资源，它描述了一组被 Prometheus 监控的 targets 列表。该资源通过 Labels 来选取对应的 Service Endpoint，让 Prometheus Server 通过选取的 Service 来获取 Metrics 信息。
Service： Service 资源主要用来对应 Kubernetes 集群中的 Metrics Server Pod，来提供给 ServiceMonitor 选取让 Prometheus Server 来获取信息。简单的说就是 Prometheus 监控的对象，例如 Node Exporter Service、Mysql Exporter Service 等等。
Alertmanager： Alertmanager 也是一个自定义资源类型，由 Operator 根据资源描述内容来部署 Alertmanager 集群。

kube-prometheus包含的组件

Prometheus Operator
高可用的 Prometheus 默认会部署2个pod
高可用的 Alertmanager
Prometheus node-exporter
Prometheus Adapter for Kubernetes Metrics APIs
kube-state-metrics
Grafana

简介：

这个kube-prometheus目前应该是开源最好的方案了，该存储库收集Kubernetes清单，Grafana仪表板和Prometheus规则，以及文档和脚本，以使用Prometheus Operator 通过Prometheus提供易于操作的端到端Kubernetes集群监视。以容器的方式部署到k8s集群，而且还可以自定义配置，非常的方便

文件存储路径：

prometheus的监控规则文件在prometheus Pod中的路径：/etc/prometheus/rules/prometheus-prometheus-kube-prometheus-prometheus-rulefiles-0/而这些文件都是通过一个叫PrometheusRule的k8s资源生成的，PrometheusRule用于配置Promtheus的 Rule 规则文件，包括 recording rules 和 alerting，可以自动被 Prometheus 加载。至于为什么 Prometheus 能够识别这个 PrometheusRule 资源对象呢？这就需要查看我们创建的 prometheus 这个资源对象了，里面有非常重要的一个属性 ruleSelector，用来匹配 rule 规则的过滤器，我们这里没有过滤，所以可以匹配所有的，假设要求匹配具有 prometheus=k8s 和 role=alert-rules 标签的 PrometheusRule 资源对象

结构分析

alertmanager-secret.yaml  # 告警配置
prometheus-prometheus.yaml　　# 监控配置
prometheusOperator-prometheusRule.yaml  # 默认监控项

官网自带的一些规则

如果这里你接上告警，他默认的一些配置会一直发消息

alertmanager-prometheusRule.yaml    
kubePrometheus-prometheusRule.yaml
kubernetesControlPlane-prometheusRule.yaml  #禁用了我先
kubeStateMetrics-prometheusRule.yaml
nodeExporter-prometheusRule.yaml
prometheusOperator-prometheusRule.yaml
prometheus-prometheusRule.yaml

自己总结流程

1-创建规则*.rules.yaml,他会自己引用到规则里面
2-报警接收器，先定义Alertmanager文件，然后kubectl create 创建成新的yaml，更新引用
3-创建AlertmanagerConfig，定义告警接收模板，预留标签
4-更新alertmanager-alertmanager.yaml，添加模板绑定标签
5-告警模板，创建*.tmpl模板，更新alertmanager-alertmanager.yaml添加configmap，修改 AlertmanagerConfig 配置文件, 指定模板文件

1-创建规则

磁盘使用率报警规则

当磁盘可用空间少于 50% 时触发告警，如果需要添加其他规则也是创建*.rules.yaml
创建 prometheus-rules.yaml，

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:name: demonamespace: monitoring
spec:groups:- name: demorules:- alert: nodeDiskUsageannotations:description: |节点 {{$labels.instance }}挂载目录 {{ $labels.mountpoint }}当前可用空间 {{ printf "%.2f" $value }}%          summary: |挂载目录可用空间低于 50%expr: |node_filesystem_avail_bytes{fstype!="",job="node-exporter"} /node_filesystem_size_bytes{fstype!="",job="node-exporter"} * 100 < 50        for: 1mlabels:severity: warning

查看生成的告警规则, 当前状态是 pending ，我们设置了 1m 的评估等待时间。一分钟过后进入 firing 状态, 正式发出告警, 此时我们设置的 $label 还没有解析。

去 Alertmanager 看一下, 成功收到了告警, 且 labels和value 也已经正常解析了

详解上面rule流程

对于 prometheusrule 的更新操作 (create, delete, update) 都会被 watch 到, 然后更新到统一的一个 configmap 中, 然后 prometheus 自动重载配置
每个 prometheusrule 会作为 configmap prometheus-k8s-rulefiles-0 中的一个 data , data 的命名规则为 <namespace>-<rulename>-ruleuid

root@k8s-master01:~# kubectl get cm prometheus-k8s-rulefiles-0 -n monitoring
NAME                         DATA   AGE
prometheus-k8s-rulefiles-0   7      9m25s# prometheus 实例的挂载信息
root@k8s-master01:~# kubectl get pod prometheus-k8s-0 -n monitoring -o jsonpath='{.spec.volumes[?(@.name=="prometheus-k8s-rulefiles-0")]}' | python3 -m json.tool
{"configMap": {"defaultMode": 420,"name": "prometheus-k8s-rulefiles-0"},"name": "prometheus-k8s-rulefiles-0"
}# prometheus 中实际的存储路径
root@k8s-master01:~# kubectl exec -it prometheus-k8s-0 -n monitoring -- ls /etc/prometheus/rules/prometheus-k8s-rulefiles-0/
monitoring-alertmanager-main-rules-3ebc6559-253d-4f65-9270-f0bf3193d640.yaml
monitoring-grafana-rules-a36dde23-2c31-487e-a115-5cec930163c2.yaml
monitoring-k8s-rules-c102dd2a-580e-4f86-b388-eb51953ada9e.yaml
monitoring-kube-prometheus-rules-a4aeb093-9683-45a2-900e-24de81d551f6.yaml
monitoring-kube-state-metrics-rules-b3f61676-d442-4b7b-bf66-421f710687a7.yaml
monitoring-node-exporter-rules-d6c9d3ba-c1cd-4767-8ccf-ce29a3c67e36.yaml
monitoring-prometheus-operator-rules-3560e71d-f6de-40a6-99df-d0daac87cfb5.yaml

Alertmanagerg查看

只有当我们设置的规则被触发了我们这边查看才会显示

2-报警接收器

Alertmanager 支持很多内置的报警接收器，如 email、slack、企业微信、webhook 等。

2.1-邮件报警

修改Alertmanager配置

vim alertmanager.yaml # 新建的一个yaml

global:resolve_timeout: 5msmtp_from: '0@163.com'smtp_smarthost: 'smtp.163.com:25'smtp_auth_username: '@163.com'smtp_auth_password: 'password'smtp_require_tls: falsesmtp_hello: '163.com'
templates:- '/etc/alertmanager/configmaps/alertmanager-templates/*.tmpl'
route:receiver: Defaultgroup_by: ['alertname', 'cluster']continue: falsegroup_wait: 30sgroup_interval: 5mrepeat_interval: 12h
receivers:
- name: Defaultemail_configs:- to: '@boysec.cn'send_resolved: true

查看现有的secret alertmanager-main

默认的我们可以看到是没有配置接收器以及告警人

kubectl get secret alertmanager-main -n monitoring -o jsonpath='{.data.alertmanager\.yaml}' |base64 -d

源配置文件

修改 secret alertmanager-main

kubectl create secret generic alertmanager-main -n monitoring --from-file=alertmanager.yaml --dry-run=client -o yaml > alertmanager-main-secret.yamlkubectl apply -f alertmanager-main-secret.yaml

参数详解

- `kubectl create secret generic`: 这是创建一个通用类型的Secret的命令，它可以用于存储任何类型的敏感数据。
- `alertmanager-main`: 这是要创建的Secret的名称，这里命名为 `alertmanager-main`。
- `-n monitoring`: `-n` 参数用于指定命名空间，这里将Secret创建在名为 `monitoring` 的命名空间中。
- `--from-file=alertmanager.yaml`: `--from-file` 参数指定了要从文件中读取数据并将其存储在Secret中。在这里，`alertmanager.yaml` 文件中的内容将作为Secret的数据。
- `--dry-run=client`: 这个选项告诉 `kubectl` 仅模拟执行，而不会实际执行创建操作。这样可以将生成的YAML文件输出到标准输出，而不会真正创建Secret。
- `-o yaml`: `-o` 参数指定输出格式，这里指定为YAML格式。
- `> alertmanager-main-secret.yaml`: 将生成的YAML输出重定向到名为 `alertmanager-main-secret.yaml` 的文件中，以供后续使用

总结

#个人总结就是 创建alertmanager.yaml文件的secret，然后导出成新的yaml，类似configmap。然后再去执行新生成的yaml文件，他就会挂载进pod里面
kubectl create secret generic alertmanager-main -n monitoring --from-file=alertmanager.yaml --dry-run=client -o yaml > alertmanager-main-secret.yaml

查看生成的 secret alertmanager-main

配置文件里面的模板就变成你改的模板了

kubectl get secret alertmanager-main -n monitoring -o jsonpath='{.data.alertmanager\.yaml}' |base64 -d

3-AlertmanagerConfig 配置

新建一个 AlertmanagerConfig 类型的资源对象，可以通过 kubectl explain AlertmanagerConfig 或者在线 API 文档来查看字段的含义

3.1-创建alertmanagerconfig.yaml 邮件版本

这个是需要我们创建的，然后修改主alertmanager.yaml，对应标签

# vim alertmanagerconfig.yaml
apiVersion: monitoring.coreos.com/v1alpha1
kind: AlertmanagerConfig
metadata:name: email-confignamespace: monitoringlabels:alertmanagerConfig: wangxiansen #这里标签注意等下要用
spec:route:groupBy: ['alertname']groupWait: 30sgroupInterval: 5mrepeatInterval: 12hreceiver: 'Critical'continue: falseroutes:- receiver: 'Critical'match:severity: criticalreceivers:- name: CriticalemailConfigs:- to: '@boysec.cn'sendResolved: truewebhookConfigs:- url: http://dingtalksendResolved: true

不过如果直接创建上面的配置是不会生效的，我们需要添加一个 Label 标签，并在 Alertmanager 的资源对象中通过标签来关联上面的这个对象，比如我们这里新增了一个 Label 标签：alertmanagerConfig: wangxiansen，然后需要重新更新 Alertmanager 对象，添加 alertmanagerConfigSelector 属性去匹配 AlertmanagerConfig 资源对象

3.2-修改alertmanager-alertmanager.yaml

我的这个主配置文件路径在kube-prometheus-0.13.0/manifests

# vim alertmanager-alertmanager.yaml
apiVersion: monitoring.coreos.com/v1
kind: Alertmanager
metadata:labels:app.kubernetes.io/component: alert-routerapp.kubernetes.io/instance: mainapp.kubernetes.io/name: alertmanagerapp.kubernetes.io/part-of: kube-prometheusapp.kubernetes.io/version: 0.26.0name: mainnamespace: monitoring
spec:image: quay.io/prometheus/alertmanager:v0.26.0nodeSelector:kubernetes.io/os: linuxpodMetadata:labels:app.kubernetes.io/component: alert-routerapp.kubernetes.io/instance: mainapp.kubernetes.io/name: alertmanagerapp.kubernetes.io/part-of: kube-prometheusapp.kubernetes.io/version: 0.26.0replicas: 1                 # 资源问题，这里就先启动一个podsresources:limits:cpu: 100mmemory: 100Mirequests:cpu: 4mmemory: 100Misecrets: []alertmanagerConfigSelector: # 匹配 AlertmanagerConfig 的标签matchLabels:alertmanagerConfig: wangxiansen  # 这个是上面要记得标签securityContext:fsGroup: 2000runAsNonRoot: truerunAsUser: 1000serviceAccountName: alertmanager-mainversion: 0.26.0

4-告警模板

Alertmanager 收到的告警大概长这个样子

4.1-Alertmanager CRD 支持 `configMaps` 参数, 会自动挂载到 `/etc/alertmanager/configmaps` 目录, 我们可以将模板文件配置成 configmap，创建模板文件 email.tmpl

vim email.tmpl

{{ define "email.html" }}
<html><body>{{- if gt (len .Alerts.Firing) 0 -}}{{- range $index, $alert := .Alerts -}}<p>========= ERROR ==========</p><h3 style="color:red;">告警名称: {{ .Labels.alertname }}</h3><p>告警级别: {{ .Labels.severity }}</p><p>告警机器: {{ .Labels.instance }} {{ .Labels.device }}</p><p>告警详情: {{ .Annotations.summary }}</p><p>告警时间: {{ time (unixMillis .StartsAt) "2006-01-02 15:04:05" }}</p><p>========= END ==========</p>{{- end }}{{- end }}{{- if gt (len .Alerts.Resolved) 0 -}}{{- range $index, $alert := .Alerts -}}<p>========= INFO ==========</p><h3 style="color:green;">告警名称: {{ .Labels.alertname }}</h3><p>告警级别: {{ .Labels.severity }}</p><p>告警机器: {{ .Labels.instance }}</p><p>告警详情: {{ .Annotations.summary }}</p><p>告警时间: {{ time (unixMillis .StartsAt) "2006-01-02 15:04:05" }}</p><p>恢复时间: {{ time (unixMillis .EndsAt) "2006-01-02 15:04:05" }}</p><p>========= END ==========</p>{{- end }}{{- end }}</body>
</html>
{{- end }}

4.2-创建 configmap

kubectl create configmap alertmanager-templates --from-file=email.tmpl --dry-run=client -o yaml -n monitoring > alertmanager-configmap-templates.yaml kubectl apply -f alertmanager-configmap-templates.yaml

4.3-更新 Alertmanager 示例, 添加 configmap

vim alertmanager-alertmanager.yaml

apiVersion: monitoring.coreos.com/v1
kind: Alertmanager
metadata:
spec:
.....alertmanagerConfigSelector:matchLabels:alertmanager: mainconfigMaps:- alertmanager-templates

4.4-修改 AlertmanagerConfig 配置文件, 指定模板文件

apiVersion: monitoring.coreos.com/v1alpha1
kind: AlertmanagerConfig
metadata:name: email-confignamespace: monitoringlabels:alertmanagerConfig: wangxiansen
spec:route:groupBy: ['alertname']groupWait: 30sgroupInterval: 5mrepeatInterval: 12hreceiver: 'Critical'continue: falseroutes:- receiver: 'Critical'match:severity: criticalreceivers:- name: CriticalemailConfigs:- to: 'xxxxx@boysec.cn'html: '{{ template "email.html" . }}'          # 添加 与模板中的 define 对应sendResolved: true

更新报警配置

kubectl apply -f alertmanagerconfig.yaml

查看新生成的告警邮件

企业微信报警

1告警规则这个自定义的有点长，我后面单独发一篇博客

2-修改Alertmanager配置

vim alertmanager.yaml # 新建的一个yaml

    global:resolve_timeout: 1msmtp_smarthost: 'smtp.163.com:25'smtp_from: ''smtp_auth_username: ''smtp_auth_password: ''smtp_require_tls: falseroute:group_by: [alertname]group_wait: 10sgroup_interval: 10srepeat_interval: 10mreceiver: wechat-001receivers:- name: 'wechat-001'wechat_configs:- corp_id: xxxx # 企业IDto_user: '@all'             # 发送所有人agent_id: xxxx          # agentIDapi_secret:  # secret

步骤跟邮件告警一样，参考上面

3-AlertmanagerConfig 配置

apiVersion: monitoring.coreos.com/v1alpha1
kind: AlertmanagerConfig
metadata:name: email-confignamespace: monitoringlabels:alertmanagerConfig: aike  # 标识此配置对象的标签，用于分类和识别
spec:route:  # 警报路由配置groupBy: ['alertname']  # 根据警报名称分组groupWait: 30s  # 组等待时间groupInterval: 5m  # 组间隔时间repeatInterval: 12h  # 重复间隔时间receiver: 'Critical'  # 默认接收器continue: false  # 是否继续路由routes:- receiver: 'Critical'match:severity: critical  # 匹配严重程度为 critical 的警报receivers:  # 接收器配置- name: Critical  # 接收器名称emailConfigs:  # 邮件配置，用于发送邮件通知- to: ''  # 接收邮件的邮箱地址html: '{{ template "email.html" . }}'  # 添加 与模板中的 define 对应sendResolved: true  # 发送解决警报的通知webhookConfigs:  # Webhook 配置，用于发送警报通知至钉企业微信- url:   # Webhook URLsendResolved: true  # 发送解决警报的通知

修改alertmanager-alertmanager.yaml
步骤一样省略

企业微信告警模板

{{ define "email.html" }}
<html><body>{{- if gt (len .Alerts.Firing) 0 -}}{{- range $index, $alert := .Alerts -}}{{- if eq $index 0 }}<p>========= xxx环境监控报警 =========</p><p>告警状态：{{ .Status }}</p><p>告警级别：{{ .Labels.severity }}</p><p>告警类型：{{ $alert.Labels.alertname }}</p><p>故障主机: {{ $alert.Labels.instance }} {{ $alert.Labels.pod }}</p><p>告警主题: {{ $alert.Annotations.summary }}</p><p>告警详情: {{ $alert.Annotations.message }}{{ $alert.Annotations.description }}</p><p>触发阀值：{{ .Annotations.value }}</p><p>故障时间: {{ ($alert.StartsAt.Add 28800e9).Format "2006-01-02 15:04:05" }}</p><p>========= end =========</p>{{- end }}{{- end }}{{- end }}{{- if gt (len .Alerts.Resolved) 0 -}}{{- range $index, $alert := .Alerts -}}{{- if eq $index 0 }}<p>========= xxx环境异常恢复 =========</p><p>告警类型：{{ .Labels.alertname }}</p><p>告警状态：{{ .Status }}</p><p>告警主题: {{ $alert.Annotations.summary }}</p><p>告警详情: {{ $alert.Annotations.message }}{{ $alert.Annotations.description }}</p><p>故障时间: {{ ($alert.StartsAt.Add 28800e9).Format "2006-01-02 15:04:05" }}</p><p>恢复时间: {{ ($alert.EndsAt.Add 28800e9).Format "2006-01-02 15:04:05" }}</p>{{- if gt (len $alert.Labels.instance) 0 }}<p>实例信息: {{ $alert.Labels.instance }}</p>{{- end }}<p>========= end =========</p>{{- end }}{{- end }}{{- end }}</body>
</html>
{{- end }}

流程大概就是这样。。。。
然后进行一下热更新

什么是热更新

为了每次修改配置文件可以热加载prometheus，也就是不停止prometheus，就可以使配置生效

怎么热更新

举例：如修改prometheus-cfg.yaml，想要使配置生效可如下操作

# 修改prometheus-cfg.yaml后
kubectl delete -f /root/k8s/monitor/prometheus-cfg.yaml 
kubectl apply -f  /root/k8s/monitor/prometheus-cfg.yaml # 告诉prometheus-deploy.yaml 需要重新加载 prometheus-cfg.yaml文件的内容
curl -X POST http://10.244.1.52:9090/-/reload

查看prometheus的pod的ip地址

kubectl get pods -n monitoring -o wide | grep prometheus

这篇关于k8s1.28.8版本配置prometheus监控告警的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

k8s1.28.8版本配置prometheus监控告警

文章目录

官方架构图

组件的具体介绍

kube-prometheus包含的组件

简介：

文件存储路径：

结构分析

官网自带的一些规则

自己总结流程

1-创建规则

磁盘使用率报警规则

详解上面rule流程

Alertmanagerg查看

2-报警接收器

2.1-邮件报警

修改Alertmanager配置

查看现有的secret alertmanager-main

源配置文件

修改 secret alertmanager-main

参数详解

总结

查看生成的 secret alertmanager-main

3-AlertmanagerConfig 配置

3.1-创建alertmanagerconfig.yaml 邮件版本

3.2-修改alertmanager-alertmanager.yaml

4-告警模板

4.1-Alertmanager CRD 支持 configMaps 参数, 会自动挂载到 /etc/alertmanager/configmaps 目录, 我们可以将模板文件配置成 configmap，创建模板文件 email.tmpl

4.2-创建 configmap

4.3-更新 Alertmanager 示例, 添加 configmap

4.4-修改 AlertmanagerConfig 配置文件, 指定模板文件

企业微信报警

1告警规则这个自定义的有点长，我后面单独发一篇博客

2-修改Alertmanager配置

3-AlertmanagerConfig 配置

企业微信告警模板

什么是热更新

怎么热更新

查看prometheus的pod的ip地址

相关文章

4.1-Alertmanager CRD 支持 `configMaps` 参数, 会自动挂载到 `/etc/alertmanager/configmaps` 目录, 我们可以将模板文件配置成 configmap，创建模板文件 email.tmpl