数据分别存在哪里
metrics、logs 和 traces 放在同一个引擎里：SQL 与 PromQL/TQL 可查，OTLP 原生，存算分离跑在对象存储之上。应用与配置数据——用户、项目、prompt、数据集定义、API key——仍然放在 Postgres，与上游 Langfuse 一致。分析事件存储是一张只追加的 raw_events 表作为事实来源，加上合并后的投影表和带索引的 EAV 侧表，支撑 metadata、tag、tool 过滤。Redis 继续跑 BullMQ 队列。
Openfuse
LLM 工程平台，跑在真正的可观测数据库上。
Langfuse 的一个 fork，把分析存储从 ClickHouse 换成了时序可观测数据库。Langfuse 的产品、公共 API 和 SDK 都不变；事件存储成为 trace、observation、score 以及仪表盘背后分析的事实来源。
五分钟上手
OPENFUSE_STANDALONE_IMAGE=tma1ai/openfuse-standalone:1.0.0-beta.1 docker compose -f docker-compose.standalone.yml up -d --pull always
克隆仓库，cp .env.quickstart.example .env，然后执行这一条。打开 localhost:3000：quickstart 配置会自动建好一个 demo 项目，可以用 demo@example.com / langfuse-dev 登录，或者直接把 Langfuse SDK 指向内置的 key。这些都是不安全的开发默认值——正式部署请从 .env.prod.example 出发，并设置 GREPTIME_PASSWORD 打开分析存储的强制鉴权。
固定发布镜像，或拆分 web 与 worker
standalone —— web + worker 单容器
# 用发布镜像代替本地构建
OPENFUSE_STANDALONE_IMAGE=tma1ai/openfuse-standalone:1.0.0-beta.1 \
docker compose -f docker-compose.standalone.yml up -d --pull always
split —— web 与 worker 独立伸缩
OPENFUSE_WEB_IMAGE=tma1ai/openfuse-web:1.0.0-beta.1 \
OPENFUSE_WORKER_IMAGE=tma1ai/openfuse-worker:1.0.0-beta.1 \
docker compose up -d --pull always
现有 Langfuse SDK 不用改
把任何现有的 Langfuse SDK——或者任何 OpenTelemetry tracer——指向 Openfuse，trace、observation、score 就会照常落库，不用改一行代码。
从小起步，按需扩展
先跑一个 openfuse-standalone。存储可以落本地磁盘，也可以落对象存储，同一个引擎从单机扩展到集群；缩回去也不丢数据。
便宜的长期留存
对象存储原生的分层存储，加上一条普通 SQL TTL（LANGFUSE_GREPTIME_TTL），让多年留存变得可负担。在 ClickHouse 版 Langfuse 里，可配置留存是企业版功能。
已经可用
完整的 Langfuse 界面，一点没少
不是子集。tracing、仪表盘、数据集、评测、导出都能用，覆盖到的读路径逐字节对齐上游 Langfuse。
Trace 与 observation
按你已经熟悉的方式搜索和过滤 trace 及其嵌套的 observation 树。编辑、删除、导出行为与预期一致，包括整个项目的删除。
localhost:3000/traces
一条 trace，逐个 span 看
打开任意一条 trace，展开完整的 observation 树——每一层的输入、输出、模型、token 数、成本和延迟。
localhost:3000/traces/…
仪表盘与指标
成本、token 用量、延迟分位数、score 分析，可按 metadata、tag、tool 拆分。与上游有意的差异——都是 fork 侧等价或更正确的情况——记录在 parity ledger 里。
localhost:3000
Session、用户与评测
完整跟一段多轮对话走到底，或者切换到某个用户做过的全部事情。数据集、实验和评测工作流端到端可用。
localhost:3000/sessions/…
为什么换存储
LLM trace 本身就是可观测数据
带时间戳、高基数上下文的宽事件，正是统一可观测数据库要处理的东西。
不需要对象存储桶
媒体上传、OTel carrier、评测 blob 存储、批量导出，默认全部走本地文件系统路径。标准部署完全不需要 S3 或 MinIO——需要分层存储时再打开对象存储，而不是为了跑起来。
方向，而非已交付
因为事件本来就存在一个真正的可观测数据库里，PromQL 原生指标、logs ↔ traces 关联、OTLP 原生摄入、Flow 持续聚合都变得可达。这些记在 issue #8 里，是想法，不是今天能用的功能。
项目状态
Beta
拿真实负载去跑，遇到问题开 issue。这些反馈才是推动它走到稳定版的东西。
当前进度
ClickHouse → GreptimeDB 的迁移已经完成，读路径逐字节对齐上游，完整的 Langfuse 产品、API 和 SDK 面都能用。
已知限制
Known limitations 是一份很短的真实约束清单，外加少数与上游有意的差异。依赖它之前先扫一遍。
社区 fork
Openfuse 与 Langfuse 无隶属关系，也未获其背书，保留上游的版权与署名。
MIT
所有功能都是解锁的。没有企业版，没有商业 license key，没有藏在合同后面的能力。
FAQ
常见问题
需要改代码吗？
不需要。Openfuse 1.0.0-beta.1 基于上游 Langfuse v3.184.1，现有 Langfuse SDK 以及公共摄入 / REST API 都原样可用。任何 OpenTelemetry tracer 同样可用。
schema 迁移怎么做？
Postgres 迁移就是上游 Langfuse 的，原样执行。GreptimeDB 那套 schema 是 fork 特有的，在容器启动时自动迁移——幂等、用 advisory lock 串行化、失败即中止。
和上游 Langfuse 到底差在哪？
在覆盖到的查询面上，仪表盘和指标输出逐字节对齐上游。少数有意的差异——都是 fork 侧等价或更正确的情况——记在 parity ledger。完整兼容性声明见 migration-from-langfuse。
发布了哪些镜像？
三个，构建 linux/amd64 和 linux/arm64，每个 v* tag 推送一次：openfuse-web、openfuse-worker，以及 openfuse-standalone——web 和 worker 装在一个容器里，适合单机自托管。