本文へ移動
統合ガイド

Python および FastAPI 構造化ロギング

Telemetry の非同期クライアントと正規化したルート名を使い、FastAPI の応答ステータスとヘッダー受信までの遅延を記録します。

レビュー者 Telemetry 製品チーム に . 送信するイベント、除外するデータ、コードの追加方法を確認しました. このページのレビュー担当

セットアップ用プロンプトで既存のルート一つに計測を追加します。試用に登録は不要です。

役に立つ
  • Python API 監視
  • テールレイテンシー分析
  • 顧客への影響のデバッグ
実装の証拠

Python and FastAPI structured logging でイベントを送信して確認する

制御されたアプリケーション境界で Python and FastAPI structured logging を使用し、イベント コントラクトを小さく保ち、集約ビューを構築する前に既知の結果を検証します。

  1. 1

    結果を選択してください

    Python API 監視

  2. 2

    契約を定義する

    route_template、メソッド、および status_code

  3. 3

    結果で発行する

    識別子によって無制限のグループが作成されないように、生の URL の代わりに一致したルート パスを使用します。

  4. 4

    証拠を検証する

    Exercise a known fixture, then inspect fastapi_response_observed for one correctly typed terminal row.

始める前に

始める前に

  • サービス環境にインストールされた telemetry-sh
  • TelemetryAsync はサーバー側の API キーで初期化されました
  • 信頼できないリクエストヘッダーをコピーせずに生成したリクエスト ID

配信設定

サーバー側のインストールと初期化

サーバー側キーを使用して、プロセスごとに 1 回、同期コードの場合は Telemetry を、非同期コードの場合は TelemetryAsync を初期化します。 ブラウザ バンドル、クライアントに表示される環境変数、ソース管理、ログ、および例外メッセージに取り込み資格情報が含まれないようにします。

python-fastapi-インストール

pipのインストール

bash
python -m pip install telemetry-sh
  1. 1制限されたネットワーク動作を持つ再利用可能なサーバー側配信クライアントを 1 つ準備します。
  2. 2成功、失敗、再試行、またはタイムアウトの境界に結果イベントを追加します。
  3. 3アラートを有効にする前に、制御されたフィクスチャを送信し、保存されている行を検査します。

スニペット

1 つの構造化されたイベントから始める

ワークフローが完了、失敗、または再試行される場所にこの図形を追加します。次に、実際のフィールドからダッシュボードを構築します。

python-fastapi

Python and FastAPI structured loggingイベント

python
import asyncio
import time
import uuid

# app and the initialized TelemetryAsync client already exist.
@app.middleware("http")
async def record_request(request, call_next):
    started_at = time.perf_counter()
    request_id = uuid.uuid4().hex
    response = await call_next(request)
    route = request.scope.get("route")
    latency_ms = round((time.perf_counter() - started_at) * 1000)

    try:
        await asyncio.wait_for(telemetry.log("fastapi_response_observed", {
            "route_template": getattr(route, "path", "unmatched"),
            "method": request.method,
            "status_code": response.status_code,
            "status": "response_observed",
            "latency_ms": latency_ms,
            "request_id": request_id,
        }), timeout=1.0)
    except Exception:
        # Best effort: connect this to your existing safe diagnostics.
        pass
    return response

イベントスキーマ

route_template、メソッド、および status_code

応答ヘッダーを観測した時点の status と latency_ms

ローカルで生成した request_id

設定を確認する

チェックポイント 1

識別子によって無制限のグループが作成されないように、生の URL の代わりに一致したルート パスを使用します。

チェックポイント 2

この例は応答ヘッダーを観測します。ストリーム本文の完了や業務上の成功は示しません。latency_ms の計測は call_next が戻った時点で終了します。

チェックポイント 3

送信には1秒の協調的なタイムアウトとエラー処理を設け、応答を維持します。本番の送信には容量制限付きのキューと安全な失敗診断が別途必要です。

チェックポイント 4

未処理のアプリケーション例外ではこのイベントは生成されません。例外ハンドラーは別途計測し、リクエストのキャンセルはそのまま伝播させてください。

検証

イベントが到着したことを証明する

既知の成功例と失敗例を実行した後、これを実行します。最終的なイベント コントラクトがスニペットと異なる場合は、フォールバック テーブル名を置き換えます。

python-fastapi-検証

Python and FastAPI structured logging 検証クエリ

sql
SELECT *
FROM fastapi_response_observed
ORDER BY timestamp_utc DESC
LIMIT 20;
論理結果ごとに 1 つのターミナル行を、予想されるステータス、識別子、単位、および UTC 時刻とともに確認します。
推論されたスキーマを検査し、再試行によってフィールド タイプが変更されたり、新しい論理イベント ID が生成されたりしないことを確認します。
保存されたフィールドで認証情報、生のペイロード、プロンプト、プライベート コンテンツ、および無制限のエラー メッセージを検索します。
ダッシュボードを完了として扱う前に、プロバイダーのタイムアウト、取り込みの拒否、およびプロセスのシャットダウンを実行します。

実装の参考資料

新しい運用パスを有効にする前に、イベント契約、データ安全性に関するガイダンス、上流の主要ドキュメントを確認してください。

イベントを記録する場所

結果イベントを小さく、回復可能なものに保つ

このパターンが提供するのは、

  • 上流のワークフローの横にある、制限付きの SQL 対応の結果。
  • ダッシュボード、アラート、およびイベント間の相関関係の安定したフィールド。
  • 成功、失敗、再試行、タイムアウトの動作を検証するためのフィクスチャ駆動のパス。

このパターンでは提供されません

  • OTLP エクスポーター、自動収集パイプライン、または詳細なトレースと診断ログの代替。
  • ペイロードにイベント ID が含まれているという理由だけで、1 回だけ配信されます。
  • 生のプロバイダー ペイロード、ユーザー コンテンツ、資格情報、または規制されたデータを収集する許可。

イベントスキーマの例

クエリまたはスニペットを運用環境に適用する前に、行粒度、出力境界、必要なタイプ、プライバシー クラス、サンプル ペイロード、および検証チェックリストを確認してください。

関連製品の機能

このワークフローを続行します アラート

レビューされた信頼性クエリを、所有するしきい値と応答のワークフローにプロモートします。

関連する SQL レシピ

その他のSQL例

このワークフローの構造化フィールドに対してクエリを実行し、結果の例を検査して、有用な回答をダッシュボードまたはアラートに変換します。

すべてのレシピを参照する
クエリ例のコレクションAPI の信頼性 SQL

実装ファミリーごとに参照する

関連する統合パターンを比較する

この統合と組み合わせるテンプレート

さらなる統合