Dela via


Smart identifiering – Prestandaavvikelser

Kommentar

Du kan migrera dina Application Insight-resurser till aviseringsbaserad smart identifiering (förhandsversion). Migreringen skapar aviseringsregler för de olika modulerna för smart identifiering. När reglerna har skapats kan du hantera och konfigurera dem på samma sätt som andra aviseringsregler i Azure Monitor. Du kan också konfigurera åtgärdsgrupper för reglerna, så att du har fler möjligheter att vidta åtgärder och utlösa meddelanden vid nya identifieringar.

Mer information om migreringsprocessen finns i Migrering av smarta identifieringsaviseringar.

Application Insights analyserar automatiskt webbappens prestanda och kan varna dig om potentiella problem.

Den här funktionen kräver ingen särskild konfiguration, förutom att konfigurera din app för Application Insights för ditt språk som stöds. Den är aktiv när din app genererar tillräckligt med telemetri.

När skulle jag få ett meddelande om smart identifiering?

Application Insights har upptäckt att programmets prestanda har försämrats på något av följande sätt:

  • Försämrad svarstid – Appen har börjat svara på begäranden långsammare än den brukade. Ändringen kan ha gått snabbt, till exempel eftersom det fanns en regression i den senaste distributionen. Eller så kan det ha varit gradvis, kanske orsakat av en minnesläcka.
  • Försämring av beroendevaraktighet – Appen anropar ett REST API, en databas eller ett annat beroende. Beroendet svarar långsammare än det brukade.
  • Långsamt prestandamönster – Appen verkar ha ett prestandaproblem som bara påverkar vissa begäranden. Sidor läses till exempel in långsammare i en typ av webbläsare än andra. eller begäranden hanteras långsammare från en viss server. För närvarande tittar våra algoritmer på sidinläsningstider, svarstider för begäranden och svarstider för beroenden.

För att upprätta en baslinje för normal prestanda kräver smart identifiering minst åtta dagars tillräcklig telemetrivolym. När programmet har körts under den perioden resulterar betydande avvikelser i ett meddelande.

Har min app definitivt ett problem?

Nej, ett meddelande innebär inte att din app definitivt har problem. Identifieringen är bara ett förslag på något som du kanske vill titta närmare på.

Hur åtgärdar jag detta?

Meddelandena innehåller diagnostikinformation. Här är ett exempel:

Här är ett exempel på identifiering av serversvarstidsförsämring

  1. Triage. Meddelandet visar hur många användare eller hur många åtgärder som påverkas. Den här informationen kan hjälpa dig att tilldela en prioritet till problemet.

  2. Omfång. Påverkar problemet all trafik eller bara vissa sidor? Är det begränsat till vissa webbläsare eller platser? Den här informationen kan hämtas från meddelandet.

  3. Diagnostisera. Ofta tyder diagnostikinformationen i meddelandet på problemets art. Om svarstiden till exempel blir långsammare när begärandefrekvensen är hög kan det tyda på att servern eller beroendena ligger utanför deras kapacitet.

    Annars öppnar du fönstret Prestanda i Application Insights där du hittar .NET Profiler-data. Om undantag utlöses kan du också prova felsökningsprogrammet för ögonblicksbilder.

Konfigurera e-postaviseringar

Meddelanden om smart identifiering är aktiverade som standard. De skickas till användare som har åtkomst till övervakningsläsare och övervakningsdeltagare till prenumerationen där Application Insights-resursen finns. Om du vill ändra standardmeddelandet klickar du antingen på Konfigurera i e-postmeddelandet eller öppnar Inställningar för smart identifiering i Application Insights.

Inställningar för smart identifiering

  • Du kan inaktivera standardmeddelandet och ersätta det med en angiven lista med e-postmeddelanden.

E-postmeddelanden om prestandaavvikelser för smart identifiering är begränsade till ett e-postmeddelande per dag per Application Insights-resurs. E-postmeddelandet skickas endast om det finns minst ett nytt problem som upptäcktes den dagen. Du får inga upprepningar av något meddelande.

