Risoluzione dei problemi negli avvisi relativi al Monitoraggio di Azure
Questo articolo illustra i problemi comuni relativi ad avvisi e notifiche in Monitoraggio di Azure. Gli avvisi di Monitoraggio di Azure notificano in modo proattivo quando vengono riscontrate importanti condizioni nei dati di monitoraggio.
Per informazioni specifiche sulla risoluzione dei problemi relativi agli avvisi di ricerca log o metrica di Azure, vedere:
- Risolvere i problemi relativi agli avvisi delle metriche di Monitoraggio di Azure
- Risolvere i problemi relativi agli avvisi di ricerca log di Monitoraggio di Azure
Prima della risoluzione dei problemi
Se l'avviso viene generato come previsto, ma le notifiche appropriate non vengono eseguite come previsto, testare prima il gruppo di azioni per assicurarsi che sia configurato correttamente.
In caso contrario, usare le informazioni contenute nel resto di questo articolo per risolvere il problema.
Non ho ricevuto l'e-mail prevista
Se un avviso attivato è visibile nel portale di Azure, ma non si è ricevuto il messaggio di posta elettronica configurato, seguire questa procedura:
L'e-mail è stata eliminata da una regola di elaborazione degli avvisi?
Controllare facendo clic sull'avviso attivato nel portale ed esaminare la scheda della cronologia relativa ai gruppi di azioni eliminati:
Il tipo di azione è "Invia un messaggio di posta elettronica al ruolo di Azure Resource Manager"?
Questa azione esamina solo le assegnazioni di ruolo di Azure Resource Manager che sono nell'ambito della sottoscrizione e di tipo Utente o Gruppo. Assicurarsi di aver assegnato il ruolo a livello di sottoscrizione e non a livello di risorsa o di gruppo di risorse.
Il server di posta elettronica e la cassetta postale accettano messaggi di posta elettronica esterni?
Verificare che i messaggi di posta elettronica da questi tre indirizzi non siano bloccati:
- azure-noreply@microsoft.com
- azureemail-noreply@microsoft.com
- alerts-noreply@mail.windowsazure.com
È comune che le liste di distribuzione interne blocchino i messaggi di posta elettronica da indirizzi di posta elettronica esterni. Assicurarsi di consentire la posta dagli indirizzi di posta elettronica precedenti. Per testare, aggiungere un normale indirizzo di posta elettronica aziendale, non una lista di distribuzione, al gruppo di azioni e verificare che gli avvisi arrivino a tale indirizzo di posta elettronica.
Il messaggio di posta elettronica è stato elaborato dalle regole Posta in arrivo o da un filtro protezione da posta indesiderata?
Verificare che non siano presenti regole Posta in arrivo che eliminano i messaggi di posta elettronica o che li spostano in una cartella vicina. Ad esempio, le regole Posta in arrivo potrebbero rilevare mittenti specifici o parole specifiche nell'oggetto. Verificare anche:
- Le impostazioni della posta indesiderata del client di posta elettronica (ad esempio Outlook, Gmail)
- I limiti del mittente, le impostazioni della posta indesiderata, le impostazioni della quarantena per il server di posta elettronica (ad esempio Exchange, Microsoft 365, G-Suite)
- Le impostazioni dell'appliance di sicurezza della posta elettronica, se presenti, ad esempio Barracuda, Cisco.
È stata annullata per errore la sottoscrizione del gruppo di azioni?
Nota
Tenere presente che, se si annulla la sottoscrizione a un gruppo di azioni, anche tutti i membri di una lista di distribuzione verranno annullati. È possibile continuare a usare l'indirizzo di posta elettronica della lista di distribuzione. Tuttavia, sarà necessario informare gli utenti della lista di distribuzione che, se annullano la sottoscrizione, annullano la sottoscrizione dell'intera lista di distribuzione anziché solo di se stessi. Per risolvere questo problema, aggiungere singolarmente l'indirizzo di posta elettronica di tutti gli utenti del gruppo di azioni. Un gruppo di azioni può contenere fino a 1.000 indirizzi di posta elettronica. Quindi, se un utente specifico vuole annullare la sottoscrizione, sarà in grado di farlo senza influire sugli altri utenti. Sarà possibile vedere anche quali utenti hanno annullato la sottoscrizione.
I messaggi di posta elettronica di avviso contengono un collegamento per annullare la sottoscrizione al gruppo di azioni. Per verificare se la sottoscrizione a questo gruppo di azioni è stata annullata per errore, eseguire una delle operazioni seguenti:
- Aprire il gruppo di azioni nel portale e controllare la colonna Stato:
- Cercare il messaggio di posta elettronica per confermare l'annullamento della sottoscrizione:
Per eseguire di nuovo la sottoscrizione, usare il collegamento nel messaggio di posta elettronica di conferma dell'annullamento della sottoscrizione ricevuto oppure rimuovere l'indirizzo di posta elettronica dal gruppo di azioni e poi aggiungerlo di nuovo.
Sono stati superati i limiti del servizio inviando molti messaggi di posta elettronica a un singolo indirizzo di posta elettronica?
È previsto un limite di 100 messaggi di posta elettronica all'ora per ogni indirizzo. Se si supera questa soglia, non verranno inviate altre notifiche di posta elettronica. Controllare di aver ricevuto un messaggio che indica che la frequenza di ricezione dei messaggi dell'indirizzo di posta elettronica è temporaneamente limitata:
Se si vuole ricevere un volume elevato di notifiche senza limitazione della frequenza, è consigliabile usare un'azione diversa, ad esempio:
- webhook
- App per la logica
- Funzioni di Azure
- Runbook di automazione
Nessuna di queste azioni è limitata.
Non è stato ricevuto l’SMS, la chiamata vocale o la notifica push come previsto
Se un avviso attivato è visibile nel portale ma non si è ricevuto il relativo SMS, la chiamata vocale o la notifica configurati, seguire questa procedura:
L'azione è stata eliminata da una regola di elaborazione degli avvisi?
Controllare facendo clic sull'avviso attivato nel portale ed esaminare la scheda della cronologia relativa ai gruppi di azioni eliminati:
Se l'eliminazione è stata accidentale, è possibile modificare, disabilitare o eliminare la regola di elaborazione degli avvisi.
SMS/chiamata vocale: il numero di telefono è corretto?
Controllare l'azione SMS per rilevare eventuali errori di digitazione nel codice paese o nel numero di telefono.
SMS/chiamata vocale: sono stati superati i limiti del servizio?
Per SMS e chiamate vocali è prevista una frequenza limitata a non più di una notifica ogni cinque minuti per numero di telefono. Se si supera questa soglia, le notifiche vengono eliminate.
- Chiamata vocale: controllare la cronologia delle chiamate e verificare se è stata ricevuta una chiamata diversa da Azure nei cinque minuti precedenti.
- SMS: controllare la cronologia degli SMS per verificare se è presente un messaggio indicante che il numero di telefono è soggetto a limite di frequenza.
Se si vuole ricevere un volume elevato di notifiche senza limitazione della frequenza, è consigliabile usare un'azione diversa, ad esempio:
- webhook
- App per la logica
- Funzioni di Azure
- Runbook di automazione
Nessuna di queste azioni è limitata.
SMS: è stata annullata per errore la sottoscrizione del gruppo di azioni?
Aprire la cronologia degli SMS e verificare se è stato rifiutato esplicitamente il recapito di SMS da questo gruppo di azioni specifico (tramite la risposta DISABLE action_group_short_name) o da tutti i gruppi di azioni (tramite la risposta STOP).
Per eseguire di nuovo la sottoscrizione, inviare il comando SMS pertinente (ENABLE action_group_short_name o START) oppure rimuovere l'azione SMS dal gruppo di azioni e quindi aggiungerlo di nuovo. Per ulteriori informazioni, vedere Comportamento degli avvisi SMS nei gruppi di azioni.
Sono state bloccate per errore le notifiche sul telefono?
La maggior parte dei cellulari consente di bloccare le chiamate o gli SMS provenienti da specifici numeri di telefono o codici brevi oppure di bloccare le notifiche push di specifiche app, ad esempio l'app per dispositivi mobili di Azure. Per verificare se le notifiche sono state bloccate per errore nel telefono, vedere la documentazione specifica del modello o del sistema operativo dell'apparecchio oppure provare a usare un telefono e un numero di telefono differenti.
L'azione prevista non è stata attivata
Se un avviso attivato è visibile nel portale, ma la relativa azione configurata non è stata attivata, seguire questa procedura:
L'azione è stata eliminata da una regola di elaborazione degli avvisi?
Controllare facendo clic sull'avviso attivato nel portale ed esaminare la scheda della cronologia relativa ai gruppi di azioni eliminati:
Se l'eliminazione è stata accidentale, è possibile modificare, disabilitare o eliminare la regola di elaborazione degli avvisi.
Il webhook è stato attivato?
L'indirizzo IP di origine è bloccato?
Aggiungere gli indirizzi IP da cui viene chiamato il webhook all'elenco elementi consentiti.
L'endpoint del webhook funziona correttamente?
Verificare che l'endpoint del webhook configurato sia corretto e che funzioni correttamente. Controllare i log del webhook o instrumentarne il codice in modo che sia possibile analizzarlo (ad esempio, registrare il payload in ingresso).
Si sta usando il formato corretto per chiamare Slack o Microsoft Teams?
Ognuno di questi endpoint prevede un formato JSON specifico. Seguire queste istruzioni per configurare in alternativa un'azione dell'app per la logica.Il webhook ha smesso di rispondere o ha restituito errori?
In genere, quando chiamati, i gruppi di azioni webhook seguono queste regole:
- Quando viene richiamato un webhook, se la prima chiamata ha esito negativo, viene ritentata almeno 1 volta e fino a cinque volte (5 tentativi) con vari intervalli di ritardo (5, 20, 40 secondi).
- Il ritardo tra il primo e il secondo tentativo è di 5 secondi
- Il ritardo tra il secondo e il terzo tentativo è di 20 secondi
- Il ritardo tra il terzo e il quarto tentativo è di 5 secondi
- Il ritardo tra il quarto e il quinto tentativo è di 40 secondi
- Il ritardo tra il quinto e il sesto tentativo è di 5 secondi
- Dopo diversi tentativi di chiamata al webhook, nessun gruppo di azioni chiama l'endpoint per 15 minuti.
- La logica di retry presuppone che sia possibile riprovare la chiamata. I codici di stato 408, 429, 503, 504 o
HttpRequestException,WebExceptionoTaskCancellationExceptionconsentono la ripetizione della chiamata.
- Quando viene richiamato un webhook, se la prima chiamata ha esito negativo, viene ritentata almeno 1 volta e fino a cinque volte (5 tentativi) con vari intervalli di ritardo (5, 20, 40 secondi).
L'azione o la notifica è stata ricevuta più di una volta
Se si riceve più volte una notifica per un avviso (ad esempio un messaggio di posta elettronica o un SMS) oppure se l'azione dell'avviso (ad esempio un webhook o una funzione di avviso) viene attivata più volte, seguire questa procedura:
Si tratta effettivamente dello stesso avviso?
In alcuni casi, vengono attivati più avvisi simili quasi contemporaneamente. Quindi, potrebbe sembrare che lo stesso avviso abbia attivato più volte le azioni. Una regola di avviso per i log attività, ad esempio, potrebbe essere configurata in modo da essere attivata quando un evento inizia e finisce (correttamente o con errore) non filtrando in base al campo dello stato dell'evento.
Per verificare se queste azioni o notifiche provengono da avvisi diversi, esaminare i dettagli dell'avviso, ad esempio il timestamp e l'ID dell'avviso o l'ID di correlazione. In alternativa, controllare l'elenco degli avvisi attivati nel portale. In questo caso, è necessario adattare la logica della regola di avviso o configurare altrimenti l'origine dell’avviso.
L'azione viene ripetuta in più gruppi di azioni?
Quando viene generato un avviso, ognuno dei relativi gruppi di azioni viene elaborato in modo indipendente. Se quindi un'azione (ad esempio un indirizzo di posta elettronica) viene visualizzata in più gruppi di azioni attivati, viene chiamata una volta per ogni gruppo di azioni.
Per verificare quali gruppi di azione sono stati attivati, controllare la scheda della cronologia degli avvisi. Qui verranno visualizzati sia i gruppi di azioni definiti nella regola di avviso che i gruppi di azioni aggiunti all'avviso dalle regole di elaborazione degli avvisi:
L'azione o la notifica includono contenuto imprevisto
Si è verificata un'interruzione che ha attivato l'uso del provider di posta elettronica di fallback?
I gruppi di azioni usano due provider di posta elettronica diversi per garantire il recapito delle notifiche tramite posta elettronica. Il provider di posta elettronica principale è resiliente e rapido, ma occasionalmente subisce interruzioni. In caso di interruzioni, il provider di posta elettronica secondario gestisce le richieste di posta elettronica. Il provider secondario è solo una soluzione di fallback. A causa delle differenze tra provider, un messaggio di posta elettronica inviato dal provider secondario potrebbe avere un'esperienza di posta elettronica danneggiata. La riduzione delle prestazioni comporta una formattazione e un contenuto di posta elettronica leggermente diversi. Poiché i modelli di posta elettronica differiscono nei due sistemi, la parità tra i due sistemi non è fattibile.
Le notifiche generate dalla soluzione di fallback contengono una nota che indica:
"Questa è un'esperienza di posta elettronica danneggiata. Ciò significa che la formattazione potrebbe essere disattivata o i dettagli potrebbero non essere presenti. Per altre informazioni sull'esperienza di posta elettronica danneggiata, leggere qui."
Se la notifica non contiene questa nota e l'avviso è stato ricevuto, ma si ritiene che alcuni dei relativi campi siano mancanti o errati, controllare il formato del payload.
Quale formato è stato usato per la configurazione della regola di avviso?
Ogni tipo di azione, ad esempio posta elettronica, webhook e così via, ha due formati: il formato predefinito legacy e il formato di schema comune. Quando si crea un gruppo di azioni, si specifica il formato dell'azione. Diverse azioni nei gruppi di azioni possono avere formati diversi.
Ad esempio, per le azioni webhook:
Verificare che il formato specificato a livello di azione sia quello previsto. Ad esempio, è possibile che sia stato sviluppato un codice che risponde agli avvisi (webhook, funzione, app per la logica e così via), in cui è previsto un formato specifico, ma in un secondo momento, nell'azione, l'utente o un’altra persona hanno specificato un formato diverso.
Controllare anche il formato del payload (JSON) per e per lo schema di avviso comune.
I risultati della ricerca non sono inclusi nelle notifiche degli avvisi di ricerca log.
A partire dall'API per gli avvisi di ricerca log versione 2021-08-01, i risultati della ricerca sono stati rimossi dal payload di notifica degli avvisi. I risultati della ricerca sono disponibili solo per le regole di avviso create con le versioni precedenti dell'API (2018-04-16). Per impostazione predefinita, la creazione di nuove regole di avviso tramite il portale di Azure creerà la regola con la versione più recente. Seguire Modifiche apportate all'esperienza di creazione delle regole di avviso del log per informazioni sulle modifiche e sulle rettifiche consigliate per l'uso della versione aggiornata.
Il campo MetricValue contiene "null" per le notifiche di avviso di ricerca log risolte.
Questo si verifica per motivi strutturali. Gli avvisi di ricerca log con stato usano una logica di risoluzione basata sul tempo anziché basata su valori. Monitoraggio di Azure invia un valore della metrica null poiché non esiste alcun valore che ha causato la risoluzione dell'avviso, ma piuttosto il tempo trascorso.
L'elenco delle dimensioni è vuoto o il titolo dell'avviso non contiene un nome di dimensione
Quando si dispone di una regola di avviso di ricerca log che non restituisce risultati, l'avviso può essere attivato come previsto, ma l'elenco delle dimensioni è vuoto o il titolo dell'avviso non contiene un nome di dimensione. Quando una query non restituisce righe, il campo ID risorsa (ovvero la base per popolare i campi dimensione e titolo) è vuoto.
Informazioni mancanti in un avviso del log attività
Gli avvisi del log attività sono avvisi basati su eventi scritti nel log attività di Azure, ad esempio eventi sulla creazione, l'aggiornamento o l'eliminazione di risorse di Azure, integrità dei servizi e integrità risorse o i risultati di Azure Advisor e Criteri di Azure. Se è stato ricevuto un avviso basato sul log attività, ma alcuni campi necessari mancano o non sono corretti, controllare innanzitutto gli eventi nel log attività. Se la risorsa di Azure non ha scritto i campi che si sta cercando nell'evento del log attività, questi non vengono inclusi nell'avviso corrispondente.
Le proprietà personalizzate sono mancanti dalle notifiche di posta elettronica, SMS o push.
Le proprietà personalizzate vengono passate solo al payload per azioni, ad esempio webhook, Funzioni di Azure o App per la logica. Le proprietà personalizzate non sono incluse per le notifiche (posta elettronica/SMS/push).
La regola di elaborazione degli avvisi non funziona come previsto
Se un avviso attivato è visibile nel portale, ma la relativa regola di elaborazione degli avvisi non ha funzionato come previsto, seguire questa procedura:
La regola di elaborazione degli avvisi è abilitata?
Controllare il campo dello stato delle regole di elaborazione degli avvisi per verificare che la regola di azione correlata sia abilitata. Per impostazione predefinita, il portale mostra solo le regole di avviso abilitate, ma è possibile modificare il filtro per visualizzare tutte le regole.
Se non è abilitata, è possibile abilitare la regola di elaborazione degli avvisi selezionandola e facendo clic su Abilita.
Si tratta di un avviso sull'integrità dei servizi?
Gli avvisi di integrità dei servizi non sono interessati dalle regole di elaborazione degli avvisi. Pertanto, se è configurata una regola di elaborazione degli avvisi per un ambito che include gli avvisi di integrità del servizio, mentre gli avvisi di integrità del servizio rientrano nell'ambito, la regola di elaborazione degli avvisi non influirà su di essi.
La regola di elaborazione degli avvisi ha elaborato l'avviso?
Selezionare l'avviso attivato nel portale e osservare la scheda Cronologia per verificare se la regola di elaborazione degli avvisi è stata elaborata.
Ecco un esempio di regola di elaborazione degli avvisi che elimina tutti i gruppi di azioni:
Ecco un esempio di regola di elaborazione degli avvisi che aggiunge un altro gruppo di azioni:
L'ambito della regola di elaborazione degli avvisi e il filtro corrispondono all'avviso attivato?
Se si ritiene che la regola di elaborazione degli avvisi avrebbe dovuto essere attivata ma non lo è stata o viceversa, esaminare con attenzione l'ambito e le condizioni di filtro della regola di elaborazione degli avvisi e confrontarla con le proprietà dell'avviso attivato.
Problemi durante la creazione, l'aggiornamento o l'eliminazione di regole di elaborazione degli avvisi nel portale di Azure
Se si è verificato un errore durante il tentativo di creazione, aggiornamento o eliminazione di una regola di elaborazione degli avvisi, seguire questa procedura:
Controllare le autorizzazioni.
È necessario avere il ruolo predefinito di Collaboratore al monitoraggio o le autorizzazioni specifiche correlate agli avvisi e alle regole di elaborazione degli avvisi.
Controllare i parametri della regola di elaborazione degli avvisi.
Controllare la documentazione relativa alla regola di elaborazione degli avvisi o il comando PowerShell Set-AzAlertProcessingRule della regola di elaborazione degli avvisi.