Modellazione dell'integrità per carichi di lavoro cruciali

Il monitoraggio delle applicazioni e dell'infrastruttura è una parte importante di qualsiasi distribuzione dell'infrastruttura. Per un carico di lavoro cruciale, il monitoraggio è una parte fondamentale della distribuzione. Il monitoraggio dell'integrità delle applicazioni e delle metriche chiave delle risorse di Azure consente di comprendere se l'ambiente funziona come previsto.

Per comprendere appieno queste metriche e valutare l'integrità complessiva di un carico di lavoro, è necessaria una comprensione olistica di tutti i dati monitorati. Un modello di integrità può essere utile per valutare lo stato di integrità complessivo visualizzando un'indicazione chiara dell'integrità del carico di lavoro anziché delle metriche non elaborate. Lo stato viene spesso presentato come indicatori di "semaforo", ad esempio rosso, verde o giallo. La rappresentazione di un modello di integrità con indicatori chiari rende intuitivo per un operatore comprendere l'integrità complessiva del carico di lavoro e rispondere rapidamente ai problemi che si verificano.

La modellazione dell'integrità può essere espansa nelle attività operative seguenti per la distribuzione mission-critical:

• Application Servizio integrità: componente dell'applicazione nel cluster di calcolo che fornisce un'API per determinare l'integrità di un timbro.

• Monitoraggio : raccolta di contatori delle prestazioni e delle applicazioni che valutano l'integrità e le prestazioni dell'applicazione e dell'infrastruttura.

• Avvisi: avvisi interattivi di problemi o interruzioni nell'infrastruttura e nell'applicazione.

• Analisi degli errori: scomposizione e analisi di eventuali errori, inclusa la documentazione della causa radice.

Queste attività costituiscono un modello di integrità completo per l'infrastruttura mission-critical. Lo sviluppo di un modello di integrità può e deve essere parte integrante di qualsiasi distribuzione mission-critical.

Per altre informazioni, vedere Modellazione dell'integrità e osservabilità dei carichi di lavoro cruciali in Azure.

Servizio integrità dell'applicazione

L'applicazione Servizio integrità (HealthService) è un componente dell'applicazione che risiede con il servizio catalogo (CatalogService) e il processore in background (BackgroundProcessor) all'interno del cluster di calcolo. HealthService fornisce un'API REST per Frontdoor di Azure da chiamare per determinare l'integrità di un timbro. HealthService è un componente complesso che riflette lo stato delle dipendenze, oltre al proprio.

Quando il cluster di calcolo è inattivo, il servizio integrità non risponderà. Quando i servizi sono operativi, esegue controlli periodici sui componenti seguenti nell'infrastruttura:

• Tenta di eseguire una query su Azure Cosmos DB.

• Tenta di inviare un messaggio a Hub eventi. Il messaggio viene filtrato in base al ruolo di lavoro in background.

• Cerca un file di stato nell'account di archiviazione. Questo file può essere usato per disattivare un'area, anche se gli altri controlli funzionano correttamente. Questo file può essere usato per comunicare con altri processi. Ad esempio, se il timbro deve essere liberato a scopo di manutenzione, il file potrebbe essere eliminato per forzare uno stato non integro e reindirizzare il traffico.

• Esegue una query sul modello di integrità per determinare se tutte le metriche operative sono entro le soglie predeterminate. Quando il modello di integrità indica che lo stamp non è integro, il traffico non deve essere instradato al timbro anche se gli altri test eseguiti da HealthService restituiscono correttamente. Il modello di integrità prende in considerazione una visualizzazione più completa dello stato di integrità.

Tutti i risultati del controllo integrità vengono memorizzati nella cache per un numero configurabile di secondi, per impostazione predefinita 10. Questa operazione aggiunge potenzialmente una latenza ridotta nel rilevamento delle interruzioni, ma garantisce che non tutte le query di HealthService richiedano chiamate back-end, riducendo così il carico sul cluster e sui servizi downstream.

Questo modello di memorizzazione nella cache è importante perché il numero di query HealthService cresce in modo significativo quando si usa un router globale come Frontdoor di Azure: ogni nodo perimetrale in ogni data center di Azure che gestisce le richieste chiamerà il Servizio integrità per determinare se ha una connessione back-end funzionale. La memorizzazione nella cache dei risultati riduce il carico aggiuntivo del cluster generato dai controlli di integrità.

