Dify 企业级实验（06）：可观测性体系——日志埋点与监控告警如何落地？

1. 业务场景

先讲一个我们实际遇到的场景。

客服系统线上跑着 3 个应用，偶发「回答慢、答非所问、调用失败」。半夜用户投诉，运维爬起来翻日志——日志散在三个应用里，格式还不一样，一翻两小时。

我们第一次接这类需求时，第一反应也是「出问题再翻日志呗」。真正动手才发现——翻日志是排障的下下策：日志散落、格式不一、没有贯穿 ID，定位一个请求要两个小时。可观测性不是锦上添花，是事故时的生命线，得在设计时就把观测点埋好。

生产系统跑挂了，最贵的是「定位时间」：是哪个应用、哪个节点、哪个环节出的问题。

这不是个例。任何「多应用线上运行、靠人工翻日志排障」的团队都是这个模式：应用越多，翻日志的代价越大。

2. 场景痛点

这个流程的痛点，在半夜爬起来翻日志的运维身上体现得最直接：

• 排障按小时计：问题定位靠人肉翻日志，用户已经投诉了，运维还在找是哪个应用——定位时间就是损失。
• 日志格式不统一：三个应用三种格式，对不上号，同一个请求在三个应用里的记录串不起来。
• 没有 request_id 贯穿：一个请求经过了哪些节点、每个节点花了多久，无据可查。
• 异常无告警：失败率悄悄涨，没人知道，直到用户先发现——被动挨打。

本质上，出问题不可怕，可怕的是「不知道哪里出了问题」。

3. 方案：为什么是设计时埋点

Dify 的 code + http 节点足以搭出一套轻量可观测体系，本实验把「埋点、监控、排障」拆成三个应用。选它的理由：

• 设计时埋点：每个请求写一条结构化日志，不是「出问题再查」，而是「设计时就把观测点埋好」；
• request_id 贯穿：全链路 Trace 一键定位到具体节点；
• 监控自动告警：失败率/P95 超阈值自动推送到 Webhook，不用等人发现。

这篇文章我们就用它搭一套「客服系统可观测体系」：埋点应用 + 监控应用 + 排障应用。

4. 整体架构

链路很清晰：业务应用旁路埋点 → 监控应用定时聚合告警 → 排障应用按 request_id 拉全链路 Trace。埋点旁路（日志失败不影响业务）是这套体系的关键设计。

5. 模块设计

5.1 请求 ID 贯穿

请求 ID 贯穿：客服应用开始节点后接「生成请求ID」code 节点，调用方没传就自动生成：rid = request_id or ("REQ-" + str(int(time.time() * 1000))[-10:])，后续每条日志都带上。

5.2 日志埋点（旁路记录）

日志埋点（旁路记录）：关键节点后接「组装日志埋点」code 节点，组装 KV 条目后 POST 到统一日志：

def main(request_id: str, query: str, answer: str) -> dict:

    import json, time

    entry = {"request_id": request_id or "", "app": "客服应用", "node": "lm_answer",

             "summary": str(answer or "")[:100], "status": "ok", "elapsed_ms": 800,

             "time": time.strftime("%Y-%m-%d %H:%M:%S")}

    return {"payload": json.dumps({"op": "append", "item": entry}, ensure_ascii=False)}

http 节点指向 http://172.19.0.50:8123/state/dify104_06_logs（KV 模拟服务，生产换 Redis/DB）。订单应用同理，其中一条把 status 置为 warn 模拟异常。

5.3 监控应用：聚合与阈值检测

监控应用聚合 code（定时触发 workflow，周一 09:00）：

total = len(logs)

failed = sum(1 for e in logs if isinstance(e, dict) and e.get("status") != "ok")

fail_rate = failed * 100.0 / total if total else 0.0

latencies = [int(e.get("elapsed_ms", 0)) for e in logs if isinstance(e, dict)]

p95 = sorted(latencies)[int(len(latencies) * 0.95) - 1] if latencies else 0

阈值检测 code（告警分级逻辑就在这里）：

rate = float(fail_rate or 0)

p = float(p95 or 0)

alerts = []

if rate > 5:

    alerts.append("失败率超阈值（>5%）")

if p > 20000:

    alerts.append("P95 耗时超阈值（>20s）")

level = "P1" if rate > 50 else ("P2" if alerts else "ok")

if-else 按 alert_level != "ok" 分流：告警分支组装载荷推送到 Webhook（本机用 KV /echo 模拟企业微信机器人端点），健康分支直接输出健康报告。

5.4 排障应用：全链路 Trace

排障应用 Trace code：从统一日志里按 request_id 过滤出该请求的全部节点记录，按时间排序拼成「节点 1 → 节点 2 → 节点 3（耗时/状态）」的诊断报告。

6. 运行验证

环境：Dify 1.16.1（Docker Compose），模型 DeepSeek deepseek-v4-flash。4 个 DSL 均导入发布通过，Service API 验证。

7. 实战坑

8. 实验文档及源码获取

• 实验文档：DIFY-104-06：可观测性体系——日志埋点与监控告警.md
• 源码一（客服应用）：dify104_06_01_客服应用.yml
• 源码二（订单应用）：dify104_06_02_订单应用.yml
• 源码三（监控应用）：dify104_06_03_监控应用.yml
• 源码四（排障应用）：dify104_06_04_排障应用.yml
• 源码目录：dify-104/dsl

文章聚焦核心配置与采坑点，完整分步操作与故障注入步骤见实验文档原文。