用 Langfuse 打造终极 LLMOps 体系——Langfuse 导论

引言

在前面几章中，我们已经覆盖了大量概念性内容。到现在为止，你应该已经对监控 LLM 驱动应用有了扎实的基础理解。现在，是时候认识本书的核心重点：Langfuse——一个开源的 LLM 可观测性平台。Langfuse 在 Y Combinator 2023 年冬季批次期间被构想出来，它解决了一个关键需求：让 LLM 驱动系统在生产环境中更容易调试、优化和扩展。虽然很多可观测性工具关注基础设施或模型指标，但 Langfuse 采取了一种整体方法，捕获整个 LLM 交互生命周期，从 prompt 设计一直到最终输出。本章中，我们将探索这个平台的核心概念，以及如何开始使用 Langfuse。

结构

本章将覆盖以下主题：

• Langfuse 导论
• 监控 LLM 应用为什么需要专门工具
• Langfuse 对开源的承诺
• Langfuse 与 LangSmith 对比
• Langfuse 的核心能力
• 可观测性
• Prompt 管理
• 评估
• Langfuse 入门
• Langfuse 技术架构
• Langfuse Cloud
• 自托管 Langfuse
• 为自托管设置环境变量
• 自托管中包含的 Langfuse 功能
• 企业版付费功能

Langfuse 导论

Langfuse 是一个开源的可观测性与分析平台，专门为由 LLM 驱动的应用而构建。不同于为 API 等确定性软件设计的传统监控系统，Langfuse 被创建出来，是为了应对使用 AI 系统时的挑战。它为团队提供了关于 LLM 应用在真实使用中如何表现的可见性，并围绕 prompt、响应、评估和性能指标提供结构化洞察。

从核心上看，Langfuse 就像 LLM 驱动应用的黑匣子记录仪。我们的应用与模型之间的每一次交互，无论是一个简单查询、一条多步骤推理链，还是涉及多个工具的编排流程，都可以被追踪、分析和评估。这种级别的可观测性不仅有助于诊断问题，也让团队能够快速迭代 prompt、评估质量并优化成本。作为开源工具，Langfuse 在部署上非常灵活：开发者可以自托管，以获得完整控制权和数据治理能力；也可以使用托管服务，以获得便利性。它的设计目标是补充现有 MLOps 和监控技术栈，弥合传统基于指标的可观测性与生成式 AI 系统需求之间的差距。

Langfuse 为用户与 LLM 之间的每次交互提供可见性，使团队能够：

• 追踪模型调用以及多步骤推理链，包括 RAG 和聊天机器人。
• 将 prompt 作为工件进行版本化和管理。
• 通过人工反馈和自动反馈循环评估输出。
• 追踪性能指标，例如延迟、成本和质量。

当团队开始把 LLM 应用部署到生产环境时，就有必要清楚了解用户是如何使用 AI 功能的。借助 Langfuse，团队可以追踪流程中的每一步，并生成性能指标，用于提升用户满意度。通过检查这些指标，我们可以检测问题、做出调整，并监控功能表现。

监控 LLM 应用为什么需要专门工具

在第 1 章《大语言模型与监控导论》中，我们看到，将基于 LLM 的应用部署到生产环境时会遇到一些独特挑战。这些挑战中的每一个都说明了为什么传统日志和监控不足以支撑 LLM 系统。对专门工具的需求，来自 LLM 系统的几个特征。

输出的随机性

API 等传统软件基于确定性输入工作，对于给定输入，每次都会以相同方式处理请求。

另一方面，LLM 驱动系统即使面对相同输入，也可能给出措辞、完整性甚至正确性都不同的答案。

这种不可预测性意味着开发者需要能够捕获并比较所有响应的工具，而不只是记录单个实例。Langfuse 使团队能够记录多个输出、分析变异性，并量化响应的稳定性。

Prompt 敏感性与多步骤工作流

Prompt 经常被称为 LLM 的“源代码”。措辞上的小变化可能导致截然不同的结果。应用很少只包含一个 prompt—response 对。相反，它们通常会编排多个步骤，例如：

• 接收一个用户查询；
• 从知识库中检索相关文档，也就是 RAG；
• 将检索到的上下文传入模型；
• 格式化并返回最终响应。

每个步骤都会引入潜在失败点。如果没有适当的可观测性，调试几乎是不可能的。Langfuse 的追踪功能允许开发者记录完整事件链，更容易定位问题究竟来自检索、prompt 格式化，还是模型输出。

超越准确性的输出评估

正如我们在第 2 章《LLM 监控原则与指标》中看到的，对于 LLM 来说，评估是多维的。考虑一个基于 LLM 构建的客户支持 Agent。它的响应必须：

• 事实正确，没有幻觉；
• 有帮助，能够回应用户意图；
• 礼貌且安全，避免有毒或有偏见的语言；
• 高效，以低延迟交付；
• 成本有效，优化 token 使用量。

没有单一指标能够捕捉所有这些方面。专用工具必须支持：

• 自动评估，例如与 ground truth 的相似度分数。
• 人在回路反馈，例如点赞 / 点踩评分。
• 与领域特定目标绑定的自定义评估器。

Langfuse 将这些评估集成到一个平台中，帮助团队以结构化方式衡量质量。

监控漂移

LLM 提供商经常更新模型。例如：

• OpenAI 可能发布一个新版 GPT，它推理能力更强，但措辞不同。
• 一个较小模型可能改变其默认系统 prompt 行为。

这些更新可能悄悄降低应用性能。如果没有监控，团队可能直到用户抱怨才会注意到。同样，我们在第 3 章《检测 LLM 中的模型漂移与偏见》中看到的各种漂移，也可能暴露系统弱点。

Langfuse 通过随时间追踪性能趋势，帮助检测漂移，并在质量或可靠性低于可接受阈值时提醒团队。

成本与延迟指标

在 LLM 驱动系统中，每一个被处理的 token，无论是输入还是输出，都会转化为成本。在规模化场景下，即使很小的变化也可能显著累积。延迟同样关键：缓慢的 AI 助手会让用户沮丧，并降低采用率。

因此，可观测性工具必须包含：

• Token 级使用指标，用于分析成本。
• 延迟分布，用于识别瓶颈。
• 关于质量、成本和速度之间权衡的洞察。

Langfuse 的指标仪表盘使团队能够优化这些权衡，在用户体验和预算约束之间取得平衡。

支持协作与迭代

LLM 应用开发高度迭代。Prompt 会演进，评估标准会被细化，编排逻辑也会变化。团队需要：

