本文へ移動
技術を、自社の仕事に。
判断と実行を助けるメディア

記事を検索

FastAPIのOpenTelemetry送信 0.143で既定オフに

目次 · 7項目

FastAPI で作った社内システムやAIのAPIサーバーを保守していると、依存関係の更新で fastapi の版が上がるPRが届くことがあります。0.142 から 0.143 への更新も、番号だけを見れば小さな変更に見えます。

ところが、この2つの版の間で 「アプリの稼働データを外部の監視サービスへ自動で送るかどうか」の既定値が変わりました。0.142.0(2026年9月29日公開)で OpenTelemetry が標準で組み込まれ、0.143.0(10月8日公開)で自動の送信設定が「明示的に有効にした場合だけ」に変わっています。その後の 0.143.1(10月14日)と 0.143.2(10月15日)は別の不具合の修正で、この既定値は変わっていません。

どちらの版を使っているかで、監視のデータが届かなくなる場合と、意図しない送信が起きる場合の両方があります。0.141.1、0.142.4、0.143.0 を手元で動かし、送信先をローカルの受信用サーバーに向けて確かめた結果を整理します。

何が変わったのか

公式のリリースノートでは、0.142.0 に「Add native OpenTelemetry support」、0.143.0 に次の説明があります。

Automatic OpenTelemetry exporter setup is now opt-in. If you rely on FastAPI to configure exporters from OTEL_* environment variables, set FASTAPI_OTEL_AUTO_CONFIGURE=true or use FastAPI(telemetry={"auto_configure": True}) to retain the previous behavior.

自前でプロバイダーと送信先(exporter)を設定しているアプリは変更不要で、FastAPI Cloud では自動の設定が有効になる、とも書かれています。

公式ドキュメントの OpenTelemetry のページによると、FastAPI は HTTP リクエストのトレース、メトリクス、ログを標準で記録します。送り先(OTLP のエンドポイント)が環境変数 OTEL_EXPORTER_OTLP_ENDPOINT で指定されていると、自動の設定が有効な場合に、トレースは /v1/traces、メトリクスは /v1/metrics、ログは /v1/logs へ送られます。

pip install "fastapi[standard]" で入れた場合、0.142 以降は送信に必要な opentelemetry-sdk と opentelemetry-exporter-otlp-proto-http も一緒に入ります(編集部の環境で確認。0.141.1 では入りませんでした)。

3つの版で送信の有無を比べた

OTEL_EXPORTER_OTLP_ENDPOINT をローカルの受信用サーバーに向け、通常のリクエストと、例外を起こすリクエストを1回ずつ送りました。受信用サーバーには、届いた送信の宛先パスを記録させています。

編集部の検証結果。OTEL_EXPORTER_OTLP_ENDPOINTを設定した状態で、0.141.1は送信なし、0.142.4はトレース・メトリクス・ログを送信、0.143.0は既定では送信なし、0.143.0でFASTAPI_OTEL_AUTO_CONFIGURE=trueにすると送信した。0.142.4ではFASTAPI_OTEL_AUTO_CONFIGURE=falseを設定しても送信は止まらなかった

ログの記録をそのまま載せます。

0.141.1                                   → 送信なし
0.142.4                                   → /v1/traces 1件、/v1/logs 1件、/v1/metrics 3件
0.142.4 + FASTAPI_OTEL_AUTO_CONFIGURE=false → /v1/traces 1件、/v1/logs 1件、/v1/metrics 3件
0.142.4 + telemetry={"auto_configure": False} → 送信なし
0.143.0                                   → 送信なし
0.143.0 + FASTAPI_OTEL_AUTO_CONFIGURE=true  → /v1/traces 1件、/v1/logs 1件、/v1/metrics 3件
0.143.0 + telemetry={"auto_configure": True}  → /v1/traces 1件、/v1/logs 1件、/v1/metrics 4件

(メトリクスの件数は送信の間隔とプロセスの停止のタイミングによる違いで、版の違いではありません)

読み取れることは2つです。

  1. 0.142.x で、送信先の環境変数があるだけで自動送信が始まる。 他のライブラリの設定や、以前の監視の名残で OTEL_EXPORTER_OTLP_ENDPOINT が環境に残っていると、FastAPI を 0.142 に上げた時点でその宛先へ送られます
  2. 環境変数 FASTAPI_OTEL_AUTO_CONFIGURE は 0.143.0 で加わったもの。 0.142.4 で false を設定しても止まりませんでした(0.142.4 のソースにこの環境変数の記述はなく、0.143.0 で追加されています)。0.142.x で止める方法は、コードで telemetry={"auto_configure": False} を渡すことです

例外メッセージもログとして送られる

