サービス フックのトラブルシューティング
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
この記事は、一般的なトラブルシューティングのガイダンスと、よく寄せられる質問 (FAQ) に対する回答に使用します。
アクティビティの表示と問題のデバッグ
Web アクセス管理者の [サービス フック] ページには、各サブスクリプションの最近のアクティビティ (過去 14 日間) と、サブスクリプションが有効か、無効か、または制限されているかが表示されます。
問題のあるサービスまたはサブスクリプションのデバッグに役立つ詳細な要求/応答データを含む、サブスクリプションに関する詳細な履歴にアクセスできます。
サブスクリプションのアクティビティと状態を表示するには、[サービス フック] ページに移動します。
完全な要求、応答、イベント ペイロード データなど、サブスクリプションの詳細なアクティビティを表示するには、テーブルでサブスクリプションを選択し、[履歴] を選択します。
サブスクリプションの障害と保護観察 (制限付き)
エラーの種類
サービス フック通知からのエラーは、次のカテゴリにグループ化されます。
- ターミナルエラー
- 一時的な障害
- 永続的な障害
ターミナルエラー
唯一のターミナル エラーは 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 を使用 します。