ガイド

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

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 つのステップです。通常のコードにはスパンを、モデル呼び出しには生成を使用します。スコアは、人によるレビューまたは自動評価によってトレースに付与される数値です。Langfuse は、分散トレーシングのベンダー中立な標準である OpenTelemetry（OTel）に対応しています。そのため、すでに導入している計装から Langfuse へ送信できます。

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

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

langfuse-web は Web インターフェースと取り込み API を提供します。
langfuse-worker はバックグラウンドでキューを処理します。取り込みバッチを解析し、コストを計算し、夜間の保持期間ジョブを実行します。
Postgres は、ユーザー、組織、プロジェクト、API キー、プロンプトなどのトランザクションデータを保持します。
ClickHouse は、オブザベーションやスコアなどのトレースデータ自体を保持します。分析クエリ向けに設計されたカラムストアであるため、1 億行を超えるデータに対するダッシュボードのクエリにも高速に応答できます。
Redis は、web と worker の間に配置されるキューおよびキャッシュです。
MinIO は、サーバー上に S3 互換のオブジェクトストレージを提供します。受信したすべての未加工イベントと、添付したメディアを保持します。

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 コンテナと worker は、それぞれ 4 GiB を必要とします。これは Langfuse がリソース要件を示している 3 コンポーネントの公開最小値です。Postgres、Redis、MinIO にも追加でメモリが必要です。プロジェクト独自の Docker Compose ガイドが 4 コア、16 GiB のメモリ、約 100 GiB のストレージを備えたマシンを推奨しているのは、この計算結果に余裕を加えたものではなく、そのまま反映したものです。

2 GiB のプランでは実行しないでください。ClickHouse は起動してしばらく書き込みを受け付けますが、バックグラウンドマージ中に停止します。マージによってテーブルの大きなパーツがメモリに読み込まれるためです。docker compose ps では clickhouse コンテナが restarting と報告され、dmesg には Out of memory: Killed process 1234 (clickhouse-serv) のような行が表示され、Langfuse のすべてのダッシュボードが 500 を返すようになります。負荷が比較的軽い場合、ClickHouse は代わりにクエリを拒否し、DB::Exception: Memory limit (total) exceeded をログに記録します。1 日に数千件のトレースを送信する開発者 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 か所に記載されています。MINIO_ROOT_PASSWORD として 1 回、その後 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 が、その日の朝にバックアップしていなかったデータベースに対する、予定外のスキーママイグレーションになります。両方を 1 つのリリースに固定する 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

4.3.1 は、2026 年 8 月時点で 4.3 系の最新バージョンでした（その後 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 エンドポイントを指す署名付き URL を使って、添付メディアをブラウザーに配信します。そのため、画像や音声を含むマルチモーダルトレースを使用する場合、MinIO を loopback のみで待ち受けると添付ファイルを読み込めません。プロキシを設定する前に、blob ストレージの設定ページを確認してください。署名付き URL に書き込まれるエンドポイントは、公開するエンドポイントと一致している必要があります。プレーンテキストのトレースには影響しません。

最初のアクセス時にアカウントを作成し、そのインスタンスを自分で管理できる状態にしてください。LANGFUSE_ALLOWED_ORGANIZATION_CREATORS には自分のメールアドレスを設定します。これにより、ページに到達した第三者がサーバー上に組織を作成できなくなります。すでに自分の identity provider として Authentik を運用している場合、Langfuse は標準の OIDC 接続を利用できます。アカウントは、このサーバーだけが管理するパスワード一覧ではなく、他のアプリと同じ ID 管理に従って追加・削除できます。

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

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() はキューに入った span が送信されるまで待機します。短時間で終了するプロセスでは必須です。SDK はバックグラウンドでバッチ処理するため、スクリプトがすぐに終了すると未送信のバッチも失われます。

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

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

ここでは、別々の 2 つが増加しているため、それぞれに別の対策が必要です。

1 つ目は、独自のトレースデータです。対策は保持期間の設定です。Web インターフェースでプロジェクト設定を開き、データ保持期間を日数で設定します。Langfuse で設定できる最小値は 3 日です。夜間ジョブが保持期間を過ぎたトレース、オブザベーション、スコア、メディアアセットを選択し、ClickHouse と blob ストレージから削除します。このジョブにはバケットへの DeleteObject 権限が必要です。デフォルトの compose ファイルにある MinIO の root 認証情報には、すでにこの権限があります。削除したデータは復元できないため、長期的な履歴が必要な場合は、先に blob ストレージへのエクスポートを設定してください。Langfuse 自身のテーブルに TTL 句を手作業で追加しないでください。保持ジョブが ClickHouse とバケットの状態を同期させますが、手動の TTL では片方だけが削除されます。

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

2 つ目は、ClickHouse 自身のシステムログテーブルです。保持期間を設定した後もディスク使用量が増え続けるため、この点に気付かないことがあります。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" を指定して実行します。システムテーブルが上位に並ぶ場合は、設定オーバーレイで無効にしてください。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 のスケーリングに関するドキュメントで、その方法が説明されています。

もう 1 つ、把握しておく価値のあるテーブルがあります。blob_storage_file_log は、バケットにアップロードされたイベントファイルを追跡します。バケットにもライフサイクルポリシーを設定する場合は、2 つの状態がずれないように、テーブルにも一致する 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 には trace が保存されます。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 では、マージの実行中に live data directory をコピーすると、一貫性のあるバックアップにならないため、より慎重な対応が必要です。1 台のサーバーで行う簡単な方法は、コンテナを停止して volume をアーカイブすることです。

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 が表示する volume 名を使用してください。ファイルでは langfuse_clickhouse_data と宣言されていますが、Compose はプロジェクト名を付けて名前を生成します。そのため、langfuse というディレクトリで clone すると langfuse_langfuse_clickhouse_data になります。名前を間違えると、docker run はエラーを出さずに新しい空の volume を作成し、アーカイブには何も含まれません。

Web コンテナは、受信した各イベントを worker が処理する前に bucket へ書き込みます。そのため、ClickHouse を短時間停止しても、主に worker が後で再試行するだけです。利用の少ない時間帯に実施し、停止時間を短くしてください。より負荷の高いインスタンスでは、ClickHouse 自身の BACKUP DATABASE default TO S3(...) statement を使用すると、サーバーを停止せずに一貫性のあるバックアップを作成できます。MinIO は 3 つ目の要素であり、mc mirror または MinIO replication によって外部の bucket へ保存すれば対応できます。どの方法で作成した場合も、バックアップはサーバー外へ移してください。VPS 上の暗号化された restic バックアップは、そのために使用します。

Redis はバックアップ不要です。Redis には queue と cache が保持されるため、失うのは処理中のイベントだけで、過去のデータは失われません。

整合性に関する注意点は実際に存在するため、明確に説明しておく必要があります。Postgres と ClickHouse は異なる時点で dump されるため、復元後に trace のない project row が残ったり、すでに存在しない project に属する trace が残ったりする可能性があります。Langfuse はこの状態を許容しますが、2 つの dump は近い時刻に、トラフィックの少ない時間帯に取得してください。イベント bucket が実質的な安全網です。Langfuse は受信したすべてのイベントを処理前にそこへ保存するためです。

少なくとも 1 回は scratch stack に復元してください。これにより、障害発生中ではなく、事前に volume 名の誤りを発見できます。

最初に確認すること

最初の 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 の bucket もバックアップしてください。そこには、Langfuse が受信時に永続化する raw events が保存されており、この構成で source of truth に最も近いデータだからです。

既存の OpenTelemetry 環境を self-hosted Langfuse に接続できますか？

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

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