• Prompt 版本管理，用于随时间追踪变更。
• 比较工具，用于评估新 prompt 是否表现更好。
• 共享仪表盘，用于开发者、产品经理和领域专家之间的跨职能协作。

Langfuse 内嵌这些协作特性，将可观测性变成开发工作流中的主动组成部分。

经过这段简要介绍之后，我们将看到 Langfuse 真正的开源特性，如何让它成为最好的 LLM 可观测性工具之一。

Langfuse 对开源的承诺

尽管 Langfuse 于 2023 年开始，但它一开始并不是完全开源的。它提供了付费 Pro 版本，许多核心功能无法在自托管版本中使用。然而，2025 年 6 月，这一点发生了巨大变化，Langfuse 团队称这一动作是“加倍下注开源”。

作为这一举措的一部分，Langfuse 将所有此前只在 Pro 版本中可用的产品功能开源。这对社区来说是一次重大推动，也让团队能够更快获得关于 Langfuse 产品如何发展的反馈。这些功能包括 LLM-as-a-judge 评估、标注队列、prompt 实验和 playground。所有这些都使 Langfuse 成为最全面且公开可用的 LLM 可观测性平台之一。

图 4.1：Langfuse 开源的功能
来源：langfuse.com/blog/2025-0…

这一决定背后的动机

Langfuse 给出了这一转变的几个关键原因：

信任与社区参与：
他们相信，移除商业壁垒可以与开发者建立更深层信任，并邀请社区围绕贡献展开协作。

与市场预期保持功能一致：
某些功能，例如 LLM-as-a-judge、评估工具和 playground，正在成为市场标准。团队认为，这些能力不应该被隐藏在付费墙后面，而必须被广泛访问，才能推动生态向前发展。

更快的迭代与反馈：
当功能完全开放后，采用和反馈周期都会加快，使产品对真实世界需求更加敏感。

重新聚焦商业努力：
在开源这些原本商业化的功能之后，Langfuse 会将商业努力集中在云服务和企业功能上，其中包括平台扩展、高级安全和企业支持，同时保持核心产品完全开放。

Langfuse 从一开始就是一个开源项目，建立在以下原则之上：

• 用户能够完全访问自己的数据；
• 在集成层面对模型和技术栈保持无关性；
• 允许针对独特工作流进行扩展和定制。

随着这一公告发布，他们移除了商业边界，并向更多用户开放了更多产品能力。

Langfuse 已经拥有强大的覆盖规模：每月超过 1500 万次 SDK 安装、超过 600 万次 Docker 拉取，以及 8000 多个每月活跃的自托管实例。

图 4.2：Langfuse 项目在 GitHub 上的 Stars
github.com/langfuse/La…
来源：langfuse.com/blog/2025-0…

直到今天，Langfuse 仍然是 LLM 工程领域开发者最受欢迎、最偏好的选择之一。它的 GitHub 项目拥有超过 24000 个 star，以及 100 多位贡献者。

Langfuse 的社区支持也非常活跃。其 GitHub discussions 页面上有 1000 多个正在进行的讨论，其中包括未来发展想法，以及对现有用户的支持。Langfuse 还拥有非常快的开发周期，新功能和修复几乎每隔一天就会推出。直到今天，其创始人、CEO 和团队创始成员仍然在积极贡献。

带着这一点，我们简要看一下 LangSmith。Langfuse 是 LangSmith 的开源替代方案。

Langfuse 与 LangSmith 对比

要理解 LangSmith，首先必须理解更广泛的 LangChain 生态系统。我们已经在第 1 章中介绍过 LangChain，它是一个编排框架。LangChain 是最早、最流行的用于构建 LLM 驱动应用的框架之一。它提供了一种可组合结构，可以把多个组件串联起来，包括 prompt、模型、检索函数、工具和 agent，从而形成复杂推理流水线。

图 4.3：LangChain 生态系统

在这一基础上，LangGraph 作为它的另一个互补框架，引入了一种基于图的编排模型，将 LLM 应用表示为由互相连接节点组成的动态工作流。每个节点可以执行推理、检索或决策，而边则定义数据和控制流的流向。

在这一生态系统中，LangSmith 作为可观测性、调试和评估层。它由 LangChain 和 LangGraph 背后的同一个团队创建，为开发者提供一个平台，用于：

• 在 chain 或 graph 执行时进行追踪和可视化。
• 记录和重放运行过程，用于调试和优化。
• 比较模型输出，用于 A/B 测试。
• 通过自动指标和人工评分指标评估性能。

由于 LangSmith 与 LangChain 和 LangGraph 原生集成，因此它可以自动捕获每次 chain 执行、工具调用和模型响应的详细元数据，为应用行为提供洞察。

不过，LangSmith 是一个商业产品。它以托管付费服务形式提供，由 LangChain Inc. 运营，并采用基于使用量的定价层级。虽然它简化了设置，并开箱即用地提供高级可视化工具，但官方并不支持自托管。这使得 LangSmith 非常适合那些已经投入 LangChain 生态、偏好托管基础设施和企业级可靠性的团队。

下面是两个平台之间的对比总结：

功能 / 能力	LangSmith	Langfuse	说明 / 评论
Tracing 与 Chain / Graph 可视化	✓	✓	两个平台都支持捕获 LLM chain 和工作流的执行 trace。
Prompt 版本化 / 实验	✓	✓	两者都具备 prompt 版本管理、运行 A/B 实验和管理 prompt 历史的能力。
评估与评分，LLM-as-judge、rubric 模板	✓	✓	使用内置模板或自定义评估器进行自动评估，是两个平台的核心功能。
人工标注 / 手动 Labeling	✓	✓	两者都允许在 UI 中对模型输出进行人工反馈或标注。
指标：延迟、成本、Token 使用量	✓	✓	两者都支持随时间监控延迟、成本，也就是 token 消耗，以及性能。
数据集与数据管理	✓	✓	两者都包含与评估、trace 过滤和版本化相关的数据集管理能力。
Playground / 交互式测试	✓，但有限	✓	两者都包含 playground 或测试 UI，尽管在边界场景下功能丰富度可能不同。
模型无关 / 多框架支持	—	✓	Langfuse 为多框架集成灵活性而构建，不限于 LangChain。
自托管 / 数据所有权	—，仅企业版	✓	自托管和完整数据控制是 Langfuse 的强设计点；LangSmith 的自托管受许可限制。
可扩展性 / 自定义评估器	✓，一定程度上	✓	两个平台都允许扩展，但 Langfuse 的开源性质提供了更大灵活性。
企业功能，RBAC、审计日志、安全	✓	✓，或通过付费附加功能	高级安全、基于角色的访问控制和审计日志在两个系统中都可能需要更高层级。

