Megosztás a következőn keresztül:


Intelligens detektálás – Teljesítményanomáliák

Megjegyzés:

Az Application Insight-erőforrásokat a riasztásalapú intelligens észlelésre (előzetes verzió) migrálhatja. The migration creates alert rules for the different smart detection modules. Once created, you can manage and configure these rules just like any other Azure Monitor alert rules. You can also configure action groups for these rules, thus enabling multiple methods of taking actions or triggering notification on new detections.

Az áttelepítési folyamatról további információt az Intelligens észlelési riasztások áttelepítése című témakörben talál.

Az alkalmazás Elemzések automatikusan elemzi a webalkalmazás teljesítményét, és figyelmeztetheti a lehetséges problémákra.

Ez a funkció nem igényel speciális beállítást, kivéve, ha az alkalmazást az Alkalmazás Elemzések a támogatott nyelvhez konfigurálja. Aktív, ha az alkalmazás elegendő telemetriát hoz létre.

Mikor kapok intelligens észlelési értesítést?

Az alkalmazás Elemzések észlelte, hogy az alkalmazás teljesítménye az alábbi módokon csökkent:

  • Válaszidő romlása – Az alkalmazás lassabban kezdett válaszolni a kérésekre, mint korábban. A változás gyors lehetett, például azért, mert regresszió történt a legújabb üzembe helyezés során. Vagy lehet, hogy fokozatos volt, talán memóriavesztés okozta.
  • Függőségek időtartamának romlása – Az alkalmazás REST API-ra, adatbázisra vagy más függőségre irányuló hívásokat indít. A függőség lassabban válaszol, mint korábban.
  • Lassú teljesítményminta – Úgy tűnik, hogy az alkalmazás teljesítményproblémája csak néhány kérést érint. A lapok például lassabban töltődnek be egy böngészőtípusra, mint mások; vagy a kérések lassabban lesznek kiszolgálva egy adott kiszolgálóról. Az algoritmusok jelenleg a lapbetöltési időket, a kérelmek válaszideit és a függőségi válaszidőket vizsgáljuk meg.

A normál teljesítmény alapkonfigurációjának megállapításához az intelligens észleléshez legalább nyolc nap elegendő telemetriai kötetre van szükség. Miután az alkalmazás ebben az időszakban futott, jelentős anomáliák fognak értesítést eredményezni.

Az alkalmazásomnak biztosan van problémája?

Nem, az értesítés nem jelenti azt, hogy az alkalmazásnak biztosan van problémája. Ezek csupán javaslatok, hogy az adott anomáliát érdemes részletesebben megvizsgálni.

Hogyan kijavítani?

Az értesítések diagnosztikai információkat tartalmaznak. Here's an example:

Here is an example of Server Response Time Degradation detection

  1. Triage. Az értesítés megmutatja, hogy hány felhasználót vagy hány műveletet érint. Ezek az információk segíthetnek a probléma prioritásának hozzárendelésében.

  2. Hatókör. A probléma minden forgalmat érint, vagy csak néhány oldalt? Bizonyos böngészőkre vagy helyekre korlátozódik? Ez az információ az értesítésből szerezhető be.

  3. Diagnosztika. Az értesítésben szereplő diagnosztikai információk gyakran a probléma természetére utalnak. Ha például a válaszidő lelassul, amikor a kérések száma magas, az azt jelezheti, hogy a kiszolgáló vagy a függőségek túllépik a kapacitásukat.

    Ellenkező esetben nyissa meg a Teljesítmény panelt az Alkalmazás Elemzések. Itt profilkészítő adatokat talál. Ha kivételeket ad ki, kipróbálhatja a pillanatkép-hibakeresőt is.

E-mail-értesítések konfigurálása

