调整规模和缩放

调整规模和缩放

原文：https://langfuse.com/self-hosting/configuration/scaling

本指南介绍了如何大规模操作 Langfuse 部署，并包含最佳实践和调整以获得最佳性能。

最低基础设施要求
服务
最低要求
Web 容器
2 个 CPU,4 GiB 内存
Langfuse Worker Container
2 个 CPU,4 GiB 内存
PostgreSQL 数据库
2 个 CPU,4 GiB 内存
Redis/Valkey 实例
1 个 CPU,1.5 GiB 内存
ClickHouse
2 个 CPU,8 GiB 内存
Blob 存储
无服务器 (S3 或兼容) 或 MinIO (2 个 CPU,4 GiB 内存)
摄取吞吐量
Langfuse 被设计用于处理大量的摄取数据。在非常高的负载下，可能需要应用影响吞吐量的额外设置。

扩展工作容器
对于大多数环境，我们建议根据工作容器的 CPU 负载来扩展它们，因为这是一个直接可以衡量的指标。对于 2 个 CPU 容器，负载超过 50% 表明实例已经饱和，吞吐量应该通过添加更多容器来增加。

此外，Langfuse 工作线程还通过 statsd 发布队列长度指标，这些指标可用于扩展工作线程容器。langfuse.queue.ingestion.length 是我们用于做出扩展决策的主要指标。通过设置 ENABLE_AWS_CLOUDWATCH_METRIC_PUBLISHING=true 来基于 AWS 指标配置自动扩展器，也可以将队列指标发布到 AWS CloudWatch。

减少摄取处理中的 ClickHouse 读数
默认情况下，Langfuse 工作程序会从 ClickHouse 读取现有事件，并将其与任何传入的数据合并。这会增加 ClickHouse 上的负载，并可能限制总吞吐量。对于尚未从先前版本的 Langfuse 迁移的项目，这是可选的，因为完整的事件历史记录在 S3 中可用。您可以将 LangFUSE_SKIP_INGESTION_CLICKHOUSE_READ_MIN_PROJECT_CREATE_DATE 设置为创建第一个项目之前的过去日期，例如 2025-01-01。请注意，任何 S3/blob 存储删除生命周期规则以及对事件的最新更新可能会导致事件历史记录重复。如果您使用 Langfuse SDK 或 OpenTelemetry 的默认集成方法，这应该不会影响您。

分离输入和用户界面
当摄取负载高时，Langfuse Web 接口和 API 调用可能变得缓慢或无响应。在这种情况下，将 Langfuse Web 部署分为一个摄取处理部署和一个用户界面处理部署可以帮助保持用户界面响应。您可以创建一个新的 Langfuse Web 部署的完全相同的副本，并将所有流量路由到 /api/public/ingestion*、/api/public/media * 和 /api/public/otel * 到新部署。

增加 S3 (Blob Storage) 写入并发
Blob 存储后端用于存储原始事件、多模式输入、批量导出和其他文件。在非常高吞吐量的情况下，S3 客户端库中允许的套接字数量可能会耗尽，请求也会受到限制。如果发生这种情况，我们通常会观察到处理摄取和媒体工作负载的 Web 容器上的内存使用量增加。相应的日志消息如下所示：@smithy/node-http-handler:WARN - 套接字使用量为容量 = 150, 额外的 387 个请求正在排队……

在这种情况下，我们建议通过将 LANGFUSE_S3_CONCURRENT_WRITES 设置为大于 50 (默认值) 的值来增加并发写入的数量。每增加一个写入套接字都会带来一定的内存开销，因此我们建议逐步增加该值，并观察服务的行为。

缓慢的 UI 查询或 API 调用
如果你注意到 UI 中的屏幕加载时间较长或 API 调用较慢，这通常与 ClickHouse 数据库资源不足或缺少时间筛选器有关。跟踪数据是按 projectId 和时间索引的，也就是说，在这些数据上添加筛选条件应该会显著提高性能。

