为 Prometheus 告警规则增加 UI 管理能力

Prometheus 体系貌似已经成为新时代的监控标准,运维出去找工作,很多公司都要求掌握 Prometheus 相关知识。

但是,Prometheus 实际在应用时,通常会遇到一个典型问题:告警规则管理问题。体现为:

想要把 Prometheus 能力开放给全公司各个团队自助服务。但是告警规则需要编写 Yaml 文件,虽然很多公司都已经使用 Git 来管理这些规则,但是仍然需要运维团队来统一 Code Review 之后才能 Merge 进主干,因为担心某个人提交规则时,影响了其他人的规则。甚至有些公司是:研发团队给运维团队提工单,由运维团队统一维护管理这些告警规则。这着实有些痛苦。效率也太低。

有痛苦必有解法。今天为大家介绍一个开源项目,就是来解决这个问题的,它的名字是:Nightingale,即夜莺监控。

夜莺监控可以充当 Prometheus 的告警引擎,用户可以在 Nightingale 的 UI 中管理告警规则,UI 有权限控制,不同的规则相互之间没有影响。而且:

  • 夜莺的告警引擎是高可用的,可以部署多个夜莺进程组成集群,某个节点挂了,整体告警功能不受影响
  • 夜莺不但可以对 Prometheus 时序数据做告警,也可以对 VictoriaMetrics、Thanos、Mimir 等其他时序库告警,也可以对 ElasticSearch、Loki 告警,也可以对 ClickHouse、MySQL、Postgres 等其他存储的数据做告警

夜莺项目相关地址:

  • 代码:https://github.com/ccfos/nightingale
  • 文档:https://n9e.github.io/

从代码仓库的地址可以看出,其 github group 是 ccfos,ccfos 是中国计算机学会开源技术发展委员会的 group,夜莺项目是托管在基金会下运作,不会突然闭源或修改开源协议。

下面我们演示一下夜莺项目的部署和告警规则的配置。

部署夜莺监控

夜莺监控作为一款开源项目,其发布包也是在 github releases 页面:

https://github.com/ccfos/nightingale/releases

当前最新版本是 v8.2.2,我是 arm64 的环境,所以下载:n9e-v8.2.2-linux-arm64.tar.gz

一般生产环境都是 Linux,所以夜莺默认提供的是 Linux 发布包,实际上,夜莺也可以跑在 Windows 或者 Mac 上面,只是官方没有提供默认的发布包,需要自行编译了。

使用如下命令解压缩:

/* by 01130.hk - online tools website : 01130.hk/zh/post.html */
mkdir n9e
tar zxvf n9e-v8.2.2-linux-arm64.tar.gz -C n9e

然后进入 n9e 目录直接启动就可以了:

./n9e

默认监听在 17000 端口,可以使用浏览器访问 WEB UI,默认用户名是 root,默认密码是 root.2020

之所以可以一键启动,是因为默认使用的存储是 sqlite,默认使用缓存是 miniredis(内置到进程内存里了),如果是生产环境,请使用单独的 MySQL 和 Redis。MySQL 和 Redis 相关的连接配置在 n9e 二进制同级目录下的 etc 目录的 config.toml 里。

配置文件里各项是什么含义,请参考:夜莺配置文件详解。

OK,夜莺部署完了,如何配置 Prometheus 告警规则呢?

接入数据源

进入夜莺的 集成中心-数据源 管理页面,把 Prometheus 作为数据源配进来,这点跟 Grafana 很像:

然后查询一下其中的数据做验证。到 指标-即时查询,即可查询时序库中的监控数据,如果能够查到数据,说明数据源配置的是没问题的。

配置告警规则

菜单位置:告警-规则管理。由于告警规则可能会有很多,不同的团队希望分门别类管理,所以夜莺里抽象了一个业务组的概念,安装完成之后有个默认业务组,我们可以选中这个业务组,右侧就会出现新增、导入的按钮,用于创建告警规则。

我们可以先点击新增,大概浏览一下夜莺的告警规则有哪些配置:

基础配置,用于配置告警规则名称(即 Prometheus 里的 alertname)、附加标签(即 Prometheus 里的 labels)、备注(即 Prometheus 里的 annotations.description),当然,因为夜莺里有权限管控,所以告警规则归属于某个业务组,刚才我们是点击了 Default Busi Group 之后再创建业务组,所以这个页面就会自动填充上业务组信息。

这里是配置 promql 查询条件的,可以配置多个(多个之间支持抑制),也可以启用变量,如果只是简单使用,就只需要配置 promql 即可。另外:

  • 执行频率。就是多久查询一次这个 promql,如果查到了就表示数据异常,相当于 Prometheus 里的 eval interval。夜莺的执行频率支持 cron 写法。
  • 持续时长。相当于 Prometheus 里的 for 关键字。

各个字段的标题旁边都有个小问号的 icon,鼠标挪上去(有些需要点击)会展示用法提示。

事件 relabel 是对告警事件做 relabel 操作,Prometheus 生态里也有 relabel 的逻辑,是对 metrics 的 relabel,夜莺里可以对告警事件做 relabel。

后面还会在告警规则颗粒度引入更多 Processor,支持事件的 Pipeline 处理,那就极为灵活了。

