Dockerにした途端、FastAPIのログが消えたとき ── logging が出力されなくなる構成上の原因
はじめに：何が起きたか
ローカルでは uvicorn で普通に logging が出ていたのに、
Docker + gunicorn にした瞬間、ログだけが一切出なくなることがある。
エラーは出ない。
アプリは起動している。
エンドポイントも普通に叩ける。
それでも、
ログだけが何も表示されない。
この事故が厄介な理由
この手のトラブルは、
落ちるわけでもなく、例外が出るわけでもない。
ただ、
「何も起きなくなる」。
いわば、静かに死ぬ事故だ。
気づくのが遅れやすく、
気づいた時には
「どこから見ればいいのか分からない」状態になりがちになる。
なぜ Docker にすると logging が消えるのか
logging が出なくなる理由はひとつではないが、
Docker 化によって見えづらくなるポイントは、だいたい決まっている。
例えば：
- stdout / stderr の行き先が変わる
（PYTHONUNBUFFERED やログレベルの継承が影響するケースもある） - gunicorn / uvicorn の起動方法が変わる
（worker 設定や loglevel の扱い） - logging 設定の読み込みタイミングが変わる
特に厄介なのは、
logging は設定が多少ズレていてもアプリが動いてしまう点だ。
そのため、
問題が表に出にくい。
この手の事故は、実は珍しくない。
切り分けは「順番」がすべて
この事故で一番やってはいけないのは、
いきなり logging 設定を書き直すことだ。
初動では、次の順で切り分ける。
- logging が本当に呼ばれているか
- logger.info() 自体が実行されているか
- Docker コンテナ内で stdout / stderr がどこに流れているか
- gunicorn / uvicorn をどう起動しているか
- logging 設定ファイルをどこで読み込んでいるか
この順で確認すれば、
原因はかなり絞れる。
ここまで来て問題が見えない場合、
FastAPI 自体に原因がある可能性は低い。
ありがちな勘違い
- ローカルで出ていたから、本番でも出ると思っていた
- logging の設定は一度書けば終わりだと思っていた
- Docker は「包むだけ」だと思っていた
logging 周りは、
作り直しても再発しやすいポイントでもある。
まとめ
logging が出ないのは、
バグではないことが多い。
仕様どおりに出ていないだけ。
帰り際の一言
何も出ていないからといって、
何も起きていないとは限らない。
🛠️ FastAPI インシデント分析シリーズ
「401 / JWT / Dockerでだけ壊れる」など、原因切り分けが難しいケースをパターン別に公開しています。
🔐 認証・JWTトラブル
/tokenは通るのに /me が401になる理由
[https://zenn.dev/fastapier/articles/0022f125547300]
（※一番人気。検証フローの盲点を解説）
環境変数は設定したのに SECRET_KEY が None になる理由
[https://zenn.dev/fastapier/articles/e93b522cc0acb3]
401 / 403 を取り違えると、原因が見えなくなる
[https://zenn.dev/fastapier/articles/41f9e2e10e7c19]
Depends が静かに壊れて 401 / 403 になる理由
[https://zenn.dev/fastapier/articles/efba40f5bcbbda]
🐳 Docker・本番環境トラブル
ローカルでは動くのに本番だけ落ちる理由
[https://zenn.dev/fastapier/articles/c90e5199e0bafc]
🏗️ 設計・運用トラブル
main.pyが1000行を超えたときに起きる崩壊の理由
[https://zenn.dev/fastapier/articles/a2a9a5209dedac]
💡 インシデント分析・個別相談のご案内
上記のようなトラブルの分析・評価を専門に承っております。GitHubプロフィール欄の連絡先よりご相談ください。
[https://github.com/hiro-kuroe]
Discussion