网站图片素材下载,网站服务器人多怎么挤进去,wordpress 代码 格式,景宁建设局网站------ 课程视频同步分享在今日头条和B站
大家好#xff0c;我是博哥爱运维。早期我们经常用邮箱接收报警邮件#xff0c;但是报警不及时#xff0c;而且目前各云平台对邮件发送限制还比较严格#xff0c;所以目前在生产中用得更为多的是基于webhook来转发报警内容到企…------ 课程视频同步分享在今日头条和B站
大家好我是博哥爱运维。早期我们经常用邮箱接收报警邮件但是报警不及时而且目前各云平台对邮件发送限制还比较严格所以目前在生产中用得更为多的是基于webhook来转发报警内容到企业中用的聊天工具中比如钉钉、企业微信、飞书等。
prometheus的报警组件是Alertmanager它支持自定义webhook的方式来接受它发出的报警它发出的日志json字段比较多我们需要根据需要接收的app来做相应的日志清洗转发
这里博哥将用golang结合Gin网络框架来编写一个日志清洗转发工具分别对这几种常用的报警方式作详细的说明及实战源码的分享计划放入golang语言开发讲解课程里面这样大家更容易接受。 https://github.com/bogeit/LearnK8s/tree/main/2023/boge-webhook 我们先制作好镜像并上传到我们自己的私有仓库Harbor里面
# 将上面代码仓库文件内容下载到目录
# 确认文件是否在当前目录
ls -l Dockerfile mycli
# 构建镜像
docker build -t harbor.boge.com/product/alertmanaer-webhook:1.0 .
# 上传镜像
docker push harbor.boge.com/product/alertmanaer-webhook:1.0
# 创建harbor私有仓库密钥
kubectl -n monitoring create secret docker-registry boge-secret --docker-serverharbor.boge.com --docker-usernameboge --docker-passwordBoge666 --docker-emailadminboge.com
将构建好的后端转发服务部署到K8S上面
kubectl -n monitoring apply -f alertmanaer-webhook.yaml# 如果出现镜像拉取失败问题注意看当前pod运行的节点上面需要添加私有仓库的本地hosts
# vim /etc/hosts
10.0.1.201 easzlab.io.local harbor.boge.com# 指定后端转发服务的svc地址发个post请求看看服务是否正常
curl -X POST -H Content-type: application/json -d {name: boge,titlea: $(id), texta: $(whoami)-$(hostname)} 10.68.138.60/b01bdc063/boge/getjson查看后端 转发服务日志
# kubectl -n monitoring logs alertmanaer-dingtalk-dp-64c966fb9b-8pxgr
[GIN-debug] [WARNING] Creating an Engine instance with the Logger and Recovery middleware already attached.[GIN-debug] [WARNING] Running in debug mode. Switch to release mode in production.- using env: export GIN_MODErelease- using code: gin.SetMode(gin.ReleaseMode)[GIN-debug] GET /status -- mycli/libs.MyWebServer.func1 (3 handlers)
[GIN-debug] POST /b01bdc063/boge/getjson -- mycli/libs.MyWebServer.func2 (3 handlers)
[GIN-debug] POST /7332f19/prometheus/dingtalk -- mycli/libs.MyWebServer.func3 (3 handlers)
[GIN-debug] POST /1bdc0637/prometheus/feishu -- mycli/libs.MyWebServer.func4 (3 handlers)
[GIN-debug] POST /5e00fc1a/prometheus/weixin -- mycli/libs.MyWebServer.func5 (3 handlers)
[GIN-debug] Listening and serving HTTP on :9999
{name: boge,titlea: uid0(root) gid0(root) groups0(root), texta: root-node-1}
[GIN] 2024/01/15 - 21:45:15 | 200 | 36.143µs | 172.20.84.128 | POST /b01bdc063/boge/getjson
首先看下报警规则及报警发送配置是什么样的
prometheus-operator的规则非常齐全基本属于开箱即用类型大家可以根据日常收到的报警对里面的rules报警规则作针对性的调整比如把报警观察时长缩短一点等
# 监控报警规划修改
kubectl -n monitoring edit PrometheusRule kubernetes-monitoring-rules# 通过这里可以获取需要创建的报警配置secret名称
# kubectl -n monitoring edit statefulsets.apps alertmanager-main
...volumes:- name: config-volumesecret:defaultMode: 420secretName: alertmanager-main-generated
...# 注意事先在配置文件 alertmanager.yaml 里面编辑好收件人等信息 再执行下面的命令
kubectl -n monitoring delete secret alertmanager-main
kubectl -n monitoring create secret generic alertmanager-main --from-filealertmanager.yaml 报警配置文件 alertmanager.yaml
# global块配置下的配置选项在本配置文件内的所有配置项下可见
global:# 在Alertmanager内管理的每一条告警均有两种状态: resolved或者firing. 在altermanager首次发送告警通知后, 该告警会一直处于firing状态,设置resolve_timeout可以指定处于firing状态的告警间隔多长时间会被设置为resolved状态, 在设置为resolved状态的告警后,altermanager不会再发送firing的告警通知.
# resolve_timeout: 1hresolve_timeout: 10m# 告警通知模板
templates:
- /etc/altermanager/config/*.tmpl# route: 根路由,该模块用于该根路由下的节点及子路由routes的定义. 子树节点如果不对相关配置进行配置则默认会从父路由树继承该配置选项。每一条告警都要进入route即要求配置选项group_by的值能够匹配到每一条告警的至少一个labelkey(即通过POST请求向altermanager服务接口所发送告警的labels项所携带的labelname)告警进入到route后将会根据子路由routes节点中的配置项match_re或者match来确定能进入该子路由节点的告警(由在match_re或者match下配置的labelkey: labelvalue是否为告警labels的子集决定是的话则会进入该子路由节点否则不能接收进入该子路由节点).
route:# 例如所有labelkey:labelvalue含clusterA及altertnameLatencyHigh labelkey的告警都会被归入单一组中group_by: [job, altername, cluster, service,severity]# 若一组新的告警产生则会等group_wait后再发送通知该功能主要用于当告警在很短时间内接连产生时在group_wait内合并为单一的告警后再发送
# group_wait: 30sgroup_wait: 10s# 再次告警时间间隔
# group_interval: 5mgroup_interval: 20s# 如果一条告警通知已成功发送且在间隔repeat_interval后该告警仍然未被设置为resolved则会再次发送该告警通知
# repeat_interval: 12hrepeat_interval: 1m# 默认告警通知接收者凡未被匹配进入各子路由节点的告警均被发送到此接收者receiver: webhook# 上述route的配置会被传递给子路由节点子路由节点进行重新配置才会被覆盖# 子路由树routes:# 该配置选项使用正则表达式来匹配告警的labels以确定能否进入该子路由树# match_re和match均用于匹配labelkey为service,labelvalue分别为指定值的告警被匹配到的告警会将通知发送到对应的receiver- match_re:service: ^(foo1|foo2|baz)$receiver: webhook# 在带有service标签的告警同时有severity标签时他可以有自己的子路由同时具有severity ! critical的告警则被发送给接收者team-ops-wechat,对severity critical的告警则被发送到对应的接收者即team-ops-pagerroutes:- match:severity: criticalreceiver: webhook# 比如关于数据库服务的告警如果子路由没有匹配到相应的owner标签则都默认由team-DB-pager接收- match:service: databasereceiver: webhook# 我们也可以先根据标签service:database将数据库服务告警过滤出来然后进一步将所有同时带labelkey为database- match:severity: criticalreceiver: webhook
# 抑制规则当出现critical告警时 忽略warning
inhibit_rules:
- source_match:severity: criticaltarget_match:severity: warning# Apply inhibition if the alertname is the same.# equal: [alertname, cluster, service]#
# 收件人配置
receivers:
- name: webhookwebhook_configs:- url: http://alertmanaer-dingtalk-svc.kube-system/b01bdc063/boge/getjsonsend_resolved: true附 监控其他服务的prometheus规则配置
https://github.com/samber/awesome-prometheus-alerts