Az intelligens észlelési értesítések alapértelmezés szerint engedélyezve vannak. A rendszer azoknak a felhasználóknak küldi el őket, akiknek a Figyelési olvasó és a Figyelési közreműködő hozzáférése van ahhoz az előfizetéshez, amelyben az alkalmazás Elemzések erőforrás található. Az alapértelmezett értesítés módosításához kattintson a Konfigurálás gombra az e-mail-értesítésben, vagy nyissa meg az Intelligens észlelési beállításokat az Alkalmazás Elemzések.

Smart Detection Settings

  • Letilthatja az alapértelmezett értesítést, és lecserélheti egy megadott e-mail-listára.

Az intelligens észlelési teljesítmény rendellenességeiről szóló e-mailek naponta egy e-mailre korlátozódnak alkalmazásonként Elemzések erőforrásonként. Az e-mailt csak akkor küldi el a rendszer, ha az adott napon legalább egy új problémát észleltek. Egyetlen üzenet sem ismétlődik.

Gyakori kérdések

  • A Microsoft munkatársai megnézik az adataimat?

    • Nem. A szolgáltatás teljesen automatikus. Csak Ön kapja meg az értesítéseket. Az adatai privátak.
  • Elemzi az Alkalmazás Elemzések által gyűjtött összes adatot?

    • Jelenleg a kérelmek válaszidejének, a függőségi válaszidőnek és a lapbetöltési időnek a elemzését vizsgáljuk. Az egyéb metrikák elemzése a hátralékunkra vár.
  • Milyen típusú alkalmazások esetén működik ez az észlelés?

    • Ezek a degradációk minden olyan alkalmazásban észlelhetők, amely létrehozza a megfelelő telemetriát. Ha telepítette az Alkalmazás Elemzések a webalkalmazásban, a rendszer automatikusan nyomon követi a kérelmeket és a függőségeket. A háttérszolgáltatásokban vagy más alkalmazásokban azonban, ha a TrackRequest() vagy a TrackDependency hívásait szúrta be, az intelligens észlelés ugyanúgy működik.
  • Létrehozhatok saját anomáliadetektálási szabályokat, vagy testre szabhatom a meglévő szabályokat?

  • Milyen gyakran történik az elemzés?

    • Az elemzést naponta futtatjuk az előző nap telemetriájával (utc időzóna szerint).
  • Ez lecseréli a metrikariasztásokat?

    • Nem. Nem kötelezettséget vállalunk arra, hogy minden rendellenesnek ítélt viselkedést észlel.
  • Ha nem csinálok semmit az értesítésre válaszul, emlékeztetőt kapok?

    • Nem, az egyes problémákról csak egyszer kap üzenetet. Ha a probléma továbbra is fennáll, az intelligens észlelési hírcsatorna panelen frissül.
  • Elvesztettem az e-mailt. Hol találom az értesítéseket a portálon?

    • Az Alkalmazás Elemzések alkalmazás áttekintésében kattintson az Intelligens észlelés csempére. Itt 90 napig minden értesítés megtalálható.

Hogyan javíthatom a teljesítményt?

A lassú és sikertelen válaszok az egyik legnagyobb frusztrációt okoznak a webhely felhasználói számára, amint azt saját tapasztalataiból tudja. Ezért fontos, hogy megoldjuk a problémákat.

Osztályozás

Először is számít? Ha egy oldal betöltése mindig lassú, de a webhely felhasználóinak csak 1%-ának kell megnéznie, talán fontosabb dolgokra kell gondolnia. Ha azonban csak a felhasználók 1%-a nyitja meg, de minden alkalommal kivételeket vet fel, érdemes lehet kivizsgálni.

Általános útmutatóként használja a hatásutasítást, például az érintett felhasználókat vagy a forgalom %-át. Ne feledje, hogy lehet, hogy nem meséli el az egész történetet. Gyűjtsön más bizonyítékot, hogy megerősítse.

Vegye figyelembe a probléma paramétereit. Ha földrajzilag függő, állítson be rendelkezésre állási teszteket , beleértve az adott régiót is: hálózati problémák lehetnek ezen a területen.

