Webalkalmazások és szolgáltatások részletes diagnosztikája az Application Insights szolgáltatással

Ez a cikk azt ismerteti, hogyan illeszkedik az Application Insights a DevOps-ciklusba.

Miért van szükségem az Application Insightsra?

Az Application Insights figyeli a futó webalkalmazást. Ismerteti a hibákat és a teljesítményproblémákat, és segít elemezni, hogyan használják az ügyfelek az alkalmazást. Olyan platformokon futó alkalmazásokhoz használható, mint a ASP.NET, a Java EE és a Node.js. A felhőben vagy a helyszínen üzemel.

A modern alkalmazások futás közben történő monitorozása elengedhetetlen. Az ügyfelek előtt szeretné észlelni a hibákat. Emellett olyan teljesítményproblémákat is szeretne felderíteni és kijavítani, amelyek lelassítják a dolgokat, vagy kényelmetlenséget okoznak a felhasználóknak. Ha a rendszer elégedetten teljesít, azt is tudni szeretné, hogy a felhasználók mit csinálnak vele. Például a legújabb funkciót használják? Sikerrel járnak?

A modern webalkalmazásokat a folyamatos teljesítés ciklusában fejlesztjük:

• Új funkció vagy fejlesztés kiadása.
• Figyelje meg, hogy milyen jól működik a felhasználók számára.
• Tervezze meg a fejlesztés következő lépését ezen ismeretek alapján.

Ennek a ciklusnak a kulcsfontosságú része a megfigyelési fázis. Az Application Insights olyan eszközöket biztosít, amelyekkel monitorozhat egy webalkalmazást a teljesítmény és a használat szempontjából.

Ennek a folyamatnak a legfontosabb eleme a diagnosztika és a diagnosztika. Ha az alkalmazás meghibásodik, az üzlet elveszik. A monitorozási keretrendszer elsődleges szerepe a következő:

• A hibák megbízható észlelése.
• Azonnal értesítse.
• Mutassa be a probléma diagnosztizálásához szükséges információkat.

Az Application Insights elvégzi ezeket a feladatokat.

Honnan származnak a hibák?

A webrendszerek hibái általában konfigurációs problémákból vagy a számos összetevő közötti rossz interakcióból erednek. Az élő helyszíni incidensek kezelésének első feladata a probléma locusának azonosítása. Melyik összetevő vagy kapcsolat az oka?

Egy egyszerűbb korszakban egy számítógépes program futott egy számítógépen. A fejlesztők alaposan tesztelték a szállítás előtt, és a szállítás után ritkán látták vagy gondolták újra. A felhasználóknak sok éven át ki kellett állítaniuk a fennmaradó hibákat.

A folyamat most már teljesen más. Az alkalmazás számos különböző eszközön futtatható, és nehéz lehet garantálni, hogy mindegyiken pontosan ugyanaz a viselkedés legyen. Az alkalmazások felhőben való üzemeltetése azt jelenti, hogy a hibák gyorsan javíthatók. Ez azonban azt is jelenti, hogy folyamatos a verseny, és az új funkciók várhatók gyakran.

Ilyen körülmények között a hibaszám szigorú ellenőrzésének egyetlen módja az automatizált egységtesztelés. Nem lehet manuálisan újra tesztelni mindent minden kézbesítéskor. Az egységteszt mostantól a buildelési folyamat gyakori része. Az olyan eszközök, mint a Xamarin Test Cloud, segítenek az automatizált felhasználói felület tesztelésében több böngészőverzión. Ezek a tesztelési rendszerek lehetővé teszik számunkra, hogy reménykedjünk abban, hogy az alkalmazásokban talált hibák aránya a lehető legalacsonyabb szinten tartható.

A tipikus webalkalmazások számos élő összetevőt tartalmaznak. Az ügyféllel (böngészőben vagy eszközalkalmazásban) és a webkiszolgálóval együtt valószínűleg jelentős háttér-feldolgozás várható. Lehet, hogy a háttér egy összetevőkből álló folyamat vagy egy közösen együttműködő darab laza gyűjteménye. Sokan nem lesznek az Ön irányítása alatt. Ezek olyan külső szolgáltatások, amelyektől Ön függ.

