ガイド

著者 Matt Connor 2026-08-03 ・更新日 2026-08-07

Langfuseをセルフホストする方法と必要なVPS性能

Q: データ保持期間を設定した後も ClickHouse のディスク使用量が増え続けるのはなぜですか？

保持期間の設定が対象にするのは、Langfuse 自身のデータだけです。ClickHouse は診断用テーブル trace_log、text_log、opentelemetry_span_log、metric_log、asynchronous_metric_log も個別に書き込みます。これらには TTL が設定されていません。テーブルごとに system.parts をグループ化して実行し、最大のテーブルを確認してください。その後、/etc/clickhouse-server/config.d/ 配下のファイルに remove="1" エントリを追加して未使用のテーブルを無効にし、ClickHouse を再起動します。すでに使用された領域を解放するには、既存のテーブルも削除してください。

Langfuse v4を自分のVPSで運用する手順です。必要なリソースの下限、固定するイメージタグ、TLS、ClickHouseの保持期間、ディスク枯渇を防ぐ設定、実際に復元できるバックアップを確認します。

AI エージェントをトレースする理由

Langfuse を自分でホスティングすると、エージェントが実行時に実際に何をしたかを確認できます。Langfuse は、オープンソースの LLM（大規模言語モデル）オブザーバビリティツールです。すべてのプロンプト、モデルの応答、ツール呼び出し、トークンを記録し、それらを 1 つのトレースにまとめます。トレースは開いて内容を確認できます。自分で管理する VPS 上で実行すれば、これらのプロンプトが自分の管理下にないサーバーへ送信されることはありません。

導入する理由は明確です。確認できないコスト問題や品質問題は修正できません。プロバイダーの請求書からは、火曜日のコストが月曜日の 4 倍だったことは分かります。トレースからは、どのエージェント実行が原因だったか、どのプロンプトが 40,000 トークンまで増えたか、どの再試行ループが諦めるまでに 9 回実行されたかが分かります。請求書が示すのは数値です。トレースが示すのは、その数値を生み出したコードです。

このガイドでは、3 つの用語を使用します。トレースは、エージェントの開始から終了までの 1 回の実行です。オブザベーションは、その実行内の 1 つのステップです。通常のコードには span、モデル呼び出しには generation が該当します。スコアは、人によるレビューまたは自動評価によってトレースに付与される数値です。Langfuse は、分散トレーシングのベンダー中立な標準である OpenTelemetry（OTel）に対応しています。そのため、すでに導入している計装から Langfuse にデータを送信できます。

セルフホストする Langfuse で実際に稼働するもの

Langfuse v4 は 1 つのコンテナではありません。2 つのアプリケーションコンテナと 4 つのストレージサービスで構成され、単一の VPS では 6 つすべてがサーバー上で稼働します。

langfuse-web は Web インターフェースと取り込み API を提供します。
langfuse-worker はバックグラウンドでキューを処理します。取り込みバッチを解析し、コストを計算し、夜間の保持ジョブを実行します。
Postgres は、ユーザー、組織、プロジェクト、API keys、prompts などのトランザクションデータを保持します。
ClickHouse は、observation と score からなる trace データそのものを保持します。分析クエリ向けに構築されたカラム型データベースであるため、1 億行を超えるデータに対するダッシュボードの応答も高速です。
Redis は、web と worker の間に配置されるキューおよびキャッシュです。
MinIO は、サーバー上で S3 compatible object storage を提供します。受信したすべての raw event と、添付したメディアを保持します。

Langfuse は、処理を担う 3 つのコンポーネントについて最小リソースを公開しています。

ChartLangfuse published minimum resources per component

label

cpu_cores

memory_gib

ClickHouse

Langfuse web

Langfuse worker

The data behind this chart

[
  {
    "label": "ClickHouse",
    "cpu_cores": 2,
    "memory_gib": 8
  },
  {
    "label": "Langfuse web",
    "cpu_cores": 2,
    "memory_gib": 4
  },
  {
    "label": "Langfuse worker",
    "cpu_cores": 2,
    "memory_gib": 4
  }
]

ClickHouse だけで 8 GiB のメモリが必要です。web container と worker は、それぞれ 4 GiB を必要とします。これは Langfuse がリソースを算定している 3 コンポーネントの公開最小値です。さらに Postgres、Redis、MinIO にもメモリが必要です。プロジェクトの Docker Compose ガイドが 4 cores、16 GiB のメモリ、約 100 GiB のストレージを備えたマシンを推奨しているのは、この計算に余裕を加えたものではなく、計算結果と一致するためです。

