用多说的网站,网络平台怎么弄,搜索网,运城网站建设费用文章目录 总结部署流程 Alertmanager 三大核心1. 分组告警2. 告警抑制3. 告警静默 报警过滤静默通知方案一#xff1a;方案二#xff1a; 抑制报警规则案例一 参考文档 自定义路由告警#xff0c;分来自不同路由的告警#xff0c;艾特不同的人员进行区分修改 alertmanager … 文章目录 总结部署流程 Alertmanager 三大核心1. 分组告警2. 告警抑制3. 告警静默 报警过滤静默通知方案一方案二 抑制报警规则案例一 参考文档 自定义路由告警分来自不同路由的告警艾特不同的人员进行区分修改 alertmanager 配置有俩种方法Alertmanager CRD **案例介绍****环境概述****快速开始**1-查看现有的规则配置文件 1-secret方式1.2-修改 secret alertmanager-main1.2.1查看日志看看有没有报错查看生成的 secret alertmanager-main1.3- 查看Alertmanager——ui页面1.4查看报警 1.2 配置告警模板1.2.1创建 wechat.tmpl模板1.2.2创建 configmap 1.3查看企业微信报警分级别告警 设置告警监控所有命名空间pod1.1修改 alertmanager.yaml1.2更新 secret1.3配置告警规则1.4查看报警 优化优化一优化二优化三 2.1-AlertmanagerConfig方式这个方式我没有做出来如果有大佬 做出来可以私信我详解一详解二 方案选择方案需求第二种方案创建 Webhook 服务2.1创建webhook服务 总结部署流程 部署Alertmanager 配置Prometheus与Alertmanager通信 配置告警 prometheus指定rules目录 创建告警yaml configmap存储告警规则 configmap挂载到容器rules目录 增加alertmanager告警配置有俩种方式下面注意下 这里是定义谁发送这个告警信息的谁接收这个邮件 Alertmanager 三大核心 1. 分组告警 分组告警是指prometheus的告警规则是对所有监控实例都生效的当同一种类型的告警触发后会汇聚一起并且发送一个告警消息降低告警噪音。 AlertManager告警分组参数 route: //根据标签进行分组alertname就是告警规则的名称多个标签可以以逗号隔开group_by: [alertname] //发送告警等待时间也就是一个时间范围内如果同一组中有其他报警则一并发送 group_wait: 10s //当触发了一组告警后下一组报警触发的间隔 group_interval: 10s //告警产生没有修复重复报警的时间间隔 repeat_interval: 10m2. 告警抑制 通过抑制可以避免产生大量的告警风暴当一个节点宕机设置标签为serveritycritical而节点上的应用告警设置为serveritywarning当节点宕机后可以使用抑制的方法仅发送一条节点宕机的信息而不是发送多条信息。 aertManager告警抑制参数 inhibit_rules:- source_match:// 源标签警报触发时抑制含有目标标签的警报在当前警报匹配serveritycriticalserverity: critical target_match:// 抑制serveritywarning类型告警serverity: warning// 告警中包含的分组名称。标签内容相同才会抑制,也就是说警报中三个标签值相同才会被抑制。equal: [alertname, dev, instance]Prometheus 告警级别 告警级别分为warning、critical和emergency。严重等级依次递增。 3. 告警静默 静默是指定周期时间内不再触发某一个报警。alertManager将检查传入警报是否与活动静默的所有相等或正则表达式匹配。匹配静默规则则不会为该警报发送任何通知。 Alertmanager Web UI 设置静默告警规则 报警过滤 有的时候可能报警通知太过频繁或者在收到报警通知后就去开始处理问题了这个期间可能报警还在频繁发送这个时候我们可以去对报警进行静默设置。 静默通知 方案一 在 Alertmanager 的后台页面中提供了静默操作的入口。 可以点击右上面的 New Silence 按钮新建一个静默通知 我们可以选择此次静默的开始时间、结束时间最重要的是下面的 Matchers 部分用来匹配哪些报警适用于当前的静默比如这里我们设置 instancek8s-node1 的标签则表示具有这个标签的报警在 2 小时内都不会触发报警点击下面的 Create 按钮即可创建 方案二 抑制报警规则 除了上面的静默机制之外Alertmanager 还提供了抑制机制来控制告警通知的行为。抑制是指当某次告警发出后可以停止重复发送由此告警引发的其他告警的机制比如现在有一台服务器宕机了上面跑了很多服务都设置了告警那么肯定会收到大量无用的告警信息这个时候抑制就非常有用了可以有效的防止告警风暴。 要使用抑制规则需要在 Alertmanager 配置文件中的 inhibit_rules 属性下面进行定义每一条抑制规则的具体配置如下 target_match:[ labelname: labelvalue, ... ]target_match_re:[ labelname: regex, ... ]target_matchers:[ - matcher ... ]source_match:[ labelname: labelvalue, ... ]source_match_re:[ labelname: regex, ... ] source_matchers:[ - matcher ... ][ equal: [ labelname, ... ] ]# 当有新的告警规则如果满足 source_match 或者 source_match_re 的匹配规则并且已发送的告警与新产生的告警中 equal 定义的标签完全相同则启动抑制机制新的告警不会发送。 # 当已经发送的告警通知匹配到 target_match 和 target_match_re 规则案例一 比如现在我们如下所示的两个报警规则 NodeMemoryUsage 与 NodeLoad apiVersion: monitoring.coreos.com/v1kind: PrometheusRulemetadata:name: nodenamespace: defaultspec:groups:- name: node-memrules:- alert: NodeMemoryUsageannotations:description: {{$labels.instance}}: 内存使用率高于 30% (当前值为: {{ printf %.2f $value }}%)summary: {{$labels.instance}}: 检测到高内存使用率expr: |(node_memory_MemTotal_bytes - (node_memory_MemFree_bytes node_memory_Buffers_bytes node_memory_Cached_bytes)) /node_memory_MemTotal_bytes * 100 30 for: 1mlabels:team: nodeseverity: critical- name: node-loadrules:- alert: NodeLoadannotations:summary: {{ $labels.instance }}: 低节点负载检测description: {{ $labels.instance }}: 节点负载低于 1 (当前值为: {{ $value }})expr: node_load5 1for: 2mlabels:team: nodeseverity: normal当前我们系统里面普通severity: normal的告警有三条k8s-node1、k8s-node2 和 k8s-master 三个节点另外一个报警也有俩条k8s-node1和 k8s-master 三个节点 现在我们来配置一个抑制规则如果 NodeMemoryUsage 报警触发则抑制 NodeLoad 指标规则引起的报警我们这里就会抑制 k8s-master 和 k8s-node1 节点的告警只会剩下 k8s-node2 节点的普通告警。 通过修改Alertmanager 配置文件中添加如下所示的抑制规则 apiVersion: monitoring.coreos.com/v1alpha1 kind: AlertmanagerConfig metadata:name: email-confignamespace: monitoringlabels:alertmanagerConfig: wangxiansen spec:route:groupBy: [alertname]groupWait: 30sgroupInterval: 5mrepeatInterval: 12hreceiver: Criticalcontinue: falseroutes:- receiver: Criticalmatch:severity: criticalreceivers:- name: CriticalemailConfigs:- to: boysec.cnhtml: {{ template email.html . }}sendResolved: trueinhibitRules:- equal: [instance]sourceMatch:- name: alertnamevalue: NodeMemoryUsage- name: severityvalue: criticaltargetMatch:- name: severityvalue: normal更新报警规则 kubectl create secret generic alertmanager-main -n monitoring --from-filealertmanager.yaml --dry-runclient -o yaml alertmanager-main-secret.yaml kubectl apply -f alertmanager-main-secret.yaml更新配置后最好重建下 Alertmanager这样可以再次触发下报警可以看到只能收到 k8s-node2 节点的 NodeLoad 报警了另外两个节点的报警被抑制了 参考文档 1-alertmanager 实现不同的告警级别发送给不同的接收人 文章参考 https://cloud.tencent.com/developer/article/2216582?areaId1060012-自定义路由告警分来自不同路由的告警艾特不同的人员进行区分 文章参考 https://cloud.tencent.com/developer/article/2327646?areaId1060013-根据不同告警级别设置发送接受器 文章参考 https://blog.51cto.com/u_12965094/2689914自定义路由告警分来自不同路由的告警艾特不同的人员进行区分 修改 alertmanager 配置有俩种方法 Alertmanager CRD Prometheus Operator 为 alertmanager 抽象了两个 CRD资源: 可以理解为俩中方式更新alertmanager alertmanager CRD: 基于 statefulset, 实现 alertmanager 的部署以及扩容缩容 这种方式是新建 alertmanager.yaml 配置文件生成 secret更新替代默认的。 注意这个相当于总配置文件需要在alertmanager.yaml填写的东西比较多模板分组什么的。。。。。 - **如果您的需求比较简单或者不需要分割配置权限**直接使用 alertmanager.yaml 并通过 Secret 应用如您所做的就足够了。这种方式简单直接适用于许多场景。alertmanagerconfig CRD: 实现模块化修改 alertmanager 的配置 如果您使用的是较新版本的 Prometheus Operator**它支持 AlertmanagerConfig 资源这是一种更为声明式的方法来定义 Alertmanager 的配置。通过使用AlertmanagerConfig资源您可以更方便地在多个团队之间分割告警配置每个团队可以管理自己的告警路由、接收器等而不需要直接编辑 alertmanager.yaml 文件。这对于多租户环境非常有用。简单一点就是更新内容上去不会改变默认的global:resolve_timeout: 5m # 该参数定义了当Alertmanager持续多长时间未接收到告警后标记告警状态为resolvedhttp_config: {} # HTTP 配置此处为空对象表示没有特定的配置smtp_hello: localhost # SMTP 邮件发送时使用的 HELO 消息smtp_require_tls: true # SMTP 邮件发送是否需要使用 TLSpagerduty_url: https://events.pagerduty.com/v2/enqueue # PagerDuty API URLopsgenie_api_url: https://api.opsgenie.com/ # Opsgenie API URLwechat_api_url: https://qyapi.weixin.qq.com/cgi-bin/ # 微信企业号 API URLvictorops_api_url: https://alert.victorops.com/integrations/generic/20131114/alert/ # VictorOps API URLroute:receiver: Default # 默认的接收器名称group_by: # 分组字段用于将警报按照指定字段进行分组- namespace # 按照命名空间分组routes: # 路由规则列表- receiver: Watchdog # 接收器名称为 Watchdog 的路由规则match: # 匹配条件alertname: Watchdog # 匹配警报名称为 Watchdog 的警报- receiver: Critical # 接收器名称为 Critical 的路由规则match: # 匹配条件severity: critical # 匹配严重程度为 critical 的警报group_wait: 30s # 在组内等待所配置的时间如果同组内30秒内出现相同报警在一个组内发送报警。group_interval: 5m # 如果组内内容不变化合并为一条警报信息5m后发送。repeat_interval: 12h # 发送报警间隔如果指定时间内没有修复则重新发送报警。inhibit_rules: # 抑制规则列表用于控制警报传播的行为- source_match: # 源警报匹配条件severity: critical # 源警报的严重程度为 criticaltarget_match_re: # 目标警报匹配条件使用正则表达式进行匹配severity: warning|info # 目标警报的严重程度为 warning 或 infoequal: # 需要匹配相等的字段- namespace # 命名空间字段需要相等- alertname # 警报名称字段需要相等- source_match: # 源警报匹配条件severity: warning # 源警报的严重程度为 warningtarget_match_re: # 目标警报匹配条件使用正则表达式进行匹配severity: info # 目标警报的严重程度为 infoequal: # 需要匹配相等的字段- namespace # 命名空间字段需要相等- alertname # 警报名称字段需要相等receivers: # 接收器列表- name: Default # 默认接收器- name: Watchdog # Watchdog 接收器- name: Critical # Critical 接收器templates: [] # 模板列表此处为空列表表示没有定义任何模板案例介绍 基于自定义路由告警我们依旧使用prometheusAlert作为告警渠道为了方便区分来自不同路由的告警我们这里使用不同分组进行告警 环境概述 rootk8s-master01:~/test/prometheus/prometheus-whach# kubectl get pod -n monitoring rootk8s-master01:~/test/prometheus/prometheus-whach# kubectl get node 快速开始 1-查看现有的规则配置文件 kubectl get secret alertmanager-main -n monitoring -o jsonpath{.data.alertmanager\.yaml} |base64 -d1-secret方式 新建 alertmanager.yaml 配置文件 相当于总配置文件需要填写的东西比较多 只需要三个文件 global:resolve_timeout: 1m # 解决超时时间指定Alertmanager标记告警状态为已解决resolved之前等待的时间templates:- /etc/alertmanager/configmaps/alertmanager-templates/*.tmplroute:receiver: ops-err # 默认的接收器名称group_wait: 30s # 在组内等待所配置的时间如果同组内30秒内出现相同报警在一个组内发送报警。group_interval: 1m # 如果组内内容不变化合并为一条警报信息5m后发送。repeat_interval: 10m # 发送报警间隔如果指定时间内没有修复则重新发送报警。group_by: [alertname, instance] # 报警分组routes: # 子路由的匹配设置- matchers:- severity warningreceiver: ops-errcontinue: true# 使用新的 matchers 语法匹配严重级别为 warning 的告警并发送到 ops-err 接收器- matchers:- severity ~ error|criticalreceiver: devopscontinue: true# 使用新的 matchers 语法和正则表达式匹配严重级别为 error 或 critical 的告警并发送到 devops 接收器receivers:- name: devopswechat_configs:- corp_id: # 企业IDto_user: all # 发送所有人agent_id: 1000002 # agentIDapi_secret: # secret# 使用企业微信发送消息- name: ops-criticalwechat_configs:- corp_id: # 企业IDto_user: all # 发送所有人agent_id: 1000005 # agentIDapi_secret: # secret# 使用企业微信发送消息- name: ops-errwechat_configs:- corp_id: # 企业IDto_user: all # 发送所有人agent_id: 1000003 # agentIDapi_secret: # secret# 使用企业微信发送消息1.2-修改 secret alertmanager-main kubectl create secret generic alertmanager-main -n monitoring --from-filealertmanager.yaml --dry-runclient -o yaml alertmanager-main-secret.yaml kubectl apply -f alertmanager-main-secret.yaml1.2.1查看日志看看有没有报错 kubectl logs -f prometheus-operator-68f6c79f9d-24fcm -n monitoring 查看生成的 secret alertmanager-main kubectl get secret alertmanager-main -n monitoring -o jsonpath{.data.alertmanager\.yaml} |base64 -d之后 prometheus-operator 会自动更新 alertmanager 的配置 # kubectl logs -n monitoring -l app.kubernetes.io/nameprometheus-operator | tail -1 levelinfo ts2023-04-30T11:43:01.104579363Z calleroperator.go:741 componentalertmanageroperator keymonitoring/main msgsync alertmanager1.3- 查看Alertmanager——ui页面 规则变成你定义的拉 查报警的分组也变成你得定义的路由规则 1.4查看报警 1.2 配置告警模板 1.2.1创建 wechat.tmpl模板 vim WeChat.tmpl{{ define wechat.default.message }} {{- if gt (len .Alerts.Firing) 0 -}} {{- range $index, $alert : .Alerts -}} {{- if eq $index 0 }} xxx环境监控报警 告警状态{{ .Status }} 告警级别{{ .Labels.severity }} 告警类型{{ $alert.Labels.alertname }} 故障主机: {{ $alert.Labels.instance }} {{ $alert.Labels.pod }} 告警主题: {{ $alert.Annotations.summary }} 告警详情: {{ $alert.Annotations.message }}{{ $alert.Annotations.description}}; 触发阀值{{ .Annotations.value }} 故障时间: {{ ($alert.StartsAt.Add 28800e9).Format 2006-01-02 15:04:05 }}end {{- end }} {{- end }} {{- end }} {{- if gt (len .Alerts.Resolved) 0 -}} {{- range $index, $alert : .Alerts -}} {{- if eq $index 0 }} xxx环境异常恢复 告警类型{{ .Labels.alertname }} 告警状态{{ .Status }} 告警主题: {{ $alert.Annotations.summary }} 告警详情: {{ $alert.Annotations.message }}{{ $alert.Annotations.description}}; 故障时间: {{ ($alert.StartsAt.Add 28800e9).Format 2006-01-02 15:04:05 }} 恢复时间: {{ ($alert.EndsAt.Add 28800e9).Format 2006-01-02 15:04:05 }} {{- if gt (len $alert.Labels.instance) 0 }} 实例信息: {{ $alert.Labels.instance }} {{- end }}end {{- end }} {{- end }} {{- end }} {{- end }} 1.2.2创建 configmap kubectl create configmap alertmanager-templates --from-filewechat.tmpl --dry-runclient -o yaml -n monitoring alertmanager-configmap-templates.yaml kubectl apply -f alertmanager-configmap-templates.yaml查看挂载 rootk8s-master01:~/test/prometheus/prometheus-whach/route# kubectl get pod -n monitoring alertmanager-main-0 -o jsonpath{.spec.volumes[?(.nameconfigmap-alertmanager-templates)]} | python3 -m json.tool {configMap: {defaultMode: 420,name: alertmanager-templates},name: configmap-alertmanager-templates }查看容器内的路径 # kubectl exec -it alertmanager-main-0 -n monitoring -- cat /etc/alertmanager/configmaps/alertmanager-templates/wechat.tmpl1.3查看企业微信报警 分级别告警 设置告警监控所有命名空间pod 1.1修改 alertmanager.yaml 增加命名空间跟pod global:resolve_timeout: 1mtemplates:- /etc/alertmanager/configmaps/alertmanager-templates/*.tmplroute:receiver: ops-errgroup_wait: 10sgroup_interval: 30srepeat_interval: 30sgroup_by: [alertname, instance, pod, namespace]routes:- matchers:- severity warningreceiver: ops-errcontinue: true- matchers:- severity ~ error|criticalreceiver: devopscontinue: truereceivers:- name: devopswechat_configs:- corp_id: to_user: allagent_id: 1000002api_secret: - name: ops-criticalwechat_configs:- corp_id: to_user: allagent_id: 1000005api_secret: - name: ops-errwechat_configs:- corp_id: to_user: allagent_id: 1000003api_secret: 详解 在你的配置中group_by: [alertname, instance, pod, namespace] 的含义是- alertname: 告警的名称。这通常是在 Prometheus 告警规则中定义的告警类型例如 PodNotRunning。 - instance: 发生告警的实例。在 Kubernetes 监控中这通常是 Pod 的 IP 地址或者节点的 IP 地址。 - pod: 发生告警的 Pod 的名称。 - namespace: 发生告警的 Pod 所在的命名空间。只有当这四个标签都相同时告警才会被归为同一组。这意味着即使是同一种告警alertname和同一节点instance只要是不同的 Pod 或者命名空间也会被视为不同的告警组会单独触发一个告警。例如如果有两个告警- 告警 A: {alertnamePodNotRunning, instance10.0.0.1, podpod-1, namespacens-1} - 告警 B: {alertnamePodNotRunning, instance10.0.0.1, podpod-2, namespacens-1}尽管它们的 alertname 和 instance 都相同但是 pod 不同所以它们会被视为两个不同的告警组会分别触发两个告警。1.2更新 secret kubectl create secret generic alertmanager-main -n monitoring --from-filealertmanager.yaml --dry-run -oyaml alertmanager-main-secret.yaml kubectl apply -f alertmanager-main-secret.yaml1.3配置告警规则 vim prometheus-pod-rules.yaml apiVersion: monitoring.coreos.com/v1 kind: PrometheusRule metadata:name: nodenamespace: defaultlabels:group: frem-k8s # 添加全局分组标签 spec:groups:- name: pod-statusrules:- alert: PodNotRunningannotations:summary: Pod状态异常description: Pod {{$labels.pod}} 在命名空间 {{$labels.namespace}} 中不在 Running 状态expr: |kube_pod_status_phase{phase!Running} 0for: 1mlabels:team: k8s-clusterseverity: error创建规则 kubectl apply -f prometheus-pod-rules.yaml 1.4查看报警 这样每个不在 Running 状态的 Pod 都会触发一个单独的告警。 优化 如果有很多pod处于!Running状态会产生很多条告警 优化一 例如你可以将 group_by 参数设置为 [alertname, instance, namespace]这样只要是同一种告警alertname、同一节点instance和同一命名空间namespace即使是不同的 Pod也会被视为同一组告警。 route:receiver: ops-errgroup_wait: 10sgroup_interval: 30srepeat_interval: 30sgroup_by: [alertname, instance, namespace] 优化二 例如你可以定义一个抑制规则当同一命名空间中有多个 Pod 发生告警时只发送一条告警通知 route:receiver: ops-errgroup_wait: 10sgroup_interval: 30srepeat_interval: 30sgroup_by: [alertname, instance, pod, namespace]routes:- matchers:- severity warningreceiver: ops-errcontinue: true- matchers:- severity ~ error|criticalreceiver: devopscontinue: trueinhibit_rules:- source_match:severity: criticaltarget_match:severity: warningequal: [alertname, namespace] 优化三 定义告警规则的抓取时间或者检测pod的时间 route:receiver: ops-errgroup_wait: 10sgroup_interval: 30srepeat_interval: 10m ## 时间改长group_by: [alertname, instance, pod, namespace]apiVersion: monitoring.coreos.com/v1 kind: PrometheusRule metadata:name: nodenamespace: defaultlabels:group: frem-k8s # 添加全局分组标签 spec:groups:- name: pod-statusrules:- alert: PodNotRunningannotations:summary: Pod状态异常description: Pod {{$labels.pod}} 在命名空间 {{$labels.namespace}} 中不在 Running 状态expr: |kube_pod_status_phase{phase!Running} 0for: 1m #时间改长labels:team: k8s-clusterseverity: error2.1-AlertmanagerConfig方式 这个方式我没有做出来如果有大佬 做出来可以私信我 详解一 在 Prometheus Operator 的 AlertmanagerConfig 资源中目前还不支持直接定义企业微信告警。在 AlertmanagerConfig 中接收器receivers只支持以下类型的配置webhookConfigsemailConfigspagerdutyConfigsopsgenieConfigsslackConfigsvictorOpsConfigswechatConfigs 并未在 AlertmanagerConfig 资源的接收器配置中被直接支持。 但是您可以通过 webhook 的方式来实现。您需要自己搭建一个 webhook 服务这个服务接收到 Alertmanager 的告警后再将告警信息发送到企业微信。在 AlertmanagerConfig 中您可以定义一个 webhookConfigs其 url 指向您的 webhook 服务。 下面是一个简单的示例 在这个配置中http://your-webhook-service-address/ops-err 和 http://your-webhook-service-address/devops 应该是您自己的 webhook 服务地址这个服务需要能够接收告警信息并将告警发送到企业微信。 对于如何搭建这样的 webhook 服务您可以参考一些开源项目如 prometheus-webhook-dingtalk虽然这是一个针对钉钉的项目但是其实现方式对于企业微信也是适用的。 详解二 由于企业微信更新问题现在已经无法直接使用创建应用后在alertmanager的配置文件中定义企业id及secret就可以发送告警信息了除非填写备案后域名为了我们这种个人开发者非常的不便所以本文档是为了解决想使用企业微信告警但又无法备案的朋友 方案选择 第一种方案PrometheusAlert Prometheus Alertmanager 实现各种类型告警第二种方案创建 Webhook 服务用于转发 Alertmanager 的告警消息到企业微信机器人方案需求 我后面希望是通过子路由匹配告警级别去分发到不同的告警接收器上面那个方案更适合我 为什么第一种方案PrometheusAlert Prometheus Alertmanager 实现各种类型告警这个不适合 第二种方案创建 Webhook 服务 这里我都给你们推荐参考文档第一种第二种你们可以进行测试 参考文档 第一种 [Prometheus接入AlterManager配置邮件告警(基于K8S环境部署)_prometheus配置邮箱告警-CSDN博客](https://blog.csdn.net/weixin_45310323/article/details/133965945)[Alertmanager实现企业微信机器人webhook告警 - k-free - 博客园 (cnblogs.com)](https://www.cnblogs.com/k-free-bolg/p/17965930)第二种 [kube-prometheus实现企业微信机器人告警_alertmanager企微告警-CSDN博客](https://blog.csdn.net/rendongxingzhe/article/details/127498349)首先恢复你默认的配置 kube-prometheus-0.13.0/manifests# kubectl apply -f alertmanager-secret.yaml2.1创建webhook服务 用于转发alertmanager的告警消息到企业微信机器人 ---apiVersion: apps/v1kind: Deploymentmetadata:labels:run: prometheus-webhook-qywxname: prometheus-webhook-qywxnamespace: monitoringspec:selector:matchLabels:run: prometheus-webhook-qywxtemplate:metadata:labels:run: prometheus-webhook-qywxspec:containers:- args: # 企业微信的webhook-key如何获取可以google一下;很简单,这里不说明了;- --adapter/app/prometheusalert/wx.js/adapter/wx #注意变更这个地址即企业微信机器人的webhook地址image: registry.cn-hangzhou.aliyuncs.com/guyongquan/webhook-adapter name: prometheus-webhook-dingtalkports:- containerPort: 80protocol: TCP---apiVersion: v1kind: Servicemetadata:labels:run: prometheus-webhook-qywxname: prometheus-webhook-qywxnamespace: monitoringspec:ports:- port: 8060protocol: TCPtargetPort: 80selector:run: prometheus-webhook-qywxtype: ClusterIP备注 adapter/app/prometheusalert/wx.js/adapter/wxhttps://qyapi.weixin.qq.com/cgi-bin/webhook/send?keyc3578c16-1a8e-ssssdddd8888888 #注意变更这个地址即企业微信机器人的webhook地址