Slimme detectie - Prestatieafwijkingen

Artikel
04/01/2024

Notitie

U kunt uw Application Insight-resources migreren naar slimme detectie op basis van waarschuwingen (preview). De migratie maakt waarschuwingsregels voor de verschillende modules voor slimme detectie. Zodra u deze regels hebt gemaakt, kunt u deze beheren en configureren, net zoals Azure Monitor-waarschuwingsregels. U kunt ook actiegroepen configureren voor deze regels, waardoor meerdere methoden worden gebruikt om acties uit te voeren of meldingen te activeren bij nieuwe detecties.

Zie Migratie van waarschuwingen voor slimme detectie voor meer informatie over het migratieproces.

Application Insights analyseert automatisch de prestaties van uw webtoepassing en kan u waarschuwen over mogelijke problemen.

Voor deze functie is geen speciale instelling vereist, behalve het configureren van uw app voor Application Insights voor uw ondersteunde taal. Deze is actief wanneer uw app voldoende telemetrie genereert.

Wanneer krijg ik een melding over slimme detectie?

Application Insights heeft vastgesteld dat de prestaties van uw toepassing op een van de volgende manieren zijn verslechterd:

Afname van reactietijd : uw app reageert langzamer op aanvragen dan voorheen. De wijziging kan snel zijn geweest, bijvoorbeeld omdat er een regressie is opgetreden in uw nieuwste implementatie. Of het is misschien geleidelijk geweest, misschien veroorzaakt door een geheugenlek.
Afname van de afhankelijkheidsduur: uw app roept een REST API, database of andere afhankelijkheid aan. De afhankelijkheid reageert langzamer dan voorheen.
Traag prestatiepatroon : uw app lijkt een prestatieprobleem te hebben dat slechts enkele aanvragen beïnvloedt. Pagina's worden bijvoorbeeld langzamer geladen op één type browser dan andere. of aanvragen worden langzamer verwerkt vanaf één bepaalde server. Op dit moment kijken onze algoritmen naar laadtijden van pagina's, reactietijden aanvragen en reactietijden voor afhankelijkheden.

Voor het vaststellen van een basislijn voor normale prestaties vereist slimme detectie ten minste acht dagen van voldoende telemetrievolume. Nadat uw toepassing gedurende die periode is uitgevoerd, resulteren aanzienlijke afwijkingen in een melding.

Heeft mijn app zeker een probleem?

Nee, een melding betekent niet dat uw app zeker een probleem heeft. Het is slechts een suggestie voor iets dat u misschien nauwkeuriger moet bekijken.

Hoe los ik dit op?

De meldingen bevatten diagnostische gegevens. Hier volgt een voorbeeld:

Triage. In de melding ziet u hoeveel gebruikers of hoeveel bewerkingen worden beïnvloed. Deze informatie kan u helpen bij het toewijzen van een prioriteit aan het probleem.
Bereik. Is het probleem van invloed op al het verkeer of op slechts enkele pagina's? Is het beperkt tot bepaalde browsers of locaties? Deze informatie kan worden verkregen via de melding.
Diagnose stellen. Vaak stellen de diagnostische gegevens in de melding de aard van het probleem voor. Als de reactietijd bijvoorbeeld vertraagt wanneer de aanvraagsnelheid hoog is, kan dit erop wijzen dat uw server of afhankelijkheden buiten hun capaciteit vallen.

Open anders het deelvenster Prestaties in Application Insights. U vindt daar Profiler-gegevens . Als er uitzonderingen optreden, kunt u ook het foutopsporingsprogramma voor momentopnamen proberen.

E-mailmeldingen configureren

Meldingen voor slimme detectie zijn standaard ingeschakeld. Ze worden verzonden naar gebruikers met toegang tot bewakingslezer en controlebijdrager voor het abonnement waarin de Application Insights-resource zich bevindt. Als u de standaardmelding wilt wijzigen, klikt u op Configureren in de e-mailmelding of opent u instellingen voor slimme detectie in Application Insights.

U kunt de standaardmelding uitschakelen en vervangen door een opgegeven lijst met e-mailberichten.

E-mailberichten over prestatieafwijkingen voor slimme detectie zijn beperkt tot één e-mail per dag per Application Insights-resource. De e-mail wordt alleen verzonden als er op die dag ten minste één nieuw probleem is gedetecteerd. U ontvangt geen herhalingen van een bericht.

Veelgestelde vragen

