这是「华为云码道实战」系列的第十篇。前九篇覆盖了成长、观点、安全、性能、部署、数据、技术债、需求、MCP 架构。这一篇回到运维——服务能跑不等于可观测，出问题时抓瞎才是最大的痛。

我造了一个"裸奔"的 Flask 订单服务（能跑但零可观测性），丢给华为云码道的可观测性配置专家，让它一次性配上日志、指标、链路、告警四件套——产出了 5 个配置文件、5 个核心指标、5 条告警规则。

一、"裸奔"的服务有多痛

先造一个典型的"能跑"服务：一个 Flask 订单服务，5 个端点（查询订单、列表、创建、取消、用户统计），SQLite 存储，调外部支付验证 API。

# app.py —— 能跑，但出问题你什么都不知道
@app.route('/api/v1/orders', methods=['POST'])
def create_order():
    data = request.get_json()
    valid = verify_payment(payment_id, amount)  # 调外部API，超时了？不知道
    # ...
    return jsonify({"code": 0, "data": {"order_id": order_id, "status": status}})

这种服务上线后，出问题是这样的：

• 用户说"下单失败了" → 你查代码猜原因，没有日志告诉你请求到了哪一步
• 支付验证超时增多 → 没有指标，你不知道超时率从 0.1% 涨到了 5%
• 慢查询在哪 → 没有链路追踪，你不知道是 DB 慢还是外部 API 慢
• 服务挂了 → 没有告警，用户投诉了你才知道

可观测性的本质是：把"不知道发生了什么"变成"看得见、查得到、会报警"。

二、把服务交给可观测性配置专家

我调用了华为云码道的可观测性配置专家（observability-config）子智能体，给它一句话需求：

"给 /workspace/obs-demo/app.py 配置完整的可观测性：日志、指标、链路追踪、告警。"

它自己读完了源码，分析了所有端点和调用链，然后产出了 5 个文件：

下面每一项都是它真实配出来的，我验证过能跑。

三、第一件套：结构化日志

改造前：无任何日志配置。改造后：每条日志都是单行 JSON，直接被 ELK/Loki 采集解析。

实测一条请求日志长这样：

{
  "timestamp": "2026-11-03T02:06:13.975544+00:00",
  "level": "INFO",
  "logger": "flask-order-service",
  "service": "flask-order-service",
  "version": "1.0.0",
  "message": "request completed",
  "trace_id": "499282be86907b89c6dcc3334cb5d782",
  "span_id": "740bac9745a1d89a",
  "method": "GET",
  "path": "/health",
  "status": "200",
  "latency_ms": 0.39,
  "user_id": null,
  "remote_addr": "127.0.0.1"
}

三个关键设计：

1. 日志-链路关联：每条日志自动注入 trace_id / span_id，在 Jaeger 里看到一条慢链路，可以一键跳到对应日志，反之亦然。这是"可观测性"最核心的体验——三件套不是孤立的，是关联的。

2. 敏感数据脱敏：payment_id 在日志里自动脱敏（保留首尾 2 字符），不泄露支付凭证。

3. 错误日志带堆栈：teardown_request 捕获未处理异常，exception 字段含完整 traceback——不是 print 出来消失在终端，而是结构化记录到日志文件。

四、第二件套：Prometheus 指标

新增 /metrics 端点，暴露 5 个核心指标：

这套指标遵循 RED 原则（Rate、Error、Duration）+ 业务指标。一个细节值得注意：

path 标签用路由模板（/api/v1/orders/<int:order_id>），不用实际 URL。如果用实际 URL，/api/v1/orders/1、/api/v1/orders/2、/api/v1/orders/3……每个订单 ID 都会变成一个标签值——这就是高基数爆炸，会让 Prometheus 内存撑爆。用路由模板把基数固定在端点数量级，是生产级配置的基本功。

五、第三件套：OpenTelemetry 链路追踪

链路追踪是可观测性里信息量最大的一层——它告诉你"一个请求内部经过了哪些步骤、每步花了多久"。

可观测性配置专家配了三层埋点：

POST /api/v1/orders (FlaskInstrumentor 自动)
  └─ create_order span (手动业务 span)
       ├─ SELECT/INSERT orders (SQLite3Instrumentor 自动)
       └─ verify_payment span (手动业务 span)
            └─ POST payment-gateway/verify (RequestsInstrumentor 自动)