表 4.1：LangSmith 与 Langfuse 对比表
来源：astralinsights.ai/wp-content/…

在实践中，选择 Langfuse 还是 LangSmith，与其说取决于功能对比，不如说更多取决于应用上下文。

LangSmith 在以下情况下最有效：

• 我们主要使用 LangChain 或 LangGraph 构建。
• 相比跨框架灵活性，更偏好无缝集成。
• 我们偏好托管服务，以最小化运维负担。
• 数据治理政策允许将 trace 发送到托管环境。

Langfuse 则特别适合以下情况：

• 应用跨多个框架或自定义流水线。
• 数据隐私或合规要求强制使用本地存储。
• 我们希望扩展或定制可观测性逻辑，例如构建自定义评估器。
• 我们希望避免厂商锁定，并长期控制自己的可观测性技术栈。

在一些组织中，这两个工具甚至可能共存。使用 LangChain 构建快速原型的开发者可能依赖 LangSmith 获得即时反馈，而生产系统则集成 Langfuse，以获得完整可观测性和自托管控制。

Langfuse 的核心能力

Langfuse 为开发者提供了完整可见性和控制能力，用于理解 LLM 应用在真实环境中的行为。随着 LLM 系统从原型演进为生产就绪解决方案，开发者会面对由多步骤工作流、外部数据源、prompt 变体、模型版本和动态用户交互带来的复杂性。有效管理这些组件需要一个强大的可观测性框架。作为一个生态系统，Langfuse 在其 Products 和 Platform 伞形体系下共同提供以下功能：

• 可观测性 提供 trace 能力，帮助我们看到应用内部正在发生什么。
• Prompt 管理 带来版本控制和 prompt 优化能力。
• 评估 通过自动评估和人工评估，进行系统性质量度量。
• 指标 量化应用性能，使数据驱动决策成为可能。
• API 与数据平台 通过统一 API 封装不同工作流和定制能力。

在接下来的几节中，我们将探索这些核心能力，并考察 Langfuse 如何实现它们，以及它们如何共同提升 AI 系统的可靠性和可解释性。

可观测性

可观测性是 Langfuse 的核心。它使开发者能够追踪和可视化系统的端到端流程：从用户输入，到中间推理步骤和 API 调用，再到最终响应。在第 2 章《LLM 监控原则与指标》中，我们定义过“trace”，它是 Langfuse 中可观测性的中心单元。每个 trace 都会捕获关键元数据，例如模型名称、延迟、token 使用量、中间输出，以及对向量数据库、工具或 API 进行的任何链式调用。这种级别的可见性使我们能够：

• 调试复杂推理链和多步骤 agent。
• 识别失败模式或非预期行为。
• 将延迟和成本指标与性能结果相关联。
• 理解模型参数和 prompt 如何影响输出。

虽然 Langfuse 提供 Python 和 JavaScript / TypeScript 的原生 SDK，但它的可观测性模型是框架无关的。它不仅能与 LangChain 集成，也能与自定义流水线集成。开发者可以手动或自动对 trace 进行埋点，使 Langfuse 能够适应任何系统架构，从小型 RAG 原型到大规模企业 AI agent 都可以使用。对于 Python / JS 之外的语言，Langfuse 提供了公开 API，我们会在本章后面看到。

Langfuse 最引人注目的特性之一，是它能够与任何 LLM 提供商、框架和工具集成。这种设计使 Langfuse 在任何 LLM 工程项目中都极为灵活，不需要改变底层技术栈。下图展示了一些广泛集成选项的例子。完整列表可以在这里找到：langfuse.com/integration…

图 4.4：Langfuse 集成示例
来源：langfuse.com/integration…

在可观测性方面，Langfuse 提供了大量用于处理 LLM trace 的功能。我们会在第 5 章《Langfuse 中的可观测性》中结合具体代码示例深入介绍这些功能，但这里先列出最常用的一些：

Sessions 可以把 trace 分组在一起，为整个交互提供整体视图。Trace 可以像 HTTP session 一样通过共同的 sessionId 聚合起来，然后作为完整用户旅程查看。

说到用户，Langfuse 也允许我们向 trace 添加 userId，从而轻松区分系统中的不同用户。用户的定义也非常灵活，可以简单地基于 userId 识别用户。

组织 trace 的另一个选项是使用 Environments 和 Tags。Environments 可以区分生产、预发布或开发上下文；tags 可以对 trace 进行分类，后续可以作为过滤器使用。

Token 与成本追踪 是 LLM 可观测性的关键组成部分，Langfuse 默认会将这些信息添加到 trace 中。对于许多流行模型，例如 GPT、Anthropic 的 Claude 或 Google Gemini，这些信息会自动预填充到 trace 中，无需额外工作。对于自定义模型或采用非标准定价的模型，Langfuse 提供了添加自定义成本和 token 使用模型的选项，可以通过 UI，也可以通过 API / SDK 以编程方式完成。

最后，可观测性数据应该易于可视化，并且能够与相关利益方共享。为此，Langfuse 允许我们创建自定义 Dashboards，这些仪表盘使用其灵活查询引擎和丰富可视化选项。来自这些仪表盘的数据也可以下载为 CSV 文件。这样，用户既可以在 Langfuse 内部做数据分析，也可以使用外部平台进行分析。

总结来说，Langfuse 的可观测性功能将 LLM 内部运作转化为可操作洞察。它帮助团队用清晰、基于证据的流程取代试错式开发，让每个模型动作都能被理解，并据此进一步优化。

Prompt 管理

LLM 的行为很大程度上由 prompt 如何结构化、措辞和参数化决定。随着应用复杂度增长，系统化管理 prompt 变得和管理源代码一样重要。因此，任何可观测性平台如果没有 prompt 管理功能，都是不完整的。

随着时间推移，开发者会实验大量 prompt 变体，以提升准确性、语气或推理能力。如果没有适当组织，我们可能会忘记哪个版本产生了哪个结果，或者为什么某个 prompt 表现优于另一个。Langfuse 提供了一个专门产品，用于创建、版本化、测试和部署 prompt，使 prompt engineering 成为一个受控、可复现的过程。