Dus, microsoft-medewerkers kijken naar mijn gegevens?
- Nee. De service is volledig automatisch. Alleen u ontvangt de meldingen. Uw gegevens zijn privé.
Analyseert u alle gegevens die zijn verzameld door Application Insights?
- Momenteel analyseren we de reactietijd van de aanvraag, reactietijd van afhankelijkheden en laadtijd van pagina's. Analyse van andere metrische gegevens bevindt zich in onze achterstand die vooruitkijken.
Voor welke typen toepassingen werkt deze detectie?
- Deze degradaties worden gedetecteerd in elke toepassing die de juiste telemetrie genereert. Als u Application Insights in uw web-app hebt geïnstalleerd, worden aanvragen en afhankelijkheden automatisch bijgehouden. Maar als u in back-endservices of andere apps aanroepen naar TrackRequest() of TrackDependency hebt ingevoegd, werkt slimme detectie op dezelfde manier.
Kan ik mijn eigen anomaliedetectieregels maken of bestaande regels aanpassen?
- Nog niet, maar u kunt het volgende doen:
  - Stel waarschuwingen in waarmee wordt aangegeven wanneer een metrische waarde een drempelwaarde overschrijdt.
  - Exporteer telemetrie naar een database of naar Power BI, waar u deze zelf kunt analyseren.
Hoe vaak wordt de analyse uitgevoerd?
- We voeren de analyse dagelijks uit op de telemetrie van de vorige dag (volledige dag in UTC-tijdzone).
Vervangt dit metrische waarschuwingen?
- Nee. We zetten ons niet in voor het detecteren van elk gedrag dat u mogelijk abnormaal beschouwt.
Als ik niets doe als reactie op een melding, krijg ik dan een herinnering?
- Nee, u krijgt slechts één keer een bericht over elk probleem. Als het probleem zich blijft voordoen, wordt het bijgewerkt in het deelvenster met slimme detectiefeeds.
Ik heb het e-mailbericht verloren. Waar vind ik de meldingen in de portal?
- Klik in het Application Insights-overzicht van uw app op de tegel Slimme detectie . Daar vindt u alle meldingen tot 90 dagen terug.

Hoe kan ik de prestaties verbeteren?

Trage en mislukte reacties zijn een van de grootste frustraties voor websitegebruikers, zoals u weet van uw eigen ervaring. Het is dus belangrijk om de problemen op te lossen.

Sorteren

Maakt het eerst uit? Als een pagina altijd langzaam wordt geladen, maar slechts 1% van de gebruikers van uw site deze ooit moet bekijken, hebt u misschien meer belangrijke dingen om over na te denken. Als echter slechts 1% van de gebruikers het opent, maar elke keer uitzonderingen genereert, kan dat het onderzoeken waard zijn.

Gebruik de impact-instructie, zoals betrokken gebruikers of % van het verkeer, als algemene handleiding. Houd er rekening mee dat het misschien niet het hele verhaal vertelt. Verzamel andere bewijzen om te bevestigen.

Houd rekening met de parameters van het probleem. Als het geografisch afhankelijk is, stelt u beschikbaarheidstests in, inclusief die regio: er kunnen netwerkproblemen in dat gebied zijn.

Trage paginabelastingen diagnosticeren

Waar is het probleem? Reageert de server traag, is de pagina te lang of heeft de browser te veel werk nodig om deze weer te geven?

Open het deelvenster Metrische gegevens van Browsers. De gesegmenteerde weergave van de laadtijd van de browserpagina geeft aan waar de tijd heen gaat.

Als de aanvraagtijd voor verzenden hoog is, reageert de server langzaam of is de aanvraag een bericht met een grote hoeveelheid gegevens. Bekijk de metrische prestatiegegevens om reactietijden te onderzoeken.
Stel het bijhouden van afhankelijkheden in om te zien of de traagheid wordt veroorzaakt door externe services of uw database.
Als het ontvangen van een antwoord overheersend is, zijn uw pagina en de afhankelijke onderdelen, JavaScript, CSS, afbeeldingen enzovoort (maar niet asynchroon geladen gegevens) lang. Stel een beschikbaarheidstest in en zorg ervoor dat u de optie instelt om afhankelijke onderdelen te laden. Wanneer u resultaten krijgt, opent u de details van een resultaat en vouwt u het uit om de laadtijden van verschillende bestanden te bekijken.
Hoge tijd voor clientverwerking suggereert dat scripts langzaam worden uitgevoerd. Als de reden niet duidelijk is, kunt u overwegen om wat tijdscode toe te voegen en de tijden in trackMetric-aanroepen te verzenden.

Trage pagina's verbeteren

Er is een web vol advies over het verbeteren van uw serverreacties en laadtijden voor pagina's, dus we proberen het hier niet allemaal te herhalen. Hier volgen enkele tips waarover u waarschijnlijk al weet, gewoon om u te laten denken:

Langzaam laden vanwege grote bestanden: laad de scripts en andere onderdelen asynchroon. Gebruik scriptbundeling. Verbreek de hoofdpagina in widgets die hun gegevens afzonderlijk laden. Verzend geen gewone oude HTML voor lange tabellen: gebruik een script om de gegevens aan te vragen als JSON of een andere compacte indeling en vul de tabel vervolgens in. Er zijn geweldige frameworks om u te helpen met dergelijke taken. (Ze bevatten natuurlijk ook grote scripts.)
Trage serverafhankelijkheden: Houd rekening met de geografische locaties van uw onderdelen. Als u bijvoorbeeld Azure gebruikt, moet u ervoor zorgen dat de webserver en de database zich in dezelfde regio bevinden. Halen query's meer informatie op dan ze nodig hebben? Zou caching of batchverwerking helpen?
Capaciteitsproblemen: bekijk de metrische servergegevens van reactietijden en aantal aanvragen. Als de reactietijden onevenredig hoog zijn met pieken in het aantal aanvragen, is het waarschijnlijk dat uw servers worden uitgerekt.

