Prometheus监控- 第3天

最新推荐文章于 2024-09-30 08:30:14 发布
最新推荐文章于 2024-09-30 08:30:14 发布
阅读量876 收藏 15
点赞数 21
文章标签： prometheus 服务器 数据库
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_26825559/article/details/141469734
版权

7.7 基于Prometheus的全方位监控平台–告警平台(Alertmanager)部署管理

基于Prometheus的全方位监控平台–告警平台(Alertmanager)部署管理一、AlertManager简介1.1、AlertManager 常用的功能1.2、Prometheus 和 AlertManager 的关系二、部署搭建Alertmanager2.1、创建AlertManager数据的存储PVC资源 alertmanager-storage.yaml2.2、创建AlertManager配置文件ConfigMap（邮件方式）2.3、创建AlertManager部署文件 alertmanager-deploy.yaml2.4、创建AlertManager外部服务暴露 alertmanager-ingress.yaml三、AlertManager的三个核心概念3.1、分组3.2、抑制3.3、静默四、Prometheus添加告警配置五、总结
基于Prometheus的全方位监控平台–告警平台(Alertmanager)部署管理
一、AlertManager简介

官网： https://prometheus.io/docs/alerting/latest/alertmanager

1.1、AlertManager 常用的功能

  • 抑制：指的是当某一告警信息发送后，可以停止由此告警引发的其它告警，避免相同的告警信息重复发送。
  • 静默：静默也是一种机制，指的是依据设置的标签，对告警行为进行静默处理。
  • 发送告警：支持配置多种告警规则，可以根据不同的路由配置，采用不同的告警方式发送告警通知。
  • 告警分组：分组机制可以将详细的告警信息合并成一个通知。
    1.2、Prometheus 和 AlertManager 的关系

二、部署搭建Alertmanager

2.1、创建AlertManager数据的存储PVC资源 alertmanager-storage.yaml

apiVersion: v1

kind: PersistentVolumeClaim

metadata:

  name: alertmanager-pvc

  namespace: monitor

spec:

  accessModes:

    - ReadWriteMany

  storageClassName: "nfs-storage"

  resources:

    requests:

      storage: 5Gi

2.2、创建AlertManager配置文件ConfigMap（邮件方式）

apiVersion: v1

kind: ConfigMap

metadata:

  name: alertmanager-config

  namespace: monitor

