实践案例

实现全链路监控与告警

一、项目背景

二、前期调研

云原生场景下，Prometheus 与 Grafana 肯定是首选，Prometheus 负责采集指标，Grafana 负责可视化展示。
但告警组件有很多类型，以下是针对告警系统的选型对比：

1. 告警系统选型

方案 A：Alertmanager

不使用任何 Web 界面配置告警。而是通过 GitOps 手段将所有的告警规则和通知路由都写成 YAML 文件，存放在 Git 仓库中。通过 K8s Operator 自动加载。优点是便于版本控制、易于回滚、通过 CI/CD 自动化管理，极其稳定。缺点是没有UI界面，改个阈值需要提交代码，开发人员通常没权限改，需运维介入。

方案 B：Grafana

直接在 Grafana 的 Web 界面上配置告警。优点是统一在 Grafana 里管理，缺点是告警只是它的一部分功能，并非核心能力，所以告警能力较弱。

方案 C：夜莺 Nightingale

夜莺内置了类似 Alertmanager 的功能，底层数据源基于 Prometheus 或 VictoriaMetrics，上层部署夜莺。优点是有完善的 UI 界面，所有的图表查看、告警规则配置、告警屏蔽、电话/短信通知，全在夜莺里操作，解决了原生 Prometheus 难以管理（改 YAML 痛苦）和 Grafana 权限管理弱的问题。支持告警自愈、告警协同。缺点是不仅是组件，而是一个系统，依赖 MySQL/Redis，增加了一些额外的维护成本。

总结：

通过以上方案对比，最终选择夜莺作为告警平台。

参考文档：

Alertmanager 官方文档：https://prometheus.io/docs/alerting/latest/alertmanager/
Grafana 官方文档：https://grafana.com/docs/grafana/latest/alerting/
夜莺 Nightingale 官方文档：https://n9e.github.io/zh/docs/

2. 部署方式选型

在 K8s 中部署 Prometheus 与 Grafana，helm 肯定是首选方案，但 helm Chart，有两种类型：