Share via

Guide de dépannage pour Azure Service Bus

  • Article

Cet article fournit des conseils et des recommandations pour résoudre certains problèmes que vous pourriez rencontrer lors de l’utilisation d’Azure Service Bus.

Problèmes de connectivité

Expiration du délai d’attente lors de la connexion au service

En fonction de l’environnement hôte et du réseau, un problème de connectivité peut se présenter aux applications en tant que TimeoutException, OperationCanceledException ou ServiceBusException avec comme ReasonServiceTimeout, et le plus souvent se produit lorsque le client ne peut pas trouver un chemin réseau vers le service.

Pour résoudre les problèmes :

  • Vérifiez que la chaîne de connexion ou le nom de domaine complet que vous avez spécifié lors de la création du client est correct. Pour plus d’informations sur l’acquisition d’une chaîne de connexion, consultez Obtenir une chaîne de connexion Service Bus.
  • Vérifiez les autorisations de pare-feu et de port dans votre environnement d’hébergement. Vérifiez que les ports AMQP (Advance Message Queueing Protocol) 5671 et 5672 sont ouverts, et que le point de terminaison est autorisé à traverser le pare-feu.
  • Essayez d’utiliser l’option de transport Web Socket qui se connecte à l’aide du port 443. Pour plus d’informations, consultez Configurer le transport.
  • Vérifiez si votre réseau bloque des adresses IP spécifiques. Pour plus d’informations, consultez Quelles adresses IP dois-je autoriser ?
  • Le cas échéant, vérifiez la configuration du proxy. Pour plus d’informations, consultez Configuration du transport.
  • Pour plus d’informations sur la résolution des problèmes de connectivité réseau, consultez : [Problèmes de connectivité, de certificat ou de délai d’expiration][#connectivity-certificate-or-timeout-issues].

Échecs d’établissement d’une liaison SSL (Secure Socket Layer)

Cette erreur peut se produire lorsqu’un proxy d’interception est utilisé. Pour vérifier, nous vous recommandons de tester l’application dans l’environnement hôte avec le proxy désactivé.

Erreurs d’épuisement de socket

Les applications doivent préférer traiter les types Service Bus en tant que singletons, créant et utilisant une seule instance tout au long de la durée de vie de l’application. Chaque nouveau ServiceBusClient créé entraîne une nouvelle connexion AMQP, qui utilise un socket. Le type ServiceBusClient gère la connexion pour tous les types créés à partir de cette instance. Chaque ServiceBusReceiver, ServiceBusSessionReceiver, ServiceBusSender et ServiceBusProcessor gère sa propre liaison AMQP pour l’entité Service Bus associée. Lorsque vous utilisez ServiceBusSessionProcessor, plusieurs liaisons AMQP sont établies en fonction du nombre de sessions traitées simultanément.

La mise en cache des clients est sans risque lorsqu’ils sont inactifs ; ils garantissent une gestion efficace du réseau, du processeur et de la mémoire, ce qui réduit leur impact pendant les périodes d’inactivité. Il est également important d’appeler CloseAsync ou DisposeAsync lorsqu’un client n’est plus nécessaire, afin de s’assurer que les ressources réseau sont correctement nettoyées.

L’ajout de composants à la chaîne de connexion ne fonctionne pas

La génération actuelle de la bibliothèque de client Service Bus prend en charge les chaînes de connexion uniquement sous la forme publiée par le portail Azure. Les chaînes de connexion sont destinées uniquement à fournir des informations de base sur l’emplacement et les clés partagées. La configuration du comportement des clients est effectuée via leurs options.

Les générations précédentes des clients Service Bus autorisaient la configuration d’un comportement en ajoutant des composants clé/valeur à une chaîne de connexion. Ces composants ne sont plus reconnus et n’ont aucun effet sur le comportement du client.

Alternative « TransportType=AmqpWebSockets »

Pour configurer Web Sockets comme type de transport, consultez Configuration du transport.

Alternative « Authentication=Managed Identity »

Pour vous authentifier avec Managed Identity, consultez : Informations d’identification d’identité et d’accès partagé. Pour plus d’informations sur la bibliothèque Azure.Identity, consultez Authentification et le SDK Azure.

Journalisation et diagnostics

La bibliothèque de client Service Bus est entièrement instrumentée pour la journalisation des informations à différents niveaux de détail en utilisant le EventSource .NET pour émettre des informations. La journalisation est effectuée pour chaque opération, et suit le modèle de marquage du point de départ de l’opération, de son achèvement et de toutes les exceptions rencontrées. Des informations supplémentaires susceptibles d’offrir des insights sont également consignées dans le contexte de l’opération associée.

Activation de la journalisation

Les journaux du client Service Bus sont accessibles à tout EventListener en s’abonnant aux sources commençant par Azure-Messaging-ServiceBus ou en s’abonnant à toutes les sources qui ont la caractéristique AzureEventSource. Pour faciliter la capture des journaux à partir des bibliothèques de client Azure, la bibliothèque Azure.Core utilisée par Service Bus offre un AzureEventSourceListener.

Pour plus d’informations, consultez Journalisation avec le SDK Azure pour .NET.

Traçage distribué

La bibliothèque de client Service Bus prend en charge le suivi distribué par le biais de l’intégration au SDK Application Insights. Elle offre également une prise en charge expérimentale de la spécification OpenTelemetry via le type .NET ActivitySource introduit dans .NET 5. Pour activer la prise en charge d’ActivitySource pour l’utilisation avec OpenTelemetry, consultez Prise en charge d’ActivitySource.

Pour utiliser la prise en charge de DiagnosticActivity en disponibilité générale, vous pouvez intégrer au SDK Application Insights. Vous trouverez plus d’informations dans ApplicationInsights avec Azure Monitor.

La bibliothèque crée les étendues suivantes :

Message
ServiceBusSender.Send
ServiceBusSender.Schedule
ServiceBusSender.Cancel
ServiceBusReceiver.Receive
ServiceBusReceiver.ReceiveDeferred
ServiceBusReceiver.Peek
ServiceBusReceiver.Abandon
ServiceBusReceiver.Complete
ServiceBusReceiver.DeadLetter
ServiceBusReceiver.Defer
ServiceBusReceiver.RenewMessageLock
ServiceBusSessionReceiver.RenewSessionLock
ServiceBusSessionReceiver.GetSessionState
ServiceBusSessionReceiver.SetSessionState
ServiceBusProcessor.ProcessMessage
ServiceBusSessionProcessor.ProcessSessionMessage
ServiceBusRuleManager.CreateRule
ServiceBusRuleManager.DeleteRule
ServiceBusRuleManager.GetRules

La plupart des étendues sont explicites, et sont démarrées et arrêtées pendant l’opération qui porte leur nom. L’étendue qui lie les autres est Message. Le message est suivi via le Diagnostic-Id défini dans la propriété ServiceBusMessage.ApplicationProperties par la bibliothèque pendant les opérations d’envoi et de planification. Dans Application Insights, les étendues Message sont affichées sous forme de liaison vers les diverses autres étendues utilisées pour interagir avec le message ; par exemple, l’étendue ServiceBusReceiver.Receive, l’étendue ServiceBusSender.Send et l’étendue ServiceBusReceiver.Complete seraient toutes liées à partir de l’étendue Message. Voici un exemple de ce à quoi cela ressemble dans Application Insights :

Image showing a sample distributed trace.

Dans la capture d’écran ci-dessus, vous voyez la transaction de bout en bout qui peut être consultée dans Application Insights dans le portail. Dans ce scénario, l’application envoie des messages et utilise le ServiceBusSessionProcessor pour les traiter. L’activité Message est liée à ServiceBusSender.Send, ServiceBusReceiver.Receive, ServiceBusSessionProcessor.ProcessSessionMessage et ServiceBusReceiver.Complete.

Remarque

Pour plus d’informations, consultez Suivi distribué et corrélation via la messagerie Service Bus.

Résoudre les problèmes liés à l’expéditeur

Impossible d’envoyer un lot avec plusieurs clés de partition

Lorsqu’une application envoie un lot à une entité prenant en charge les partitions, tous les messages inclus dans une opération d’envoi unique doivent avoir la même PartitionKey. Si votre entité prend en charge les sessions, la même exigence est vraie pour la propriété SessionId. Pour envoyer des messages avec des valeurs PartitionKey ou SessionId différentes, regroupez les messages dans des instances ServiceBusMessageBatch distinctes ou incluez-les dans des appels distincts à la surcharge SendMessagesAsync qui accepte un ensemble d’instances ServiceBusMessage.

L’envoi du lot échoue

Un lot de messages est soit ServiceBusMessageBatch contenant deux messages ou plus, ou un appel à SendMessagesAsync où deux messages ou plus sont transmis. Le service n’autorise pas qu’un lot de messages dépasse 1 Mo. Ce comportement est vrai, que la fonctionnalité de prise en charge des messages volumineux Premium soit activée ou non. Si vous envisagez d’envoyer un message supérieur à 1 Mo, il doit être envoyé individuellement plutôt que regroupé avec d’autres messages. Malheureusement, le type ServiceBusMessageBatch ne prend actuellement pas en charge la validation du fait qu’un lot ne contient aucun message supérieur à 1 Mo, car la taille est limitée par le service et peut changer. Par conséquent, si vous envisagez d’utiliser la fonctionnalité de prise en charge des messages volumineux Premium, assurez-vous que vous envoyez les messages de plus de 1 Mo individuellement.

Résoudre les problèmes liés au récepteur

Le nombre de messages retournés ne correspond pas au nombre demandé dans la réception par lot

Lorsque vous tentez d’effectuer une opération de réception par lot, autrement dit de transmettre une valeur maxMessages de deux ou plus à la méthode ReceiveMessagesAsync, il n’est pas garanti que vous receviez le nombre de messages demandés, même si la file d’attente ou l’abonnement contient ce nombre de messages disponibles à ce moment-là, et même si le délai maxWaitTime entier configuré n’a pas encore expiré. Pour optimiser le débit et éviter l’expiration du verrou, une fois que le premier message est passé sur le câble, le récepteur attend des messages supplémentaires pendant 20 millisecondes supplémentaires avant de distribuer les messages à traiter. maxWaitTime contrôle la durée pendant laquelle le récepteur attend de recevoir le premier message ; les messages suivants sont attendus pendant 20 millisecondes. Par conséquent, votre application ne doit pas partir du principe que tous les messages disponibles seront reçus lors d’un appel unique.

Le verrouillage de message ou de session est perdu avant la durée d’expiration du verrou

Le service Service Bus utilise le protocole AMQP, qui est avec état. En raison de la nature du protocole, si le lien qui connecte le client et le service est détaché une fois qu’un message est reçu, mais avant qu’il ne soit résolu, le message ne peut pas l’être lors de la reconnexion du lien. Les liens peuvent être détachés en raison d’une défaillance réseau temporaire à court terme, d’une panne du réseau ou d’un délai d’inactivité de 10 minutes imposé par le service. La reconnexion du lien se produit automatiquement dans le cadre d’une opération qui nécessite le lien, autrement dit, l’installation ou la réception de messages. Dans ce cas, vous recevez un ServiceBusException avec comme ReasonMessageLockLost ou SessionLockLost même si le délai d’expiration du verrou n’a pas encore été atteint.

Comment parcourir les messages planifiés ou différés

Les messages planifiés et différés sont inclus lors de l’aperçu des messages. Ils peuvent être identifiés par la propriété ServiceBusReceivedMessage.State. Une fois que vous avez le SequenceNumber d’un message différé, vous pouvez le recevoir avec un verrou via la méthode ReceiveDeferredMessagesAsync.

Lorsque vous utilisez des rubriques, vous ne pouvez pas consulter les messages planifiés sur l’abonnement, car les messages restent dans la rubrique jusqu’à l’horaire de mise en file d’attente planifié. Pour contourner ce problème, vous pouvez construire un ServiceBusReceiver transmettant le nom de la rubrique afin d’afficher un aperçu ces messages. Aucune autre opération avec le récepteur ne fonctionne lors de l’utilisation d’un nom de rubrique.

Comment parcourir les messages de session entre toutes les sessions

Vous pouvez utiliser un ServiceBusReceiverstandard pour afficher un aperçu entre toutes les sessions. Pour afficher un aperçu pour une session spécifique, vous pouvez utiliser le ServiceBusSessionReceiver, mais vous devez obtenir un verrou de session.

NotSupportedException levée lors de l’accès au corps du message

Ce problème se produit le plus souvent dans les scénarios d’interopérabilité lors de la réception d’un message envoyé à partir d’une autre bibliothèque qui utilise un autre format de corps de message AMQP. Si vous interagissez avec ces types de messages, consultez l’exemple de corps de message AMQP pour savoir comment accéder au corps du message.

Résoudre les problèmes liés au processeur

Le renouvellement du verrouillage automatique ne fonctionne pas

Le renouvellement du verrouillage automatique s’appuie sur l’heure système pour déterminer quand renouveler un verrou pour un message ou une session. Si l’heure de votre système n’est pas exacte, par exemple si votre horloge est en avance, le renouvellement du verrouillage peut ne pas se produire avant la perte du verrou. Vérifiez que l’heure système est exacte si le renouvellement du verrouillage automatique ne fonctionne pas.

Le processeur semble se bloquer ou avoir des problèmes de latence lors de l’utilisation d’une concurrence élevée

Ce comportement est souvent dû à la privation de thread, en particulier lors de l’utilisation du processeur de session et de l’utilisation d’une valeur très élevée pour MaxConcurrentSessions, par rapport au nombre de cœurs sur la machine. La première chose à faire est de vérifier que vous n’effectuez pas de sync sur async dans l’un de vos gestionnaires d’événements. Une opération sync sur async est un moyen simple de provoquer des blocages et une privation de thread. Même si vous n’effectuez pas d’opération sync sur async, tout code synchrone pur dans vos gestionnaires peut contribuer à la privation de thread. Si vous avez déterminé que ce n’est pas le problème, par exemple, car vous avez du code asynchrone pur, vous pouvez essayer d’augmenter votre [TryTimeout][TryTimeout]. Il réduit la pression sur le pool de threads en réduisant le nombre de commutateurs de contexte et d’expirations de délai d’attente qui se produisent lors de l’utilisation du processeur de session en particulier. La valeur par défaut de [TryTimeout][TryTimeout] est de 60 secondes, mais elle peut être définie jusqu’à une heure. Nous vous recommandons de tester avec TryTimeout défini sur cinq minutes comme point de départ, et d’itérer à partir de là. Si aucune de ces suggestions ne fonctionne, vous devez simplement effectuer un scale-out vers plusieurs hôtes, ce qui réduit la concurrence dans votre application, mais en exécutant l’application sur plusieurs hôtes afin d’obtenir la concurrence globale souhaitée.

Pour aller plus loin :

Le processeur de session prend trop de temps pour changer de session

Cela peut être configuré à l’aide de [SessionIdleTimeout][SessionIdleTimeout], qui indique au processeur combien de temps attendre pour recevoir un message d’une session, avant d’abandonner et de passer à une autre. Il est utile si vous avez de nombreuses sessions partiellement remplies, où chaque session ne contient que quelques messages. Si vous vous attendez à ce que chaque session ait de nombreux messages qui arrivent petit à petit, l’affectation d’une valeur trop faible peut être contre-productive, car cela entraîne la fermeture inutile de la session.

Le processeur s’arrête immédiatement

Cela est souvent observé pour les scénarios de démonstration ou de test. StartProcessingAsync retourne immédiatement après le démarrage du processeur. L’appel de cette méthode ne bloque pas et ne maintient pas votre application active pendant l’exécution du processeur. Vous auvez donc besoin d’un autre mécanisme pour le faire. Pour les démonstrations ou les tests, il suffit d’ajouter un appel Console.ReadKey() après avoir démarré le processeur. Pour les scénarios de production, vous souhaiterez probablement utiliser une sorte d’intégration de framework comme [BackgroundService][BackgroundService] pour fournir des hooks pratiques de cycle de vie d’application qui peuvent être utilisés pour démarrer et supprimer le processeur.

Résoudre les problèmes liés aux transactions

Pour obtenir des informations générales sur les transactions dans Service Bus, consultez [Vue d’ensemble du traitement des transactions Service Bus][Transactions].

Opérations prises en charge

Toutes les opérations ne sont pas prises en charge lors de l’utilisation des transactions. Pour afficher la liste des transactions prises en charge, consultez [Opérations dans une étendue de transaction][TransactionOperations].

Délai d'expiration

Une transaction expire après une [période de temps][TransactionTimeout] ; il est donc important que le traitement qui se produit dans une étendue de transaction respecte ce délai d’expiration.

Les opérations dans une transaction ne sont pas retentées

C'est la procédure normale. Considérez le scénario suivant : vous tentez d’exécuter un message au sein d’une transaction, mais une erreur temporaire se produit, par exemple, ServiceBusException avec comme ReasonServiceCommunicationProblem. Supposez que la requête finisse par atteindre le service. Si le client réessayait, le service verrait deux requêtes terminées. La première ne sera pas finalisée tant que la transaction ne sera pas validée. La deuxième n’est même pas en mesure d’être évaluée avant la fin de la première. La transaction sur le client attend la fin de l’exécution. Cela crée un interblocage où le service attend que le client termine la transaction, mais où le client attend que le service reconnaisse la deuxième opération terminée. La transaction expirera au bout de deux minutes, mais il s’agit d’une mauvaise expérience utilisateur. Pour cette raison, nous ne réessayons pas d’opérations au sein d’une transaction.

Les transactions entre entités ne fonctionnent pas

Pour effectuer des transactions impliquant plusieurs entités, vous devez affecter la valeur true à la propriété ServiceBusClientOptions.EnableCrossEntityTransactions. Pour plus d’informations, consultez l’exemple [Transactions entre entités][CrossEntityTransactions].

Quotas

Les informations sur les quotas Service Bus sont disponibles [ici][ServiceBusQuotas].

Problèmes de connectivité, de certificat ou de délai d’expiration

Aidez-vous des étapes suivantes pour résoudre les problèmes de connectivité, de certificat ou de délai d’expiration pour tous les services sous *.servicebus.windows.net.

  • Accédez à wget ou utilisez https://<yournamespace>.servicebus.windows.net/. Cet outil facilite les vérifications quand vous rencontrez des problèmes avec le filtrage des adresses IP, le réseau virtuel ou les chaînes de certificats, qui sont courants lors de l’utilisation du Kit de développement logiciel (SDK) Java.

    Voici un exemple de message de réussite :

    <feed xmlns="http://www.w3.org/2005/Atom"><title type="text">Publicly Listed Services</title><subtitle type="text">This is the list of publicly-listed services currently available.</subtitle><id>uuid:27fcd1e2-3a99-44b1-8f1e-3e92b52f0171;id=30</id><updated>2019-12-27T13:11:47Z</updated><generator>Service Bus 1.1</generator></feed>

    Voici un exemple de message d’échec :

    <Error>
    <Code>400</Code>
    <Detail>
        Bad Request. To know more visit https://aka.ms/sbResourceMgrExceptions. . TrackingId:b786d4d1-cbaf-47a8-a3d1-be689cda2a98_G22, SystemTracker:NoSystemTracker, Timestamp:2019-12-27T13:12:40
    </Detail>
</Error>

  • Exécutez la commande suivante pour vérifier si un port est bloqué sur le pare-feu. Les ports utilisés sont les suivants : 443 (HTTPS), 5671 et 5672 (AMQP), et 9354 (Net Messaging/SBMP). Selon la bibliothèque que vous utilisez, d’autres ports peuvent également être utilisés. Voici l’exemple de commande qui vérifie le blocage éventuel du port 5671. C

    tnc <yournamespacename>.servicebus.windows.net -port 5671

    Sur Linux :

    telnet <yournamespacename>.servicebus.windows.net 5671

  • Si vous constatez des problèmes de connectivité intermittents, exécutez la commande suivante pour détecter les paquets supprimés. Cette commande essaye d’établir 25 connexions TCP différentes au service toutes les secondes. Ensuite, vous pouvez vérifier le nombre d’entre elles ayant réussi ou échoué, ainsi que la latence de connexion TCP. Vous pouvez télécharger l’outil psping à partir d’psping.

    .\psping.exe -n 25 -i 1 -q <yournamespace>.servicebus.windows.net:5671 -nobanner

    Vous pouvez utiliser des commandes équivalentes dans d’autres outils, par exemple tnc, ping, etc.

  • Si les étapes précédentes n’ont pas résolu le problème, obtenez une trace réseau et analysez-la à l’aide d’un outil tel que Wireshark. Contactez le support Microsoft si nécessaire.

  • Pour trouver les adresses IP appropriées à ajouter à la liste d’autorisation de vos connexions, consultez Quelles adresses IP dois-je ajouter à la liste d’autorisation.

Le 30 septembre 2026, nous mettrons fin à la prise en charge du protocole SBMP pour Azure Service Bus. Vous ne pourrez donc plus utiliser ce protocole après le 30 septembre 2026. Migrez vers les dernières bibliothèques du SDK Azure Service Bus utilisant le protocole AMQP, qui offre des mises à jour de sécurité critiques et des fonctionnalités améliorées, avant cette date.

Pour plus d’informations, consultez l’annonce concernant l’arrêt de la prise en charge.

Problèmes qui peuvent se produire avec les mises à niveau/redémarrages du service

Symptômes

  • Les requêtes peuvent être momentanément limitées.
  • Il peut y avoir une chute des messages/requêtes entrantes.
  • Le fichier journal peut contenir des messages d’erreur.
  • Les applications peuvent être déconnectées du service pendant quelques secondes.

Cause

Les mises à niveau et redémarrages du service principal peuvent causer ces problèmes dans vos applications.

Résolution

Si le code d’application utilise le SDK, la stratégie de nouvelles tentatives est déjà intégrée et active. L’application se reconnecte sans impact significatif sur l’application/le workflow.

Accès non autorisé : Envoyer les revendications requises

Symptômes

Vous pouvez voir cette erreur lorsque vous tentez d’accéder à une rubrique Service Bus à partir de Visual Studio sur un ordinateur local à l’aide d’une identité managée affectée par l’utilisateur avec des autorisations d’envoi.

Service Bus Error: Unauthorized access. 'Send' claim\(s\) are required to perform this operation.

Cause

L’identité ne dispose pas des autorisations nécessaires pour accéder à la rubrique Service Bus.

Résolution

Pour résoudre cette erreur, installez la bibliothèque Microsoft.Azure.Services.AppAuthentication. Pour plus d’informations, consultez Authentification du développement local.

Pour savoir comment affecter des autorisations à des rôles, consultez Authentifier une identité managée avec Microsoft Entra ID pour accéder aux ressources Azure Service Bus.

Exception Service Bus : Échec du jeton PUT

Symptômes

Vous recevez le message d’erreur suivant :

Microsoft.Azure.ServiceBus.ServiceBusException: Put token failed. status-code: 403, status-description: The maximum number of '1000' tokens per connection has been reached.

Le 30 septembre 2026, nous retirerons les bibliothèques WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus et com.microsoft.azure.servicebus du kit de développement logiciel (SDK) Azure Service Bus, qui ne sont pas conformes aux directives du kit de développement logiciel (SDK) Azure. Nous mettrons également fin à la prise en charge du protocole SBMP. Vous ne pourrez donc plus utiliser ce protocole après le 30 septembre 2026. Migrez vers les dernières bibliothèques du kit de développement logiciel (SDK) Azure, qui offre des correctifs de sécurité critiques et des fonctionnalités améliorées, avant cette date.

Bien que les anciennes bibliothèques puissent toujours être utilisées au-delà du 30 septembre 2026, elles ne seront plus prises en charge officiellement et mises à jour par Microsoft. Pour plus d’informations, consultez l’annonce concernant l’arrêt de la prise en charge.

Cause

Le nombre de jetons d’authentification autorisé pour des liaisons simultanées dans une même connexion à un espace de noms Service Bus a dépassé la limite de 1 000.

Résolution

Effectuez l’une des étapes suivantes :

  • Réduire le nombre de liaisons simultanées dans une seule connexion ou utiliser une nouvelle connexion
  • Utilisez des SDK pour Azure Service Bus pour ne pas vous retrouver dans cette situation (recommandé)

Les verrous des ressources ne fonctionnent pas lors de l’utilisation du Kit de développement logiciel (SDK) du plan de données

Symptômes

Vous avez configuré un verrou de suppression sur un espace de noms Service Bus, mais vous pouvez supprimer des ressources dans l’espace de noms (files d’attente, rubriques, etc.) en utilisant l’outil Service Bus Explorer.

Cause

Le verrou de ressource est conservé dans Azure Resource Manager (plan de contrôle) et n’empêche pas l’appel du Kit de développement logiciel (SDK) du plan de données pour supprimer la ressource directement à partir de l’espace de noms. L’outil Service Bus Explorer autonome utilise le Kit de développement logiciel (SDK) du plan de données pour que la suppression soit traitée.

Résolution

Nous vous recommandons d’utiliser l’API Azure Resource Manager via le Portail Azure, PowerShell, l’interface CLI ou un modèle Resource Manager pour supprimer des entités afin que le verrou de ressource empêche la suppression accidentelle de ressources.

L’entité n’est plus disponible

Symptômes

Une erreur s’affiche car l’entité n’est plus disponible.

Cause

La ressource a peut-être été supprimée. Suivez ces étapes pour identifier la raison pour laquelle l’entité a été supprimée.

  • Vérifiez le journal d’activité pour voir s’il existe une demande de suppression Azure Resource Manager.
  • Vérifiez le journal opérationnel pour voir s’il y a eu un appel d’API direct pour suppression. Pour savoir comment collecter un journal opérationnel, consultez la section Collecte et routage. Pour obtenir le schéma et un exemple de journal des opérations, consultez la section Journaux des opérations
  • Vérifiez le journal des opérations pour voir s’il y a eu une suppression associée à autodeleteonidle.

Étapes suivantes

Voir les articles suivants :

  • Exceptions Azure Resource Manager. Répertorie les exceptions générées lors de l’interaction avec Azure Service Bus à l’aide d’Azure Resource Manager (via des modèles ou des appels directs).
  • Exceptions de messagerie. Fournit une liste d’exceptions générées par .NET Framework pour Azure Service Bus.