Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022
Cet article fournit des conseils de dépannage généraux pour les hooks de service Azure DevOps. Il fournit également des réponses aux questions fréquemment posées (FAQ).
Afficher l'activité et déboguer les problèmes
La page Crochets de Service dans la console d'administration web récapitule l'activité des sept derniers jours pour chaque abonnement. La page indique également si chaque abonnement est activé, désactivé ou restreint.
Pour chaque abonnement, vous pouvez accéder à un historique détaillé qui inclut les données de demande et de réponse complètes pour chaque événement. Ces informations peuvent vous aider à déboguer un service ou un abonnement problématique.
Pour afficher l’activité et l’état de vos abonnements, accédez à la page Service Hooks.
Pour afficher l’activité détaillée d’un abonnement, notamment les données complètes de la demande, de la réponse et de la charge utile des événements, sélectionnez un abonnement dans la table, puis sélectionnez Historique.
Échecs d’abonnement et mises en probation (restreintes)
Si la réponse HTTP à une demande de notification indique une erreur, la gravité de l’échec détermine la façon dont Azure DevOps répond. Certains types d’échecs peuvent désactiver les abonnements ou les mettre en probation.
Types d’échecs
Les échecs des notifications de crochet de service sont regroupés dans les catégories suivantes :
- Défaillances du terminal
- Échecs temporaires
- Défaillances durables
Le code d’erreur de la réponse HTTP détermine comment Azure DevOps classe l’échec.
Défaillances du terminal
Le seul code d’état HTTP classé en tant qu’échec de terminal est 410 (Disparu).
Lorsqu’un échec de terminal se produit dans un abonnement, l’abonnement est automatiquement désactivé, quel que soit son état antérieur.
Échecs temporaires
Les réponses HTTP avec les codes d’état suivants sont classées comme des échecs temporaires :
- 408 (Délai d’expiration de la demande)
- 502 (Mauvaise Passerelle)
- 503 (Service indisponible)
- 504 (Dépassement du délai de la passerelle)
Lorsqu’un échec temporaire se produit dans un abonnement, Azure DevOps tente de renvoyer la notification jusqu’à huit fois, avec un délai croissant entre chaque tentative.
Le tableau suivant répertorie des informations sur les nouvelles tentatives tentées après un échec temporaire. Il s’agit du délai d’interruption approximatif ou du délai d’attente avant de tenter de renvoyer une notification. Le délai maximal d’interruption est de 60 secondes. Le tableau affiche également le délai total pour chaque nouvelle tentative.
| Nombre de nouvelles tentatives | Délai d’interruption en secondes | Délai total en secondes |
|---|---|---|
| 1 | 1 | 1 |
| 2 | 2 | 3 |
| 3 | 4 | 7 |
| 4 | 8 | 15 |
| 5 | 16 | 31 |
| 6 | 32 | 63 |
| 7 | soixante | 123 |
| 8 | soixante | 183 |
Si toutes les nouvelles tentatives d’une notification sont épuisées et que chaque tentative entraîne un échec temporaire, la notification n’est plus envoyée. Au lieu de cela, il est classé comme un échec durable.
Défaillances durables
Tous les autres codes d’échec HTTP, par exemple, 404 (introuvable) et 500 (erreur de serveur interne), entraînent des défaillances durables.
Lorsqu’un échec durable se produit dans un abonnement, l’abonnement est mis en probation.
Probation
Lorsqu’un abonnement est en probation, tous les nouveaux événements sont perdus. Le système effectue un nombre limité de tentatives pour renvoyer la notification ayant échoué.
Le tableau suivant répertorie les délais d’interruption approximatifs et le temps de probation total pour les nouvelles tentatives effectuées pendant la probation : Au plus sept nouvelles tentatives sont tentées, et le délai maximal d’interruption pour une nouvelle tentative de probation est de 15 heures.
| Nombre de nouvelles tentatives | Temps de recul | Durée totale de probation en heures |
|---|---|---|
| 1 | 20 minutes | 0,33 |
| 2 | 40 minutes | 1 |
| 3 | 1 heure 20 minutes | 2.33 |
| 4 | 2 heures 40 minutes | 5 |
| 5 | 5 heures 20 minutes | 10,33 |
| 6 | 10 heures 40 minutes | Vingt-et-un |
| 7 | 15 heures | 36 |
Si l’abonnement reçoit une réponse réussie lors de la probation, il est restauré à un état entièrement activé et les événements sont publiés à nouveau. Si les sept nouvelles tentatives échouent, l’état de l’abonnement est défini sur DisabledBySystem.
Utiliser l’IA pour résoudre les problèmes d’un hook de service
L’exemple d’invite suivant pour Copilot Chat aide Copilot à résoudre votre code d’erreur et votre message. Copiez et collez cette invite dans Copilot Chat, en remplaçant l’espace réservé par votre message d’erreur spécifique.
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.
Questions fréquentes (FAQ)
Q : Quelle est la limite de charge utile d’un hook de service ?
Un: La limite de charge utile est de 2 Mo. Les charges utiles plus volumineuses entraînent une dégradation des performances et de la fiabilité. En tant que meilleure pratique, les service hooks doivent limiter la charge utile à 2 Mo.
Q : Que signifie l’état Activé (restreint) ?
A: Un abonnement devient restreint si trop d'échecs se produisent. L’état Activé (restreint) est identique à celui de la probation.
Q : Que signifie l’état Désactivé (en raison de pannes) ?
Un: Un abonnement est automatiquement désactivé dans les cas suivants :
- Une défaillance de terminal est rencontrée.
- Une série de défaillances consécutives se produit sur une période prolongée.
Les notifications qui entraînent des échecs temporaires sont retentées plusieurs fois avant d’être déclarées en cas d’échecs durables. Les notifications d’échec durables sont retentées un nombre limité de fois pendant la probation. Si toutes les tentatives de probation échouent, l’abonnement est désactivé.
Les codes d’état suivants fournissent des exemples de chaque type de défaillance :
- Temporaire : 408 (Délai d’expiration de la demande), 502 (Passerelle incorrecte), 503 (Service indisponible), 504 (Dépassement du délai de la passerelle)
- Terminal : 410 (Disparu)
- Durable : toutes les défaillances qui ne sont pas temporaires ou terminales
Q : Que signifie l'état Désactivé (utilisateur a quitté le projet) ?
Un: L’utilisateur qui a créé l’abonnement n’est plus membre de l’équipe.
Q : Que dois-je essayer si un hook de service ne fonctionne pas ?
A: Vérifiez les éléments suivants :
- Vérifiez que l’abonnement est activé.
- Vérifiez que les paramètres d’abonnement sont corrects. Vérifiez les filtres d’événements et les actions.
- Examinez l’historique, en particulier s’il y a des défaillances.
Q : Puis-je accorder à un utilisateur régulier du projet la possibilité de visualiser et gérer les abonnements de crochet de service pour un projet ?
Un: Par défaut, seuls les administrateurs de projet disposent de ces autorisations. Pour les accorder directement à d’autres utilisateurs, vous pouvez utiliser l’outil en ligne de commande ou l’API REST de sécurité .
Q : Puis-je créer des abonnements par programmation ?
Un: Oui, utilisez des API REST.