コモンイベント契約書
これらのクエリを再利用可能に保つフィールド
- timestamp_utc、job_id、job_name、queue_name、およびステータス
- scheduled_at、started_at、completed_at、duration_ms、および試行
- error_type、worker_name、item_count、およびリリース
SQL より前の定義
クエリでは決定できないこと
- 1同じ論理ジョブのすべての試行を接続する識別子を 1 つ選択します。
- 2停止したジョブのクエリが完了した作業にフラグを立てないように、ターミナルのステータスを文書化します。
- 3しきい値を設定する前に、キューの待機を実行時間から切り離します。
推奨される順序
最初にビルド検出、次に診断
分析パターン
結果で決定を説明する
ジョブのライフサイクルをモデル化する
スケジュール、開始、再試行、完了、失敗、および破棄された結果を区別しておくことで、1 つのクエリで各論理ジョブを再構築できます。
ストックとフローを分離する
各タイム バケット中に作成および解決されたジョブとは別に、現在のバックログを測定します。
持続的な遅延に関するアラート
単一の一時的なワーカー エラーの代わりに、キューの経過時間、連続したスケジュールの欠如、または繰り返しの再試行を使用します。
完全なレシピ
クエリをコピーし、仮定を検証します
バックグラウンドジョブの再試行と失敗率を測定する
成功した実行、再試行、失敗、テール期間を比較して、信頼性の低いジョブを見つけます。
どのバックグラウンド ジョブが再試行を最も多く消費するか、または依然として失敗するのはどれですか?
SQL と結果を参照してください。SQL で停止したバックグラウンド ジョブを見つける
ジョブの開始イベントと終了イベントを結合して、予想される完了ウィンドウを超えた作業を特定します。
開始されたが、最終イベントを生成しなかったジョブはどれですか?
SQL と結果を参照してください。ジョブごとのキュー待ち時間の測定
キュー内での待機時間を実行時間から分離し、ジョブ名ごとに p50 と p95 の遅延を比較します。
ワーカーが開始するまでに最も長く待機するジョブはどれですか?
SQL と結果を参照してください。配信不能キューの増加を測定する
デッドレターの作成と解決を比較して、回復不可能な作業が蓄積されているキューを見つけます。
デッドレター ジョブを解決するよりも早く追加しているキューはどれですか?
SQL と結果を参照してください。欠落した Cron スケジュールの検出
連続する cron-run イベントを各スケジュール間隔と比較して、実行の遅延または欠落を見つけます。
スケジュールされたジョブは、文書化された間隔よりも遅く実行されましたか?
SQL と結果を参照してください。バックグラウンドジョブの再試行ストームを検出する
ジョブの試行が繰り返されることで不均衡なキュー作業と障害が発生するタイム バケットを見つけます。
現在、再試行に最も多くの時間を費やしている職種はどれですか?
SQL と結果を参照してください。しきい値の前にイベント コントラクトを適応させる
分析パターンを維持しますが、テーブル名、フィールド タイプ、ビジネス定義、時間枠、および最小ボリューム ルールを独自のイベントに対して検証します。パブリッシュされたすべてのクエリも計画され、ピン留めされたエンジンを使用して空の型付きテーブルに対して実行されます。