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

Azure DevOps サービス |Azure DevOps Server |Azure DevOps Server 2022

この記事では、Azure DevOps サービス フックの一般的なトラブルシューティング ガイダンスを提供します。 また、よく寄せられる質問 (FAQ) に対する回答も提供されます。

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

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

サブスクリプションごとに、各イベントの要求と応答の完全なデータを含む詳細な履歴にアクセスできます。 この情報は、問題のあるサービスまたはサブスクリプションをデバッグするのに役立ちます。

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

    サブスクリプションの状態、状態、およびその他のデータを示すサービス フック ページのスクリーンショット。Project設定とサービス フックが強調表示されています。

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

    状態、メッセージ、エラー メッセージなど、失敗したイベントの詳細情報を含むサブスクリプションの履歴を示すスクリーンショット。

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

通知要求に対する HTTP 応答がエラーを示している場合、エラーの重大度によってAzure DevOpsの応答方法が決まります。 特定の種類の障害では、サブスクリプションを無効にしたり、保護観察に入れたりすることができます。

エラーの種類

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

  • ターミナルの障害
  • 一時的な障害
  • 継続的な障害

HTTP 応答のエラー コードによって、エラー Azure DevOps分類する方法が決まります。

ターミナルの障害

ターミナル エラーとして分類される HTTP 状態コードは 410 (Gone) のみです。

サブスクリプションでターミナルエラーが発生すると、その前の状態に関係なく、サブスクリプションは自動的に無効になります。

一時的な障害

次の状態コードを含む HTTP 応答は、一時的なエラーとして分類されます。

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

サブスクリプションで一時的な障害が発生した場合、Azure DevOpsは通知の再送信を最大 8 回試行し、各試行の間に遅延が増加します。

次の表に、一時的な障害が発生した後に試行される再試行に関する情報を示します。 含まれるのは、おおよその バックオフ 時間、または通知の再送信を試みるまでの待機時間です。 バックオフの最大時間は 60 秒です。 この表には、各再試行の合計遅延も示されています。

再試行回数 バックオフ時間 (秒単位) 合計遅延時間 (秒)
1 1 1
2 2 3
3 4 7
4 8 15
5 16 31
6 32 63
7 六十 123
8 六十 183

通知のすべての再試行が使い果たされ、試行するたびに一時的なエラーが発生した場合、通知は送信されなくなります。 代わりに、永続的なエラーとして分類されます。

継続的な障害

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

サブスクリプションで永続的なエラーが発生すると、サブスクリプションは 保護観察中になります。

保護観察

サブスクリプションが保護観察中の場合、新しいイベントは失われます。 システムは、失敗した通知の再送信を制限された回数だけ試行します。

次の表に、システムが保護観察中に試行する再試行のおおよそのバックオフ時間と保護観察時間の合計を示します。 システムは最大 7 回の再試行を試行し、保護観察再試行の最大バックオフ時間は 15 時間です。

再試行回数 バックオフ時間 総保護観察時間 (時間単位)
1 20 分 0.33
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 に設定します。

非アクティブのためサブスクリプションが無効になっている

Azure DevOps、最新の正常な通知配信が 6 か月以上前の場合、サブスクリプションは自動的に無効になります。 サブスクリプションは、ユーザーが再度有効になるまでイベントの受信を停止します。

この非アクティブ チェックでは、最後に成功した配信のみが考慮されます。 サブスクリプションがいつ作成されたか、最後に編集されたか、またはサブスクリプションに一致したイベントの数は考慮されません。 通知を正常に配信し続けるサブスクリプションは、有効期間に関係なく、非アクティブのため無効になりません。 成功した配信が記録されていないサブスクリプションは、非アクティブ チェックの影響を受けません。

AI を使用してサービス フックのトラブルシューティングを行う

次の例のプロンプトは、Copilot Chatでエラーコードとメッセージのトラブルシューティングに役立ちます。 このプロンプトをコピーしてCopilot Chatに貼り付け、プレースホルダーを特定のエラー メッセージに置き換えます。

I'm getting this Azure DevOps service hook error: [PASTE YOUR ERROR MESSAGE HERE]

Can you help me troubleshoot this issue? Please provide step-by-step instructions to:
1. Identify the root cause
2. Fix the issue
3. Verify the solution works

Context: This is for a service hook in Azure DevOps.

よく寄せられる質問

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

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

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

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

Q: サブスクリプションが無効になるのはなぜですか?

ある: サブスクリプションは、次の場合に自動的に無効になります。

  • ターミナルエラーが発生しました。
  • 一連の連続した障害は、長期間にわたって発生します。
  • その最新の成功した通知配信は、6 か月以上前でした。
  • サブスクリプションを作成したユーザーは、チームのメンバーではなくなりました。

Q: 無効化されている状態 (障害のため) とはどういう意味ですか?

A: 一時的なエラーが発生した通知は、永続的なエラーとして宣言される前に複数回再試行されます。 永続的なエラー通知は、 保護観察中に限られた回数だけ再試行されます。 すべての試用再試行が失敗した場合、サブスクリプションは無効になります。

次の状態コードは、各種類のエラーの例を示しています。

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

Q: 状態が無効 (非アクティブのため) とはどういう意味ですか?

A:サブスクリプションの最新の成功した通知配信は 6 か月以上前であるため、Azure DevOps無効にしました。 この状態は無効 (障害のため) とは異なります。つまり、Azure DevOps配信が試行され、配信が繰り返し失敗したことを意味します。 統合がまだ必要な場合は、サブスクリプションを再度有効にします。

Q: 非アクティブなサブスクリプションが無効になっているのはなぜですか?

A: Azure DevOpsは、受信統合がアクティブでなくなった場合でも、一致するイベントが発行されたときにすべてのサブスクリプションを評価します。 時間が経つにつれて、パイプラインが廃止され、統合が破棄されるため、組織は非アクティブなサブスクリプションを蓄積できます。 一部の組織には、数年で通知を配信しなかった数万のサブスクリプションがあります。 非アクティブなサブスクリプションを無効にすると、引き続き使用中のサブスクリプションに対してサービス フックを高速かつ信頼性の高い状態に保つことができます。

Q: 無効 (ユーザーがプロジェクトを離れた) の状態はどういう意味ですか?

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

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

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

  • サブスクリプションが有効であることを確認します。
  • サブスクリプションの設定が正しいことを確認します。 イベント フィルターとアクションを確認します。
  • 特にエラーがある場合は、履歴を確認します。

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

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

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

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