data:

  alertmanager.yml: |-

    global:

      resolve_timeout: 1m

      smtp_smarthost: 'smtp.exmail.qq.com:465'     # 邮箱服务器的SMTP主机配置

      smtp_from: 'zhdya@zhdya.cn'    # 发送邮件主题

      smtp_auth_username: 'zhdya@zhdya.cn'      # 登录用户名

      smtp_auth_password: 'XXXyfXBjd6J73DwYTjn'    # 此处的auth password是邮箱的第三方登录授权密码，而非用户密码

      smtp_require_tls: false           # 有些邮箱需要开启此配置，这里使用的是企微邮箱，仅做测试，不需要开启此功能。
      
    templates:

      - '/etc/alertmanager/*.tmpl'

    route:

      group_by: ['env','instance','type','group','job','alertname','cluster']   # 报警分组

      group_wait: 5s      # 在组内等待所配置的时间，如果同组内，5秒内出现相同报警，在一个组内出现。

      group_interval: 1m        # 如果组内内容不变化，合并为一条警报信息，2m后发送。

      repeat_interval: 2m    # 发送报警间隔，如果指定时间内没有修复，则重新发送报警。

      receiver: 'email'

      routes:

      - receiver: 'devops'

        match:

          severity: critical22

        group_wait: 5s

        group_interval: 5m

        repeat_interval: 30m

    receivers:

    - name: 'email'

      email_configs:

      - to: 'zhdya@qq.com'

        send_resolved: true

        html: '{{ template "email.to.html" . }}'

    - name: 'devops'

      email_configs:

      - to: 'zhdyaa@163.com,10000@qq.com'

        send_resolved: true

        html: '{{ template "email.to.html" . }}'

    inhibit_rules:    # 抑制规则

      - source_match:       # 源标签警报触发时抑制含有目标标签的警报，在当前警报匹配 servrity: 'critical'

          severity: 'critical'

        target_match:

          severity: 'warning'    # 目标标签值正则匹配，可以是正则表达式如: ".*MySQL.*"

        equal: ['alertname', 'dev', 'instance']    # 确保这个配置下的标签内容相同才会抑制，也就是说警报中必须有这三个标签值才会被抑制。

  wechat.tmpl: |-

    {{ define "wechat.default.message" }}

    {{- if gt (len .Alerts.Firing) 0 -}}

    {{- range $index, $alert := .Alerts -}}

    {{- if eq $index 0 }}

    ========= 监控报警 =========

    告警状态：{{   .Status }}

    告警级别：{{ .Labels.severity }}

    告警类型：{{ $alert.Labels.alertname }}

    故障主机: {{ $alert.Labels.instance }}

    告警主题: {{ $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 }}

    ========= 告警恢复 =========

    告警类型：{{ .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 }}

  email.tmpl: |-

    {{ define "email.from" }}xxx.com{{ end }}

    {{ define "email.to" }}xxx.com{{ end }}

    {{ define "email.to.html" }}

    {{- if gt (len .Alerts.Firing) 0 -}}

    {{ range .Alerts }}

    ========= 监控报警 =========


    告警程序: prometheus_alert 


    告警级别: {{ .Labels.severity }} 


    告警类型: {{ .Labels.alertname }} 


    告警主机: {{ .Labels.instance }} 


    告警主题: {{ .Annotations.summary }}  


    告警详情: {{ .Annotations.description }} 


    触发时间: {{ .StartsAt.Format "2006-01-02 15:04:05" }} 


    ========= = end =  =========


    {{ end }}{{ end -}}



    {{- if gt (len .Alerts.Resolved) 0 -}}

    {{ range .Alerts }}

    ========= 告警恢复 =========


    告警程序: prometheus_alert 


    告警级别: {{ .Labels.severity }} 


    告警类型: {{ .Labels.alertname }} 


    告警主机: {{ .Labels.instance }} 


    告警主题: {{ .Annotations.summary }} 


    告警详情: {{ .Annotations.description }} 


    触发时间: {{ .StartsAt.Format "2006-01-02 15:04:05" }} 


    恢复时间: {{ .EndsAt.Format "2006-01-02 15:04:05" }} 


    ========= = end =  =========


    {{ end }}{{ end -}}
    
    {{- end }}

参数说明：

global:

  resolve_timeout: 5m    ##超时,默认5min

  smtp_smarthost: 'smtp.exmail.qq.com:25'

  smtp_from: 'xxxxxxx'

  smtp_auth_username: 'xxxx'

  smtp_auth_password: '123'

  smtp_require_tls: false

templates:    ##告警模板(可定义多个)

  - '/etc/alertmanager/*.tmpl'

##route:用来设置报警的分发策略。Prometheus的告警先是到达alertmanager的根路由(route)，alertmanager的根路由不能包含任何匹配项，因为根路由是所有告警的入口点

##另外，根路由需要配置一个接收器(receiver)，用来处理那些没有匹配到任何子路由的告警（如果没有配置子路由，则全部由根路由发送告警），即缺省

##接收器。告警进入到根route后开始遍历子route节点，如果匹配到，则将告警发送到该子route定义的receiver中，然后就停止匹配了。因为在route中

##continue默认为false，如果continue为true，则告警会继续进行后续子route匹配。如果当前告警仍匹配不到任何的子route，则该告警将从其上一级(

##匹配)route或者根route发出（按最后匹配到的规则发出邮件）。查看你的告警路由树，https://www.prometheus.io/webtools/alerting/routing-tree-editor/,

##将alertmanager.yml配置文件复制到对话框，然后点击"Draw Routing Tree"