2 GiB のプランでは実行しないでください。ClickHouse は起動してしばらく書き込みを受け付けますが、background merge 中に停止します。merge ではテーブルの大きな part がメモリに読み込まれるためです。docker compose ps には clickhouse container が restarting と表示され、dmesg には Out of memory: Killed process 1234 (clickhouse-serv) のような行が記録され、Langfuse のすべてのダッシュボードが 500 を返すようになります。負荷が比較的軽い場合、ClickHouse は代わりにクエリを拒否し、DB::Exception: Memory limit (total) exceeded をログに記録します。1 日に数千件の trace を送信する 1 人の開発者であれば、8 GiB でも運用できます。計画上は 16 GiB を見込んでください。

Docker Compose で Langfuse をデプロイする

リポジトリをクローンします。スタック、各サービスの接続設定、デフォルト環境は docker-compose.yml にすべて含まれています。

git clone https://github.com/langfuse/langfuse.git
cd langfuse

変更が必要な値には、そのファイル内で # CHANGEME のマークが付いています。まず、3 つのアプリケーションシークレットを生成します。

openssl rand -base64 32   # NEXTAUTH_SECRET
openssl rand -base64 32   # SALT
openssl rand -hex 32      # ENCRYPTION_KEY

ENCRYPTION_KEY は 64 個の 16 進数文字で記述した 256 ビットである必要があります。これは openssl rand -hex 32 が出力する形式と一致します。この値は、インスタンスに保存する LLM プロバイダーのキーなど、保存時の機密値を暗号化します。データが存在した後に変更すると、該当する行を復号できなくなります。そのため、初回起動時から永続的な値として扱ってください。SALT は Langfuse API キーのハッシュ化に使用されます。変更すると、エージェントがすでに使用しているすべてのキーが無効になります。

次に、POSTGRES_PASSWORD、CLICKHOUSE_PASSWORD、REDIS_AUTH、MINIO_ROOT_PASSWORD を設定します。MinIO のパスワードは 4 箇所に記述されています。1 箇所目が MINIO_ROOT_PASSWORD で、その後に LANGFUSE_S3_EVENT_UPLOAD_SECRET_ACCESS_KEY、LANGFUSE_S3_MEDIA_UPLOAD_SECRET_ACCESS_KEY、LANGFUSE_S3_BATCH_EXPORT_SECRET_ACCESS_KEY として再度記述されています。1 箇所でも漏れると、MinIO はそのクライアントを SignatureDoesNotMatch で拒否します。このエラーは worker のログに記録されますが、Web インターフェースは正常に見えます。これらの値を追跡対象の compose ファイルではなく env ファイルに保持する方法については、Docker Compose の env ファイルとシークレットで説明しています。

起動前にイメージタグを固定する

配布されたファイルでは langfuse/langfuse:4 と langfuse/langfuse-worker:4 が使用されています。これらのタグは更新されます。Langfuse は起動時に Postgres と ClickHouse のマイグレーションを自動実行します。そのため、数か月後の通常の docker compose pull が、同じ朝にバックアップしていないデータベースに対する、予定外のスキーママイグレーションになる可能性があります。両方を docker-compose.override.yml で同じリリースに固定します。Compose はこれを配布ファイルの上に適用するため、後の git pull によって編集内容が上書きされることはありません。

services:
  langfuse-web:
    image: docker.io/langfuse/langfuse:4.3.1
  langfuse-worker:
    image: docker.io/langfuse/langfuse-worker:4.3.1

2026 年 8 月時点では、4.3 リリースの最新版は 4.3.1 でした（その後 4.4.0 がリリースされています）。プロジェクトの GitHub releases ページを確認し、デプロイ当日に最新のバージョンを固定してください。その後は、その番号を意図的に更新します。配布されたファイルのストレージイメージは、すでにメジャーバージョンで固定されています。対象は postgres:17、clickhouse-server:25.12、redis:7 です。これらも同じように固定してください。

起動します。

docker compose up -d
docker compose ps
docker compose logs -f langfuse-worker

初回起動ではマイグレーションが実行されます。何らかの応答が返るまで 1〜2 分待ってください。docker compose ps の結果には、状態 running のサービスが 6 つ表示されるはずです。worker が再起動を繰り返す場合は、ログに原因が記録されています。CLICKHOUSE_MIGRATION_URL はポート 9000 の ClickHouse native protocol を使用します。HTTP ポート 8123 を指定すると失敗しますが、web コンテナは正常に見えます。

