Guida alla risoluzione dei problemi per il bus di servizio di Azure

Questo articolo fornisce suggerimenti e raccomandazioni per la risoluzione di alcuni problemi che vengono visualizzati quando si usa il bus di servizio di Azure.

Problemi di connettività

Timeout durante la connessione al servizio

A seconda dell'ambiente host e della rete, potrebbe insorgere un problema di connettività per le applicazioni come TimeoutException, OperationCanceledException o un ServiceBusException con Reason di ServiceTimeout che spesso si verifica quando il client non riesce a trovare un percorso di rete al servizio.

Per risolvere il problema:

• Verificare che la stringa di connessione o il nome di dominio completo specificato durante la creazione del client sia corretto. Per informazioni su come acquisire una stringa di connessione, vedere Ottenere una stringa di connessione del bus di servizio.
• Controllare le autorizzazioni del firewall e della porta nell'ambiente di hosting. Verificare che le porte AMQP (Advanced Message Queuing Protocol) 5671 e 5672 siano aperte e che l'endpoint sia consentito tramite il firewall.
• Provare a usare l'opzione di trasporto del Web Socket, che si connette usando la porta 443. Per informazioni dettagliate, vedere Configurare il trasporto.
• Verificare se la rete blocca indirizzi IP specifici. Per informazioni dettagliate, vedere Quali indirizzi IP è necessario consentire?
• Se applicabile, verificare la configurazione del proxy. Per informazioni dettagliate, vedere: Configurare il trasporto
• Per altre informazioni sulla risoluzione dei problemi di connettività di rete, vedere: [Problemi di connettività, certificato o timeout][#connectivity-certificate-or-timeout-issues].

Errori di handshake del Secure Socket Layer (SSL)

Questo errore può verificarsi quando viene usato un proxy di intercettazione. Per verificarlo, è consigliabile testare l'applicazione nell'ambiente host con il proxy disabilitato.

Errori di esaurimento del socket

Le applicazioni devono preferire la gestione dei tipi di bus di servizio come singleton, la creazione e l'uso di una singola istanza per tutta la durata dell'applicazione. Ogni nuovo ServiceBusClient creato genera una nuova connessione AMQP, che usa un socket. Il tipo ServiceBusClient gestisce la connessione per tutti i tipi creati da tale istanza. Ogni ServiceBusReceiver, ServiceBusSessionReceiver, ServiceBusSender e ServiceBusProcessor gestisce il proprio collegamento AMQP per l'entità del bus di servizio associata. Quando si usa ServiceBusSessionProcessor, vengono stabiliti più collegamenti AMQP a seconda del numero di sessioni elaborate contemporaneamente.

I client memorizzano nella cache in modo sicuro quando sono inattivi. Garantiscono una gestione efficiente dell'uso della rete, della CPU e della memoria, riducendo al minimo l'impatto durante i periodi di inattività. È anche importante che venga chiamato CloseAsync o DisposeAsync quando un client non è più necessario per garantire che le risorse di rete vengano pulite correttamente.

L'aggiunta di componenti alla stringa di connessione non funziona

La generazione corrente della libreria client del bus di servizio supporta le stringhe di connessione solo nel formato pubblicato dal portale di Azure. Le stringhe di connessione sono destinate a fornire solo informazioni di base sulla posizione e sulla chiave condivisa. La configurazione del comportamento dei client viene eseguita tramite le relative opzioni.

Le generazioni precedenti dei client del bus di servizio hanno consentito la configurazione di alcuni comportamenti aggiungendo componenti chiave/valore a una stringa di connessione. Questi componenti non sono più riconosciuti e non hanno alcun effetto sul comportamento del client.

Alternativa "TransportType=AmqpWebSockets"

Per configurare i Web Socket come tipo di trasporto, vedere Configurare il trasporto.

Alternativa "Authentication=Managed Identity"

Per eseguire l'autenticazione con l'identità gestita, vedere: Identità e credenziali di accesso condiviso. Per altre informazioni sulla libreria Azure.Identity, vedere Autenticazione e Azure SDK.

Registrazione e diagnostica

La libreria client del bus di servizio è completamente instrumentata per la registrazione delle informazioni a vari livelli di dettaglio usando EventSource di .NET per generare informazioni. La registrazione viene eseguita per ogni operazione e segue il modello di contrassegno del punto iniziale dell'operazione, del relativo completamento e di eventuali eccezioni rilevate. Vengono registrate anche informazioni aggiuntive che potrebbero offrire informazioni dettagliate nel contesto dell'operazione associata.

Abilitazione della registrazione

I log del client del bus di servizio sono disponibili per qualsiasi EventListener acconsentendo esplicitamente alle origini che iniziano con Azure-Messaging-ServiceBus o acconsentendo esplicitamente a tutte le origini che hanno il tratto AzureEventSource. Per semplificare l'acquisizione dei log dalle librerie client di Azure, la libreria Azure.Core usata dal bus di servizio offre un AzureEventSourceListener.

Per altre informazioni, vedere Registrazione con Azure SDK per .NET.

Traccia distribuita

La libreria client del bus di servizio supporta la traccia distribuita tramite l'integrazione con Application Insights SDK. Include anche un supporto sperimentale per la specifica OpenTelemetry tramite il tipo ActivitySource di .NET introdotto in .NET 5. Per abilitare il supporto di ActivitySource per l'uso con OpenTelemetry, vedere il supporto di ActivitySource.

Per usare il supporto di DiagnosticActivity in disponibilità generale, è possibile eseguire l'integrazione con Application Insights SDK. Altre informazioni sono disponibili in Application Insights con Monitoraggio di Azure.

La libreria crea le espansioni seguenti:

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 maggior parte delle espansioni è autoesplicativa e viene avviata e arrestata durante l'operazione che ne porta il nome. L'espansione che collega le collega è Message. Il modo in cui il messaggio viene tracciato è tramite Diagnostic-Id impostato nella proprietà ServiceBusMessage.ApplicationProperties dalla libreria durante le operazioni di invio e pianificazione. In Application Insights, le estensioni Message vengono visualizzati come collegamenti a varie altre espansioni usate per interagire con il messaggio, ad esempio l'espansione ServiceBusReceiver.Receive, l'espansione ServiceBusSender.Send e l'espansione ServiceBusReceiver.Complete verrebbe collegate dall'espansione Message. Di seguito è riportato un esempio di come appare in Application Insights:

Nello screenshot precedente viene visualizzata la transazione end-to-end che può essere visualizzata in Application Insights nel portale. In questo scenario, l'applicazione invia messaggi e usa ServiceBusSessionProcessor per elaborarli. L'attività Message è collegata a ServiceBusSender.Send, ServiceBusReceiver.Receive, ServiceBusSessionProcessor.ProcessSessionMessage e ServiceBusReceiver.Complete.

Nota

Per altre informazioni, vedere Correlazione e analisi distribuita tramite la messaggistica del bus di servizio.

Risolvere i problemi del mittente

Non è possibile inviare un batch con più chiavi di partizione

Quando un'app invia un batch a un'entità abilitata per la partizione, tutti i messaggi inclusi in una singola operazione di invio devono avere la stessa PartitionKey. Se l'entità è abilitata per la sessione, lo stesso requisito è valido per la proprietà SessionId. Per inviare messaggi con valori PartitionKey o SessionId diversi, raggruppare i messaggi in istanze ServiceBusMessageBatch separate o includerli in chiamate separate all'overload SendMessagesAsync che accetta un set di istanze di ServiceBusMessage.

Il batch non riesce a inviare

Un batch di messaggi è ServiceBusMessageBatch contenente due o più messaggi oppure una chiamata a SendMessagesAsync in cui vengono passati due o più messaggi. Il servizio non consente a un batch di messaggi di superare 1 MB. Questo comportamento è vero se è abilitata o meno la funzionalità Supporto per messaggi di grandi dimensioni Premium. Se si intende inviare un messaggio di dimensioni maggiori di 1 MB, deve essere inviato singolarmente anziché raggruppato con altri messaggi. Sfortunatamente, il tipo ServiceBusMessageBatch non supporta attualmente la convalida che un batch non contenga messaggi superiori a 1 MB perché le dimensioni sono vincolate dal servizio e potrebbero cambiare. Pertanto, se si intende usare la funzionalità di supporto di messaggi di grandi dimensioni Premium, assicurarsi di inviare messaggi superiori a 1 MB singolarmente.

Risolvere i problemi del ricevitore

Il numero di messaggi restituiti non corrisponde al numero richiesto nella ricezione batch

Quando si tenta di eseguire un'operazione di ricezione batch, ovvero passare un valore di maxMessages pari a due o superiore al metodo ReceiveMessagesAsync, non è garantito che si riceva il numero di messaggi richiesti, anche se nella coda o nella sottoscrizione è disponibile quel numero di messaggi in quel momento e anche se l'intero maxWaitTime configurato non è ancora trascorso. Per ottimizzare la velocità effettiva ed evitare la scadenza del blocco, una volta che il primo messaggio arriva in rete, il ricevitore attende altri 20 millisecondi per eventuali messaggi aggiuntivi prima di inviare i messaggi per l'elaborazione. maxWaitTime controlla per quanto tempo il ricevitore attende di ricevere il primo messaggio. L'attesa per i messaggi successivi è di 20 millisecondi. Pertanto, l'applicazione non deve presupporre che tutti i messaggi disponibili vengano ricevuti in una sola chiamata.

Il blocco del messaggio o della sessione si perde prima dell'ora di scadenza del blocco

Il servizio bus di servizio usa il protocollo AMQP con stato. A causa della natura del protocollo, se il collegamento che connette il client e il servizio è scollegato dopo la ricezione di un messaggio, ma prima che il messaggio venga definito, il messaggio non può essere definito alla riconnessione del collegamento. I collegamenti possono essere scollegati a causa di un errore di rete temporaneo a breve termine, di un'interruzione della rete o a causa del timeout di inattività di 10 minuti imposto dal servizio. La riconnessione del collegamento viene eseguita automaticamente come parte di qualsiasi operazione che richiede il collegamento, ovvero la definizione o la ricezione di messaggi. In questo caso, si riceve una ServiceBusException con Reason di MessageLockLost o SessionLockLost anche se l'ora di scadenza del blocco non è ancora passata.

Come esplorare i messaggi pianificati o posticipati

I messaggi pianificati e posticipati vengono inclusi durante la visualizzazione in anteprima dei messaggi. Possono essere identificati dalla proprietà ServiceBusReceivedMessage.State. Quando si ha il SequenceNumber di un messaggio posticipato, è possibile riceverlo con un blocco tramite il metodo ReceiveDeferredMessagesAsync.

Quando si usano con gli argomenti, non è possibile visualizzare in anteprima i messaggi pianificati nella sottoscrizione, perché questi rimangono nell'argomento fino all'ora di accodamento pianificata. Come soluzione alternativa, è possibile costruire un ServiceBusReceiver che passa nel nome dell'argomento per visualizzare in anteprima tali messaggi. Nessun'altra operazione funziona con il ricevitore quando si usa un nome dell'argomento.

Come esplorare i messaggi di sessione in tutte le sessioni

È possibile usare un normale ServiceBusReceiver per visualizzare in anteprima in tutte le sessioni. Per visualizzare in anteprima una sessione specifica, è possibile usare il ServiceBusSessionReceiver, ma è necessario ottenere un blocco di sessione.

Quando si accede al corpo del messaggio viene generata l'eccezione NotSupportedException

Questo problema si verifica più spesso in scenari di interoperabilità quando si riceve un messaggio inviato da una libreria diversa che usa un diverso formato del corpo del messaggio AMQP. Se si interagisce con questi tipi di messaggi, vedere l'esempio di corpo del messaggio AMQP per informazioni su come accedere al corpo del messaggio.

Risolvere i problemi del processore

Il rinnovo automatico non funziona

Il rinnovo automatico si basa sull'ora del sistema per determinare quando rinnovare un blocco per un messaggio o una sessione. Se l'ora di sistema non è precisa, ad esempio, l'orologio è lento, il rinnovo del blocco potrebbe non verificarsi prima che il blocco venga perso. Assicurarsi che l'ora di sistema sia precisa se il rinnovo automatico non funziona.

Il processore sembra bloccarsi o avere problemi di latenza quando si usa una concorrenza elevata

Questo comportamento è spesso causato dalla scadenza del thread, in particolare quando si usa il processore della sessione e si usa un valore molto elevato per MaxConcurrentSessions, in relazione al numero di core nel computer. La prima cosa da controllare consiste nell'assicurarsi che non si stia eseguendo sync-over-async in uno dei gestori dell'evento. Sync-over-async è un modo semplice per causare deadlock e scadenza del thread. Anche se non si esegue un sync-over-async, qualsiasi codice di sincronizzazione puro nei gestori potrebbe contribuire alla scadenza del thread. Se è stato determinato che questo non è il problema, ad esempio perché si dispone di codice asincrono puro, è possibile provare ad aumentare il valore di [TryTimeout][TryTimeout]. Riduce la pressione sul pool di thread riducendo il numero di cambi di contesto e di timeout che si verificano quando si usa in particolare il processore di sessione. Il valore predefinito per [TryTimeout][TryTimeout] è di 60 secondi, ma può essere impostato fino a 1 ora. È consigliabile eseguire il test con TryTimeout impostato su 5 minuti come punto di partenza e da qui eseguire l'iterazione. Se nessuno di questi suggerimenti funziona, è sufficiente aumentare il numero di istanze in più host, riducendo la concorrenza nell'applicazione, ma eseguendo l'applicazione su più host per ottenere la concorrenza complessiva desiderata.

Altre informazioni:

• Debug della scadenza del pool di thread
• Diagnostica della scadenza del pool di thread .NET Core con PerfView (perché il servizio non satura tutti i core o sembra bloccarsi)
• Diagnostica dei problemi di esaurimento del pool di thread in app .NET Core(video)

Il processore di sessione richiede troppo tempo per cambiare sessione

Questa configurazione può essere eseguita usando [SessionIdleTimeout][SessionIdleTimeout], che indica al processore il tempo di attesa per ricevere un messaggio da una sessione, prima di rinunciare e spostarsi in un'altra sessione. È utile se sono presenti molte sessioni meno densamente popolate, in cui ogni sessione contiene solo alcuni messaggi. Se si prevede che in ogni sessione arriveranno lentamente molti messaggi, impostare un valore troppo basso può essere controproducente, in quanto comporta la chiusura non necessaria della sessione.

Il processore si arresta immediatamente

Questo comportamento viene spesso osservato per scenari demo o di test. StartProcessingAsync viene restituito immediatamente dopo l'avvio del processore. La chiamata a questo metodo non si blocca e mantiene attiva l'applicazione mentre il processore è in esecuzione, quindi è necessario un altro meccanismo per farlo. Per le demo o i test, è sufficiente aggiungere solo una chiamata Console.ReadKey() dopo l'avvio del processore. Per gli scenari di produzione, è probabile che si voglia usare una sorta di integrazione del framework, ad esempio [BackgroundService][BackgroundService] per fornire utili hook del ciclo di vita dell'applicazione che possono essere usati per avviare ed eliminare il processore.

Risolvere i problemi relativi alle transazioni

Per informazioni generali sulle transazioni nel bus di servizio, vedere [Panoramica dell'elaborazione delle transazioni del bus di servizio][Transazioni].

Operazioni supportate

Non tutte le operazioni sono supportate quando si usano le transazioni. Per visualizzare l'elenco delle transazioni supportate, vedere [Operazioni nell'ambito di una transazione][TransactionOperations].

Timeout

Si verifica il timeout di una transazione dopo un [periodo di tempo][TransactionTimeout], quindi è importante che l'elaborazione che si verifica nell' ambito di una transazione rispetti questo timeout.

Le operazioni in una transazione non vengono ritentate

Questo si verifica per motivi strutturali. Si consideri lo scenario seguente: si sta tentando di completare un messaggio all'interno di una transazione, ma si verifica un errore temporaneo, ad esempio, ServiceBusException con Reason di ServiceCommunicationProblem. Si supponga che la richiesta raggiunga effettivamente il servizio. Se il client dovesse ripetere l'operazione, il servizio visualizzerebbe due richieste complete. Il primo completamento non verrebbe finalizzato finché non viene eseguito il commit della transazione. Il secondo completamento non è nemmeno in grado di essere valutato prima del completamento del primo. La transazione sul client è in attesa che il completamento termini. In questo modo viene creato un deadlock in cui il servizio è in attesa del completamento della transazione da parte del client, ma il client è in attesa che il servizio riconosca il completamento della seconda operazione. La transazione raggiunge infine il timeout dopo 2 minuti, ma questa è un'esperienza utente non ottimale. Per questo motivo, le operazioni all'interno di una transazione non vengono rieseguite.

Le transazioni tra entità non funzionano

Per eseguire transazioni che coinvolgono più entità, è necessario impostare la proprietà ServiceBusClientOptions.EnableCrossEntityTransactions su true. Per informazioni dettagliate, vedere l'esempio [Transazioni tra entità][CrossEntityTransactions].

Obiettivi di vendita

Le informazioni sulle quote del bus di servizio sono disponibili [qui][ServiceBusQuotas].

Problemi di connettività, certificato o timeout

La procedura seguente consente di risolvere i problemi di connettività/certificato/timeout per tutti i servizi in *.servicebus.windows.net.

• Passare a https://<yournamespace>.servicebus.windows.net/ o usare wget. Consente di verificare se si verificano problemi di filtro IP, rete virtuale o catena di certificati, comuni quando si usa Java SDK.

  Esempio di messaggio completato:

  <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>
  

  Esempio di messaggio di errore:

  <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>
  

• Eseguire il comando seguente per verificare se una porta è bloccata nel firewall. Le porte usate sono 443 (HTTPS), 5671 e 5672 (AMQP) e 9354 (Messaggistica di rete/SBMP). A seconda della libreria usata, vengono usate anche altre porte. Ecco il comando di esempio che controlla se la porta 5671 è bloccata. A

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

  In Linux:

  telnet <yournamespacename>.servicebus.windows.net 5671
  

• Quando si verificano problemi di connettività intermittente, eseguire il comando seguente per verificare se sono presenti pacchetti rimossi. Questo comando tenta di stabilire 25 connessioni TCP diverse al servizio ogni secondo. Sarà quindi possibile verificare quanti di essi hanno avuto esito positivo/negativo e vedere anche la latenza della connessione TCP. È possibile scaricare lo strumento psping da qui.

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

  È possibile usare comandi equivalenti se si usano altri strumenti, ad esempio tnc, ping e così via.

• Ottenere una traccia di rete se i passaggi precedenti non sono utili e analizzarla usando strumenti come Wireshark. Contattare il supporto tecnico Microsoft, se necessario.

• Per trovare gli indirizzi IP corretti da aggiungere all'elenco elementi consentiti per le connessioni, vedere Quali indirizzi IP è necessario aggiungere all'elenco elementi consentiti.

Il 30 settembre 2026 verrà ritirato il supporto del protocollo SBMP per il bus di servizio di Azure, quindi non sarà più possibile usare questo protocollo dopo il 30 settembre 2026. Eseguire la migrazione alle librerie più recenti dell'SDK del bus di servizio di Azure usando il protocollo AMQP che offre aggiornamenti critici della sicurezza e funzionalità migliorate, prima di tale data.

Per altre informazioni, vedere l'annuncio del ritiro del supporto.

Problemi che possono verificarsi con aggiornamenti/riavvii del servizio

Sintomi

• Le richieste potrebbero essere momentaneamente limitate.
• Potrebbe verificarsi un calo di messaggi o richieste in ingresso.
• Il file di log potrebbe contenere messaggi di errore.
• Le applicazioni potrebbero essere disconnesse dal servizio per alcuni secondi.

Causa

Gli aggiornamenti e i riavvii del servizio back-end possono causare questi problemi nelle applicazioni.

Risoluzione

Se il codice dell'applicazione usa l'SDK, i criteri di ripetizione sono già incorporati e attivi. L'applicazione si riconnette senza alcun impatto significativo sull'applicazione o sul flusso di lavoro.

Accesso non autorizzato: sono necessarie attestazioni di invio

Sintomi

Questo errore potrebbe verificarsi quando si tenta di accedere a un argomento del bus di servizio da Visual Studio in un computer locale usando un'identità gestita assegnata dall'utente con autorizzazioni di invio.

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

Causa

L'identità non dispone delle autorizzazioni per accedere all'argomento del bus di servizio.

Risoluzione

Per risolvere questo errore, installare la libreria Microsoft.Azure.Services.AppAuthentication. Per altre informazioni, vedere Autenticazione per lo sviluppo locale.

Per informazioni su come assegnare le autorizzazioni ai ruoli, vedere Autenticare un'identità gestita con Microsoft Entra ID per accedere alle risorse del bus di servizio di Azure.

Eccezione del bus di servizio: token put non riuscito

Sintomi

Viene visualizzato il messaggio di errore seguente:

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

Il 30 settembre 2026 verranno ritirate le librerie dell'SDK del bus di servizio di Azure WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus e com.microsoft.azure.servicebus, che non sono conformi alle linee guida di Azure SDK. Verrà terminato anche il supporto del protocollo SBMP, quindi non sarà più possibile usare questo protocollo dopo il 30 settembre 2026. Eseguire la migrazione alle librerie più recenti di Azure SDK, che offrono aggiornamenti critici della sicurezza e funzionalità migliorate, prima di tale data.

Anche se le librerie precedenti possono ancora essere usate oltre il 30 settembre 2026, non riceveranno più il supporto e gli aggiornamenti ufficiali da Microsoft. Per altre informazioni, vedere l'annuncio del ritiro del supporto.

Causa

Il numero di token di autenticazione per i collegamenti simultanei in una singola connessione a uno spazio dei nomi del bus di servizio ha superato il limite: 1.000.

Risoluzione

Completa uno dei seguenti passaggi:

• Ridurre il numero di collegamenti simultanei in una singola connessione o usare una nuova connessione
• Usare gli SDK per il bus di servizio di Azure: questo garantisce che non si crei questa situazione (scelta consigliata)

I blocchi delle risorse non funzionano quando si usa l'SDK del piano dati

Sintomi

È stato configurato un blocco di eliminazione in uno spazio dei nomi del bus di servizio, ma è possibile eliminare le risorse nello spazio dei nomi (code, argomenti e così via) usando Service Bus Explorer.

Causa

Il blocco delle risorse viene mantenuto in Azure Resource Manager (piano di controllo) e non impedisce alla chiamata dell'SDK del piano dati di eliminare la risorsa direttamente dallo spazio dei nomi. Service Bus Explorer autonomo usa l'SDK del piano dati, quindi l'eliminazione lo ignora.

Risoluzione

È consigliabile usare l'API basata su Azure Resource Manager tramite il portale di Azure, PowerShell, l'interfaccia della riga di comando o il modello di Resource Manager per eliminare le entità in modo che il blocco delle risorse impedisca l'eliminazione accidentale delle risorse.

L'entità non è più disponibile

Sintomi

Viene visualizzato un errore che indica che l'entità non è più disponibile.

Causa

La risorsa potrebbe essere stata eliminata. Seguire questa procedura per identificare il motivo per cui l'entità è stata eliminata.

• Controllare il log attività per verificare se è presente una richiesta di Azure Resource Manager per l'eliminazione.
• Controllare il log operativo per verificare se è presente una chiamata API diretta per l'eliminazione. Per informazioni su come raccogliere un log operazioni, vedere Raccolta e routing. Per lo schema e un esempio di log operazioni, vedere Log operazioni
• Controllare il log operazioni per verificare l'eventuale presenza di un'eliminazione autodeleteonidle correlata.

Passaggi successivi

Fai riferimento ai seguenti articoli:

• Eccezioni di Resource Manager. Elenca le eccezioni generate durante l'interazione con il bus di servizio di Azure usando Azure Resource Manager (tramite modelli o chiamate dirette).
• Eccezioni della messaggistica. Fornisce un elenco di eccezioni generate da .NET Framework per il bus di servizio di Azure.