Prompt 不仅由开发者编写，也会由非技术用户编写。产品经理、内容设计师和领域专家往往对语气、清晰度和事实正确性有宝贵洞察。Langfuse 通过用户友好且直观的 UI，使这些用户能够直接参与 prompt 开发。在 UI 中，用户可以查看、编辑和测试 prompt，而无需编写代码。这帮助组织把语言和领域专业知识直接带入优化循环。

Langfuse 通过外部托管 prompt，并通过 SDK / API 动态提供 prompt，将 prompt 与应用逻辑解耦。这意味着我们可以在 Langfuse 中编辑和更新 prompt，而不需要重新部署应用。我们只需要在运行时通过名称、版本和标签引用 prompt，就可以获取一个 prompt。这种解耦缩短了迭代周期，使更快实验和更低工程开销成为可能。如果新部署的 prompt 导致意外行为，团队可以直接在 UI 中通过一个动作立刻回滚到之前版本。Langfuse 确保 prompt 管理不会对生产应用造成延迟或可用性影响。Prompt 会由客户端 SDK 拉取并本地缓存，这意味着更新会在后台无缝传播。

Langfuse 的 prompt 管理方法结合了团队协作、安全性和灵活性。它允许非技术团队成员通过直观可视化界面微调 prompt，使开发者能够独立于发布周期更新 prompt，并提供完整版本控制，同时不影响运行时性能。

第 6 章《Langfuse 中的 Prompt 管理》将完全专注于 Prompt 管理，我们会详细看到该产品的所有高级功能。

评估

在其评估产品中，Langfuse 提供了一个集成框架，支持多种评估方法，使开发者能够为 trace、session 或 observation 分配 score。Score 是评估输出的主要数据对象，每个评估结果都会进入一个一致的评分模型。系统支持内置评估器，例如幻觉、相关性、毒性、有用性等维度，这些通过 LLM-as-a-Judge 模板实现，并附带用于评估输出质量的最佳实践 prompt 模式。

LLM 评估可以提升语言模型准确性和可靠性，从而改善用户体验，并增强用户对我们 AI 应用的信任。Langfuse 的评估框架使团队能够通过系统性检测不准确性、衡量性能，并随时间追踪改进，维护高质量且可信的 AI 应用。通过结构化指标，开发者可以监控响应质量、增强可靠性，并在部署前防止问题发生，最终建立用户信心并最小化运维风险。LLM 评估可以分为两个主要部分：

离线评估：

• 在部署前使用预定义测试数据集评估应用。
• 在开发期间用于衡量改进或回归。
• 它是可重复的，并且在有可用 ground truth 时，允许进行清晰的准确性测量。

在线评估：

• 在生产环境中，对处于真实世界运行状态的应用进行评估。
• 用于追踪成功率、用户满意度分数或其他指标。
• 可以收集真实用户反馈，并用于运行 A/B 测试。

下图展示了离线评估与在线评估之间的持续循环，用于提升输出质量。对于全面评估，通常会结合在线和离线评估。

图 4.5：如何持续改进 LLM 产品，Evidently AI
来源：www.youtube.com/watch?v=x9m…

Langfuse 的评估中包含以下核心概念：

概念	解释
Scores	Score 构成 Langfuse 评估系统的基础。它们是记录评估结果的数据条目，可以链接到不同 Langfuse 对象，例如 trace、session 或 observation。每个 score 都代表一个可度量的性能方面，例如准确性或相关性，并帮助标准化模型质量如何随时间被追踪和比较。
Evaluation Methods	这些代表用于生成 score 的流程或工具。评估方法可以从自动化规则脚本，到高级 LLM-as-a-Judge 技术，即另一个模型根据定义好的标准对输出评分。Langfuse 也通过其 API 支持外部或自定义评估器，使其能够灵活集成到现有工作流中。
Datasets	在 Langfuse 中，dataset 是结构化测试输入集合，并与期望输出配对，作为评估基准。它们支持跨多个模型或 prompt 版本进行一致测试，确保比较公平、可复现且数据驱动。Dataset 可以在实验之间复用，以随时间监控性能趋势。
Experiments	Experiment 是评估的实际执行阶段，其中 dataset 会经过 LLM 应用处理，并使用选定评估方法生成对应 score。该框架支持在 prompt、模型变体或发布版本之间进行系统性基准测试，创建可追踪、可重复的性能测试流程。

表 4.2：Langfuse 评估中的核心概念

正如我们所看到的，Langfuse 的评估功能为衡量基于 LLM 的应用表现提供了清晰且一致的方式。它帮助团队追踪变化、比较结果，并基于数据而不是猜测来改进应用。在第 7 章《在 Langfuse 中评估 LLM》中，我们会覆盖评估方法，包括在线和离线评估，以及使用 Langfuse 的评估能力进行漂移检测。

Langfuse 入门

本节探索使用 Langfuse 的不同方式，帮助我们选择最适合自身技术环境、组织需求和安全要求的方法。我们会介绍两条主要路径：Langfuse Cloud，这是由 Langfuse 托管的可管理、可扩展方案；以及自托管 Langfuse，它让组织完全控制自己的基础设施和数据。本节讨论每种路径的运维、安全和成本考量，并强调易用性、控制权和合规之间的权衡。我们将清楚理解每种使用模式适合哪些场景，从而在设置 Langfuse 时做出明智决策。让我们先从 Langfuse 系统架构的高层视图开始。

Langfuse 技术架构

为了符合其真正开源的性质，Langfuse 在设计中只使用开源框架和组件，这使得它可以部署在本地，也可以部署在任何云基础设施上，无论是云服务商提供的云，还是私有云。

图 4.6：Langfuse 系统架构
来源：langfuse.com/self-hostin…

Langfuse 的架构被设计为可靠、可扩展和可维护，使其能够高效处理大量 LLM 应用数据。该系统遵循模块化和分布式设计，将数据采集、存储、处理和可视化之间的职责分离。每个组件都扮演明确定义的角色，确保系统保持高性能和容错能力。

Web Server（Langfuse/Langfuse）

Web Server 是 Langfuse 系统的中心入口点。它处理来自 UI、API 和 SDK 的传入请求，并作为用户交互和数据摄入的网关。它部署在虚拟私有云（Virtual Private Cloud，VPC）中，以实现安全且受控的访问。

• 它验证并将客户端数据路由到后端。
• 它直接与 Redis 交互，用于缓存和队列操作。
• 它与数据库，即 Postgres 和 ClickHouse 通信，用于存储和检索。

Redis / Valkey（缓存、队列）

Redis 在 Langfuse 中既作为缓存，也作为消息队列。

