Oefening: een toepassingsstatusmodel bouwen
Contoso Shoes heeft een manier nodig om problemen in deze architectuur te detecteren, diagnosticeren en voorspellen. U wilt een statusmodel bouwen dat meetbaar is via een status die wordt toegepast op gebruikers- en systeemstromen. Het doel is om potentiële storingspunten te identificeren voordat ze een storing kunnen veroorzaken.
Huidige status en probleem
Tot nu toe hebt u een statuscontrole-API toegevoegd en mogelijkheden voor meerdere regio's in uw architectuur ontwikkeld. Er is echter geen manier om inzicht te krijgen in de complexe topologie die gebruikers- en systeemstromen omvat. Deze kloof moet worden opgevuld, zodat het SRE-team snel problemen kan identificeren en oplossen.
In een recent incident kon het team de trapsgewijze impact van een probleem dat het gevolg is van een API-onderdeel dat van invloed is op de platformafhankelijkheden niet zien. Er is veel tijd besteed aan het oplossen van problemen omdat het beschadigde onderdeel niet meteen kan worden gezien. Uiteindelijk heeft deze inefficiëntie geleid tot langere downtime, waardoor het bedrijf financieel verlies veroorzaakt.
Specificatie
Ontwerp een statusmodel met de relatie tussen alle onderdelen in de architectuur, inclusief de toepassingsonderdelen en de platformafhankelijkheden. Factor in items die aanwezig zijn in de aanvraagstroom, waaronder de gateway, compute, databases, opslag, caches, enzovoort. Neem ook onderdelen op die doorgaans buiten de aanvraagstroom bestaan. Open OCI-artefacten (Container Initiative), geheime archieven, configuratieservices en andere. Alle Azure-services moeten worden geconfigureerd om diagnostische gegevens te verzenden.
Voeg een geïntegreerde gegevenssink toe in de architectuur voor het verzamelen van gegevens uit verschillende bronnen.
Definieer een algemene status op basis van geaggregeerde historische logboeken en metrische gegevens. Vertegenwoordig de status in een van de drie statussen: beschadigd, gedegradeerd en gezond.
Visualiseer de status van alle onderdelen in een hiërarchie die alle stromen vertegenwoordigt.
Aanbevolen benadering
Als u aan de slag wilt gaan met uw ontwerp, raden we u aan deze stappen uit te voeren:
Belangrijk
Statusmodellering is een uitgebreide oefening. De aanpak in deze sectie is bedoeld om u te helpen aan de slag te gaan. Wees uitgebreid in het toepassen van het model op alle functionele en niet-functionele stromen in uw bedrijfskritiek ontwerp om een holistische weergave van het systeem te krijgen.
1–Statusmodellering starten
Deze oefening is theoretisch. Statusmodellering in een top-down ontwerpactiviteit waarin u een uitgebreide lijst met onderdelen nodig hebt die in de architectuur worden gebruikt. Deze lijst moet alle toepassingsonderdelen en de Azure-services bevatten.
Plaats deze onderdelen in een afhankelijkheidsgrafiek met een hiërarchische weergave van de oplossing. De bovenste laag bevat de gebruikersstromen die de aanvraag van de eindgebruiker naar de website bijhouden en stromen op toepassings-API-niveau. De onderste laag bevat de systeemstromen van de Azure-services. Wijs ook afhankelijkheden toe tussen de Azure-resources.
Uw grafiek ziet er ongeveer als volgt uit:
Controleer uw voortgang: gelaagde toepassingsstatus
2– De statusscores definiëren
Verzamel voor elk onderdeel metrische gegevens en metrische drempelwaarden en bepaal vervolgens de waarde waarmee het onderdeel moet worden beschouwd als in orde, gedegradeerd en beschadigd. Deze beslissing moet worden beïnvloed door de verwachte prestaties en niet-functionele bedrijfsvereisten. Categoriseer uw metrische gegevens als:
Metrische toepassingsgegevens: gegevenspunten uit toepassingscode, zoals het aantal uitzonderingen.
Metrische servicegegevens: gegevenspunten van Azure-services, zoals DTU's (Database Transaction Units) die worden gebruikt.
Metrische gegevens voor oplossingen: gegevenspunten op oplossingsniveau, zoals de end-to-end verwerkingstijd van een aanvraag.
Hier volgt een voorbeeld voor Azure-app Services:
| App-services | Integriteitsstatus |
|---|---|
| Reactietijd < 200 ms HTTP-serverfouten < 2 |
|
| Reactietijd < 500 ms HTTP-serverfouten < 2 |
|
| Reactietijd > 500 ms HTTP-serverfouten > 2 |
|
3– Een algemene status definiëren
Definieer voor elke gebruikers- en systeemstroom een algemene status. U moet de status aggregeren van afzonderlijke onderdelen die deelnemen aan die stroom.
Stel dat een systeemstroom bestaat uit een toepassingsonderdeel, Azure-app Service-plan en App Services.
| API | App Service-plan | App-services | Integriteitsstatus |
|---|---|---|---|
| Maximale latentie < 30 ms | CPU % < 70% HTTP-wachtrijlengte < 5 |
Reactietijd < 200 ms HTTP-serverfouten < 2 |
|
| Maximale latentie < 30 ms | CPU % < 90% HTTP-wachtrijlengte < 5 |
Reactietijd < 500 ms HTTP-serverfouten < 2 |
|
| Maximale latentie > 30 ms | CPU % > 90% HTTP-wachtrijlengte > 5 |
Reactietijd > 500 ms HTTP-serverfouten > 2 |
|
De statusscore voor een gebruikersstroom moet worden vertegenwoordigd door de laagste score voor alle toegewezen onderdelen. Voor systeemstromen past u de juiste gewichten toe op basis van bedrijfskritiek. Tussen de twee stromen moeten financieel significante of klantgerichte gebruikersstromen prioriteit krijgen.
Controleer uw voortgang: voorbeeld - gelaagd statusmodel
4– Bewakingsgegevens verzamelen
U hebt een geïntegreerde gegevenssink nodig in elke regio die logboeken en metrische gegevens verzamelt voor alle toepassings- en platformservices die zijn geïmplementeerd als onderdeel van de regionale stempel. U hebt een andere sink nodig voor het opslaan van metrische gegevens die worden verzonden uit globale resources, zoals Azure Front Door en Cosmos DB.
Technologieopties
- Azure-toepassing Insights: wordt gebruikt om alle telemetriegegevens van toepassingen te verzamelen.
- Azure Monitor-logboeken: verzamelt gegevens die worden verzonden door Application Insights en metrische platformgegevens voor Azure-services.
- Azure Log Analytics: wordt gebruikt als het centrale hulpprogramma voor het analyseren van logboeken en metrische gegevens van alle toepassings- en infrastructuuronderdelen.
Controleer uw voortgang: Geïntegreerde gegevenssink voor gecorreleerde analyse
5– Query's instellen voor bewakingsgegevens
Kusto-querytaal (KQL) is goed geïntegreerd met Log Analytics. Implementeer aangepaste KQL-query's als functies om gegevens op te halen uit Azure Monitor.
Sla aangepaste query's op in de codeopslagplaats, zodat ze automatisch worden geïmporteerd en toegepast als onderdeel van uw CI/CD-pijplijnen (Continuous Integration/Continuous Delivery).
6– De status visualiseren
U kunt de afhankelijkheidsgrafiek visualiseren met statusscores met een verkeerslichtweergave. Gebruik hulpprogramma's zoals Azure Dashboards, Monitor Workbooks of Grafana. Hier volgt een voorbeeld:
Uw voortgang controleren: Visualisatie
7– Waarschuwingen instellen voor statuswijzigingen
U moet dashboards met waarschuwingen gebruiken om direct aandacht te vestigen op problemen.
Als de status van een onderdeel verandert in Gedegradeerd of Beschadigd, moet de operator onmiddellijk worden gewaarschuwd. Stel waarschuwingen in op het hoofdknooppunt, omdat elke wijziging in dit knooppunt een slechte status aangeeft in de onderliggende gebruikersstromen of -resources.
Controleer uw voortgang: waarschuwingen
Controleer uw werk
Bekijk deze demo over bewaking en statusmodellering. Heb je alle aspecten in je ontwerp behandeld?
- Hebt u een geïntegreerde gegevenssink voor gecorreleerde analyse?
- Hebt u toepassingslogboeken, metrische platformgegevens en oplossingsgegevenspunten opgenomen?
- Hebt u dashboards ingesteld om de status van alle onderdelen te visualiseren?
- Hebt u rekening gehouden met storingspunten voor elke service (of een deel van die service) die een storing kunnen veroorzaken of dat u niet kunt schalen, implementeren, bewaken?
- Hebt u querypakketten overwogen voor het vastleggen van sleutelquery's waarmee problemen sneller kunnen worden opgevraagd?
- Was uw statuscontrole-API nuttig in dit model? Moest u die API aanpassen aan het statusmodel?