Vanliga frågor och svar

  • Så, Microsofts personal tittar på mina data?

    • Nej. Tjänsten är helt automatisk. Det är bara du som får meddelandena. Dina data är privata.
  • Analyserar du alla data som samlas in av Application Insights?

    • För närvarande analyserar vi svarstid för begäran, svarstid för beroenden och sidinläsningstid. Analysen av andra mått ligger på vår kvarvarande information framöver.
  • Vilka typer av program fungerar den här identifieringen för?

    • Dessa försämringar identifieras i alla program som genererar lämplig telemetri. Om du har installerat Application Insights i webbappen spåras begäranden och beroenden automatiskt. Men i serverdelstjänster eller andra appar fungerar smart identifiering på samma sätt om du har infogat anrop till TrackRequest() eller TrackDependency.
  • Kan jag skapa egna regler för avvikelseidentifiering eller anpassa befintliga regler?

  • Hur ofta görs analysen?

    • Vi kör analysen dagligen på telemetrin från föregående dag (hela dagen i UTC-tidszonen).
  • Ersätter detta måttaviseringar?

    • Nej. Vi åtar oss inte att identifiera alla beteenden som du kan anse vara onormala.
  • Får jag en påminnelse om jag inte gör något som svar på ett meddelande?

    • Nej, du får bara ett meddelande om varje problem en gång. Om problemet kvarstår uppdateras det i fönstret för smart identifieringsflöde.
  • Jag förlorade e-postmeddelandet. Var hittar jag meddelandena i portalen?

    • I Application Insights-översikten över din app klickar du på panelen Smart identifiering . Där hittar du alla meddelanden för upp till 90 dagar tillbaka.

Hur kan jag förbättra prestandan?

Långsamma och misslyckade svar är en av de största frustrationerna för webbplatsanvändare, som du vet från din egen erfarenhet. Därför är det viktigt att ta itu med problemen.

Sortera

För det första, spelar det någon roll? Om en sida alltid är långsam att läsa in, men bara 1 % av webbplatsens användare någonsin behöver titta på den, kanske du har viktigare saker att tänka på. Men om bara 1 % av användarna öppnar den, men den genererar undantag varje gång, kan det vara värt att undersöka.

Använd konsekvensbeskrivningen, till exempel berörda användare eller % av trafiken, som en allmän guide. Tänk på att det kanske inte berättar hela historien. Samla in andra bevis för att bekräfta.

Överväg problemets parametrar. Om det är geografiskt beroende konfigurerar du tillgänglighetstester inklusive den regionen: det kan finnas nätverksproblem i det området.

Diagnostisera långsamma sidinläsningar

Var finns problemet? Svarar servern långsamt, är sidan för lång eller behöver webbläsaren för mycket arbete för att visa den?

Öppna fönstret Webbläsarmått. Den segmenterade visningen av webbläsarsidans inläsningstid visar vart tiden är på väg.

  • Om sändningstiden är hög svarar servern långsamt eller så är begäran ett inlägg med stora mängder data. Titta på prestandamåtten för att undersöka svarstider.
  • Konfigurera beroendespårning för att se om långsamheten beror på externa tjänster eller din databas.
  • Om Mottagande svar är dominerande är sidan och dess beroende delar – JavaScript, CSS, bilder och så vidare (men inte asynkront inlästa data) långa. Konfigurera ett tillgänglighetstest och se till att ange alternativet för att läsa in beroende delar. När du får några resultat öppnar du informationen om ett resultat och expanderar det för att se inläsningstiderna för olika filer.
  • Hög klientbearbetningstid tyder på att skripten körs långsamt. Om orsaken inte är uppenbar kan du överväga att lägga till tidskod och skicka tiderna i trackMetric-anrop.

Förbättra långsamma sidor

Det finns en webb full av råd om att förbättra dina serversvar och sidinläsningstider, så vi försöker inte upprepa allt här. Här är några tips som du förmodligen redan vet om, bara för att få dig att tänka:

  • Långsam inläsning på grund av stora filer: Läs in skripten och andra delar asynkront. Använd paketering av skript. Dela upp huvudsidan i widgetar som läser in sina data separat. Skicka inte vanlig gammal HTML för långa tabeller: Använd ett skript för att begära data som JSON eller annat kompakt format och fyll sedan tabellen på plats. Det finns bra ramverk för att hjälpa till med sådana uppgifter. (De innehåller även stora skript, naturligtvis.)
  • Långsamma serverberoenden: Överväg komponenternas geografiska platser. Om du till exempel använder Azure kontrollerar du att webbservern och databasen finns i samma region. Hämtar frågor mer information än de behöver? Skulle cachelagring eller batchbearbetning vara till hjälp?
  • Kapacitetsproblem: Titta på servermåtten för svarstider och antal förfrågningar. Om svarstiderna ökar oproportionerligt med toppar i antalet begäranden är det troligt att servrarna är utsträckta.

