Esercizio - Definire lo stato di integrità, le metriche e le soglie
In questo esercizio si continuerà con la struttura del modello di integrità creata in precedenza. Il vostro compito è quello di quantificare lo stato di salute dei singoli componenti dell'applicazione di esempio.
Nella struttura del modello di salute, si inizia a valutare gli strati partendo dall'alto con i flussi di utenti e si procede con gli strati inferiori.
Stato di integrità del flusso utente
Finora sono stati identificati due flussi utente: Elencare gli elementi del catalogo e Aggiungi commento. Per determinare gli stati di integrità per ogni flusso, porre domande come:
- Quando il flusso utente è considerato integro?
- Può funzionare in uno stato danneggiato?
In base ai requisiti di implementazione e funzionali, identificare i componenti dell'applicazione che partecipano al flusso dell'utente. I componenti sono descritti in Componenti di architettura di esempio.
| Flusso utente | Componenti |
|---|---|
| Elencare gli elementi del catalogo | Applicazione Web interna front-end, API catalogo |
| Aggiungi commento | Applicazione Web interna front-end, API catalogo, processore in background |
Se uno di questi componenti diventa non integro, si prevede che il flusso utente diventi non integro.
Nota
Alcune applicazioni possono funzionare in una modalità danneggiata speciale. Ad esempio, se Contoso Shoes implementa la memorizzazione nella cache del browser locale, i dipendenti che utilizzano l'applicazione Web possono creare commenti, ma i commenti non possono essere inviati e la visualizzazione del cliente non viene aggiornata fino a quando l'API catalogo non diventa integra, in modo che il browser la possa controllare continuamente.
Stato di integrità del componente dell'applicazione
Determinare le metriche che contribuiscono allo stato di integrità del componente. Per questo passaggio, è necessario conoscere la funzionalità del componente. Fare domande come:
- Quale tempo di elaborazione nell'API è accettabile per mantenere un'esperienza utente ottimale?
- Sono presenti errori previsti? Qual è la frequenza di errore "normale"?
- Qual è il tempo di elaborazione "normale"? Cosa significa se il tempo di elaborazione è superiore al normale?
- Cosa accade alle operazioni di scrittura se Azure Cosmos DB non è raggiungibile?
Queste domande dovrebbero portare a soglie specifiche e misurabili per le metriche chiave. Ad esempio, è possibile considerare questi valori soglia per il componente API catalogo.
| Metriche e soglie | Stato integrità |
|---|---|
| Tempo di risposta < 150 ms Numero di richieste non riuscite < 10 |
Healthy |
| Tempo di risposta < 300 ms Numero di richieste non riuscite < 50 |
Degraded |
| Tempo di risposta > 300 ms Numero di richieste non riuscite > 50 |
Unhealthy |
È possibile ottenere i valori da una soluzione di monitoraggio delle applicazioni, ad esempio Application Insights.
Stato di integrità delle risorse di Azure
Gli stati di integrità dei servizi di Azure si basano su risorse specifiche. Ad esempio, Azure Cosmos DB segnala l'utilizzo delle unità di elaborazione di database e Servizio app di Azure fornisce informazioni sull'utilizzo della CPU.
Per informazioni sulle metriche in base al tipo di risorsa, vedere Metriche supportate con Monitoraggio di Azure.
Stati di integrità e soglie
Dopo aver valutato tutti i livelli dell'applicazione, è necessario avere un elenco di componenti e le relative definizioni dello stato di integrità simili a questo esempio.
| Componente | Indicatore/metrica | Healthy | Degraded | Unhealthy |
|---|---|---|---|---|
| Elencare gli elementi catalogo del flusso utente | Stato di integrità sottostante | Integrità dell'API front-end e dell'API catalogo | ||
| Aggiungere un commento al flusso utente | Stato di integrità sottostante | Integrità del front-end, integrità dell'API catalogo e integrità del processore in background | ||
| Applicazione Web front-end | Numero di risposte HTTP non 20x/min | 0 | 1-10 | > 10 |
| API Catalogo | Numero di eccezioni/sec | < 10 | 10-50 | > 10 |
| Durata media di elaborazione (ms) | < 150 | 150-500 | > 500 | |
| Processore in background | Tempo medio nella coda (ms) | < 200 | 200-1,000 | > 1,000 |
| Durata media di elaborazione (ms) | < 100 | 100-200 | > 200 | |
| Numero di errori | < 3 | 3-10 | > 10 | |
| Azure Cosmos DB | Utilizzo DTU | < 70% | 70%-90% | > 90% |
| Insieme di credenziali chiave di Azure | Numero di errori | < 3 | 3-10 | > 10 |
| Hub eventi di Azure | Elaborazione della lunghezza del backlog (messaggi in uscita/in ingresso) | < 3 | 3-20 | > 20 |
| Archiviazione BLOB di Azure | Latenza media (ms) | < 100 | 100-200 | > 200 |
In questo esempio la tolleranza di errore per l'applicazione Web front-end e l'API catalogo è diversa. Questa differenza si riferisce alla comprensione tecnica dell'applicazione. Tutti gli errori del front-end dovrebbero essere gestiti dal lato client, in modo da avere una soglia pari a zero. Tuttavia, nel livello API sono consentite 10 eccezioni per tenere conto degli errori causati dall'utente. Ad esempio, gli errori come 404 - Non trovato non indicano necessariamente un problema di integrità.