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 per il controllo dell’integrità e sono state create funzionalità in più aree 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 conclusione, questa inefficienza ha portato a tempi di inattività più lunghi, generando perdite economiche per l'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 ha lo scopo di aiutare l'utente a cominciare. L'applicazione del modello a tutti i flussi funzionali e non funzionali di un progetto di importanza cruciale fornisce un quadro completo 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. Questa decisione deve essere influenzata dalle prestazioni previste e dai requisiti aziendali non funzionali. Classificare le metriche come segue:
Metriche dell'applicazione: Punti dati dal codice dell'applicazione, ad esempio il conteggio delle eccezioni.
Metrica servizio: Punti dati dai servizi di Azure, ad esempio le unità di transazione del database (DTU) in uso.
Metriche della soluzione: Punti dati a livello di soluzione, ad esempio il tempo di elaborazione complessivo di una richiesta.
Di seguito è riportato un esempio per Servizio app di Azure:
| 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% durata coda HTTP > 5 |
Tempo 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 dell'applicazione e della piattaforma distribuiti come parte dello stamp 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
- Azure Application Insights: Usato per raccogliere tutti i dati di telemetria dell'applicazione.
- Log di Monitoraggio di Azure: Raccoglie i dati inviati da Application Insights e dalle metriche della piattaforma per i servizi di Azure.
- Azure Log Analytics: Usato come strumento centrale per l'analisi di log e 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 relativi punteggi di integrità con una rappresentazione a semaforo. 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
Le dashboard devono essere integrate con avvisi per segnalare immediatamente eventuali problemi.
Se lo stato di integrità di un componente viene modificato in Degradato o Non integro, l'operatore ricevere immediatamente una notifica. Impostare gli avvisi nel nodo radice, poiché ogni variazione in questo nodo suggerisce un'anomalia nello stato di integrità dei flussi utente o delle 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à?