セルフホスト版Dify×Langfuse連携で「No key found for public key」と怒られたときの覚え書き

TL;DR

Langfuse側のデフォルトで張られるネットワーク（langfuse_default）を利用する際、

Dify側サービスapiの他に、workerも同じnetworksに所属させる必要があった。

やったこと

WSL上でDifyを構築したので、試しにセルフホスト版のLangfuseを連携させてみようと思い立った。

それぞれ公式の手順通りcloneしてきてコンテナを立てた状態。

http://localhost:3000でLangfuseUIにアクセスして、アカウント登録とプロジェクトの作成、またAPIキーの発行まで行った。

でまず、発行したAPIキーをDifyに読み込もうとすると下記エラーが発生。

LangFuse API check failed: [Errno 111] Connection refused

これはDifyコンテナからLangFuseコンテナへ疎通できていないことが原因で、

Dify側のdocker-compose.yamlにnetworks定義が必要だった。

これはDifyどうのというよりDockerの問題で、
コンテナ同士は、同一networksに所属してさえいればサービス名で通信が可能になることは知ってた（つもりだった）

LangFuseコンテナ側にnetworksの定義は無いが、
立ち上げるとlangfuse_defaultっていうネットワークが張られる

このlangfuse_defaultにDify側のapiサービスを所属させた。
（LangFuse側を先に立ち上げる必要があることに注意）

Dify側のdocker-compose.yamlのヘッダに
直接編集だめみたいな記述があるが、コントリビューター向けっぽいので無視した
docker-compose-template.yamlを元に
python経由で環境に合わせたyamlを生成する構成になっているもよう

docker-compose.yaml

services:
  # API service
  api:
    image: langgenius/dify-api:1.9.2
    restart: always

    ...(省略)

    networks:
      - ssrf_proxy_network
      - default
      - langfuse_default  # 追加

  ...(省略)

networks:
  # create a network between sandbox, api and ssrf_proxy, and can not access outside.
  ssrf_proxy_network:
    driver: bridge
    internal: true
  milvus:
    driver: bridge
  opensearch-net:
    driver: bridge
    internal: true
  langfuse_default:  # 追加
    driver: bridge
    external: true

また、Hostをlocalhostから、
Langfuseのサービス名langfuse-webに変更してIN SERVICE状態になった。

ここまでやって、ワークフローを動かしてみると、Langfuse側に何も入ってこない。

docker compose logs -f langfuse-web langfuse-worker
で、見てみると、public keyが見つからないエラーが出てることが判明

2025-11-06T04:50:30.100Z error     No key found for public key
2025-11-06T04:50:30.100Z info      No key found, storing api-key-non-existent in redis
2025-11-06T04:50:30.102Z info      Error verifying auth header: Invalid credentials Invalid credentials
Error: Invalid credentials

ここからめっちゃ詰まった。

まずWSLの割り当てメモリ容量が足りなくて不安定だった。（Fetch Failedとかになる）

これは4GBで指定しちゃってたので8GBまで拡張。

その後curlでLangfuseAPIを直接叩いて疎通できるか確認。

/projects

とか

/ingestion
とかで試して、実際にデータが入ることを確認。

export LANGFUSE_PUBLIC_KEY="pk-lf-xxxxx"
export LANGFUSE_SECRET_KEY="sk-lf-yyyyy"

curl -u "$LANGFUSE_PUBLIC_KEY:$LANGFUSE_SECRET_KEY" \
  -H "Content-Type: application/json" \
  -X POST http://localhost:3000/api/public/ingestion \
  -d '{
    "batch": [
      {
        "id": "test-trace-1",
        "timestamp": "2025-11-06T00:00:00.000Z",
        "type": "trace-create",
        "body": {
          "id": "test-trace-1",
          "timestamp": "2025-11-06T00:00:00.000Z",
          "environment": "production",
          "name": "wsl-manual-test",
          "userId": "test-user",
          "input": "hello",
          "output": "world",
          "sessionId": "test-session",
          "release": "1.0.0",
          "version": "1.0.0",
          "metadata": {},
          "tags": ["manual", "test"],
          "public": true
        }
      }
    ]
  }'

ちなみに、調べる過程で、PublishしないとDifyのデフォルトのlogsとかMonitoringにもデータが蓄積されないことに今更気づく。

Publishしてから動確するように変更。

その後色々試行錯誤して、Difyのpythonソースにデバッグを仕込み始めた時、

「あれ、Langfuseへの通信って、非同期でworkerっていうサービスのTasksにキューイングされてそこから出てね・・・？」

となって、

workerもnetworksをlangfuse_defaultに所属させたらちゃんとデータが連携された。
（public keyが見当たらないっていうエラーログなんだったんや紛らわしい・・・）

Difyにはworker_beatっていうサービスもあるが、これは定期実行タスクをworkerにキューイングしてるだけっぽく、networks設定はおそらく不要だと思われます。

以上、基本的な設定ミスでしたがご参考なれば幸いです。