Gyakorlat – Állapot, metrikák és küszöbértékek meghatározása

Befejeződött

Ebben a gyakorlatban a korábban létrehozott állapotmodell-struktúrát fogjuk használni. A feladat az egyes összetevők állapotának számszerűsítése a példaalkalmazáshoz.

Az állapotmodell struktúrájában először a felülről kiinduló rétegeket értékelje ki a felhasználói folyamatokkal, és folytassa az alsó rétegekkel.

Felhasználói folyamat állapota

Eddig két felhasználói folyamatot azonosítottunk: katalóguselemek listázása és megjegyzés hozzáadása. Az egyes folyamatok állapotának meghatározásához tegye fel a következő kérdéseket:

  • Mikor tekinthető kifogástalannak a felhasználói folyamat?
  • Működik csökkentett állapotban?

A megvalósítási és funkcionális követelmények alapján azonosítsa a felhasználói folyamatban részt vevő alkalmazás-összetevőket. Az összetevőket a példaarchitektúra-összetevők ismertetik.

User flow Összetevők
Katalóguselemek listázása Előtérbeli belső webalkalmazás, Catalog API
Megjegyzés hozzáadása Előtérbeli belső webalkalmazás, Catalog API, háttérprocesszor

Ha bármelyik összetevő nem megfelelő állapotúvá válik, a felhasználói folyamat várhatóan nem megfelelő állapotúvá válik.

Megjegyzés:

Egyes alkalmazások speciális csökkentett módban működhetnek . Ha például a Contoso Shoes helyi böngésző-gyorsítótárazást valósít meg, a webalkalmazást használó alkalmazottak megjegyzéseket hozhatnak létre, de megjegyzéseket nem lehet küldeni, és az ügyfélnézet nem frissül, amíg a Catalog API kifogástalan állapotúvá nem válik, amelyet a böngésző folyamatosan ellenőrizhet.

Alkalmazásösszetevő állapota

Határozza meg az összetevő állapotához hozzájáruló metrikákat. Ehhez a lépéshez ismernie kell az összetevő funkcióit. Tegye fel a következő kérdéseket:

  • Milyen feldolgozási idő érhető el az API-ban a jó felhasználói élmény fenntartása érdekében?
  • Vannak várt hibák? Mi a "normál" hibaarány?
  • Mi a "normál" feldolgozási idő? Mit jelent, ha a feldolgozási idő magasabb a normálnál?
  • Mi történik az írási műveletekkel, ha az Azure Cosmos DB nem érhető el?

Ezeknek a kérdéseknek konkrét és mérhető küszöbértékekhez kell vezetniük a főbb metrikákhoz. Megfontolhatja például a Catalog API-összetevő küszöbértékeit.

Metrikák és küszöbértékek Állapot
Válaszidő < 150 ms
Sikertelen kérések száma < 10
Kifogástalan
Válaszidő < 300 ms
Sikertelen kérések száma < 50
Csökkentett teljesítményű
Válaszidő > 300 ms
Sikertelen kérések száma > 50
Nem kifogástalan

Az értékeket lekérheti egy alkalmazásmonitorozási megoldásból, például az Alkalmazás Elemzések.

Azure-erőforrások állapotának állapota

Az Azure szolgáltatásállapotai adott erőforrásokon alapulnak. Az Azure Cosmos DB például a DTU-kihasználtságot jelenti, a Azure-alkalmazás Services pedig információt nyújt a processzorhasználatról.

A metrikákkal kapcsolatos információk erőforrástípus szerint: Támogatott metrikák az Azure Monitorral.

Állapotok és küszöbértékek

Miután kiértékelte az alkalmazás összes rétegét, rendelkeznie kell az összetevők és azok állapotdefinícióinak listájával, amelyek a példához hasonlóan néznek ki.

Összetevő Mutató/metrika Kifogástalan Csökkentett teljesítményű Nem kifogástalan
Katalóguselemek felhasználói folyamatának listázása Mögöttes állapot Az előtér kifogástalan állapotú és a catalog API kifogástalan állapotú
Megjegyzés felhasználói folyamat hozzáadása Mögöttes állapot Az előtér kifogástalan állapotú, a Catalog API kifogástalan, a háttérprocesszor pedig kifogástalan
Előtérbeli webalkalmazás Nem 20x HTTP-válaszok száma/perc 0 1-10 > 10
Catalog API Kivételek száma/mp < 10 10-50 > 10
Átlagos feldolgozási idő (ms) < 150 150-500 > 500
Háttérprocesszor Várakozási sorban töltött átlagos idő (ms) < 200 200-1,000 > 1,000
Átlagos feldolgozási idő (ms) < 100 100-200 > 200
Hibák száma < 3 3-10 > 10
Azure Cosmos DB DTU-kihasználtság < 70% 70%-90% > 90%
Azure Key Vault Hibák száma < 3 3-10 > 10
Azure Event Hubs Hátralék hossza (kimenő/bejövő üzenetek) feldolgozása < 3 3-20 > 20
Azure Blob Storage Átlagos késés (ms) < 100 100-200 > 200

Ebben a példában az előtérbeli webalkalmazás és a Catalog API hibatűrése eltérő. Ez a különbség az alkalmazás technikai megértéséhez kapcsolódik. Minden előtérbeli hibát ügyféloldalinak kell kezelni, ezért nulla a küszöbérték. Az API-rétegben azonban 10 kivételt lehet figyelembe venni a felhasználó által okozott hibákért. Például az olyan hibák, mint a 404 – Nem található , nem feltétlenül jeleznek állapotproblémát.