用途
本技能面向生产系统的监控、可观测性与事件响应，帮助在日志、指标、追踪三类数据之间建立关联，从「出了问题」推进到「知道原因」。当用户询问结构化日志、分布式追踪、指标、告警或事件响应相关实践时适用。
可观测性三大支柱
- 日志：应用发出的离散事件（错误、状态变化、审计轨迹）。基数高，每个事件可携带唯一上下文，最适合事后调试具体事件。
- 指标：随时间聚合的数值测量（计数器、仪表、直方图）。基数是设计上受控的，标签应有有限取值集合，最适合发现趋势、设置阈值与告警。
- 追踪：记录单个请求穿越多个服务的过程，每个追踪由代表单独操作的 span 组成，最适合定位延迟瓶颈与依赖故障。
三者如何连接：指标告警触发（如错误率飙升）→ 按服务与时间窗查询日志 → 从日志中取出 trace ID 查看完整请求路径。
结构化日志
非结构化文本日志难以搜索与聚合；结构化日志（通常为 JSON）使每个字段可被机器解析。示例字段包括 timestamp、level、service、trace_id、correlation_id、message、duration_ms。
日志级别：DEBUG（仅开发）、INFO（正常操作）、WARN（可恢复问题）、ERROR（请求级失败）、FATAL（进程必须退出）。
关联 ID：在边缘（API 网关）生成唯一 ID，通过 X-Request-ID 头传播到每个下游调用，并写入每一行日志，以重建完整请求路径。
指标类型
- Counter（计数器）：单调递增，用 rate() 查询，例如总请求数、总错误数。
- Gauge（仪表）：可升可降，例如内存使用、活跃连接数、队列深度。
- Histogram（直方图）：在可配置桶中计数观测值，产生 _bucket、_sum、_count 序列，用 histogram_quantile() 求延迟分布。
- Summary（摘要）：客户端计算分位数，无法跨实例聚合，多数场景优先用直方图。
Prometheus 基础
Prometheus 是基于拉取（pull）的指标系统，抓取以文本格式暴露指标的 HTTP 端点。文中给出抓取配置示例（global.scrape_interval、job_name、static_configs、metrics_path、kubernetes_sd_configs、relabel_configs）。
关键 PromQL 查询示例：
- rate(http_requests_total[5m]) —— 请求速率
- histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])) —— p99
- sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) —— 错误比例
告警规则示例包含 alert: HighErrorRate、expr、for: 5m、labels.severity: critical 及 annotations（summary、runbook_url）。
Grafana 仪表盘
数据源支持 Prometheus、Loki、Elasticsearch、InfluxDB、CloudWatch 等。面板类型包括时间序列、Stat、Table、Heatmap、Logs。可用模板变量（如 $namespace、$service、$instance）让一个仪表盘服务多个团队。Grafana 9+ 提供统一告警引擎，可按标签路由通知到 Slack、PagerDuty 或 OpsGenie。
日志聚合
- ELK（Elasticsearch、Logstash、Kibana）：ES 存储并全文索引日志；Logstash 摄取、转换与发送；Kibana 提供查询、可视化与仪表盘。资源占用较重，适合有平台团队的大型组织。
- Loki：仅按标签索引日志而非全文，运营成本低得多；LogQL 语法与 PromQL 类似；与 Grafana 天然搭配，用 Promtail 或 Grafana Agent 发送日志。
选择建议：需要跨所有字段全文搜索选 ELK；需要低成本存储加基于标签的查询选 Loki；已在运行 Prometheus 与 Grafana 时，Loki 可降低运维负担。
告警策略
告警疲劳：每个告警都必须可行动，若无人需要处理就删除。优先对症状（用户受影响）告警，而非原因（CPU 高）。
严重级别：P1/Critical（服务宕机或数据丢失，立即呼叫）、P2/High（降级、部分中断，工作时间内呼叫）、P3/Medium（非紧急、有绕行方案，开单数天内修复）、P4/Low（外观或轻微问题，进入待办）。
Runbook：每个告警应链接到包含告警含义、如何验证、缓解步骤、升级联系人与相关仪表盘链接的 runbook，并与告警规则一同纳入版本控制。
通知路由：P1/P2 路由到值班呼叫工具，P3/P4 路由到 Slack 或工单系统；配置升级策略，主值班在 N 分钟内未确认则呼叫备班。
SLI、SLO 与错误预算
- SLI：服务某方面的定量度量，如可用性（成功请求百分比）、延迟（低于阈值的请求百分比）。
- SLO：SLI 在时间窗内的目标，如 30 天滚动窗口内 99.9% 请求成功。
- 错误预算：允许的不可靠度 1 − SLO。99.9% 的 SLO 给出 0.1% 预算（约每 30 天 43 分钟停机）。预算接近耗尽时冻结发布、专注可靠性。
建议：每个服务从一两个 SLO 开始；从客户端视角测量（负载均衡日志、合成探针）；在每周可靠性会议中评审。
健康检查与就绪探针
- Liveness：进程是否存活？失败时 Kubernetes 重启 Pod。保持简单，如事件循环运行即返回 200。
- Readiness：能否接受流量？失败时 Kubernetes 将 Pod 从负载均衡中移除。需检查依赖（数据库连接池、缓存）。
- Startup：防止存活检查杀死启动缓慢的容器。
文中给出 livenessProbe 与 readinessProbe 的 YAML 示例（httpGet、initialDelaySeconds、periodSeconds）。
RED 方法与 USE 方法
RED（面向请求驱动服务）：Rate（每秒请求数）、Errors（每秒失败请求数）、Duration（延迟 p50/p95/p99）；错误率或延迟超过 SLO 阈值时告警。
USE（面向资源，如 CPU、内存、磁盘、网络）：Utilization（资源繁忙百分比）、Saturation（超出容量的排队工作）、Errors（错误事件）。高利用率本身不是问题，高饱和意味着资源是瓶颈；基础设施瓶颈常表现为请求延迟上升（把 USE 与 RED 联系起来）。
可用性监控
- 合成检查：从多区域模拟用户操作的自动化脚本，工具如 Grafana Synthetic Monitoring、Checkly、Pingdom。
- 真实用户监控（RUM）：从真实浏览器收集性能数据，测量页面加载、可交互时间、Core Web Vitals，捕捉合成监控无法覆盖的真实网络条件与设备多样性。
- 状态页：对外发布服务状态（Statuspage、Instatus），尽量把更新从告警状态变化自动化。
事件响应流程
检测（告警触发、用户报告、合成检查失败）→ 分诊（评估范围与受影响用户、定级、开事件频道）→ 缓解（先恢复服务，根因稍后处理：回滚、扩容、切换功能开关、故障转移，并定期沟通）→ 解决（确认指标恢复正常，关闭事件频道并更新状态页）→ 复盘（48 小时内写出无指责复盘，包含时间线、根因、影响、做得好的地方与行动项，并跟踪到完成）。
应优先建设的仪表盘
服务概览（每服务 RED 指标）、基础设施（每节点/Pod 的 CPU、内存、磁盘、网络，USE）、SLO 追踪（当前 SLI 值、剩余错误预算、燃烧率）、部署叠加（在错误率与延迟图上标注部署事件）、数据库（查询速率、慢查询、连接池、复制延迟）、队列/worker（入队速率、出队速率、队列深度、处理时间）。
反模式
对一切告警（制造噪音与值班倦怠，应对用户可见症状告警）；没有 runbook（凌晨被呼叫却无处置指引）；缺少上下文的指标（仪表盘全是无法解释的数字）；记录敏感数据（PII 或密钥造成合规风险，记录前需清洗字段）；忽视基数（指标中使用无界标签值如用户 ID、请求 ID 会撑爆存储并拖慢查询，高基数数据应放日志与追踪）；缺少跨支柱关联（指标、日志、追踪彼此割裂；应在日志中包含 trace ID、在指标中加入 exemplar，并使用支持交叉引用的工具，如 Grafana 配合 Prometheus、Loki 和 Tempo）。
参考资料
Google SRE 手册（监控与告警章节）、Observability Engineering（Majors、Fong-Jones、Miranda，O'Reilly）、Prometheus 文档 https://prometheus.io/docs/、Grafana 文档 https://grafana.com/docs/、OpenTelemetry https://opentelemetry.io/、RED 方法（Tom Wilkie）、USE 方法（Brendan Gregg）。