Az ilyen konfigurációkban nehéz és nem gazdaságos lehet minden lehetséges meghibásodási módot tesztelni vagy előrejelezni, kivéve magát az élő rendszert.

Kérdések

Íme néhány kérdés, amit fel kell tenni egy webes rendszer fejlesztésekor:

• Összeomlik az alkalmazás?
• Pontosan mi történt? Ha egy kérés meghiúsult, tudni szeretné, hogyan került oda. Események nyomára van szüksége.
• Elég gyors az alkalmazás? Mennyi ideig tart a tipikus kérések megválaszolása?
• Képes a kiszolgáló kezelni a terhelést? Ha a kérések száma emelkedik, a válaszidő állandó?
• Mennyire rugalmasak a függőségek, például a REST API-k, az adatbázisok és az alkalmazás által meghívt egyéb összetevők? Különösen, ha a rendszer lassú, ez az ön összetevője, vagy valaki mástól kap lassú válaszokat?
• Az alkalmazás fel- vagy le van állítva? Lehet látni a világ minden tájáról? Tudnia kell, hogy leáll-e.
• Mi a kiváltó ok? Hiba történt az összetevőben vagy függőségben? Kommunikációs probléma?
• Hány felhasználót érint? Ha egynél több problémát kell megoldania, melyik a legfontosabb?

Mi az Application Insights?

1. Az Application Insights eszközöket ad az alkalmazásnak, és telemetriát küld róla az alkalmazás futása közben. Létrehozhatja az Application Insights SDK-t az alkalmazásba, vagy futtatáskor alkalmazhatja a rendszerállapot-kialakítást. Az előbbi módszer rugalmasabb, mert hozzáadhatja a saját telemetriáját a normál modulokhoz.
2. A telemetria az Application Insights portálra kerül, ahol a rendszer tárolja és feldolgozja. Bár az Application Insights az Azure-ban van üzemeltetve, bármilyen webalkalmazást figyelhet, nem csak az Azure-alkalmazásokat.
3. A telemetria diagramok és eseménytáblák formájában jelenik meg.

A telemetriának két fő típusa van: az összesített és a nyers példányok.

• A példányadatok tartalmazhatnak egy jelentést a webalkalmazás által fogadott kérésről. A kérés részleteit az Application Insights portál Keresés eszközével keresheti meg és vizsgálhatja meg. A példány olyan adatokat tartalmazhat, mint például az, hogy az alkalmazás mennyi ideig tartott a kérésre való válaszadáshoz, valamint a kért URL-címhez és az ügyfél hozzávetőleges helyéhez.
• Az összesített adatok az egységenkénti események számát tartalmazzák, így összehasonlíthatja a kérések arányát a válaszidőkkel. Emellett olyan metrikák átlagait is tartalmazza, mint a kérelmek válaszideje.

Az adatok fő kategóriái a következők:

• Az alkalmazásnak küldött kérések (általában HTTP-kérések) URL-címmel, válaszidővel és sikerrel vagy hibával kapcsolatos adatokkal.
• Függőségek, például az alkalmazás által kezdeményezett REST- és SQL-hívások, URI-val, válaszidővel és sikerrel.
• Kivételek, beleértve a verem-nyomkövetéseket is.
• Oldalnézeti adatok, amelyek a felhasználók böngészőiből származnak.
• Olyan metrikák, mint a teljesítményszámlálók és a saját maga által írt metrikák.
• Egyéni események, amelyekkel nyomon követheti az üzleti eseményeket.
• Hibakereséshez használt naplókövetések.

Esettanulmány: Real Madrid FC

A Real Madrid Football Club webszolgáltatása világszerte mintegy 450 millió szurkolót szolgál ki. A szurkolók webböngészőken és a klub mobilalkalmazásain keresztül érhetik el. A rajongók jegyet foglalhatnak, és információkat és videoklipeket is hozzáférhetnek az eredményekről, a játékosokról és a közelgő játékokról. Olyan szűrőkkel kereshetnek, mint a szerzett gólok száma. A közösségi médiára mutató hivatkozások is találhatók. A felhasználói élmény nagymértékben személyre szabott, és kétirányú kommunikációként lett kialakítva, hogy bevonja a rajongókat.

