AI 应用可观测性:链路追踪、成本管控与告警体系

AI 应用可观测性:链路追踪、成本管控与告警体系

当 LLM 应用从原型走向生产环境,一个严峻的现实随之浮出水面:你无法优化你无法度量的东西。传统 Web 应用的可观测性体系(Metrics、Logs、Traces 三支柱)在面对 LLM 应用时出现了显著的能力缺口——Token 消耗带来的弹性成本、模型推理的非确定性延迟、输出质量的主观性评估,这些新维度要求我们在传统可观测性的基础上构建一套专属于 AI 应用的监控体系。

本文面向生产级 LLM 应用的开发者与 SRE,系统性地拆解 AI 应用可观测性的完整技术栈:从三支柱的 AI 适配,到 LangFuse/LangSmith 的实操集成,再到基于 Prometheus + Grafana 的自定义监控、成本管控与告警策略。


一、可观测性三支柱在 AI 场景的适配

传统可观测性的三大支柱——Metrics(指标)Logs(日志)Traces(链路)——构成了监控系统的骨架。但 LLM 应用的特殊性,要求对每一支柱进行针对性的扩展。

1.1 Metrics:从请求数到 Token 经济指标

传统应用的 Metrics 聚焦于 QPS、错误率、延迟百分位。AI 应用需要在此基础上叠加一层全新的指标维度:

传统指标AI 扩展指标说明
Request CountRequest Count + Token Volume请求数不再反映真实负载,Token 消耗量才是
Error RateHallucination Rate模型不会抛 500 错误,但会"一本正经地胡说八道"
Latency P99Time-to-First-Token (TTFT)流式输出场景下,用户感知的延迟是首 Token 延迟而非总延迟
ThroughputTokens per Second模型生成速度直接影响用户体验
CPU/MemoryGPU Utilization + KV Cache Hit Rate推理引擎的硬件指标替代了传统 CPU 密集型指标

这些指标的变化频率和量级与传统应用截然不同。一个高流量的聊天应用可能每秒产生数百万个 Token,而这些 Token 的成本是按量计费的——这意味着监控系统不仅要实时采集指标,还要具备实时成本计算能力。

1.2 Logs:结构化日志与语义审计

LLM 应用的日志远比传统应用复杂。一次完整的请求日志可能包含:

  • 输入层:System Prompt 版本、用户输入(含敏感信息脱敏)、上下文窗口内容
  • 推理层:模型选择、温度参数、Top-P、推理耗时、Token 分段统计
  • 输出层:模型回复全文、停止原因(stop_reason)、安全过滤触发记录
  • 工具层:Function Calling 的工具名、参数、返回值、重试次数
  • 评估层:在线评估分数、幻觉检测标记、安全审计结果

日志的结构化程度直接决定了后续分析的可行性。一个常见的错误是在日志中直接存储完整的用户输入和模型输出,这不仅违反数据合规要求(GDPR、《个人信息保护法》),还会在大规模场景下迅速耗尽存储资源。

1.3 Traces:LLM 调用的分布式链路

LLM 应用的链路追踪需要覆盖一个完整的调用生命周期。以一个典型的 RAG + Agent 应用为例,一次请求可能涉及以下调用链路:

