
使用方式
关于
使用 Prometheus、Grafana、PagerDuty 和结构化告警实现生产系统可观测性。
name: monitoring-ops description: "可观测性模式——指标、日志、追踪、告警和基础设施监控。适用于:monitoring、observability、prometheus、grafana、metrics、alerting、structured logging、distributed tracing、opentelemetry、SLO、SLI、dashboard、health check、loki、jaeger、datadog、pagerduty。" license: MIT allowed-tools: "Read Write Bash" metadata: author: claude-mods related-skills: python-observability-ops, docker-ops, ci-cd-ops, nginx-ops
监控操作
涵盖三大支柱(指标、日志、追踪)、告警策略、仪表盘设计和基础设施监控的全面可观测性模式。
三大支柱快速参考
使用此表决定哪种可观测性信号适合你的需求:
| 支柱 | 最适用于 | 工具 | 数据类型 | |--------|----------|-------|-----------| | 指标 | 聚合数值测量、趋势、阈值告警 | Prometheus、Datadog、CloudWatch、StatsD | 时间序列(数值) | | 日志 | 离散事件、错误详情、审计追踪、调试上下文 | Loki、ELK、CloudWatch Logs、Fluentd | 非结构化/结构化文本 | | 追踪 | 跨服务请求流、延迟分解、依赖映射 | Jaeger、Tempo、Zipkin、Datadog APM | Span 树(结构化) |
何时使用哪个:
- "每秒多少请求?" → 指标(counter + rate)
- "这个特定请求为什么失败?" → 日志(错误消息 + 堆栈追踪)
- "这个请求的延迟在哪里?" → 追踪(span 瀑布图)
- "系统现在健康吗?" → 指标(gauges + 告警)
- "凌晨 3:42 发生了什么?" → 日志(时间戳事件搜索)
- "哪个下游服务导致了超时?" → 追踪(span 分析)
关联是关键: 通过在日志条目中嵌入 trace_id、在指标中记录 exemplars、将 trace spans 链接到日志查询来连接三者。
指标类型决策树
使用此决策树选择正确的指标类型:
你在测量什么?
│
├─ 只增不减的事件计数?
│ └─ COUNTER
│ 示例:http_requests_total、errors_total、bytes_sent_total
│ 使用 rate() 或 increase() 获取每秒或每间隔值
│ 永远不要使用 counter 的原始值——重启时会重置
│
├─ 可升可降的当前值?
│ └─ GAUGE
│ 示例:temperature_celsius、active_connections、queue_depth
│ 用于当前状态的快照
│ 可使用 avg_over_time()、max_over_time() 查看趋势
│
├─ 值的分布(延迟、大小)?
│ │
│ ├─ 需要跨实例可聚合的分位数?
│ │ └─ HISTOGRAM
│ │ 示例:http_request_duration_seconds、response_size_bytes
│ │ 定义桶:[0.005, 0.01, 0.025, 0.05, 0.1, 0.25, 0.5, 1, 2.5, 5, 10]
│ │ 使用 histogram_quantile() 计算百分位(p50、p95、p99)
│ │ 跨实例可聚合(histogram 可以求和)
│ │
│ └─ 需要预计算的分位数(单实例精确值)?
│ └─ SUMMARY
│ 示例:rpc_duration_seconds{quantile="0.99"}
│ 不可跨实例聚合
│ 适用于客户端库预计算
Prometheus 查询模式
# 请求速率(每秒)
rate(http_requests_total[5m])
# 错误率百分比
sum(rate(http_requests_total{status=~"5.."}[5m]))
/ sum(rate(http_requests_total[5m])) * 100
# P99 延迟
histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))
# 可用性(成功请求比例)
sum(rate(http_requests_total{status!~"5.."}[5m]))
/ sum(rate(http_requests_total[5m]))
告警最佳实践
| 原则 | 说明 | |------|------| | 基于症状告警 | 告警用户可见的影响,而非内部原因 | | 使用多窗口 | 短窗口检测突发,长窗口检测趋势 | | 设置合理阈值 | 避免告警疲劳,只在需要行动时告警 | | 包含 Runbook | 每个告警附带处理步骤链接 | | 分级严重性 | Critical(立即行动)、Warning(工作时间处理)、Info(仅记录) |
SLO/SLI 框架
| 概念 | 定义 | 示例 | |------|------|------| | SLI(服务级别指标) | 服务行为的定量测量 | 请求延迟 < 200ms 的比例 | | SLO(服务级别目标) | SLI 的目标值 | 99.9% 的请求延迟 < 200ms | | 错误预算 | 允许的不可靠量 | 0.1% = 每月约 43 分钟停机 |
结构化日志
{
"timestamp": "2024-01-15T10:30:00Z",
"level": "error",
"message": "Payment processing failed",
"service": "payment-api",
"trace_id": "abc123",
"user_id": "user_456",
"error": "timeout after 5s",
"duration_ms": 5002
}
附加资源
./references/prometheus-queries.md- 完整 PromQL 模式./references/grafana-dashboards.md- 仪表盘设计模式./references/alerting-rules.md- 告警规则模板./references/opentelemetry.md- OTel 集成模式