Degradatie van de reactietijd van de server

In de melding voor degradatie van de reactietijd wordt het volgende aangegeven:

De reactietijd vergeleken met de normale reactietijd voor deze bewerking.
Hoeveel gebruikers worden beïnvloed.
De gemiddelde reactietijd en de reactietijd van het 90e percentiel voor deze bewerking op de dag van de detectie en zeven dagen ervoor.
Het aantal aanvragen voor deze bewerking op de dag van de detectie en zeven dagen ervoor.
Correlatie tussen degradatie in deze bewerking en degradaties in gerelateerde afhankelijkheden.
Koppelingen om u te helpen bij het vaststellen van het probleem.
- Profiler-traceringen kunnen u helpen om te zien waar de bewerkingstijd wordt besteed. De koppeling is beschikbaar als Profiler-traceringsvoorbeelden bestaan voor deze bewerking.
- Prestatierapporten in Metric Explorer, waar u tijdsbereik en filters voor deze bewerking kunt segmenteren en dobbelstenen kunt toepassen.
- Zoek naar deze aanroep om specifieke gesprekseigenschappen weer te geven.
- Foutrapporten: als aantal > 1, betekent dit dat er fouten zijn opgetreden in deze bewerking die mogelijk hebben bijgedragen aan prestatievermindering.

Degradatie van afhankelijkheidsduur

Moderne toepassingen hanteren vaak een benadering voor het ontwerpen van microservices, die in veel gevallen sterk afhankelijk zijn van externe services. Als uw toepassing bijvoorbeeld afhankelijk is van een bepaald gegevensplatform of van een kritieke serviceprovider zoals Azure AI-services.

Voorbeeld van melding over degradatie van afhankelijkheden:

U ziet dat dit u het volgende vertelt:

De duur vergeleken met de normale reactietijd voor deze bewerking
Hoeveel gebruikers worden beïnvloed
Gemiddelde duur en 90e percentielduur voor deze afhankelijkheid op de dag van de detectie en zeven dagen vóór
Aantal afhankelijkheidsaanroepen op de dag van de detectie en zeven dagen vóór
Koppelingen om u te helpen bij het vaststellen van het probleem
- Prestatierapporten in Metric Explorer voor deze afhankelijkheid
- Zoeken naar deze afhankelijkheidsaanroepen om de eigenschappen van aanroepen weer te geven
- Foutrapporten: als aantal > 1, betekent dit dat er tijdens de detectieperiode mislukte afhankelijkheidsaanroepen zijn opgetreden die mogelijk hebben bijgedragen aan duurdegradatie.
- Open Analytics met query's waarmee de duur en telling van deze afhankelijkheid worden berekend

Slimme detectie van traag presterende patronen

Application Insights vindt prestatieproblemen die mogelijk alleen van invloed zijn op een deel van uw gebruikers, of die in sommige gevallen alleen van invloed zijn op gebruikers. Als een pagina bijvoorbeeld langzamer wordt geladen op een specifiek browsertype in vergelijking met anderen, of als een bepaalde server aanvragen langzamer verwerkt dan andere servers. Het kan ook problemen detecteren die zijn gekoppeld aan combinaties van eigenschappen, zoals trage paginabelastingen in één geografisch gebied voor clients die een bepaald besturingssysteem gebruiken.

Afwijkingen zoals deze zijn moeilijk te detecteren door de gegevens te inspecteren, maar komen vaker voor dan u denkt. Vaak komen ze alleen voor wanneer uw klanten klagen. Tegen die tijd is het te laat: de betrokken gebruikers schakelen al over naar uw concurrenten!

Op dit moment kijken onze algoritmen naar laadtijden van pagina's, reactietijden aanvragen op de server en reactietijden van afhankelijkheden.

U hoeft geen drempelwaarden in te stellen of regels te configureren. Machine learning- en data mining-algoritmen worden gebruikt om abnormale patronen te detecteren.

Wanneer de tijd wordt weergegeven waarop het probleem is gedetecteerd.
Wat beschrijft het probleem dat is gedetecteerd en de kenmerken van de set gebeurtenissen die we hebben gevonden, waarin het probleemgedrag werd weergegeven.
De tabel vergelijkt de slecht presterende set met het gemiddelde gedrag van alle andere gebeurtenissen.

Klik op de koppelingen om Metric Explorer te openen om rapporten weer te geven, gefilterd op de tijd en eigenschappen van de traag presterende set.

Wijzig het tijdsbereik en de filters om de telemetrie te verkennen.

Volgende stappen

Met deze diagnostische hulpprogramma's kunt u de telemetrie van uw app inspecteren:

Slimme detectie is automatisch. Maar misschien wilt u wat meer waarschuwingen instellen?

Share via