用户请求
  └── Query Rewrite (LLM Call #1)
       └── Vector Search (Embedding Call + DB Query)
            └── Rerank (LLM Call #2 or Cross-Encoder)
                 └── Context Assembly
                      └── Main Generation (LLM Call #3, Stream)
                           └── Tool Calls (LLM Call #4, if needed)
                                └── Tool Execution (HTTP Call)
                                     └── Final Generation (LLM Call #5)
                                          └── Safety Check (LLM Call #6)
                                               └── Response

在这条链路中,每一个节点都可能独立失败或引入延迟。没有链路追踪,你无法知道一个"慢回答"究竟慢在了哪个环节——是 Embedding 检索慢了,Rerank 模型排队了,还是 LLM 的输出被安全过滤拦截后重新生成了?


二、LLM 特有指标

在传统可观测性指标之上,AI 应用需要一套专属的指标体系来捕捉 LLM 行为的独特模式。

2.1 Token 使用指标

Token 是 LLM 应用中最重要的计量单位,直接关联成本和性能:

  • Token Volume(Token 消耗量):按输入/输出/总 Token 分别统计,区分 Prompt Token 和 Completion Token。建议按模型、按业务线、按用户维度分别聚合。
  • Token Rate(Token 生成速率):衡量模型每秒输出的 Token 数。GPT-4o 通常在 40-80 tokens/s,Claude 3.5 Sonnet 约 60-100 tokens/s。速率下降可能暗示 API 限流或服务降级。
  • Token Utilization(Token 利用率):有效输出 Token(用户实际需要的回答内容)占总 Token(含推理链、系统提示、上下文注入)的比例。低 Token 利用率意味着存在优化空间。

2.2 延迟分布指标

LLM 应用的延迟分布通常呈双峰形态——简单查询快速返回,复杂推理显著耗时:

指标含义健康基线(参考)
TTFT (Time to First Token)从请求发出到首个 Token 返回的延迟< 800ms(P95)
TPOT (Time Per Output Token)平均每个输出 Token 的生成间隔< 50ms
Total Latency从请求到完整响应返回的总耗时< 10s(P95,依场景而定)
E2E Latency with Tools含工具调用的端到端延迟< 30s(P95)

TTFT 是用户感知体验的关键分界线——超过 1 秒无响应,用户就会感到焦虑;超过 3 秒,流失率急剧上升。监控 TTFT 的 P50 和 P95 差异,能快速发现长尾延迟问题。

2.3 质量与安全指标

LLM 输出的非确定性使得质量监控成为必要但极具挑战的工作:

  • Hallucination Rate(幻觉率):通过 LLM-as-Judge 或事实核查工具,在线评估模型回答中包含虚构信息的比例。通常通过抽样评估来估算,全量评估成本过高。
  • **Safety Event Rate(安全事件率):**触发内容安全过滤的请求占比。包括 Prompt 注入检测、有害内容拦截、敏感信息泄露等维度。
  • Model Fallback Rate(模型降级率):因主模型不可用或超时而切换到备用模型的请求比例。高降级率可能暗示上游模型服务不稳定。
  • Cache Hit Rate(缓存命中率):语义缓存(Semantic Cache)命中的请求比例。对于重复性高的场景(如客服问答),缓存命中率可以达到 30%-60%,直接降低 50% 以上的 Token 成本。

2.4 指标采集的时间窗口

LLM 应用的指标具有明显的时间特性:

  • 实时窗口(1-5 分钟):用于即时告警,关注 TTFT、错误率、Token 速率的突变
  • 短期窗口(1-24 小时):用于趋势分析,关注每日 Token 消耗曲线、高峰时段识别
  • 长期窗口(7-90 天):用于成本预测和容量规划,关注月度 Token 消耗趋势、模型切换影响

三、LangFuse/LangSmith 实操

LangFuse 和 LangSmith 是当前 LLM 可观测性领域的两大主流平台。LangFuse 开源且自托管友好,LangSmith 是 LangChain 官方的商业 SaaS 平台。

3.1 LangFuse 安装与部署

LangFuse 提供 Docker Compose 一键部署方案,适合中小团队快速上手:

# docker-compose.yml
version: "3.9"
services:
  langfuse-db:
    image: postgres:16-alpine
    environment:
      POSTGRES_USER: langfuse
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_DB: langfuse
    volumes:
      - langfuse_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U langfuse"]
      interval: 5s
      timeout: 5s
      retries: 5

  langfuse-server:
    image: langfuse/langfuse:latest
    ports:
      - "3000:3000"
    environment:
      DATABASE_URL: postgresql://langfuse:${DB_PASSWORD}@langfuse-db:5432/langfuse
      NEXTAUTH_SECRET: ${NEXTAUTH_SECRET}
      NEXTAUTH_URL: http://localhost:3000
      SALT: ${SALT}
    depends_on:
      langfuse-db:
        condition: service_healthy

volumes:
  langfuse_data:

部署完成后,通过 Web UI 创建项目并获取 API Key:

# 获取 LangFuse API Key 后,配置环境变量
export LANGFUSE_SECRET_KEY="sk-lf-..."
export LANGFUSE_PUBLIC_KEY="pk-lf-..."
export LANGFUSE_HOST="http://localhost:3000"

3.2 SDK 集成与 Trace 上报

LangFuse 提供了与主流框架的无缝集成。以下分别展示 LangChain 和原生 OpenAI SDK 的接入方式:

LangChain 集成

from langfuse.callback import CallbackHandler
from langchain_openai import ChatOpenAI
from langchain_core.messages import HumanMessage

langfuse_handler = CallbackHandler(
    public_key="pk-lf-...",
    secret_key="sk-lf-...",
    host="http://localhost:3000"
)

llm = ChatOpenAI(model="gpt-4o", temperature=0)
response = llm.invoke(
    [HumanMessage(content="解释 Transformer 中的注意力机制")],
    config={"callbacks": [langfuse_handler]}
)

原生 OpenAI SDK 集成

from langfuse import Langfuse
from langfuse.decorators import observe

langfuse = Langfuse(
    public_key="pk-lf-...",
    secret_key="sk-lf-...",
    host="http://localhost:3000"
)

@observe(as_type="generation")
def call_llm(prompt: str) -> str:
    from openai import OpenAI
    client = OpenAI()
    response = client.chat.completions.create(
        model="gpt-4o",
        messages=[{"role": "user", "content": prompt}],
        temperature=0
    )
    return response.choices[0].message.content

@observe()
def rag_pipeline(query: str) -> str:
    docs = retrieve_documents(query)
    context = "\n".join([d.page_content for d in docs])
    prompt = f"基于以下上下文回答问题:\n{context}\n\n问题:{query}"
    return call_llm(prompt)

result = rag_pipeline("什么是 RAG?")
langfuse.flush()

3.3 数据集与在线评估

LangFuse 支持创建评估数据集(Dataset),用于系统性地评估模型输出质量:

from langfuse import Langfuse

langfuse = Langfuse()

dataset = langfuse.create_dataset(name="rag-qa-evaluation-v2")

experiment_items = [
    {
        "input": {"query": "什么是 MCP 协议?", "context_docs": ["mcp_spec_v1.md"]},
        "expected_output": "MCP 是 Model Context Protocol 的缩写...",
        "metadata": {"difficulty": "easy", "category": "definition"}
    },
    {
        "input": {"query": "比较 LangChain 和 LlamaIndex 的差异", "context_docs": ["comparison.md"]},
        "expected_output": "LangChain 侧重于 Agent 编排...",
        "metadata": {"difficulty": "medium", "category": "comparison"}
    }
]

for item in experiment_items:
    langfuse.create_dataset_item(
        dataset_name="rag-qa-evaluation-v2",
        input=item["input"],
        expected_output=item["expected_output"],
        metadata=item["metadata"]
    )

在线评估可以通过 LangFuse 的 Evaluation API 实现,将每条 Trace 关联到数据集中的对应样本,从而持续追踪模型质量的变化趋势。


四、自定义 Metrics:Prometheus + Grafana

对于需要深度定制监控面板的团队,Prometheus + Grafana 是构建 AI 指标体系的经典组合。

4.1 自定义 AI 指标 Exporter

通过 Prometheus client 在应用层暴露自定义指标:

from prometheus_client import Counter, Histogram, Gauge, start_http_server

LLM_TOKEN_USAGE = Counter(
    "llm_token_usage_total",
    "Total token consumption",
    ["model", "token_type", "team", "project"]
)

LLM_REQUEST_DURATION = Histogram(
    "llm_request_duration_seconds",
    "LLM request latency",
    ["model", "endpoint"],
    buckets=[0.5, 1.0, 2.0, 5.0, 10.0, 20.0, 30.0, 60.0]
)

TTFT_LATENCY = Histogram(
    "llm_ttft_seconds",
    "Time to first token",
    ["model"],
    buckets=[0.1, 0.3, 0.5, 0.8, 1.0, 1.5, 2.0, 3.0]
)

LLM_ERROR_TOTAL = Counter(
    "llm_errors_total",
    "LLM errors by type",
    ["model", "error_type"]
)

HALLUCINATION_RATE = Gauge(
    "llm_hallucination_rate",
    "Hallucination rate (rolling 1h)",
    ["model", "task_type"]
)

CACHE_HIT_RATIO = Gauge(
    "llm_cache_hit_ratio",
    "Semantic cache hit ratio",
    ["model"]
)

COST_DOLLARS = Counter(
    "llm_cost_dollars_total",
    "Estimated cost in USD",
    ["model", "team"]
)

start_http_server(8000)

4.2 Grafana Dashboard 配置

以下是核心面板的 Grafana 查询示例(PromQL):

# Panel: Token 消耗速率(按模型分组)
- expr: rate(llm_token_usage_total[5m])
  legend: "{{model}} - {{token_type}}"
  title: "Token 消耗速率"

# Panel: P95 延迟趋势
- expr: histogram_quantile(0.95, rate(llm_request_duration_seconds_bucket[5m]))
  legend: "{{model}}"
  title: "P95 延迟"

# Panel: TTFT P95
- expr: histogram_quantile(0.95, rate(llm_ttft_seconds_bucket[5m]))
  legend: "{{model}}"
  title: "Time to First Token P95"

# Panel: 幻觉率(1 小时滚动窗口)
- expr: llm_hallucination_rate
  legend: "{{model}} - {{task_type}}"
  title: "幻觉率"

# Panel: 缓存命中率
- expr: llm_cache_hit_ratio
  legend: "{{model}}"
  title: "语义缓存命中率"

# Panel: 每日成本趋势
- expr: increase(llm_cost_dollars_total[24h])
  legend: "{{model}} - {{team}}"
  title: "每日成本 (USD)"

4.3 Prometheus 告警规则配置

# prometheus_ai_rules.yml
groups:
  - name: ai_application_alerts
    rules:
      - alert: HighTTFT
        expr: histogram_quantile(0.95, rate(llm_ttft_seconds_bucket[5m])) > 1.5
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "TTFT P95 超过 1.5 秒"
          description: "模型 {{ $labels.model }} 的 TTFT P95 持续超过 1.5 秒,可能影响用户体验。"

      - alert: TokenBudgetExceeded
        expr: increase(llm_cost_dollars_total[1h]) > 50
        for: 0m
        labels:
          severity: critical
        annotations:
          summary: "1 小时 Token 成本超过 $50"
          description: "团队 {{ $labels.team }} 在过去 1 小时内 Token 消耗成本达到 ${{ $value }}。"

      - alert: HighHallucinationRate
        expr: llm_hallucination_rate > 0.15
        for: 30m
        labels:
          severity: critical
        annotations:
          summary: "幻觉率超过 15%"
          description: "模型 {{ $labels.model }} 的幻觉率达到 {{ $value | humanizePercentage }},超过安全阈值。"

      - alert: LLMHighErrorRate
        expr: rate(llm_errors_total[5m]) > 0.1
        for: 3m
        labels:
          severity: warning
        annotations:
          summary: "LLM 错误率偏高"
          description: "模型 {{ $labels.model }} 的错误率 {{ $value | humanizePercentage }}。"

      - alert: CacheHitRateDropped
        expr: llm_cache_hit_ratio < 0.2
        for: 1h
        labels:
          severity: info
        annotations:
          summary: "缓存命中率低于 20%"
          description: "语义缓存命中率降至 {{ $value | humanizePercentage }},请检查缓存策略。"

五、成本管控

LLM API 的按量计费模式意味着成本是流动的、弹性的、可失控的。一个设计不当的 Agent 循环可能在几分钟内烧掉数百美元。成本管控不是可选项,而是生产级 AI 应用的生存前提。

5.1 Token 预算管理

Token 预算管理的核心是建立多层级的限额体系:

class TokenBudgetManager:
    def __init__(self, config: dict):
        self.limits = {
            "per_request": config.get("per_request", 8000),
            "per_user_daily": config.get("per_user_daily", 50000),
            "per_team_daily": config.get("per_team_daily", 1000000),
            "global_hourly": config.get("global_hourly", 5000000),
        }
        self.usage_tracker = UsageTracker()

    def check_budget(self, scope: str, entity_id: str, estimated_tokens: int) -> bool:
        limit = self.limits.get(scope, float("inf"))
        current_usage = self.usage_tracker.get_usage(scope, entity_id)
        if current_usage + estimated_tokens > limit:
            return False
        return True

    def record_usage(self, scope: str, entity_id: str, input_tokens: int,
                     output_tokens: int, model: str):
        total = input_tokens + output_tokens
        self.usage_tracker.record(scope, entity_id, total)
        cost = self._calculate_cost(model, input_tokens, output_tokens)
        self.usage_tracker.record_cost(scope, entity_id, cost)

    def _calculate_cost(self, model: str, input_tokens: int, output_tokens: int) -> float:
        pricing = {
            "gpt-4o": {"input": 2.50, "output": 10.00},
            "gpt-4o-mini": {"input": 0.15, "output": 0.60},
            "claude-3-5-sonnet": {"input": 3.00, "output": 15.00},
            "deepseek-v3": {"input": 0.27, "output": 1.10},
        }
        rates = pricing.get(model, {"input": 1.0, "output": 3.0})
        return (input_tokens * rates["input"] + output_tokens * rates["output"]) / 1_000_000

5.2 异常告警与熔断

除了被动的预算限制,还需要主动检测异常消耗模式:

  • 单请求 Token 爆发告警:当单次请求的输出 Token 超过阈值(如 4000),自动触发审查。这通常意味着 Agent 进入了异常循环或模型生成了大量冗余内容。
  • 短时消耗激增告警:1 分钟内的 Token 消耗量超过历史同期均值的 3 倍,触发预警。可能是遭受了 Prompt 注入攻击导致的 Token 耗尽。
  • 成本趋势异常告警:每日成本超过预算的 120%,触发团队负责人通知。
  • 自动熔断机制:当检测到异常模式时,自动降级到更低成本的模型(如从 GPT-4o 降级到 GPT-4o-mini),或限制请求频率。

5.3 使用分析与成本归因

精确的成本归因是优化的前提。建议按以下维度建立成本分析视图:

归因维度分析价值
按团队/项目识别成本大户,推动资源优化
按模型评估模型替换的 ROI,决定何时用小模型替代大模型
按功能模块区分 RAG 检索、Agent 推理、安全审查等模块的独立成本
按用户类型识别免费用户与付费用户的成本差异
按时间段发现成本的周期性模式,优化调度策略

通过 Grafana 的多维度面板,可以快速定位成本的驱动因素。例如,一个看似合理的"日均成本上升 30%",深入分析后可能发现:70% 的增量来自某个新上线的 Agent 功能中的工具调用循环,而非整体流量增长。


六、日志聚合与分析

6.1 技术栈选择

对于 AI 应用的日志聚合,两种主流方案各有优势:

方案优势劣势适用场景
ELK Stack (Elasticsearch + Logstash + Kibana)全文搜索能力强,查询灵活资源消耗大,运维复杂大规模日志分析,需要复杂查询
Grafana Loki轻量级,标签索引,与 Grafana 生态集成全文搜索能力弱于 ES已使用 Grafana 的团队,成本敏感

对于已经采用 Prometheus + Grafana 监控体系的团队,Loki 是自然的选择——它复用了 Prometheus 的标签体系,可以在 Grafana 中统一查看 Metrics 和 Logs。

6.2 结构化日志模式

AI 应用的日志必须遵循严格的结构化格式,以下是推荐的日志 Schema:

import json
import time
from dataclasses import dataclass, asdict
from typing import Optional

@dataclass
class AILogEntry:
    timestamp: float
    trace_id: str
    span_id: str
    parent_span_id: Optional[str]
    level: str
    event_type: str
    model: str
    input_tokens: int
    output_tokens: int
    total_tokens: int
    latency_ms: float
    ttft_ms: Optional[float]
    stop_reason: str
    team: str
    project: str
    user_id: str
    error: Optional[str] = None
    cache_hit: bool = False
    safety_triggered: bool = False
    metadata: Optional[dict] = None

def log_llm_call(entry: AILogEntry):
    safe_entry = asdict(entry)
    safe_entry["input_tokens"] = entry.input_tokens
    safe_entry["cost_usd"] = calculate_cost(
        entry.model, entry.input_tokens, entry.output_tokens
    )
    print(json.dumps(safe_entry, ensure_ascii=False))

关键设计原则:

  • 永远不要在日志中存储原始用户输入:使用哈希或摘要替代,敏感信息必须脱敏
  • 每条日志必须携带 trace_id:确保日志与链路追踪可以关联
  • 使用统一的命名规范:如 input_tokens 而非混用 prompt_tokensinput_token_count
  • 分级存储策略:热数据(7 天)保留在 Loki/ES,温数据(30 天)迁移到对象存储,冷数据(90 天+)归档或删除

6.3 Loki 日志查询示例

# 查询特定模型的错误日志
{app="ai-gateway"} |= "error" | json | model="gpt-4o" | level="error"

# 查询 Token 消耗异常高的请求
{app="ai-gateway"} | json | total_tokens > 10000

# 查询幻觉检测触发的日志
{app="ai-gateway"} | json | hallucination_detected=true

# 按团队统计 1 小时内的 Token 消耗
sum by (team) (
  sum_over_time({app="ai-gateway"} | json | unwrap total_tokens [1h])
)

七、告警策略

告警体系的设计直接影响团队对问题的响应速度和处理质量。一个设计不当的告警系统要么频繁误报导致告警疲劳,要么遗漏关键事件导致故障扩大。

7.1 SLA 定义

在制定告警策略之前,首先需要定义清晰的 SLA:

SLA 指标目标值说明
可用性99.9%指 LLM 服务(含降级路径)可用时间占比
TTFT P95< 1.5s从请求到首 Token 返回
总延迟 P95< 10s标准对话场景
幻觉率< 5%抽样评估的滚动 24 小时均值
安全事件响应< 1min从检测到安全事件到触发拦截的延迟
成本偏差< ±20%实际成本与预算的偏差范围

7.2 分级告警体系

告警分为三个级别,每个级别对应不同的响应机制:

Info 级别(信息通知):

  • 缓存命中率低于预期
  • 新版本模型上线后指标波动
  • 日成本达到预算的 80%
  • 模型降级率轻微上升

响应方式:Slack/飞书 通知,无需即时处理,工作时间内确认即可。

Warning 级别(需要关注):

  • TTFT P95 超过 1.5 秒持续 5 分钟
  • 某团队 Token 消耗异常偏高
  • 幻觉率上升至 10%-15% 区间
  • 模型 API 错误率超过 5%

响应方式:Slack/飞书 + 邮件通知,值班人员需在 30 分钟内响应,评估是否需要干预。

Critical 级别(立即处理):

  • LLM 服务完全不可用
  • TTFT P95 超过 5 秒
  • 幻觉率超过 15%
  • 单小时成本突破预算上限
  • 检测到 Prompt 注入攻击

响应方式:电话/短信通知 + 自动升级。15 分钟内无响应自动升级至团队负责人,30 分钟内无响应升级至技术总监。

7.3 升级机制

# escalation-policy.yml
escalation_policies:
  - name: "AI 应用告警升级"
    steps:
      - delay: 0m
        notify:
          - type: slack
            channel: "#ai-alerts"
      - delay: 15m
        notify:
          - type: pagerduty
            service: "ai-production"
      - delay: 30m
        notify:
          - type: phone
            targets:
              - "team-lead"
      - delay: 60m
        notify:
          - type: phone
            targets:
              - "engineering-director"
            repeat: 15m

7.4 告警治理

避免告警疲劳的关键措施:

  • 告警抑制:当一个根因触发多个告警时,自动抑制衍生告警。例如,LLM API 全面不可用时,不需要对每个模型单独发告警。
  • 告警收敛:将 5 分钟窗口内的重复告警合并为一条,附带触发次数。
  • 告警静默:在已知维护窗口(如模型升级、数据迁移)期间自动静默相关告警。
  • 定期回顾:每月回顾告警的有效性,清理误报率高的规则,优化阈值。

八、架构图

以下是 AI 应用可观测性的完整架构图:

┌──────────────────────────────────────────────────────────────────┐
│                     用户请求层 (User Requests)                     │
│          Web / Mobile / API / CLI / Embedded Widget               │
└──────────────────────────┬───────────────────────────────────────┘
                           │
┌──────────────────────────▼───────────────────────────────────────┐
│                    API Gateway / Load Balancer                     │
│              请求路由 · 限流 · 鉴权 · Token 预算检查                  │
└──────────────────────────┬───────────────────────────────────────┘
                           │
┌──────────────────────────▼───────────────────────────────────────┐
│                   AI 应用服务层 (App Server)                       │
│                                                                   │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐        │
│  │   RAG    │  │  Agent   │  │  Safety  │  │  Budget  │        │
│  │ Pipeline │  │ Executor │  │  Filter  │  │ Manager  │        │
│  └────┬─────┘  └────┬─────┘  └────┬─────┘  └────┬─────┘        │
│       │              │              │              │               │
│  ┌────▼──────────────▼──────────────▼──────────────▼────┐        │
│  │            Observability SDK (LangFuse/OpenTelemetry) │        │
│  │       Trace Collection · Metric Emission · Log Emit   │        │
│  └──────┬────────────────┬────────────────┬──────────────┘        │
└─────────┼────────────────┼────────────────┼──────────────────────┘
          │                │                │
    ┌─────▼─────┐   ┌─────▼─────┐   ┌─────▼─────┐
    │  LangFuse │   │ Prometheus│   │   Loki    │
    │  (Traces  │   │ + Grafana │   │  (Logs)   │
    │  & Eval)  │   │ (Metrics) │   │           │
    └─────┬─────┘   └─────┬─────┘   └─────┬─────┘
          │                │                │
          │         ┌──────▼──────┐         │
          │         │ Alert Rules │         │
          │         │ (Prometheus │         │
          │         │   Alerting) │         │
          │         └──────┬──────┘         │
          │                │                │
    ┌─────▼────────────────▼────────────────▼─────┐
    │              告警通知分发                       │
    │   Slack · 飞书 · PagerDuty · 邮件 · 短信       │
    └─────────────────────────────────────────────┘
                           │
          ┌────────────────┼────────────────┐
          │                │                │
    ┌─────▼─────┐   ┌─────▼─────┐   ┌─────▼─────┐
    │ GPT-4o    │   │ Claude    │   │ DeepSeek  │
    │ (Primary) │   │ (Fallback)│   │ (Budget)  │
    └───────────┘   └───────────┘   └───────────┘

架构设计的核心原则:

  • 旁路采集:可观测性 SDK 以非阻塞方式采集数据,绝不影响主请求链路的延迟
  • 多维度冗余:Traces、Metrics、Logs 三路数据互相校验,任何一路数据丢失不影响全局可观测性
  • 分层存储:热数据存 Loki/Prometheus 本地,温数据存 LangFuse,冷数据归档至对象存储
  • 告警统一出口:所有告警通过统一的分发层路由到对应的接收渠道,避免各监控系统各自为战

九、延伸阅读