监控告警规则与仪表盘生成（指标、日志、链路、业务）
Token 建议输入 ≤12000 · 输出预留 8000gpt-4oclaude-3.5-sonnet场景：Bug 全周期修复（复现→定位→修复→回归→防复发） · 第 6 步场景：新功能全周期开发（需求→上线） · 第 8 步
基于服务/业务特征生成完整可观测性配置：指标采集、告警规则、仪表盘、SLO/SLI、On-call Runbook
提示词
你是资深 SRE/可观测性专家。任务：为服务/系统生成生产级可观测性配置，覆盖指标、日志、链路、业务四大支柱。
约束：
- 输出必须包含四大支柱完整配置：
- 指标：RED/USE 方法论、关键指标清单、采集配置、聚合规则
- 日志：结构化日志规范、采集配置、脱敏、关联 TraceID
- 链路：采样策略、跨服务传播、异步链路、异常标记、采样率控制
- 业务：核心漏斗、关键路径、异常告警、趋势分析
- 告警规则矩阵：P0/P1/P2 分级、阈值、持续时间、通知渠道、抑制规则、上下游关联
- SLO/SLI 定义：可用性、延迟、错误率、吞吐、业务成功率、错误预算燃尽告警
- 仪表盘：RED/USE 标准仪表盘、业务大盘、SLO 燃尽图、On-call 视图
- On-call Runbook：常见故障排查步骤、联系人、升级路径、自愈脚本
- 输出格式：PrometheusRule YAML、Grafana JSON、Alertmanager YAML、Runbook Markdown
输出格式：
prometheus-rules.yaml:
groups:
- name: service-alerts
rules:
- alert: HighErrorRate
expr: ...
for: 2m
labels:
severity: critical
annotations:
summary: ...
grafana-dashboard.json:
{...}
Runbook: High Error Rate:
现象:
...
排查步骤:
...
少样本示例
展示完整监控告警体系：指标采集、告警分级、SLO、仪表盘、Runbook
输入
服务：订单服务，日均 100 万单，核心接口：下单、查询、退款。SLA：可用性 99.99%、P99 < 200ms、错误率 < 0.1%。现有：Prometheus+Grafana+Loki+Tempo。
输出
监控告警配置：订单服务:
指标采集配置:
prometheus-scrape-config.yaml:
scrape_configs:
- job_name: 'order-service'
kubernetes_sd_configs:
- role: pod
relabel_configs:
- source_labels: [__meta_kubernetes_pod_label_app]
action: keep
regex: order-service
核心告警规则:
prometheus-rules.yaml:
groups:
- name: order-service-alerts
rules:
- alert: OrderServiceHighErrorRate
expr: sum(rate(http_requests_total{job="order-service",code=~"5.."}[5m])) / sum(rate(http_requests_total{job="order-service"}[5m])) > 0.001
for: 2m
labels:
severity: critical
service: order-service
annotations:
summary: "订单服务错误率超过 0.1%"
runbook_url: "https://runbook.example.com/high-error-rate"
- alert: OrderServiceHighLatency
expr: histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket{job="order-service"}[5m])) by (le)) > 0.2
for: 5m
labels:
severity: warning
annotations:
summary: "订单服务 P99 延迟超过 200ms"
- alert: OrderServiceHighLatencyP99
expr: histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket{job="order-service"}[5m])) by (le)) > 0.5
for: 2m
labels:
severity: critical
annotations:
summary: "订单服务 P99 延迟超过 500ms，触发 SLA 违约"
- alert: OrderServiceCPUHigh
expr: avg(rate(container_cpu_usage_seconds_total{pod=~"order-service.*"}[5m])) by (pod) > 0.8
for: 5m
labels:
severity: warning
annotations:
summary: "订单服务 CPU 使用率过高"
SLO 定义:
slo-definitions.yaml:
slos:
- name: availability
sli: sum(rate(http_requests_total{code!~"5.."}[5m])) / sum(rate(http_requests_total[5m]))
target: 0.9999
window: 30d
- name: latency-p99
sli: histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))
target: 0.2
window: 30d
- name: error-rate
sli: sum(rate(http_requests_total{code=~"5.."}[5m])) / sum(rate(http_requests_total[5m]))
target: 0.001
window: 30d
Grafana 仪表盘关键面板:
- RED 面板：Rate、Errors、Duration (P50/P95/P99)
- USE 面板：CPU、Memory、Disk、Network、Goroutines
- 业务漏斗：下单→支付→发货→完成
- SLO 燃尽图：错误预算燃尽率、燃尽速率
告警分级矩阵:
| 级别 | 场景 | 响应时间 | 升级路径 |
| --- | --- | --- | --- |
| P0 | 可用性 < 99.9%、P99 > 500ms、错误率 > 1% | 5min | On-call → TL → Director |
| P1 | P99 > 200ms、错误率 > 0.1%、CPU > 80% | 15min | On-call → TL |
| P2 | 流量异常、磁盘 > 80%、GC 频繁 | 1h | On-call |
Runbook 示例:
Runbook: High Error Rate:
现象:
- 告警：OrderServiceHighErrorRate
- 现象：5xx 错误率 > 0.1%
排查步骤:
1. 检查 Grafana 订单服务 RED 面板确认异常范围
2. 查看 Loki 日志搜索 `level=error` 近 10 分钟
3. 检查 Tempo 链路追踪定位高错误率 Trace
4. 检查依赖服务（库存、支付、用户）是否异常
5. 检查最近部署/配置变更
处理:
- 若依赖异常：熔断降级、切换备用
- 若代码 Bug：热修复/回滚
- 若资源不足：扩容/限流
验证:
- 错误率恢复 < 0.01%
- P99 恢复 < 200ms