Lassú oldalbetöltések diagnosztizálása

Hol található a probléma? A kiszolgáló lassan válaszol, túl hosszú az oldal, vagy túl sok munkát igényel a böngésző ahhoz, hogy megjelenjen?

Nyissa meg a Böngészők metrika panelt. A böngészőoldal betöltési idejének szegmentált megjelenítése azt mutatja, hogy hol tart az idő.

  • Ha a kérés elküldésének ideje magas, vagy a kiszolgáló lassan válaszol, vagy a kérés nagy mennyiségű adatot tartalmazó bejegyzés. Tekintse meg a teljesítménymetrikákat a válaszidők vizsgálatához.
  • Állítson be függőségkövetést annak megállapításához, hogy a lassúság a külső szolgáltatások vagy az adatbázis miatt van-e.
  • Ha a Válasz fogadása elsődleges, a lap és annak függő részei – JavaScript, CSS, képek stb. (de nem aszinkron módon betöltött adatok) hosszúak. Állítson be egy rendelkezésre állási tesztet, és mindenképpen állítsa be a függő alkatrészek betöltésének lehetőségét. Ha eredményt kap, nyissa meg az eredmény részleteit, és bontsa ki a különböző fájlok betöltési idejének megtekintéséhez.
  • A magas ügyfélfeldolgozási idő azt jelzi, hogy a szkriptek lassan futnak. Ha az ok nem egyértelmű, fontolja meg az időzítési kód hozzáadását, és küldje el az időpontokat a trackMetric-hívásokban.

Lassú oldalak fejlesztése

Egy web tele van tanácsokkal a kiszolgáló válaszainak és a lapbetöltési idők javításához, ezért itt nem próbáljuk megismételni az egészet. Íme néhány tipp, amelyről valószínűleg már tud, csak hogy elgondolkodjon:

  • Lassú betöltés nagy fájlok miatt: A szkriptek és más részek aszinkron betöltése. Használjon szkriptcsomagolást. A főoldalt olyan widgetekre bontja, amelyek külön töltik be az adataikat. Ne küldjön egyszerű régi HTML-t hosszú táblázatokhoz: használjon szkriptet az adatok JSON-ként vagy más kompakt formátumban való lekéréséhez, majd töltse ki a táblázatot a helyén. Vannak nagyszerű keretrendszerek, amelyek segítenek az ilyen feladatokban. (Természetesen nagy szkripteket is tartalmaznak.)
  • Lassú kiszolgálófüggőségek: Vegye figyelembe az összetevők földrajzi helyét. Ha például az Azure-t használja, győződjön meg arról, hogy a webkiszolgáló és az adatbázis ugyanabban a régióban található. A lekérdezések több információt kérnek le, mint amennyi szükséges? Segít a gyorsítótárazás vagy a kötegelés?
  • Kapacitásproblémák: Tekintse meg a kiszolgáló válaszidejének és a kérések számának metrikáit. Ha a válaszidők aránytalanul csúcsosodnak a kérések számában, akkor valószínű, hogy a kiszolgálók ki vannak feszítve.

Kiszolgáló válaszidejének romlása

A válaszidő romlását jelző értesítés a következőt jelzi:

  • A művelet normál válaszidejével összehasonlítva a válaszidő.
  • Hány felhasználó érintett.
  • A művelet átlagos válaszideje és 90. percentilis válaszideje az észlelés napján és hét nappal korábban.
  • A műveletkérések száma az észlelés napján és hét nappal korábban.
  • Korreláció a művelet romlása és a kapcsolódó függőségek romlása között.
  • Hivatkozások a probléma diagnosztizálásához.
    • A profilkészítő nyomkövetések segítségével megtekintheti, hogy hol töltik a műveleti időt. A hivatkozás akkor érhető el, ha a profiler nyomkövetési példái léteznek ehhez a művelethez.
    • Teljesítményjelentések a Metric Explorerben, ahol szeletelheti és kockázhatja a művelet időtartományát/szűrőit.
    • Keresse meg ezt a hívást adott hívástulajdonságok megtekintéséhez.
    • Hibajelentések – Ha 1-et számlál > , az azt jelenti, hogy olyan hibák történtek ebben a műveletben, amelyek hozzájárulhattak a teljesítménycsökkenéshez.