route:

  group_by: ['env','instance','type','group','job','alertname','cluster']    ##用于分组聚合，对告警通知按标签(label)进行分组，将具有相同标签或相同告警名称(alertname)的告警通知聚合在一个组，然后作为一个通知发送。如果想完全禁用聚合，可以设置为group_by: [...]

  group_wait: 10s    ##当一个新的告警组被创建时，需要等待'group_wait'后才发送初始通知。这样可以确保在发送等待前能聚合更多具有相同标签的告警，最后合并为一个通知发送

  group_interval: 2m    ##当第一次告警通知发出后，在新的评估周期内又收到了该分组最新的告警，则需等待'group_interval'时间后，开始发送为该组触发的新告警，可以简单理解为，group就相当于一个通道(channel)

  repeat_interval: 10m    ##告警通知成功发送后，若问题一直未恢复，需再次重复发送的间隔(根据实际情况来调整)

  receiver: 'email'        ##配置告警消息接收者，与下面配置的对应，例如常用的 email、wechat、slack、webhook 等消息通知方式。

  routes:    ##子路由

  - receiver: 'wechat'

    match:    ##通过标签去匹配这次告警是否符合这个路由节点；也可以使用match_re进行正则匹配

      severity: error    ##标签severity为error时满足条件使用wechat警报

      continue: true   ##匹配到这个路由后是否继续匹配，默认flase

receivers:    ##配置报警信息接收者信息

- name: 'email' ##警报接收者名称

  email_configs:

  - to: 'xxxxxx'  ##接收警报的email（可引用模板文件中定义的变量）,可定义多个

##    html: '{{ template "email.to.html" .}}' ##发送邮件的内容（调用模板文件中的）

    helo: 'alertmanager.com' #alertmanager的地址

    send_resolved: true #故障恢复后通知

 

- name: 'wechat'

  wechat_configs:

  - corp_id: xxxxxxxxx    ##企业信息

    to_user: '@all'        ##发送给企业微信用户的ID，这里是所有人

    agent_id: xxxxx    ##企业微信AgentId

    api_secret: xxxxxxxxx        ##企业微信Secret 

##    message: '{{ template "wechat.default.message" .}}'    ##发送内容(调用模板里面的微信模板)

    send_resolved: true         ##故障恢复后通知

 

inhibit_rules:        ##抑制规则配置，当存在与另一组匹配的警报（源）时，抑制规则将禁用与一组匹配的警报（目标）

  - source_match:

      severity: 'critical'

    target_match:

      severity: 'warning'

    equal: ['alertname', 'dev', 'instance']

2.3、创建AlertManager部署文件 alertmanager-deploy.yaml

apiVersion: v1

kind: Service

metadata:

  name: alertmanager

  namespace: monitor

  labels:

    k8s-app: alertmanager

spec:

  type: ClusterIP

  ports:

  - name: http

    port: 9093

    targetPort: 9093

  selector:

    k8s-app: alertmanager

---

apiVersion: apps/v1

kind: Deployment

metadata:

  name: alertmanager

  namespace: monitor

  labels:

    k8s-app: alertmanager

spec:

  replicas: 1

  selector:

    matchLabels:

      k8s-app: alertmanager

  template:

    metadata:

      labels:

        k8s-app: alertmanager

    spec:

      containers:

      - name: alertmanager

        image: prom/alertmanager:v0.24.0

        imagePullPolicy: IfNotPresent

        ports:

        - name: http

          containerPort: 9093

        args:

        ## 指定容器中AlertManager配置文件存放地址 (Docker容器中的绝对位置)

        - "--config.file=/etc/alertmanager/alertmanager.yml"

        ## 指定AlertManager管理界面地址，用于在发生的告警信息中,附加AlertManager告警信息页面地址

        - "--web.external-url=https://alertmanager.kubernets.cn"  

        ## 指定监听的地址及端口

        - '--cluster.advertise-address=0.0.0.0:9093'

        ## 指定数据存储位置 (Docker容器中的绝对位置)

        - "--storage.path=/alertmanager"

        resources:

          limits:

            cpu: 1000m

            memory: 512Mi

          requests:

            cpu: 1000m

            memory: 512Mi

        readinessProbe:

          httpGet:

            path: /-/ready

            port: 9093

          initialDelaySeconds: 5

          timeoutSeconds: 10

        livenessProbe:

          httpGet:

            path: /-/healthy

            port: 9093

          initialDelaySeconds: 30

          timeoutSeconds: 30

        volumeMounts:

        - name: data

          mountPath: /alertmanager 

        - name: config

          mountPath: /etc/alertmanager

      - name: configmap-reload

        image: jimmidyson/configmap-reload:v0.7.1

        args:

        - "--volume-dir=/etc/config"

        - "--webhook-url=http://localhost:9093/-/reload"

        resources:

          limits:

            cpu: 100m

            memory: 100Mi

          requests:

            cpu: 100m

            memory: 100Mi

        volumeMounts:

        - name: config

          mountPath: /etc/config

          readOnly: true

      volumes:

      - name: data

        persistentVolumeClaim:

          claimName: alertmanager-pvc

      - name: config

        configMap:

          name: alertmanager-config