• 作为缓存，它通过临时存储频繁访问的数据和 API 响应来帮助降低延迟。
• 作为队列，它会在后台 worker 异步处理之前，缓冲来自 web server 的传入事件。这种设计确保在高负载下仍能平稳运行，并帮助将摄入层与数据处理层解耦。

Async Worker（Langfuse/Worker）

Async Worker 处理来自 Redis 的排队任务，在主 Web 请求周期之外执行计算密集和存储密集的任务。

• 它将可观测性数据和评估结果写入数据库。
• 它管理后台任务，例如数据聚合、指标计算和评估调度。这种异步方法提升了系统响应性和可扩展性。

Postgres — OLTP（事务数据）

Langfuse 使用 PostgreSQL 作为其主要在线事务处理（Online Transaction Processing，OLTP）数据库，用于存储事务性和关系型数据。

• 它保存用户、组织、项目、数据集、加密 API key 和设置等元数据。
• 数据完整性和 ACID 合规性使它非常适合结构化、关系型操作和管理任务。

ClickHouse — OLAP（可观测性数据）

对于分析和高容量可观测性数据，Langfuse 使用 ClickHouse，这是一个列式在线分析处理（Online Analytical Processing，OLAP）数据库。

• 它存储大规模 trace 数据、日志和指标，用于快速聚合和实时分析。
• ClickHouse 优化过的列式格式确保在数百万条记录上进行低延迟查询，高效支持 Langfuse 的仪表盘和可视化。Postgres 与 ClickHouse 之间的这种划分，确保事务型和分析型工作负载保持隔离并被分别优化。

S3 / Blob Storage

Langfuse 与 AWS S3 兼容对象存储集成，用于存储原始事件数据和多模态附件，例如文件、图像或模型输入 / 输出。

• 它对于保留大型或二进制工件特别有用，因为这些内容不适合存储在关系数据库中。
• S3 存储也可选用于 playground 功能，使用户能够使用真实数据测试 prompt 和实验。

LLM API / Gateway（可选）

Langfuse 可以选择连接到 LLM API 或 Gateway，它可以位于同一 VPC 中，也可以通过 VPC peering 连接。

• 这种连接可以支持与模型服务端点直接集成，用于评估或实时追踪。
• 它可以由用户提供，也就是 “bring your own” 设置，允许跨不同环境和合规要求进行灵活部署。

数据流概览

客户端应用，也就是 UI、API 或 SDK，将 trace 和评估数据发送到 Web Server。

Web Server 缓存请求并将其推送到 Redis，确保高流量期间不会丢失数据。

Async Worker 消费这些任务，进行处理，并根据数据类型将结果写入 Postgres、ClickHouse 或 S3。

指标和 trace 随后通过 Langfuse UI 被聚合和可视化，供开发者和分析师访问。

架构优势

可扩展性：
异步处理和独立 OLTP / OLAP 系统可以高效处理不断增长的数据量。

韧性：
Redis 队列可以缓冲流量峰值，从而确保稳定性。

性能：
缓存和列式分析为摄入和查询都提供低延迟响应。

灵活性：
可选集成，例如 S3、LLM gateway，使其适用于不同用例和基础设施设置。

Langfuse 架构中的优化

无论我们使用 Langfuse Cloud 还是自托管，它都运行完全相同的代码库。两种方法唯一的区别在于，后一种方式需要我们自带基础设施。Langfuse 自己托管云版本，这是使用最广泛的选项，在生产环境中服务数以万计的团队。只有依靠其优化且高可用的架构，Langfuse 才能扩展到满足用户需求。下面是一些最强大的优化：

批量 Trace 处理：
传入 trace 会由 Langfuse Web Server 批量收集，并首先保存到 S3。一个引用会被添加到 Redis 用于排队，之后 Worker 会处理并加载它们到 ClickHouse。这种方法可以防止流量峰值期间出现变慢或错误。

快速 API Key 查找：
LLM 使用的 API key 存储在 Redis 内存中，使系统能够快速验证请求，而无需反复查询数据库。这降低了负载并加快了认证速度。

高效 Prompt 缓存：
Prompt 会由 SDK / API 本地缓存，并在后台刷新。它们也会存储在 Redis 中，因此频繁使用的 prompt 可以立即获取，而无需查询数据库。

专用分析数据库：
分析型和读密集查询由 ClickHouse 处理，即使面对大量可观测性数据，它也能提供快速响应。

支持大文件：
来自包含大文件的多模态模型的 trace，例如视频或其他媒体，会由客户端 SDK 直接上传到 S3 或兼容存储系统中，从而高效处理。

可靠事件存储：
所有 trace 和评估数据在写入主数据库之前，都会先保存到 S3 或 blob storage。这确保即使数据库暂时不可用，数据也不会丢失。

使用后台迁移实现无中断升级：
系统更新期间所需的长时间数据库迁移，会作为后台任务处理，从而最大限度减少停机，并保持常规操作顺畅运行。这些任务可能涉及添加或回填列，或者在不同存储之间迁移数据。后台迁移会在 worker 容器启动时开始，并在后台持续运行，直到完成或失败。

带着这些背景，我们进入使用 Langfuse 的两个选项。两种方法都有优缺点，我们这里的目标是给读者一个开放且公平的对比。

Langfuse Cloud

开始使用 Langfuse 的最快方式，是使用其云版本。它完全由 Langfuse 团队管理，也是最容易上手的方式。虽然这种方式可以免费开始，但如果使用量超过免费限制，可能会产生前置成本。我们建议在学习阶段从 Hobby 账号开始，以感受 Langfuse；之后再根据使用情况迁移到付费版本或自托管版本。

要开始使用 Langfuse，我们将在这里创建一个免费账号：

cloud.langfuse.com/auth/sign-u…

图 4.7：Langfuse 注册页面

除了姓名、邮箱和密码等基础信息外，我们需要选择一个数据区域。这个选择非常关键，因为它会决定我们的数据将存储在哪个地理位置。Langfuse Cloud 使用 Amazon Web Services（AWS）进行数据存储。在写作时，有 3 个选项可用：

• US：Oregon（AWS us-west-2）
• EU：Ireland（AWS eu-west-1）
• HIPAA：Oregon（AWS us-west-2）——符合 HIPAA 的区域，仅付费计划可用

理想情况下，我们应该选择一个离物理位置最近，并且符合数据保护法律和法规的位置。