ホスト自身からヘルス状態を確認します。

curl -s "http://localhost:3000/api/public/health?failIfDatabaseUnavailable=true"
curl -s -o /dev/null -w '%{http_code}\n' http://localhost:3000/api/public/ready

通常の /api/public/health 呼び出しで確認できるのは、API プロセスが稼働していることだけです。これは、Postgres が一時的に停止してもサービスが提供を継続できるよう、データベースの確認を意図的に省略するためです。監視対象にする価値があるのは failIfDatabaseUnavailable=true 形式です。データベースに接続できない場合は 503 を返します。/api/public/ready はマイグレーション完了後に 200 を返し、コンテナがトラフィックを受け付けられる状態であることを示します。どちらも通常の HTTP チェックです。そのため、Uptime Kuma のステータスページで監視し、エージェントより先にスタックの停止を検知できます。

TLS を前段に置き、不要なポートを閉じる

配布されている compose ファイルでは、Web コンテナ用に 3000:3000、MinIO 用に 9090:9000 が公開されています。どちらもすべてのインターフェースで待ち受けます。パブリック IP で運用すると、ポート 3000 をスキャンした相手はサインアップページに到達でき、9090 をスキャンした相手は生のプロンプトを格納するバケットに接続できます。

ファイアウォールルールだけでは、これらのポートは閉じません。Docker は nat テーブルに独自の DNAT ルールを書き込みます。これらのルールは、パケットが ufw の filter ルールで処理される前に評価されます。そのため、ufw deny 3000 を設定しても公開ポートは開いたままです。この問題に遭遇する利用者が多いため、Docker の公開ポートが ufw を回避する理由という専用ガイドがあります。代わりに、override ファイルで loopback にバインドしてください。

services:
  langfuse-web:
    ports:
      - "127.0.0.1:3000:3000"
    environment:
      NEXTAUTH_URL: https://langfuse.example.com
  minio:
    ports:
      - "127.0.0.1:9090:9000"
      - "127.0.0.1:9091:9001"

NEXTAUTH_URL には、スキームを含む正確な公開アドレスを指定する必要があります。ログインフローは、この値からコールバック URL を生成するためです。HTTPS プロキシの背後で http://localhost:3000 のままにすると、サインインの往復処理でブラウザーが到達できない場所へ移動します。

次に、リバースプロキシを 127.0.0.1:3000 に向け、証明書をプロキシで管理します。同じ Compose プロジェクト内の Traefik が通常の選択肢です。ルーティングラベルについては、1 台の Traefik リバースプロキシで複数のアプリを運用するで説明しています。Langfuse だけをこのホストで運用する場合は、Caddy でも 2 行で同じことができます。curl -sI https://langfuse.example.com/api/public/ready で確認し、別のマシンから curl http://YOUR_IP:3000 がタイムアウトすることも確認してください。

MinIO には注意点があります。Langfuse は、S3 エンドポイントを指す presigned URL を使って、添付メディアをブラウザーに配信します。そのため、画像や音声を含むマルチモーダルトレースを使う場合、loopback のみで待ち受ける MinIO では添付ファイルを読み込めません。プロキシを設定する前に blob storage の設定ページを確認してください。presigned URL に書き込まれるエンドポイントは、公開するエンドポイントと一致する必要があります。プレーンテキストのトレースには影響しません。

最初のアクセス時にアカウントを作成し、そのインスタンスを自分で管理できる状態にしてください。LANGFUSE_ALLOWED_ORGANIZATION_CREATORS には自分のメールアドレスを設定します。これにより、ページに到達した第三者があなたのサーバー上に組織を作成することを防げます。

最初のトレースを送信する

Web インターフェースでプロジェクトを作成し、プロジェクト設定から公開キーと Secret キーをコピーします。Python SDK は3つの環境変数を読み取ります。

export LANGFUSE_PUBLIC_KEY="pk-lf-..."
export LANGFUSE_SECRET_KEY="sk-lf-..."
export LANGFUSE_BASE_URL="https://langfuse.example.com"

LANGFUSE_BASE_URLは2026年3月にリリースされた SDK v4 の変数名です。古いコードや古いガイドではLANGFUSE_HOSTが使われています。トレースがサーバーではなく Langfuse Cloud に送られる場合、原因はベース URL が未設定であることです。未設定の場合、ホストされたインスタンスがデフォルトで指定されます。

