Risoluzione dei problemi negli avvisi relativi al Monitoraggio di Azure
Questo articolo illustra i problemi comuni degli avvisi e delle notifiche di Monitoraggio di Azure. Gli avvisi di Monitoraggio di Azure notificano in modo proattivo quando vengono rilevate condizioni importanti 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 ad 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 il messaggio di posta elettronica previsto
Se è possibile visualizzare un avviso attivato nella portale di Azure, ma non è stato ricevuto il messaggio di posta elettronica configurato, seguire questa procedura:
Il messaggio di posta elettronica è stato eliminato 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 si trovano nell'ambito della sottoscrizione e di tipo Utente. Assicurarsi di aver assegnato il ruolo a livello di sottoscrizione e non a livello di risorsa o 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:
- Impostazioni di posta indesiderata del client di posta elettronica (ad esempio Outlook, Gmail)
- Limiti del mittente/impostazioni di posta indesiderata/impostazioni di quarantena del 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 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 1000 indirizzi di posta elettronica. Quindi, se un utente specifico vuole annullare la sottoscrizione, sarà in grado di farlo senza influire sugli altri utenti. Potrai anche vedere 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 è stata annullata accidentalmente la sottoscrizione a questo gruppo di azioni, 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 della sottoscrizione ricevuto o rimuovere l'indirizzo di posta elettronica dal gruppo di azioni e quindi aggiungerlo nuovamente.
Hai superato 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 vengono inviate altre notifiche tramite posta elettronica. Controllare se è stato ricevuto un messaggio che indica che l'indirizzo di posta elettronica è temporaneamente limitato:
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 ho ricevuto l'SMS, la chiamata vocale o la notifica push prevista
Se è possibile visualizzare un avviso attivato nel portale, ma non è stato ricevuto l'SMS, la chiamata vocale o la notifica push configurata, 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/voce: il numero di telefono è corretto?
Controllare l'azione SMS per rilevare eventuali errori di digitazione nel codice paese o nel numero di telefono.
SMS/voce: 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 eseguita una chiamata diversa da Azure nei cinque minuti precedenti.
- SMS: controllare la cronologia SMS per un messaggio che indica che il numero di telefono è limitato.
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 SMS e verificare se si è scelto di rifiutare esplicitamente il recapito sms da questo gruppo di azioni specifico (usando la risposta DISABLE action_group_short_name) o da tutti i gruppi di azioni (usando 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 è possibile visualizzare un avviso attivato nel portale, ma l'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 l'endpoint 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 non risponde o restituisce errori?
I gruppi di azioni webhook seguono in genere queste regole quando viene chiamato:
- Quando viene richiamato un webhook, se la prima chiamata ha esito negativo, viene ritentata almeno 1 volta e fino a cinque volte (5 tentativi) a vari intervalli di ritardo (5, 20, 40 secondi).
- Il ritardo tra il primo e il secondo tentativo è di 5 secondi
- Il ritardo tra il 2° e il terzo tentativo è di 20 secondi
- Il ritardo tra il 3° e il 4° tentativo è di 5 secondi
- Il ritardo tra il 4 e il 5° tentativo è di 40 secondi
- Il ritardo tra il 5 e il 6° tentativo è di 5 secondi
- Dopo aver tentato di chiamare il webhook, nessun gruppo di azioni chiama l'endpoint per 15 minuti.
- La logica di ripetizione dei tentativi presuppone che la chiamata possa essere ritentata. Codici di stato: 408, 429, 503, 504 o
HttpRequestException,WebExceptionoTaskCancellationExceptionconsentire 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) a vari intervalli di ritardo (5, 20, 40 secondi).
L'azione o la notifica è avvenuta più volte
Se è stata ricevuta una notifica per un avviso (ad esempio un messaggio di posta elettronica o un SMS) più volte o l'azione dell'avviso (ad esempio webhook o funzione di Azure) è stata 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. Ad esempio, una regola di avviso del log attività potrebbe essere configurata in modo che venga attivata sia all'avvio di un evento che al termine (operazione riuscita o non riuscita), senza filtrare il campo relativo allo 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 l'origine 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 azioni sono stati attivati, controllare la scheda Cronologia avvisi. Verranno visualizzati entrambi i gruppi di azioni definiti nella regola di avviso e i gruppi di azioni aggiunti all'avviso dalle regole di elaborazione degli avvisi:
L'azione o la notifica ha contenuto imprevisto
Si è verificato 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 (posta elettronica, webhook e così via) ha due formati, ovvero 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 codice che risponda agli avvisi (webhook, funzione, app per la logica e così via), prevedendo un formato, ma più avanti nell'azione è stato specificato un formato diverso.
Controllare anche il formato del payload (JSON) per gli avvisi del log attività, per gli avvisi di ricerca log (sia Application Insights che Log Analytics), per gli avvisi di metrica, per lo schema di avviso comune e per gli avvisi della metrica classica deprecati.
I risultati della ricerca non sono inclusi nelle notifiche degli avvisi di ricerca log.
A partire dall'API degli 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 MetricValue campo 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 di metrica Null perché non esiste alcun valore che ha causato la risoluzione dell'avviso, ma piuttosto 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 (che è la base per popolare i campi della dimensione e del 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 relativi alla creazione, all'aggiornamento o all'eliminazione di risorse di Azure, all'integrità dei servizi e all'integrità delle risorse o ai risultati di Azure Advisor e Criteri di Azure. Se è stato ricevuto un avviso in base al log attività, ma alcuni campi necessari sono mancanti o errati, controllare prima di tutto gli eventi nel log attività stesso. Se la risorsa di Azure non ha scritto i campi che si sta cercando nell'evento del log attività, tali campi non vengono inclusi nell'avviso corrispondente.
Le proprietà personalizzate non sono presenti nella posta elettronica, negli SMS o nelle notifiche 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 in per le notifiche (posta elettronica/SMS/push).
La regola di elaborazione degli avvisi non funziona come previsto
Se è possibile visualizzare un avviso attivato nel portale, ma una regola di elaborazione degli avvisi correlata non funziona come previsto, seguire questa procedura:
La regola di elaborazione degli avvisi è abilitata?
Controllare il campo stato della regola di elaborazione degli avvisi per verificare che il ruolo azione correlato sia abilitato. 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?
Integrità dei servizi gli avvisi 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 li influirà.
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 debba essere stata attivata ma non sia stata attivata o che non sia stata attivata, esaminare attentamente l'ambito della regola di elaborazione degli avvisi e le condizioni di filtro e confrontarle 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 creare, aggiornare o eliminare una regola di elaborazione degli avvisi, seguire questa procedura:
Controllare le autorizzazioni.
È necessario avere il ruolo predefinito Collaboratore monitoraggio o le autorizzazioni specifiche correlate alle regole e agli avvisi di elaborazione degli avvisi.
Controllare i parametri della regola di elaborazione degli avvisi.
Controllare la documentazione della regola di elaborazione degli avvisi o il comando PowerShell Set-AzAlertProcessingRule della regola di elaborazione degli avvisi.