A megoldás az Azure-beli szolgáltatások és alkalmazások rendszere. A méretezhetőség kulcsfontosságú követelmény. A forgalom változó, és a mérkőzések során és környékén nagy mennyiségeket érhet el.

A Real Madrid számára létfontosságú a rendszer teljesítményének monitorozása. Az Application Insights átfogó képet nyújt a rendszerről a megbízható és magas szintű szolgáltatás biztosítása érdekében.

A klub emellett alapos ismereteket szerez a szurkolóiról, például arról, hogy hol vannak (csak 3%, Spanyolországban vannak), milyen érdeklődési körük van a játékosok iránt, a történelmi eredmények és a közelgő játékok iránt, és hogy hogyan reagálnak a mérkőzés eredményeire.

A telemetriai adatok nagy része automatikusan, kód hozzáadása nélkül lesz összegyűjtve, ami leegyszerűsíti a megoldást, és csökkenti a működési összetettség mértékét. A Real Madrid esetében az Application Insights havonta 3,8 milliárd telemetriai ponttal foglalkozik.

A Real Madrid a Power BI modullal tekinti meg a telemetriai adatokat.

Intelligens detektálás

A proaktív diagnosztika egy új funkció. Az Application Insights a speciális konfigurációk nélkül automatikusan észleli és riasztást küld az alkalmazásban tapasztalható szokatlan hibaarány-emelkedésről. Elég okos ahhoz, hogy figyelmen kívül hagyja az alkalmi hibák hátterét, és olyan emelkedéseket is, amelyek egyszerűen arányosak a kérések számának növekedésével.

Előfordulhat például, hogy hiba történt az egyik olyan szolgáltatásban, amelytől függ. Vagy lehet, hogy az üzembe helyezett új build nem működik megfelelően. Amint megtekinti az e-mail-címét, tudnia kell róla. Vannak webhookok is, amelyekkel más alkalmazásokat is aktiválhat.

A funkció egy másik aspektusa napi részletes elemzést végez a telemetriai adatokról, és szokatlan teljesítménymintákat keres, amelyeket nehéz felderíteni. Előfordulhat például, hogy egy adott földrajzi területhez vagy egy adott böngészőverzióhoz kapcsolódó lassú teljesítményről van szó.

A riasztás mindkét esetben jelzi a felfedezett tüneteket. Emellett a probléma diagnosztizálásához szükséges adatokat is megadja, például a vonatkozó kivételjelentéseket.

Samtec ügyfél a következőt mondta: "A funkció átállása során egy olyan, alulméretezett adatbázist találtunk, amely elérte az erőforráskorlátokat, és időtúllépéseket okozott. A proaktív észlelési riasztások szó szerint a probléma osztályozása során jöttek létre, nagyon közel valós időben a meghirdetett módon. Ez a riasztás és az Azure-platform riasztásai szinte azonnal segítettek megoldani a problémát. Teljes állásidő <10 perc."

Élő metrikastream

A legújabb build üzembe helyezése aggodalomra ad lehetőséget. Ha bármilyen probléma merül fel, azonnal tudnia kell róluk, hogy szükség esetén vissza tudjon készülni. Az élő metrikák streamje körülbelül egy másodperces késéssel biztosítja a legfontosabb metrikákat.

Lehetővé teszi, hogy azonnal megvizsgáljon egy mintát az esetleges hibákról vagy kivételekről.

Alkalmazástérkép

Az Alkalmazástérkép automatikusan felderíti az alkalmazástopológiát. A rendszer a teljesítményadatokat a térképre helyezi, így könnyen azonosíthatja a teljesítmény szűk keresztmetszeteit és a problémás folyamatokat az elosztott környezetben. Az Application Map segítségével felderítheti az Azure-szolgáltatások alkalmazásfüggőségeit.

