用途
该技能用于为生产服务构建可观测性基础，定位是“从第一天就开始搭建”的基础设施，而非上线后才补充的功能。目标是让团队能够在不部署新代码的前提下，对系统行为提出任意问题，从而快速定位生产事故。
三条支柱
资料将可观测性拆为三条互补支柱：
- 日志：告知发生了什么，即带上下文的离散事件，例如“用户 X 登录失败：token 过期”。
- 指标：告知系统当前表现，即随时间聚合的数值，例如“p99 延迟 450ms 且仍在上升”。
- 追踪：告知为什么变慢，即一次请求跨服务的完整路径，例如“user-service 中的 Postgres 查询耗时 2.3s”。
三者的协同方式：指标触发告警（错误率 > 1%），按时间窗口过滤日志查看具体错误，从日志中提取 trace ID 追踪到慢服务，修复后验证指标恢复。
主要能力
结构化日志
资料强调非结构化日志在生产中无法过滤、聚合或做看板。给出 Python 的 structlog 配置示例（含处理器链、JSON 渲染、开发环境控制台渲染、屏蔽 uvicorn.access、httpx、sqlalchemy.engine 等噪音库），以及 Node.js 的 pino 配置示例（含日志级别、pino-pretty 传输、service 基础字段、对 authorization、cookie、password、token 的 redact 脱敏）。
日志级别被视为与值班工程师的约定：ERROR 需要人工关注并应触发告警；WARNING 是意外但被处理的情况；INFO 记录业务事件与正常路径；DEBUG 仅供开发者诊断且不应出现在生产。规则包括：没人会读的日志不要打；ERROR 必须有对应告警，否则应降为 WARNING；生产 DEBUG 是零价值的性能负担。
明确禁止记录的字段：密码、token/授权头、信用卡号、SSN/PII、原始请求体（可能含密钥）。每条日志应尽量包含 request_id、trace_id、user_id、业务实体 ID、金额与币种、service 等字段。
跨服务关联 ID：在边缘为每个请求生成唯一 ID，通过 header 向下游传递，并写入每一行日志。资料给出 Starlette/ASGI 中间件的 CorrelationIDMiddleware 实现（读取 x-request-id 或 x-correlation-id，否则生成 UUID，绑定到 structlog contextvars，并在响应头回写 x-request-id），以及使用 httpx 向下游传递 X-Request-ID 的示例。
OpenTelemetry 链路追踪
资料将 OpenTelemetry 定位为厂商中立标准，一次埋点可导出到 Jaeger、Tempo、Datadog 或任意 OTLP 后端。给出 Python 依赖列表（opentelemetry-api、opentelemetry-sdk、opentelemetry-exporter-otlp-proto-grpc，以及 fastapi、sqlalchemy、httpx、redis 的 instrumentation 包），完整的 FastAPI 集成代码（Resource 配置服务名、版本、部署环境，BatchSpanProcessor + OTLPSpanExporter，自动埋点 SQLAlchemy、HTTPX、Redis，并在 lifespan 中配置与关闭）。
资料指出自动埋点只覆盖库层面，最有价值的 span 应在业务逻辑上，并给出 process_order 的示例：为 process_order、validate_inventory、charge_payment 创建嵌套 span，设置 order.id、user.id 属性，失败时设置 span 状态与错误信息，成功后添加 order_completed 事件及订单总额。上下文传播采用 W3C TraceContext，已埋点的 HTTP 客户端会自动注入 traceparent；未埋点的客户端可用 opentelemetry.propagate.inject 手动注入 traceparent 与 tracestate。导出端示例使用 Jaeger 容器命令与 OTEL_EXPORTER_OTLP_ENDPOINT 环境变量。
指标（RED 方法）
RED 方法给出三个最关键的指标：Rate（每秒请求数）、Errors（错误率，含 4xx 与 5xx）、Duration（延迟分布，p50/p95/p99）。
资料给出 Python prometheus_client 的计数器、直方图与仪表定义，以及 PrometheusMiddleware 的实现：将路径中的数字和 UUID 归一化为 {id} 以避免基数爆炸，记录进行中请求数、请求总数（按 method、endpoint、status_code）与请求耗时，并提供 metrics_endpoint 输出 generate_latest。
同时给出业务指标示例：orders_placed_total（按支付方式与地区）、order_value_dollars 直方图、active_users_current 仪表。
基数意识被视为 Prometheus 最常见的配置错误：标签取值必须有界（少于 100 个唯一值），绝不能把 user_id、request_id 或时间戳作为标签；需要按用户维度分析时应使用日志或追踪；并建议监控 prometheus_tsdb_head_series 是否无界增长。
健康检查端点
资料给出三类探针：
- /health/live（存活）：始终返回 200，绝不检查依赖，避免慢数据库导致容器被重启。
- /health/ready（就绪）：检查所有关键依赖，失败则从负载均衡中移除（不重启）。示例包含数据库与 Redis 检查，每个检查有 2 秒超时，健康返回 200，不健康返回 503 并附带各依赖状态。
- /health/startup（启动）：面向启动慢的服务（ML 模型、迁移），Kubernetes 会先等待该探针再开始存活探测，示例通过 app.state.startup_complete 判断。
并给出 Kubernetes 探针配置：livenessProbe 连续 3 次失败重启容器，readinessProbe 连续 3 次失败从 Service 移除但不重启，startupProbe 以 30 次、每次 5 秒即最多 150 秒启动时间。资料还建议将健康端点排除在访问日志与鉴权中间件之外。
告警
资料强调告警疲劳比没有告警更糟，会导致团队忽略分页并漏掉真实事故。核心原则是“对症状告警，而非对原因告警”：例如基于 CPU 使用率超 80% 的告警会在部署与批处理任务时频繁触发而被忽略；而基于用户实际遭遇错误的告警（如错误率过高）才有意义。资料以 YAML 片段形式给出告警表达式示例，原文在此处截断。
适用场景
适用于需要为生产服务建立可观测性基础的 Web 服务与微服务场景，尤其是使用 Python（FastAPI、SQLAlchemy、httpx、Redis、structlog、prometheus_client、OpenTelemetry）或 Node.js（pino）技术栈，并运行在 Kubernetes、ECS、Cloud Run 等编排平台上的服务。
限制
资料原文在“告警最佳实践”的 YAML 示例处被截断，该部分内容不完整。SLO 定义在标题中被提及，但资料未展开具体内容。资料未说明该技能的安装方式、支持的平台范围、收费情况或使用限制，这些信息暂未提供。