pip install langfuse opentelemetry-instrumentation-anthropic anthropic

import os
from anthropic import Anthropic
from langfuse import get_client, observe
from opentelemetry.instrumentation.anthropic import AnthropicInstrumentor

AnthropicInstrumentor().instrument()
langfuse = get_client()
client = Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])

@observe(as_type="tool")
def lookup_order(order_id: str) -> str:
    return f"order {order_id}: shipped"

@observe()
def handle_request(question: str) -> str:
    context = lookup_order("A-1042")
    message = client.messages.create(
        model="claude-haiku-4-5",
        max_tokens=512,
        messages=[{"role": "user", "content": f"{context}\n\n{question}"}],
    )
    return message.content[0].text

if __name__ == "__main__":
    assert langfuse.auth_check()
    print(handle_request("Where is my order?"))
    langfuse.flush()

@observeデコレーターは関数の周囲にオブザベーションを作成し、引数と戻り値を取得します。すでにアクティブなオブザベーションがある場合は、その下にネストします。AnthropicInstrumentorは Anthropic クライアント用の OpenTelemetry インストルメンテーションです。各messages.create呼び出しを、モデル名、トークン使用量、レイテンシを含む generation に変換します。呼び出し箇所を変更する必要はありません。

2つの呼び出しで確認できます。langfuse.auth_check()は、キーが無効な場合やベース URL が誤っている場合に False を返します。ダッシュボードが空の理由を調べ続けるよりも迅速です。langfuse.flush()はキューに入ったスパンが送信されるまでブロックします。短時間で終了するプロセスでは必要です。SDK はバックグラウンドでバッチ処理するため、スクリプトがすぐに終了すると未送信のバッチも失われます。

ClickHouse のデータが増え続けるのはなぜですか？

トレースは、多くの人が self-host するデータの中で最も速く増えます。エージェントが 1 回実行されるたびにステップごとに 1 行が書き込まれ、入力と出力も完全な形で保存されます。そのため、プロンプトが長く、ログの多いエージェントは、監視対象のアプリケーションよりも 1 日あたりのデータ量がはるかに多くなります。放置すると ClickHouse がディスクを使い切り、ディスクが満杯になると取り込みは遅くなるのではなく停止します。

ここでは、増加するものが 2 つあり、それぞれに別の対策が必要です。

1 つ目は独自のトレースデータです。対策は retention 設定です。Web インターフェースでプロジェクト設定を開き、データ保持期間を日数で設定します。Langfuse では最短 3 日を指定できます。その後、夜間ジョブが保持期間より古いトレース、observations、scores、メディアアセットを選択し、ClickHouse と blob storage から削除します。このジョブにはバケットへの DeleteObject 権限が必要です。デフォルトの compose ファイルにある MinIO の root credentials には、すでにこの権限があります。削除したデータは復元できないため、長期保存が必要な場合は、先に blob storage へのエクスポートを設定してください。Langfuse 自身のテーブルに TTL 句を手動で記述しないでください。ClickHouse とバケットの状態を一致させるのは retention job であり、手動の TTL では片方だけが削除されます。

実際の利用状況に基づいて保持期間を選択してください。コストや品質の確認に使うのは、数か月前のデータではなく、数日前のデータです。小規模なチームなら 30 日から始めるのが妥当です。問題が発生したときだけトレースを確認するなら、14 日で十分です。

2 つ目は ClickHouse 自身の system log テーブルです。retention を設定した後もディスク使用量が増え続けるため、これが原因だと気付かない人もいます。ClickHouse は診断情報として trace_log、text_log、opentelemetry_span_log、metric_log、asynchronous_metric_log を書き込みます。これらには TTL が設定されておらず、Langfuse が読み取ることもありません。まず、実際にどこでディスクを消費しているかを確認してください。

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
)

docker compose exec clickhouse clickhouse-client --password "$CLICKHOUSE_PASSWORD" を付けて実行します。system テーブルが上位にある場合は、設定オーバーレイで無効にしてください。ClickHouse は起動時に /etc/clickhouse-server/config.d/ 内のすべてのファイルをメイン設定にマージします。

<clickhouse>
    <trace_log remove="1"/>
    <text_log remove="1"/>
    <opentelemetry_span_log remove="1"/>
    <asynchronous_metric_log remove="1"/>
    <metric_log remove="1"/>
