Alertmanager已经在前面Prometheus初体验(三)已经介绍过了。现在介绍一下在kube-promethues里面怎么修改alertmanager配置文件,以及怎么通过各种媒介发送信息。

一、配置 PrometheusRule(触发器)

kube-promethues把所有资源监控起来之后,就需要配置告警这一块了,而告警其实就是配置触发器。在promethues的Alert界面,已经有了很多触发器了。

那么,这些报警信息是哪里来的呢?他们应该用怎样的方式通知我们呢?我们知道之前使用二进制部署的时候,是通过自定义的方式在 Prometheus 的配置文件之中指定 AlertManager 实例和 报警的 rules 文件,现在我们通过 Operator 部署的呢?我们可以在 Prometheus Dashboard 的 Config 页面下面查看关于 AlertManager 的配置:

  1. global:
  2. scrape_interval: 30s
  3. scrape_timeout: 10s
  4. evaluation_interval: 30s
  5. external_labels:
  6. prometheus: monitoring/k8s
  7. prometheus_replica: prometheus-k8s-0
  8. alerting:
  9. alert_relabel_configs:
  10. - separator: ;
  11. regex: prometheus_replica
  12. replacement: $1
  13. action: labeldrop
  14. alertmanagers:
  15. - kubernetes_sd_configs:
  16. - role: endpoints
  17. namespaces:
  18. names:
  19. - monitoring
  20. scheme: http
  21. path_prefix: /
  22. timeout: 10s
  23. api_version: v1
  24. relabel_configs:
  25. - source_labels: [__meta_kubernetes_service_name]
  26. separator: ;
  27. regex: alertmanager-main
  28. replacement: $1
  29. action: keep
  30. - source_labels: [__meta_kubernetes_endpoint_port_name]
  31. separator: ;
  32. regex: web
  33. replacement: $1
  34. action: keep
  35. rule_files:
  36. - /etc/prometheus/rules/prometheus-k8s-rulefiles-0/*.yaml

  上面 alertmanagers 实例的配置我们可以看到是通过角色为 endpoints 的 kubernetes 的服务发现机制获取的,匹配的是服务名为 alertmanager-main,端口名为 web 的 Service 服务,我们查看下 alertmanager-main 这个 Service:

  1. [root@vm10-0-0-12 ~]# kubectl describe svc alertmanager-main -n monitoring
  2. Name: alertmanager-main
  3. Namespace: monitoring
  4. Labels: alertmanager=main
  5. Annotations: kubectl.kubernetes.io/last-applied-configuration:
  6. {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"labels":{"alertmanager":"main"},"name":"alertmanager-main","namespace":"...
  7. Selector: alertmanager=main,app=alertmanager
  8. Type: ClusterIP
  9. IP: 10.254.160.2
  10. Port: web 9093/TCP
  11. TargetPort: web/TCP
  12. Endpoints: 10.8.0.21:9093,10.8.1.72:9093,10.8.2.19:9093
  13. Session Affinity: ClientIP
  14. Events: <none>

  可以看到服务名正是 alertmanager-main,Port 定义的名称也是 web,符合上面的规则,所以 Prometheus 和 AlertManager 组件就正确关联上了。而对应的报警规则文件位于:/etc/prometheus/rules/prometheus-k8s-rulefiles-0/目录下面所有的 YAML 文件。我们可以进入 Prometheus 的 Pod 中验证下该目录下面是否有 YAML 文件:

  1. $ kubectl exec -it prometheus-k8s-0 /bin/sh -n monitoring
  2. Defaulting container name to prometheus.
  3. Use 'kubectl describe pod/prometheus-k8s-0 -n monitoring' to see all of the containers in this pod.
  4. /prometheus $ ls /etc/prometheus/rules/prometheus-k8s-rulefiles-0/
  5. monitoring-prometheus-k8s-rules.yaml
  6. /prometheus $ cat /etc/prometheus/rules/prometheus-k8s-rulefiles-0/monitoring-prometheus-k8s-rules.yaml
  7. groups:
  8. - name: k8s.rules
  9. rules:
  10. - expr: |
  11. sum(rate(container_cpu_usage_seconds_total{job="kubelet", image!="", container_name!=""}[5m])) by (namespace)
  12. record: namespace:container_cpu_usage_seconds_total:sum_rate
  13. ......

  这个 YAML 文件实际上就是我们之前创建的一个 PrometheusRule 文件包含的:

  1. $ cat prometheus-rules.yaml
  2. apiVersion: monitoring.coreos.com/v1
  3. kind: PrometheusRule
  4. metadata:
  5. labels:
  6. prometheus: k8s
  7. role: alert-rules
  8. name: prometheus-k8s-rules
  9. namespace: monitoring
  10. spec:
  11. groups:
  12. - name: k8s.rules
  13. rules:
  14. - expr: |
  15. sum(rate(container_cpu_usage_seconds_total{job="kubelet", image!="", container_name!=""}[5m])) by (namespace)
  16. record: namespace:container_cpu_usage_seconds_total:sum_rate

  我们这里的 PrometheusRule 的 name 为 prometheus-k8s-rules,namespace 为 monitoring,我们可以猜想到我们创建一个 PrometheusRule 资源对象后,会自动在上面的 prometheus-k8s-rulefiles-0 目录下面生成一个对应的<namespace>-<name>.yaml文件,所以如果以后我们需要自定义一个报警选项的话,只需要定义一个 PrometheusRule 资源对象即可。

至于为什么 Prometheus 能够识别这个 PrometheusRule 资源对象呢?这就需要查看我们创建的 prometheus 这个资源对象了,里面有非常重要的一个属性 ruleSelector,用来匹配 rule 规则的过滤器,要求匹配具有 prometheus=k8s 和 role=alert-rules 标签的 PrometheusRule 资源对象,现在明白了吧?

cat prometheus-prometheus.yaml

  1. apiVersion: monitoring.coreos.com/v1
  2. kind: Prometheus
  3. metadata:
  4. labels:
  5. prometheus: k8s
  6. name: k8s
  7. namespace: monitoring
  8. spec:
  9. alerting:
  10. alertmanagers:
  11. - name: alertmanager-main
  12. namespace: monitoring
  13. port: web
  14. baseImage: prom/prometheus
  15. nodeSelector:
  16. beta.kubernetes.io/os: linux
  17. podMonitorSelector: {}
  18. replicas: 2
  19. resources:
  20. requests:
  21. memory: 400Mi
  22. ruleSelector:
  23. matchLabels:
  24. prometheus: k8s
  25. role: alert-rules
  26. securityContext:
  27. fsGroup: 2000
  28. runAsNonRoot: true
  29. runAsUser: 1000
  30. serviceAccountName: prometheus-k8s
  31. serviceMonitorNamespaceSelector: {}
  32. serviceMonitorSelector: {}
  33. version: v2.11.0

  所以我们要想自定义一个报警规则,只需要创建一个具有 prometheus=k8s 和 role=alert-rules 标签的 PrometheusRule 对象就行了,比如现在我们添加一个 etcd 是否可用的报警,我们知道 etcd 整个集群有一半以上的节点可用的话集群就是可用的,所以我们判断如果不可用的 etcd 数量超过了一半那么就触发报警,创建文件 prometheus-etcdRules.yaml:

  1. apiVersion: monitoring.coreos.com/v1
  2. kind: PrometheusRule
  3. metadata:
  4. labels:
  5. prometheus: k8s
  6. role: alert-rules
  7. name: etcd-rules
  8. namespace: monitoring
  9. spec:
  10. groups:
  11. - name: etcd
  12. rules:
  13. - alert: EtcdClusterUnavailable
  14. annotations:
  15. summary: etcd cluster small
  16. description: If one more etcd peer goes down the cluster will be unavailable
  17. expr: |
  18. count(up{job="etcd"} == 0) > (count(up{job="etcd"}) / 2 - 1)
  19. for: 3m
  20. labels:
  21. severity: critical

  注意:label 标签一定至少要有 prometheus=k8s 和 role=alert-rules!

rule文件的头部都是统一的,只有spec里面不同。

创建完成后,隔一会儿再去容器中查看下 rules 文件夹:

  1. kubectl exec -it prometheus-k8s-0 /bin/sh -n monitoring
  2. Defaulting container name to prometheus.
  3. Use 'kubectl describe pod/prometheus-k8s-0 -n monitoring' to see all of the containers in this pod.
  4. /prometheus $ ls /etc/prometheus/rules/prometheus-k8s-rulefiles-0/
  5. monitoring-etcd-rules.yaml monitoring-prometheus-k8s-rules.yaml

  可以看到我们创建的 rule 文件已经被注入到了对应的 rulefiles 文件夹下面了,证明我们上面的设想是正确的。然后再去 Prometheus Dashboard 的 Rules页面下面就可以查看到上面我们新建的报警规则了:

二、配置promethuesAlert(告警媒介)

触发器配置完成后,接下来需要在kube-promethues环境里配置告警通知了。promethues支持多种告警方式:钉钉、微信、邮件、webhook。其中webhook最为灵活,可以和自研的第三方平台对接。

告警配置相关可以在alertmanager里面查看:

这些配置信息实际上是来自于我们之前在prometheus-operator/contrib/kube-prometheus/manifests目录下面创建的 alertmanager-secret.yaml 文件:

  1. apiVersion: v1
  2. data:
  3. alertmanager.yaml: Imdsb2JhbCI6IAogICJyZXNvbHZlX3RpbWVvdXQiOiAiNW0iCiJyZWNlaXZlcnMiOiAKLSAibmFtZSI6ICJudWxsIgoicm91dGUiOiAKICAiZ3JvdXBfYnkiOiAKICAtICJqb2IiCiAgImdyb3VwX2ludGVydmFsIjogIjVtIgogICJncm91cF93YWl0IjogIjMwcyIKICAicmVjZWl2ZXIiOiAibnVsbCIKICAicmVwZWF0X2ludGVydmFsIjogIjEyaCIKICAicm91dGVzIjogCiAgLSAibWF0Y2giOiAKICAgICAgImFsZXJ0bmFtZSI6ICJEZWFkTWFuc1N3aXRjaCIKICAgICJyZWNlaXZlciI6ICJudWxsIg==
  4. kind: Secret
  5. metadata:
  6. name: alertmanager-main
  7. namespace: monitoring
  8. type: Opaque

  可以将 alertmanager-secret.yaml 对应的 value 值做一个 base64 解码:

  1. echo "Imdsb2JhbCI6IAogICJyZXNvbHZlX3RpbWVvdXQiOiAiNW0iCiJyZWNlaXZlcnMiOiAKLSAibmFtZSI6ICJudWxsIgoicm91dGUiOiAKICAiZ3JvdXBfYnkiOiAKICAtICJqb2IiCiAgImdyb3VwX2ludGVydmFsIjogIjVtIgogICJncm91cF93YWl0IjogIjMwcyIKICAicmVjZWl2ZXIiOiAibnVsbCIKICAicmVwZWF0X2ludGVydmFsIjogIjEyaCIKICAicm91dGVzIjogCiAgLSAibWF0Y2giOiAKICAgICAgImFsZXJ0bmFtZSI6ICJEZWFkTWFuc1N3aXRjaCIKICAgICJyZWNlaXZlciI6ICJudWxsIg==" | base64 -d

也就是说,如果我们需要修改告警的主配置文件,只要修改 alertmanager-secret.yaml文件就行了。而 alertmanager-secret.yaml是一个secret,所以修改过程如下:

1、新建一个alertmanager.yaml文件

2、删除之前的secret文件(alertmanager-main)

3、新建secret文件

cat alertmanager.yaml

  1. global:
  2. resolve_timeout: 5m
  3. wechat_api_url: 'https://qyapi.weixin.qq.com/cgi-bin/'
  4. wechat_api_secret: '*****'
  5. wechat_api_corp_id: '*******'
  6. smtp_smarthost: 'smtp.163.com:25'
  7. smtp_from: '你的邮箱'
  8. smtp_auth_username: '邮箱用户名'
  9. smtp_auth_password: '密码或授权码'
  10. smtp_require_tls: false
  11.  
  12. templates: ##消息模板
  13. - '*.tmpl'
  14.  
  15. route:
  16. group_by: ['alertname','job']
  17. group_wait: 10s
  18. group_interval: 10s
  19. repeat_interval: 12h
  20. receiver: 'wechat'
  21. routes:
  22. - match:
  23. job: 'prometheus'
  24. receiver: 'wechat'
  25.  
  26. receivers:
  27. - name: 'email'
  28. email_configs:
  29. - to: '邮件接收人'
  30. - name: 'wechat'
  31. wechat_configs:
  32. - send_resolved: true
  33. to_party: '2'
  34. agent_id: '1'
  35. - name: 'webhook'
  36. webhook_configs:
  37. # - url: 'http://dingtalk-hook:5000'
  38. - url: 'http://webhook-dingtalk.monitoring.svc.cluster.local:8060/dingtalk/webhook1/send'
  39. send_resolved: true

  

  1. # 先将之前的 secret 对象删除
  2. $ kubectl delete secret alertmanager-main -n monitoring
  3. secret "alertmanager-main" deleted
  4.  
  5. # 创建新的secret对象
  6. $ kubectl create secret generic alertmanager-main --from-file=alertmanager.yaml -n monitoring
  7. secret "alertmanager-main" created

  注意:这里--from-file可以使用多个,如果你使用多重告警方式的话。

以上过程执行完成后,就可以在alertmanager中看到最新的配置了:

三、配置promethuesAlert(邮件告警)

邮件告警是最简单的,只需要直接在alertmanager的config里面配置就行。

  1. global:
  2. resolve_timeout: 5m
  3. smtp_smarthost: 'smtp.163.com:25'
  4. smtp_from: 'xuequn_2008@163.com'
  5. smtp_auth_username: 'xuequn_2008@163.com'
  6. smtp_auth_password: 'password'
  7. smtp_require_tls: false
  8.  
  9. templates: ##消息模板
  10. - '*.tmpl'
  11.  
  12. route:
  13. group_by: ['alertname','job']
  14. group_wait: 10s
  15. group_interval: 10s
  16. repeat_interval: 12h
  17. receiver: 'wechat'
  18. routes:
  19. - match:
  20. job: 'prometheus'
  21. receiver: 'wechat'
  22.  
  23. receivers:
  24. - name: 'email'
  25. email_configs:
  26. - to: 'xuequn_2008@163.com'

  以上是一个简单的配置,完成后,将repeat-interval设置小一点,比如1m。去邮箱查看对应的告警就行了。

四、配置promethuesAlert(钉钉告警)

1、注册钉钉账号->机器人管理

2、自定义(通过webhook接入自定义服务)

3、添加->复制webhook

重点在webhook,复制webhook的url链接。

4、编写yaml

在/data/k8s-install/prometheus/alertmanager目录下,新建dingtalk-webhook.yaml

  1. ---
  2. apiVersion: extensions/v1beta1
  3. kind: Deployment
  4. metadata:
  5. labels:
  6. run: dingtalk
  7. name: webhook-dingtalk
  8. namespace: monitoring
  9. spec:
  10. replicas: 1
  11. template:
  12. metadata:
  13. labels:
  14. run: dingtalk
  15. spec:
  16. containers:
  17. - name: dingtalk
  18. image: timonwong/prometheus-webhook-dingtalk:v0.3.0
  19. imagePullPolicy: IfNotPresent
  20. # 设置钉钉群聊自定义机器人后,使用实际 access_token 替换下面 xxxxxx部分
  21. args:
  22. - --ding.profile=webhook1=https://oapi.dingtalk.com/robot/send?access_token=你的token
  23. ports:
  24. - containerPort: 8060
  25. protocol: TCP
  26.  
  27. ---
  28. apiVersion: v1
  29. kind: Service
  30. metadata:
  31. labels:
  32. run: dingtalk
  33. name: webhook-dingtalk
  34. namespace: monitoring
  35. spec:
  36. ports:
  37. - port: 8060
  38. protocol: TCP
  39. targetPort: 8060
  40. selector:
  41. run: dingtalk
  42. sessionAffinity: None

  填上上面复制的webhook链接地址。

5、应用配置

  1. kubectl apply -f dingtalk-webhook.yaml

  应用配置后,对应的pod和service就起来了,我们可以看到侦听的端口为8060.

6、alertmanager配置告警通知

  1. global:
  2. resolve_timeout: 5m
  3.  
  4. templates: ##消息模板
  5. - '*.tmpl'
  6.  
  7. route:
  8. group_by: ['alertname','job']
  9. group_wait: 10s
  10. group_interval: 10s
  11. repeat_interval: 12h
  12. receiver: 'webhook'
  13.  
  14. receivers:
  15. #配置邮件告警
  16. - name: 'email'
  17. email_configs:
  18. - to: 'xuequn_2008@163.com'
  19.  
  20. #配置钉钉告警的webhook
  21. - name: 'webhook'
  22. webhook_configs:
  23. - url: 'http://webhook-dingtalk.monitoring.svc.cluster.local:8060/dingtalk/webhook1/send'
  24. send_resolved: true

  

7、更新告警文件

  1. # 先将之前的 secret 对象删除
  2. $ kubectl delete secret alertmanager-main -n monitoring
  3. secret "alertmanager-main" deleted
  4.  
  5. # 创建新的secret对象
  6. $ kubectl create secret generic alertmanager-main --from-file=alertmanager.yaml -n monitoring
  7. secret "alertmanager-main" created

  

8、测试告警

一般情况下,没有问题的话,你就可以接收到钉钉告警拉。

五、配置promethuesAlert(微信告警)

由于wechat的强大,所以alertmanager官方直接支持wechat告警,直接配置即可。

1、注册企业微信

找到以下几个东西:

wechat_api_secret    应用ID

wechat_api_corp_id  企业ID

to_party   中心(部门的上级)

agent_id  部门ID

2、配置alertmanager

  1. global:
  2. resolve_timeout: 5m
  3. wechat_api_url: 'https://qyapi.weixin.qq.com/cgi-bin/'
  4. wechat_api_secret: '应用ID'
  5. wechat_api_corp_id: '企业ID'
  6.  
  7. templates: ##消息模板
  8. - '*.tmpl'
  9.  
  10. route:
  11. group_by: ['alertname','job']
  12. group_wait: 10s
  13. group_interval: 10s
  14. repeat_interval: 1m
  15. receiver: 'wechat'
  16.  
  17. receivers:
  18.  
  19. - name: 'wechat'
  20. wechat_configs:
  21. - send_resolved: true
  22. to_party: '2' #中心ID
  23. agent_id: '1' #部门ID

  按照以上方式配置完成后,直接测试即可,一般没有问题的情况下,你会收到如下形式的告警:

六、配置promethuesAlert(自研平台)

自研平台,就是自己开发的平台。其实也是通过webhook方式和第三方对接。前提是:自研平台有对应的API接口接受告警。

比如,我们自己开发的接口如下:

  1. curl -X POST "http://www.baibai.com/eventhub/api/v1/failure_events/" \
  2. -H "Content-Type:application/json" \
  3. -H "Authorization:Token 7HNSNBqqRf6EHCBaCgDdMPYHCq9VK6RE" \
  4. -d @- << EOF
  5. {
  6. "name": "告警事件名",
  7. "description":"事件描述",
  8. "project_name": "告警项目",
  9. "failure_type":"程序故障-通用应用程序故障-通用应用程序BUG"
  10. }
  11. EOF

  上面对接的是一个事件系统,有一个POST接口,可以直接接受事件告警。

因为我们希望webhook同样运行在k8s环境里,方便维护和开发,所以,我们先要制作一个对应webhook的镜像文件。

1、制作镜像

编写app

  1. import os
  2. import json
  3. import requests
  4. import datetime
  5.  
  6. from flask import Flask
  7. from flask import request
  8.  
  9. app = Flask(__name__)
  10.  
  11. @app.route('/', methods=['POST', 'GET'])
  12. def send():
  13. if request.method == 'POST':
  14. post_data = request.get_data()
  15. post_data = eval(str(post_data, encoding = "utf-8"))
  16. event_status = post_data.get('alerts')[0].get('status','')
  17. event_job = post_data.get('alerts')[0].get('labels','').get('job','')
  18. event_type = post_data.get('alerts')[0].get('labels','').get('alertname','')
  19. event_desc = post_data.get('alerts')[0].get('annotations','').get('message','')
  20. event_level = post_data.get('alerts')[0].get('labels','').get('severity','')
  21. event_time = post_data.get('alerts')[0].get('startsAt')[0:-11]
  22.  
  23. new_data = {
  24. "alert_status": event_status,
  25. "alert_instance": event_job,
  26. "alert_type": event_type,
  27. "alert_desc": event_desc,
  28. "alert_severity": event_level,
  29. "alert_time": event_time
  30. }
  31. send_alert(new_data)
  32. return 'success'
  33. else:
  34. return 'weclome to use prometheus alertmanager events-hub webhook server!'
  35.  
  36. class ComplexEncoder(json.JSONEncoder):
  37. def default(self, obj):
  38. if isinstance(obj, datetime.datetime):
  39. return obj.strftime('%Y-%m-%d %H:%M:%S')
  40. elif isinstance(obj, bytes):
  41. return str(obj, encoding='utf-8')
  42. else:
  43. return json.JSONEncoder.default(self, obj)
  44.  
  45. def send_alert(data):
  46. url = "http://www.baibai/eventhub/api/v1/failure_events/"
  47. headers = {
  48. "Content-Type": "application/json",
  49. "Authorization": "Token 7HNSNBqqRf6EHCBaCgDdMPYHCq9VK6RE"
  50. }
  51. send_data = {
  52. "name": data.get('alert_desc',''),
  53. "description": data,
  54. "project_name": "维护支持部",
  55. "failure_type": "程序故障-通用应用程序故障-通用应用程序BUG"
  56. }
  57. req = requests.post(url, data=json.dumps(send_data,cls=ComplexEncoder),headers=headers)
  58. print(req.text)
  59. result = req.json()
  60.  
  61. if __name__ == '__main__':
  62. app.run(host='0.0.0.0', port=5000)

  

2、编写Dockerfile

cat Dockerfile

  1. FROM python:3.6.4
  2.  
  3. # set working directory
  4. WORKDIR /src
  5.  
  6. # add app
  7. ADD . /src
  8.  
  9. # install requirements
  10. RUN pip install -r requirements.txt
  11.  
  12. # run server
  13. CMD python app.py

  

cat requirements.txt

  1. certifi==2018.10.15
  2. chardet==3.0.4
  3. Click==7.0
  4. Flask==1.0.2
  5. idna==2.7
  6. itsdangerous==1.1.0
  7. Jinja2==2.10
  8. MarkupSafe==1.1.0
  9. requests==2.20.1
  10. urllib3==1.24.1
  11. Werkzeug==0.14.1

  上面其实就是写了一个简单的flask app,通过POST方法,向第三方系统的API提交数据。

3、构建镜像

  1. docker build -t loveliuli/events-hub:v0.1 .

  

4、上传镜像到Dockerhub

当然,这里的前提是你得先在Dockerhub上注册了账号,并且在本地使用docker login登录。

  1. docker push loveliuli/events-hub:v0.1

  

这样就方便在任何地方都可以进行使用这个镜像了。

5、alertmanager编写yaml

cat dingtalk-webhook-flask.yaml

  1. apiVersion: extensions/v1beta1
  2. kind: Deployment
  3. metadata:
  4. name: dingtalk-hook
  5. namespace: monitoring
  6. spec:
  7. template:
  8. metadata:
  9. labels:
  10. app: dingtalk-hook
  11. spec:
  12. containers:
  13. - name: dingtalk-hook
  14. image: loveliuli/events-hub:v0.30
  15. imagePullPolicy: IfNotPresent
  16. ports:
  17. - containerPort: 5000
  18. name: http
  19. resources:
  20. requests:
  21. cpu: 50m
  22. memory: 100Mi
  23. limits:
  24. cpu: 50m
  25. memory: 100Mi
  26.  
  27. ---
  28. apiVersion: v1
  29. kind: Service
  30. metadata:
  31. name: dingtalk-hook
  32. namespace: monitoring
  33. spec:
  34. type: NodePort
  35. selector:
  36. app: dingtalk-hook
  37. ports:
  38. - name: hook
  39. port: 5000
  40. targetPort: http

  以上name命名可能有点误导,其实和钉钉毫无关系。

6、应用配置

  1. kubectl apply -f dingtalk-webhook-flask.yaml

  应用配置后,我们即可查看启动情况:

7、配置alertmanager

  1. global:
  2. resolve_timeout: 5m
  3.  
  4. templates: ##消息模板
  5. - '*.tmpl'
  6.  
  7. route:
  8. group_by: ['alertname','job']
  9. group_wait: 10s
  10. group_interval: 10s
  11. repeat_interval: 1m
  12. receiver: 'webhook'
  13.  
  14. receivers:
  15. - name: 'webhook'
  16. webhook_configs:
  17. - url: 'http://dingtalk-hook:5000'
  18. send_resolved: true

  

8、更新告警文件

  1. # 先将之前的 secret 对象删除
  2. $ kubectl delete secret alertmanager-main -n monitoring
  3. secret "alertmanager-main" deleted
  4.  
  5. # 创建新的secret对象
  6. $ kubectl create secret generic alertmanager-main --from-file=alertmanager.yaml -n monitoring
  7. secret "alertmanager-main" created

  注意:我们每次更新alertmanager的配置文件,都必须更新告警文件,才能生成最新的配置。

9、测试告警

不出意外的话,你将会看到如下log信息,那就表示成功了。

第三方系统接收信息:

通过第三方系统和自己企业的短信、内部系统对接,就非常简单了!

kube-promethues监控告警详解(邮件、钉钉、微信、自研平台)的更多相关文章

  1. Spring Boot Actuator监控使用详解

    在企业级应用中,学习了如何进行SpringBoot应用的功能开发,以及如何写单元测试.集成测试等还是不够的.在实际的软件开发中还需要:应用程序的监控和管理.SpringBoot的Actuator模块实 ...

  2. 搭建zabbix监控系统详解

    搭建zabbix监控系统详解 文:warren   博文大纲:一.前言 二.zabbix监控架构三.搭建Zabbix监控服务器四.搭建过程中遇到有些服务无法正常启动的解决办法 一.前言 : 要想实时的 ...

  3. Linux 系统性能监控命令详解

    Linux 系统性能监控命令详解 CPU MEMORY IO NETWORK LINUX进程内存占用查看方法 系统负载过重时往往会引起其它子系统的问题,比如:->大量的读入内存的IO请求(pag ...

  4. Zabbix 监控过程详解

    Zabbix 监控过程详解 一.修改密码及中文语言 修改密码 修改中文语言 如果复选框中没有 Chinese(zh_CN) 选项,需要安装中文包 [root@Zabbix-server ~]# yum ...

  5. 《吐血整理》保姆级系列教程-玩转Fiddler抓包教程(5)-Fiddler监控面板详解

    1.简介 按照从上往下,从左往右的计划,今天就轮到介绍和分享Fiddler的监控面板了.监控面板主要是一些辅助标签工具栏.有了这些就会让你的会话请求和响应时刻处监控中毫无隐私可言.监控面板是fiddl ...

  6. Wordpress 网站搭建及性能监控方法详解!

    前言 说到 Wordpress,大家往往想到的是博客,其实,如今的 WordPress 已经成为全球使用量最多的开源 CMS 系统.并且,如果你有一定的技术基础稍加改动,就可以搭建出新闻网站.企业网站 ...

  7. JMeter性能测试-服务器资源监控插件详解

          零.引言 我们对被测应用进行性能测试时,除了关注吞吐量.响应时间等应用自身的表现外,对应用运行所涉及的服务器资源的使用情况,也是非常重要的方面,通过实时监控,可以准确的把握不同测试场景下服 ...

  8. (转)JMeter性能测试-服务器资源监控插件详解

    零.引言 我们对被测应用进行性能测试时,除了关注吞吐量.响应时间等应用自身的表现外,对应用运行所涉及的服务器资源的使用情况,也是非常重要的方面,通过实时监控,可以准确的把握不同测试场景下服务器资源消耗 ...

  9. JVM监控命令详解(转)

    JVM监控命令基本就是 jps.jstack.jmap.jhat.jstat 几个命令的使用就可以了 JDK本身提供了很多方便的JVM性能调优监控工具,除了集成式的VisualVM和jConsole外 ...

随机推荐

  1. VUE基础回顾2

    1.响应式 vue修改了每个添加到data上的对象,当该对象发生变化时vue会收到通知,从而实现响应式.对象的每个属性都会被替换为getter,setter方法. 有两种方式实现data对象的监听 ( ...

  2. mysql模糊查询1,11,111用逗号(其他符号)拼接的相似字符串

    mysql进行模糊查询时,基本都是LIKE "%sss%",有时候这种查询时准确的,但是有种情况这种查询会出现很大问题. 看一下下面这张表 如果想查询字段test包含1的数据,一般 ...

  3. PM2 对 Node 项目进行线上部署与配置

    pm2 是一个带有负载均衡功能的 Node 应用的进程管理器. 1. pm2 主要特点 内建负载均衡(使用Node cluster 集群模块) 保持后台运行 进程守护,系统崩溃后自动重启 启动多进程, ...

  4. Centos7.3安装nexus-3.14.0-04

    nexus-3.14.0-04的安装       nexus-3.14.0-04-unix.tar.gz             1.下载nexus             2.上传到服务器/root ...

  5. angularcli 第七篇(service 服务)

    在组件中定义的信息是固定的,假设另外一个组件也需要用到这些信息,这时候就用到服务,实现 共享数据 和 方法 组件不应该直接获取或保存数据,它们不应该了解是否在展示假数据. 它们应该聚焦于展示数据,而把 ...

  6. Linux操作系统的进程管理

    Linux操作系统的进程管理 作者:尹正杰 版权声明:原创作品,谢绝转载!否则将追究法律责任. 一.进程相关概念 1>.进程概述 内核的功用: 进程管理.文件系统.网络功能.内存管理.驱动程序. ...

  7. Docker容器网络篇

    Docker容器网络篇 作者:尹正杰 版权声明:原创作品,谢绝转载!否则将追究法律责任. 一.Docker的网络模型概述 如上图所示,Docker有四种网络模型: 封闭式网络(Closed conta ...

  8. 微信小程序~下拉刷新真机测试不弹回的处理办法

    问题描述: 下拉刷新在手机上不会自动回弹,开发工具可以 解决办法: 主动调用wx.stopPullDownRefresh /** * 页面相关事件处理函数--监听用户下拉动作 */ onPullDow ...

  9. Centos7-安装py3

    安装依赖 yum install gcc openssl-devel bzip2-devel expat-devel gdbm-devel readline-devel sqlite-devel li ...

  10. Alpha冲刺(6/10)——2019.4.29

    所属课程 软件工程1916|W(福州大学) 作业要求 Alpha冲刺(6/10)--2019.4.29 团队名称 待就业六人组 1.团队信息 团队名称:待就业六人组 团队描述:同舟共济扬帆起,乘风破浪 ...