/images/avatar.png

LLM 可观测性:监控 Prompt 和 Response 的实战方法

Langfuse 要接的场面:LLM 服务上线后,用户开始抱怨输出质量下降。打开监控面板——CPU 正常,内存正常,P99 延迟在 SLA 范围内。服务从基础设施角度看完全健康,但根本不知道模型在返回什么。这就是 LLM 可观测性的缺口:传统 APM 工具能告诉系统好不好,但告诉不了 AI 好不好。

PostgreSQL 性能优化

慢查询通常先暴露在计划上,而不是在 postgresql.conf 里。按 PostgreSQL 的路径:先跑 EXPLAIN (ANALYZE, BUFFERS),看清 Seq Scan 还是 Index Scan,再决定索引、写法和配置。

缺索引、函数包住列、统计信息过期、autovacuum 跟不上、代价参数按机械盘默认——都会让同一条 SQL 走全表。先读计划,再动旋钮。

Prometheus + Grafana 监控实战:让 LLM 服务可见

LLM 服务挂了而没人知道,多半是只盯着 CPU。Prometheus + Grafana 能看见请求,但默认的 node 面板看不见 token、TTFT,也看不见 model 标签把时序基数打爆。

下面按抓取 → 查询 → 规则 → 面板写。正文里的 llm_* 名字是示例指标名,不是 Prometheus 或某个网关的标准导出。接入前对照实际 /metrics