Langfuse 4.68.0 常用 CLI 命令与工具详解
Langfuse v4.68.0 自托管实例日常运维 CLI 工具集详解：Docker Compose 编排、prisma 迁移管理、ClickHouse/PostgreSQL/Redis/MinIO 巡查、/api/public 摄取与查询 curl 实测、数据保留清理与摄取队列排障
Langfuse 4.68.0 常用 CLI 命令与工具详解
目标：整理 Langfuse v4.68.0 自托管实例的日常运维 CLI 工具集——Docker Compose 编排、容器内 prisma 迁移管理、ClickHouse 数据查询、PostgreSQL 业务核查、Redis 队列巡检、MinIO 对象管理、curl API 操作与数据保留清理，全部命令在 Ubuntu 22.04 实机逐条执行并采集真实回显。
一、环境信息
- 操作系统：Ubuntu 22.04（x86_64）；Docker Engine 29.8.1 + Compose v5.5.1
- 部署形态：compose 项目
langfuse-4.68.0-stack（部署过程见《Langfuse Docker Compose 部署指南》），六服务：langfuse-web:4.68.0 / langfuse-worker:4.68.0 / postgres:17 / clickhouse-server:25.12 / chainguard minio / redis:7 - 实例演示凭据：管理员
root@langfuse.local/q1w2e3r4；项目 API Keypk-lf-4ff4ca96909a5c6a1316:sk-lf-be93f07fe1be549f7b53693cee10e079；ClickHouseclickhouse:q1w2e3r4；Redis 口令q1w2e3r4redis；MinIOminio:q1w2e3r4minio；PostgreSQLpostgres:q1w2e3r4 - 端口（宿主侧）：Web 8146、Worker 3030、ClickHouse 18123、MinIO 19090、PostgreSQL 25432、Redis 26379
- Langfuse 自身无独立「langfuse 命令行」二进制：v4 的 CLI 运维面由「compose 编排 + 容器内自带工具 + 存储/队列原生客户端 + HTTP API」组合构成，本文按此组织
二、工具概览
| 工具 | 运行位置 | 用途 |
|---|---|---|
| docker compose | 服务器 shell | 栈编排：启停/日志/升级/重建 |
| prisma（v6.19.3，镜像自带） | langfuse-web 容器内 | 迁移状态核查、手工迁移、执行 SQL |
| clickhouse-client（镜像自带） | clickhouse 容器内 | 追踪宽表查询、迁移计数、行数巡检 |
| psql（镜像自带） | postgres 容器内 | 用户/项目/密钥/审计日志等业务表核查 |
| redis-cli（镜像自带） | redis 容器内 | 队列积压与键空间巡检 |
| mc（镜像自带） | minio 容器内 | 对象枚举与备份 |
| curl | 服务器 shell | 健康检查、OTLP/score 摄取、v2 查询 API |
💡 技术拓展：容器内自带工具 vs 服务器安装客户端——推荐优先用
docker compose exec <服务> <客户端>的方式（版本与服务端严格匹配、无需额外安装、免维护），服务器侧只保留 curl；若需长期直连，可另行在服务器安装与各组件版本匹配的独立客户端，但 ClickHouse 这类版本敏感组件务必避免用旧客户端连新服务端。
三、前置条件
- 全栈已按部署指南启动且健康：
cd /opt/langfuse && docker compose ps --format 'table {{.Name}}\t{{.Status}}'
实测回显：
NAME STATUS
langfuse-4680-stack-clickhouse-1 Up 56 seconds (healthy)
langfuse-4680-stack-langfuse-web-1 Up 50 seconds
langfuse-4680-stack-langfuse-worker-1 Up 50 seconds
langfuse-4680-stack-minio-1 Up 56 seconds (healthy)
langfuse-4680-stack-postgres-1 Up 56 seconds (healthy)
langfuse-4680-stack-redis-1 Up 56 seconds (healthy)
- 已摄取至少一条 trace（本文后续查询示例依赖部署指南 4.6 节摄取的
14a87e396596ce929e71fe5418ba6239）； - 知道各凭据（见环境信息）；建议把常用凭据写进服务器环境的受保护变量文件而非散落在历史命令里。
四、各工具详解
4.1 docker compose 编排命令
状态与日志（最常用的两条巡检命令）：
docker compose ps # 六服务状态与端口
docker compose logs -f langfuse-web # 跟踪 Web 日志（迁移/告警/启动错误都在这）
docker compose logs --tail 100 langfuse-worker # Worker 最近 100 行（摄取/评估/清理活动）
实测回显（worker 日志节选，text 格式默认形态）：
2026-10-22T21:29:32.652Z info Listening: http://f4505ee3ab31:3030
2026-10-22T21:29:32.682Z info [Background Migration] No background migrations to run
2026-10-22T21:29:32.682Z info MonitorRunner(1/1): published 0 events
改配置后的单服务重建（改了 compose environment 后只重建受影响服务，不惊动全栈）：
docker compose up -d langfuse-web # 只重建 web
docker compose up -d langfuse-worker # 只重建 worker
版本升级标准流程（改镜像标签 → 拉取 → 重建；迁移在 Web 容器启动时自动执行）：
# 1. 编辑 docker-compose.yml，把两个 langfuse 镜像标签 4.68.0 改为目标版本
# 2. 拉新镜像
docker compose pull
# 3. 滚动重建（依赖关系保证存储先就绪）
docker compose up -d
# 4. 确认迁移完成
docker compose logs langfuse-web | grep -E 'migrations found|up to date'
# 5. 回滚：把标签改回旧版本号重复 2-3 步（数据卷不动）
停栈与清栈：
docker compose down # 停止并删容器/网络，保留 5 个数据卷
docker compose down -v # ⚠️ 连数据卷一起删除（彻底清库重装用，不可恢复）
资源巡检：
docker stats --no-stream --format 'table {{.Name}}\t{{.MemUsage}}\t{{.CPUPerc}}'
实测回显（空载稳态）：
NAME MEM USAGE / LIMIT CPU %
langfuse-4680-stack-langfuse-web-1 674MiB / 31.3GiB 0.78%
langfuse-4680-stack-langfuse-worker-1 612.6MiB / 31.3GiB 0.38%
langfuse-4680-stack-postgres-1 79.03MiB / 31.3GiB 3.86%
langfuse-4680-stack-redis-1 6.086MiB / 31.3GiB 0.24%
langfuse-4680-stack-clickhouse-1 352.6MiB / 31.3GiB 5.32%
langfuse-4680-stack-minio-1 71.84MiB / 31.3GiB 3.75%
4.2 容器内 prisma CLI（迁移管理）
官方镜像自带 prisma 6.19.3，启动时 entrypoint 自动执行 prisma migrate deploy；日常运维主要用 migrate status 核查迁移一致性（升级后、迁移失败排查时）。
迁移状态核查：
docker compose exec langfuse-web sh -c \
'DIRECT_URL="$DATABASE_URL" prisma migrate status --schema=/app/packages/shared/prisma/schema.prisma'
实测回显：
Prisma schema loaded from packages/shared/prisma/schema.prisma
Datasource "db": PostgreSQL database "postgres", schema "public" at "postgres:5432"
460 migrations found in prisma/migrations
Database schema is up to date!
排障实录：不带 DIRECT_URL 直接执行会报错——entrypoint 只在启动进程里把 DIRECT_URL 默认成 DATABASE_URL，手工 exec 进去的 shell 没有这个变量：
Error: Prisma schema validation - (get-config wasm)
Error code: P1012
error: Environment variable not found: DIRECT_URL.
--> packages/shared/prisma/schema.prisma:16
|
15 | url = env("DATABASE_URL")
16 | directUrl = env("DIRECT_URL")
解决：命令前缀 DIRECT_URL="$DATABASE_URL"（如上例）。
版本核对：
docker compose exec langfuse-web prisma --version
实测回显（节选）：
prisma : 6.19.3
@prisma/client : 6.19.3
Computed binaryTarget : rhel-openssl-3.0.x
关闭自动迁移后的手工迁移：设 LANGFUSE_AUTO_POSTGRES_MIGRATION_DISABLED=true 的实例，升级时手工执行：
docker compose exec langfuse-web sh -c \
'DIRECT_URL="$DATABASE_URL" prisma migrate deploy --schema=/app/packages/shared/prisma/schema.prisma'
⚠️ 注意：
prisma migrate deploy只应用未执行的迁移（幂等、安全），禁止在 Langfuse 生产库使用prisma migrate reset（会清库）。
entrypoint 附带的 cleanup.sql：每次启动迁移前会先执行 /app/packages/shared/scripts/cleanup.sql（清理历史遗留迁移记录），内容实测如下（388 字节）：
DO $$
BEGIN
IF EXISTS (SELECT 1 FROM information_schema.tables WHERE table_name = '_prisma_migrations') THEN
DELETE FROM _prisma_migrations
WHERE migration_name IN ('20240606090858_pricings_add_latest_gemini_models', '20240530212419_model_price_anthropic_via_google_vertex', '20240604133340_backfill_manual_scores', '20260203220622_pending_deletions_object_id_idx');
END IF;
END $$;
4.3 ClickHouse 数据查询（追踪宽表）
追踪数据在 v4 落 ClickHouse default 库。所有查询经容器内 clickhouse-client：
库表清单：
docker compose exec clickhouse clickhouse-client \
--user clickhouse --password q1w2e3r4 --query "SHOW TABLES FROM default"
实测回显（18 张表）：
analytics_observations
analytics_scores
analytics_traces
audit_logs
blob_storage_file_log
dataset_run_items_rmt
events_core
events_core_mv
events_full
observations
observations_batch_staging
observations_pid_tid_sorting
schema_migrations
scores
topic_assignments
topic_facet_summaries
topics
traces
💡 说明：v4 数据模型下 OTLP 事件落在
events_full/events_core（新模型），traces/observations是 v3 兼容投影——空载时events_full有 1 行而 traces/observations 为 0 属正常，控制台读的是新模型。
行数巡检（三表对比，一屏看清数据分布）：
docker compose exec clickhouse clickhouse-client \
--user clickhouse --password q1w2e3r4 --multiquery --query \
"SELECT 'events_full' t, count() c FROM default.events_full
UNION ALL SELECT 'traces', count() FROM default.traces
UNION ALL SELECT 'observations', count() FROM default.observations
UNION ALL SELECT 'scores', count() FROM default.scores
FORMAT PrettyCompact"
实测回显：
┌─t────────────┬─c─┐
1. │ observations │ 0 │
2. │ events_full │ 1 │
3. │ traces │ 0 │
4. │ scores │ 2 │
└──────────────┴─c─┘
事件明细查询（按 trace_id 追一条记录）：
docker compose exec clickhouse clickhouse-client \
--user clickhouse --password q1w2e3r4 \
--query "SELECT trace_id, span_id, name, type, start_time FROM default.events_full WHERE trace_id='14a87e396596ce929e71fe5418ba6239' FORMAT PrettyCompact"
实测回显：
┌─trace_id─────────────────────────┬─span_id──────────┬─name──────────┬─type───────┬──────────start_time─┐
1. │ 14a87e396596ce929e71fe5418ba6239 │ 9ecab8c7ce7cfbc3 │ demo-llm-call │ GENERATION │ 2026-10-22 21:23:56 │
└──────────────────────────────────┴──────────────────┴───────────────┴────────────┴─────────────────────┘
评分明细（核对 UI 里两条演示评分已落库）：
docker compose exec clickhouse clickhouse-client \
--user clickhouse --password q1w2e3r4 \
--query "SELECT id, name, value, data_type FROM default.scores WHERE project_id='demo-project' ORDER BY created_at FORMAT PrettyCompact"
实测回显：
┌─id──────────────┬─name──────────┬─value─┬─data_type─┐
1. │ demo-score-0001 │ user-feedback │ 0.95 │ NUMERIC │
2. │ demo-score-0002 │ human-review │ 0.8 │ NUMERIC │
└─────────────────┴───────────────┴───────┴───────────┘
迁移计数（ClickHouse 侧迁移是否完整应用）：
docker compose exec clickhouse clickhouse-client \
--user clickhouse --password q1w2e3r4 \
--query "SELECT count() AS applied FROM default.schema_migrations"
实测回显：
106
4.4 PostgreSQL 业务核查（psql）
用户/组织/项目/API Key/审计日志等业务实体在 PostgreSQL postgres 库：
# 核心实体计数
docker compose exec postgres psql -U postgres -d postgres -tAc \
"SELECT 'users='||count(*) FROM users
UNION ALL SELECT 'organizations='||count(*) FROM organizations
UNION ALL SELECT 'projects='||count(*) FROM projects
UNION ALL SELECT 'api_keys='||count(*) FROM api_keys"
实测回显：
users=1
organizations=1
projects=1
api_keys=1
# 管理员与 API Key 核对（secret 只有哈希，明文只在创建时可见）
docker compose exec postgres psql -U postgres -d postgres -c \
"SELECT email, name, created_at FROM users;"
实测回显：
email | name | created_at
------------------------------+-------+----------------------------
root@langfuse.local | root | 2026-10-22 21:27:24.347668
(1 row)
# API Key 形态（hashed_secret_key 不可逆，display_secret_key 是打码预览）
docker compose exec postgres psql -U postgres -d postgres -c \
"SELECT public_key, display_secret_key, scope FROM api_keys;"
实测回显：
public_key | display_secret_key | scope
---------------------------+----------------------------------+---------
pk-lf-4ff4ca96909a5c6a1316 | sk-lf-0d64********************************c639 | PROJECT
(1 row)
⚠️ 注意：
sk-私钥入库即哈希（hashed_secret_key），任何人（包括 DBA）都无法从库里找回明文——丢了只能在控制台重建密钥。这也是部署时用 LANGFUSE_INIT_PROJECT_SECRET_KEY 显式固定演示密钥的原因。
4.5 Redis 队列巡检（redis-cli）
Worker 的任务队列是 BullMQ，队列健康度直接决定摄取延迟：
# 键空间规模
docker compose exec redis redis-cli -a q1w2e3r4redis --no-auth-warning dbsize
实测回显：
182
# 队列清单（bull: 前缀的 meta 键即队列名）
docker compose exec redis redis-cli -a q1w2e3r4redis --no-auth-warning --scan --pattern 'bull:*' | head -5
实测回显：
bull:ingestion-queue:meta
bull:v4-legacy-api-usage-queue:events
bull:data-retention-queue:events
bull:project-delete:meta
bull:experiment-create-queue:meta
💡 说明：
ingestion-queue（摄取）、data-retention-queue（数据保留清理）、experiment-create-queue（实验）等队列名与《Langfuse 4.68.0 配置参数详解》5.6 节的QUEUE_CONSUMER_*_IS_ENABLED开关一一对应——排障时先看积压（各队列的 waiting/active 计数）再决定是否扩 Worker 副本。
4.6 MinIO 对象管理（mc）
官方镜像内置 mc 客户端（健康检查也用它）：
# 配置别名（一次性）
docker compose exec minio mc alias set local http://127.0.0.1:9000 minio q1w2e3r4minio
实测回显：
Added `local` successfully.
# 递归枚举事件对象（S3 落盘核对）
docker compose exec minio mc ls --recursive local/langfuse
实测回显（摄取 1 条 OTLP 后）：
[2026-10-22 21:23:57 UTC] 686B STANDARD events/otel/demo-project/2026/10/22/21/23/2901dedb-fb44-4d68-9bbe-b42445ad7971.json
对象键规律：<LANGFUSE_S3_EVENT_UPLOAD_PREFIX>otel/<项目ID>/<年>/<月>/<日>/<时>/<uuid>.json，与《Langfuse 4.68.0 配置参数详解》5.5 节的 S3 前缀配置直接对应。备份整桶：
docker compose exec minio mc mirror local/langfuse /backup/langfuse-objects
4.7 curl：健康检查与 API 操作
健康与就绪：
curl -s http://localhost:8146/api/public/health # Web（公开端点，无鉴权）
curl -s http://localhost:3030/api/health # Worker
实测回显：
{"status":"OK","version":"4.68.0"}
{"status":"ok"}
v4 摄取模型实测（默认 LANGFUSE_MIGRATION_V4_WRITE_MODE=events_only）：
旧路径发 trace 已不可用（部署指南 Q3 实录返回 400），正确的三条路径如下。
路径一：trace/observation 一律走 OpenTelemetry：
curl -s -u 'pk-lf-4ff4ca96909a5c6a1316:sk-lf-be93f07fe1be549f7b53693cee10e079' \
-X POST http://localhost:8146/api/public/otel/v1/traces \
-H 'Content-Type: application/json' \
-d '{"resourceSpans":[{"resource":{"attributes":[{"key":"service.name","value":{"stringValue":"demo-service"}}]},"scopeSpans":[{"scope":{"name":"demo-instrumentation"},"spans":[{"traceId":"14a87e396596ce929e71fe5418ba6239","spanId":"9ecab8c7ce7cfbc3","name":"demo-llm-call","kind":1,"startTimeUnixNano":"1761173037000000000","endTimeUnixNano":"1761173038500000000","attributes":[{"key":"langfuse.span.type","value":{"stringValue":"GENERATION"}}],"status":{"code":1}}]}]}]}'
实测回显（节选，入队确认）：
{"name":"otel-ingestion-job","data":{"id":"a74116af-fef2-41b7-9e6c-481a6526e3e2","timestamp":"2026-10-22T21:23:57.030Z","name":"otel-ingestion-job","payload":{"data":{"fileKey":"events/otel/demo-project/2026/10/22/21/23/2901dedb-fb44-4d68-9bbe-b42445ad7971.json","publicKey":"pk-lf-4ff4ca96909a5c6a1316"},...
路径二：ingestion 端点仍可用，但只收 score 事件：
curl -s -u 'pk-lf-4ff4ca96909a5c6a1316:sk-lf-be93f07fe1be549f7b53693cee10e079' \
-X POST http://localhost:8146/api/public/ingestion \
-H 'Content-Type: application/json' \
-d '{"batch":[{"id":"demo-score-0001","type":"score-create","timestamp":"2026-10-22T21:31:00.000Z","body":{"id":"demo-score-0001","traceId":"14a87e396596ce929e71fe5418ba6239","name":"user-feedback","value":0.95,"dataType":"NUMERIC","comment":"demo score"}}]}'
实测回显：
{"successes":[{"id":"demo-score-0001","status":201}],"errors":[]}
路径三：直发评分端点（等价于路径二的单发形态）：
curl -s -u 'pk-lf-4ff4ca96909a5c6a1316:sk-lf-be93f07fe1be549f7b53693cee10e079' \
-X POST http://localhost:8146/api/public/scores \
-H 'Content-Type: application/json' \
-d '{"id":"demo-score-0002","traceId":"14a87e396596ce929e71fe5418ba6239","name":"human-review","value":0.8,"dataType":"NUMERIC","timestamp":"2026-10-22T21:32:00.000Z"}'
实测回显：
{"id":"demo-score-0002"}
v2 查询 API（v4 新增；旧版 GET /api/public/traces、/api/public/observations、GET /api/public/scores 在 events_only 模式下均返回「This endpoint is not available」错误，查询一律走 v2）：
curl -s -u 'pk-lf-4ff4ca96909a5c6a1316:sk-lf-be93f07fe1be549f7b53693cee10e079' \
'http://localhost:8146/api/public/v2/observations'
实测回显（节选）：
{"data":[{"id":"9ecab8c7ce7cfbc3","traceId":"14a87e396596ce929e71fe5418ba6239","startTime":"2026-10-22T21:23:56.998Z","endTime":"2026-10-22T21:23:58.498Z","projectId":"demo-project","parentObservationId":null,"type":"GENERATION","name":"demo-llm-call","level":"DEFAULT","statusMessage":"","version":"","environment":"default","latency":1.5,"timeToFirstToken":null,"userId":"","sessionId":"","isRootObservation":true,...
4.8 数据保留与清理
Langfuse 的数据保留有两层，均为控制台配置 + Worker 后台执行，CLI 侧负责核查：
- 项目级 Data Retention（控制台 Project Settings 配置保留天数，Worker 的
data-retention-queue定期执行软删）； - 删除执行器：批量删除由
TraceDeleteBatchActionRunner周期执行（默认 10 秒一轮、锁 TTL 1800 秒、每轮最多 5 批，参数见《Langfuse 4.68.0 配置参数详解》5.3 节），ClickHouse 侧由 deleted mask cleaner 清理已删位图。
CLI 核查手段：
# Worker 日志中过滤删除执行器活动
docker compose logs langfuse-worker 2>&1 | grep -i 'TraceDeleteBatchActionRunner' | tail -3
实测回显（debug 级别下的完整闭环：加锁 → 无任务 → 放锁）：
{"langfuse.clickhouse.route":"langfuse.periodic_runner.trace_delete_batch_action_runner",...,"message":"[TraceDeleteBatchActionRunner] Acquired lock with TTL 1800s",...}
{"langfuse.clickhouse.route":"langfuse.periodic_runner.trace_delete_batch_action_runner",...,"message":"TraceDeleteBatchActionRunner: No active trace delete actions",...}
{"langfuse.clickhouse.route":"langfuse.periodic_runner.trace_delete_batch_action_runner",...,"message":"[TraceDeleteBatchActionRunner] Released lock",...}
# 队列层面确认数据保留队列存在
docker compose exec redis redis-cli -a q1w2e3r4redis --no-auth-warning --scan --pattern 'bull:data-retention*'
实测回显：
bull:data-retention-queue:events
清理盘面空间（保留策略删除后，对象存储与 ClickHouse 的物理回收核查）：
docker compose exec minio sh -c 'du -sh /data/langfuse' # 对象体积
docker compose exec clickhouse clickhouse-client \
--user clickhouse --password q1w2e3r4 \
--query "SELECT table, formatReadableSize(sum(bytes)) size FROM system.parts WHERE active AND database='default' GROUP BY table ORDER BY sum(bytes) DESC LIMIT 5 FORMAT PrettyCompact"
实测回显（空载实例，ClickHouse 各表物理占用极小）：
┌─table──────────────┬─size─────┐
│ observations │ 0.00 B │
...
五、注意事项
- 读写分离视角：日常「看数据」优先控制台与
/api/public/v2/*；ClickHouse/psql 直查仅用于排障与审计，表结构属内部实现，升级可能变化，不要在直查结果上建自动化流程； - prisma 手工命令必须带
DIRECT_URL="$DATABASE_URL"前缀（4.2 排障实录）； - secret key 不可找回：丢了重建，勿在多个项目复用同一 sk；
- docker compose down -v 是唯一危险命令：会删除全部数据卷；执行前先
mc mirror+pg_dump+clickhouse backup三路备份； - 日志排障优先级：Web 日志（迁移/配置错误）→ Worker 日志（摄取/清理）→ Redis 队列积压 → ClickHouse 查询，绝大多数问题在前两层定位。
六、常见问题
Q1：docker compose exec langfuse-web prisma ... 报 P1012 找不到 DIRECT_URL？
见 4.2 排障实录：手工 exec 的 shell 不继承 entrypoint 的运行时导出，加前缀 DIRECT_URL="$DATABASE_URL"。
Q2：v4 里还能用 GET /api/public/traces 拉数据吗？
events_only 默认模式下不能（返回 "This endpoint is not available on deployments running in Langfuse v4 events_only mode"）。查询走 v2 端点：GET /api/public/v2/observations、GET /api/public/v2/metrics；写入走 OTLP（trace）与 score 端点。
Q3：摄取后 ClickHouse 查不到数据？
摄取是异步的：Web 收到请求只确认入队（返回 otel-ingestion-job 回执），Worker 按批量周期写 ClickHouse，实测 10 秒左右可见；先看 Worker 日志有无报错，再查 MinIO 对象是否生成（对象在、表里没有 = Worker 写入或迁移问题）。
Q4：升级后 ClickHouse 兼容性告警怎么看？
启动日志的 Resolved ClickHouse compatibility from version 段会输出 computedCompatibilityFlags（每个 flag 带版本区间与原因），例如 25.12.11.4 自动应用 disable-lazy-materialization-for-patch-parts 绕过上游缺陷；按日志建议的版本区间规划 ClickHouse 升级即可。
Q5：迁移中途失败（Applying database migrations failed）怎么处理？
按官方 entrypoint 的提示顺序排查：依赖服务健康度（docker compose ps 看 healthy）→ 凭据特殊字符（官方内置 HINT 会提示 P1013 与百分号编码）→ 修复后重启 Web 容器自动重放迁移（migrate deploy 幂等）。
七、参考链接
- 官方自托管文档：https://langfuse.com/docs/deployment/self-hosting
- 官方 OpenAPI 定义（API 端点依据）：https://raw.githubusercontent.com/langfuse/langfuse/main/fern/apis/server/definition/observations.yml
- Prisma migrate 命令参考：https://www.prisma.io/docs/orm/prisma-client/deployment/deploy-database-changes-with-prisma-migrate
- 本专栏系列：《Langfuse Docker Compose 部署指南》（部署实录）、《Langfuse 4.68.0 配置参数详解》（参数依据）、《Langfuse 介绍与选型指南》（架构与选型）