69 lines
2.2 KiB
Markdown
69 lines
2.2 KiB
Markdown
---
|
|
title: "Alerting"
|
|
type: concept
|
|
tags: [Monitoring, Automation, Notification, Threshold]
|
|
sources: [dynamic-dashboard]
|
|
last_updated: 2026-04-22
|
|
---
|
|
|
|
## Definition
|
|
|
|
**Alerting** 是在指标超过预设阈值时，主动通知相关人员的机制。与被动查询仪表盘不同，告警实现"异常来找人"而非"人去查异常"的范式转变。
|
|
|
|
## 核心洞察
|
|
|
|
> "指标异常不是被看到，而是被通知"
|
|
|
|
## 告警生命周期
|
|
|
|
```
|
|
Threshold Exceeded → Alert Triggered → Notification Sent → Acknowledged → Resolved
|
|
│ │ │ │ │
|
|
监控规则 事件生成 多渠道推送 用户确认 问题修复
|
|
```
|
|
|
|
## 告警类型
|
|
|
|
1. **阈值告警**
|
|
- 固定阈值: `if cpu > 90% → alert`
|
|
- 变化率: `if stars_change > 50/hour → alert`
|
|
|
|
2. **趋势告警**
|
|
- 异常检测: Twitter 负面情绪突增
|
|
- 预测告警: 基于历史趋势预测故障
|
|
|
|
3. **复合告警**
|
|
- 多条件组合: `if cpu > 80% AND disk < 20% → alert`
|
|
|
|
## 告警渠道
|
|
|
|
| 渠道 | 适用场景 | 优势 |
|
|
|------|----------|------|
|
|
| Discord | 团队协作/实时讨论 | 频道分类、@mention |
|
|
| Email | 正式记录/异步通知 | 归档、可搜索 |
|
|
| Slack | 企业团队集成 | 频道/线程组织 |
|
|
| Telegram | 个人/移动优先 | 即时推送 |
|
|
| SMS | 紧急故障 | 无网络依赖 |
|
|
|
|
## 告警疲劳管理
|
|
|
|
- **聚合**: 相似告警合并，减少噪音
|
|
- **静默期**: 维护窗口自动静默
|
|
- **升级**: 无人响应时升级通知级别
|
|
- **去重**: 同一问题不重复通知
|
|
|
|
## 与 Prometheus Alertmanager 的对比
|
|
|
|
| 维度 | 自定义 Alerting | Prometheus Alertmanager |
|
|
|------|----------------|------------------------|
|
|
| 触发规则 | 自然语言描述 | PromQL 表达式 |
|
|
| 数据源 | 任意 API | Prometheus metrics |
|
|
| 灵活性 | 高（对话式调整） | 中（规则编写） |
|
|
| 集成成本 | 低 | 中 |
|
|
|
|
## Related Concepts
|
|
|
|
- [[Dynamic-Dashboard]] — 告警是动态仪表盘的核心输出
|
|
- [[Scheduled-Task-Flywheel]] — 定时检查是告警的前置条件
|
|
- [[Prometheus告警规则]] — Prometheus 生态的规则定义方式
|