k8s1.28.8版本配置Alertmanager报警方式(邮件,企业微信)

文章目录

          • 总结部署流程
    • Alertmanager 三大核心
          • 1. 分组告警
          • 2. 告警抑制
          • 3. 告警静默
    • 报警过滤
    • 静默通知
          • 方案一:
          • 方案二:
    • 抑制报警规则
          • 案例一
      • 参考文档
    • 自定义路由告警,分来自不同路由的告警,艾特不同的人员进行区分
    • 修改 alertmanager 配置有俩种方法
        • Alertmanager CRD
      • **案例介绍**
      • **环境概述**
      • **快速开始**
        • 1-查看现有的规则配置文件
    • 1-secret方式
        • 1.2-修改 secret alertmanager-main
          • 1.2.1查看日志看看有没有报错
          • 查看生成的 secret alertmanager-main
          • 1.3- 查看Alertmanager——ui页面
          • 1.4查看报警
    • 1.2 配置告警模板
        • 1.2.1创建 wechat.tmpl模板
        • 1.2.2创建 configmap
    • 1.3查看企业微信报警
        • 分级别告警
    • 设置告警监控所有命名空间pod
        • 1.1修改 alertmanager.yaml
        • 1.2更新 secret
        • 1.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: 10m
2. 告警抑制

通过抑制可以避免产生大量的告警风暴,当一个节点宕机设置标签为serverity=critical,而节点上的应用告警设置为serverity=warning,当节点宕机后可以使用抑制的方法,仅发送一条节点宕机的信息,而不是发送多条信息。

aertManager告警抑制参数

  inhibit_rules:

  - source_match:

// 源标签警报触发时抑制含有目标标签的警报,在当前警报匹配serverity=critical

      serverity: 'critical'                        

    target_match:

// 抑制`serverity=warning`类型告警

      serverity: 'warning'

// 告警中包含的分组名称。标签内容相同才会抑制,也就是说警报中三个标签值相同才会被抑制。equal: ['alertname', 'dev', 'instance']

Prometheus 告警级别

告警级别分为warning、critical和emergency。严重等级依次递增。

3. 告警静默

静默是指定周期时间内不再触发某一个报警。alertManager将检查传入警报是否与活动静默的所有相等或正则表达式匹配。匹配静默规则,则不会为该警报发送任何通知。

Alertmanager Web UI 设置静默告警规则
image.png

报警过滤

有的时候可能报警通知太过频繁,或者在收到报警通知后就去开始处理问题了,这个期间可能报警还在频繁发送,这个时候我们可以去对报警进行静默设置。

静默通知

方案一:

在 Alertmanager 的后台页面中提供了静默操作的入口。
image.png
可以点击右上面的 New Silence 按钮新建一个静默通知

image.png
我们可以选择此次静默的开始时间、结束时间,最重要的是下面的 Matchers 部分,用来匹配哪些报警适用于当前的静默,比如这里我们设置 instance=k8s-node1 的标签,则表示具有这个标签的报警在 2 小时内都不会触发报警,点击下面的 Create 按钮即可创建:

image.png

方案二:

抑制报警规则