注册后，我们需要创建一个 Organization，并在组织内创建一个 Project。在项目设置中，我们会创建一个 Project API Key。这基本上就是我们在应用中使用 SDK / API 向 Langfuse 发送 trace 时所需的认证信息。API key 由两部分组成：

• Langfuse Public Key，类似用户名；
• Langfuse Secret Key，也就是密码。

Secret key 创建后只能查看一次，因此请确保把它复制到安全位置。一个项目可以创建任意数量的 API key。删除 API key 是永久操作，无法撤销。

如果你计划在本书中使用 Langfuse Cloud，我们建议在进入下一章之前完成这个设置。除了注册和创建 API key 之外，对于 Hobby 账号来说，开始使用 Langfuse 不需要其他设置。

自托管 Langfuse

用户可能会选择自托管 Langfuse，而不是使用云版本，原因有很多，从数据控制与合规，到定制化和可扩展性都有。

数据隐私与安全：
自托管 Langfuse 可以确保所有敏感数据留在用户自己的基础设施中，对数据存储和访问拥有完全控制权。这对于拥有严格合规要求，或者要求本地数据驻留的法规约束的组织尤其重要。自托管还允许 Langfuse 在高安全环境中运行，而不需要互联网访问。

控制与定制：
自托管允许进行深入定制，并直接与现有内部工具和 API 集成。用户可以在没有厂商限制的情况下修改或扩展 Langfuse 的开源核心，在平台之上构建自定义功能或工作流。

可扩展性与性能：
自托管没有任意使用量或扩展限制；用户可以部署与 Langfuse Cloud 相同的水平可扩展架构，支持从小型测试到处理数十亿事件的大规模生产环境。

合规与企业要求：
企业可以自托管 Langfuse，以满足内部安全和合规政策，支持高级审计要求，或确保与内部认证和网络实践兼容。

成本考量：
对于拥有大量基础设施或运维专业能力的组织来说，自托管从长期看可能更具成本效益，尤其是在大规模场景下，因为它没有持续的托管服务费用。

当自托管 Langfuse 时，我们需要构建与前一节架构中看到的相同基础设施。这意味着，在自托管之前，我们需要准备以下组件：

• Postgres： 用于用户、组织和项目等事务存储。
• ClickHouse： 用于 trace、observation 和 score 的 OLAP 数据库。
• Redis / Valkey cache： 用于队列和缓存操作。
• AWS S3： 用于所有传入事件、多模态输入和文件导出。

所有这些组件既可以自管理，也可以直接使用云厂商提供的服务。主要要求是我们对这些组件拥有完整访问权限，使 Langfuse 能够不间断使用它们。

对于自托管，推荐的最低要求如下：

ClickHouse

Langfuse 支持 ClickHouse 版本 >= 24.3。对于生产设置，最低推荐配置包括：

Replicas：
生产设置至少 3 个副本。

Resources：
对于较大部署，将 resourcesPreset 设置为 large 或更高。

Storage：
从较大卷开始，例如 100Gi，以防止早期扩容。

ClickHouse 用户必须拥有以下授权，将 'user' 替换为你的实际 ClickHouse 用户名：

GRANT INSERT ON default.* TO 'user';
GRANT SELECT ON default.* TO 'user';
GRANT ALTER UPDATE, ALTER DELETE ON default.* TO 'user';
GRANT CREATE ON default.* TO 'user';
GRANT DROP TABLE ON default.* TO 'user';

Postgres Database

Postgres 作为事务型工作负载的主数据库。Langfuse 支持 Postgres 版本 >= 12，并使用所选数据库中的 public schema。Langfuse 没有指定该数据库的精确最低要求。

Redis / Valkey Cache

Redis / Valkey 被用作快速内存数据结构存储，用于队列和缓存操作。Langfuse 不支持 Redis / Valkey Cluster Mode，任何副本都只会作为备用实例。在生产环境中，我们一开始至少需要 1.5 GB 内存。

Docker

Langfuse 使用 Docker 对应用进行容器化。有两个容器：

Langfuse Web：
Web server，作为前端并托管 UI。

Langfuse Worker：
处理后端任务的应用。

对于生产环境，建议两个容器都至少使用 2 个 CPU 和 4 GB RAM，并至少运行两个 Web 容器实例以实现高可用。如果使用自动扩缩容，当任一容器 CPU 利用率超过 50% 时，应添加实例。

LLM API / Gateway

虽然是可选项，但强烈建议设置与我们计划在应用中使用的 LLM 提供商之间的连接。对于 Playground、LLM-as-a-judge 和 Prompt Experiments 等功能，这些连接是必需的，而本书会大量覆盖这些主题。这意味着你需要访问以下任一 LLM 模型：

• OpenAI，本书使用
• Azure OpenAI
• Anthropic
• Google Vertex
• Amazon Bedrock

当基础设施准备好之后，我们就可以开始部署 Langfuse。

使用 Docker 进行本地或非生产部署

在我们准备好在生产中使用自托管 Langfuse 之前，可以先用 Docker 设置快速试用。它有点像自托管版本中的 Hobby 账号。我们可以在本地计算机上这样做，也可以在 AWS、GCP 或 Azure 等云服务商内部的虚拟机（Virtual Machine，VM）上这样做。Docker 设置可以通过 3 个简单步骤完成：

• 从 GitHub 克隆官方 Langfuse 仓库。
• 更新 docker-compose.yml 中的 secrets。
• 启动 Docker 容器。

你也可以在本地机器上使用下面的代码块：

git clone https://github.com/langfuse/langfuse.git
cd Langfuse
docker compose up

这会使用每个组件的默认 Docker 设置，在你的机器或 VM 上部署 Langfuse 及其所有基础设施。要浏览 UI，只需访问：

http://localhost:3000

虽然这个设置很容易开始，但不建议用于高级使用或生产环境。主要原因是所有组件都在本地运行，所以该设置可用性很低，并且缺少任何备份功能，无法扩展到非常简单的使用之外。只有当我们希望试着玩一下这个设置，并且对在个人电脑上运行 Langfuse 感到好奇时，才应该使用 Docker。这也是一个适合学习目的的低成本选项。

使用 Kubernetes 或 Terraform 进行生产部署

对于生产或真实使用，我们可以选择两个选项之一：

Kubernetes（Helm）

• 使用官方 Helm chart 在任意 Kubernetes 集群上部署 Langfuse。
• 需要访问 Kubernetes 集群，并在本地安装 Helm。
• 默认情况下，它会部署应用容器和数据存储，也就是 PostgreSQL、ClickHouse、Redis，但应通过指向我们已经部署好的基础设施来覆盖这些默认配置。
• Helm chart 支持 sizing、外部数据库和包括 S3 在内的存储提供商配置。应该更新的 values 列表在这里提到：