Impostazione

HealthService e CatalogService hanno impostazioni di configurazione comuni tra i componenti, ad eccezione delle impostazioni seguenti usate esclusivamente da HealthService:

Implementazione

Tutti i controlli vengono eseguiti in modo asincrono e in parallelo. Se uno di essi ha esito negativo, l'intero timbro verrà considerato non disponibile.

I risultati del controllo vengono memorizzati nella cache in memoria, usando lo standard ASP.NET Core MemoryCache. La scadenza della cache è controllata da SysConfig.HealthServiceCacheDurationSeconds ed è impostata su 10 secondi per impostazione predefinita.

Nella tabella seguente vengono descritti in dettaglio i controlli di integrità per i componenti nell'infrastruttura:

Query di Azure Cosmos DB

Per la query di sola lettura, viene usata la query seguente, che non recupera dati e non ha un effetto elevato sul carico complessivo:

SELECT GetCurrentDateTime ()

La query di scrittura crea un fittizio ItemRating con contenuto minimo:

var testRating = new ItemRating()
{
    Id = Guid.NewGuid(),
    CatalogItemId = Guid.NewGuid(), // Create some random (=non-existing) item id
    CreationDate = DateTime.UtcNow,
    Rating = 1,
    TimeToLive = 10 // will be auto-deleted after 10sec
};

await AddNewRatingAsync(testRating);

Monitoraggio

Azure Log Analytics viene usato come archivio centrale per log e metriche per tutti i componenti dell'applicazione e dell'infrastruttura. app Azure lication Insights viene usato per tutti i dati di monitoraggio delle applicazioni. Ogni stamp nell'infrastruttura ha un'area di lavoro Log Analytics dedicata e un'istanza di Application Insights. Un'area di lavoro Log Analytics separata viene usata per le risorse condivise a livello globale, ad esempio Frontdoor e Azure Cosmos DB.

Tutti i francobolli sono di breve durata e continuamente sostituiti con ogni nuova versione. Le aree di lavoro Log Analytics per stamp vengono distribuite come risorsa globale in un gruppo di risorse di monitoraggio separato come risorse di Log Analytics. Queste risorse non condividono il ciclo di vita di un timbro.

Per altre informazioni, vedere Sink di dati unificato per l'analisi correlata.

Monitoraggio: origini dati

• Impostazioni di diagnostica: tutti i servizi di Azure usati per Azure Mission-Critical sono configurati per inviare tutti i dati di diagnostica, inclusi i log e le metriche all'area di lavoro Log Analytics specifica (globale o stamp). Questo processo viene eseguito automaticamente come parte della distribuzione di Terraform. Le nuove opzioni verranno identificate automaticamente e aggiunte come parte di terraform apply.

• Monitoraggio di Kubernetes: le impostazioni di diagnostica vengono usate per inviare log e metriche di servizio Azure Kubernetes (servizio Azure Kubernetes) a Log Analytics. Il servizio Azure Kubernetes è configurato per l'uso di Informazioni dettagliate sui contenitori. Container Insights distribuisce OMSAgentForLinus tramite un DaemonSet kubernetes in ogni nodo nei cluster del servizio Azure Kubernetes. OMSAgentForLinux è in grado di raccogliere log e metriche aggiuntivi dall'interno del cluster Kubernetes e di inviarli all'area di lavoro Log Analytics corrispondente. Questi log e metriche aggiuntivi contengono dati più granulari su pod, distribuzioni, servizi e integrità complessiva del cluster. Per ottenere altre informazioni dettagliate dai vari componenti, ad esempio in ingresso-nginx, cert-manager e altri componenti distribuiti in Kubernetes accanto al carico di lavoro mission-critical, è possibile usare lo scraping prometheus. Prometheus scraping configura OMSAgentForLinux per raschiare le metriche di Prometheus da vari endpoint all'interno del cluster.

