通过 Blob 存储集成导出
Blob 存储导出在 Pro 计划(团队附加项)、Enterprise 计划和自托管版本中可用;Hobby 和 Core 计划不可用。
你可以安排导出到 Blob 存储,例如 S3、GCS 或 Azure Blob Storage。导出包含丰富的 observations(每个 observation 行包括其 trace 属性)和 scores;每次运行都写入你存储桶中 / 下的 observations_v2/、scores/ 和 manifests/。
这些导出可以每 20 分钟运行一次,或按 hourly、daily 或 weekly 计划运行。
导航到你的项目设置并选择 Integrations > Blob Storage 以设置新的导出。
选择你要使用 S3、S3 兼容存储、Google Cloud Storage 还是 Azure Blob Storage。
关于每个导出文件中每一列的内容,参见导出字段参考。
本页其余部分将介绍设置导出(文件格式、导出的列以及回溯导出的范围)、在你的流水线中消费导出(什么落在你的存储桶中以及如何检测完成的运行),以及监控和重新配置运行中的集成。
较旧的集成可能仍通过已弃用的旧版源导出,带有单独的 traces 和 observations 文件;差异和升级路径参见旧版导出源。
设置导出
创建集成
要设置导出,导航到 Your Project > Settings > Integrations > Blob Storage。
填写设置以向你的厂商进行身份验证,启用集成,然后按保存。 启用集成后不久即开始初始导出,然后按你选择的计划继续。 该导出支持 Parquet(默认)、CSV、JSON 和 JSONL 文件格式。参见文件格式。 阅读我们的 blob 存储文档,了解如何获取特定厂商的凭证。

