LLM 可观测性:监控 Prompt 和 Response 的实战方法
Langfuse 要接的场面:LLM 服务上线后,用户开始抱怨输出质量下降。打开监控面板——CPU 正常,内存正常,P99 延迟在 SLA 范围内。服务从基础设施角度看完全健康,但根本不知道模型在返回什么。这就是 LLM 可观测性的缺口:传统 APM 工具能告诉系统好不好,但告诉不了 AI 好不好。
Langfuse 要接的场面:LLM 服务上线后,用户开始抱怨输出质量下降。打开监控面板——CPU 正常,内存正常,P99 延迟在 SLA 范围内。服务从基础设施角度看完全健康,但根本不知道模型在返回什么。这就是 LLM 可观测性的缺口:传统 APM 工具能告诉系统好不好,但告诉不了 AI 好不好。
跨 Host 复用工具时再上 MCP。GitHub 和 filesystem 最值;高频调用和需要事务的路径不要走 Server。权限用最小 token,版本钉死,给每个 Server 设 timeout。
慢查询通常先暴露在计划上,而不是在 postgresql.conf 里。按 PostgreSQL 的路径:先跑 EXPLAIN (ANALYZE, BUFFERS),看清 Seq Scan 还是 Index Scan,再决定索引、写法和配置。
缺索引、函数包住列、统计信息过期、autovacuum 跟不上、代价参数按机械盘默认——都会让同一条 SQL 走全表。先读计划,再动旋钮。
Go 1.23 发布于 2024 年 8 月,带来了 range-over-func 这个期待已久的特性。六个月后回头看,哪些特性真正改变了日常开发?这篇文章是一次实际使用后的回顾,而不是发布时的功能清单。
LLM 服务挂了而没人知道,多半是只盯着 CPU。Prometheus + Grafana 能看见请求,但默认的 node 面板看不见 token、TTFT,也看不见 model 标签把时序基数打爆。
下面按抓取 → 查询 → 规则 → 面板写。正文里的 llm_* 名字是示例指标名,不是 Prometheus 或某个网关的标准导出。接入前对照实际 /metrics。