生效时间配置,就是告警规则的生效时间,对于一些证券类的场景很有用,有些时候,告警规则只想白天运行,晚上就不想运行了,或者白天一个阈值晚上一个阈值,在夜莺里都可以实现。

告警事件产生之后要通知出去,所以后面要配置通知规则,通知规则是在其他菜单管理的,主要是用于配置不同的告警发给不同的人,不同的告警使用不同的通知媒介(比如高优的告警打电话,低优的告警的发邮件)。

留观时长、重复通知间隔、最大通知次数,见名知意,右侧也都有小问号 icon,可以点击查看具体用法提示。

  • 告警自愈。夜莺支持在告警的时候去告警机器上执行一个脚本,比如磁盘满了自动清理一下,或者自动抓个现场。所以告警规则这里可以关联自愈脚本。
  • 附加信息。类似 Prometheus 中的 annotations,比如把 SOP 的 URL 放进来。

除了手工创建告警规则,我们也可以导入 Prometheus 之前的告警规则。

导入 Prometheus 告警规则

Prometheus 生态有很多人分享了告警规则,比如这个项目:awesome-prometheus-alerts 每个目录下都是 yaml 格式的告警规则,比如 host-and-hardware 目录下就是常见的 node-exporter 的告警规则。

我们可以拷贝 Yaml 内容,然后在夜莺里点击那个导入按钮,导入 Prometheus 的规则:

夜莺告警引擎的其他能力

除了可以页面化管理告警规则、支持引擎高可用之外,夜莺的告警规则还有另外两个有意思的点:

  • 可以使用一套告警规则,生效到多个时序库,这样管理起来更方便
  • 可以处理边缘时序库场景。比如有个时序库能连中心的夜莺进程,但是夜莺进程连不上边缘时序库,这种场景也可以支持。具体可以参考夜莺的文档,或者等后面的文章。

本文介绍了夜莺开源项目来纳管 Prometheus 告警规则,希望对你有用。

内容概要:本文详细介绍了“秒杀商城”微服务架构的设计与实战全过程,涵盖系统从需求分析、服务拆分、技术选型到核心功能开发、分布式事务处理、容器化部署及监控链路追踪的完整流程。重点解决了高并发场景下的超卖问题,采用Redis预减库存、消息队列削峰、数据库乐观锁等手段保障数据一致性,并通过Nacos实现服务注册发现与配置管理,利用Seata处理跨服务分布式事务,结合RabbitMQ实现异步下单,提升系统吞吐能力。同时,项目支持Docker Compose快速部署和Kubernetes生产级编排,集成Sleuth+Zipkin链路追踪与Prometheus+Grafana监控体系,构建可观测性强的微服务系统。; 适合人群:具备Java基础和Spring Boot开发经验,熟悉微服务基本概念的中高级研发人员,尤其是希望深入理解高并发系统设计、分布式事务、服务治理等核心技术的开发者;适合工作2-5年、有志于转型微服务或提升架构能力的工程师; 使用场景及目标:①学习如何基于Spring Cloud Alibaba构建完整的微服务项目;②掌握秒杀场景下高并发、超卖控制、异步化、削峰填谷等关键技术方案;③实践分布式事务(Seata)、服务熔断降级、链路追踪、统一配置中心等企业级中间件的应用;④完成从本地开发到容器化部署的全流程落地; 阅读建议:建议按照文档提供的七个阶段循序渐进地动手实践,重点关注秒杀流程设计、服务间通信机制、分布式事务实现和系统性能优化部分,结合代码调试与监控工具深入理解各组件协作原理,真正掌握高并发微服务系统的构建能力
### Prometheus 告警配置与管理 #### 配置告警规则 Prometheus 警报规则使用 YAML 格式进行定义[^4]。这些规则基于 PromQL 查询来指定触发条件。每当查询的结果为真时,就会创建一个新的告警实例。 ```yaml groups: - name: example rules: - alert: HighRequestLatency expr: job:request_latency_seconds:mean5m{job="myjob"} > 0.1 for: 10m labels: severity: page annotations: summary: "High request latency on {{ $labels.instance }}" description: "{{ $labels.instance }} has a mean request latency above 0.1s (current value: {{ $value }})" ``` 此段代码展示了如何编写一条简单的告警规则,该规则会在 `request_latency_seconds` 平均值超过 0.1 秒并持续十分钟的情况下触发告警。 #### 显示告警状态 对于只想在 Prometheus 的界面上查看告警状态而不发送通知的情况,Prometheus 自身能够处理告警规则并在其 UI 中显示告警的触发状态,但这仅限于在 Prometheus 的仪表板上查看[^1]。 #### Alertmanager集成 Alertmanager 接收来自 Prometheus 发送的告警,负责管理和传递告警信息。它提供了多种功能如分组、静默、抑制和聚合等,并能将告警通过路由发送到相应的接收器上,支持邮件、Slack 及 Webhook 方式发送告警通知[^3]。 #### 实际案例中的应用 在一个企业级 Prometheus 部署中,可以观察到具体的部署过程和优化步骤有助于理解如何有效地实施监控策略。这不仅涉及技术细节还包括最佳实践的应用[^2]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值