尧图网站建设 
把可观测性数据送进 LLM 追踪平台本文基于实际部署经验整理实验环境为 Windows WSL2 Docker。核心目标让 OpenTelemetry Demo 采集 Github Copilot 的 traces在不改动任何业务代码的前提下额外转发一份到自托管的 Langfuse实现 LLM 调用的全链路追踪。背景OpenTelemetryOTel是目前最主流的可观测性标准覆盖 traces、metrics、logs 三类信号。很多团队已经用 OTel Demo 跑通了从应用到 Prometheus Grafana 的链路。这次的具体需求我想看看 GitHub Copilot 具体的行为模式它在代码补全、对话、Edits 等场景下分别发起了哪些 LLM 调用、调用了什么模型、耗时多少、token 用量如何。OTel Demo 已经在采集这些gen_ai.*语义约定的 traces但 Prometheus Grafana 只能看聚合指标看不到单次调用的输入输出细节也做不了多次调用的关联分析。我们需要的是一个能把每一次 LLM 调用都当成一个可检索、可回放的事件来存储和分析的平台。Langfuse 是专为 LLM 应用设计的可观测平台支持标准 OTLP 协议接入这意味着只需改一行 OTel Collector 配置就能把现有 traces 同时打到 Langfuse零业务代码改动。采集 LLM 交互信息的意义采集并保存每一次 LLM 调用的输入/输出、模型、耗时、token 用量、调用上下文等信息对团队和产品有多方面的价值可观测性与故障定位将单次调用做为可检索事件可以精确重现异常请求、定位模型返回错误或延迟的根因如模型、网络、超参或输入质量问题。成本与计费归因通过记录每次调用的 token 与耗时能按功能、用户、产品线精确核算成本支持异常扣费警报与成本优化决策。性能优化与容量规划按模型/接口统计延迟与吞吐趋势识别瓶颈带宽、显存、模型选择指导量化、缓存或分层路由等优化策略。模型行为分析与质量监控可进行误答率、鲁棒性、偏差检测与回归测试帮助评估不同模型/版本在真实流量下的表现。产品与 UX 迭代分析用户输入与模型输出的模式发现常见失败场景或交互阻力驱动提示词设计、候选排序或对话策略优化。A/B 实验与模型选择将调用视为事件可用于分组实验模型 A/B/n量化改动对业务指标与体验的影响。审计、合规与可回放对敏感或合规场景保留可回放记录支持审计、事后追踪与法律合规需配合访问控制与保留策略。训练数据与持续学习筛选高价值的真实交互作为微调或强化学习的候选样本帮助持续改进模型质量。注意事项采集 LLM 交互数据同时伴随隐私与合规风险实践中应至少做到最小化与脱敏仅收集必要字段对可能包含 PII 的文本做脱敏或加密对高风险请求建立明确白名单/黑名单策略。访问与保留策略制定细粒度访问控制、审计日志与数据留存期限避免长期存储不必要的敏感数据。合规与告知在需要的法律/监管场景如金融、医疗明确用户告知与同意并与合规团队对接审查数据处理流程。将这些实践与 Langfuse 的事件化 trace 能力结合既能实现工程与业务层面的度量与改进也能把可回放、审计与实验能力带入 LLM 产品化的常规流程。整体架构这里仅以我的验证环境为例实际部署时需细致规划。关键点两套 Docker 栈运行在不同的 WSL 实例中通过 WSL 的内部网络互通OTel Collector 以 HTTP 协议将 traces 推送给 Langfuse 的 OTLP 入口。部署概况部署细节略不是本文重点仅简略说明。OTel Demo官方 Docker Compose 一键启动包含 20 微服务 otel-collector prometheus jaeger grafanaLangfuse官方 Docker Compose 一键启动包含 web、worker、postgres、clickhouse、redis、minio两套栈分别在不同 WSL 实例内运行天然网络隔离。排坑记录实际操作中遇到了几个典型问题记录在此供参考。问题一多 WSL 实例共享 Linux 内核导致 Docker 网络子网冲突两个 WSL 实例Ubuntu-24.04 和 langfuse使用同一个 Linux 内核Docker 默认都会尝试使用172.18.0.0/16产生路由冲突导致容器间 DNS 解析正确但 TCP 不通。解法给 Langfuse 的 Docker Compose 指定独立子网# docker-compose.override.yml放在 langfuse 目录networks:default:driver:bridgeipam:config:-subnet:172.25.0.0/16gateway:172.25.0.1问题二iptables-legacy FORWARD 链默认 DROPWSL 重启后iptables-legacy的 FORWARD chain policy 变成 DROP导致同一 Docker 网络内的容器之间无法通信ping 通但 TCP 不通。表现容器日志报Cant reach database server但docker network inspect显示 IP 分配完全正确。解法持久化修复规则# /etc/rc.local#!/bin/bashiptables-legacy-PFORWARD ACCEPT问题三WSL 内的 curl 走了系统代理返回 503Langfuse 实际已正常启动日志显示✓ Ready in 86.1s但 curl 验证一直返回 503因为环境变量中设置了 HTTP 代理curl 把本地请求也转发给了代理服务器。解法验证时加--noproxy *参数。核心配置OTel Collector → Langfuse这是本文的核心只需修改一个文件otelcol-config-extras.yml。OTel Demo 的 Collector 支持通过 extras 文件叠加配置不用动主配置文件。第一步生成 Langfuse API Key登录 Langfuse 控制台创建项目后在Settings → API Keys中获取Public Keypk-lf-xxxxxxxxSecret Keysk-lf-xxxxxxxx将两者拼接后做 Base64 编码作为 Basic Auth 凭证echo-npk-lf-xxxxxxxx:sk-lf-xxxxxxxx|base64# 输出类似cGstbGYteHh4eHh4eHg6c2stbGYteHh4eHh4eHg第二步编写 extras 配置编辑src/otel-collector/otelcol-config-extras.yml# otelcol-config-extras.yml# 将 traces 额外转发到自托管 Langfuseexporters:otlp_http/langfuse:endpoint:http://LANGFUSE_HOST_IP:3000/api/public/otelheaders:Authorization:Basic 上一步生成的Base64字符串tls:insecure:trueservice:pipelines:traces:# 在现有导出器基础上追加 langfuse保留原有 jaeger 和 span_metricsexporters:[debug,otlp_grpc/jaeger,span_metrics,otlp_http/langfuse]注意OTel Collector 合并多个配置文件时exporters是合并的但pipeline.exporters数组是替换而非追加所以必须把原有的导出器名称也写进去。第三步重启 OTel Collector配置文件是以 volume mount 方式挂载的修改后直接重启容器即可dockerrestart otel-collector查看日志确认 Langfuse 导出器已加载dockerlogs otel-collector21|grep-ilangfuse正常输出只有 deprecation 提示无 errorwarn otlphttp alias is deprecated; use otlp_http instead {otelcol.component.id: otlphttp/langfuse, otelcol.signal: traces}验证效果Langfuse 收到 traces通过 API 查询确认数据已入库curl--noproxy*\-upk-lf-xxxxxxxx:sk-lf-xxxxxxxx\http://LANGFUSE_HOST_IP:3000/api/public/traces?limit5成功返回 trace 列表说明链路已打通{data:[{id:c6d44c1d...,name:chat gpt-4o-mini-2024-07-18,timestamp:2026-05-29T02:43:05.639Z,projectId:my-project,...}]}截图演示Trace 全景Langfuse Traces 列表Trace 详情与 Jaeger 并行工作Langfuse 接入后原有的 Jaeger、Prometheus、Grafana 完全不受影响traces 只是多发了一份。两种平台的定位对比维度Prometheus GrafanaLangfuse擅长信号Metrics时序TracesLLM 调用链适合场景服务健康、资源监控LLM 输入输出、token 消耗、对话链路接入方式OTel metrics pipelineOTel traces pipelineOTLP HTTP数据存储TSDBClickHouse PostgreSQL配置改动已有新增 extras 约 15 行两者互补关系。小结整个接入过程的核心就是15 行 YAML在 extras 配置里声明一个新的otlp_http/langfuseexporter在 traces pipeline 的 exporters 列表里追加它重启 OTel CollectorLangfuse 对 OTLP 协议的原生支持是这一切能够顺滑实现的基础——不需要 SDK、不需要改业务代码、不需要额外的 agent已有的 OTel instrumentation 产生的数据直接复用。对于正在用 OTel 做可观测性、同时有 LLM 应用需要追踪的团队这是成本最低的接入路径。环境Windows 11 WSL2 Docker Desktop / Docker EngineOTel Demo v0.151.0Langfuse v3.104.0 把可观测性数据送进 LLM 追踪平台
把可观测性数据送进 LLM 追踪平台本文基于实际部署经验整理实验环境为 Windows WSL2 Docker。核心目标让 OpenTelemetry Demo 采集 Github Copilot 的 traces在不改动任何业务代码的前提下额外转发一份到自托管的 Langfuse实现 LLM 调用的全链路追踪。背景OpenTelemetryOTel是目前最主流的可观测性标准覆盖 traces、metrics、logs 三类信号。很多团队已经用 OTel Demo 跑通了从应用到 Prometheus Grafana 的链路。这次的具体需求我想看看 GitHub Copilot 具体的行为模式它在代码补全、对话、Edits 等场景下分别发起了哪些 LLM 调用、调用了什么模型、耗时多少、token 用量如何。OTel Demo 已经在采集这些gen_ai.*语义约定的 traces但 Prometheus Grafana 只能看聚合指标看不到单次调用的输入输出细节也做不了多次调用的关联分析。我们需要的是一个能把每一次 LLM 调用都当成一个可检索、可回放的事件来存储和分析的平台。Langfuse 是专为 LLM 应用设计的可观测平台支持标准 OTLP 协议接入这意味着只需改一行 OTel Collector 配置就能把现有 traces 同时打到 Langfuse零业务代码改动。采集 LLM 交互信息的意义采集并保存每一次 LLM 调用的输入/输出、模型、耗时、token 用量、调用上下文等信息对团队和产品有多方面的价值可观测性与故障定位将单次调用做为可检索事件可以精确重现异常请求、定位模型返回错误或延迟的根因如模型、网络、超参或输入质量问题。成本与计费归因通过记录每次调用的 token 与耗时能按功能、用户、产品线精确核算成本支持异常扣费警报与成本优化决策。性能优化与容量规划按模型/接口统计延迟与吞吐趋势识别瓶颈带宽、显存、模型选择指导量化、缓存或分层路由等优化策略。模型行为分析与质量监控可进行误答率、鲁棒性、偏差检测与回归测试帮助评估不同模型/版本在真实流量下的表现。产品与 UX 迭代分析用户输入与模型输出的模式发现常见失败场景或交互阻力驱动提示词设计、候选排序或对话策略优化。A/B 实验与模型选择将调用视为事件可用于分组实验模型 A/B/n量化改动对业务指标与体验的影响。审计、合规与可回放对敏感或合规场景保留可回放记录支持审计、事后追踪与法律合规需配合访问控制与保留策略。训练数据与持续学习筛选高价值的真实交互作为微调或强化学习的候选样本帮助持续改进模型质量。注意事项采集 LLM 交互数据同时伴随隐私与合规风险实践中应至少做到最小化与脱敏仅收集必要字段对可能包含 PII 的文本做脱敏或加密对高风险请求建立明确白名单/黑名单策略。访问与保留策略制定细粒度访问控制、审计日志与数据留存期限避免长期存储不必要的敏感数据。合规与告知在需要的法律/监管场景如金融、医疗明确用户告知与同意并与合规团队对接审查数据处理流程。将这些实践与 Langfuse 的事件化 trace 能力结合既能实现工程与业务层面的度量与改进也能把可回放、审计与实验能力带入 LLM 产品化的常规流程。整体架构这里仅以我的验证环境为例实际部署时需细致规划。关键点两套 Docker 栈运行在不同的 WSL 实例中通过 WSL 的内部网络互通OTel Collector 以 HTTP 协议将 traces 推送给 Langfuse 的 OTLP 入口。部署概况部署细节略不是本文重点仅简略说明。OTel Demo官方 Docker Compose 一键启动包含 20 微服务 otel-collector prometheus jaeger grafanaLangfuse官方 Docker Compose 一键启动包含 web、worker、postgres、clickhouse、redis、minio两套栈分别在不同 WSL 实例内运行天然网络隔离。排坑记录实际操作中遇到了几个典型问题记录在此供参考。问题一多 WSL 实例共享 Linux 内核导致 Docker 网络子网冲突两个 WSL 实例Ubuntu-24.04 和 langfuse使用同一个 Linux 内核Docker 默认都会尝试使用172.18.0.0/16产生路由冲突导致容器间 DNS 解析正确但 TCP 不通。解法给 Langfuse 的 Docker Compose 指定独立子网# docker-compose.override.yml放在 langfuse 目录networks:default:driver:bridgeipam:config:-subnet:172.25.0.0/16gateway:172.25.0.1问题二iptables-legacy FORWARD 链默认 DROPWSL 重启后iptables-legacy的 FORWARD chain policy 变成 DROP导致同一 Docker 网络内的容器之间无法通信ping 通但 TCP 不通。表现容器日志报Cant reach database server但docker network inspect显示 IP 分配完全正确。解法持久化修复规则# /etc/rc.local#!/bin/bashiptables-legacy-PFORWARD ACCEPT问题三WSL 内的 curl 走了系统代理返回 503Langfuse 实际已正常启动日志显示✓ Ready in 86.1s但 curl 验证一直返回 503因为环境变量中设置了 HTTP 代理curl 把本地请求也转发给了代理服务器。解法验证时加--noproxy *参数。核心配置OTel Collector → Langfuse这是本文的核心只需修改一个文件otelcol-config-extras.yml。OTel Demo 的 Collector 支持通过 extras 文件叠加配置不用动主配置文件。第一步生成 Langfuse API Key登录 Langfuse 控制台创建项目后在Settings → API Keys中获取Public Keypk-lf-xxxxxxxxSecret Keysk-lf-xxxxxxxx将两者拼接后做 Base64 编码作为 Basic Auth 凭证echo-npk-lf-xxxxxxxx:sk-lf-xxxxxxxx|base64# 输出类似cGstbGYteHh4eHh4eHg6c2stbGYteHh4eHh4eHg第二步编写 extras 配置编辑src/otel-collector/otelcol-config-extras.yml# otelcol-config-extras.yml# 将 traces 额外转发到自托管 Langfuseexporters:otlp_http/langfuse:endpoint:http://LANGFUSE_HOST_IP:3000/api/public/otelheaders:Authorization:Basic 上一步生成的Base64字符串tls:insecure:trueservice:pipelines:traces:# 在现有导出器基础上追加 langfuse保留原有 jaeger 和 span_metricsexporters:[debug,otlp_grpc/jaeger,span_metrics,otlp_http/langfuse]注意OTel Collector 合并多个配置文件时exporters是合并的但pipeline.exporters数组是替换而非追加所以必须把原有的导出器名称也写进去。第三步重启 OTel Collector配置文件是以 volume mount 方式挂载的修改后直接重启容器即可dockerrestart otel-collector查看日志确认 Langfuse 导出器已加载dockerlogs otel-collector21|grep-ilangfuse正常输出只有 deprecation 提示无 errorwarn otlphttp alias is deprecated; use otlp_http instead {otelcol.component.id: otlphttp/langfuse, otelcol.signal: traces}验证效果Langfuse 收到 traces通过 API 查询确认数据已入库curl--noproxy*\-upk-lf-xxxxxxxx:sk-lf-xxxxxxxx\http://LANGFUSE_HOST_IP:3000/api/public/traces?limit5成功返回 trace 列表说明链路已打通{data:[{id:c6d44c1d...,name:chat gpt-4o-mini-2024-07-18,timestamp:2026-05-29T02:43:05.639Z,projectId:my-project,...}]}截图演示Trace 全景Langfuse Traces 列表Trace 详情与 Jaeger 并行工作Langfuse 接入后原有的 Jaeger、Prometheus、Grafana 完全不受影响traces 只是多发了一份。两种平台的定位对比维度Prometheus GrafanaLangfuse擅长信号Metrics时序TracesLLM 调用链适合场景服务健康、资源监控LLM 输入输出、token 消耗、对话链路接入方式OTel metrics pipelineOTel traces pipelineOTLP HTTP数据存储TSDBClickHouse PostgreSQL配置改动已有新增 extras 约 15 行两者互补关系。小结整个接入过程的核心就是15 行 YAML在 extras 配置里声明一个新的otlp_http/langfuseexporter在 traces pipeline 的 exporters 列表里追加它重启 OTel CollectorLangfuse 对 OTLP 协议的原生支持是这一切能够顺滑实现的基础——不需要 SDK、不需要改业务代码、不需要额外的 agent已有的 OTel instrumentation 产生的数据直接复用。对于正在用 OTel 做可观测性、同时有 LLM 应用需要追踪的团队这是成本最低的接入路径。环境Windows 11 WSL2 Docker Desktop / Docker EngineOTel Demo v0.151.0Langfuse v3.104.0