本文へ移動
Telemetry
バックグラウンドジョブ SQL レシピ

バックグラウンドジョブの再試行ストームを検出する

ジョブの試行が繰り返されることで不均衡なキュー作業と障害が発生するタイム バケットを見つけます。

中級者job_attemptsレビュー済み 2026-07-28テスト済み アパッチ DataFusion 45.2.0

レビュー者 Telemetry 製品チーム . SQL の互換性、イベント コントラクト、合成出力、および操作上の注意事項. 基準と所有権を確認する

質問に回答しました

現在、再試行に最も多くの時間を費やしている職種はどれですか?

再試行ストームによりスループットは向上しますが、有用な完了は減少します。試行、固有のジョブ、再試行シェア、および失敗シェアをまとめて測定することで、生産的な負荷と繰り返しの作業を分離します。

イベント契約

クエリが期待するフィールド

フィールド種類なぜ存在するのか
timestamp_utcTimestamp試行完了時間。
job_idUtf8安定した論理ジョブ識別子。
job_nameUtf8安定した職種です。
attemptInt641 から始まる試行番号。
statusUtf8完了、再試行、または失敗。
DataFusion SQL

クエリをコピーする

sql
SELECT
  date_trunc('hour', timestamp_utc) AS hour,
  job_name,
  COUNT(*) AS attempts,
  COUNT(DISTINCT job_id) AS logical_jobs,
  SUM(CASE WHEN attempt > 1 THEN 1 ELSE 0 END) AS retry_attempts,
  100.0 * SUM(CASE WHEN attempt > 1 THEN 1 ELSE 0 END)
    / NULLIF(COUNT(*), 0) AS retry_attempt_rate_pct,
  100.0 * SUM(CASE WHEN status = 'failed' THEN 1 ELSE 0 END)
    / NULLIF(COUNT(*), 0) AS failed_attempt_rate_pct
FROM job_attempts
WHERE timestamp_utc >= now() - INTERVAL '24 hours'
GROUP BY date_trunc('hour', timestamp_utc), job_name
HAVING COUNT(*) >= 20
ORDER BY retry_attempt_rate_pct DESC, attempts DESC;

この読み取り専用クエリは、空の型付きテーブルに対して計画され、実行されます。 アパッチ DataFusion 45.2.0。決定論的なサンプル出力は合成され、個別にレビューされます。フィールド タイプ、しきい値、ビジネス定義を独自のデータと照合して検証します。 テスト方法を読んでください。

クエリ結果

ジョブ別のリトライ率

CRM 同期では、論理ジョブよりもはるかに多くの試行が行われ、繰り返しの作業によりワーカーのキャパシティが消費されます。

hourjob_nameattemptslogical_jobsretry_attemptsretry_attempt_rate_pctfailed_attempt_rate_pct
2026-07-27 14:00sync_crm_accounts1,8404921,11860.7622.34
2026-07-27 14:00send_receipt_email3,1803,0611193.740.44

合成出力例。運用上の決定に使用する前に、独自のイベント スキーマとしきい値に対してクエリを実行します。

Retry-attempt rate by job: Detect Background-Job Retry Storms 結果例からの合成 retry_attempt_rate_pct 値の静的チャート
決定論的な出力例のインデックス可能な SVG。記事、ランブック、または出典を明示した設計レビューのためにダウンロードしてください。

例を再現する

パブリックフィクスチャをダウンロードする

JSON バンドルには、型付きイベント コントラクトが含まれています。 illustrative 入力行、正確な SQL、予想される出力、レビューメモ、およびエンジンのバージョン。 CSV には、表示された結果が含まれます。

SQL の仕組み

  1. 1個別のジョブ ID は有用な論理作業を推定し、生のカウントはワーカーの試行を測定します。
  2. 2試行回数が 1 を超えると、最終的な成功を最初の試行として扱わずに、繰り返しの作業が分離されます。
  3. 3失敗率は再試行シェアの横にあるため、意図的に再試行された一時的な依存関係は最終的な失敗と区別できます。

決定すべきエッジケース

  • ファンアウト ジョブは、合法的に複数の子 ID を作成できます。カウントを比較する前に、論理作業識別子を定義します。
  • 即時再試行とスケジュールされたバックオフでは容量への影響が異なるため、別のフィールドが必要になる場合があります。
  • 再試行の嵐は時間ごとのバケット間を移動する可能性があります。応答時間が重要な場合は、より短い操作クエリを追加します。

推奨されるダッシュボード

  • バー: ジョブ別 retry_attempt_rate_pct
  • 傾向: 試行回数と logical_jobs
  • 表: 試行回数が最も多く、エラーの種類が最も新しいジョブ

アラートガイダンス

連続する完全なバケットの再試行シェア、試行ボリューム、およびキューの経過時間が一緒に上昇すると、アラートが表示されます。

アラート設定を読む

レシピを活用する

関連する機器とガイド

分析を続ける

実際のイベントで実行する

テーブルを作成し、フィールドを調整して、結果を保存します

無料で始めて、構造化されたイベントを送信し、クエリ結果をグラフ、共有ダッシュボード ウィジェット、またはアラート入力として使用します。

API キーを取得する