Försämrad serversvarstid

Meddelandet om svarstidsförsämring visar följande:

  • Svarstiden jämfört med normal svarstid för den här åtgärden.
  • Hur många användare som påverkas.
  • Genomsnittlig svarstid och 90:e percentilsvarstiden för den här åtgärden på identifieringsdagen och sju dagar tidigare.
  • Antal begäranden om den här åtgärden på dagen för identifieringen och sju dagar innan.
  • Korrelation mellan nedbrytning i den här åtgärden och försämringar i relaterade beroenden.
  • Länkar som hjälper dig att diagnostisera problemet.
    • .NET Profiler-spårningar kan hjälpa dig att se var driftstiden används. Länken är tillgänglig om det finns spårningsexempel för .NET Profiler för den här åtgärden.
    • Prestandarapporter i Metric Explorer, där du kan segmentera och tärna tidsintervall/filter för den här åtgärden.
    • Sök efter det här anropet för att visa specifika samtalsegenskaper.
    • Felrapporter – Om antalet är > 1 innebär det att det fanns fel i den här åtgärden som kan ha bidragit till prestandaförsämring.

Försämring av beroendevaraktighet

Moderna program använder ofta en designmetod för mikrotjänster, som i många fall är starkt beroende av externa tjänster. Om ditt program till exempel förlitar sig på någon dataplattform eller på en leverantör av kritiska tjänster, till exempel Azure AI-tjänster.

Exempel på meddelande om beroendeförsämring:

Här är ett exempel på identifiering av försämring av beroendevaraktighet

Observera att det säger dig:

  • Varaktigheten jämfört med normal svarstid för den här åtgärden
  • Hur många användare som påverkas
  • Genomsnittlig varaktighet och 90:e percentilvaraktighet för det här beroendet på identifieringsdagen och sju dagar före
  • Antal beroendeanrop på identifieringsdagen och sju dagar före
  • Länkar som hjälper dig att diagnostisera problemet
    • Prestandarapporter i Metric Explorer för det här beroendet
    • Sök efter det här beroendeanropet för att visa anropsegenskaper
    • Felrapporter – Om antalet är > 1 innebär det att det fanns misslyckade beroendeanrop under identifieringsperioden som kan ha bidragit till en försämring av varaktigheten.
    • Öppna Analys med frågor som beräknar den här beroendevaraktigheten och antalet

Smart identifiering av mönster med långsamma prestanda

Application Insights hittar prestandaproblem som bara kan påverka en del av dina användare eller bara påverka användare i vissa fall. Om en sida till exempel läses in långsammare för en viss webbläsartyp jämfört med andra, eller om en viss server hanterar begäranden långsammare än andra servrar. Den kan också identifiera problem som är associerade med kombinationer av egenskaper, till exempel långsamma sidinläsningar i ett geografiskt område för klienter som använder ett visst operativsystem.

Avvikelser som dessa är svåra att identifiera bara genom att inspektera data, men är vanligare än du kanske tror. Ofta dyker de bara upp när dina kunder klagar. Vid det laget är det för sent: de berörda användarna byter redan till dina konkurrenter!

För närvarande tittar våra algoritmer på sidinläsningstider, svarstider för begäranden på servern och svarstider för beroenden.

Du behöver inte ange några tröskelvärden eller konfigurera regler. Maskininlärnings- och datautvinningsalgoritmer används för att identifiera onormala mönster.

Från e-postaviseringen klickar du på länken för att öppna diagnostikrapporten i Azure

  • När visas när problemet upptäcktes.
  • Vad beskriver problemet som identifierades och de här egenskaperna för den uppsättning händelser som vi hittade, som visade problembeteendet.
  • Tabellen jämför den dåligt presterande uppsättningen med det genomsnittliga beteendet för alla andra händelser.

Klicka på länkarna för att öppna Metric Explorer för att visa rapporter, filtrerade efter tid och egenskaper för den långsamma uppsättningen.

Ändra tidsintervallet och filtren för att utforska telemetrin.

Nästa steg

De här diagnostikverktygen hjälper dig att inspektera telemetrin från din app:

Smart identifiering är automatiskt. Men du kanske vill ställa in några fler aviseringar?