Felsöka problem i Azure Monitor-aviseringar

Den här artikeln beskriver vanliga problem i Azure Monitor-aviseringar och -meddelanden. Azure Monitor-aviseringar meddelar dig proaktivt när viktiga villkor finns i dina övervakningsdata.

Specifik information om hur du felsöker Azure-mått- eller loggsökningsaviseringar finns i:

• Felsöka Azure Monitor-måttaviseringar
• Felsöka azure monitor-loggsökningsaviseringar

Innan du felsöker

Om aviseringen utlöses som avsett, men rätt meddelanden inte fungerar som förväntat, testar du åtgärdsgruppen först för att säkerställa att den är korrekt konfigurerad.

Annars kan du använda informationen i resten av den här artikeln för att felsöka problemet.

Jag fick inte det förväntade e-postmeddelandet

Om du kan se en utlöst avisering i Azure-portalen, men inte fick det e-postmeddelande som du konfigurerade, följer du dessa steg:

1. Undertrycktes e-postmeddelandet av en regel för aviseringsbearbetning?

   Kontrollera det genom att klicka på den utlösta aviseringen på portalen och gå till historikfliken där du kan se utelämnade åtgärdsgrupper:

   

2. Är typen av åtgärd ”E-posta Azure Resource Manager-rollen”?

   Den här åtgärden tittar bara på Rolltilldelningar i Azure Resource Manager som finns i prenumerationsomfånget och av typen Användare. Kontrollera att du har tilldelat rollen på prenumerationsnivå och inte på resursnivå eller resursgruppsnivå.

3. Accepterar e-postservern och postlådan externa e-postmeddelanden?

   Kontrollera att e-post från följande tre adresser inte blockeras:

   • azure-noreply@microsoft.com
   • azureemail-noreply@microsoft.com
   • alerts-noreply@mail.windowsazure.com

   Det är vanligt att interna e-postlistor eller distributionslistor blockerar e-postmeddelanden från externa e-postadresser. Se till att du tillåter e-post från ovanstående e-postadresser. Du kan testa genom att lägga till en vanlig e-postadress för arbetet (inte en distributionslista) i åtgärdsgruppen och se om aviseringar kommer till den e-postadressen.

4. Har e-postmeddelandet bearbetats av inkorgsregler eller ett skräppostfilter?

   Kontrollera att det inte finns några inkorgsregler som tar bort dessa e-postmeddelanden och flyttar dem till en sidomapp. Inkorgsregler kan till exempel fånga upp vissa avsändare eller ord i ämnet. Kontrollera också:

   • Skräppostinställningarna för din e-postklient (t.ex. Outlook, Gmail)
   • Avsändarens gränser/inställningar för skräppost/karantäninställningar för din e-postserver (till exempel Exchange, Microsoft 365, G-suite)
   • Inställningarna för din säkerhetsinstallation, om sådan finns, (t.ex. Barracuda eller Cisco).

5. Har du av misstag avslutat prenumerationen på åtgärdsgruppen?

   Kommentar

   Tänk på att om du avregistrerar dig från en åtgärdsgrupp kommer även alla medlemmar från en distributionslista att avsluta prenumerationen. Du kan fortsätta att använda din e-postadress för distributionslistan. Du måste dock informera användarna om din distributionslista att om de avregistrerar prenumerationen avregistrerar de hela distributionslistan i stället för bara sig själva. En lösning för detta är att lägga till e-postadressen för alla användare i åtgärdsgruppen individuellt. En åtgärdsgrupp kan innehålla upp till 1 000 e-postadresser. Om en specifik användare sedan vill avbryta prenumerationen kommer de att kunna göra det utan att påverka de andra användarna. Du kommer också att kunna se vilka användare som har avslutat prenumerationen.

   E-postaviseringarna innehåller en länk för att avbryta prenumerationen på åtgärdsgruppen. Om du vill kontrollera om du av misstag har avslutat prenumerationen från den här åtgärdsgruppen kan du antingen:

   1. Öppna åtgärdsgruppen i portalen och kontrollera kolumnen Status:

   

   2. Söka i e-posten efter bekräftelsen på den avbrutna prenumerationen:

   

   Om du vill prenumerera igen – använd antingen länken i bekräftelsemeddelandet för att avbryta prenumerationen som du fick eller ta bort e-postadressen från åtgärdsgruppen och lägg sedan till den igen.

6. Har du överskridit tjänstgränserna genom att skicka många e-postmeddelanden till en enda e-postadress?

   Frekvensen för e-postmeddelanden är begränsad till 100 e-postmeddelanden i timmen till varje e-postadress. Om du klarar det här tröskelvärdet skickas inga fler e-postaviseringar. Kontrollera om du har fått ett meddelande som anger att din e-postadress är tillfälligt begränsad:

   

   Om du vill få en stor mängd meddelanden utan hastighetsbegränsning kan du överväga att använda en annan åtgärd, till exempel:

   • Webhook
   • Logikapp
   • Azure-funktion
   • Automation-runbooks

   Ingen av dessa åtgärder är hastighetsbegränsade.

