ccfos / nightingale

An all-in-one observability solution which aims to combine the advantages of Prometheus and Grafana. It manages alert rules and visualizes metrics, logs, traces in a beautiful web UI.
https://flashcat.cloud/docs/
Apache License 2.0
9.53k stars 1.39k forks source link

能否在多级业务组中添加,各级支持自己独立告警规则,子集目录可继承父级目录告警规则并可以添加自己的告警规则 #1941

Closed sunailong closed 3 months ago

sunailong commented 4 months ago

What would you like to be added: 能否在多级业务组中添加,各级支持自己独立告警规则,子集目录可继承父级目录告警规则并可以添加自己的告警规则 Why is this needed: 这样就不用再左右的子集目录内都添加一遍相同的监控项了。例如如下图中,

UlricQin commented 4 months ago

不支持这种做法。在 Prometheus 生态里,基本都是靠监控数据的指标来筛选,比如你的用于 Dev 的 Monitor 机器,可以打上标签:env=dev,service=monitor,之后可以有两种办法配置告警规则:

方法1:拆成不同的告警规则,每个告警规则里写详细的筛选条件,适合于不同的机器不同的阈值的场景

# 告警规则1,告警接收人可能是 dev 团队
mem_used_percent{env="dev", service="monitor"} > 80

# 告警规则2,告警接收人可能是 prod 团队
mem_used_percent{env="prod", service="monitor"} > 85

方法2:只配置一条告警规则,不同的告警事件由不同的人订阅接收。需要去了解一下订阅规则。适用于不同的机器阈值相同的场景。

# 只需要一条告警规则,不需要配置告警接收人。在订阅规则那里配置不同的标签不同的接收人
# 订阅规则里,比如 `env="prod"` 的就发给 prod,`env="dev"` 的就发给 dev
mem_used_percent > 80

核心原因1:业务组的树形结构其实是假的,本质是扁平的,只是视觉效果上可以展示成树的样子。 核心原因2:promql 告警判定查的是时序库,和业务组其实没关系,没法在告警的时候联动业务组

后面会改么?

短期不会。长期的话可能会同时引入类似 zabbix 的告警模板的概念。需要从长计议。