Esercizio - Creare un modello di integrità dell'applicazione
Contoso Shoes sta cercando un modo per rilevare, diagnosticare e prevedere i problemi di questa architettura. La finalità dell’utente è quella di creare un modello di integrità quantificabile tramite uno stato di integrità applicato ai flussi utente e di sistema. L'obiettivo è identificare i potenziali punti di errore prima che possano causare un'interruzione.
Stato corrente e problema
Finora è stata aggiunta un'API di controllo integrità e sono state compilate funzionalità multiregione nell'architettura. Tuttavia, non esiste un metodo per ottenere informazioni dettagliate riguardo la complessa topologia che coinvolge i flussi di utenti e sistemi. Questa lacuna deve essere colmata in modo che il team SRE possa identificare e risolvere rapidamente i problemi.
In un recente incidente, il team non ha potuto osservare l'effetto a catena di un problema derivante da un componente dell'API, che influenzava le dipendenze della piattaforma. La risoluzione dei problemi ha comportato un notevole dispendio di tempo perché non è stato possibile individuare immediatamente il componente non integro. In definitiva, questa inefficienza ha portato a tempi di inattività più lunghi, causando perdite finanziarie all'azienda.
Specifica
Progettare un modello di integrità che mostra le relazioni tra tutti i componenti dell'architettura, includendo sia i componenti dell'applicazione che le dipendenze della piattaforma. Prendere in considerazione gli elementi che esistono all'interno del flusso di richieste, tra cui il gateway, l'elaborazione, i database, l'archiviazione, le cache e così via. Inoltre, includere i componenti che in genere esistono al di fuori del flusso di richieste. Ad esempio, artefatti OCI (Open Container Initiative), archivi segreti, servizi di configurazione e altro. Tutti i servizi di Azure devono essere configurati per l'invio di dati di diagnostica.
Aggiungere un sink di dati unificato nell'architettura per raccogliere informazioni provenienti da diverse origini.
Definire uno stato di integrità complessivo basato su log cronologici aggregati e metriche. Rappresenta lo stato in uno dei tre stati di integrità: non integro, danneggiato e integro.
Visualizzare lo stato di integrità di tutti i componenti di una gerarchia che rappresenta tutti i flussi.
Approccio consigliato
Per iniziare a progettare, è consigliabile seguire questa procedura:
Importante
La modellazione dell'integrità è un'attività che richiede un'analisi approfondita. L'approccio in questa sezione è destinato a facilitare l'avvio. È importante applicare il modello a tutti i flussi funzionali e non funzionali nella progettazione mission-critical per ottenere una visione olistica del sistema.
1 - Avviare la modellazione dell'integrità
Questo esercizio è teorico. La modellazione dell'integrità è un'attività di progettazione dall'alto verso il basso che richiede un elenco completo dei componenti usati nell'architettura. Questo elenco deve includere tutti i componenti dell'applicazione e i servizi di Azure.
Inserire questi componenti in un grafico dipendenze che mostri una visione gerarchica della soluzione. Il livello superiore include i flussi utente che tengono traccia della richiesta dall'utente finale al sito Web e i flussi a livello di API dell'applicazione. Il livello inferiore contiene i flussi di sistema dai servizi di Azure. Eseguire anche il mapping delle dipendenze tra le risorse di Azure.
Il grafo dovrebbe essere simile al seguente:
Verificare i progressi: Integrità dell'applicazione a livelli
2 - Definire i punteggi di integrità
Per ogni componente, è necessario rilevare le metriche e definire le loro soglie e quindi decidere il valore che determina se il componente è integro, danneggiato e non integro. Tale decisione deve essere influenzata dai requisiti aziendali previsti e non funzionali. Classificare le metriche come segue:
Metriche dell'applicazione: punti dati dal codice dell'applicazione, ad esempio il conteggio delle eccezioni.
Metriche del servizio: punti dati dei servizi di Azure, ad esempio unità di transazione di database (DTU) in uso.
Metriche della soluzione: punti dati a livello di soluzione, ad esempio il tempo di elaborazione end-to-end di una richiesta.
Ecco un esempio per app Azure Services:
| Servizi app | Health status |
|---|---|
| Tempo di risposta < 200ms Errori del server HTTP < 2 |
 |
| Tempo di risposta < 500ms Errori del server HTTP < 2 |
 |