Jag fick inte det förväntade SMS-, röstsamtalet eller push-meddelandet

Om du kan se en utlöst avisering i portalen, men inte fick det SMS, röstsamtal eller push-meddelande som du konfigurerade, följer du dessa steg:

1. Doldes åtgärden av en regel för aviseringsbearbetning?

   Kontrollera det genom att klicka på den utlösta aviseringen på portalen och gå till historikfliken där du kan se utelämnade åtgärdsgrupper:

   

   Om det var oavsiktligt kan du ändra, inaktivera eller tar bort aviseringsbearbetningsregeln.

2. SMS/röst: Stämmer ditt telefonnummer?

   Kontrollera om landskoden eller telefonnumret i SMS-åtgärden innehåller fel.

3. SMS/röst: har du överskridit tjänstgränserna?

   SMS-meddelanden och röstsamtal är frekvensbegränsade till högst ett meddelande var femte minut per telefonnummer. Om du klarar det här tröskelvärdet tas meddelandena bort.

   • Röstsamtal – kontrollera samtalshistoriken och se om du hade ett annat samtal från Azure under de föregående fem minuterna.
   • SMS – kontrollera din SMS-historik för ett meddelande som anger att ditt telefonnummer är hastighetsbegränsad.

   Om du vill få stora mängder meddelanden utan hastighetsbegränsning kan du överväga att använda en annan åtgärd, till exempel:

   • Webhook
   • Logikapp
   • Azure-funktion
   • Automation-runbooks

   Ingen av dessa åtgärder är hastighetsbegränsade.

4. SMS: Har du avslutat prenumerationen på åtgärdsgruppen av misstag?

   Öppna sms-historiken och kontrollera om du har valt bort SMS-leverans från den här specifika åtgärdsgruppen (med hjälp av svarsmeddelandet INAKTIVERA action_group_short_name) eller från alla åtgärdsgrupper (med hjälp av STOP-svaret).

   Om du vill prenumerera igen kan du antingen skicka relevant SMS-kommando (ENABLE action_group_short_name eller START) eller ta bort SMS-åtgärden från åtgärdsgruppen och sedan lägga tillbaka den igen. Mer information finns i avsnittet om SMS-aviseringsbeteende i åtgärdsgrupper.

5. Har du av misstag blockerat aviseringarna å din telefon?

   På de flesta mobiltelefoner kan du blockera samtal eller SMS från specifika telefonnummer eller kortnummer eller blockera push-meddelanden från vissa appar (till exempel Azure-mobilappen). Du kan kontrollera om du har råkat blockera meddelanden på din telefon genom att läsa dokumentationen för ditt telefonoperativsystem och din telefonmodell eller prova med en annan telefon och ett annat telefonnummer.

Den förväntade åtgärden utlöstes inte

Om du kan se en utlöst avisering i portalen, men den konfigurerade åtgärden inte utlöstes, följer du dessa steg:

1. Undertrycktes åtgärden av en regel för aviseringsbearbetning?

   Kontrollera det genom att klicka på den utlösta aviseringen på portalen och gå till historikfliken där du kan se utelämnade åtgärdsgrupper:

   

   Om det var oavsiktligt kan du ändra, inaktivera eller tar bort aviseringsbearbetningsregeln.

2. Utlöste webhooken?

   1. Är käll-IP-adressen blockerad?

      Lägg till IP-adresserna som webhooken anropas från till listan över tillåtna adresser.

   2. Fungerar webhook-slutpunkten som den ska?

      Kontrollera att webhookens slutpunkt som du konfigurerade är korrekt och att slutpunkten fungerar korrekt. Kontrollera dina webhook-loggar eller instrumentera dess kod så att du kan undersöka den (logga exempelvis den inkommande nyttolasten).

   3. Använder du rätt format för att anropa Slack eller Microsoft Teams?
      Var och en av dessa slutpunkter förväntar sig ett specifikt JSON-format. Följ de här anvisningarna för att konfigurera en åtgärd för en logikapp i stället.

   4. Svarade webhooken inte eller returnerade du fel?

      Webhook-åtgärdsgrupper följer vanligtvis dessa regler när de anropas:

      • När en webhook anropas, om det första anropet misslyckas, görs ett nytt försök minst 1 gång till och upp till fem gånger (5 återförsök) med olika fördröjningsintervall (5, 20, 40 sekunder).
        • Fördröjningen mellan första och andra försöket är 5 sekunder
        • Fördröjningen mellan 2:a och 3:e försöket är 20 sekunder
        • Fördröjningen mellan 3:e och 4:e försöket är 5 sekunder
        • Fördröjningen mellan 4:e och 5:e försöket är 40 sekunder
        • Fördröjningen mellan 5:e och 6:e försöket är 5 sekunder
      • När återförsöken försökte anropa webhooken misslyckas anropar ingen åtgärdsgrupp slutpunkten i 15 minuter.
      • Logiken för återförsök förutsätter att anropet kan göras om. Statuskoderna: 408, 429, 503, 504 eller HttpRequestException, WebExceptioneller TaskCancellationException tillåter att anropet prövas på nytt.

