用 Claude Code 写监控配置：从日志到告警的完整闭环

监控配置通常是最容易被拖延的事情。"先把功能做完再加监控"——等到功能做完，监控又排到下一个 sprint。Claude Code 让写监控配置变成一件快速、有意义的事。

从业务行为生成指标定义：

claude "我有一个支付服务，核心业务行为是：
- 用户发起支付
- 支付成功 / 失败
- 退款申请 / 退款成功

为这些行为定义 Prometheus 指标：
- 计数器（成功/失败分开）
- 延迟直方图（按支付渠道区分）
- 当前进行中的支付数量（Gauge）

输出 Go 的 prometheus/client_golang 代码。"

生成 Grafana Dashboard JSON：

claude "基于这些 Prometheus 指标，
生成一个 Grafana Dashboard JSON（适合 Grafana 10.x）：
- 关键指标的时间序列图
- 成功率（使用 rate() 计算）
- P50/P95/P99 延迟
- 每分钟交易量
- 告警阈值线（成功率 < 99% 用红线标注）"

分析日志模式，生成告警规则：

claude "分析这份 production.log（最近 1 小时），
找出：
1. 出现频率异常的错误模式（比平均值高 3σ）
2. 延迟突增的时间点和关联请求
3. 可以用来定义告警阈值的数据点

输出 Prometheus alerting rules YAML 格式。"

结构化日志的规范：

claude "我们用 Go slog 写日志。
设计一套日志规范：
- 每个 HTTP 请求必须记录哪些字段？
- 错误日志必须包含哪些上下文？
- 如何区分 debug / info / warn / error 级别？
- 如何确保同一请求的日志能被 trace ID 关联？

输出中间件代码和使用示例。"

从现有代码生成 SLI/SLO：

claude "分析 src/handlers/ 里的所有公共 API，
基于代码行为建议：
1. 哪些接口是用户关键路径（影响 SLO）？
2. 每个关键接口合理的延迟 SLO 是多少？
3. 可用性 SLO 应该设多少（99.9% vs 99.99%）？
4. Error budget 计算示例

不要给通用答案，要基于这个具体服务的代码。"

告警疲劳诊断：

claude "分析这份告警历史（alerts_last_30_days.csv），
找出：
1. 误报率最高的告警规则（触发了但没有实际问题）
2. 告警阈值设置不合理的规则
3. 可以合并的重复告警
4. 缺少的告警覆盖点

给出具体的规则调整建议。"

有效的监控是工程文化，不只是技术问题。但 Claude 至少能帮你把"配置复杂"这个借口去掉——现在没有理由不加监控了。