---

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 集成模式