3. Grafana 告警体系：从 Prometheus 到 Loki 的告警演进

3.1 告警体系演进路线：从 Prometheus 到 Loki 的架构变迁

在可观测性领域，告警体系经历了从单数据源告警到统一告警管理的深刻变革。Prometheus 的 Alertmanager 是早期告警体系的代表，它专注于处理基于指标（Metrics）的告警规则，而 Loki 的引入则带来了基于日志（Logs）的告警能力。Grafana Alerting 作为统一告警管理器，将这两者整合到一个统一的控制平面中。

3.2 Grafana Alerting 统一告警管理器架构

Grafana Alerting 是 Grafana 内置的统一告警引擎，它不再依赖外部的 Alertmanager 或 Loki Ruler 进行告警评估和路由，而是将所有告警规则、评估、路由、静默和通知集中管理。其核心组件包括：

3.3 从 Prometheus 到 Loki 的告警规则迁移

当从 Prometheus 告警迁移到 Grafana 统一告警时，需要理解两种规则定义方式的差异。以下是一个典型的迁移对照：

3.4 告警路由与通知策略的标准化

在 Grafana Alerting 中，Notification Policy 取代了传统 Alertmanager 的 route 配置。它采用树形结构，支持基于标签的精确匹配、正则匹配和默认路由。以下是一个标准化的告警路由配置示例：

// Grafana Notification Policy 树形结构（UI 配置等效）
// 根策略：默认路由
//   ├── 子策略 1：匹配 severity="critical"
//   │   └── 发送到 PagerDuty + Slack
//   ├── 子策略 2：匹配 severity="warning" + team="platform"
//   │   └── 发送到 Slack #platform-alerts
//   ├── 子策略 3：匹配 source="loki" + log_type="error"
//   │   └── 发送到 Webhook (变更窗口事件)
//   └── 默认子策略：匹配所有未匹配告警
//       └── 发送到 Email 摘要

3.5 告警模板与标准化通信

Grafana Alerting 支持使用 Go 模板 自定义通知消息。这对于变更窗口场景尤为重要——你可以将告警的上下文信息（如变更 ID、服务名称、时间戳）嵌入到通知中，形成标准化的通信格式。

以下是一个标准的告警通知模板示例：

{{ define "changewindow_alert" }}
[{{ .Status | toUpper }}] 变更窗口告警
变更 ID: {{ .Labels.changewindow_id }}
服务: {{ .Labels.service }}
环境: {{ .Labels.environment }}
告警名称: {{ .Labels.alertname }}
描述: {{ .Annotations.description }}
触发时间: {{ .StartsAt | date "2006-01-02 15:04:05" }}
当前值: {{ .Values.A }}
{{ end }}

3.6 从 Prometheus 到 Loki 告警的实践要点

在迁移或新建告警体系时，需要关注以下实践要点：

1. 告警规则统一管理：将所有告警规则迁移到 Grafana Alerting，避免分散在 Prometheus 和 Loki Ruler 中。
2. 标签标准化：定义统一的标签命名规范（如 severity、team、service、changewindow_id），确保路由策略可正确匹配。
3. 评估间隔与延迟：Loki 日志告警通常需要更大的评估间隔（如 1m-5m），以应对日志采集和索引的延迟。
4. 告警分组降噪：利用 Notification Policy 的分组功能，将相同变更窗口的告警合并为一条通知，避免告警风暴。
5. 静默与变更窗口联动：通过 API 或 Webhook 在变更窗口开启时自动创建 Mute Timing，关闭时自动清理。