Langfuse 云成本分析指南：基于 Metabase 成本 Mart 的 Langfuse Cloud 基础设施成本洞察-编程实验室

Langfuse 云成本分析指南：基于 Metabase 成本 Mart 的 Langfuse Cloud 基础设施成本洞察

【免费下载链接】langfuse🪢 Open source AI engineering platform: LLM evals, observability, metrics, prompt management, playground, datasets. Integrates with OpenTelemetry, LangChain, OpenAI SDK, LiteLLM, and more. 🍊YC W23项目地址: https://gitcode.com/GitHub_Trending/la/langfuse

导读

本文面向 Langfuse Cloud 的运维与财务工程团队，系统讲解如何基于 Metabase 基础设施成本仪表盘及其生产环境成本 Mart（cost marts）开展有数据支撑的云成本分析。你将掌握：如何按天、按云厂商、按服务、按用量类型与账号维度拆解 AWS 与 ClickHouse 的成本结构，如何定位成本回归（cost regression）的根因，以及如何严谨地输出包含时间窗口、查询粒度、主要成本驱动因素与注意事项的分析结论。文中所引用的表结构、字段 ID 与查询模式均来自当前仓库.agents/skills/analyze-cloud-costs/下的技能定义与参考文档，可直接复用到日常成本复盘与异常排查中。

一、技能定位与适用场景

analyze-cloud-costs是仓库.agents/skills/analyze-cloud-costs/SKILL.md中定义的一个 Agent 技能（Skill），其 frontmatter 明确定义了触发时机：

被询问 Langfuse Cloud 的云支出（cloud spend）时；
需要 AWS 与 ClickHouse 的成本拆分（cost split）时；
需要按云厂商 / 服务 / 用量类型 / 账号维度分析成本驱动因素时；
需要计算每日每追踪事件成本（daily cost per tracing event）时；
需要解释 Metabase 中可见的基础设施成本仪表盘或成本回归现象时。

技能的核心原则是evidence-backed（有证据支撑）：一切结论必须来自 Metabase 基础设施成本仪表盘及其生产成本 Mart，最终交付物应明确指出分析的时间窗口、查询粒度、主要成本驱动因素以及必要的注意事项，而不是凭经验猜测。

在 Langfuse 的整体架构中，这个技能与仓库worker/src/ee/cloudUsageMetering/、worker/src/ee/cloudSpendAlerts/、worker/src/ee/usageThresholds/等计费与用量计量模块（详见后文第六节）共同构成"用量采集 → 计费计量 → 成本核算 → 成本分析"的完整闭环：前者是实时/近实时的计量与告警，而本技能负责的则是基于 Metabase 数据仓库的离线成本核算与结构分析。

二、数据源：Metabase 成本仪表盘与生产成本 Mart

2.1 主数据源

技能的主数据源是Metabase 基础设施成本仪表盘（Infra Cost dashboard）及其底层production cost marts（生产成本数据集）。仪表盘的入口定义在参考文档.agents/skills/analyze-cloud-costs/references/cost-marts.md中，并支持按account与date参数筛选、以过去 90 天（past90days）为默认时间范围浏览。

2.2 四张核心 Mart 表

参考文档将成本数据建模为四张 Mart 表，各自承载不同的分析粒度：

用途	表名	表 ID
按云厂商、服务、用量类型、账号、天聚合的 AWS 与 ClickHouse 统一成本行	`langfuse_prod.mart_daily_cost_chart`	`739`
每日头条汇总：总成本 + 追踪事件数 + 每 10 万事件成本	`langfuse_prod.mart_daily_cost_with_events`	`784`
按产品、操作、账号、用量类型细分的 AWS CUR 汇总	`langfuse_prod.mart_aws_cost_daily_by_service`	`610`
按实体与指标细分的 ClickHouse 成本	`langfuse_prod.mart_clickhouse_daily_cost`	`689`

参考文档给出了明确的选表建议：

结构拆分分析（structural breakdowns）优先使用表739；
每日头条汇总（daily headline totals）优先使用表784；
需要 AWS 侧更细粒度的 CUR（Cost and Usage Report）明细时使用表610；
需要 ClickHouse 侧按实体/指标的成本细节时使用表689。

说明：mart_aws_cost_daily_by_service直接对接 AWS CUR（Cost and Usage Report），这是 AWS 原生导出的计费明细数据，因此它天然存在"当日数据延迟到达"的特性，这也是技能要求"优先使用完整 UTC 日"的底层原因。

三、Mart 表字段 ID 参考

Metabase 通过t<表ID>-<字段序号>的形式暴露字段 ID，用于构造查询。参考文档为两张核心表列出了完整字段映射，分析时务必对照使用：

3.1`mart_daily_cost_chart`（表 ID`739`）

字段 ID	字段名
`t739-0`	`usage_date`
`t739-1`	`service_provider`
`t739-2`	`service_name`
`t739-3`	`operation`
`t739-4`	`usage_type`
`t739-5`	`account_name`
`t739-6`	`cost_usd`

3.2`mart_daily_cost_with_events`（表 ID`784`）

