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

配信不能キューの増加を測定する

デッドレターの作成と解決を比較して、回復不可能な作業が蓄積されているキューを見つけます。

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

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

質問に回答しました

デッドレター ジョブを解決するよりも早く追加しているキューはどれですか?

配信不能数はストックですが、作成および解決されたイベントはフローです。両方を追跡すると、キューが回復しているか増加しているかがわかります。

イベント契約

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

フィールド種類なぜ存在するのか
timestamp_utcTimestampジョブのライフサイクル イベント時間。
job_idUtf8安定した論理ジョブ識別子。
queue_nameUtf8ジョブを所有するキュー。
event_nameUtf8dead_letter_created または dead_letter_resolved。
error_typeUtf8分類された端末障害。
DataFusion SQL

クエリをコピーする

sql
SELECT
  date_trunc('day', timestamp_utc) AS day,
  queue_name,
  SUM(CASE
    WHEN event_name = 'dead_letter_created' THEN 1 ELSE 0
  END) AS created_jobs,
  SUM(CASE
    WHEN event_name = 'dead_letter_resolved' THEN 1 ELSE 0
  END) AS resolved_jobs,
  SUM(CASE
    WHEN event_name = 'dead_letter_created' THEN 1
    WHEN event_name = 'dead_letter_resolved' THEN -1
    ELSE 0
  END) AS net_queue_change
FROM job_events
WHERE timestamp_utc >= now() - INTERVAL '30 days'
  AND event_name IN ('dead_letter_created', 'dead_letter_resolved')
GROUP BY date_trunc('day', timestamp_utc), queue_name
ORDER BY day, queue_name;

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

クエリ結果

配信不能ジョブの作成と解決

7 月 26 日、請求業務ではさらに 22 件のデッドレター ジョブが蓄積されましたが、輸入業務ではキューが減りました。

dayqueue_namecreated_jobsresolved_jobsnet_queue_change
2026-07-25billing18162
2026-07-26billing31922
2026-07-27imports1214-2

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

Dead-letter jobs created and resolved: Measure Dead-Letter Queue Growth 結果例からの合成 created_jobs 値の静的チャート
決定論的な出力例のインデックス可能な SVG。記事、ランブック、または出典を明示した設計レビューのためにダウンロードしてください。

例を再現する

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

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

SQL の仕組み

  1. 1作成されたイベントと解決されたイベントは分離されたままであるため、同じ実質的な変更によって大きく異なる運用ワークロードを隠すことはできません。
  2. 2署名された純変更により、未解決の作業が蓄積された日々が明らかになります。
  3. 3キューごとにグループ化すると、所有権とエスカレーション パスが明確になります。

決定すべきエッジケース

  • 論理ジョブが文書化された最終的な成功または破棄の結果に達するまで、再試行は解決にはなりません。
  • バックフィルされたライフサイクル イベントは、過去の純移動を変更する可能性があります。
  • 現在のキュー在庫を個別に追跡するか、既知の期首残高から累積合計を計算します。

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

  • 積み上げバー: キュー別の created_jobs および resolved_jobs
  • 傾向: 累積送達不能在庫
  • 表: error_type ごとの最も古い未解決ジョブ

アラートガイダンス

net_queue_change が連続するバケットに対して正の値を維持している場合、または最も古い未解決のジョブが応答ターゲットに違反している場合にアラートを発行します。

アラート設定を読む

レシピを活用する

関連する機器とガイド

分析を続ける

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

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

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

API キーを取得する