34. Monitoring & Alerting 监控告警

V1 — 1个用户：纯前端状态检测

场景

你想监控几个自己的网站是否正常运行，打开页面就能看到绿灯/红灯。

你要解决什么

• 定时检测一组URL是否可访问
• 用颜色直观显示状态（绿=正常，红=异常）
• 检测历史保存在本地，刷新不丢失

给AI的Prompt

用纯HTML+JS实现一个网站状态监控页面：

功能：
1. 页面上硬编码5个URL（如 https://example.com）
2. 每30秒用fetch发请求检测每个URL是否可达
3. 状态显示：绿色圆点=正常（HTTP 200），红色=异常
4. 每次检测结果存localStorage，保留最近100条
5. 点击某个URL显示最近24小时的状态时间线
6. 页面顶部显示"上次检测时间"

注意：fetch可能遇到CORS问题，先用no-cors模式检测（只能判断是否超时）

技术：纯HTML+CSS+JavaScript，Chart.js画状态时间线，localStorage持久化
单个index.html文件

验证清单

• 页面加载后自动开始检测
• 每30秒刷新一次状态
• 绿/红圆点正确显示
• localStorage中能看到检测历史
• 刷新页面后历史记录仍在
• 点击URL能看到时间线图表

你学到了什么

• 浏览器fetch的CORS限制 → Module: 网络基础
• setInterval定时任务 → Module: JavaScript异步
• localStorage做简单持久化 → Module: 浏览器存储

---

V2 — 10个用户：后端健康检查

场景

团队需要一个内部状态页，监控十几个服务的健康状况，前端CORS绕不过去了。

你要解决什么

• 后端发HTTP/TCP请求，绕过CORS
• 支持HTTP健康检查和TCP端口检查两种方式
• 检查结果持久化，支持查看历史

给AI的Prompt

用Go+Gin实现一个健康检查服务：

后端：
1. 配置文件定义检查目标：
   - HTTP类型：GET请求，期望状态码200，超时5秒
   - TCP类型：拨号测试端口是否开放，超时3秒
2. 后台goroutine每60秒执行一次所有检查
3. SQLite存检查结果（target_name, type, status, latency_ms, checked_at）
4. API：
   - GET /api/targets — 所有目标当前状态
   - GET /api/targets/:name/history — 某目标最近24小时历史
   - GET /api/summary — 整体概要（总数/正常数/异常数）

前端：
1. 状态页面：列表显示所有服务状态
2. 每个服务显示：名称、类型(HTTP/TCP)、状态灯、响应时间
3. 自动每30秒刷新
4. 点击服务名查看历史曲线（响应时间折线图）

技术：Go+Gin, SQLite, React前端

验证清单

• 后端启动后自动开始定时检查
• HTTP和TCP两种检查都正常工作
• SQLite中能查到检查记录
• 前端状态页实时显示
• 历史曲线图正确渲染
• 服务宕机时状态变红

你学到了什么

• 后台goroutine定时任务 → Module: Go并发
• HTTP客户端超时配置 → Module: 网络编程
• TCP拨号检测 → Module: 网络协议
• SQLite时序查询 → Module: 数据库基础

---

V3 — 100个用户：指标采集与可视化

场景

公司有几十个微服务，需要统一的指标采集、仪表盘和告警历史。

你要解决什么

• 应用暴露Prometheus格式指标
• Grafana可视化Dashboard
• 告警历史持久化到PostgreSQL

给AI的Prompt

在V2基础上添加Prometheus指标和告警系统：

指标暴露：
1. 服务暴露 /metrics endpoint（Prometheus格式）
2. 指标包括：
   - monitor_check_duration_seconds（检查耗时直方图）
   - monitor_target_up（目标状态 0/1 gauge）
   - monitor_check_total（检查总次数 counter）
3. 用prometheus/client_golang库

告警系统：
1. PostgreSQL表：alerts（id, target_name, severity, message, status, created_at, resolved_at）
2. 检查失败连续3次 → 创建告警（severity=warning）
3. 检查失败连续5次 → 升级告警（severity=critical）
4. 恢复后自动关闭告警
5. API：
   - GET /api/alerts — 当前活跃告警
   - GET /api/alerts/history — 历史告警

Docker Compose：
1. 添加Prometheus容器，配置scrape监控服务
2. 添加Grafana容器，预配置Dashboard
3. 监控服务 + PostgreSQL

技术：Go+Gin, PostgreSQL, Prometheus, Grafana, Docker Compose

验证清单

• /metrics返回Prometheus格式数据
• Prometheus能抓取到指标
• Grafana Dashboard显示检查状态和延迟
• 连续失败触发告警，记录到PostgreSQL
• 恢复后告警自动关闭
• 告警历史API可查询

你学到了什么

• Prometheus指标类型（Counter/Gauge/Histogram）→ Module: 可观测性
• Grafana Dashboard配置 → Module: 运维监控
• 告警状态机（触发→升级→恢复）→ Module: 状态管理
• Docker Compose多服务编排 → Module: 容器化

---

V4 — 1000个用户：告警规则与通知

场景

运维团队需要灵活配置告警规则，不同严重级别通知不同的人。

你要解决什么

• 可配置的告警规则（阈值、条件）
• 多通知渠道（邮件、Webhook）
• 告警静默和升级策略

给AI的Prompt

在V3基础上实现可配置告警规则引擎：