もう1つ確かめたのは、ログの中身です。例外を起こすエンドポイントで、メッセージにパスワードを模した文字列(db password=SECRET-TOKEN-123)を含めました。

0.142.4 の既定と、0.143.0 で自動設定を有効にした場合のどちらも、/v1/logs に届いたデータにこの文字列が含まれていました。公式ドキュメントにも「Exception logs include the exception’s type, message, and stack trace. Messages and stack traces can contain sensitive information.」とあり、仕様どおりの動きです。

telemetry={"logs": False} を渡すと、トレースとメトリクスは送られ、ログは送られなくなり、文字列も届きませんでした。

例外のメッセージには、SQL の断片、外部APIの応答、利用者が入力した値などが入ることがあります。送り先が社内で管理する監視基盤なのか、外部のSaaSなのか、データの保存場所や保存期間はどうなっているかを、送信を有効にする前に確認しておくべき点です。ドキュメントは、ログを加工・削除する処理(log processor)で取り除くか、logs を False にする方法を案内しています。

なお、リクエストの検証エラー(422)の警告ログについては「These logs do not include the invalid input」とされ、入力値そのものは含まれません。

版ごとに確かめること

以下は、上の結果を踏まえた編集部の整理です。

0.141 以前から 0.143 へ上げる場合 既定では何も送られないため、挙動は変わりません。新たに FastAPI 経由で監視へ送りたい場合は、FASTAPI_OTEL_AUTO_CONFIGURE=true か telemetry={"auto_configure": True} を設定します。

0.142.x を使っている場合 本番の環境変数に OTEL_EXPORTER_OTLP_ENDPOINT(または OTEL_ で始まる送信先の設定)があるかを確認します。ある場合は、すでに送信されています。意図した送信なら、0.143 へ上げると送信が止まるため、上げる前に FASTAPI_OTEL_AUTO_CONFIGURE=true を環境に追加します。意図していないなら、0.143 へ上げるか、telemetry={"auto_configure": False} を渡します。

すでに自前で OpenTelemetry を設定している場合 ドキュメントでは、FastAPI は設定済みのプロバイダーを使い、自動設定が有効なときにだけ送信先を追加するとされています。他のライブラリが同じ宛先へ送っている場合は、重複を避けるため自動設定を有効にしないよう案内されています。

設定を確かめる手順の例です。

# 使っている版と、送信先の環境変数の有無
pip show fastapi | grep -i '^version'
env | grep -E '^(OTEL_|FASTAPI_OTEL_)'

そのほかの設定

telemetry には、ほかに次の項目があります(公式ドキュメントの表から)。

  • tracing / metrics / logs: それぞれの記録の有無(既定はすべて True)
  • operation_spans: 依存関係の解決や関数の実行ごとのスパンを追加するか
  • exclude: ヘルスチェックなど、記録しないリクエストを関数で指定

ヘルスチェックを数秒ごとに受けるサーバーでは、exclude で外しておくと、監視サービス側のデータ量と費用を抑えられます。可観測性の基盤を移行する考え方はAirbnb 事例に学ぶ OpenTelemetry 移行、Python の依存部品の更新を安全に進める方法はPip 26.1 Dependency Cooldowns、Python のアプリをサーバーレスで動かす選択肢はCloudflare Python Workersでも扱っています。

確認した範囲

2026年10月12日に、fastapi/fastapi の docs/en/docs/release-notes.md(0.142.0〜0.143.0。2026年10月16日に 0.143.2 までを再確認)と docs/en/docs/advanced/opentelemetry.md、PyPI の公開日時、インストールした各版のソースを確認しました(資料調査)。あわせて Linux 上の Python 3.11.17 で fastapi[standard] の 0.141.1・0.142.4・0.143.0 をそれぞれの仮想環境に入れ、uvicorn で起動し、OTEL_EXPORTER_OTLP_ENDPOINT をローカルの HTTP サーバーに向けて、届いた送信の宛先と中身を記録しました(実機検証)。実在の監視サービスへの送信、WebSocket、gRPC での送信、FastAPI Cloud は試していません。

FastAPI で作るAPIサーバーや監視の設計・保守は、開発・AI・自動化のご相談からお問い合わせください。

参考資料

この記事を共有XFacebook
鈴木 翔

技術の可能性に魅了され、学生時代からプログラミングとデジタルアートの分野に深い関心を持つ

この記事のテーマを、自社の次の一歩へ

自社での進め方を、具体的に。

つくりたい仕組み、既存システム、運用の条件を整理し、実現に向けた次の一歩を考えます。

  • 実現したい仕組み
  • 既存環境との接続
  • 運用の条件
開発・運用の構想を相談する

構想段階からご相談いただけます。この記事の情報を相談フォームに引き継ぎます。

最新記事をメールで受け取る