</clickhouse>

これをマウントして ClickHouse を再起動します。

services:
  clickhouse:
    volumes:
      - ./clickhouse-config.d/system-logs.xml:/etc/clickhouse-server/config.d/system-logs.xml:ro

これで新しい書き込みは停止します。すでにディスク上にある行は残るため、DROP TABLE IF EXISTS system.trace_log で明示的に領域を解放し、削除した各テーブルにも同じ操作を行ってください。診断情報を保持したい場合は、remove="1" の代わりに各テーブルへ積極的な TTL を設定する方法もあります。Langfuse の scaling ドキュメントにその方法が記載されています。

もう 1 つ、把握しておくべきテーブルがあります。blob_storage_file_log は、バケットにアップロードされたイベントファイルを追跡します。バケットにも lifecycle policy を設定する場合は、テーブルにも対応する TTL を設定し、両者の状態がずれないようにしてください。

ALTER TABLE blob_storage_file_log MODIFY TTL created_at + INTERVAL 30 DAY DELETE;

データディスクには、単純な df -h アラートも設定してください。トレースは一定のペースで増えるとは限りません。新しいエージェントをリリースした日に急増します。その最初の兆候が、取り込みの失敗にならないようにしてください。

Postgres と ClickHouse をバックアップする

Langfuse のバックアップは 3 つの部分で構成されます。Postgres にはユーザー、組織、プロジェクト、API key が保存されます。ClickHouse にはトレースが保存されます。MinIO には生イベントが保存されます。Postgres だけを復元すると、ログインはできても履歴がない状態になります。ClickHouse だけを復元すると、誰もログインして確認できない履歴だけが残ります。

Postgres は単純な pg_dump であり、Langfuse のバックアップドキュメントでも推奨されています。

docker compose exec -T postgres pg_dump -U postgres postgres \
  | gzip > langfuse-pg-$(date +%F).sql.gz

ClickHouse では、マージ実行中にライブデータディレクトリをコピーすると、一貫性のあるバックアップにならないため、より慎重な対応が必要です。1 台のホストであれば、コンテナを停止してボリュームをアーカイブする方法が簡単です。

docker compose stop clickhouse
docker volume ls | grep clickhouse
docker run --rm -v langfuse_langfuse_clickhouse_data:/data -v "$PWD":/backup alpine \
  tar czf /backup/langfuse-ch-$(date +%F).tar.gz -C /data .
docker compose start clickhouse

YAML に記載された名前ではなく、docker volume ls が表示するボリューム名を使用してください。ファイルでは langfuse_clickhouse_data と宣言されていますが、Compose がプロジェクト名を付けるため、langfuse というディレクトリでクローンすると langfuse_langfuse_clickhouse_data になります。ここを間違えると、docker run はエラーを出さずに新しい空のボリュームを作成し、アーカイブには何も入りません。

Web コンテナは受信した各イベントを worker が処理する前にバケットへ書き込むため、ClickHouse を短時間停止しても、主に worker が後で再試行するだけです。利用の少ない時間帯に実施し、停止時間を短くしてください。より負荷の高いインスタンスでは、ClickHouse 独自の BACKUP DATABASE default TO S3(...) 文を使用すると、サーバーを停止せずに一貫性のあるバックアップを作成できます。MinIO が 3 つ目の構成要素であり、mc mirror または MinIO のオフホストバケットへのレプリケーションで対応できます。作成したバックアップは必ずサーバー外へ移してください。VPS 上の暗号化された restic バックアップはそのために使用します。

Redis のバックアップは必要ありません。Redis はキューとキャッシュを保持しているため、失うのは処理中のイベントだけで、過去のデータは失われません。

一貫性に関する注意点は実際に存在するため、明確にしておく必要があります。Postgres と ClickHouse は異なる時点でダンプされるため、復元後にトレースのないプロジェクト行が残ったり、すでに存在しないプロジェクトに属するトレースが残ったりする可能性があります。Langfuse はこの状態を許容しますが、両方のダンプはできるだけ近い時点で、トラフィックの少ない時間帯に取得してください。イベントバケットが実質的な安全網になります。Langfuse は受信した各イベントを処理前にそこへ永続化するためです。

少なくとも 1 回はスクラッチ環境へ復元してください。これにより、障害発生中ではなく、今の段階で誤ったボリューム名に気付けます。

最初に確認する項目

最初の 1 週間で確認する価値がある項目は 4 つです。