字段 ID	字段名
`t784-0`	`usage_date`
`t784-1`	`total_cost_usd`
`t784-2`	`clickhouse_cost_usd`
`t784-3`	`aws_cost_usd`
`t784-5`	`s3_api_operations_cost_usd`
`t784-6`	`total_tracing_events`
`t784-7`	`total_cost_per_100k_events`

从字段映射可以清晰看到表784的设计意图：它把总成本拆成clickhouse_cost_usd与aws_cost_usd两大来源，同时引入total_tracing_events（追踪事件总量）与total_cost_per_100k_events（每 10 万事件成本）——后者正是技能描述中提到的"daily cost per tracing event"指标的数据来源，用于评估成本与业务规模（事件量）之间的相对关系，而不仅仅是绝对金额。

四、标准分析工作流

技能在SKILL.md中定义了六个步骤的标准工作流，这也是成本分析的核心方法论：

步骤 1：澄清问题并选择分析粒度（grain）

技能明确区分了三种分析粒度，务必先对齐问题再选粒度：

每日头条汇总（Headline daily totals）：关注总成本、AWS 成本、ClickHouse 成本、追踪事件数、每 10 万事件成本；
成本结构（Cost structure）：按云厂商、服务、用量类型、操作、账号、天等维度展开；
驱动因素/回归分析（Driver or regression analysis）：将近期"完整日"窗口与之前的基线窗口进行对比，解释成本为何变化。

步骤 2：加载参考文档

查询前先加载.agents/skills/analyze-cloud-costs/references/cost-marts.md，其中包含表 ID、字段 ID、查询示例与注意事项。这保证了查询的准确性和一致性。

步骤 3：通过 Metabase MCP 工具查询

优先使用 Metabase MCP 提供的工具执行查询。如果 Metabase 工具不可见，应先通过工具搜索（tool search）发现它们，再考虑手动解释兜底。技能代理接口配置见.agents/skills/analyze-cloud-costs/agents/openai.yaml，其默认提示词为："Use $analyze-cloud-costs to explain recent Langfuse Cloud cost drivers from Metabase."

步骤 4：优先使用完整 UTC 日

这是技能反复强调的数据完整性原则：AWS CUR 行可能延迟到达，因此不应把当日（current-day）的 AWS 成本视为最终值。做稳定分析时，应选择最近的完整 UTC 日，而不是把今天包含进来。

步骤 5：由粗到细逐层下钻（drill down）

标准的下钻顺序是：

云厂商拆分（Provider split）：先看 AWS 与 ClickHouse 的整体占比；
主导云厂商内的服务拆分（Service split）：在占主导的厂商内部按服务展开；
用量类型、操作、账号拆分（Usage type / operation / account split）：针对 Top 服务进一步拆分；
日趋势（Daily trend）：解释随时间变化的原因。

步骤 6：只报告数据支持的内容

技能明确要求：只报告查询数据支持的事实。如果请求的某个切片不存在，应明确说明"该切片未查询到数据"，而不是臆造一个成本驱动因素。这是保证分析可信度的底线原则。

五、Metabase MCP 查询模式与 JSON 示例

5.1 三种工具用法

参考文档说明 Metabase MCP 支持三种工具：

query：用于快速读取（quick reads），即一次性的即席查询；
construct_query+execute_query：用于构造并执行不透明查询（opaque query），适合需要检查或复用查询的场景。

5.2 参数传递规则

实际使用时，filters、aggregations、group_by、fields一律以JSON 数组形式传递。某些工具 schema 可能把这些参数显示为字符串——此时应将相同的数组序列化为 JSON 字符串，且不得改变数组结构（"serialize the same arrays without changing their shape"）。

参考文档给出的标准查询示例（按云厂商 + 服务聚合成本，表739）：

{ "table_id": 739, "filters": [ { "field_id": "t739-0", "operation": "greater-than-or-equal", "value": "2026-05-09" } ], "aggregations": [ { "function": "sum", "field_id": "t739-6" } ], "group_by": [ { "field_id": "t739-1" }, { "field_id": "t739-2" } ], "limit": "200" }

5.3 分页与限额

技能要求limit 显式设置且足够小以满足分析需要；仅在需要 continuation token（续页令牌）时才使用分页。

六、常用成本拆分模板

参考文档为最常见的分析场景提供了可直接套用的"查询配方"，核心模式是"固定表739+sum(t739-6)聚合 + 不同的 group_by 维度"：

分析场景	表	聚合	分组维度
云厂商拆分（Provider split）	`739`	`sum(t739-6)`	`t739-1`
服务拆分（Service split）	`739`	`sum(t739-6)`	`t739-1`,`t739-2`
用量类型拆分（Usage type split）	`739`	`sum(t739-6)`	`t739-1`,`t739-4`
环境/账号拆分（Account split）	`739`	`sum(t739-6)`	`t739-1`,`t739-5`
按厂商的日趋势（Daily trend by provider）	`739`	`sum(t739-6)`	`t739-0`,`t739-1`