Åtgärden eller meddelandet inträffade mer än en gång

Om du har fått ett meddelande om en avisering (till exempel ett e-postmeddelande eller ett SMS) mer än en gång, eller om aviseringens åtgärd (till exempel webhook eller Azure-funktion) utlöstes flera gånger, följer du dessa steg:

1. Är det verkligen samma avisering?

   I vissa fall utlöses flera liknande aviseringar vid samma tidpunkt. Det kan därför verka som om samma avisering utlöste sin åtgärd flera gånger. En aktivitetsloggaviseringsregel kan till exempel konfigureras för att utlösa både när en händelse startar och slutförs (lyckades eller misslyckades) genom att inte filtrera i fältet händelsestatus.

   Du kan kontrollera om åtgärderna eller meddelandena kommer från olika aviseringar genom att granska aviseringsinformationen, till exempel tidstämpeln och antingen aviserings-ID:t eller korrelations-ID:t. Du kan också kontrollera listan med utlösta aviseringar i portalen. I så fall skulle du behöva anpassa aviseringsregellogik eller på annat sätt konfigurera aviseringskällan.

2. Upprepas åtgärden i flera åtgärdsgrupper?

   När en avisering utlöses bearbetas var och en av åtgärdsgrupperna oberoende av varandra. Om en åtgärd (till exempel en e-postadress) förekommer i flera utlösta åtgärdsgrupper anropas den alltså en gång per åtgärdsgrupp.

   Om du vill kontrollera vilka åtgärdsgrupper som utlöstes kontrollerar du aviseringshistorikfliken. Du skulle se att det finns både åtgärdsgrupper som definierats i aviseringsregeln och åtgärdsgrupper som lagts till i aviseringen genom aviseringsbearbetningsregler:

   

Åtgärden eller meddelandet har oväntat innehåll

1. Uppstod det ett avbrott som utlöste användningen av reserv-e-postleverantören?

   Åtgärdsgrupper använder två olika e-postleverantörer för att säkerställa leverans av e-postmeddelanden. Den primära e-postleverantören är motståndskraftig och snabb men drabbas ibland av avbrott. När det uppstår avbrott hanterar den sekundära e-postleverantören e-postbegäranden. Den sekundära providern är bara en reservlösning. På grund av skillnader mellan leverantörer kan ett e-postmeddelande som skickas från vår sekundära provider ha en försämrad e-postupplevelse. Försämringen resulterar i något annorlunda e-postformatering och innehåll. Eftersom e-postmallarna skiljer sig åt i de två systemen är det inte möjligt att upprätthålla paritet mellan de två systemen.

   Meddelanden som genereras av reservlösningen innehåller en anteckning som säger:

   "Det här är en försämrad e-postupplevelse. Det innebär att formateringen kan vara inaktiverad eller att information saknas. Mer information om den försämrade e-postupplevelsen finns här."

   Om meddelandet inte innehåller den här anteckningen och du har fått aviseringen, men tror att vissa av dess fält saknas eller är felaktiga, kontrollerar du nyttolastformatet.

2. Vilket format använde du när du konfigurerade aviseringsregeln?

   Varje åtgärdstyp (e-post, webhook osv.) har två format – standardformatet, det äldre formatet och det gemensamma schemaformatet. När du skapar en åtgärdsgrupp anger du formatet för åtgärden. Olika åtgärder i åtgärdsgrupperna kan ha olika format.

   Till exempel för webhook-åtgärder:

   

   Kontrollera att formatet som anges på åtgärdsnivå stämmer. Du kan till exempel ha utvecklat kod som svarar på aviseringar (webhook, funktion, logikapp osv.), som förväntar sig ett format, men senare i åtgärden angav du eller en annan person ett annat format.

   Kontrollera också nyttolastformatet (JSON) för aktivitetsloggaviseringar, för loggsökningsaviseringar (både Application Insights och Log Analytics), för måttaviseringar, för det gemensamma aviseringsschemat och för de föråldrade klassiska måttaviseringarna.

Sökresultaten ingår inte i aviseringsaviseringar för loggsökning.

