サービス フックのトラブルシューティング

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

この記事は、一般的なトラブルシューティングのガイダンスと、よく寄せられる質問 (FAQ) に対する回答に使用します。

アクティビティの表示と問題のデバッグ

Web アクセス管理者の [サービス フック] ページには、各サブスクリプションの最近のアクティビティ (過去 14 日間) と、サブスクリプションが有効か、無効か、または制限されているかが表示されます。

問題のあるサービスまたはサブスクリプションのデバッグに役立つ詳細な要求/応答データを含む、サブスクリプションに関する詳細な履歴にアクセスできます。

  1. サブスクリプションのアクティビティと状態を表示するには、[サービス フック] ページに移動します。

    サブスクリプションのアクティビティと状態のビューを示すスクリーンショット。

  2. 完全な要求、応答、イベント ペイロード データなど、サブスクリプションの詳細なアクティビティを表示するには、テーブルでサブスクリプションを選択し、[履歴] を選択します

    サブスクリプションのアクティビティの詳細ビューを示すスクリーンショット。

サブスクリプションの障害と保護観察 (制限付き)

エラーの種類

サービス フック通知からのエラーは、次のカテゴリにグループ化されます。

  • ターミナルエラー
  • 一時的な障害
  • 永続的な障害

ターミナルエラー

唯一のターミナル エラーは HTTP 状態コード 410 (Gone) です。 サブスクリプションにターミナル エラーが表示されると、以前の状態に関係なく自動的に無効になります。

一時的な障害

サブスクリプションで一時的な障害が発生すると、通知の再送信が最大 8 回試行され、各試行の間に遅延が増加します。 一時的なエラーには、次のコードが含まれます。

  • 408 (要求タイムアウト)
  • 502 (無効なゲートウェイ)
  • 503 (サービスを利用できません)
  • 504 (ゲートウェイ タイムアウト)

一時的な障害に対する再試行のシーケンス

再試行# 待機時間
再試行前 1 最大 1 秒待つ
再試行前 2 最大 2 秒待機 (合計 3 秒の遅延)
再試行前 3 最大 4 秒待機 (合計 7 秒の遅延)
再試行前 4 最大 8 秒待機 (合計 15 秒の遅延)
再試行前 5 最大 16 秒待機 (合計遅延 31 秒)
再試行前 6 最大 32 秒待機 (合計遅延 63 秒)
再試行前 7 最大 60 秒待機 (最大バックオフ時間、合計遅延 123 秒)
再試行前 8 最大 60 秒待機 (最大バックオフ時間、合計遅延 183 秒)

通知が再試行をすべて使い果たし、試行ごとに一時的なエラーが引き続き表示される場合、サブスクリプションは通知の送信を停止し、永続的なエラーが発生したかのように通知を処理します。

永続的な障害

永続的なエラーには、404 (見つかりません)、500 (内部サーバー エラー) など、他のすべての HTTP エラー コードが含まれます。

サブスクリプションに永続的なエラーが表示されると、保護観察が行 われます

Probation

保護観察中、サブスクリプションは送信できる通知の数に制限されます。 サブスクリプションが永続的な障害に達し続ける場合は、ますます制限され、最終的に無効になります。 保護観察中にサブスクリプションが正常な応答を受信すると、完全に有効な状態に復元されます。

サブスクリプションが保護観察中の最大 7 回の再試行のシーケンス

サブスクリプションが保護観察中の場合、新しいイベントはすべて失われます。 再試行が成功すると、サブスクリプションが有効になり、イベントが再び発行されます。

再試行# 待機時間
再試行前 1 最大 20 分待つ
再試行前 2 最大 40 分待機 (1 時間の総保護観察時間)
再試行前 3 約 1 時間 20 分待機 (総保護観察時間は 2.33 時間)
再試行前 4 約 2 時間 40 分待機 (総保護観察時間は 5 時間)
再試行前 5 約 5 時間 20 分待機 (総保護観察時間は 10.33 時間)
再試行前 6 約 10 時間 40 分待機 (総保護観察時間は 21 時間)
再試行前 7 最大 15 時間待機 (最大バックオフ時間、総保護観察時間は 36 時間)

7 回の再試行の後、コンシューマーへの通知が失敗した場合、サブスクリプションの状態は DisabledBySystem設定されます。

よく寄せられる質問

Q: サービス フックのペイロード制限は何ですか?

A: ペイロードの制限は 2 MB (メガバイト)です。 ペイロードが大きくなると、パフォーマンスと信頼性は低下します。 ベスト プラクティスとして、サービスフックはペイロードを 2 MB 以下に制限する必要があります。

Q: 有効 (制限付き) 状態とはどういう意味ですか?

A: 多すぎるエラーが発生すると、サブスクリプションが制限されます。 有効 (制限付き) は、保護観察中と同じです。

Q: 状態が無効 (失敗による) とはどういう意味ですか?

A: サブスクリプションは、長期間にわたって連続する一連の障害が発生した後、またはターミナルの障害が発生した後に自動的に無効になります。 一時的な障害の 種類は、エラーとして宣言される前に複数回再試行されます。 永続的な障害 の種類は再試行されません。 エラーの種類ごとの例を次に示します。

  • 一時的: 408 (要求タイムアウト)、502 (無効なゲートウェイ)、503 (サービス利用不可)、504 (ゲートウェイ タイムアウト)
  • ターミナル: 410 (Gone)
  • 永続的: 一時的またはターミナルではないすべての障害

Q: 状態が [無効] (ユーザーが左のプロジェクト) とはどういう意味ですか?

A: サブスクリプションを作成したユーザーは、チームのメンバーではなくなりました。

Q: サービス フックが機能しない場合はどうすればよいですか?

A: 次の項目を確認します。

  • サブスクリプションが有効になっていることを確認する

  • サブスクリプション設定が正しいことを確認します (イベント フィルターとアクションの両方)

  • 特にエラーがある場合は、履歴を確認します

Q: 通常のプロジェクト ユーザーに、プロジェクトのサービス フック サブスクリプションを表示および管理する権限を付与できますか。

A: 既定では、これらのアクセス許可を持つのはプロジェクト管理者だけです。 他のユーザーに直接付与するには、コマンド ライン ツールまたは Security REST API を使用できます。

Q: プログラムでサブスクリプションを作成できますか?

A: はい。REST API を使用 します