• Telemetria di Application Insights: Application Insights viene usato per raccogliere dati di telemetria dall'applicazione. Il codice è stato instrumentato per raccogliere dati sulle prestazioni dell'applicazione con Application Insights SDK. Vengono raccolte informazioni critiche, ad esempio il codice di stato risultante e la durata delle chiamate e dei contatori delle dipendenze per le eccezioni non gestite. Queste informazioni vengono usate nel modello di integrità ed è disponibile per avvisi e risoluzione dei problemi.

Monitoraggio: test di disponibilità di Application Insights

Per monitorare la disponibilità dei singoli timbri e la soluzione complessiva da un punto di vista esterno, i test di disponibilità di Application Insights vengono configurati in due posizioni:

• Test di disponibilità a livello di area: questi test vengono configurati nelle istanze di Application Insights a livello di area e vengono usati per monitorare la disponibilità dei francobolli. Questi test sono destinati direttamente ai cluster e agli account di archiviazione statici dei francobolli. Per chiamare direttamente i punti di ingresso dei cluster, le richieste devono portare l'intestazione dell'ID frontdoor corretta, altrimenti vengono rifiutati dal controller di ingresso.

• Test di disponibilità globale: questi test vengono configurati nell'istanza globale di Application Insights e vengono usati per monitorare la disponibilità della soluzione complessiva eseguendo il ping di Frontdoor. Vengono usati due test: uno per testare una chiamata API a CatalogService e una per testare la home page del sito Web.

Monitoraggio: query

Azure Mission-Critical usa query di Linguaggio di query Kusto (KQL) diverse per implementare query personalizzate come funzioni per recuperare i dati da Log Analytics. Queste query vengono archiviate come singoli file nel repository di codice, separate per le distribuzioni globali e stamp. Vengono importati e applicati automaticamente tramite Terraform come parte di ogni esecuzione della pipeline dell'infrastruttura.

Questo approccio separa la logica di query dal livello di visualizzazione. Le query di Log Analytics vengono chiamate direttamente dal codice, ad esempio dall'API HealthService. Un altro esempio è quello di uno strumento di visualizzazione, ad esempio Dashboard di Azure, Monitoraggio cartelle di lavoro o Grafana.

Monitoraggio: visualizzazione

Per visualizzare i risultati delle query sull'integrità di Log Analytics, è stato usato Grafana nell'implementazione di riferimento. Grafana viene usato per visualizzare i risultati delle query di Log Analytics e non contiene alcuna logica stessa. Lo stack Grafana non fa parte del ciclo di vita della distribuzione della soluzione, ma rilasciato separatamente.

Per altre informazioni, vedere Visualizzazione.

Creazione di avvisi

Gli avvisi sono una parte importante della strategia operativa complessiva. È consigliabile usare il monitoraggio proattivo, ad esempio l'uso dei dashboard, con avvisi che generano un'attenzione immediata ai problemi.

Questi avvisi costituiscono un'estensione del modello di integrità, avvisando l'operatore a una modifica dello stato di integrità, allo stato danneggiato/giallo o allo stato non integro/rosso. Impostando l'avviso sul nodo radice del modello di integrità, l'operatore è immediatamente a conoscenza di qualsiasi livello aziendale che influisce sullo stato della soluzione: dopo tutto, questo nodo radice diventa giallo o rosso se uno dei flussi utente o delle risorse sottostanti segnala le metriche gialle o rosse. L'operatore può indirizzare l'attenzione alla visualizzazione modello di integrità per la risoluzione dei problemi.

Per altre informazioni, vedere Risposta automatica agli eventi imprevisti.

Analisi degli errori

La composizione dell'analisi degli errori è principalmente un esercizio teorico di pianificazione. Questo esercizio teorico deve essere usato come input per gli inserimenti automatici di errori che fanno parte del processo di convalida continua. Simulando le modalità di errore definite qui, è possibile convalidare la resilienza della soluzione rispetto a questi errori per assicurarsi che non provocheranno interruzioni.

La tabella seguente elenca i casi di errore di esempio dei vari componenti dell'implementazione di riferimento Mission-Critical di Azure.

Passaggi successivi

Distribuire l'implementazione di riferimento per ottenere una conoscenza completa delle risorse e della relativa configurazione usata in questa architettura.