| Tempo di risposta > 500ms Errori del server HTTP > 2 |
 |
3 - Definire uno stato di integrità complessivo
Per ogni utente e flusso di sistema, definire uno stato complessivo. Sarà necessario aggregare lo stato di integrità dei singoli componenti che contribuiscono a tale flusso.
Supponiamo che un flusso di sistema sia costituito da un componente dell'applicazione, da un piano si Servizio app di Azure e da Servizi app.
| API | Piano di servizio app | Servizi app | Health status |
|---|---|---|---|
| Latenza massima < 30ms | % CPU < 70% Lunghezza coda HTTP < 5 |
Tempo di risposta < 200ms Errori del server HTTP < 2 |
|
| Latenza massima < 30ms | % CPU < 90% Lunghezza coda HTTP < 5 |
Tempo di risposta < 500ms Errori del server HTTP < 2 |
|
| Latenza massima > 30ms | CPU % > 90% lunghezza > coda HTTP 5 |
Tempi di > risposta 500ms Errori > del server HTTP 2 |
|
Il punteggio di integrità per un flusso utente deve essere rappresentato dal punteggio più basso in tutti i componenti mappati. Per i flussi di sistema, applicare pesi adeguati in base alla criticità aziendale. Tra i due flussi, devono avere la priorità i flussi di utenti significativi dal punto di vista finanziario o quelli rivolti al cliente.
Verificare i progressi: Esempio: integrità dell'applicazione a livelli
4 - Raccogliere dati di monitoraggio
È necessario un sink di dati unificato in ogni area che raccoglie log e metriche per tutti i servizi di applicazione e piattaforma distribuiti come parte del timbro a livello di area. È necessario un altro sink per archiviare le metriche generate dalle risorse globali, ad esempio Frontdoor di Azure e Cosmos DB.
Scelte di tecnologia
- app Azure lication Insights: usato per raccogliere tutti i dati di telemetria dell'applicazione.
- Log di Monitoraggio di Azure: raccoglie i dati inviati da Application Insights e metriche della piattaforma per i servizi di Azure.
- Azure Log Analitica: usato come strumento centrale per l'analisi dei log e delle metriche da tutti i componenti dell'applicazione e dell'infrastruttura.
Verificare i progressi: Data sink unificato per l'analisi correlata
5 - Configurare le query per il monitoraggio dei dati
Linguaggio di query Kusto (KQL) è ben integrato con Log Analytics. Implementare query KQL personalizzate come funzioni per recuperare i dati da Monitoraggio di Azure.
Archiviare query personalizzate nel repository di codice in modo che vengano importate e applicate automaticamente come parte delle pipeline di integrazione continua/recapito continuo (CI/CD).
6 - Visualizzare lo stato di integrità
È possibile visualizzare il grafico delle dipendenze con i punteggi di integrità con una rappresentazione della luce del traffico. Usare strumenti come la dashboard di Azure, le cartelle di lavoro di Monitoraggio o Grafana. Ecco un esempio:
Verificare i progressi: Visualizzazione
7 - Configurare avvisi sulle modifiche dello stato
È consigliabile usare i dashboard con avvisi per alzare immediatamente l'attenzione per i problemi.
Se lo stato di integrità di un componente viene modificato in Degradato o Non integro, l'operatore ricevere immediatamente una notifica. Impostare avvisi nel nodo radice, perché qualsiasi modifica apportata a questo nodo indica lo stato non integro nei flussi utente o nelle risorse sottostanti.
Verificare i progressi: Avvisi
Controlla il tuo lavoro
Guardare questa demo sul monitoraggio e sulla modellazione dell'integrità. Sono stati coperti tutti gli aspetti nel progetto?
- È disponibile un sink di dati unificato per l'analisi correlata?
- Sono stati inclusi i log delle applicazioni, le metriche della piattaforma e i punti dati della soluzione?
- Sono state configurate le dashboard per visualizzare lo stato di integrità di tutti i componenti?
- Sono stati presi in considerazione i punti critici di ogni servizio (o parte del servizio) che potrebbero causare un'interruzione o ostacolare il ridimensionamento, la distribuzione e il monitoraggio?
- Sono stati presi in considerazione i pacchetti di query per acquisire le query chiave che consentono di risolvere i problemi più velocemente?
- L'API per il controllo dello stato di integrità è stata utile per questo modello? È stato necessario modificare l'API per adattarla al modello di integrità?