github.com/langfuse/la…

在这个文件中，我们可以看到部署 Langfuse 前需要自定义和更新的完整 values 列表。我们不会深入 values 的细节，因为它超出了本书范围。上面的 README 文件很好地解释了如何为 Kubernetes 部署更新 chart values。

更新 values 后，我们可以运行：

helm repo add langfuse https://langfuse.github.io/langfuse-k8s
helm repo update
helm install langfuse langfuse/langfuse -f values.yaml

Terraform

默认情况下，Terraform 模块会为应用容器和数据存储配置必要基础设施。我们应该配置该模块来使用现有基础设施资源。

AWS（Terraform）

• 使用官方 Terraform 模块：github.com/langfuse/la…
• 部署在 Amazon Elastic Kubernetes Service（EKS）上，并使用数据库和存储的托管服务。
• 最小配置只需要一个 domain URL。

Azure（Terraform）

• 使用官方 Terraform 模块：github.com/langfuse/la…
• 部署在 Azure Kubernetes Service（AKS）上，并使用 Azure Database for PostgreSQL、Redis Cache 和 Storage Account。
• 创建完整技术栈，包括 Virtual Network、带 Web Application Firewall（WAF）的 Application Gateway，以及 private endpoints。

GCP（Terraform）

• 使用官方 Terraform 模块：github.com/langfuse/la…
• 部署在 Google Kubernetes Engine（GKE）上，并使用 Cloud SQL PostgreSQL、Memorystore Redis 和 Cloud Storage。
• 包含 VPC 设置、TLS certificates 和 Cloud DNS 配置。

所有生产部署都遵循相同架构：

• 应用容器： Langfuse Web，也就是 UI / APIs；Langfuse Worker，也就是异步处理。
• 存储组件： PostgreSQL，事务型；ClickHouse，分析型；Redis / Valkey，缓存 / 队列；S3 / Blob Store，事件 / 导出。
• 可选 LLM API / Gateway： 用于上一节提到的某些功能。

这些部署针对生产环境进行了优化，具备高可用、扩展能力和安全功能。在本章最后一节中，我们会看到自托管任何 Langfuse 实例所需的环境变量。

为自托管设置环境变量

设置 Langfuse 需要通过环境变量进行大量配置。无论你使用 Docker、Kubernetes 还是 Terraform 设置，都需要了解这些变量，并在适用的配置中填写，以确保设置能够正常工作。完整变量列表可在这里查看：

langfuse.com/self-hostin…

下面的表格总结了必填变量。

Postgres / Database

名称	解释	是否必填
DATABASE_URL	Postgres 数据库连接字符串。除了 DATABASE_URL，我们也可以将变量拆分为 DATABASE_HOST、DATABASE_USERNAME、DATABASE_PASSWORD、DATABASE_NAME、DATABASE_ARGS	是

表 4.3：Database 环境变量

ClickHouse

名称	解释	是否必填
CLICKHOUSE_MIGRATION_URL	ClickHouse 的迁移 URL，TCP，格式为 clickhouse://:(9000/9440)。	是
CLICKHOUSE_MIGRATION_SSL	设置为 true 以对 ClickHouse 迁移使用 SSL，默认 false。	否，可选
CLICKHOUSE_URL	ClickHouse 实例的 HTTP(S) URL，格式为 http(s)://:(8123/8443)。	是
CLICKHOUSE_USER	ClickHouse 用户名，需要 SELECT / ALTER / INSERT / CREATE / DELETE 授权。	是
CLICKHOUSE_PASSWORD	ClickHouse 用户密码。	是

表 4.4：ClickHouse 环境变量

Redis / Cache

名称	解释	是否必填
REDIS_CONNECTION_STRING	Redis 实例的连接字符串	是

表 4.5：Redis / Cache 环境变量

Storage / S3 / Blob（Events、Media、Exports）

名称	解释	是否必填
LANGFUSE_S3_EVENT_UPLOAD_BUCKET	上传 event / tracing 数据的 S3 bucket 名称。	是
LANGFUSE_S3_MEDIA_UPLOAD_BUCKET	用于上传媒体或多模态附件的 bucket。	是

表 4.6：S3 / Storage 环境变量

Authentication / Secrets / Security

名称	解释	是否必填
NEXTAUTH_URL	Langfuse web 部署的公开 URL，例如 yourdomain.com。	是
NEXTAUTH_SECRET	用于验证登录 session cookies 的 secret。我们可以使用命令 openssl rand -base64 32 生成。	是
SALT	用于哈希 API key 的 salt。我们可以使用命令 openssl rand -base64 32 安全生成。	是
ENCRYPTION_KEY	256-bit key，hex，64 个字符，用于加密敏感数据。我们可以使用命令 openssl rand -hex 32 安全生成。	是

表 4.7：Authentication / Secrets / Security 环境变量

自托管中包含的 Langfuse 功能

自托管时，Langfuse 提供额外功能，帮助团队根据自己的基础设施、合规和工作流需求定制 Langfuse 部署。无论是配置自定义缓存层、通过加密保护数据、设置邮件提醒，还是监控系统健康状态，这些功能都可以通过环境变量配置。下面是自托管 Langfuse 部署中可用的主要额外功能简要概览：

缓存

Langfuse 为 API key 和 prompt 提供内置缓存选项，以降低延迟。通过在 Redis 中缓存频繁访问对象，应用可以更快响应，并在高负载下保持平稳性能。缓存配置可以通过环境变量完全调整，包括控制 Time-to-Live（TTL）以及是否为特定组件启用缓存。

名称	描述
LANGFUSE_CACHE_API_KEY_ENABLED	启用或禁用 API key 缓存，默认 true。
LANGFUSE_CACHE_API_KEY_TTL_SECONDS	设置 API key 的缓存时长，单位为秒，默认 300。
LANGFUSE_CACHE_PROMPT_ENABLED	启用或禁用 prompt 缓存，默认 true。
LANGFUSE_CACHE_PROMPT_TTL_SECONDS	设置 prompt 的缓存时长，单位为秒，默认 300。

表 4.8：Caching 环境变量

自定义 Base Path

自定义 base path 功能允许用户将 Langfuse 放在反向代理后，或在子路径下提供服务，例如 yourdomain.com/langfuse。这在大型组织或多应用环境中特别有用，因为服务会被组合在共享域名下。配置 base path 可确保即使 Langfuse 不托管在根域名下，所有路由、静态资源和 API endpoint 仍能被正确解析。