每日头条汇总则走表784：按t784-0过滤日期后，直接读取total_cost_usd、clickhouse_cost_usd、aws_cost_usd、total_tracing_events、total_cost_per_100k_events五个指标。

成本尖峰（cost spike）的标准下钻序列

参考文档给出了排查成本异常升高的完整链路：

在表784中对比每日总成本，锁定异常日期；
在表739中对同样的日期按云厂商拆分；
对占主导的云厂商按服务拆分；
对主导服务按用量类型、操作和账号继续拆分。

这一"总成本 → 厂商 → 服务 → 用量维度"的层层下钻，正是第四步工作流"由粗到细"原则的具体落地。

七、与仓库成本计量模块的关联印证

虽然成本分析的数据源是 Metabase，但"成本从何而来"可以从仓库的成本计量实现中找到印证。worker/src/ee/cloudUsageMetering/handleCloudUsageMeteringJob.ts是 Langfuse Cloud 用量计量的核心作业处理器，它通过getTraceCountsByProjectInCreationInterval、getObservationCountsByProjectInCreationInterval、getScoreCountsByProjectInCreationInterval等函数按项目统计创建时间窗口内的 trace / observation / score 数量，并将其作为计费事件上报给 Stripe 的 Billing Meter（stripe.billing.meterEvents.create）。

这段实现从源码层面印证了表784中total_tracing_events的业务来源：追踪事件（tracing events）是 Langfuse Cloud 计费与成本核算的基础计量单位，成本按事件量归一化（cost per 100k events）正是为了让成本分析可以剥离业务规模因素、聚焦单位成本变化。

同时，worker/src/ee/cloudUsageMetering/constants.ts定义了cloud_usage_metering定时任务与队列状态机（queued/processing），说明整个计量链路由 BullMQ 队列驱动、按固定间隔执行，这与 Metabase Mart 按"天"聚合的成本数据天然匹配——成本分析的时间粒度（UTC 天）与计量间隔设计是相互呼应的。

此外，仓库中还有配套的支出告警模块（worker/src/ee/cloudSpendAlerts/handleCloudSpendAlertJob.ts）与用量阈值模块（worker/src/ee/usageThresholds/），前者负责在成本超过阈值时触发告警，后者负责免费额度等用量阈值处理。这三者与analyze-cloud-costs技能共同构成了 Langfuse Cloud 成本治理的完整工具箱：告警负责即时响应，技能负责深度分析。

八、注意事项（Caveats）

技能与参考文档明确列出以下数据解读注意事项，输出分析结论时必须主动说明：

当日 AWS 成本可能不完整：AWS CUR 数据可能尚未落地，当日 AWS 成本不应视为最终值；
优先最近完整 UTC 日：进行稳定分析时，应排除今天，选择最近已完整结束的 UTC 日；
ClickHouse 成本的单位语义：统一 Mart 中 ClickHouse 成本行标记为cost_usd，但其底层来源指标是 ClickHouse 积分（credits）。当分析需要精确的计费口径解读时，必须向读者说明这一换算关系；
字段 ID 可能变化：如果 Metabase 模型被重建（rebuilt），字段 ID 可能改变。查询失败时，应先搜索 Metabase 中的表名并检查返回的元数据，再调整分析，而不是盲目修改查询。

九、输出交付物规范

技能对最终分析结论的输出格式提出了明确要求，任何成本分析交付都应包含以下要素：

时间窗口：明确说明分析覆盖的时间范围，以及是否使用完整 UTC 日；
总成本与云厂商拆分：相关时给出总成本及 AWS / ClickHouse 的占比；
主要成本驱动因素：按服务、用量类型、操作或账号列出 Top 驱动项；
趋势或基线对比：当用户问"为什么变化了"时，给出趋势或与基线的对比结论；
注意事项：特别是当日 AWS 数据不完整，以及统一 Mart 中 ClickHouse 积分标注为cost_usd这两点；
可追溯上下文：在最终回答中附上 Metabase 仪表盘链接或查询结果上下文，便于复核。

十、最佳实践总结

综合技能定义与参考文档，可以将 Langfuse Cloud 成本分析的最佳实践归纳为以下要点：

先定粒度再查询：头条汇总、结构拆分、回归对比三种粒度对应不同的表与查询配方，切忌混用；
数据完整性优先：坚持使用完整 UTC 日，避免被延迟到达的 AWS CUR 数据误导；
层层下钻：从总成本出发，按"厂商 → 服务 → 用量类型/操作/账号"逐层定位驱动因素；
严格守界：只报告查询数据支持的内容，数据缺失时如实说明，不臆造驱动因素；
保留证据链：输出中附带仪表盘链接与查询上下文，并主动说明单位换算（ClickHouse credits →cost_usd）与数据延迟等 caveats。

按此流程执行，即可在 Langfuse Cloud 的成本分析工作中得到可复核、可追溯、口径清晰的数据结论，为成本优化决策提供可靠依据。

Langfuse 云成本分析指南：基于 Metabase 成本 Mart 的 Langfuse Cloud 基础设施成本洞察