如果所有筛选器都已就位，较大的 ClickHouse 实例可能会提高观察到的性能。ClickHouse 被设计为垂直扩展，即向实例添加更多内存应该会产生更快的响应时间。您可以在 ClickHouse 文档中查看为工作负载选择哪种内存大小。一般来说，我们建议对于较大的部署，至少需要 16 GiB 的内存。

增加磁盘使用
LLM 跟踪数据可能包含大量有效负载，这是由于被跟踪的输入和输出。此外，ClickHouse 在其系统表中存储可观测性数据。如果您注意到 S3/Blob Storage 或 ClickHouse 上的磁盘空间显著增加，我们可以推荐以下做法。

一般来说，释放磁盘空间最有效的方法是配置数据保留策略。如果您的计划中没有这种策略，请考虑以下选项。

S3/Blob Storage 磁盘使用
您可以实现生命周期规则来自动从 Blob 存储中删除旧文件。我们建议将事件保留到您想在 UI 中访问它们或想要更新它们的时间。对于大多数客户来说，默认为 30 天是一个不错的选择。

然而，这不适用于用于存储上传媒体文件的媒体存储桶。不建议在此存储桶上设置保留策略，原因如下：

跟踪中引用的媒体文件将崩溃
未来上传同一文件将会失败，因为文件上传状态是通过 Postgres 中的哈希跟踪的。
相反，我们建议使用 Langfuse 数据保留功能来正确管理媒体文件，避免产品中出现不正确的引用。

ClickHouse 磁盘使用
要自动删除 ClickHouse 中的数据，可以使用 TTL 功能。有关如何配置 TTL 的更多详细信息，请参阅 ClickHouse 文档。这适用于 ClickHouse 中的跟踪、观察、评分和 event_log 表。

此外，ClickHouse 中的 system.trace_log 和 system.text_log 表可能会变得更大，即使在较小的部署中也是如此。您可以修改 ClickHouse 的设置，以在这两个表上设置 TTL。偶尔手动修剪它们也是安全的。请参阅 ClickHouse 文档，了解有关如何在这些表上配置 TTL 的详细信息。

以下查询有助于识别 Clickhouse 中最大的表：

SELECT table, formatReadableSize(size) as size, rows FROM (
SELECT
table,
database,
sum(bytes) AS size,
sum(rows) AS rows
FROM system.parts
WHERE active
GROUP BY table, database
ORDER BY size DESC
)

高 Redis CPU 负载
如果您观察到 Redis 引擎 CPU 利用率高 (超过 90%), 我们建议检查以下内容：

使用一个至少有 4 个 CPU 的实例。这将允许 Redis 在单独的 CPU 上调度网络和后台任务。
确保已启用 Redis 集群模式。
如果高 CPU 利用率持续存在，可以将 Langfuse 使用的队列在多个节点之间进行分片。将 LangFUSE_INGESTION_QUEUE_SHARD_COUNT 和 LangFUSE_TRACE_UPSERT_QUEUE_SHARD_COUNT 设置为大于 1 的值以启用分片。我们建议将值设置为 Redis 集群中分片数量的约 2-3 倍，以确保在节点之间公平分配，因为每个队列分片将被分配到 Redis 中的随机槽 (有关更多详细信息，请参阅 Redis 集群文档)。

分片队列是一项高级功能，仅当您具有较高的 Redis CPU 负载并遵循上述建议时才应使用。分片队列后，不要减少分片的数量。请确保相应地缩放 LANGFUSE_INGESTION_QUEUE_PROCESSING_CONCURRENCY 和 LANGFUSE_TRACE_UPSERT_WORKER_CONCURRENCY, 因为它们在每个分片中计数。默认情况下，我们将每个工作线程的并发目标设置为 20, 即如果您有 10 个队列分片，则将其设置为 2。