Övning – Definiera hälsotillstånd, mått och tröskelvärden
I den här övningen fortsätter vi med den hälsomodellstruktur som du skapade tidigare. Din uppgift är att kvantifiera hälsotillstånd för enskilda komponenter för exempelprogrammet.
I hälsomodellstrukturen börjar du med att utvärdera lagren som börjar längst upp med användarflöden och fortsätter till de lägre lagren.
Hälsotillstånd för användarflöde
Hittills har vi identifierat två användarflöden: Lista katalogobjekt och Lägg till kommentar. För att fastställa hälsotillstånd för varje flöde ställer du frågor som:
- När anses användarflödet vara felfritt?
- Kan den fungera i ett degraderat tillstånd?
Baserat på implementerings- och funktionskraven identifierar du de programkomponenter som deltar i användarflödet. Komponenterna beskrivs i Exempel på arkitekturkomponenter.
| Användarflöde | Komponenter |
|---|---|
| Lista katalogobjekt | Internt webbprogram på klientsidan, katalog-API |
| Lägg till kommentar | Intern webbapp i klientdelen, katalog-API, bakgrundsprocessor |
Om någon av dessa komponenter blir felfritt förväntas användarflödet bli felfritt.
Kommentar
Vissa program kan fungera i ett särskilt degraderat läge. Om Contoso Shoes till exempel implementerar cachelagring av lokala webbläsare kan anställda som använder webbprogrammet skapa kommentarer, men kommentarer kan inte skickas och kundvyn uppdateras inte förrän katalog-API:et blir felfritt, vilket webbläsaren kontinuerligt kan kontrollera.
Hälsotillstånd för programkomponent
Fastställa mått som bidrar till komponentens hälsotillstånd. För det här steget måste du känna till komponentens funktioner. Ställ frågor som:
- Vilken bearbetningstid i API:et är acceptabel för att upprätthålla en bra användarupplevelse?
- Finns det några förväntade fel? Vad är den "normala" felfrekvensen?
- Vad är den "normala" bearbetningstiden? Vad innebär det om bearbetningstiden är högre än normalt?
- Vad händer med skrivåtgärder om Azure Cosmos DB inte kan nås?
De här frågorna bör leda dig till specifika och mätbara tröskelvärden för viktiga mått. Du kan till exempel överväga dessa tröskelvärden för komponenten Katalog-API.
| Mått och tröskelvärde | Hälsotillstånd |
|---|---|
| Svarstid < 150 ms Antal misslyckade förfrågningar < 10 | Felfri |
| Svarstid < 300 ms Antal misslyckade förfrågningar < 50 | Degraderad |
| Svarstid > 300 ms Antal misslyckade förfrågningar > 50 | Ohälsosamt |
Du kan hämta värdena från en programövervakningslösning, till exempel Application Insights.
Hälsotillstånd för Azure-resurser
Hälsotillstånd för Azure-tjänsten baseras på specifika resurser. Till exempel rapporterar Azure Cosmos DB databastransaktionsenhetsanvändning (DTU) och Azure App Services innehåller information om processoranvändning.
Information om mått efter resurstyp finns i Mått som stöds med Azure Monitor.
Hälsotillstånd och tröskelvärden
När du har utvärderat alla lager i programmet bör du ha en lista över komponenter och deras hälsotillståndsdefinitioner som liknar det här exemplet.
| Komponent | Indikator/mått | Felfri | Degraderad | Ohälsosamt |
|---|---|---|---|---|
| Lista användarflöde för katalogobjekt | Underliggande hälsotillstånd | Klientdelen är felfri och katalog-API:et är felfritt | ||
| Lägg till kommentarsanvändarflöde | Underliggande hälsotillstånd | Klientdelen är felfri, katalog-API:et är felfritt och bakgrundsprocessorn felfri | ||
| Klientwebbprogram | Antal icke-20x HTTP-svar/min | 0 | 1-10 | > 10 |
| Katalog-API | Antal undantag per sekund | < 10 | 10-50 | > 10 |
| Genomsnittlig bearbetningstid (ms) | < 150 | 150-500 | > 500 | |
| Bakgrundsprocessor | Genomsnittlig tid i kö (ms) | < 200 | 200-1,000 | > 1,000 |
| Genomsnittlig bearbetningstid (ms) | < 100 | 100-200 | > 200 | |
| Antal fel | < 3 | 3-10 | > 10 | |
| Azure Cosmos DB | DTU-användning | < 70% | 70%-90% | > 90% |
| Azure Key Vault | Antal fel | < 3 | 3-10 | > 10 |
| Azure Event Hubs | Bearbetning av kvarvarande uppgifter (utgående/inkommande meddelanden) | < 3 | 3-20 | > 20 |
| Azure Blob Storage | Genomsnittlig svarstid (ms) | < 100 | 100-200 | > 200 |
I det här exemplet skiljer sig feltoleransen för klientwebbprogrammet och katalog-API:et. Den här skillnaden gäller den tekniska förståelsen av programmet. Alla klientdelsfel bör hanteras på klientsidan, så det finns ett tröskelvärde på noll. Men på API-lagret tillåts 10 undantag att ta hänsyn till användarorsakade fel. Till exempel indikerar fel som 404 – Hittades inte nödvändigtvis ett hälsoproblem.