2.4、创建AlertManager外部服务暴露 alertmanager-ingress.yaml

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

  namespace: monitor

  name: alertmanager-ingress

spec:

  ingressClassName: nginx

  rules:

  - host: alertmanager.kubernets.cn

    http:

      paths:

        - pathType: Prefix

          backend:

            service:

              name: alertmanager

              port:

                number: 9093

          path: /

访问验证：

$ curl http://alertmanager.kubernets.cn

三、AlertManager的三个核心概念

3.1、分组

被触发的警报合并为一个警报进行通知，避免瞬间突发性的接受大量警报通知，使得管理员无法对问题进行快速定位。
场景：
在Kubernetes集群中，运行着重量级规模的实例，即便是集群中持续很小一段时间的网络延迟或者延迟导致网络抖动，也会引发大量类似服务应用无法连接 DB 的故障。如果在警报规则中定义每一个应用实例都发送警报，那么到最后的结果就是会有大量的警报信息通过Alertmanager发送给咱们的运维及研发小伙伴。
3.2、抑制

Inhibition 是 当某条警报已经发送，停止重复发送由此警报引发的其他异常或故障的警报机制。
场景：
在我们的灾备体系中，当原有集群故障宕机业务彻底无法访问的时候，会把用户流量切换到备份集群中，这样为故障集群及其提供的各个微服务状态发送警报机会失去了意义，此时， Alertmanager 的抑制特性就可以在一定程度上避免管理员收到过多无用的警报通知。
3.3、静默

Silences 提供了一个简单的机制，根据标签快速对警报进行静默处理；对传进来的警报进行匹配检查，如果接受到警报符合静默的配置，Alertmanager 则不会发送警报通知。
场景：

  • 用于解决严重生产故障问题时，因所花费的时间过长，通过静默设置避免接收到过多的无用通知；
  • 在已知的例行维护中，为了防止对例行维护的机器发送不必要的警报；
    四、Prometheus添加告警配置

修改ConfigMap资源文件prometheus-config.yaml，改动内容如下:

  • 添加AlertManager服务器地址
  • 指定告警规则文件路径位置
  • 添加Prometheus中触发告警的告警规则（已经简单添加了2条）
    修改 prometheus-config.yaml
apiVersion: v1

kind: ConfigMap

metadata:

  name: prometheus-config

  namespace: monitoring

