-
Notifications
You must be signed in to change notification settings - Fork 0
MO‐OB 告警接入操作流程
本文是根据MO-OB规则管理流程提供的具体操作手册,只需按照步骤配置好即可将业务指标接入并告警
下图是指标数据从采集到告警到展示的链路图,其中蓝色字标识的配置是需要要由用户配置的,配置完成后才可实现采集-监控-告警
主要有以下配置:
- 业务方暴漏
/metrics
接口供 prometheus agent 采集 - prometheus agent 的采集配置(默认无需修改)
- 告警规则
- alertmaneger 的告警 receiver(决定 email or webhook 的接受方)
- [可选] grafana 图表
下面将按照操作的顺序,提供不同组件的配置方法
首先在业务代码中引入prometheus的指标抓取接口,详情请参考:业务 metric 采集接入
为了便于prometheus的服务发现,在k8s上部署时需要额外部署组件相对应的 service
(推荐),或者使用 80
端口,部署好service后,可以去相应集群的grafana页面中看看是否已经有开始采集到数据(可能会有2-3分钟的延迟),不同集群的grafana环境以及账号请见:Grafana 地址列表
接着,拉取本项目的代码,接下来的操作是在仓库中添加或修改相应的配置代码,并验证、提交:
git clone https://github.com/matrixone-cloud/observability.git && cd ./observability
默认情况下无需配置,已由上一步的prometheus的服务发现配置好采集,但如果需要进一步定制化的配置(如添加额外的label),可以在 charts/mo-ob-opensource/values.yaml
下的kube-prometheus-stack.prometheus.prometheusSpec.additionalScrapeConfigs
中进行添加或修改
更详细的配置方法请见:官方采集配置文档
在charts/mo-ruler-stack/rules
下新建yaml文件,名称为相应的组件名并使用-
分隔(如 instance-service.yaml
)
参考文档:告警规则编写官方文档,根据需求,在yaml文件中写入告警规则
groups:
- name: example
rules:
- alert: HighRequestLatencyAlert
expr: job:request_latency_seconds:mean5m{job="myjob"} > 0.5
for: 10m
labels:
severity: page
annotations:
summary: High request latency
- alert: SomeOtherAlert
...
- alert:告警规则的名称。
- expr:基于PromQL表达式告警触发条件,用于计算是否有时间序列满足该条件。
- for:评估等待时间,可选参数。用于表示只有当触发条件持续一段时间后才发送告警。在等待期间新产生告警的状态为pending。
- labels:自定义标签,允许用户指定要附加到告警上的一组附加标签。
- annotations:用于指定一组附加信息,比如用于描述告警详细信息的文字等,annotations的内容在告警产生时会一同作为参数发送到Alertmanager。
可以需要在告警规则中添加告警owner,使得当告警产生时,可以在群里@特定的人,效果见下图:
只需在 labels 中添加字段 alertOwner: [企业微信 ID]
即可(具体的)
- alert: HighRequestLatencyAlert
expr: job:request_latency_seconds:mean5m{job="myjob"} > 0.5
for: 10m
labels:
severity: page
+ alertOwner: bruce
annotations:
summary: High request latency
除了核心的告警规则之外,我们还需要编写简单的单元测试用于验证告警规则的正确性,是否符合预期。我们使用prometheus官方提供的promtool进行编写,他允许我们自己模拟指标数据源,并读取已经写好的告警规则进行验证,具体的文档请见:unit-testing-for-rules
在test/rule-check
下新建yaml文件编写,一个单元测试文件将对应一个规则文件(意即一个规则组),按照告警规则-test.yaml
命名(如instance-service-test.yaml
),其中将单元测试rule_files
写出以下形式即可读取到刚才创建的告警规则所在的文件夹
rule_files:
- ../../charts/mo-ruler-stack/rules/*.yaml
- ../../charts/mo-ruler-stack/rules/*.yml
修改提交PR后,将会自动执行验证,也可以在 github action 页面上选择 Alert Rules Check
手动执行(勾选该分支)使用promtool进行验证,验证告警规则的语法,以及单元测试时候符合预期
也可以在本地安装prometheus,即可以安装promtool,并执行测试:
$ brew install prometheus
$ promtool test rules test/rule-check/*
在.github/CODEOWNERS
中标记这些文件的owner为提交人
如果不进行配置,则默认会发送到告警通知企业微信群
如果需要将告警通过alertmanager发送到邮箱,或者通过webhook发送到其他组件中,则需要在charts/mo-ruler-stack/values.yaml
下进行配置:
- 配置
alertmanager.config.receivers
中可以新增的 webhook ,并在routes
中路由相关告警发送到对应的receiver,详见官方文档receiver- 如果是想发邮件,则可以用已经有的
email-receiver
- 如果是想发邮件,则可以用已经有的
- 配置
alertmanager.config.route.routes
,将告警根据label路由到你想要发送到的receiver,详见官方文档 route
建议仿照已有的配置进行编写
提交分支变更后,在github action中执行Alert Config Check
,该 action 可以根据输入读取告警规则组(默认读取rules文件夹下所有告警),并模拟这些告警触发发送至alertmanager:
- 对于email将会根据输入发送到指定的邮箱充当配置中的邮件接收者(其他无异)
- 对于webhook,将会打印最终alertmaanger发送至配置中的webhook的CURL语句,可以让开发者自行在合适的环境执行CRUL,效果等同于alertmanager发送的请求
这里将由开发者自行验证告警的效果是否符合预期
在 .github/observability/grafana-playground
下提供了 docker-compose 捆绑 Prometheus Agent 和 Grafana 的一键部署,只需在 grafana-playground/prometheus-server.yml
配置中填入 endpoint 信息即可(通常是将服务 port-forward 到本地某端口,则只需修改下方的 port )
scrape_configs:
- job_name: 'service-local'
static_configs:
# 在本地环境暴露相应端口让 prometheus 进行采集
# 或者自行在 docker-compose 中添加组件进行测试
- targets:
- 'host.docker.internal:<local-port>'
修改好后直接启动:
# 启动
docker-compose up -d
# 关闭(并删除 volumes)
docker-compose down -v
在本地打开 grafana http://localhost:3000
(用户密码为admin:admin),就可以在本地看到采集到的业务指标,并在 UI 界面中制作图表,制作完成后点击分享按钮
然后勾选 Export for sharing externally
再点击 save to file
保存到本地
remote_write:
- url: "http://your-service/metrics"
然后在本地打开 grafana http://localhost:3000
(密码为admin-admin)在 UI 界面中制作图表,制作完成后点击分享按钮
然后勾选 Export for sharing externally
再点击 save to file
保存到本地
请将 dashboard.json 提交至目录 ./charts/mo-ruler-stack/grafana/dashboards
下, 并追加项目至 ./charts/mo-ruler-stack/grafana/dashboards/README.md
在.github/CODEOWNERS
中标记该文件的owner为提交人
以上流程中,业务端进行配置时,遇到有任何问题 & bug 都可直接联系 OB 人员进行辅助