Gyakorlat – Állapot, metrikák és küszöbértékek meghatározása
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.