data:

  prometheus.yml: |

    global:

      scrape_interval:     15s

      evaluation_interval: 15s

      external_labels:

        cluster: "kubernetes"

    ############ 添加配置 Aertmanager 服务器地址 ###################

    alerting:

      alertmanagers:

      - static_configs:

        - targets: ["alertmanager:9093"] 

    ############ 指定告警规则文件路径位置 ###################

    rule_files: 
    - /etc/prometheus/*-rule.yml

按上面方法重载 Prometheus，打开 Prometheus 的 Target 页面，就会看到 上面定义的 mysql-exporter 任务

$ curl -XPOST http://prometheus.kubernets.cn/-/reload

Prometheus UI查看配置和告警规则是否生效
告警规则是否生效：

$ curl -XPOST -H 'Content-Type: application/json' http://alertmanager.kubernets.cn/api/v1/alerts -d 
'[{"labels":{"severity":"critical22"},"annotations":{"summary":"This is a test alert"}}]'

五、总结

  • 灵活性：Alertmanager提供了灵活的配置选项，允许用户根据自己的需求定义警报规则和接收警报的方式，同时支持多个不同层面的媒介进行告警通知。
  1. 可视化：Alertmanager提供了丰富的可视化功能，包括交互式控制台和Web界面，使用户可以轻松地查看警报和监控状态，以及管理警报的路由和通知。
  2. 多功能：通过分组，抑制，静默等多功能。这意味着这款工具可以适配更多的场景，做不同维度的功能释放。
  3. 与Prometheus的集成：Alertmanager是由Prometheus团队开发的，这意味着它与Prometheus监控系统紧密集成。Alertmanager可以与Prometheus进行无缝协作，从而实现更全面、更高效的监控和警报功能。

7.8 基于Prometheus的全方位监控平台–告警平台(Alertmanager)高级配置

一、基于企业微信的报警媒介
实时告警通知：企业微信/钉钉等即时通信工具能够实现实时的告警通知，使得团队成员能够及时响应和解决问题。
通知范围更广：基于企业微信/钉钉的告警通知可以通过群组和@某人的方式，将告警通知发送给更广泛的接收者，避免出现漏报的情况。
告警信息更直观：企业微信/钉钉等通信工具提供了更丰富的告警信息呈现方式，例如文本消息、链接、图片、语音等，使得告警信息更加直观和易于理解。

apiVersion: v1
kind: ConfigMap
metadata:
  name: alertmanager-config
  namespace: monitor
data:
  alertmanager.yml: |-
    global:
      resolve_timeout: 1m
      smtp_smarthost: 'smtp.exmail.qq.com:465'     # 邮箱服务器的SMTP主机配置
      smtp_from: 'zhdya@zhdya.cn'    # 发送邮件主题
      smtp_auth_username: 'zhdya@zhdya.cn'      # 登录用户名
      smtp_auth_password: 'yfXBjd6J73DwYTjn'    # 此处的auth password是邮箱的第三方登录授权密码，而非用户密码
      smtp_require_tls: false           # 有些邮箱需要开启此配置，这里使用的是企微邮箱，仅做测试，不需要开启此功能。

    templates:
      - '/etc/alertmanager/*.tmpl'
    route:
      group_by: ['env','instance','type','group','job','alertname','cluster']
      group_wait: 10s
      group_interval: 2m
      repeat_interval: 10m
      receiver: 'email'
      routes:
      - receiver: 'wechat'
        match:
          severity: critical

    receivers:
    - name: 'email'
      email_configs:
      - to: 'zhdyaa@163.com'
        send_resolved: true
        html: '{{ template "email.to.html" . }}'

    - name: 'wechat'
      wechat_configs:
      - corp_id: 'ww182a29bdbaeXXXc4'
        to_party: '413'
        to_user: '@all'
        agent_id: 1000035
        api_secret: 'XXXXS6lb5WRCq2-EoDxoqFXSnBdY3fyocuDP-tc'
        send_resolved: true

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

  wechat.tmpl: |-
    {{ define "wechat.default.message" }}
    {{- if gt (len .Alerts.Firing) 0 -}}
    {{- range $index, $alert := .Alerts -}}
    {{- if eq $index 0 }}
    ========= 监控报警 =========
    告警状态：{{   .Status }}
    告警级别：{{ .Labels.severity }}
    告警类型：{{ $alert.Labels.alertname }}
    故障主机: {{ $alert.Labels.instance }}
    告警主题: {{ $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 }}
    ========= 告警恢复 =========
    告警类型：{{ .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 }}

  email.tmpl: |-
    {{ define "email.from" }}xxx.com{{ end }}
    {{ define "email.to" }}xxx.com{{ end }}
    {{ define "email.to.html" }}
    {{- if gt (len .Alerts.Firing) 0 -}}
    {{ range .Alerts }}
    ========= 监控报警 =========<br>
    告警程序: prometheus_alert <br>
    告警级别: {{ .Labels.severity }} <br>
    告警类型: {{ .Labels.alertname }} <br>
    告警主机: {{ .Labels.instance }} <br>
    告警主题: {{ .Annotations.summary }}  <br>
    告警详情: {{ .Annotations.description }} <br>
    触发时间: {{ .StartsAt.Format "2006-01-02 15:04:05" }} <br>
    ========= = end =  =========<br>
    {{ end }}{{ end -}}

    {{- if gt (len .Alerts.Resolved) 0 -}}
    {{ range .Alerts }}
    ========= 告警恢复 =========<br>
    告警程序: prometheus_alert <br>
    告警级别: {{ .Labels.severity }} <br>
    告警类型: {{ .Labels.alertname }} <br>
    告警主机: {{ .Labels.instance }} <br>
    告警主题: {{ .Annotations.summary }} <br>
    告警详情: {{ .Annotations.description }} <br>
    触发时间: {{ .StartsAt.Format "2006-01-02 15:04:05" }} <br>
    恢复时间: {{ .EndsAt.Format "2006-01-02 15:04:05" }} <br>
    ========= = end =  =========<br>
    {{ end }}{{ end -}}

    {{- end }}

测试验证：

## 匹配如上webhook标签：hostname:zhdya
$ curl -XPOST -H 'Content-Type: application/json' http://alertmanager.kubernets.cn/api/v1/alerts -d 
'[{"labels":{"severity":"critical"},"annotations":{"summary":"This is a test alert"}}]'

二、基于钉钉的报警媒介

> 官网：https://open.dingtalk.com/document/robots/customize-robot-security-settings

2.1、dingtalk部署配置

```bash
cat << EOF > dingtalk-webhook.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    run: dingtalk
  name: webhook-dingtalk
  namespace: monitor
spec:
  replicas: 1
  selector:
    matchLabels:
      run: dingtalk
  template:
    metadata:
      labels:
        run: dingtalk
    spec:
      containers:
      - name: dingtalk
        image: timonwong/prometheus-webhook-dingtalk:v1.4.0
        imagePullPolicy: IfNotPresent
        args:
          - --ding.profile=webhook1=https://oapi.dingtalk.com/robot/send?access_token=<替换成你的token>
        ports:
        - containerPort: 8060
          protocol: TCP 
---
apiVersion: v1
kind: Service
metadata:
  labels:
    run: dingtalk
  name: webhook-dingtalk
  namespace: monitor
spec:
  ports:
  - port: 8060
    protocol: TCP
    targetPort: 8060
  selector:
    run: dingtalk
  sessionAffinity: None
EOF

2.2、配置alertmanager配置文件configmap

 route:
      group_by: ['env','instance','type','group','job','alertname','cluster']
      group_wait: 10s
      group_interval: 2m
      repeat_interval: 10m
      receiver: 'email'
      routes:
      - receiver: 'wechat'
        match:
          severity: critical

      - receiver: 'webhook'         ## 新增告警receiver通道
        match:
          hostname: zhdya

    receivers:
    - name: 'email'
      email_configs:
      - to: 'zhdyaa@163.com'
        send_resolved: true
        html: '{{ template "email.to.html" . }}'

    - name: 'wechat'
      wechat_configs:
      - corp_id: 'ww187a29bdbaececc4'
        to_party: '413'
        to_user: '@all'
        agent_id: 1000035
        api_secret: 'IVRfzG15S6lb5WRCq2-EoDxoqFXSnBdY3fyocuDP-tc'
        send_resolved: true

    - name: 'webhook'           ## 配置接收告警的媒介
      webhook_configs:
      - url: 'http://webhook-dingtalk.monitor.svc.cluster.local:8060/dingtalk/webhook1/send'
        send_resolved: true

测试验证：

## 匹配如上webhook标签：hostname:zhdya
$ curl -XPOST -H 'Content-Type: application/json' http://alertmanager.kubernets.cn/api/v1/alerts -d 
'[{"labels":{"hostname":"zhdya"},"annotations":{"summary":"This is a test alert"}}]'

三、告警静默
3.1、什么是告警静默
静默 Silences ：指让通过设置让警报在指定时间暂时不会发送警报的一种方式。

用于解决严重生产故障问题时，因所花费的时间过长，通过静默设置避免接收到过多的无用通知；
在已知的例行维护中，为了防止对例行维护的机器发送不必要的警报；
3.2、如何设置临时静默

四、总结
实时告警通知：企业微信/钉钉等即时通信工具能够实现实时的告警通知，使得团队成员能够及时响应和解决问题。
告警抑制：对已知或排查问题的时候进行告警静默。

我为你走过-YOYO
关注
第 10 章 Prometheus 监控 | 实战案例 - Nginx 监控
甘蓝的专栏
06-18 306
为 Nginx 安装 nginx-prometheus-exporter，实现对 Nginx 的监控。
Prometheus监控-第1天
qq_26825559的博客
08-28 1952
由上可知，启动参数里面有一个 --listen-metrics-urls=http://127.0.0.1:2381 的配置，该参数就是来指定 Metrics 接口运行在 2381 端口下面的，而且是 http 的协议，所以也不需要什么证书配置，这就比以前的版本要简单许多了，以前的版本需要用 https 协议访问，所以要配置对应的证书。Node Exporter 是 Prometheus 官方提供的一个节点资源采集组件，可以用于收集服务器节点的数据，如 CPU频率信息、磁盘IO统计、剩余可用内存等等。
Prometheus监控-第6天
qq_26825559的博客
08-25 670
Prometheus Operator 是 Kubernetes 原生的工具，它通过将 Prometheus 资源定义为 Kubernetes 对象（CRD）来简化 Prometheus 集群的管理。它自动化了在 Kubernetes 中配置和扩展 Prometheus 实例时涉及的常见任务，并提供了在 Kubernetes 环境中部署、配置和管理 Prometheus 的简单方式。
Prometheus监控- 第7天
qq_26825559的博客
08-26 852
每一个 Prometheus 资源，Operator 都会在相同 namespace 下部署成一个正确配置的 StatefulSet，Prometheus 的 Pod 都会挂载一个名为 的 Secret，里面包含了 Prometheus 的配置。调整配置ingress-nginx的配置文件，打开service及pod的10254端口。使用CRD做prometheus配置，“匹配” 是一个很重要的细节，详细匹配关系如图，任何地方匹配失败会导致转化成的标配prometheus文件无法识别到targets。
Prometheus监控- 第2天
qq_26825559的博客
08-21 709
Prometheus监控-第一天文章目录 一、背景： 二、Metrics-server 2.1、Metrics-server部署配置 三、HorizontalPodAutoscaler 3.1、使用HorizontalPodAutoscaler 3.2、测试验证 四、总结基于Prometheus的全方位监控平台–基于Prometheus的HPA自动伸缩我们对Markdown编辑器进行了一些功能拓展与语法支持，除了标准的Markdown编辑器功能，我们增加了如下几点新功能，帮助你用它写博客：撤销：Ctrl/C
监控系统Prometheus--入门
xd__xy的博客
03-23 1025
Prometheus 安装包下载链接：https://pan.baidu.com/s/1a3cUS3VF8NQyHF6xO7LKBQ?pwd=hxy2提取码：hxy2Prometheus 受启发于Google的Brogmon监控系统（相似的Kubernetes是从Google的Brog系统演变而来），从2012年开始由前Google工程师在Soundcloud以开源软件的形式进行研发，并且于2015年早期对外发布早期版本。
02-prometheus监控-服务器节点监控node-exporter
2302_79199605的博客
03-01 1939
点击Metrics之后，就可以看到，node-exporter采集的数据；数据包含结构：1，数据类型【TYPE】2，数据的key { 数据的value }也就是说，数据是以key{value}的形式，展示的；至于数据类型，以后再说，现在不着急；
监控系统Prometheus--与第三方框架集成
xd__xy的博客
04-14 1057
邮件通知常会出现接收不及时的问题，为确保通知信息被及时接收，可通过配置Prometheus 或者Grafana 与第三方平台告警平台（例如睿象云）集成，进而通过第三方平台提供的多种告警媒介（例如电话，短信）等发送告警信息。手动一个个添加Dashboard比较繁琐，Grafana社区鼓励用户分享Dashboard，通过https://grafana.com/dashboards网站，可以找到大量可直接使用的Dashboard模板。通知策略，可以配置被分派人接收告警的通知方式，通知时间，通知延时等等。
【30天精通Prometheus：一站式监控实战指南】第17天：nginx-prometheus-exporter从入门到实战：安装、配置详解与生产环境搭建指南，超详细
大唐有趣的小胡.
06-03 2381
通过访问官网、选择并下载适合版本的nginx-prometheus-exporter，读者可以轻松完成安装并运行。文章还深入探讨了nginx-prometheus-exporter的配置文件和服务，以及在实战演练中，指导读者如何在生产环境中搭建，包括创建管理用户、解压安装包、集成到Prometheus、编辑服务文件等步骤。最后，通过启动服务并验证其正常运行，确保nginx-prometheus-exporter在生产环境中成功部署，为监控Nginx服务器性能提供有力支持。
Day07-Prometheus监控项目
苦难带不走梦想
05-21 790
Prometheus监控架构,知晓prometheus及相关服务关系,知晓每个服务作用.基于prometheus+grafana全网监控.部署使用各种exportercadvisor监控容器配置中静态与动态加载grafana。
prometheus-webhook-dingtalk-1.4.0告警插件一键部署
12-30
这是一个 Prometheus 的第三方告警处理器，它实现了 Prometheus Alertmanager 的 webhook 接口，并将其转换为 DingTalk 可以识别的消息格式。 5. **部署流程**： - 下载 prometheus-webhook-dingtalk-1.4.0 包。 ...
9-3 Prometheus监控服务Kube-state-metrics
分享云原生，容器，运维等干货知识
10-24 2288
在前面章节8-5 在Prometheus实现Kubernetes-apiserver及Coredns服务发现介绍过使用kubernetes_sd_config对K8s集群进行监控。监控内容有master，node，schedule，controlle-manager，pod等。但是由于这些都是K8s内置的指标数据，数据并不全面。其他资源对象也需要监控的，例如Deployment，Daemonset，ConfigMap等资源对象。
CentOS7中使用Prometheus Process-exporter监控进程状态
JessonLiu_的博客
01-05 1841
Process-exporter 主要监控主机进程状态,采集服务的进程数、消耗CPU、内存、IO资源等。Process-exporter 官网。
Prometheus 监控指标采集
Korbin的博客
08-13 1820
在现代分布式系统和云原生环境中，为了确保复杂的分布式系统和服务的高可用性、可靠性和性能，通常采用实时可视化监控和分析，实现故障快速响应、资源优化和安全保障，从而提升用户满意度和运营效率。在目前主流的解决方案中，Prometheus和Grafana是两个使用 Go 开发的强大开源工具，通常一起使用来实现全面的监控和可视化系统。其中Prometheus负责采集和存储监控对象的时序数据。
IPEmotion 2024 R2现支持Amazon S3和Windows SMB服务器
WINDHILL风丘科技
09-27 514
新版IPEmotion 2024 R2软件推出了许多新功能，其中的一大功能是支持Amazon S3、Windows SMB服务器以及新的IPE-CAM-007 USB摄像头。IPEmotion 2024 R2还支持直接写入TEDS数据和配置可装载电池的新款IPE833记录仪。
服务器被挂马，导致网站首页被更改怎么解决
KookeeyLena7的博客
09-27 1178
当服务器被挂马并导致网站首页被篡改时，说明服务器或网站的安全性遭到破坏。
电脑加密机的基本功能与模块
最新发布
SafePloy_SH的博客
09-30 503
当需要传输数据时，加密机会将数据进行加密处理，使得数据在传输过程中以密文的形式存在，从而防止数据被未经授权的人员获取和篡改。加密机与主机之间使用TCP/IP协议通信，因此对主机的类型和主机操作系统无特殊要求，但仍需确保加密机与主机的硬件和软件环境相匹配。电脑加密机，又称主机加密机，是一种通过国家商用密码主管部门鉴定并批准使用的国内自主开发的主机加密设备。功能：电脑加密机主要通过使用密码学算法对数据进行加密和解密，以保护数据的机密性和完整性。性能：加密机的性能会影响加密和解密的速度以及系统的整体性能。
mobaxterm、vscode通过跳板机连接服务器
weixin_43815222的博客
09-27 287
点击登录，会输入密码，成功。
Linux 文件目录结构（详细）
2301_80035882的博客
09-26 536
Linux的文件系统是采用级层式的树状目录结构，在此结构中的最上层是根目录“/”，然后在此目录下再创建其他的目录。Linux世界中，一切皆文件！
prometheus docker-compose持久化存储
03-30
第一个作业是Prometheus自身的监控，而第二个作业是用于监控主机资源的node_exporter。 3. 启动Prometheus服务。 在命令行中进入docker-compose.yml所在的目录，并输入以下命令启动服务： ``` docker-compose up ...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值