• 自动埋点：FlaskInstrumentor（HTTP 入口）、RequestsInstrumentor（外部 API）、SQLite3Instrumentor（DB 查询）——三件套自动 span，不用改业务代码
• 手动业务 span：create_order 和 verify_payment 额外包了业务 span，加了 order.user_id、order.amount、payment.valid 等业务属性——光有技术 span 不够，加上业务属性才能在 Jaeger 里按"金额 > 10000 的慢订单"筛选
• 异常标记：span 上 record_exception + set_status(ERROR)，Jaeger UI 里红色标记，一眼看到哪步出了错

OTLP exporter 优先 gRPC(4317)，自动回退 HTTP(4318)，导出到 Jaeger。采样率通过环境变量 OTEL_TRACES_SAMPLER_ARG 控制。

一个验证细节：我实测时 Jaeger 没启动，OTLP 连接被拒。但服务没有崩溃——可观测性配置专家做了防御性 import，prometheus/otel 缺失时优雅降级。这是生产级配置的另一个基本功：可观测性组件本身不能成为可用性风险。

六、第四件套：告警规则

5 条告警规则，覆盖了最常见的生产事故场景：

每条告警都附了 runbook_url（运维手册链接）和 category 标签——告警不只是"告诉你出事了"，还要"告诉你怎么处理"。

注意 OrderCreationDrop 这条——它不是技术指标告警，是业务指标告警。订单创建速率突然下降 50%，可能不是服务挂了（health check 正常），而是上游入口被封、或者某个活动页挂了。这种"业务异常"比"技术异常"更难发现，也更重要。

七、改造前后对比

最让我意外的是优雅降级的设计。可观测性组件（prometheus_client、opentelemetry）不是强依赖——import 失败时服务照常跑，只是少了指标和链路。这个设计很关键：可观测性是"锦上添花"，不能变成"雪上加霜"。

八、复盘：可观测性配置专家替我做了什么

回看整个过程，我作为"运维方"只做了一件事：把服务路径给它。它自己完成了：

裸奔的 Flask 服务
    │
    ├─ 分析端点和调用链 → 识别 5 个端点 + DB 调用 + 外部 API 调用
    ├─ 配结构化日志    → JSON 格式 + 请求/错误/业务全链路 + trace 关联 + 脱敏
    ├─ 配 Prometheus   → 5 个指标，RED 原则 + 业务 KPI，路由模板避免高基数
    ├─ 配 OpenTelemetry → 三层埋点 + 业务 span + OTLP 导出 + 优雅降级
    └─ 配告警规则      → 5 条，技术 + 业务，含 runbook

这和"让 AI 帮我写段 logging 配置"有本质区别：

最让我意外的是它对高基数爆炸的防护——把 path 标签设成路由模板而不是实际 URL。这个坑很多有经验的运维都会踩，它主动避了。

九、哪些地方它还没法替代人

1. 指标阈值定标：P99 > 2s 才告警？还是 > 500ms？这取决于业务的 SLA 承诺——工具能给默认值，但定标要人。
2. 采样率决策：链路采样率 100% 最全但开销大，1% 最省但可能漏关键 trace——这个权衡取决于流量和预算。
3. 告警收敛：5 条规则之间会不会告警风暴？一个 DB 挂了可能同时触发高错误率 + 高延迟 + 服务不可用——收敛策略需要人根据实际情况调。

十、结语

可观测性是运维的底座。没有可观测性，安全审计是盲的、性能优化是猜的、告警是缺的——前面九篇里很多实战，都依赖"看得见"才能"改得对"。

华为云码道的可观测性配置专家，让"给服务穿上四件套"这件事的成本低到——一句话需求 + 一个服务路径。而穿上了四件套的服务，才真正具备了"上线"的资格。

系列十篇，从"写代码"到"看代码运行"： 成长 → 观点 → 安全 → 性能 → 部署 → 数据 → 技术债 → 需求 → MCP → 可观测性。 前五篇是"把代码写好"，后五篇是"把代码管好"。下一份见。

本文所有配置均由华为云码道可观测性配置专家（observability-config）对 /workspace/obs-demo/app.py 真实执行。改造后代码 app_observable.py 已验证可运行，/metrics 端点正常暴露指标。