A problémák osztályozásához megtudhatja, hogy kóddal vagy függőséggel kapcsolatos-e. Egyetlen helyről részletezheti a kapcsolódó diagnosztikai élményt. Előfordulhat például, hogy az alkalmazás meghiúsul egy SQL-szint teljesítménycsökkenése miatt. Az Application Map segítségével azonnal megtekintheti, és részletezheti az SQL Index Advisor vagy a Query Insights felületét.

Application Insights Log Analytics

A Log Analytics segítségével tetszőleges lekérdezéseket írhat hatékony SQL-szerű nyelven. A teljes alkalmazásverem diagnosztizálása egyszerűvé válik a különböző perspektívák összekapcsolása során. Ezután felteheti a megfelelő kérdéseket a szolgáltatásteljesítmény és az üzleti metrikák és az ügyfélélmény korrelálásához.

A portálon tárolt összes telemetriai példányt és metrika nyers adatot lekérdezheti. A nyelv szűrőt, illesztést, összesítést és egyéb műveleteket tartalmaz. Mezőket számíthat ki, és statisztikai elemzést végezhet. Táblázatos és grafikus vizualizációk érhetők el.

Például a következőket könnyű:

• Szegmentálta az alkalmazás kérési teljesítményadatait ügyfélszintek szerint, hogy megértse a felhasználói élményt.
• Keressen konkrét hibakódokat vagy egyéni eseményneveket az élő webhely vizsgálata során.
• A funkciók beszerzésének és használatának megismeréséhez tekintse meg az egyes ügyfelek alkalmazáshasználatát.
• Adott felhasználók munkameneteinek és válaszideinek nyomon követése, hogy a támogatási és üzemeltetési csapatok azonnali ügyfélszolgálatot nyújtsanak.
• A szolgáltatás priorizálásával kapcsolatos kérdések megválaszolásához gyakran használt alkalmazásfunkciók meghatározása.

Az ügyfél DNN-je azt mondta: "Az Application Insights biztosította számunkra az egyenlet hiányzó részét, hogy szükség szerint kombinálhassuk, rendezhessünk, lekérdezhessünk és szűrhessünk adatokat. Ha lehetővé teszi a csapatunk számára, hogy a saját leleményességüket és tapasztalatukat felhasználva hatékony lekérdezési nyelvvel keressenek adatokat, betekintést nyerhetünk, és megoldhatjuk azokat a problémákat, amelyekről még nem is tudtunk. Sok érdekes válasz származik a kérdések kezdve "Kíváncsi vagyok, ha ..."."

Fejlesztői eszközök integrációja

Az Application Insights integrálható a fejlesztői eszközökkel.

Az Application Insights konfigurálása

A Visual Studio és az Eclipse eszközökkel rendelkezik a fejlesztendő projekthez megfelelő SDK-csomagok konfigurálásához. Van egy menüparancs az Application Insights hozzáadásához.

Ha olyan nyomkövetési naplózási keretrendszert használ, mint a Log4N, az NLog vagy a System.Diagnostics.Trace, lehetősége van arra, hogy a többi telemetriával együtt elküldje a naplókat az Application Insightsnak, így könnyedén összevetheti a nyomkövetéseket a kérésekkel, függőségi hívásokkal és kivételekkel.

Telemetria keresése a Visual Studióban

A funkciók fejlesztése és hibakeresése során közvetlenül a Visual Studióban tekintheti meg és keresheti meg a telemetriát. Ugyanazokat a keresési lehetőségeket használhatja, mint a webportálon.

Amikor az Application Insights naplóz egy kivételt, megtekintheti az adatpontot a Visual Studióban, és közvetlenül a megfelelő kódra ugorhat.

A hibakeresés során megtarthatja a telemetriát a fejlesztői gépen. A Visual Studióban anélkül tekintheti meg, hogy elküldené a portálra. Ez a helyi beállítás nem keveri össze a hibakeresést az éles telemetriával.

Munkaelemek

Riasztás létrehozásakor az Application Insights automatikusan létrehozhat egy munkaelemet a munkakövető rendszerben.