Oefening: status, metrische gegevens en drempelwaarden definiëren
In deze oefening gaan we verder met de structuur van het statusmodel die u eerder hebt gemaakt. Uw taak is om de statussen van afzonderlijke onderdelen voor de voorbeeldtoepassing te kwantificeren.
Begin in de structuur van het statusmodel door de lagen te evalueren die bovenaan met gebruikersstromen beginnen en doorgaan naar de lagere lagen.
Status van gebruikersstroom
Tot nu toe hebben we twee gebruikersstromen geïdentificeerd: Catalogusitems vermelden en Opmerking toevoegen. Als u de statusstatussen voor elke stroom wilt bepalen, stelt u vragen zoals:
- Wanneer wordt de gebruikersstroom als in orde beschouwd?
- Kan het werken in een gedegradeerde status?
Identificeer op basis van de implementatie- en functionele vereisten de toepassingsonderdelen die deelnemen aan de gebruikersstroom. De onderdelen worden beschreven in de onderdelen van de voorbeeldarchitectuur.
| Gebruikersstroom | Onderdelen |
|---|---|
| Catalogusitems weergeven | Front-end interne webtoepassing, Catalogus-API |
| Opmerking toevoegen | Front-end interne webtoepassing, Catalogus-API, Achtergrondprocessor |
Als een van deze onderdelen beschadigd raakt, wordt verwacht dat de gebruikersstroom beschadigd raakt.
Notitie
Sommige toepassingen kunnen worden uitgevoerd in een speciale gedegradeerde modus. Als Contoso Shoes bijvoorbeeld lokale cacheopslag in de browser implementeert, kunnen werknemers die de webtoepassing gebruiken opmerkingen maken, maar opmerkingen kunnen niet worden verzonden en wordt de weergave van de klant pas bijgewerkt als de Catalogus-API in orde is, waardoor de browser continu kan controleren.
Status van toepassingsonderdeel
Bepaal metrische gegevens die bijdragen aan de status van het onderdeel. Voor deze stap moet u de functionaliteit van het onderdeel kennen. Stel vragen als:
- Welke verwerkingstijd in de API is acceptabel om een goede gebruikerservaring te behouden?
- Zijn er verwachte fouten? Wat is het 'normale' foutpercentage?
- Wat is de 'normale' verwerkingstijd? Wat betekent dit als de verwerkingstijd hoger is dan normaal?
- Wat gebeurt er met schrijfbewerkingen als Azure Cosmos DB niet bereikbaar is?
Deze vragen moeten u leiden tot specifieke en meetbare drempelwaarden voor belangrijke metrische gegevens. U kunt deze drempelwaarden bijvoorbeeld overwegen voor het onderdeel Catalogus-API.
| Metrische gegevens en drempelwaarden | Status |
|---|---|
| Reactietijd < 150 ms Mislukte aanvraag tellen < 10 | In orde |
| Reactietijd < 300 ms Mislukte aanvraag tellen < 50 | Verminderd beschikbaar |
| Reactietijd > 300 ms Mislukte aanvraag tellen > 50 | Niet in orde |
U kunt de waarden ophalen uit een toepassingsbewakingsoplossing, zoals Application Insights.
Status van Azure-resource
Statussen van Azure-services zijn gebaseerd op specifieke resources. Azure Cosmos DB rapporteert bijvoorbeeld DTU-gebruik (Database Transaction Unit) en Azure-app Services biedt informatie over het CPU-gebruik.
Zie Ondersteunde metrische gegevens met Azure Monitor voor informatie over metrische gegevens per resourcetype.
Statussen en drempelwaarden
Nadat u alle lagen van de toepassing hebt geëvalueerd, moet u een lijst met onderdelen en de bijbehorende statusdefinities hebben die er ongeveer uitzien als in dit voorbeeld.
| Onderdeel | Indicator/metrische waarde | In orde | Verminderd beschikbaar | Niet in orde |
|---|---|---|---|---|
| Gebruikersstroom voor catalogusitems weergeven | Onderliggende status | Front-end in orde en Catalogus-API in orde | ||
| Gebruikersstroom voor opmerkingen toevoegen | Onderliggende status | Front-end in orde, Catalogus-API in orde en achtergrondprocessor in orde | ||
| Front-endwebtoepassing | Aantal niet-20x HTTP-antwoorden/min. | 0 | 1-10 | > 10 |
| Catalog API | Aantal uitzonderingen per seconde | < 10 | 10-50 | > 10 |
| Gemiddelde verwerkingstijd (ms) | < 150 | 150-500 | > 500 | |
| Achtergrondprocessor | Gemiddelde tijd in wachtrij (ms) | < 200 | 200-1,000 | > 1,000 |
| Gemiddelde verwerkingstijd (ms) | < 100 | 100-200 | > 200 | |
| Aantal fouten | < 3 | 3-10 | > 10 | |
| Azure Cosmos DB | DTU-gebruik | < 70% | 70%-90% | > 90% |
| Azure Key Vault | Aantal fouten | < 3 | 3-10 | > 10 |
| Azure Event Hubs | Lengte van achterstand verwerken (uitgaande/inkomende berichten) | < 3 | 3-20 | > 20 |
| Azure Blob-opslag | Gemiddelde latentie (ms) | < 100 | 100-200 | > 200 |
In dit voorbeeld is de fouttolerantie voor de front-endwebtoepassing en de Catalogus-API anders. Dit verschil heeft betrekking op het technische begrip van de toepassing. Alle front-endfouten moeten worden verwerkt aan de clientzijde, dus er is een drempelwaarde van nul. Op de API-laag mogen echter 10 uitzonderingen rekening houden met door de gebruiker veroorzaakte fouten. Bijvoorbeeld: fouten zoals 404 - Niet gevonden geven niet noodzakelijkerwijs een statusprobleem aan.