告警规则：
1. 规则模型：
   - name, target_pattern（支持通配符匹配多个目标）
   - condition: "latency > 500ms" 或 "failure_count >= 3"
   - severity: info/warning/critical
   - notification_channels: [email, webhook]
2. 规则CRUD API
3. 规则评估引擎：每次检查后评估所有匹配规则

通知系统：
1. 通知渠道配置（邮件SMTP、Webhook URL）
2. 告警触发时按渠道发送通知
3. 通知模板（Go template）支持变量替换
4. 通知记录（发送时间、渠道、状态）

告警管理：
1. 告警静默：设置时间范围内不发通知（维护窗口）
2. 告警升级：warning持续30分钟未处理 → 自动升级critical
3. 告警确认（acknowledge）：运维人员确认已知晓
4. 用Redis缓存当前告警状态，减少数据库查询

技术：Go+Gin, PostgreSQL, Redis, 邮件(net/smtp), Webhook(HTTP POST)

验证清单

• 创建告警规则后能匹配目标
• 阈值条件正确触发告警
• 邮件/Webhook通知正常发送
• 静默期间不发送通知
• 告警自动升级正常工作
• 确认告警后不再重复通知
• Redis缓存命中率可观测

你学到了什么

• 规则引擎设计模式 → Module: 设计模式
• Go template模板渲染 → Module: Go标准库
• Redis缓存策略 → Module: 缓存
• 通知系统的幂等性 → Module: 分布式系统

---

V5 — 1万个用户：分布式探测

场景

用户分布全球，需要从多个地域探测服务可达性，并建立SLO体系。

你要解决什么

• 多地域探测节点，检测不同地区的访问质量
• 链路追踪集成，定位慢请求根因
• SLO/SLI自动计算和报告

给AI的Prompt

在V4基础上实现分布式探测和SLO体系：

多地域探测：
1. 探测节点注册：每个节点启动时向中心注册（node_id, region, ip）
2. 中心下发检查任务给各节点
3. 各节点执行检查，结果上报中心
4. 同一目标的多地域结果聚合（某地异常≠全局异常）
5. 节点心跳检测，节点离线告警

链路追踪：
1. 集成OpenTelemetry SDK
2. 每次检查生成trace，记录各阶段耗时（DNS/连接/TLS/首字节）
3. 慢检查自动关联trace，方便排查

SLO/SLI：
1. SLI定义：可用性 = 成功检查次数 / 总检查次数
2. SLO配置：如"可用性 >= 99.9%（滚动30天）"
3. Error Budget计算和燃烧率告警
4. SLO Dashboard：当前状态、趋势、剩余Error Budget
5. 月度SLA报告自动生成（PDF/HTML）

技术：Go微服务, gRPC(节点通信), OpenTelemetry, PostgreSQL, Redis

验证清单

• 探测节点成功注册到中心
• 各节点独立执行检查并上报
• 多地域结果正确聚合
• 节点离线能被检测到
• OpenTelemetry trace正确生成
• SLI计算准确，SLO状态正确
• Error Budget燃烧率告警触发

你学到了什么

• 分布式任务调度 → Module: 分布式系统
• gRPC通信 → Module: RPC框架
• OpenTelemetry链路追踪 → Module: 可观测性
• SLO/SLI/Error Budget → Module: SRE实践

---

V6 — 10万+用户：AIOps智能运维

场景

海量告警让运维疲于应对，需要智能降噪、自动根因分析和自动修复。

你要解决什么

• 异常检测：统计方法识别指标异常
• 根因分析：关联分析定位故障源
• 告警聚合降噪：减少告警风暴
• 自动化修复（Runbook）

给AI的Prompt

在V5基础上实现AIOps能力：

异常检测：
1. 对每个指标维护滑动窗口统计（均值、标准差）
2. 3-sigma异常检测：偏离均值3个标准差视为异常
3. 季节性检测：按小时/星期维护基线，识别周期性异常
4. 异常事件存储，支持回溯分析

根因分析：
1. 服务依赖拓扑图（手动配置或自动发现）
2. 故障传播分析：从叶子节点向上追溯
3. 时间相关性：在时间窗口内关联多个异常事件
4. 根因建议排序（按概率/影响）

告警聚合降噪：
1. 相似告警合并（同一服务/同一类型）
2. 告警风暴抑制：短时间大量告警只发一条摘要
3. 告警去重：相同告警不重复通知
4. 降噪统计：展示原始告警数 vs 实际通知数

Runbook自动化：
1. Runbook定义：触发条件 + 自动执行步骤
2. 步骤类型：HTTP调用、脚本执行、重启服务
3. 执行日志和回滚机制
4. 人工审批模式（critical级自动化需人工确认）

技术：Go, PostgreSQL, Redis, 时序计算, DAG依赖图

验证清单

• 注入异常数据后3-sigma检测触发
• 依赖拓扑图正确渲染
• 故障传播路径分析准确
• 告警风暴被正确抑制
• 降噪比例统计展示
• Runbook自动执行并记录日志
• critical级Runbook触发人工审批
• 回滚机制正常工作

你学到了什么

• 统计异常检测（3-sigma/Z-score）→ Module: 数据分析
• 依赖拓扑与故障传播 → Module: 图算法
• 告警聚合策略 → Module: 事件处理
• 自动化运维（Runbook）→ Module: SRE实践