Függőségek időtartamának romlása

A modern alkalmazások gyakran alkalmazzák a mikroszolgáltatások tervezési megközelítését, amely sok esetben nagymértékben támaszkodik a külső szolgáltatásokra. Ha például az alkalmazás valamilyen adatplatformra vagy egy kritikus fontosságú szolgáltatóra, például az Azure AI-szolgáltatásokra támaszkodik.

Példa a függőségek romlását jelző értesítésre:

Here is an example of Dependency Duration Degradation detection

Figyelje meg, hogy a következőt mondja:

  • A művelet normál válaszidejével összehasonlított időtartam
  • Hány felhasználó érintett
  • A függőség átlagos időtartama és 90. percentilis-időtartama az észlelés napján és hét nappal korábban
  • A függőségi hívások száma az észlelés napján és hét nappal korábban
  • Hivatkozások a probléma diagnosztizálásához
    • Teljesítményjelentések a Metrikaböngészőben ehhez a függőséghez
    • A hívások tulajdonságainak megtekintéséhez keresse meg ezt a függőségi hívást
    • Hibajelentések – Ha 1-es szám > , az azt jelenti, hogy sikertelen függőségi hívások történtek az észlelési időszakban, amelyek hozzájárulhattak az időtartam csökkenéséhez.
    • Az Elemzés megnyitása olyan lekérdezésekkel, amelyek kiszámítják a függőség időtartamát és számát

Lassú végrehajtású minták intelligens észlelése

Az alkalmazás Elemzések olyan teljesítményproblémákat talál, amelyek csak a felhasználók egy részét érinthetik, vagy csak bizonyos esetekben érintik a felhasználókat. Ha például egy oldal lassabban tölt be egy adott böngészőtípust, mint mások, vagy ha egy adott kiszolgáló lassabban kezeli a kéréseket, mint a többi kiszolgáló. Emellett olyan problémákat is felfedezhet, amelyek tulajdonságok kombinációihoz kapcsolódnak, például lassú lapbetöltések egy földrajzi területen az adott operációs rendszert használó ügyfelek számára.

Az ilyen anomáliákat nehéz észlelni csak az adatok vizsgálatával, de gyakoribbak, mint gondolná. Gyakran csak akkor bukkannak fel, ha az ügyfelek panaszkodnak. Addigra már túl késő: az érintett felhasználók már váltanak a versenytársakra!

Az algoritmusok jelenleg a lapbetöltési időket, a kérések válaszideit és a függőségi válaszidőket vizsgáljuk meg.

Nem kell küszöbértékeket beállítania vagy szabályokat konfigurálnia. A gépi tanulási és adatbányászati algoritmusok a rendellenes minták észlelésére szolgálnak.

From the email alert, click the link to open the diagnostic report in Azure

  • Amikor megjelenik a probléma észlelésének időpontja.
  • Mi írja le az észlelt problémát, és a talált események halmazának jellemzőit, amelyek a probléma viselkedését mutatják.
  • A táblázat összehasonlítja a rosszul teljesítő készletet az összes többi esemény átlagos viselkedésével.

A hivatkozásokra kattintva megnyithatja a Metrikaböngészőt a jelentések megtekintéséhez, amelyeket a lassú teljesítményhalmaz ideje és tulajdonságai szűrnek.

Módosítsa az időtartományt és a szűrőket a telemetria vizsgálatához.

Következő lépések

Ezek a diagnosztikai eszközök segítenek az alkalmazás telemetriájának vizsgálatában:

Az intelligens észlelés automatikus. De lehet, hogy szeretne még néhány riasztást beállítani?