Från och med api-version 2021-08-01 för loggsökningsaviseringar togs sökresultaten bort från nyttolasten för aviseringsmeddelanden. Sökresultat är endast tillgängliga för aviseringsregler som skapats med äldre API-versioner (2018-04-16). Skapande av nya aviseringsregler via Azure-portalen skapar som standard regeln med den nyare versionen. Läs Ändringar i funktionen för att skapa loggaviseringsregeln om du vill veta mer om ändringarna och rekommenderade justeringar vid användning av den uppdaterade versionen.

Fältet MetricValue innehåller "null" för matchade aviseringar om loggsökning.

Det här är avsiktligt. Tillståndskänsliga loggsökningsaviseringar använder en tidsbaserad lösningslogik i stället för värdebaserade. Azure Monitor skickar ett null-måttvärde eftersom det inte finns något värde som gjorde att aviseringen löstes, utan snarare förflutit.

Dimensionslistan är tom eller så innehåller inte aviseringsrubriken något dimensionsnamn

När du har en varningsregel för loggsökning som inte returnerar några resultat kan aviseringen utlösas som förväntat, men dimensionslistan är tom eller så innehåller inte aviseringsrubriken något dimensionsnamn. När en fråga inte returnerar några rader är resurs-ID-fältet (som är grunden för att fylla i dimensions- och rubrikfält) tomt.

Information saknas i en aktivitetsloggavisering

Aktivitetsloggaviseringar är aviseringar som baseras på händelser som skrivits till Azure-aktivitetsloggen, till exempel händelser om att skapa, uppdatera eller ta bort Azure-resurser, händelser för tjänsthälsa och resurshälsa eller resultat från Azure Advisor och Azure Policy. Om du har fått en avisering baserat på aktivitetsloggen men vissa fält som du behöver saknas eller är felaktiga kontrollerar du först händelserna i själva aktivitetsloggen. Om Azure-resursen inte skrev de fält som du letar efter i aktivitetslogghändelsen inkluderas inte dessa fält i motsvarande avisering.

De anpassade egenskaperna saknas i e-post, SMS eller push-meddelanden.

Anpassade egenskaper skickas endast till nyttolasten för åtgärder, till exempel webhook, Azure-funktion eller logikappar. Anpassade egenskaper ingår inte i för meddelanden (e-post/SMS/push).

Aviseringsbearbetningsregeln fungerar inte som förväntat

Om du kan se en utlöst avisering i portalen, men en relaterad aviseringsbearbetningsregel inte fungerade som förväntat, följer du dessa steg:

1. Är regeln för aviseringsbearbetning aktiverad?

   Kontrollera statusfältet för aviseringsbearbetningsregeln för att kontrollera att den relaterade åtgärdsrollen är aktiverad. Som standard visar portalen endast aviseringsregler som är aktiverade, men du kan ändra filtret så att alla regler visas.

   

   Om den inte är aktiverad kan du aktivera aviseringsbearbetningsregeln genom att välja den och klicka på Aktivera.

2. Är det en avisering om tjänsthälsa?

   Tjänststatus aviseringar påverkas inte av aviseringsbearbetningsregler. Så om du har en regel för aviseringsbearbetning konfigurerad för ett omfång som innehåller aviseringar om tjänsthälsa, medan tjänstens hälsoaviseringar ligger inom omfånget, påverkar inte aviseringsbearbetningsregeln dem.

3. Bearbetade aviseringsbearbetningsregeln din avisering?

   Välj den utlösta aviseringen i portalen och titta på fliken Historik för att se om aviseringsbearbetningsregeln bearbetades.

   Här är ett exempel på en regel för aviseringsbearbetning som undertrycker alla åtgärdsgrupper:

   

   Här är ett exempel på en regel för aviseringsbearbetning som lägger till en annan åtgärdsgrupp:

   

4. Matchar regelomfånget och filtret för aviseringsbearbetning den utlösta aviseringen?

   Om du anser att regeln för aviseringsbearbetning borde ha utlösts men inte gjort det, eller om den inte borde ha utlösts, men det gjorde den, bör du noggrant undersöka regelns omfång och filtervillkor för aviseringsbearbetning och jämföra dem med egenskaperna för den utlösta aviseringen.

Problem med att skapa, uppdatera eller ta bort aviseringsbearbetningsregler i Azure-portalen

Om du fick ett fel när du försökte skapa, uppdatera eller ta bort en aviseringsbearbetningsregel följer du dessa steg:

1. Kontrollera behörigheterna.

   Du bör antingen ha den inbyggda rollen Övervakningsdeltagare eller de specifika behörigheter som är relaterade till regler och aviseringar för aviseringsbearbetning.

2. Kontrollera regelparametrarna för aviseringsbearbetning.

   Kontrollera dokumentationen för aviseringsbearbetningsregeln eller kommandot PowerShell Set-AzAlertProcessingRule för aviseringsbearbetningsregeln.

Nästa steg

• Felsöka Azure Monitor-måttaviseringar
• Felsöka azure monitor-loggsökningsaviseringar