本文へ移動
統合ガイド

Django と Celery の構造化イベント監視

Celery タスクの各試行の状態を記録し、再試行を最終的な失敗と混同せず、タスクの結果を変更しません。

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

役に立つ
  • Celery ワーカーの結果
  • セロリのリトライ分析
  • 再試行とタスクの関連付け
実装の証拠

Django and Celery structured event monitoring でイベントを送信して確認する

Celery タスクの一回の試行を観測し、元の結果を保ち、グラフ作成前に記録された状態を確認します。

  1. 1

    試行を選ぶ

    Celery ワーカーの結果

  2. 2

    契約を定義する

    job_name、job_id、queue_name、observed_state、status

  3. 3

    試行の状態を記録

    この例では task_postrun の SUCCESS、FAILURE、RETRY を試行の状態として記録します。再試行は最終的な失敗ではありません。

  4. 4

    証拠を検証する

    既知のタスクを実行し、celery_task_attempt_finished で観測した試行の状態を確認します。再試行の行は最終結果ではありません。

始める前に

始める前に

  • サーバー側 TELEMETRY_API_KEY
  • ワーカープロセスに Celery がインストールされていること
  • Celery ワーカーの起動時にこのモジュールをインポートすること

配信設定

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

この Celery ワーカーモジュールは Python 標準ライブラリの HTTP でイベントを送信します。Telemetry SDK のインストールや初期化は不要です。 ブラウザ バンドル、クライアントに表示される環境変数、ソース管理、ログ、および例外メッセージに取り込み資格情報が含まれないようにします。

  1. 1各ワーカーでシグナルモジュールを一度読み込み、送信エラーをタスク結果と分離します。
  2. 2成功、失敗、再試行、またはタイムアウトの境界に結果イベントを追加します。
  3. 3アラートを有効にする前に、制御されたフィクスチャを送信し、保存されている行を検査します。

スニペット

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

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

django-celery

Django and Celery structured event monitoringイベント

python
import json
import logging
import os
from urllib.request import Request, urlopen
from celery.signals import task_postrun


def report_export_failure():
    try:
        logging.getLogger(__name__).warning("Telemetry export unavailable")
    except Exception:
        pass


@task_postrun.connect(weak=False)
def record_task(sender=None, task_id=None, state=None, **kwargs):
    try:
        status = {"SUCCESS": "success", "FAILURE": "failed",
                  "RETRY": "retry_scheduled"}.get(state)
        if status is None:
            return  # Other states need their own observed lifecycle handlers.
        key = os.getenv("TELEMETRY_API_KEY")
        if not key:
            report_export_failure()
            return
        delivery = sender.request.delivery_info or {}
        payload = {
            "table": "celery_task_attempt_finished",
            "data": {
                "job_name": sender.name,
                "job_id": task_id,
                "queue_name": delivery.get("routing_key"),
                "observed_state": state,
                "status": status,
                "attempt": sender.request.retries + 1,
            },
        }
        request = Request("https://api.telemetry.sh/log",
                          data=json.dumps(payload).encode("utf-8"),
                          headers={"Authorization": key,
                                   "Content-Type": "application/json",
                                   "User-Agent": "telemetry-agent/1.0"},
                          method="POST")
        # Socket timeout, not a hard end-to-end deadline. Export can be lost.
        with urlopen(request, timeout=1.0) as response:
            if not 200 <= response.status < 300:
                report_export_failure()
    except Exception:
        # Do not let export or metadata errors replace the task outcome.
        report_export_failure()

イベントスキーマ

job_name、job_id、queue_name、observed_state、status

観測した実行の attempt は retries + 1

ワーカーのメタデータのみ。送信前にタスクとキューの識別子を確認してください

設定を確認する

チェックポイント 1

この例では task_postrun の SUCCESS、FAILURE、RETRY を試行の状態として記録します。再試行は最終的な失敗ではありません。

チェックポイント 2

再試行でも同じ論理タスク ID を保ち、試行番号として retries + 1 を記録します。

チェックポイント 3

各ワーカープロセスでこのモジュールを一度インポートします。Django リクエストの計測やタスク所要時間の測定は行いません。

チェックポイント 4

送信はベストエフォートで、ソケットのタイムアウトは 1 秒です。ワーカーの遅延が増え、厳密な総時間の上限、永続的な配信、送信の再試行は実装していません。

チェックポイント 5

タスク引数、結果、例外文、URL、認証情報をイベントに含めないでください。ワーカーの停止や消失で task_postrun が発生しない場合があるため、イベントがない場合の状態は不明です。

検証

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

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

django-celery-検証

Django and Celery structured event monitoring 検証クエリ

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

実装の参考資料

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

イベントを記録する場所

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

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

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

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

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

イベントスキーマの例

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

関連製品の機能

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

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

関連する SQL レシピ

その他のSQL例

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

すべてのレシピを参照する

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

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

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

さらなる統合