文件格式
导出可以写为 Apache Parquet、CSV、JSON 或 JSONL 文件。新集成默认为 Parquet。
- Parquet 是一种列式二进制格式,由存储引擎编码和压缩,可由大多数数据仓库和查询引擎直接加载。
- CSV、JSON 和 JSONL 是可选 gzip 压缩的文本格式。
Parquet observation 导出不包含每单位模型价格列(input_price、output_price、total_price)。这些列在导出时快照模型定义价格,未来可能弃用。请使用 cost_details 和 total_cost 获取成本数据,它们包含在每种文件类型中。细节参见字段参考中的 Parquet 导出说明。
运行 ClickHouse < 25.11 的自托管部署: Parquet 导出失败可能不会作为错误显现。一次运行可能完成(并写入其清单),而 Parquet 输出不完整或无效。请升级到 ClickHouse >= 25.11,或使用文本格式(CSV、JSON 或 JSONL)以可靠地检测失败。
选择导出哪些列
字段组让你选择 observation 导出每行中出现哪些列组。十一个组覆盖完整行,其中十个可切换;在 Project Settings → Integrations → Blob Storage 下的 Export Field Groups 中切换它们。
组按它们在 UI 中出现的顺序列出;每个组内的字段按字母顺序排序。core 组是必需的,始终导出。
| 组 | 字段(observations_v2) |
|---|---|
core |
end_time、id、parent_observation_id、project_id、start_time、trace_id、type |
basic |
bookmarked、environment、level、name、public、session_id、status_message、user_id、version |
time |
completion_start_time、created_at、updated_at |
io |
input、output |
metadata |
metadata |
model |
input_price、model_id、model_parameters、output_price、provided_model_name、total_price |
usage |
cost_details、total_cost、usage_details、usage_pricing_tier_id、usage_pricing_tier_name |
prompt |
prompt_id、prompt_name、prompt_version |
metrics |
latency、time_to_first_token |
trace_context |
release、tags、trace_name |
tools |
tool_call_names、tool_calls、tool_definitions |
字段组也适用于旧版导出源,其中三个组(basic、usage、trace_context)包含较少的列;参见该节中的对比。
每单位定价字段(
input_price、output_price、total_price)位于model组中;它们来自匹配的模型定义。取消选择model会完全跳过工作端的模型定价查找。usage_pricing_tier_id和usage_pricing_tier_name字段保留在usage组中。使用 Parquet 文件类型时,即使选择了model,这三个价格列也不包含。参见文件格式。
新集成默认为全部十一个组,因此除非你缩小选择,否则行为与早期导出匹配。
通过 REST API 配置
GET 和 PUT /api/public/integrations/blob-storage 接受并返回:
exportSource:OBSERVATIONS_V2。值LEGACY_TRACES_OBSERVATIONS和LEGACY_TRACES_AND_ENRICHED_OBSERVATIONS仅用于旧版集成。exportFieldGroups:组名列表。提供时必须包含core。适用于所有导出源的 observation 导出。更新时省略则保留现有值。fileType:PARQUET(新集成的默认值)、CSV、JSON或JSONL。compressed:布尔值;新集成默认为true。为true时,文件写为.csv.gz、.json.gz或.jsonl.gz。不适用于PARQUET;Parquet 文件由存储引擎压缩,始终写为纯.parquet文件。
完整 schema 参见 API 参考。
导出模式
Export Mode 决定集成从多早开始导出:
| 模式 | 起始于 | 何时使用 |
|---|---|---|
| Full history | 你项目中最早的数据 | 你想要所有现有数据的完整一次性回填,以及持续的导出。 |
| From setup date | 你启用集成的时刻 | 你只关心未来的数据,不需要历史;这是开始的最轻量选项。 |
| From custom date | 你选择的开始日期 | 你想要从特定点(例如季度开始)的历史,而不导出其之前的所有内容。 |
更改模式会重置同步位置,因此它也是重新扫描历史的机制。参见重新导出数据和配置更改。
在你的流水线中消费导出
导出如何运行
每次运行将一个时间窗口的数据导出到你的存储桶,然后前进并在你配置的计划上导出下一个窗口。
- 导出延迟。 数据以短延迟导出,而非直到当前时刻,因此仍在通过接入移动的记录不会被半写入地导出。预期事件记录与其出现在你存储桶之间会有短暂滞后。
- 追赶/回填。 当集成从历史点开始(或落后)时,它会向前处理积压,并可能在稳定到正常节奏之前快速连续写入许多文件。新创建的完整历史集成会这样做,直到追赶上当前。
运行完成清单
单次导出运行每个导出的表写一个文件(最多四个,取决于所选导出源),因此仅凭表文件无法告诉你运行何时完成。作为每次成功运行的最后一个对象,Langfuse 写入一个清单文件,列出该运行产生的所有内容:
{prefix}{project-id}/manifests/{max-timestamp}.json
清单严格在该运行的所有表文件之后上传。一旦它出现,它列出的每个文件都在你的存储桶中完全可用;如果任何上传失败,则不写入清单,整个运行重试(表文件在重试时在相同键下被覆盖)。清单键中的时间戳是该运行的 maxTimestamp(UTC),截断到整秒,冒号替换为连字符,毫秒和尾随 Z 被删除(2026-07-13T09:00:00.000Z → 2026-07-13T09-00-00)。这与该运行表文件使用的词干相同(//.),因此一个运行的表文件和其清单共享相同的时间戳词干。
示例清单:
{
"version": 1,
"projectId": "cm0abcd1234efgh5678ijkl90",
"exportSource": "OBSERVATIONS_V2",
"window": {
"minTimestamp": "2026-07-13T08:00:00.000Z",
"maxTimestamp": "2026-07-13T09:00:00.000Z"
},
"maxTimestamp": "2026-07-13T09:00:00.000Z",
"createdAt": "2026-07-13T09:02:11.123Z",
"tables": ["observations_v2", "scores"],
"files": [
{
"key": "my-prefix/cm0abcd1234efgh5678ijkl90/observations_v2/2026-07-13T09-00-00.parquet",
"table": "observations_v2",
"fileType": "PARQUET",
"format": "parquet",
"compressed": false,
"contentType": "application/vnd.apache.parquet",
"sizeBytes": 1048576,
"rowCount": null
},
{
"key": "my-prefix/cm0abcd1234efgh5678ijkl90/scores/2026-07-13T09-00-00.parquet",
"table": "scores",
"fileType": "PARQUET",
"format": "parquet",
"compressed": false,
"contentType": "application/vnd.apache.parquet",
"sizeBytes": 20480,
"rowCount": null
}
]
}
关于 schema 的说明:
version仅在破坏性变更时递增;新字段可能在不增加版本的情况下添加,因此解析时忽略未知字段。window是运行覆盖的数据时间范围,两个边界都包含:恰好在maxTimestamp的记录也落入下一个运行的窗口。maxTimestamp重复window.maxTimestamp;清单文件名中的时间戳词干如上所述派生自它。tables和files反映所选导出源;无论源如何,scores始终包含。files[].key是包含你配置前缀的完整对象键,因此消费者无需重建路径即可获取列出的文件。files[].fileType是配置的文件类型:JSON、CSV、JSONL或PARQUET。files[].format还编码压缩:parquet、json-raw、json-gzip、jsonl-raw、jsonl-gzip、csv-raw或csv-gzip之一。files[].sizeBytes是上传大小(压缩文本格式为 gzip 后)。files[].rowCount是文本格式的导出行数,Parquet 文件为null。- 在追赶或回填期间,每个导出的窗口是带有自己清单的单独运行,因此几个清单可能快速连续出现。
对完成的导出运行做出反应
Langfuse 在导出运行完成时不发送 webhook。相反,订阅你存储提供商的原生对象创建事件,并对 /manifests/ 使用前缀过滤。由于清单是每次运行的最后一个对象,这给你每个完成运行一个事件。当事件触发时,下载清单并处理 files[].key 中列出的对象。
提供商方案:
- AWS S3:对
s3:ObjectCreated:*的 Event Notifications 到 SQS、SNS 或 Lambda,带键前缀过滤,或匹配对象键前缀的 EventBridge 规则。 - Google Cloud Storage:
OBJECT_FINALIZE事件的 Pub/Sub 通知;创建通知配置时设置对象名前缀。 - Azure Blob Storage:
Microsoft.Storage.BlobCreated上的 Event Grid 订阅,带subjectBeginsWith过滤,例如/blobServices/default/containers//blobs//manifests/。 - MinIO:
s3:ObjectCreated:*上的 Bucket 通知(webhook、Kafka、AMQP 等),带前缀过滤。 - Backblaze B2:带前缀过滤的 Event Notifications(webhooks)。
对于没有对象创建事件的 S3 兼容提供商(例如 Wasabi 或 DigitalOcean Spaces),请改为轮询清单前缀:按计划列出 /manifests/ 并处理比你的上一个检查点更新的任何清单。清单名称按导出时间戳字典序排序,因此基于标记(start-after)的列表使轮询保持廉价。
存储桶中的空文件
监控和重新配置
导出状态
集成设置页面显示状态徽章:
| 徽章 | 含义 |
|---|---|
| Active | 已启用并同步;下一次导出计划在未来。 |
| Running | 导出作业当前正在进行中(带旋转图标显示)。 |
| Queued | 导出到期并等待运行。 |
| Pending | 已启用但尚未运行导出(Data exported up to 显示 Never (pending))。 |
| Disabled | 集成已关闭。 |
| Error | 最近的导出失败;显示错误消息和时间戳。 |
同一页面上的状态卡片还显示:
- Data exported up to:最后成功导出窗口的时间戳(或
Never (pending))。 - Next export scheduled:下一次运行何时发生。
- Export mode:
Full history、From setup date或From custom date(加上适用时的开始日期)。 - 处于 Error 状态时带错误消息和时间的 Last export failed 警报。
如果工作进程在导出中途崩溃,2 小时的安全阀 TTL 确保徽章从 Running 恢复到其底层状态(通常为 Queued),以便下一个计划的运行可以继续。重新加载页面以查看最新状态。
Langfuse 在下一次运行重试失败的导出。重复失败会通过电子邮件和配置的 Slack 或 webhook 渠道通知项目管理员。在 Project Settings → Notifications 下配置它。
重新导出数据和配置更改
旧版导出源
本节仅适用于仍使用已弃用的
Traces and observations (legacy)导出源的集成。它将在未来版本中移除;请遵循下面的升级路径。新集成使用Enriched observations (recommended),可以跳过本节。
Export Source 设置决定集成导出哪些表。旧版源导出单独的 traces 和 observations 文件,而非丰富的 observations_v2 文件;无论源如何,scores 始终包含。每个源在 / 下写入的目录:
| 导出源 | 写入的目录 |
|---|---|
Enriched observations (recommended) |
observations_v2/、scores/ |
Traces and observations (legacy) and enriched observations |
traces/、observations/、observations_v2/、scores/ |
Traces and observations (legacy) |
traces/、observations/、scores/ |
关于每个文件中的列,参见字段参考中的导出源概览。
字段组也适用于旧版 observation 导出,但旧版 observations 文件中有三个组包含较少的列;所有其他组与丰富导出相同:
| 组 | 丰富(observations_v2) |
旧版(observations) |
|---|---|---|
basic |
bookmarked、environment、level、name、public、session_id、status_message、user_id、version |
environment、level、name、status_message、version |
usage |
cost_details、total_cost、usage_details、usage_pricing_tier_id、usage_pricing_tier_name |
相同,不含 usage_pricing_tier_id |
trace_context |
release、tags、trace_name |
无效;这些字段位于单独的 traces 文件中 |
旧版源仍可用的位置:
- Langfuse Cloud: 只有在 2026-05-20 之前创建的项目中、2026-06-22 之前创建的集成才保留其配置的旧版源并看到选择器。所有其他集成自动使用
Enriched observations (recommended),REST API 以400 BAD_REQUEST拒绝旧版值。 - 自托管: 丰富导出需要 v4 预览选择加入(
LANGFUSE_MIGRATION_V4_ALLOW_PREVIEW_OPT_IN);没有它,集成使用旧版源。一旦部署完成 v4 迁移(LANGFUSE_MIGRATION_V4_WRITE_MODE=events_only),旧版源不再可用(包括之前保存的),选择器被隐藏。
在 Langfuse Cloud 上,仍导出旧版源的集成还会在 /DEPRECATION_NOTICE.txt 收到纯文本弃用通知。它在每次成功运行时刷新(在该运行的清单之后尽力写入,且不列在其中),并在集成切换到 Enriched observations (recommended) 后的下一次成功运行时自动移除。清单仍是权威的运行完成标记;如果你的流水线对存储桶内容进行 diff 或订阅不带前缀过滤的对象创建事件,请考虑此对象。
升级路径
要安全地迁移现有旧版集成:
- 切换到
Traces and observations (legacy) and enriched observations。 - 在两个源都被导出时验证下游作业和数据消费者(此模式按设计创建重复记录)。字段级对比参见丰富导出与旧版导出之间的差异。
- 将消费者从
traces/和observations/目录重新指向observations_v2/。优先用运行清单驱动消费者,而非监视目录;每个清单准确列出其运行写入的文件。 - 验证完成后切换到
Enriched observations (recommended)。
切换后,
traces/和observations/目录完全不再接收任何文件,甚至不接收空文件,而空文件否则会为没有数据的窗口写入。仍监视这些目录的流水线会在没有错误信号的情况下静默,因此请在切换前完成步骤 3。由运行清单驱动的流水线不受影响:清单继续准确列出每次运行写入的内容,因此清单驱动的消费者会自动跟随源切换。
替代方案
你也可以通过以下方式导出数据: