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

バックグラウンドジョブの再試行と失敗率を測定する

成功した実行、再試行、失敗、テール期間を比較して、信頼性の低いジョブを見つけます。

初心者job_runsレビュー済み 2026-07-27テスト済み アパッチ DataFusion 45.2.0

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

質問に回答しました

どのバックグラウンド ジョブが再試行を最も多く消費するか、または依然として失敗するのはどれですか?

再試行により、余分な作業や遅延した結果を隠しながら、キューが正常に見えるようにすることができます。このクエリは、最初の試みの成功として扱わずに、成功したリカバリを表示したままにします。

イベント契約

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

フィールド種類なぜ存在するのか
timestamp_utcTimestamp実行が完了したか失敗したとき。
job_nameUtf8安定した論理ジョブ名。
statusUtf8成功か失敗か。
attemptInt641 ベースの実行試行。
duration_msFloat64試行期間。
DataFusion SQL

クエリをコピーする

sql
SELECT
  job_name,
  COUNT(*) AS attempts,
  SUM(CASE WHEN attempt > 1 THEN 1 ELSE 0 END) AS retries,
  SUM(CASE WHEN status = 'failed' THEN 1 ELSE 0 END) AS failures,
  100.0 * SUM(CASE WHEN attempt > 1 THEN 1 ELSE 0 END)
    / NULLIF(COUNT(*), 0) AS retry_rate_pct,
  approx_percentile_cont(duration_ms, 0.95) AS p95_duration_ms
FROM job_runs
WHERE timestamp_utc >= now() - INTERVAL '7 days'
GROUP BY job_name
ORDER BY retry_rate_pct DESC, failures DESC;

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

クエリ結果

ジョブ別のリトライ率

電子メールの方が絶対的な再試行回数が多い場合でも、サブスクリプション同期は注目に値します。

job_nameattemptsretriesfailuresretry_rate_pctp95_duration_ms
sync_subscription1032308,000
generate_report81112.512,000
send_email10000900

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

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

例を再現する

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

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

SQL の仕組み

  1. 1論理ジョブの代わりに試行をカウントすると、再試行によって発生する余分な実行負荷が意図的に明らかになります。
  2. 2再試行率の分母はすべての試行です。論理ジョブの分母を使用する場合は、job_id を含めて、個別のジョブ ID をカウントします。
  3. 3p95 の期間は、ワーカーの容量を消費する高価な実行と、迅速な一時的な再試行を区別するのに役立ちます。

決定すべきエッジケース

  • スケジュールされた再試行は予期された動作である可能性があります。再試行ポリシーを変更する前に、error_type でセグメント化してください。
  • 複数の試行が 1 つの論理作業単位に属する場合は、安定した job_id を使用してください。
  • 配信不能イベントは回復が枯渇していることを表すため、個別に報告する必要があります。

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

  • 棒グラフ: retry_rate_pct by job_name
  • 折れ線グラフ: 日別の障害数と job_name
  • 表: 最新の最終的な失敗と顧客およびエラーのコンテキスト

アラートガイダンス

再試行率が前の 7 日間のベースラインと比較して 2 倍になった場合、または最終的な失敗が重要なワークフローに影響を与えた場合にアラートを送信します。

アラート設定を読む

レシピを活用する

関連する機器とガイド

分析を続ける

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

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

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

API キーを取得する