除了上面的静默机制之外,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` 规则
案例一

比如现在我们如下所示的两个报警规则 NodeMemoryUsageNodeLoad

apiVersion: monitoring.coreos.com/v1

kind: PrometheusRule

metadata:

  name: node

  namespace: default

spec:

  groups:

  - name: node-mem

    rules:

    - alert: NodeMemoryUsage

      annotations:

        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: 1m

      labels:

        team: node

        severity: critical

  - name: node-load

    rules:

    - alert: NodeLoad

      annotations:

        summary: '{{ $labels.instance }}: 低节点负载检测'

        description: '{{ $labels.instance }}: 节点负载低于 1 (当前值为: {{ $value }})'

      expr: node_load5 < 1

      for: 2m

      labels:

        team: node

        severity: normal

当前我们系统里面普通(severity: normal)的告警有三条,k8s-node1、k8s-node2 和 k8s-master 三个节点,另外一个报警也有俩条,k8s-node1和 k8s-master 三个节点:

image.png

现在我们来配置一个抑制规则,如果 NodeMemoryUsage 报警触发,则抑制 NodeLoad 指标规则引起的报警,我们这里就会抑制 k8s-master 和 k8s-node1 节点的告警,只会剩下 k8s-node2 节点的普通告警。

通过修改Alertmanager 配置文件中添加如下所示的抑制规则

apiVersion: monitoring.coreos.com/v1alpha1
kind: AlertmanagerConfig
metadata:
  name: email-config
  namespace: monitoring
  labels:
    alertmanagerConfig: wangxiansen
spec:
  route:
    groupBy: ['alertname']
    groupWait: 30s
    groupInterval: 5m
    repeatInterval: 12h
    receiver: 'Critical'
    continue: false
    routes:
      - receiver: 'Critical'
        match:
          severity: critical
  receivers:
    - name: Critical
      emailConfigs:
        - to: '@boysec.cn'
          html: '{{ template "email.html" . }}'
          sendResolved: true
  inhibitRules:
  - equal: ['instance']
    sourceMatch:
    - name: alertname
      value: NodeMemoryUsage
    - name: severity
      value: critical
    targetMatch:
    - name: severity
      value: normal

更新报警规则

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

更新配置后,最好重建下 Alertmanager,这样可以再次触发下报警,可以看到只能收到 k8s-node2 节点的 NodeLoad 报警了,另外两个节点的报警被抑制了:
image.png

参考文档

1-alertmanager 实现不同的告警级别发送给不同的接收人

文章参考 https://cloud.tencent.com/developer/article/2216582?areaId=106001

2-自定义路由告警,分来自不同路由的告警,艾特不同的人员进行区分

文章参考  https://cloud.tencent.com/developer/article/2327646?areaId=106001

3-根据不同告警级别设置发送接受器

文章参考 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持续多长时间未接收到告警后标记告警状态为resolved

  http_config: {}        # HTTP 配置,此处为空对象,表示没有特定的配置

  smtp_hello: localhost  # SMTP 邮件发送时使用的 HELO 消息

  smtp_require_tls: true # SMTP 邮件发送是否需要使用 TLS

  pagerduty_url: https://events.pagerduty.com/v2/enqueue     # PagerDuty API URL

  opsgenie_api_url: https://api.opsgenie.com/                # Opsgenie API URL

  wechat_api_url: https://qyapi.weixin.qq.com/cgi-bin/       # 微信企业号 API URL

  victorops_api_url: https://alert.victorops.com/integrations/generic/20131114/alert/  # VictorOps API URL

  

route:

  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  # 源警报的严重程度为 critical

  target_match_re:      # 目标警报匹配条件(使用正则表达式进行匹配)

    severity: warning|info  # 目标警报的严重程度为 warning 或 info

  equal:                # 需要匹配相等的字段

  - namespace           # 命名空间字段需要相等

  - alertname           # 警报名称字段需要相等

- source_match:         # 源警报匹配条件

    severity: warning   # 源警报的严重程度为 warning

  target_match_re:      # 目标警报匹配条件(使用正则表达式进行匹配)

    severity: info      # 目标警报的严重程度为 info

  equal:                # 需要匹配相等的字段

  - namespace           # 命名空间字段需要相等

  - alertname           # 警报名称字段需要相等

  

receivers:     # 接收器列表

- name: Default  # 默认接收器

- name: Watchdog  # Watchdog 接收器

- name: Critical  # Critical 接收器

  

templates: []   # 模板列表,此处为空列表,表示没有定义任何模板

案例介绍

基于自定义路由告警,我们依旧使用prometheusAlert作为告警渠道,为了方便区分来自不同路由的告警,我们这里使用不同分组进行告警

环境概述

root@k8s-master01:~/test/prometheus/prometheus-whach# kubectl get pod -n monitoring 
root@k8s-master01:~/test/prometheus/prometheus-whach# kubectl get node

image.png

快速开始

1-查看现有的规则配置文件
kubectl get secret alertmanager-main -n monitoring -o jsonpath='{.data.alertmanager\.yaml}' |base64 -d

image.png

1-secret方式

新建 alertmanager.yaml 配置文件
相当于总配置文件,需要填写的东西比较多
只需要三个文件
image.png

global:
  resolve_timeout: 1m  # 解决超时时间,指定Alertmanager标记告警状态为已解决(resolved)之前等待的时间

templates:
  - '/etc/alertmanager/configmaps/alertmanager-templates/*.tmpl'

route:
  receiver: 'ops-err'  # 默认的接收器名称
  group_wait: 30s  # 在组内等待所配置的时间,如果同组内,30秒内出现相同报警,在一个组内发送报警。
  group_interval: 1m  # 如果组内内容不变化,合并为一条警报信息,5m后发送。
  repeat_interval: 10m  # 发送报警间隔,如果指定时间内没有修复,则重新发送报警。
  group_by: [alertname, instance]  # 报警分组
  routes:  # 子路由的匹配设置
    - matchers:
        - severity = warning
      receiver: 'ops-err'
      continue: true
      # 使用新的 matchers 语法匹配严重级别为 warning 的告警,并发送到 ops-err 接收器

    - matchers:
        - severity =~ error|critical
      receiver: 'devops'
      continue: true
      # 使用新的 matchers 语法和正则表达式匹配严重级别为 error 或 critical 的告警,并发送到 devops 接收器

receivers:
  - name: 'devops'
    wechat_configs:
      - corp_id: '' # 企业ID
        to_user: '@all'  # 发送所有人
        agent_id: '1000002'  # agentID
        api_secret: ''  # secret
        # 使用企业微信发送消息

  - name: 'ops-critical'
    wechat_configs:
      - corp_id: '' # 企业ID
        to_user: '@all'  # 发送所有人
        agent_id: '1000005'  # agentID
        api_secret: ''  # secret
        # 使用企业微信发送消息

  - name: 'ops-err'
    wechat_configs:
      - corp_id: '' # 企业ID
        to_user: '@all'  # 发送所有人
        agent_id: '1000003'  # agentID
        api_secret: ''  # secret
        # 使用企业微信发送消息
1.2-修改 secret alertmanager-main
kubectl create secret generic alertmanager-main -n monitoring --from-file=alertmanager.yaml --dry-run=client -o yaml > alertmanager-main-secret.yaml 


kubectl apply -f alertmanager-main-secret.yaml
1.2.1查看日志看看有没有报错
kubectl logs -f prometheus-operator-68f6c79f9d-24fcm -n monitoring 

image.png

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

image.png

之后 prometheus-operator 会自动更新 alertmanager 的配置

# kubectl logs -n monitoring -l app.kubernetes.io/name=prometheus-operator | tail -1 

level=info ts=2023-04-30T11:43:01.104579363Z caller=operator.go:741 component=alertmanageroperator key=monitoring/main msg="sync alertmanager"
1.3- 查看Alertmanager——ui页面

规则变成你定义的拉
image.png
查报警的分组也变成你得定义的路由规则
image.png

1.4查看报警

image.png

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-file=wechat.tmpl --dry-run=client -o yaml -n monitoring > alertmanager-configmap-templates.yaml 


kubectl apply -f alertmanager-configmap-templates.yaml

查看挂载

root@k8s-master01:~/test/prometheus/prometheus-whach/route# kubectl get pod -n monitoring alertmanager-main-0 -o jsonpath="{.spec.volumes[?(@.name=='configmap-alertmanager-templates')]}" | python3 -m json.tool
{
    "configMap": {
        "defaultMode": 420,
        "name": "alertmanager-templates"
    },
    "name": "configmap-alertmanager-templates"
}

image.png

查看容器内的路径

# kubectl exec -it alertmanager-main-0 -n monitoring -- cat /etc/alertmanager/configmaps/alertmanager-templates/wechat.tmpl

image.png

1.3查看企业微信报警

分级别告警

image.png

image.png

设置告警监控所有命名空间pod

1.1修改 alertmanager.yaml

增加命名空间跟pod

global:
  resolve_timeout: 1m

templates:
  - '/etc/alertmanager/configmaps/alertmanager-templates/*.tmpl'

route:
  receiver: 'ops-err'
  group_wait: 10s
  group_interval: 30s
  repeat_interval: 30s
  group_by: [alertname, instance, pod, namespace]
  routes:
    - matchers:
        - severity = warning
      receiver: 'ops-err'
      continue: true

    - matchers:
        - severity =~ error|critical
      receiver: 'devops'
      continue: true

receivers:
  - name: 'devops'
    wechat_configs:
      - corp_id: ''
        to_user: '@all'
        agent_id: '1000002'
        api_secret: ''

  - name: 'ops-critical'
    wechat_configs:
      - corp_id: ''
        to_user: '@all'
        agent_id: '1000005'
        api_secret: ''

  - name: 'ops-err'
    wechat_configs:
      - corp_id: ''
        to_user: '@all'
        agent_id: '1000003'
        api_secret: ''

详解

在你的配置中,`group_by: [alertname, instance, pod, namespace]` 的含义是:

- `alertname`: 告警的名称。这通常是在 Prometheus 告警规则中定义的告警类型,例如 `PodNotRunning`。
- `instance`: 发生告警的实例。在 Kubernetes 监控中,这通常是 Pod 的 IP 地址或者节点的 IP 地址。
- `pod`: 发生告警的 Pod 的名称。
- `namespace`: 发生告警的 Pod 所在的命名空间。

只有当这四个标签都相同时,告警才会被归为同一组。这意味着,即使是同一种告警(`alertname`)和同一节点(`instance`),只要是不同的 Pod 或者命名空间,也会被视为不同的告警组,会单独触发一个告警。

例如,如果有两个告警:

- 告警 A: `{alertname="PodNotRunning", instance="10.0.0.1", pod="pod-1", namespace="ns-1"}`
- 告警 B: `{alertname="PodNotRunning", instance="10.0.0.1", pod="pod-2", namespace="ns-1"}`

尽管它们的 `alertname` 和 `instance` 都相同,但是 `pod` 不同,所以它们会被视为两个不同的告警组,会分别触发两个告警。

image.png

1.2更新 secret
kubectl create secret generic alertmanager-main -n monitoring --from-file=alertmanager.yaml --dry-run -oyaml > alertmanager-main-secret.yaml kubectl apply -f alertmanager-main-secret.yaml
1.3配置告警规则
vim  prometheus-pod-rules.yaml
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: node
  namespace: default
  labels:
    group: frem-k8s  # 添加全局分组标签
spec:
  groups:
  - name: pod-status
    rules:
    - alert: PodNotRunning
      annotations:
        summary: 'Pod状态异常'
        description: 'Pod {{$labels.pod}} 在命名空间 {{$labels.namespace}} 中不在 Running 状态'
      expr: |
        kube_pod_status_phase{phase!="Running"} > 0
      for: 1m
      labels:
        team: k8s-cluster
        severity: error

创建规则 kubectl apply -f prometheus-pod-rules.yaml

1.4查看报警

image.png

这样,每个不在 Running 状态的 Pod 都会触发一个单独的告警。

优化

如果有很多pod处于!="Running状态,会产生很多条告警

优化一:

例如,你可以将 group_by 参数设置为 [alertname, instance, namespace],这样,只要是同一种告警(alertname)、同一节点(instance)和同一命名空间(namespace),即使是不同的 Pod,也会被视为同一组告警。

route:
  receiver: 'ops-err'
  group_wait: 10s
  group_interval: 30s
  repeat_interval: 30s
  group_by: [alertname, instance, namespace]

优化二

例如,你可以定义一个抑制规则,当同一命名空间中有多个 Pod 发生告警时,只发送一条告警通知:

route:
  receiver: 'ops-err'
  group_wait: 10s
  group_interval: 30s
  repeat_interval: 30s
  group_by: [alertname, instance, pod, namespace]
  routes:
    - matchers:
        - severity = warning
      receiver: 'ops-err'
      continue: true
    - matchers:
        - severity =~ error|critical
      receiver: 'devops'
      continue: true

inhibit_rules:
  - source_match:
      severity: 'critical'
    target_match:
      severity: 'warning'
    equal: ['alertname', 'namespace']

优化三

定义告警规则的抓取时间,或者检测pod的时间

route:
  receiver: 'ops-err'
  group_wait: 10s
  group_interval: 30s
  repeat_interval: 10m   ## 时间改长
  group_by: [alertname, instance, pod, namespace]
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: node
  namespace: default
  labels:
    group: frem-k8s  # 添加全局分组标签
spec:
  groups:
  - name: pod-status
    rules:
    - alert: PodNotRunning
      annotations:
        summary: 'Pod状态异常'
        description: 'Pod {{$labels.pod}} 在命名空间 {{$labels.namespace}} 中不在 Running 状态'
      expr: |
        kube_pod_status_phase{phase!="Running"} > 0
      for: 1m  #时间改长
      labels:
        team: k8s-cluster
        severity: error

2.1-AlertmanagerConfig方式

这个方式我没有做出来,如果有大佬 做出来可以私信我

详解一

在 Prometheus Operator 的 AlertmanagerConfig 资源中,目前还不支持直接定义企业微信告警。在 AlertmanagerConfig 中,接收器(receivers)只支持以下类型的配置:webhookConfigsemailConfigspagerdutyConfigsopsgenieConfigsslackConfigsvictorOpsConfigswechatConfigs 并未在 AlertmanagerConfig 资源的接收器配置中被直接支持。

但是,您可以通过 webhook 的方式来实现。您需要自己搭建一个 webhook 服务,这个服务接收到 Alertmanager 的告警后,再将告警信息发送到企业微信。在 AlertmanagerConfig 中,您可以定义一个 webhookConfigs,其 url 指向您的 webhook 服务。

下面是一个简单的示例:
在这个配置中,http://your-webhook-service-address/ops-errhttp://your-webhook-service-address/devops 应该是您自己的 webhook 服务地址,这个服务需要能够接收告警信息并将告警发送到企业微信。

对于如何搭建这样的 webhook 服务,您可以参考一些开源项目,如 prometheus-webhook-dingtalk(虽然这是一个针对钉钉的项目,但是其实现方式对于企业微信也是适用的)。

详解二:

由于企业微信更新问题,现在已经无法直接使用创建应用后在alertmanager的配置文件中定义企业id及secret就可以发送告警信息了,除非填写备案后域名;为了我们这种个人开发者非常的不便,所以本文档是为了解决想使用企业微信告警但又无法备案的朋友

方案选择:

第一种方案:PrometheusAlert + Prometheus + Alertmanager 实现各种类型告警

第二种方案:创建 Webhook 服务,用于转发 Alertmanager 的告警消息到企业微信机器人

image.png

方案需求

我后面希望是通过子路由匹配告警级别,去分发到不同的告警接收器,上面那个方案更适合我
image.png
为什么第一种方案:PrometheusAlert + Prometheus + Alertmanager 实现各种类型告警这个不适合

image.png

第二种方案:创建 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.yaml

image.png

2.1创建webhook服务

用于转发alertmanager的告警消息到企业微信机器人

---

apiVersion: apps/v1

kind: Deployment

metadata:

  labels:

    run: prometheus-webhook-qywx

  name: prometheus-webhook-qywx

  namespace: monitoring

spec:

  selector:

    matchLabels:

      run: prometheus-webhook-qywx

  template:

    metadata:

      labels:

        run: prometheus-webhook-qywx

    spec:

      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-dingtalk

        ports:

        - containerPort: 80

          protocol: TCP

---

apiVersion: v1

kind: Service

metadata:

  labels:

    run: prometheus-webhook-qywx

  name: prometheus-webhook-qywx

  namespace: monitoring

spec:

  ports:

  - port: 8060

    protocol: TCP

    targetPort: 80

  selector:

    run: prometheus-webhook-qywx

  type: ClusterIP

image.png

备注:
adapter=/app/prometheusalert/wx.js=/adapter/wx=https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=c3578c16-1a8e-ssssdddd8888888 #注意变更这个地址,即企业微信机器人的webhook地址

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:/a/505582.html

如若内容造成侵权/违法违规/事实不符,请联系我们进行投诉反馈qq邮箱809451989@qq.com,一经查实,立即删除!

相关文章

中缀转后缀表达式

思路分析 遇到数字&#xff0c;直接输出遇到符号 栈为空&#xff0c;符号直接入栈若为 ( &#xff0c;则直接入栈用当前符号和栈顶符号比较优先级 当前符号 > 栈顶符号&#xff0c;当前符号直接入栈&#xff0c;结束当前符号 < 栈顶符号,栈顶符号出栈并输出&#xff0c;…

verilog中的testbench语句——display,fopen,fread,fwrite——更新中

一、fopen bmp_file_read $fopen("../pic/picture.bmp","rb"); 要注意这类操作文件的函数&#xff0c;在vivado2018自带的仿真软件里&#xff0c;不综合直接仿真&#xff0c;它的当前文件夹如图所示。 一、fwrite $fwrite(bmp_file_write,"%c"…

【Effective Web】页面优化

页面优化 页面渲染流程 JavaScript 》 Style 》 Layout 》 Paint 》 Composite 首先js做了一些逻辑&#xff0c;触发了样式变化&#xff0c;style计算好这些变化后&#xff0c;把影响的dom元素进行重新布局&#xff08;layout&#xff09;,再画到画布中&#xff08;Paint&am…

【数据结构与算法】二叉树遍历、判断和 diff 算法

遍历 深度优先遍历 function Node(value) {this.value valuethis.left nullthis.right null }let a new Node(a) let b new Node(b) let c new Node(c) let d new Node(d) let e new Node(e) let f new Node(f) let g new Node(g) a.left c a.right b c.l…

如何提升公众号搜索量?分享内部运营的5步优化技术!

最近一直有自媒体同行朋友在写关于公众号的内容&#xff0c;很多都说公众号现在没得玩了。其实&#xff0c;在运营自媒体上面&#xff0c;思维不通&#xff0c;技术不到位&#xff0c;哪个平台都不适合你玩。 想要在自媒体上面运营变现&#xff0c;一定不要先点击广告变现&…

【二分查找】查找数列中数第一次出现的编号

一道巩固二分查找知识的题&#xff0c;非常简单&#xff0c;一起做一下吧 题目&#xff1a; 答案&#xff1a; #include<iostream> #include<algorithm> #include<cstring> using namespace std; const int N1000010;int n,m; int q[N];bool isBlue(int num…

7种2024年算法优化BP,实现回归,单/多变量输入,单/多步预测功能,机器学习预测全家桶再更新!...

截止到本期MATLAB机器学习预测全家桶&#xff0c;一共发了19篇关于机器学习预测代码的文章。算上这一篇&#xff0c;一共20篇&#xff01;参考文章如下&#xff1a; 1.五花八门的机器学习预测&#xff1f;一篇搞定不行吗&#xff1f; 2.机器学习预测全家桶&#xff0c;多步预测…

中文乱码 一文讲解 字符集和字符编码 不再困惑(有源码)

初级代码游戏的专栏介绍与文章目录-CSDN博客 我的github&#xff1a;codetoys&#xff0c;所有代码都将会位于ctfc库中。已经放入库中我会指出在库中的位置。 这些代码大部分以Linux为目标但部分代码是纯C的&#xff0c;可以在任何平台上使用。 这可能是应用级程序员最困惑的…

SSTI 服务器端模板注入(Server-Side Template Injection)

1.Web_python_template_injection {{}}是变量包裹标识符&#xff0c;里面存放的是一个变量&#xff0c;当你输入 http://61.147.171.105:55121/{{8*8}} 执行成功&#xff0c;说明存在模版注入。接下来&#xff0c;开始想办法编代码拿到服务器的控制台权限 。 首先&#xff0c…

Redis 命令行客户端

目 录 redis 客户端介绍 redis 客户端介绍 redis 是一个 客户端-服务器 结构的程序&#xff01;&#xff01;&#xff08;类似于 MySQL&#xff09; 因此 redis 客户端和服务器 可以在同一个主机上&#xff0c;也可以在不同主机上. Redis 的客户端也有很多种形态&#xff1a;…

2024 批量下载吾爱破解公众号文章内容/话题/图片/封面/视频/音频,导出文章pdf合集,excel数据包含阅读数留言数粉丝数

前几天看到吾爱破解论坛公众号文章吾爱破解精华集2023&#xff0c;于是把吾爱破解论坛公众号2022-2023年所有公众号文章也下载做成合集分享给大家&#xff0c;网盘地址https://pan.quark.cn/s/9c1b60b822a7 下载的excel文章数据包含文章日期&#xff0c;文章标题&#xff0c;文…

基于springboot实现图书个性化推荐系统项目【项目源码+论文说明】

基于springboot实现图书个性化推荐系统演示 摘要 本论文主要论述了如何使用JAVA语言开发一个图书个性化推荐系统&#xff0c;本系统将严格按照软件开发流程进行各个阶段的工作&#xff0c;采用B/S架构&#xff0c;面向对象编程思想进行项目开发。在引言中&#xff0c;作者将论…

risc-v向量扩展strlen方法学习

riscv向量文档中给出了strlen的实现&#xff0c; 大概是这么一个思路&#xff0c; 加载向量: 使用向量加载指令&#xff08;如 vload&#xff09;从内存中加载一个向量长度的字符。比较向量与零: 使用向量比较指令&#xff08;如 vmask 或 vcmpeq&#xff09;来检查向量中的每…

Js之运算符与表达式

运算符&#xff1a;也叫操作符&#xff0c;是一种符号。通过运算符可以对一个或多个值进行运算&#xff0c;并获取运算结果。 表达式&#xff1a;由数字、运算符、变量的组合&#xff08;组成的式子&#xff09;。 表达式最终都会有一个运算结果&#xff0c;我们将这个结果称…

【电路笔记】-快速了解数字逻辑门

快速了解数字逻辑门 文章目录 快速了解数字逻辑门1、概述2、集成电路的分类3、摩尔定律4、数字逻辑状态5、数字逻辑噪声6、简单的基本数字逻辑门7、基本 TTL 逻辑门8、发射极耦合数字逻辑门9、集成电路的“74”子族10、基本 CMOS 数字逻辑门数字逻辑门是一种电子电路,它根据其…

C++从入门到精通——引用()

C的引用 前言一、C引用概念二、引用特性交换指针引用 三、常引用保证值不变权限的方法权限的放大权限的缩小权限的平移类型转换临时变量 四、引用的使用场景1. 做参数2. 做返回值 五、传值、传引用效率比较值和引用的作为返回值类型的性能比较 六、引用和指针的区别引用和指针的…

动态规划-最长回文子串

动态规划-最长回文子串 原题描述解答中心移动思想代码实现复杂度分析时间复杂度空间复杂度 动态规划思想代码实现复杂度分析时间复杂度空间复杂度 突然觉得很有必要将学过的内容记录下来&#xff0c;这样后续在需要用到的时候就可以避免从头进行学习&#xff0c;而去看自己之前…

调试技巧安全预编译头文件(C++基础)

调试 调试可以选择条件调试和操作调试&#xff1a; 条件调试来选择条件进入断点设置&#xff0c;操作调试来使达到断点条件后完成某些操作&#xff08;一般是output窗口输出&#xff09;。 在这里就只输出了小于6的条件。 安全 降低崩溃、内存泄露、非法访问等问题。 应该转…

GetSystemTimes:获取CPU占用率(WIN API)

原文链接&#xff1a;https://blog.csdn.net/qq_28742901/article/details/104960653 GetSystemTimes函数&#xff1a; BOOL WINAPI GetSystemTimes(__out_opt LPFILETIME lpIdleTime, // 空闲时间__out_opt LPFILETIME lpKernelTime, // 内核进程占用时间__out_opt LPFILETI…

【JavaWeb】Day29.SpringBootWeb请求响应——请求(二)

请求响应 4.数组集合参数 数组集合参数的使用场景&#xff1a;在HTML的表单中&#xff0c;有一个表单项是支持多选的(复选框)&#xff0c;可以提交选择的多个值。 4.1 数组 数组参数&#xff1a;请求参数名与形参数组名称相同且请求参数为多个&#xff0c;定义数组类型形参即…