トレースあたりのコスト。 Langfuse はモデル名とトークン使用量からコストを計算します。トレースをコスト順に並べ、最も高額なものを最初から最後まで読みます。原因は通常、肥大化したプロンプトです。文書全体をコンテキストに貼り付けているか、誰も整理していない会話履歴を渡している可能性があります。原因を確認できれば、AI エージェントのコストを制御する方法は推測ではなく、エンジニアリング上の作業になります。
入力と出力に分けたトークン使用量。 入力トークンは多く低コストで、出力トークンは少ないものの高コストです。キャッシュされた入力はさらに低コストです。同じ料金計算の詳細は Claude Code のトークン使用量の数え方で説明しており、自作するエージェントにも適用できます。
レイテンシのパーセンタイル。 中央値では問題が隠れます。タイムアウトは p95 と p99 に現れます。エージェントループ内では、p95 の遅いツール呼び出しが反復回数分だけ積み重なります。
失敗したツール呼び出し。 レベル ERROR でオブザベーションを絞り込みます。5% の確率で失敗するツールは、全体の成功率では見えません。しかしトレースでは、モデルが再試行し、その回避処理でトークンを消費する様子を確認できます。

保持期間を設定し、毎週同じ曜日に確認するダッシュボードをデプロイ日に決めます。誰も開かないオブザーバビリティツールは、ディスクを使い切るデータベースです。

FAQ

セルフホストの Langfuse にはどれだけのメモリが必要ですか？

4 CPU コア、16 GiB のメモリ、約 100 GiB のストレージを見込んでください。これは、1 台の仮想マシンを使用する場合に Langfuse の Docker Compose ガイドが推奨する構成です。公開されている各コンポーネントの最小要件は、ClickHouse が 8 GiB、web コンテナと worker コンテナがそれぞれ 4 GiB です。これに加えて、Postgres、Redis、MinIO にもメモリが必要です。8 GiB なら 1 人の開発者用インスタンスを実行できます。2 GiB では実行できません。バックグラウンドマージ中に ClickHouse がカーネルによって強制終了され、dmesg に Out of memory: Killed process が表示されます。

データ保持期間を設定した後も ClickHouse のディスク使用量が増え続けるのはなぜですか？

保持期間の設定が対象にするのは、Langfuse 自身のデータだけです。ClickHouse は診断用テーブル trace_log、text_log、opentelemetry_span_log、metric_log、asynchronous_metric_log も個別に書き込みます。これらには TTL が設定されていません。テーブルごとに system.parts をグループ化して実行し、最大のテーブルを確認してください。その後、/etc/clickhouse-server/config.d/ 配下のファイルに remove="1" エントリを追加して未使用のテーブルを無効にし、ClickHouse を再起動します。すでに使用された領域を解放するには、既存のテーブルも削除してください。

Langfuse の最小データ保持期間はどれくらいですか？

3 日間です。保持期間はプロジェクト設定または projects API でプロジェクトごとに設定します。夜間ジョブが、保持期間より古い traces、observations、scores、media assets を ClickHouse と blob storage の両方から削除します。削除は元に戻せないため、その期間を超える履歴が必要な場合は、先に blob storage へのエクスポートを設定してください。

Postgres と ClickHouse の両方をバックアップする必要がありますか？

はい。両者が異なるデータを保持しているためです。Postgres には users、organisations、projects、API keys が保存され、ClickHouse には trace データそのものが保存されます。Postgres だけを復元すると、ログインはできてもデータがないインスタンスになります。MinIO バケットもバックアップしてください。ここには、Langfuse が受信時に永続化する raw events が保存されており、このスタックにおける source of truth に最も近いデータだからです。

既存の OpenTelemetry 構成をセルフホストの Langfuse に接続できますか？

はい。Langfuse v4 とその v4 SDK は OpenTelemetry を基盤としており、Anthropic と OpenAI の OTel instrumentation は Langfuse に直接エクスポートできます。Python では pip install langfuse opentelemetry-instrumentation-anthropic を実行し、起動時に AnthropicInstrumentor().instrument() を 1 回呼び出します。LANGFUSE_PUBLIC_KEY、LANGFUSE_SECRET_KEY、LANGFUSE_BASE_URL には自身のホストを設定してください。ダッシュボードが見つからない場合は、まず langfuse.auth_check() で接続を確認してから調査してください。

#langfuse#observability #llm #docker-compose #self-hosting