名称	描述
NEXT_PUBLIC_BASE_PATH	当 Langfuse 在子目录下提供服务时，定义自定义 base path，例如 /langfuse。
NEXT_PUBLIC_WEBAPP_URL	Langfuse web interface 的完整公开 URL，包括协议和 base path。

表 4.9：Custom Base Path 环境变量

加密

加密设置允许敏感信息，例如 API key、secret 或存储 payload，在持久化到数据库之前使用安全 key 加密。该功能可以防止数据泄露，并确保符合安全标准。加密机制对开发者透明，只需要 ENCRYPTION_KEY 和 SALT 变量即可启用加密。

日志

Langfuse 提供可配置日志，使管理员能够定义日志级别、指定日志格式，文本或 JSON，并将 HTTP header 传播到日志中，用于与 Datadog 或 Grafana 等外部系统关联。

名称	描述
LANGFUSE_LOG_LEVEL	设置日志详细程度，包括 trace、debug、info、warn、error、fatal；默认 info。
LANGFUSE_LOG_FORMAT	定义日志输出格式，text 或 json；默认 text。
LANGFUSE_LOG_PROPAGATED_HEADERS	以逗号分隔的 HTTP header 列表，用于纳入日志中进行关联。

表 4.10：Logging 环境变量

事务邮件

Langfuse 支持发送事务邮件，例如组织邀请、密码重置和用户 onboarding 通知。邮件发送通过 SMTP 环境变量配置，允许与 SendGrid、SES 或自定义 SMTP 服务器集成。这一能力通过支持完整用户账号生命周期管理，增强了自托管体验。

名称	描述
EMAIL_FROM	事务邮件默认 “from” 地址，包括邀请和密码重置。
EMAIL_SMTP_HOST	SMTP 服务器主机名或 IP 地址。
EMAIL_SMTP_PORT	SMTP 端口号，通常 SSL 使用 465，TLS 使用 587。
EMAIL_SMTP_USER	SMTP 认证用户名。
EMAIL_SMTP_PASSWORD	SMTP 认证密码。
EMAIL_SMTP_SECURE	启用安全 SSL / TLS SMTP 连接，true / false。
EMAIL_SMTP_ALLOW_INVALID_CERT	允许无效 SSL 证书，仅应在测试中使用。

表 4.11：Transactional Emails 环境变量

健康与就绪检查

为了确保容器化或云原生部署中的平稳运行，Langfuse 提供专用健康检查和就绪检查 endpoint。这些检查会监控核心组件，例如数据库、缓存和队列系统。通过与 Kubernetes 或 Docker 等编排平台集成，当依赖不可用时，系统可以自动重启或重新调度容器，确保高可用性和稳定性。

名称	描述
LANGFUSE_HEALTH_CHECK_PORT	提供健康和就绪 endpoint 的端口，默认 8080。
LANGFUSE_HEALTH_CHECK_PATH	健康 endpoint 的路径，默认 /healthz。
LANGFUSE_HEALTH_CHECK_INTERVAL_SECONDS	内部健康探针频率，单位为秒，默认 30。

表 4.12：Health Check 环境变量

企业版付费功能

到目前为止，我们看到的功能都可以在自托管版本中无限制使用。所有核心 Langfuse 功能和 API 都在开源 MIT 许可下可用，并且对规模或功能没有限制。不过，Langfuse 也提供额外的可定制功能，主要面向希望为用户获得完整规模体验的组织。企业版（Enterprise Edition，EE）功能需要单独 license key，该 key 需要通过 Langfuse 销售团队购买。

项目级访问角色：
支持项目级细粒度访问控制，以更好地管理跨团队权限。Langfuse 中的用户会继承其所属组织的角色。通过使用该功能，我们可以在同一组织内按项目级别区分用户访问。

数据保留策略：
允许管理员根据保留周期配置自动数据删除，以满足合规和成本控制。默认情况下，Langfuse 会永久存储事件数据，但借助这一 EE 功能，可以将保留时间缩短到最少 3 天。

审计日志：
保留用户和系统操作的详细记录，用于可追踪性和合规审计。

UI 定制：
让组织能够定制 Langfuse 界面，包括品牌和外观。

组织创建者：
限制谁可以在自托管部署中创建新组织。

组织管理 API：
提供编程方式访问，用于创建、更新和管理组织与项目。

要在自托管部署中激活这些功能，请在设置中添加以下环境变量：

LANGFUSE_EE_LICENSE_KEY=<your-license-key>

结论

本章以全面方式介绍了 Langfuse。我们讨论了为什么需要专门工具来追踪模型性能、Langfuse 对开源的承诺，以及它在更广泛 LLM 生态系统中如何与 LangSmith 对比。本章阐明了 Langfuse 的核心能力，包括可观测性、prompt 管理和评估，并进一步探索了它的架构、部署选项、配置设置和企业功能。在下一章中，我们将更深入地了解 Langfuse 中的可观测性，并结合大量代码示例和 Langfuse UI 的动手体验进行学习。

参考资料

Langfuse v/s LangSmith - astralinsights.ai/wp-content/…

Remberg Use case of Langfuse - langfuse.com/faq/all/ai-…

Langfuse doubling down on Open Source - langfuse.com/blog/2025-0…

Langfuse GitHub discussions - github.com/orgs/langfu…

Langfuse Home Page - langfuse.com/

Langfuse Observability Overview - langfuse.com/docs/observ…

Langfuse Prompt Management Overview - langfuse.com/docs/prompt…

Langfuse Evaluation Overview - langfuse.com/docs/evalua…

How to continuously improve LLM products? By Evidently AI www.youtube.com/watch?v=x9m…

Langfuse Metrics Overview - langfuse.com/docs/metric…

Langfuse Self-hosting - langfuse.com/self-hostin…

Langfuse Self-hosting deployment containers - langfuse.com/self-hostin…

Langfuse Self-hosting ClickHouse - langfuse.com/self-hostin…

Langfuse Self-hosting Docker - langfuse.com/self-hostin…

Langfuse Self-hosting AWS - langfuse.com/self-hostin…

Langfuse Self-hosting Azure - langfuse.com/self-hostin…

Langfuse Self-hosting GCP - langfuse.com/self-hostin…

Langfuse Self-hosting Configuration guide - langfuse.com/self-hostin…

Langfuse EE features - langfuse.com/self-hostin…