Cvičení – definování stavu, metrik a prahových hodnot
V tomto cvičení budeme pokračovat ve struktuře modelu stavu, kterou jste vytvořili dříve. Vaším úkolem je kvantifikovat stav jednotlivých komponent pro ukázkové aplikace.
Ve struktuře modelu stavu začněte vyhodnocením vrstev začínajících nahoře s toky uživatelů a pokračujte k nižším vrstvě.
Stav toku uživatele
Zatím jsme identifikovali dva toky uživatelů: Výpis položek katalogu a přidání komentáře. Pokud chcete určit stav jednotlivých toků, položte otázky, jako jsou:
- Kdy se tok uživatele považuje za v pořádku?
- Může fungovat v degradovaném stavu?
Na základě požadavků na implementaci a funkčnost identifikujte komponenty aplikace, které se účastní toku uživatele. Komponenty jsou popsány v příkladech komponent architektury.
| Tok uživatele | Komponenty |
|---|---|
| Výpis položek katalogu | Interní webová aplikace front-endu, rozhraní API katalogu |
| Přidat komentář | Interní webová aplikace front-endu, rozhraní API katalogu, procesor na pozadí |
Pokud některá z těchto komponent není v pořádku, očekává se, že tok uživatele nebude v pořádku.
Poznámka:
Některé aplikace můžou fungovat ve speciálním degradovaném režimu. Pokud například Contoso Shoes implementuje ukládání do mezipaměti místního prohlížeče, můžou zaměstnanci, kteří používají webovou aplikaci, vytvářet komentáře, ale komentáře se nedají odeslat a zobrazení zákazníka se neaktualizuje, dokud se rozhraní API katalogu neaktualizuje, což prohlížeč může průběžně kontrolovat.
Stav součásti aplikace
Určete metriky, které přispívají ke stavu komponenty. V tomto kroku budete muset znát funkce komponenty. Ptejte se na něco podobného:
- Jaká doba zpracování v rozhraní API je přijatelná pro zachování dobrého uživatelského prostředí?
- Došlo k nějakým očekávaným chybám? Jaká je "normální" míra chyb?
- Jaká je "normální" doba zpracování? Co znamená, že doba zpracování je vyšší než normální?
- Co se stane s operacemi zápisu, pokud je služba Azure Cosmos DB nedostupná?
Tyto otázky by vás měly vést ke konkrétním a měřitelným prahům klíčových metrik. Můžete například zvážit tyto prahové hodnoty pro komponentu rozhraní API katalogu.
| Metriky a prahová hodnota | Stav |
|---|---|
| Doba < odezvy 150 ms Počet neúspěšných požadavků < 10 | V pořádku |
| Doba < odezvy 300 ms Počet neúspěšných požadavků < 50 | Snížený výkon |
| Doba > odezvy 300 ms Počet neúspěšných požadavků > 50 | Není v pořádku |
Hodnoty můžete získat z řešení pro monitorování aplikací, jako je Přehledy aplikace.
Stav služby Azure Resource Health
Stavy stavu služby Azure jsou založené na konkrétních prostředcích. Například Azure Cosmos DB hlásí využití DTU a Aplikace Azure Services poskytuje informace o využití procesoru.
Informace o metrikách podle typu prostředku najdete v tématu Podporované metriky ve službě Azure Monitor.
Stavy a prahové hodnoty
Po vyhodnocení všech vrstev aplikace byste měli mít seznam komponent a jejich definic stavu, které vypadají podobně jako v tomto příkladu.
| Komponenta | Ukazatel/metrika | V pořádku | Snížený výkon | Není v pořádku |
|---|---|---|---|---|
| Zobrazení seznamu položek uživatelského toku položek katalogu | Základní stav | Rozhraní API front-endu v pořádku a rozhraní API katalogu v pořádku | ||
| Přidání toku uživatele komentáře | Základní stav | Front-end v pořádku, rozhraní API katalogu v pořádku a procesor na pozadí | ||
| Front-endová webová aplikace | # of non-20x HTTP responses/min | 0 | 1-10 | > 10 |
| Rozhraní API pro katalog | # of exceptions/sec | < 10 | 10-50 | > 10 |
| Průměrná doba zpracování (ms) | < 150 | 150-500 | > 500 | |
| Procesor na pozadí | Průměrná doba ve frontě (ms) | < 200 | 200-1,000 | > 1,000 |
| Průměrná doba zpracování (ms) | < 100 | 100-200 | > 200 | |
| Počet selhání | < 3 | 3-10 | > 10 | |
| Azure Cosmos DB | Využití DTU | < 70% | 70%-90% | > 90% |
| Azure Key Vault | Počet selhání | < 3 | 3-10 | > 10 |
| Azure Event Hubs | Zpracování délky backlogu (odchozí/příchozí zprávy) | < 3 | 3-20 | > 20 |
| Azure Blob Storage | Průměrná latence (ms) | < 100 | 100-200 | > 200 |
V tomto příkladu se tolerance chyb pro front-endovou webovou aplikaci a rozhraní API katalogu liší. Tento rozdíl souvisí s technickým porozuměním aplikace. Všechny chyby front-endu by se měly zpracovávat na straně klienta, takže je nulová prahová hodnota. Na vrstvě rozhraní API však může 10 výjimek počítat s chybami způsobenými uživatelem. Například chyby 404 – Nenalezena nemusí nutně znamenat problém se stavem.