Procedure consigliate per il monitoraggio e la diagnostica

Le applicazioni distribuite e i servizi eseguiti nel cloud sono componenti software complessi che comprendono molte parti in movimento. In un ambiente di produzione è importante tenere traccia del modo in cui i clienti usano il sistema, tracciano l'utilizzo delle risorse e monitorano l'integrità e le prestazioni del sistema. È possibile usare queste informazioni per rilevare e correggere i problemi e rilevare potenziali problemi prima che si verifichino.

Scenari di monitoraggio e diagnostica

È possibile usare il monitoraggio per ottenere informazioni dettagliate su come funziona un sistema. Il monitoraggio è una parte fondamentale della gestione della qualità dei servizi (QoS). Raccogliere dati di monitoraggio per gli scenari comuni seguenti:

• Assicurarsi che il sistema rimanga integro.

• Tenere traccia della disponibilità del sistema e dei relativi componenti.

• Mantenere le prestazioni per garantire che la velocità effettiva del sistema non si degradi in modo imprevisto man mano che aumenta il volume di lavoro.

• Garantire che il sistema soddisfi gli accordi sul livello di servizio (SLA).

• Proteggere la privacy e la sicurezza del sistema, degli utenti e dei relativi dati.

• Tenere traccia delle operazioni di controllo o normative.

• Monitorare l'utilizzo quotidiano del sistema e risolvere le tendenze che potrebbero causare problemi.

• Tenere traccia dei problemi che si verificano, dal report iniziale all'analisi di possibili cause, rettifica, aggiornamenti software e distribuzione.

• Traccia le operazioni ed esegui il debug dei rilasci software.

Le sezioni seguenti descrivono questi scenari in modo più dettagliato.

Monitoraggio della salute

Un sistema funzionante è in esecuzione e può elaborare le richieste. Usare il monitoraggio dell'integrità per generare uno snapshot dell'integrità corrente del sistema in modo da poter verificare che tutti i componenti funzionino come previsto.

Configurare gli avvisi

Il sistema dovrebbe generare un avviso entro pochi secondi se qualsiasi componente non funziona correttamente. Gli avvisi possono evidenziare l'integrità del sistema tramite segnali di luce del traffico:

• Rosso per stato non integro (il sistema si è arrestato)
• Giallo per parzialmente funzionante (il sistema funziona con funzionalità ridotte)
• Verde per la salute

Un sistema di monitoraggio dell'integrità completo mostra lo stato di integrità di ogni sottosistema e componente, in modo da poter determinare quali parti funzionano normalmente e quali parti riscontrano problemi.

Raccogliere dati sanitari

Le seguenti fonti possono generare i dati non elaborati necessari per il monitoraggio dello stato:

• Tracciare l'esecuzione delle richieste utente. È possibile usare queste informazioni per determinare quali richieste hanno esito positivo o negativo e per misurare il tempo necessario per ogni richiesta.

• Monitorare gli utenti sintetici. Questo processo simula le azioni eseguite da un utente e segue una serie predefinita di passaggi. Acquisire i risultati di ogni passaggio.

• Registrare eccezioni, errori e avvisi. È possibile acquisire queste informazioni dalle istruzioni di traccia incorporate nel codice dell'applicazione e dai registri eventi dei servizi a cui fa riferimento il sistema.

• Monitorare lo stato dei servizi non Microsoft utilizzati dal sistema. Potrebbe essere necessario recuperare e interpretare i dati sullo stato di integrità forniti da questi servizi.

• Monitorare gli endpoint.

• Raccogliere informazioni sulle prestazioni di ambiente, ad esempio l'utilizzo della CPU in background o le operazioni di input/output (I/O), inclusa l'attività di rete.

Analizzare i dati sanitari

L'obiettivo principale del monitoraggio dello stato di salute è indicare rapidamente se il sistema è in esecuzione. L'analisi in tempo reale dei dati può attivare un avviso se un componente critico non funziona correttamente.

Un sistema più avanzato può includere un elemento predittivo che esegue un'analisi a freddo sui carichi di lavoro recenti e correnti. Un'analisi a freddo può identificare le tendenze e determinare se è probabile che il sistema rimanga integro o richieda più risorse. Basare questo elemento predittivo sulle metriche di prestazioni critiche seguenti:

• Frequenza delle richieste indirizzate a ogni servizio o sottosistema
• Tempi di risposta di queste richieste
• Volume di dati che passano da e in uscita da ogni servizio

Se il valore di una metrica supera una soglia definita, il sistema può generare un avviso per aumentare le prestazioni. È anche possibile aggiungere risorse, riavviare i servizi con errori o limitare le richieste con priorità inferiore per mantenere l'integrità del sistema.

Monitoraggio della disponibilità

In un sistema integro sono disponibili tutti i componenti e i sottosistemi. Il monitoraggio della disponibilità è strettamente correlato al monitoraggio della salute. Il monitoraggio dello stato offre una vista immediata dello stato attuale del sistema. Il monitoraggio della disponibilità tiene traccia della disponibilità del sistema e dei relativi componenti per generare statistiche sul tempo di attività.

In molti sistemi, alcuni componenti, ad esempio i database, sono configurati con ridondanza predefinita per consentire un failover rapido in caso di grave errore o perdita di connettività. Raccogliere il maggior numero possibile di informazioni su questi errori per determinare la causa e intraprendere azioni correttive per evitare la ricorrenza.

I dati necessari per tenere traccia della disponibilità possono dipendere da più fattori di livello inferiore che potrebbero essere specifici per l'applicazione, il sistema e l'ambiente. Un sistema di monitoraggio efficace acquisisce i dati di disponibilità che corrispondono a questi fattori di basso livello e li aggrega per fornire un quadro generale del sistema. Ad esempio, in un sistema di e-commerce, la funzionalità aziendale che consente a un cliente di effettuare ordini può dipendere dal repository in cui sono archiviati i dettagli dell'ordine e dal sistema di pagamento che gestisce le transazioni monetarie. La disponibilità della funzionalità di posizionamento degli ordini dipende dalla disponibilità del repository e dal sottosistema di pagamento.

La soluzione di monitoraggio della disponibilità offre visualizzazioni correnti e cronologiche dello stato di disponibilità di ogni sottosistema. Avvisa rapidamente l'utente quando uno o più servizi hanno esito negativo o quando gli utenti non possono connettersi ai servizi. Usare queste informazioni per identificare le tendenze che potrebbero causare errori nei sottosistemi. Ad esempio, è possibile usare i dati di disponibilità per rilevare quali servizi hanno esito negativo durante le ore di elaborazione di picco.

Raccogliere i dati di disponibilità

Monitorare gli utenti sintetici, registrare eccezioni, errori e avvisi e monitorare gli endpoint per generare i dati non elaborati necessari per supportare il monitoraggio della disponibilità. L'applicazione può esporre uno o più endpoint di monitoraggio dello stato, ciascuno dei quali verifica l'accesso a un'area funzionale all'interno del sistema. Il sistema di monitoraggio segue una pianificazione definita per eseguire il ping di ogni endpoint e raccogliere i risultati, ad esempio esito positivo o negativo.

Registrare tutti i timeout, i guasti della connettività di rete e i tentativi di riconnessione, e apporre un riferimento temporale a tutti i dati.

Analizzare i dati di disponibilità

Aggregare e correlare i dati per supportare i tipi di analisi seguenti:

• Disponibilità immediata del sistema e dei sottosistemi.

• Frequenza degli errori di disponibilità del sistema e dei sottosistemi. Correlare gli errori con attività specifiche per comprendere le cause dell'errore di sistema.

• Visualizzazione cronologica delle percentuali di errore in un periodo specificato e del carico nel sistema, ad esempio il numero di richieste utente, quando si verifica un errore.

• Motivi di indisponibilità del sistema o dei sottosistemi. Questi motivi includono il servizio non in esecuzione, la connettività persa, i timeout o le risposte al codice di errore.

È possibile calcolare la disponibilità percentuale di un servizio in un periodo di tempo usando la formula seguente:

%Availability =  ((Total Time – Total Downtime) / Total Time ) * 100

Usare questa formula per il monitoraggio del contratto di servizio. La definizione del tempo di inattività dipende dal servizio. Ad esempio, il servizio di compilazione Azure DevOps definisce il tempo di inattività come periodo, in totale minuti accumulati, durante i quali il servizio di compilazione non è disponibile. Il servizio viene considerato non disponibile per un minuto se tutte le richieste HTTP continue durante tale minuto generano un codice di errore o non restituiscono una risposta.

Monitoraggio delle prestazioni

Man mano che aumenta il volume degli utenti, le dimensioni dei set di dati a cui gli utenti accedono aumentano e la possibilità di errori di uno o più componenti diventa più probabile. Spesso si verifica una riduzione delle prestazioni prima dell'errore del componente. Se è possibile rilevare una riduzione delle prestazioni, è possibile eseguire passaggi proattivi per evitare errori.

Le prestazioni del sistema dipendono da più fattori. In genere, ogni fattore viene misurato tramite indicatori di prestazioni chiave (KPI), ad esempio il numero di transazioni di database al secondo o il volume di richieste di rete gestite correttamente in un intervallo di tempo specificato. Alcuni di questi indicatori KPI potrebbero essere disponibili come misure di prestazioni specifiche, mentre altri indicatori KPI potrebbero essere derivati da una combinazione di metriche.

Requisiti per il monitoraggio delle prestazioni

Per valutare le prestazioni del sistema, sono in genere necessarie le informazioni seguenti:

• Velocità di risposta per le richieste degli utenti
• Numero di richieste utente simultanee
• Volume del traffico di rete
• Tariffe con cui il sistema completa le transazioni aziendali
• Tempo medio di elaborazione per le richieste

Usare gli strumenti che consentono di identificare le correlazioni seguenti:

• Il numero di utenti simultanei rispetto ai tempi di latenza delle richieste o il tempo necessario per avviare l'elaborazione di una richiesta dopo l'invio da parte dell'utente

• Il numero di utenti simultanei rispetto al tempo medio di risposta o il tempo necessario per completare una richiesta dopo l'avvio dell'elaborazione

• Volume di richieste rispetto al numero di errori di elaborazione

Oltre a queste informazioni funzionali di alto livello, ottenere una visualizzazione dettagliata delle prestazioni per ogni componente nel sistema. I contatori delle prestazioni di basso livello forniscono in genere questi dati. Tengono traccia delle informazioni seguenti:

• Utilizzo della memoria
• Numero di thread
• Tempo di elaborazione CPU
• Lunghezza coda richiesta
• Velocità e errori di I/O su disco o di rete
• Numero di byte scritti o letti
• Indicatori middleware, ad esempio la lunghezza della coda

Tutte le visualizzazioni devono consentire di specificare un periodo di tempo. I dati visualizzati potrebbero essere uno snapshot della situazione corrente o una visualizzazione cronologica delle prestazioni. Il sistema deve generare avvisi in base a qualsiasi misura delle prestazioni per qualsiasi valore specificato durante qualsiasi intervallo di tempo specificato.

Raccogliere dati sulle prestazioni

Raccogliere dati sulle prestazioni di alto livello, ad esempio velocità effettiva, numero di utenti simultanei, numero di transazioni aziendali e tassi di errore, monitorando lo stato delle richieste degli utenti. Incorporare istruzioni di traccia e informazioni di intervallo nei punti chiave nel codice dell'applicazione. Acquisire tutti gli errori, le eccezioni e gli avvisi con dati sufficienti e correlarli con le richieste che li hanno generati.

Se possibile, acquisire i dati sulle prestazioni per tutti i sistemi esterni usati dall'applicazione. Questi sistemi esterni possono fornire contatori delle prestazioni personalizzati o altre funzionalità per richiedere dati sulle prestazioni. Se questo metodo non è possibile, registrare informazioni come l'ora di inizio e l'ora di fine di ogni richiesta a un sistema esterno e lo stato di esito positivo, negativo o di avviso dell'operazione.

I dati sulle prestazioni a basso livello dei singoli componenti di un sistema potrebbero essere disponibili tramite funzionalità e servizi, ad esempio i contatori delle prestazioni di Windows raccolti da Monitoraggio di Azure Agent.

Analizzare i dati sulle prestazioni

La maggior parte dell'analisi aggrega i dati sulle prestazioni in base al tipo di richiesta utente o al sottosistema o al servizio a cui viene inviata ogni richiesta. Un esempio di richiesta utente consiste nell'aggiungere un articolo a un carrello acquisti o al processo di checkout in un sistema di e-commerce.

Un altro requisito comune consiste nel riepilogare i dati sulle prestazioni nei percentili. Ad esempio, è possibile determinare i tempi di risposta per 99% di richieste, 95% di richieste e 70% di richieste. È possibile impostare obiettivi di contratto di servizio o altri obiettivi per ogni percentile. Segnalare i risultati in corso quasi in tempo reale per consentire di rilevare immediatamente i problemi. Aggregare i risultati nel tempo per scopi statistici.

I problemi di latenza possono influire anche sulle prestazioni. Per identificare rapidamente la causa dei colli di bottiglia, valuta la latenza di ogni fase eseguita da ciascuna richiesta. I dati sulle prestazioni devono fornire un modo per correlare le metriche delle prestazioni per ogni passaggio per associarle a una richiesta specifica.

A seconda dei requisiti di visualizzazione, potrebbe essere utile generare e archiviare un cubo di dati contenente visualizzazioni dei dati non elaborati. Questo cubo di dati può consentire query complesse, non pianificate e analisi delle informazioni sulle prestazioni.

Monitoraggio della sicurezza

Tutti i sistemi commerciali che includono dati sensibili devono implementare una struttura di sicurezza. La riservatezza dei dati determina in genere la complessità del meccanismo di sicurezza. In un sistema che richiede l'autenticazione degli utenti, registrare le informazioni seguenti:

• Tutti i tentativi di accesso e se hanno esito negativo o esito positivo

• Tutte le operazioni eseguite da un utente autenticato e i dettagli di tutte le risorse a cui accedono

• Quando un utente termina una sessione e si disconnette

Il monitoraggio potrebbe aiutare a rilevare gli attacchi nel sistema. Ad esempio, diversi tentativi di accesso non riusciti potrebbero indicare un attacco di forza bruta. Un aumento imprevisto delle richieste potrebbe essere il risultato di un attacco DDoS. Prepararsi a monitorare tutte le richieste a tutte le risorse indipendentemente dall'origine. Un sistema con una vulnerabilità di accesso potrebbe esporre accidentalmente risorse senza richiedere l'accesso di un utente.

Requisiti per il monitoraggio della sicurezza

I dati acquisiti dal monitoraggio della sicurezza consentono di:

• Rilevare le intrusioni tentate da un'entità non autenticata.

• Identificare i tentativi da parte delle entità di eseguire operazioni sui dati a cui non hanno accesso.

• Determinare se un utente non autenticato o un utente autenticato malintenzionato sta tentando di attaccare il sistema.

Per supportare queste attività, il sistema deve inviare avvisi se:

• Un account esegue tentativi di accesso ripetuti non riusciti entro un periodo specificato.

• Un account autenticato tenta ripetutamente di accedere a una risorsa non consentita durante un periodo specificato.

• Un numero elevato di richieste non autenticate o non autorizzate si verifica durante un periodo specificato.

Configurare gli avvisi per includere l'indirizzo host dell'origine per ogni richiesta. Se le violazioni di sicurezza si verificano regolarmente da un intervallo specifico di indirizzi, è possibile bloccare questi host.

Una parte fondamentale della gestione della sicurezza di un sistema è la possibilità di rilevare rapidamente le azioni che deviano dal modello consueto. È possibile visualizzare informazioni come il numero di richieste di accesso non riuscite o riuscite visivamente per rilevare i picchi di attività in momenti insoliti. È anche possibile usare queste informazioni per configurare la scalabilità automatica basata sul tempo. Ad esempio, se si nota che molti utenti accedono regolarmente in un momento specifico, è possibile avviare servizi di autenticazione aggiuntivi per gestire il volume di lavoro. Arrestate questi servizi una volta superato il picco.

Raccogliere dati di sicurezza

La sicurezza è un aspetto onnicomprensivo della maggior parte dei sistemi distribuiti e il monitoraggio genera dati pertinenti in diversi punti del sistema. Adottare un approccio SIEM (Security Information and Event Management) per raccogliere informazioni risultanti da eventi generati dall'applicazione, apparecchiature di rete, server, firewall, software antivirus e altri elementi di prevenzione delle intrusioni.

Il monitoraggio della sicurezza può incorporare i dati dagli strumenti all'esterno dell'applicazione. Questi strumenti includono utilità che identificano le attività di analisi delle porte da parte di agenzie esterne e filtri di rete che rilevano i tentativi di ottenere l'accesso non autenticato all'applicazione e ai dati. In alcuni casi, l'integrazione continua e gli strumenti di distribuzione continua (CI/CD) costituiscono una parte importante del ciclo di vita dell'applicazione. Questi strumenti devono anche contrassegnarne il comportamento anomalo.

Analizzare i dati di sicurezza

Una funzionalità chiave del monitoraggio della sicurezza è che raccoglie i dati da molte origini. I diversi formati e livelli di dettaglio spesso richiedono un'analisi complessa per compilare i dati in un thread coerente di informazioni. È possibile rilevare accessi non riusciti o tentativi ripetuti di ottenere l'accesso non autorizzato alle risorse, ma un'elaborazione automatizzata complessa dei dati di sicurezza potrebbe non essere fattibile. In questo scenario, è necessario apporre un timestamp ai dati e memorizzarli in un repository sicuro nella loro forma originale per un'analisi manuale da parte di esperti.

Monitoraggio SLA

I sistemi commerciali che supportano clienti paganti assumono impegni riguardo alle prestazioni del sistema sotto forma di accordi sul livello di servizio. I contratti di servizio dichiarano che il sistema può gestire un volume definito di lavoro entro un intervallo di tempo concordato e senza perdere informazioni critiche. Il monitoraggio del contratto di servizio garantisce che il sistema soddisfi contratti di servizio misurabili.

Le metriche seguenti definiscono i contratti di servizio:

• Disponibilità complessiva del sistema. Per esempio, un'organizzazione potrebbe impegnarsi affinché il sistema sia disponibile il 99,9% del tempo. Questa percentuale equivale a non più di nove ore di inattività all'anno o a circa 10 minuti alla settimana.

• Velocità effettiva operativa. Questo aspetto viene spesso espresso mediante uno o più valori di picco, ad esempio un impegno secondo cui il sistema è in grado di supportare fino a 100.000 richieste simultanee degli utenti o di gestire 10.000 transazioni aziendali simultanee.

• Tempo di risposta operativo. Il sistema potrebbe anche dover elaborare le richieste a una velocità definita. Ad esempio, 99% di tutte le transazioni aziendali devono terminare entro 2 secondi e nessuna singola transazione richiede più di 10 secondi.

Requisiti per il monitoraggio del contratto di servizio

È necessario essere in grado di determinare rapidamente se il sistema soddisfa un contratto di servizio. Se non soddisfa lo SLA, è necessario valutare i fattori alla base per individuare la causa delle prestazioni inferiori agli standard.

È possibile rappresentare visivamente gli indicatori generali seguenti:

• Percentuale di tempo di attività del servizio

• Velocità effettiva dell'applicazione, misurata in termini di transazioni o operazioni riuscite al secondo

• Numero di richieste dell'applicazione riuscite o non riuscite

• Numero di errori di applicazione e sistema, eccezioni e avvisi

Assicurarsi di poter filtrare tutti questi indicatori in base a un periodo di tempo specificato.

L'applicazione cloud comprende probabilmente più sottosistemi e componenti. Dovrebbe essere possibile selezionare un indicatore di alto livello, ad esempio il tempo di attività complessivo del sistema e determinare quali elementi sottostanti influiscono sullo stato di integrità.

Ai fini degli avvisi, il sistema deve generare un evento se uno degli indicatori di alto livello supera una soglia specificata. Rendere disponibili i dettagli di livello inferiore per il sistema di avvisi come dati contestuali.

Raccogliere i dati del contratto di servizio

Eseguire le azioni seguenti per acquisire i dati non elaborati necessari per il monitoraggio del contratto di servizio:

• Eseguire il monitoraggio degli endpoint.
• Registrare eccezioni, errori e avvisi.
• Tracciare l'esecuzione delle richieste utente.
• Monitorare la disponibilità di eventuali servizi non Microsoft utilizzati dal sistema.
• Usare metriche e contatori delle prestazioni.

Tutti i dati devono essere temporalizzati e marcati temporalmente.

Analizzare i dati del contratto di servizio

Aggregare i dati del contratto di servizio per generare un quadro delle prestazioni complessive del sistema. È anche possibile eseguire il drill-down dei dati aggregati per valutare i sottosistemi sottostanti. Ad esempio, dovrebbe essere possibile eseguire le attività seguenti:

• Calcolare il numero totale di richieste utente durante un periodo specificato e determinare il tasso di esito positivo e negativo di queste richieste.

• Combinare i tempi di risposta delle richieste degli utenti per generare una visualizzazione complessiva dei tempi di risposta del sistema.

• Analizzare lo stato di avanzamento delle richieste dell'utente per suddividere il tempo di risposta complessivo nei tempi di risposta dei singoli elementi di lavoro nella richiesta.

• Determinare la disponibilità complessiva del sistema come percentuale di tempo di attività per un periodo specifico.

• Analizzare la disponibilità percentuale del tempo dei singoli componenti e servizi nel sistema. Potrebbe essere necessario analizzare i log generati da non servizi Microsoft.

I sistemi commerciali devono segnalare dati reali sulle prestazioni rispetto ai contratti di servizio per un periodo specificato. È possibile utilizzare queste informazioni per calcolare crediti o altre forme di rimborsi per i clienti se non si soddisfano contratti di servizio durante tale periodo. È possibile calcolare la disponibilità per un servizio usando la tecnica descritta in Analizzare i dati di disponibilità.

Per scopi interni, un'organizzazione potrebbe anche tenere traccia del numero e della natura degli eventi imprevisti che causano un errore dei servizi. Informazioni su come risolvere questi problemi rapidamente o eliminarli in modo da ridurre i tempi di inattività e soddisfare i contratti di servizio.

Auditing

A seconda della natura dell'applicazione, le normative legali potrebbero specificare i requisiti per il controllo delle operazioni degli utenti e la registrazione di tutti gli accessi ai dati. Il controllo può fornire prove che consentono di collegare i clienti a richieste specifiche. Il non ripudio è un fattore importante nei sistemi di business elettronici per contribuire a mantenere la fiducia tra il cliente e l'organizzazione responsabile dell'applicazione o del servizio.

Requisiti per il controllo

È necessario essere in grado di tracciare la sequenza di operazioni aziendali eseguite dagli utenti in modo da poter ricostruire le azioni degli utenti. Questo record potrebbe essere necessario per scopi di documentazione o come parte di un'indagine forense.

Le informazioni di controllo sono estremamente sensibili. È probabile che includa i dati che identificano gli utenti di sistema e le attività che eseguono. Per questo motivo, le informazioni di controllo sono molto probabilmente disponibili solo per analisti attendibili, anziché come parte di un sistema interattivo. L'analista genera una serie di report come gli esempi seguenti:

• Report che elencano tutte le attività degli utenti durante un intervallo di tempo specificato

• Report che dettagliano la cronologia delle attività per un singolo utente

• Rapporti che elencano la sequenza di operazioni eseguite su una o più risorse

Raccogliere dati di controllo

Le fonti principali di informazioni per il controllo includono:

• Sistema di sicurezza che gestisce l'autenticazione utente.
• Log di traccia che registrano l'attività dell'utente.
• Log di sicurezza che tengono traccia di tutte le richieste di rete identificabili e non identificabili.

I requisiti normativi possono determinare il formato dei dati di controllo e la modalità di archiviazione. Se le normative richiedono di registrare i dati nel formato originale, potrebbe non essere possibile pulire i dati. Di conseguenza, l'accesso al repository in cui è archiviato deve essere strettamente protetto per evitare manomissioni.

Analizzare i dati di controllo

È necessario essere in grado di accedere ai dati non elaborati nella sua interezza e nel formato originale. A parte il requisito di generare report di controllo comuni, è probabile che gli strumenti per l'analisi di questi dati siano specializzati e mantenuti esterni al sistema.

Monitoraggio dell'utilizzo

Il monitoraggio dell'utilizzo tiene traccia del modo in cui i clienti usano le funzionalità e i componenti di un'applicazione. È possibile usare i dati per:

• Identificare le funzionalità più diffuse e i potenziali hotspot nel sistema. Gli elementi a traffico elevato possono trarre vantaggio dal partizionamento funzionale o dalla replica per distribuire il carico in modo più uniforme. È anche possibile utilizzare queste informazioni per determinare quali funzionalità vengono usate raramente e sono possibili candidati per il ritiro o la sostituzione in una versione futura del sistema.

• Ottenere informazioni sugli eventi operativi del sistema in uso normale. Ad esempio, in un sito di e-commerce è possibile registrare informazioni statistiche sul numero di transazioni e sul volume dei clienti responsabili. È possibile usare queste informazioni per la pianificazione della capacità man mano che aumenta il numero di clienti.

• Rilevare la soddisfazione dell'utente con le prestazioni e le funzionalità del sistema. Ad esempio, se molti clienti in un sistema di e-commerce abbandonano regolarmente i carrello acquisti, potrebbe verificarsi un problema con la funzionalità di checkout.

• Generare informazioni di fatturazione. Un'applicazione commerciale o un servizio multi-tenant potrebbe addebitare ai clienti le risorse usate.

• Applicare le quote. Se un utente in un sistema multi-tenant supera la quota a pagamento del tempo di elaborazione o dell'utilizzo delle risorse durante un periodo specificato, è possibile limitare l'accesso o limitare l'elaborazione.

• Rilevare i problemi del vicino rumoroso. Per facilitare le indagini sugli errori o le decisioni relative ai prodotti, determinare se il traffico viene distribuito in modo uniforme o se un piccolo set di utenti genera la maggior parte del traffico. Se un singolo utente genera traffico significativo, la funzionalità potrebbe richiedere l'ottimizzazione delle prestazioni. In alternativa, è possibile decidere di imporre quote aggiuntive per ridurre il traffico.

Requisiti per il monitoraggio dell'utilizzo

Per valutare l'utilizzo del sistema, sono in genere necessarie le informazioni seguenti:

• Numero di richieste che ogni sottosistema elabora e indirizza a ogni risorsa

• Il lavoro eseguito da ogni utente

• Volume di archiviazione dei dati occupato da ogni utente

• Risorse a cui ogni utente accede

Dovrebbe anche essere possibile generare grafici. Esempi comuni includono grafici degli utenti che utilizzano la maggior parte delle risorse e le risorse o le funzionalità di sistema a cui si accede più di frequente.

Raccolta dei dati sull'utilizzo

È possibile eseguire il rilevamento elevato dell'utilizzo notando l'ora di inizio e di fine di ogni richiesta e la natura di ogni richiesta, ad esempio lettura o scrittura. Per acquisire queste informazioni, eseguire le attività seguenti:

• Tracciare l'attività dell'utente.
• Acquisisci i contatori delle prestazioni che misurano l'utilizzo di ciascuna risorsa.
• Monitorare l'utilizzo delle risorse di ogni utente.

A scopo di misurazione, è anche necessario identificare gli utenti che eseguono le operazioni e le risorse usate da queste operazioni. Assicurarsi che le informazioni raccolte siano sufficientemente dettagliate per supportare la fatturazione accurata.

Tracciamento dei problemi

I clienti e altri utenti potrebbero segnalare problemi se si verificano eventi o comportamenti imprevisti nel sistema. Il rilevamento dei problemi gestisce questi problemi, associa i problemi agli sforzi per risolverli e informa i clienti delle risoluzioni.

Requisiti per il rilevamento dei problemi

Per tenere traccia dei problemi, usare un sistema separato che consente di registrare e segnalare i dettagli dei problemi che gli utenti segnalano. Questi dettagli includono le attività tentate, i sintomi del problema, la sequenza di eventi e i messaggi di errore o di avviso.

Raccogliere dati di rilevamento dei problemi

L'origine dati iniziale per i dati di rilevamento dei problemi è l'utente che segnala il problema. Questo utente potrebbe essere in grado di fornire i dettagli seguenti:

• Un dump di arresto anomalo del sistema, se l'applicazione include un componente eseguito sul desktop dell'utente

• Uno snapshot dello schermo

• Data e ora in cui si è verificato l'errore e altre informazioni ambientali, ad esempio la posizione dell'utente

Usare queste informazioni per eseguire il debug del sistema e costruire un backlog per le versioni software future.

Analizzare i dati di rilevamento dei problemi

Diversi utenti potrebbero segnalare lo stesso problema e il sistema di rilevamento dei problemi deve associare report comuni.

Registrare lo stato di avanzamento del debug su ogni report. Quando si risolve il problema, informare il cliente della soluzione.

Se un utente segnala un problema con una soluzione nota nel sistema di rilevamento dei problemi, è possibile informare immediatamente l'utente della soluzione.

Operazioni di tracciamento e debug delle versioni software

Quando un utente segnala un problema, in genere è a conoscenza solo dell'effetto immediato che ha sulle operazioni. L'utente può solo segnalare i risultati della propria esperienza. Queste esperienze sono in genere un sintomo visibile di uno o più problemi fondamentali. In molti casi, un analista deve analizzare la cronologia delle operazioni sottostanti per stabilire la causa radice del problema. Questo processo è denominato analisi della causa radice (RCA).

Requisiti per il tracciamento e il debug

Per tracciare eventi imprevisti e altri problemi, i dati di monitoraggio devono fornire informazioni sufficienti per consentire a un analista di trovare l'origine del problema e ricostruire la sequenza di eventi. Uno sviluppatore può quindi apportare modifiche per impedire la ripetizione del problema.

Raccogli dati di tracciamento e di debug

Per risolvere i problemi, tracciare tutti i metodi e i relativi parametri richiamati come parte di un'operazione. Creare quindi un albero che illustra il flusso logico attraverso il sistema quando un cliente effettua una richiesta specifica. Acquisire e registrare eccezioni e avvisi generati dal sistema in seguito a questo flusso.

Per supportare il debug, il sistema fornisce hook che è possibile usare per acquisire informazioni sullo stato in punti cruciali del sistema. In alternativa, il sistema può fornire informazioni dettagliate dettagliate in base allo stato di avanzamento delle operazioni selezionate. L'acquisizione dei dati a questo livello di dettaglio può aumentare il carico nel sistema e deve essere un processo temporaneo. Usare questo processo quando si verificano eventi insoliti e difficili da replicare o quando una nuova versione richiede un monitoraggio attento per garantire che gli elementi funzionino come previsto.

Pipeline di monitoraggio e diagnostica

Il monitoraggio di un sistema distribuito su vasta scala costituisce una sfida significativa. Non è necessario considerare necessariamente ognuno degli scenari descritti nelle sezioni precedenti in isolamento. I dati di monitoraggio e diagnostica necessari per ogni situazione si sovrappongono, ma potrebbe essere necessario elaborare e presentare questi dati in modi diversi. Per questi motivi, prendere una visione olistica del monitoraggio e della diagnostica.

È possibile immaginare l'intero processo di monitoraggio e diagnostica come pipeline che comprende le fasi illustrate nel diagramma seguente.

Il diagramma mostra il modo in cui i dati di monitoraggio e diagnostica provengono da varie origini. Le fasi di strumentazione e raccolta consentono di identificare i dati che è necessario acquisire, dove e come acquisirli e come formattarli in modo da poterli analizzare facilmente. La fase di analisi e diagnosi accetta i dati non elaborati e la usa per generare informazioni significative che è possibile usare per determinare lo stato del sistema. È possibile usare queste informazioni per determinare le possibili azioni da eseguire e quindi inserire i risultati nelle fasi di strumentazione e raccolta. La fase di visualizzazione e generazione degli avvisi fornisce una vista fruibile dello stato del sistema. Può visualizzare informazioni quasi in tempo reale usando una serie di dashboard. Può generare report, grafici e grafici per fornire una visualizzazione cronologica dei dati che consentono di identificare le tendenze a lungo termine. Se le informazioni indicano che è probabile che un indicatore KPI superi limiti accettabili, questa fase può anche attivare un avviso. In alcuni casi, un avviso può anche attivare un processo automatizzato che tenta di eseguire azioni correttive, ad esempio la scalabilità automatica.

Questi passaggi costituiscono un processo di flusso continuo in cui le fasi vengono eseguite in parallelo. Idealmente, tutte le fasi devono essere configurabili in modo dinamico. In alcuni punti, in particolare quando un sistema viene appena distribuito o si verificano problemi, potrebbe essere necessario raccogliere dati estesi più frequentemente. In altri casi, è possibile continuare a acquisire informazioni essenziali di alto livello per verificare che il sistema funzioni correttamente.

Considerare l'intero processo di monitoraggio come una soluzione in tempo reale che richiede l'ottimizzazione e i miglioramenti in base al feedback. Ad esempio, è possibile iniziare misurando molti fattori per determinare l'integrità del sistema e perfezionare l'analisi nel tempo per eliminare le misure non pertinenti.

Origini dei dati di monitoraggio e diagnostica

Le informazioni usate dal processo di monitoraggio possono provenire da diverse origini. A livello di applicazione, le informazioni provengono dai log di traccia incorporati nel codice di sistema. Gli sviluppatori devono seguire un approccio standard per tenere traccia del flusso di controllo tramite il codice. Ad esempio, all'ingresso di un metodo è possibile emettere un messaggio di traccia che specifica il nome del metodo, l'ora corrente, il valore di ogni parametro e altre informazioni pertinenti. È anche possibile registrare l'orario di ingresso e di uscita.

Registrare tutte le eccezioni e gli avvisi e assicurarsi di mantenere una traccia completa di eventuali eccezioni e avvisi annidati. Acquisire informazioni che identificano l'utente che esegue il codice e informazioni di correlazione dell'attività per tenere traccia delle richieste mentre attraversano il sistema. Registrare gli eventuali tentativi di accesso a tutte le risorse, quali code di messaggi, database, file e altri servizi da cui dipendono. È possibile usare queste informazioni a scopo di misurazione e controllo.

Molte applicazioni usano librerie e framework per eseguire attività comuni, ad esempio l'accesso a un archivio dati o la comunicazione tramite una rete. È possibile configurare questi framework per fornire i propri messaggi di traccia e informazioni di diagnostica non elaborate, ad esempio velocità delle transazioni e errori di trasmissione dei dati.

Il sistema operativo in cui viene eseguita l'applicazione può essere un'origine di informazioni di basso livello, a livello di sistema, ad esempio i contatori delle prestazioni che indicano le frequenze di I/O, l'utilizzo della memoria e l'utilizzo della CPU. Potrebbe anche segnalare errori del sistema operativo, ad esempio l'errore di aprire correttamente un file.

Consideri anche l'infrastruttura e i componenti sottostanti su cui viene eseguito il suo sistema. Le macchine virtuali, le reti virtuali e i servizi di archiviazione possono essere tutte origini di importanti contatori delle prestazioni a livello di infrastruttura e altri dati di diagnostica.

Se l'applicazione usa altri servizi esterni, ad esempio un server Web o un sistema di gestione di database (DBMS), questi servizi potrebbero pubblicare le proprie informazioni di traccia, log e contatori delle prestazioni. Ad esempio, le viste a gestione dinamica (DMV) in SQL Server tenere traccia delle operazioni eseguite su un database SQL Server. Application Insights analizza i log per registrare le richieste effettuate a Servizio app di Azure.

Quando si modificano i componenti di sistema e si distribuiscono nuove versioni, è importante che sia possibile attribuire problemi, eventi e metriche a ogni versione. Associare queste informazioni alla pipeline di versione in modo che sia possibile tenere traccia e risolvere rapidamente i problemi con una versione specifica di un componente.

Usare le strategie seguenti per raccogliere dati di monitoraggio e diagnostica:

• Il monitoraggio dell'applicazione e del sistema usa origini interne all'interno dell'applicazione, dei framework dell'applicazione, del sistema operativo e dell'infrastruttura. Il codice dell'applicazione può generare i propri dati di monitoraggio in punti rilevanti durante il ciclo di vita di una richiesta client. L'applicazione può includere istruzioni di traccia che è possibile attivare e disattivare in base alle esigenze. È anche possibile inserire la diagnostica in modo dinamico usando un framework di diagnostica. Questi framework in genere forniscono plug-in che si collegano a vari punti di strumentazione nel codice e acquisiscono i dati di traccia in questi punti.

  Il codice o l'infrastruttura sottostante possono anche generare eventi in punti critici. Gli agenti di monitoraggio configurati per l'ascolto di questi eventi possono registrare le informazioni sull'evento.

• Il monitoraggio utente reale registra le interazioni tra un utente e l'applicazione e osserva il flusso di ogni richiesta e risposta. Usare queste informazioni per misurare l'utilizzo da parte di ogni utente e determinare se gli utenti ricevono un QoS appropriato, inclusi tempi di risposta rapidi, bassa latenza e errori minimi. È possibile usare i dati per identificare le aree in cui si verificano gli errori più spesso. È anche possibile usare i dati per identificare le aree in cui il sistema rallenta a causa di hotspot nell'applicazione o altri colli di bottiglia. Se si implementa con attenzione questo approccio, è possibile ricostruire i flussi degli utenti attraverso l'applicazione per scopi di debug e test.

  Importante

  Considerare i dati acquisiti dal monitoraggio utente reale come altamente sensibili perché potrebbero includere materiale riservato. Se si salvano i dati acquisiti, archiviarlo in modo sicuro. Se si vogliono usare i dati per scopi di monitoraggio delle prestazioni o debug, rimuovere prima tutti i dati personali.

• Il monitoraggio utenti sintetici richiede di scrivere un client di test personalizzato che simula un utente ed esegue una serie di operazioni configurabili ma tipiche. È possibile tenere traccia delle prestazioni del client di test per determinare lo stato del sistema. È anche possibile usare più istanze del client di test come parte di un'operazione di test di carico per stabilire come il sistema risponde sotto stress e l'output di monitoraggio generato da queste condizioni.

  Note

  È possibile implementare il monitoraggio degli utenti reali e sintetici includendo codice che traccia e misura l'esecuzione delle chiamate di metodo e di altre parti critiche di un'applicazione.

• La profilatura consente di monitorare e migliorare le prestazioni dell'applicazione. A differenza del monitoraggio utente reale e del monitoraggio sintetico degli utenti, che operano a livello funzionale, la profilatura acquisisce informazioni di livello inferiore durante l'esecuzione dell'applicazione. Implementare la profilatura eseguendo periodicamente il campionamento dello stato di esecuzione di un'applicazione o determinando quale parte di codice viene eseguita dall'applicazione in un momento specifico. È anche possibile usare la strumentazione che inserisce probe nel codice in momenti importanti, ad esempio l'inizio e la fine di una chiamata al metodo. Le probe registrano quali metodi la chiamata ha invocato, a che ora e quanto tempo richiede ogni chiamata. È quindi possibile analizzare questi dati per determinare quali parti dell'applicazione potrebbero causare problemi di prestazioni.

• Il monitoraggio degli endpoint utilizza uno o più endpoint di diagnostica che l'applicazione espone appositamente per consentire il monitoraggio. Un endpoint fornisce un percorso nel codice dell'applicazione e può restituire informazioni sull'integrità del sistema. Endpoint diversi possono concentrarsi su vari aspetti della funzionalità. È possibile scrivere un client di diagnostica personalizzato che invia richieste periodiche a questi endpoint e assimila le risposte. Per ulteriori informazioni, vedere il Modello di monitoraggio dell'integrità degli endpoint.

• I dump degli errori utente si basano sull'applicazione per fornire un modo per raccogliere uno snapshot dello stato dell'applicazione se non è in grado di eseguire il ripristino. Gli utenti devono anche condividere volontariamente tale snapshot. Non è possibile garantire l'esecuzione di un dump di errore, ma si possono usare i dati di basso livello che esso fornisce per determinare la causa all'origine degli errori. Questo scenario è comune se gli errori si verificano raramente o se si verificano errori solo in una funzionalità dell'applicazione usata raramente.

Per la copertura massima, è consigliabile usare una combinazione di queste tecniche.

Instrumentare un'applicazione

La strumentazione è una parte fondamentale del processo di monitoraggio. È necessario acquisire dati che consentono di prendere decisioni significative sulle prestazioni e sull'integrità del sistema. Usare la strumentazione per raccogliere informazioni sufficienti per valutare le prestazioni, diagnosticare i problemi e prendere decisioni senza accedere a un server di produzione remoto per tracciare ed eseguire il debug manualmente. I dati di strumentazione in genere comprendono metriche e informazioni scritte nei log di traccia.

Un log di traccia può contenere dati testuali che l'applicazione scrive o dati binari creati da un evento di traccia, se l'applicazione usa Event Tracing for Windows (ETW). I log di sistema che registrano eventi che si verificano da parti dell'infrastruttura, ad esempio un server Web, possono anche generare contenuto del log di traccia. I messaggi di log testuali sono spesso leggibili dall'utente, ma li scrivono in un formato che un sistema automatizzato può anche analizzare facilmente.

Classificare anche i log. Non scrivere tutti i dati di traccia in un singolo log. Usare log separati per registrare l'output di traccia relativo ai diversi aspetti operativi del sistema. È quindi possibile filtrare rapidamente i messaggi di log leggendo dal log appropriato anziché elaborando un singolo file di lunghezza. Non scrivere mai informazioni con requisiti di sicurezza diversi, ad esempio le informazioni di controllo e i dati di debug, nello stesso log.

Le metriche sono in genere una misura o un conteggio di alcuni aspetti o risorse nel sistema in un momento specifico, con uno o più tag o dimensioni associati, detti anche campione. Una singola istanza di una metrica non è utile in isolamento. Raccogli invece le metriche nel tempo. Prendere in considerazione le metriche da registrare e la frequenza. La generazione di dati per le metriche troppo spesso può comportare un carico eccessivo nel sistema. Ma non acquisire dati sufficienti potrebbe farti perdere le circostanze che portano a un evento significativo. Le considerazioni variano da metrica a metrica. Ad esempio, l'utilizzo della CPU in un server potrebbe variare dal secondo al secondo, ma l'utilizzo elevato diventa un problema solo se persiste per diversi minuti.

Informazioni per la correlazione dei dati

È possibile monitorare facilmente singoli contatori delle prestazioni a livello di sistema, acquisire le metriche per le risorse e ottenere informazioni di traccia dell'applicazione da vari file di log. Tuttavia, alcune forme di monitoraggio richiedono la fase di analisi e diagnostica nella pipeline di monitoraggio per correlare i dati recuperati da diverse origini. Questi dati non elaborati possono assumere diverse forme e il processo di analisi deve disporre di dati di strumentazione sufficienti per eseguire il mapping di queste diverse forme. Ad esempio, a livello di framework applicazione, un ID thread potrebbe identificare un'attività. All'interno di un'applicazione, lo stesso lavoro potrebbe essere associato all'ID utente per l'utente che esegue tale attività.

È probabile che non esista un mapping uno-a-uno tra thread e richieste utente perché le operazioni asincrone potrebbero riutilizzare gli stessi thread per eseguire operazioni per più utenti. Più thread possono anche gestire una singola richiesta come flusso di esecuzione attraverso il sistema. Se possibile, associare ogni richiesta a un ID attività univoco propagato attraverso il sistema come parte del contesto della richiesta. La tecnica per la generazione e l'inclusione degli ID attività nelle informazioni di traccia dipende dalla tecnologia usata per acquisire i dati di traccia.

Applica un timestamp a tutti i dati di monitoraggio nello stesso modo. Per coerenza, registrare tutte le date e le ore usando l'ora UTC. Questo metodo consente di tracciare più facilmente sequenze di eventi.

Informazioni da includere nei dati di strumentazione

Quando si decide quali dati di strumentazione raccogliere, tenere presente quanto segue:

• Assicurarsi che le informazioni acquisite dagli eventi di traccia siano leggibili dal computer e leggibili dall'utente. Adottare schemi ben definiti per queste informazioni per facilitare l'elaborazione automatizzata dei dati di log tra sistemi e per garantire coerenza al personale operativo e tecnico che leggono i log. Includere informazioni ambientali, ad esempio l'ambiente di distribuzione, il computer in cui viene eseguito il processo, i dettagli del processo e lo stack di chiamate.

• Abilitare la profilatura solo quando necessario perché può comportare un sovraccarico significativo per il sistema. La profilatura tramite strumentazione registra un evento, ad esempio una chiamata al metodo, ogni volta che si verifica, mentre il campionamento registra solo gli eventi selezionati. La selezione può essere basata sul tempo, una volta ogni n secondi o basata sulla frequenza, una volta ogni n richieste. Se gli eventi si verificano frequentemente, la profilatura tramite strumentazione potrebbe causare una quantità eccessiva di carico e influire sulle prestazioni complessive. In questo caso, l'approccio di campionamento è preferibile. Tuttavia, se la frequenza degli eventi è bassa, il campionamento potrebbe perderli. In questo caso, la strumentazione potrebbe essere l'approccio migliore.

• Fornire contesto sufficiente in modo che uno sviluppatore o un amministratore possa determinare l'origine di ogni richiesta. Questo contesto può includere un ID attività che identifica un'istanza specifica di una richiesta o informazioni che correla un'attività con il lavoro di calcolo eseguito e le risorse usate. Questo lavoro potrebbe attraversare i limiti del processo e del computer. Per la misurazione, il contesto deve includere anche, direttamente o indirettamente, tramite altre informazioni correlate, un riferimento al cliente che genera la richiesta. Questo contesto fornisce informazioni utili sullo stato dell'applicazione durante l'acquisizione dei dati di monitoraggio.

• Registrare tutte le richieste e le località o le aree da cui vengono effettuate queste richieste. Queste informazioni consentono di determinare se esistono hotspot specifici della posizione. Può anche essere utile per determinare se ripartizionare un'applicazione o i dati usati.

• Registrare e acquisire attentamente i dettagli delle eccezioni. Spesso, le informazioni di debug critiche vengono perse a causa di una gestione delle eccezioni insufficiente. Acquisire i dettagli completi delle eccezioni generate dall'applicazione, incluse eventuali eccezioni interne e altre informazioni sul contesto. Se possibile, includere lo stack di chiamate.

• Essere coerenti nei dati acquisiti dai diversi elementi dell'applicazione. La coerenza consente di analizzare gli eventi e correlarli con le richieste degli utenti. Prendere in considerazione l'uso di un pacchetto di registrazione completo e configurabile per raccogliere informazioni, anziché fare affidamento sugli sviluppatori affinché adottino lo stesso approccio durante l'implementazione delle diverse parti del sistema. Raccogliere dati dai contatori delle prestazioni chiave, ad esempio il volume di I/O, l'utilizzo della rete, il numero di richieste, l'uso della memoria e l'utilizzo della CPU. Alcuni servizi di infrastruttura possono fornire contatori delle prestazioni personalizzati, ad esempio il numero di connessioni a un database, la frequenza con cui il sistema esegue transazioni e il numero di transazioni che hanno esito positivo o negativo. Le applicazioni possono anche definire contatori delle prestazioni specifici.

• Registra tutte le chiamate effettuate a servizi esterni, ad esempio sistemi di database, servizi Web o altri servizi a livello di sistema che fanno parte dell'infrastruttura. Registrare informazioni sul tempo necessario per eseguire ogni chiamata e se la chiamata ha esito positivo o negativo. Se possibile, acquisire informazioni su tutti i tentativi di ripetizione e fallimenti per qualsiasi errore temporaneo che si verifica.

Garantire la compatibilità con i sistemi di telemetria

In molti casi, le informazioni generate dalla strumentazione vengono generate come una serie di eventi e passate a un sistema di telemetria separato per l'elaborazione e l'analisi. Un sistema di telemetria è in genere indipendente da applicazioni o tecnologie specifiche, ma prevede che le informazioni seguano un formato specifico definito da uno schema. Lo schema specifica un contratto che definisce i campi dati e i tipi che il sistema di telemetria può inserire. Generalizzare lo schema per consentire i dati da un'ampia gamma di piattaforme e dispositivi. Un esempio di framework e schema ampiamente usato è OpenTelemetry.

Uno schema comune deve includere campi che tutti gli eventi di strumentazione hanno in comune, ad esempio il nome dell'evento, l'ora dell'evento, l'indirizzo IP del mittente. Deve includere anche i dettagli necessari per correlare con altri eventi, ad esempio un ID utente, un ID dispositivo e un ID applicazione. Tenere presente che un numero qualsiasi di dispositivi potrebbe generare eventi, quindi lo schema non deve dipendere dal tipo di dispositivo. Inoltre, vari dispositivi potrebbero generare eventi per la stessa applicazione e l'applicazione potrebbe supportare il roaming o un'altra forma di distribuzione tra dispositivi.

Lo schema può includere anche campi di dominio rilevanti per uno scenario specifico comune in diverse applicazioni. Questi scenari includono informazioni sulle eccezioni, sugli eventi di avvio e fine dell'applicazione e sull'esito positivo o negativo delle chiamate API del servizio Web. Tutte le applicazioni che usano lo stesso set di campi di dominio devono generare lo stesso set di eventi per creare un set di report e analisi comuni.

Infine, uno schema può contenere campi personalizzati per acquisire i dettagli degli eventi specifici dell'applicazione.

Pratiche migliori per la strumentazione delle applicazioni

L'elenco seguente riepiloga le procedure consigliate per instrumentare un'applicazione distribuita eseguita nel cloud:

• Semplificare la lettura e l'analisi dei log. Usare la registrazione strutturata laddove possibile. Essere concisi e descrittivi nei messaggi di log.

• In tutti i log identificare l'origine e fornire informazioni di contesto e temporizzazione durante la scrittura di ogni record di log.

• Usare lo stesso fuso orario e il formato per tutti i timestamp. Questa procedura consente di correlare gli eventi per le operazioni che si estendono su hardware e servizi eseguiti in aree geografiche diverse.

• Classificare i log e scrivere messaggi nel file di log appropriato.

• Non divulgare informazioni riservate sul sistema o informazioni personali sugli utenti. Ripulisci queste informazioni prima di registrarle, ma assicurati di conservare i dettagli pertinenti. Ad esempio, rimuovere l'ID e la password dalle stringhe di connessione del database. Scrivere le informazioni rimanenti nel log in modo che sia possibile determinare se il sistema accede al database corretto. Registrare tutte le eccezioni critiche, ma consentire all'amministratore di attivare e disattivare la registrazione per livelli inferiori di eccezioni e avvisi. Acquisire e registrare anche tutte le informazioni sulla logica di ripetizione dei tentativi. È possibile usare questi dati per monitorare l'integrità temporanea del sistema.

• Traccia le chiamate esterne al processo, ad esempio le richieste a servizi web esterni o a database.

• Non combinare messaggi di log con requisiti di sicurezza diversi nello stesso file di log. Ad esempio, non scrivere informazioni di debug e controllo nello stesso log.

• Avviare le chiamate di registrazione che continuano a funzionare in modo autonomo. Questi tipi di operazioni non bloccano lo stato di avanzamento delle operazioni aziendali. Gli eventi di controllo sono un'eccezione perché sono fondamentali per l'azienda. Classificarli come parte fondamentale delle operazioni aziendali.

• Assicurarsi che il sistema di logging sia estensibile e non abbia dipendenze dirette da una destinazione specifica. Ad esempio, anziché scrivere informazioni usando System.Diagnostics.Trace, definire un'interfaccia astratta, ad esempio ILogger, che espone i metodi di registrazione e che è possibile implementare tramite qualsiasi mezzo appropriato.

• Assicurarsi che tutta la registrazione sia a prova di guasto e non inneschi mai errori a cascata. La registrazione non deve generare eccezioni.

• Considerare la strumentazione come un processo iterativo in corso ed esaminare regolarmente i log, non solo quando si verifica un problema.

Raccogliere e archiviare i dati

La fase di raccolta recupera le informazioni generate dalla strumentazione, formatta questi dati per semplificare l'utilizzo durante la fase di analisi e diagnosi e salva i dati trasformati in un archivio affidabile. È possibile archiviare i dati di strumentazione raccolti da parti diverse di un sistema distribuito in diversi percorsi e formati. Ad esempio, il codice dell'applicazione potrebbe generare file di log di traccia e dati del log eventi dell'applicazione. Altre tecnologie possono acquisire contatori delle prestazioni che monitorano gli aspetti chiave dell'infrastruttura usata dall'applicazione. Tutti i componenti e i servizi non Microsoft usati dall'applicazione possono fornire informazioni di strumentazione in formati diversi usando file di traccia separati, archiviazione BLOB o anche un archivio dati personalizzato.

Servizio di raccolta che viene eseguito in modo autonomo dall'applicazione che genera i dati di strumentazione in genere raccoglie i dati. Il diagramma seguente mostra un esempio di questa architettura ed evidenzia il sottosistema di raccolta dati di strumentazione.

Questo diagramma mostra una visualizzazione semplificata della raccolta dati. Il servizio di raccolta comprende in genere molte parti eseguite in computer diversi. Se è necessario analizzare rapidamente i dati di telemetria, usare i componenti locali che operano all'esterno del servizio di raccolta. Dopo l'elaborazione analitica, i componenti inviano i risultati direttamente al sottosistema di visualizzazione e avviso. I dati soggetti all'analisi ad accesso frequente o sporadico sono mantenuti nell'archiviazione durante l'attesa dell'elaborazione. Per altre informazioni, vedi Supporto per l'analisi a caldo, a tiepido e a freddo.

Per Azure applicazioni e servizi eseguiti in macchine virtuali, l'agente Monitoraggio di Azure offre una soluzione per l'acquisizione dei dati. È possibile definire regole di raccolta dati (DCR) che specificano i dati da raccogliere da ogni nodo di calcolo e dall'area di lavoro Log Analytics in Monitoraggio di Azure a cui inviarli. L'agente può raccogliere dati dalle origini seguenti:

• Log di Internet Information Services (IIS)
• Registri eventi di Windows
• Contatori delle prestazioni
• Syslog dai nodi Linux
• Log di testo e JSON scritti da applicazioni

Strategie per la raccolta dei dati di strumentazione

A causa della natura elastica del cloud e per evitare di recuperare manualmente i dati di telemetria da ogni nodo del sistema, disporre di consolidare i dati e trasferirli in una posizione centrale. In un sistema che si estende su più data center, è possibile raccogliere, consolidare e archiviare prima i dati in base all'area per area e quindi aggregare i dati a livello di area in un unico sistema centrale.

Per ottimizzare l'uso della larghezza di banda, è possibile trasferire dati meno urgenti come batch. Non ritardare il trasferimento a tempo indefinito, soprattutto se i dati contengono informazioni sensibili al tempo.

Eseguire il pull e il push dei dati di strumentazione

Il sottosistema di raccolta dati di strumentazione può recuperare attivamente i dati di strumentazione dai vari log e altre origini per ogni istanza dell'applicazione. Questo metodo viene chiamato modello pull. Oppure può fungere da ricevitore passivo che attende i componenti che costituiscono ogni istanza dell'applicazione per inviare i dati. Questo metodo è denominato modello push.

Un approccio al modello pull consiste nell'usare agenti di monitoraggio eseguiti localmente con ogni istanza dell'applicazione. Un agente di monitoraggio è un processo separato che recupera periodicamente i dati di telemetria raccolti nel nodo locale e scrive queste informazioni nell'archiviazione centralizzata condivisa da tutte le istanze dell'applicazione. L'agente Monitoraggio di Azure implementa questo meccanismo. I dati vengono configurati per la raccolta da ogni istanza di calcolo tramite una regola di raccolta dati. L'agente di monitoraggio eseguito insieme a ogni istanza raccoglie i dati specificati, ad esempio i log IIS, i registri eventi Windows e i contatori delle prestazioni e li invia a un'area di lavoro Log Analytics in Monitoraggio di Azure, in cui è possibile eseguire query e analizzarli. Il diagramma seguente illustra un esempio di questa architettura.

È possibile usare i modelli pull e push per archiviare i dati di telemetria per un'applicazione su scala ridotta eseguita in un numero limitato di nodi in un'unica posizione. Un'applicazione cloud globale complessa e altamente scalabile può generare enormi volumi di dati da centinaia di istanze di calcolo, partizioni di database e altri servizi. Questa alluvione di dati può facilmente sovraccaricare la larghezza di banda di I/O disponibile con una singola posizione centrale. Di conseguenza, è necessario essere in grado di ridimensionare la soluzione di telemetria per evitare un collo di bottiglia man mano che il sistema si espande. Idealmente, la soluzione deve incorporare un grado di ridondanza per ridurre i rischi di perdita di informazioni di monitoraggio importanti, ad esempio il controllo o i dati di fatturazione, se parte del sistema non riesce.

Per risolvere questi problemi, implementa l'accodamento. Nell'architettura di esempio seguente, l'agente di monitoraggio locale o il servizio di raccolta dati personalizzato inserisce i dati in una coda. Il servizio di scrittura nello storage, un processo asincrono separato, preleva i dati da questa coda e li scrive nello storage condiviso. Una coda di messaggi è adatta a questo scenario perché fornisce semantiche at-least-once che consentono di garantire che i dati in coda non vengano persi dopo la pubblicazione. È possibile implementare il servizio di scrittura nello storage utilizzando un processo separato in background.

Il servizio di raccolta dati locale può aggiungere dati a una coda immediatamente dopo averlo ricevuto. La coda funge da buffer e il servizio di scrittura dell'archiviazione può recuperare e scrivere i dati al proprio ritmo. Per impostazione predefinita, una coda opera in base al principio del primo arrivato, primo servito. Tuttavia, è possibile classificare in ordine di priorità i messaggi per accelerarli attraverso la coda se contengono dati che è necessario gestire rapidamente. Per altre informazioni, vedere Modello di coda priorità. In alternativa, è possibile utilizzare canali diversi, ad esempio argomenti di bus di servizio, per indirizzare i dati verso destinazioni diverse in base al tipo di elaborazione analitica richiesto.

Per garantire la scalabilità, è possibile eseguire più istanze del servizio di scrittura per la memorizzazione. Per volumi elevati di eventi, è possibile usare un hub eventi per inviare i dati a risorse di calcolo diverse per l'elaborazione e l'archiviazione.

Consolidare i dati di strumentazione

I dati di strumentazione recuperati dal servizio di raccolta dati da una singola istanza di un'applicazione offrono una visualizzazione localizzata dell'integrità e delle prestazioni di tale istanza. Per valutare l'integrità complessiva del sistema, consolidare gli aspetti dei dati nelle visualizzazioni locali. È possibile eseguire questo passaggio dopo l'archiviazione dei dati, ma in alcuni casi è anche possibile farlo durante la raccolta dei dati. Anziché scrivere direttamente nell'archiviazione condivisa, i dati di strumentazione passano attraverso un servizio separato che consolida, filtra e pulisce i dati. Ad esempio, i dati di strumentazione che includono le stesse informazioni di correlazione, ad esempio un ID attività, possono essere amalgamati. Un utente potrebbe avviare un'operazione aziendale in un nodo e quindi essere trasferito a un altro nodo se il nodo ha esito negativo o a causa del bilanciamento del carico. Questo processo può anche rilevare e rimuovere dati duplicati, cosa che può accadere se il servizio di telemetria usa code di messaggi per inviare i dati di telemetria a un sistema di archiviazione. Il diagramma seguente mostra un esempio di questa struttura.

Archiviare i dati di strumentazione

Le sezioni precedenti illustrano una visualizzazione semplificata di come archiviare i dati di strumentazione. In pratica, è consigliabile archiviare diversi tipi di informazioni usando le tecnologie che si adattano al modo in cui si prevede di usarlo.

Ad esempio, Archiviazione BLOB di Azure e Archiviazione tabelle di Azure hanno modelli di accesso simili, ma le operazioni che possono eseguire sono limitate e la granularità dei dati archiviati varia. Se è necessario eseguire operazioni analitiche o richiedere funzionalità di ricerca full-text, potrebbe essere necessario usare l'archiviazione dei dati che offre le funzionalità di query e accesso ai dati seguenti:

• Archiviare i dati del contatore delle prestazioni in un database SQL per abilitare l'analisi non pianificata.
• Archiviare i log di traccia in Azure Cosmos DB.
• Scrivere informazioni di sicurezza in Hadoop Distributed File System (HDFS).
• Archiviare le informazioni che richiedono la ricerca full-text tramite Elasticsearch, che usa l'indicizzazione avanzata per accelerare le ricerche.

Il diagramma seguente illustra come implementare un servizio aggiuntivo che recupera periodicamente i dati dall'archiviazione condivisa, dalle partizioni e filtra i dati in base allo scopo e quindi li scrive in un set appropriato di archivi dati. Un approccio alternativo consiste nell'includere questa funzionalità nel processo di consolidamento e pulizia e scrivere i dati direttamente in questi archivi durante il recupero, anziché salvarli in un'area di archiviazione condivisa intermedia. Ogni approccio presenta vantaggi e svantaggi. L'implementazione di un servizio di partizionamento separato riduce il carico del servizio di consolidamento e pulizia. Consente inoltre di rigenerare almeno alcuni dei dati partizionati, se necessario, a seconda della quantità di archiviazione condivisa dei dati mantenuta. Tuttavia, questo approccio usa più risorse. Potrebbe anche ritardare la ricezione dei dati di strumentazione da ogni istanza dell'applicazione e la conversione di questi dati in informazioni utilizzabili.

Potrebbero essere necessari gli stessi dati di strumentazione per più scopi. Ad esempio, i contatori delle prestazioni possono fornire una visualizzazione cronologica delle prestazioni del sistema nel tempo. È possibile combinare queste informazioni con altri dati di utilizzo per generare informazioni di fatturazione dei clienti. In questi scenari, inviare gli stessi dati a più di una destinazione, ad esempio un database di documenti che archivia le informazioni di fatturazione e un archivio multidimensionale che gestisce analisi delle prestazioni complesse.

Considerare quanto urgentemente sono necessari i dati. I dati che forniscono informazioni per l'invio di avvisi devono essere accessibili rapidamente, pertanto è consigliabile archiviarli in un archivio dati veloce e indicizzarli o strutturarli per ottimizzare le query di sistema di avviso. In alcuni casi, il servizio di telemetria che raccoglie i dati in ogni nodo potrebbe dover formattare e salvare i dati in locale in modo che un'istanza locale del sistema di avvisi possa inviare rapidamente una notifica sui problemi. È possibile inviare gli stessi dati al servizio di scrittura dello spazio di archiviazione che i diagrammi precedenti mostrano e archiviarli centralmente, se necessario per altri scopi.

Le informazioni usate per l'analisi più complessa, la creazione di report e l'identificazione delle tendenze cronologiche sono meno urgenti. Archiviarlo in modo da supportare il data mining e le query non pianificate. Per altre informazioni, vedi Supporto per l'analisi a caldo, a tiepido e a freddo.

Rotazione dei log e conservazione dei dati

La strumentazione genera molti dati. In alcuni casi, dopo l'elaborazione e il trasferimento dei dati, è possibile rimuovere i dati di origine non elaborati originali da ogni nodo. Oppure potrebbe essere necessario salvare le informazioni non elaborate.

I dati sulle prestazioni hanno in genere una durata più lunga, in modo da poterli usare per identificare le tendenze delle prestazioni e la capacità del piano. Mantenere online la visualizzazione consolidata di questi dati per un periodo finito in modo che sia possibile accedervi rapidamente. Potrebbe essere necessario salvare i dati raccolti per la misurazione e la fatturazione per un periodo illimitato. Inoltre, i requisiti normativi potrebbero richiedere l'archiviazione e il salvataggio delle informazioni raccolte per scopi di controllo e sicurezza. Crittografare o proteggere in altro modo questi dati sensibili per evitare manomissioni. Non registrare mai le password degli utenti o altre informazioni personali. Pulire questi dettagli dai dati prima di archiviarlo.

Riduzione del campionamento dei dati

Archiviare i dati cronologici per individuare tendenze a lungo termine. Invece di salvare tutti i dati obsoleti, è possibile eseguire il down-sample dei dati per ridurre la risoluzione e risparmiare sui costi di archiviazione. Ad esempio, invece di risparmiare indicatori di prestazioni minuto per minuto, è possibile consolidare i dati più vecchi di un mese per formare una visualizzazione oraria per ora.

Procedure consigliate per la raccolta e l'archiviazione delle informazioni di registrazione

L'elenco seguente riepiloga le procedure consigliate per l'acquisizione e l'archiviazione delle informazioni di registrazione:

• L'agente di monitoraggio o il servizio di raccolta dati deve essere eseguito come servizio out-of-process ed essere semplice da distribuire.

• Tutto l'output dell'agente di monitoraggio o del servizio di raccolta dati deve essere un formato indipendente dal computer, dal sistema operativo o dal protocollo di rete. Ad esempio, generare informazioni in un formato autodescrittivo, ad esempio JSON, MessagePack o Protobuf anziché file ETL (Event Trace Log) in Linux o ETW. Usare un formato standard in modo che il sistema possa costruire pipeline di elaborazione. È possibile integrare facilmente i componenti che leggono, trasformano e inviano dati nel formato concordato.

• Il processo di monitoraggio e raccolta dati deve essere sicuro e non deve attivare errori a catena.

• Se un errore temporaneo invia informazioni a un sink di dati, l'agente di monitoraggio o il servizio di raccolta dati deve essere preparato per riordinare i dati di telemetria in modo che le informazioni più recenti vengano inviate per prime. L'agente di monitoraggio o il servizio di raccolta dati potrebbe scegliere di eliminare i dati meno recenti o salvarli in locale e trasmetterli in un secondo momento per recuperarli, a propria discrezione.

Analizzare i dati e diagnosticare i problemi

Una parte importante del monitoraggio e della diagnostica consiste nell'analizzare i dati raccolti per ottenere un quadro dell'integrità complessiva del sistema. Definire indicatori KPI e metriche delle prestazioni personalizzati e informazioni su come strutturare i dati per soddisfare i requisiti di analisi. Comprendere in che modo i dati acquisiti in metriche e file di log diversi sono correlati perché queste informazioni sono fondamentali per tenere traccia di una sequenza di eventi e diagnosticare i problemi.

I dati per ogni parte del sistema vengono in genere acquisiti localmente, ma è necessario combinarlo con i dati generati in altri siti che partecipano al sistema. Correlare attentamente queste informazioni per assicurarsi che i dati vengano combinati in modo accurato. Ad esempio, i dati di utilizzo per un'operazione potrebbero estendersi sui nodi seguenti:

• Nodo che ospita un sito Web a cui un utente si connette
• Nodo che esegue un servizio separato a cui si accede come parte di questa operazione
• Nodo che archivia i dati

È necessario collegare queste informazioni per fornire una visualizzazione complessiva dell'utilizzo delle risorse e dell'elaborazione per l'operazione. Il nodo che acquisisce i dati potrebbe pre-elaborarli e filtrarli, ma i nodi centrali in genere aggregano e formattano i dati. Per altre informazioni, vedere Consolidare i dati di strumentazione.

Supporta l'analisi a caldo, a tiepido e a freddo

L'analisi e la riformattazione dei dati per scopi di visualizzazione, creazione di report e avvisi possono essere un processo complesso che utilizza il proprio set di risorse. Alcune forme di monitoraggio richiedono, per essere efficaci, un'analisi immediata dei dati, nota anche come analisi a caldo. Gli esempi includono l'analisi per l'invio di avvisi e il monitoraggio della sicurezza. Per l'analisi ad accesso frequente, rendere i dati disponibili e strutturati per un'elaborazione efficiente. In alcuni casi, potrebbe essere necessario spostare l'elaborazione dell'analisi nei singoli nodi che contengono i dati.

Altre forme di analisi sono meno sensibili al tempo e potrebbero richiedere calcoli e aggregazioni dopo la ricezione dei dati non elaborati. Questo metodo si chiama analisi warm. L'analisi delle prestazioni rientra spesso in questa categoria. In questo caso, un picco o un errore improvviso può causare un singolo evento di prestazioni isolato che non è statisticamente significativo. I dati di una serie di eventi offrono un quadro più affidabile delle prestazioni del sistema.

Puoi anche usare l'analisi a caldo per aiutare a diagnosticare i problemi di funzionamento. Usare l'analisi in tempo reale per elaborare un evento sullo stato di integrità e attivare immediatamente un avviso. Quindi utilizzare l'analisi a caldo per esaminare i dati e individuare la causa dell'evento relativo allo stato di salute.

Alcuni tipi di monitoraggio generano dati a lungo termine. È possibile eseguire questa analisi in un secondo momento, possibilmente in base a una pianificazione predefinita. In alcuni casi, l'analisi potrebbe dover filtrare grandi volumi di dati acquisiti nel tempo. Questo metodo è detto analisi a freddo. Il requisito chiave è che i dati vengono archiviati in modo sicuro dopo l'acquisizione. Ad esempio, il monitoraggio e il controllo dell'utilizzo richiedono un quadro accurato dello stato del sistema a intervalli regolari, ma queste informazioni sullo stato non devono essere immediatamente disponibili per l'elaborazione.

È anche possibile utilizzare l'analisi a freddo per fornire i dati per l'analisi predittiva dello stato di salute. Raccogliere dati storici in un periodo specificato e combinarli con i dati correnti sullo stato di salute per individuare tendenze che potrebbero causare problemi di salute. In questi casi, potrebbe essere necessario generare un avviso per correggere la tendenza.

Correlare i dati

I dati acquisiti dalla strumentazione possono fornire uno snapshot dello stato del sistema, ma lo scopo dell'analisi è rendere questi dati interattivi. Ad esempio, è possibile determinare la causa del caricamento di I/O intenso a livello di sistema a un momento specifico e assicurarsi che i tempi di risposta del database, il numero di transazioni al secondo e i tempi di risposta dell'applicazione allo stesso punto confermano i risultati.

Un modo per ridurre il carico consiste nel partizionare i dati su più server. Le eccezioni possono verificarsi a causa di un errore a qualsiasi livello del sistema. Un'eccezione a un livello spesso attiva un altro errore al livello superiore.

Per questi motivi, è necessario correlare i diversi tipi di dati di monitoraggio a ogni livello per produrre una visualizzazione generale dello stato del sistema e delle applicazioni eseguite su di esso. Utilizzare queste informazioni per decidere se il sistema funziona in modo accettabile e determinare le operazioni che è possibile eseguire per migliorare la qualità.

Assicurarsi che i dati di strumentazione non elaborati includano informazioni sufficienti sul contesto e sull'ID attività per supportare le aggregazioni necessarie per correlare gli eventi. Questi dati potrebbero essere conservati in formati diversi, pertanto potrebbe essere necessario analizzarli e convertirli in un formato standardizzato per l'analisi. Per altre informazioni, vedere Informazioni per la correlazione dei dati.

Risolvere e diagnosticare i problemi

Per diagnosticare i problemi, è necessario eseguire rca per determinare la causa di errori o comportamenti imprevisti. In genere sono necessarie le informazioni seguenti per l'intero sistema o per un sottosistema specifico durante un intervallo di tempo specificato:

• Informazioni dettagliate dai registri eventi e dalle tracce
• Completare le analisi dello stack dalle eccezioni e dagli errori di qualsiasi livello specificato
• Dump di arresto anomalo per qualsiasi processo non riuscito
• Registri attività che registrano le operazioni effettuate da tutti gli utenti o da utenti selezionati

Per analizzare i dati a scopo di risoluzione dei problemi, è necessaria una conoscenza tecnica approfondita dell'architettura di sistema e dei relativi componenti. È necessario interpretare i dati, stabilire la causa dei problemi e consigliare una strategia per correggerli. Un'altra strategia consiste nell'archiviare una copia di queste informazioni nel formato originale e renderla disponibile per l'analisi a freddo da parte di un esperto.

Visualizzare i dati e generare avvisi

I sistemi di monitoraggio devono presentare dati in modo da poter identificare rapidamente tendenze o problemi. Devono anche notificare immediatamente quando si verifica un evento che richiede attenzione.

La presentazione dei dati può assumere diverse forme, tra cui la visualizzazione usando dashboard, avvisi e report.

Visualizzazione tramite dashboard

Il modo più comune per visualizzare i dati consiste nell'utilizzare dashboard in cui le informazioni sono presentate sotto forma di una serie di grafici, diagrammi o altre illustrazioni. È possibile parametrizzare questi elementi e selezionare i parametri importanti, ad esempio il periodo di tempo, per una situazione specifica.

È possibile organizzare i dashboard in modo gerarchico. I dashboard di primo livello offrono una visualizzazione complessiva di ogni aspetto del sistema e consentono di eseguire il drill-down dei dettagli. Ad esempio, in un dashboard che illustra l'I/O complessivo del disco per il sistema, è possibile visualizzare le tariffe di I/O per ogni singolo disco per determinare se uno o più dispositivi specifici rappresentano un volume sproporzionato di traffico. Il dashboard deve anche visualizzare informazioni correlate, ad esempio l'utente o l'attività che genera l'I/O. Queste informazioni consentono di distribuire il carico in modo più uniforme tra i dispositivi.

Un dashboard può anche usare la codifica a colori o altri segnali visivi per indicare i valori che appaiono anomali o che non rientrano in un intervallo previsto. Si considerino gli esempi di codifica a colori seguenti:

• Rosso per un disco con una velocità di I/O che si avvicina alla capacità massima per un periodo prolungato, oppure per un disco molto utilizzato

• Giallo per un disco con un tasso di I/O che raggiunge periodicamente il limite massimo per brevi intervalli, oppure un disco con attività moderata

• Verde per un disco che presenta un utilizzo normale

I sistemi dashboard devono avere i dati non elaborati per funzionare in modo efficace. Se si crea un sistema dashboard personalizzato o si usa un dashboard sviluppato da un'altra organizzazione, è necessario comprendere quali dati di strumentazione è necessario raccogliere, a quali livelli di granularità e come formattarli per l'utilizzo del dashboard.

Un dashboard efficace consente anche di porre domande sulle informazioni. Alcuni sistemi forniscono strumenti di gestione che è possibile usare per eseguire queste attività ed esplorare i dati sottostanti. A seconda del repository che contiene le informazioni, è possibile eseguire query sui dati direttamente o importarli in strumenti come Excel per ulteriori analisi e report.

Generare avvisi

L'invio di avvisi analizza i dati di monitoraggio e strumentazione e genera una notifica se rileva un evento significativo.

L'invio di avvisi garantisce che il sistema rimanga integro, reattivo e sicuro. È una parte importante di qualsiasi sistema che garantisce prestazioni, disponibilità e privacy agli utenti. Il sistema di avviso può anche segnalare gli eventi che generano avvisi. Usare gli avvisi per richiamare funzioni di sistema come la scalabilità automatica.

Gli avvisi dipendono dai dati di strumentazione seguenti:

• Eventi di sicurezza: Se i registri eventi indicano che si verificano errori ripetuti di autenticazione o autorizzazione. In questo scenario, un avviso dovrebbe informare che il sistema potrebbe essere sotto attacco.

• Metriche delle prestazioni: Il sistema deve rispondere rapidamente se una metrica delle prestazioni supera una soglia specificata.

• Informazioni sulla disponibilità: Se viene rilevato un errore, potrebbe essere necessario riavviare rapidamente uno o più sottosistemi o eseguire il failover in una risorsa di backup. Gli errori ripetuti in un sottosistema potrebbero indicare problemi più gravi.

È possibile ricevere informazioni sugli avvisi tramite molti canali, ad esempio posta elettronica, cercapersone o SMS. Un avviso può includere anche un'indicazione del livello di criticità di una situazione. Molti sistemi di avviso supportano i gruppi di sottoscrittori e tutti gli operatori membri dello stesso gruppo ricevono lo stesso set di avvisi.

Rendere personalizzabile il sistema di avvisi e specificare i valori appropriati dei dati di strumentazione sottostanti come parametri. Usando questo approccio, è possibile filtrare i dati per soglie o combinazioni specifiche di valori. In alcuni casi, è possibile fornire i dati di strumentazione non elaborati al sistema di avvisi. Oppure potrebbe essere più appropriato fornire dati aggregati. Ad esempio, un avviso viene attivato quando l'utilizzo della CPU per un nodo supera i 90% negli ultimi 10 minuti. Fornire al sistema di avvisi informazioni di riepilogo e contesto appropriate per ridurre la possibilità che gli eventi falsi positivi attivino un avviso.

Reportistica

Usare la creazione di report per generare una visualizzazione complessiva del sistema. Può incorporare dati cronologici e informazioni correnti. I requisiti di creazione di report rientrano nelle categorie operative e di sicurezza.

La creazione di report operativi include in genere gli aspetti seguenti per il sistema complessivo o per sottosistemi specifici durante un intervallo di tempo specificato:

• Statistiche aggregate che è possibile usare per comprendere l'utilizzo delle risorse

• Tendenze nell'utilizzo delle risorse

• Monitoraggio delle eccezioni

• Efficienza delle applicazioni in termini di risorse distribuite e se è possibile ridurre il volume di risorse senza influire sulle prestazioni

La reportistica sulla sicurezza monitora il modo in cui i clienti utilizzano il sistema. In genere include gli aspetti seguenti:

• Controlla le operazioni degli utenti. Registrare singole richieste eseguite da ogni utente insieme a date e ore. Strutturare i dati in modo da poter ricostruire rapidamente la sequenza di operazioni eseguite da un utente in un periodo specificato.

• Tenere traccia dell'uso delle risorse per ogni utente. Registrare il modo in cui ogni richiesta per un utente accede alle risorse di sistema e per quanto tempo. Usare questi dati per generare un report di utilizzo per ogni utente in un periodo specificato, possibilmente a scopo di fatturazione.

In molti casi, i processi batch possono generare report in base a una pianificazione definita. La generazione di report in genere non aumenta la latenza, quindi è possibile generare report su richiesta, se necessario. Se si archiviano dati in un database relazionale, ad esempio database SQL di Azure, è possibile usare uno strumento come SQL Server Reporting Services per estrarre e formattare i dati e presentarli come set di report.

Passaggi successivi

• Panoramica di Monitoraggio di Azure
• Monitorare, diagnosticare e risolvere i problemi di archiviazione
• Panoramica degli avvisi in Azure
• Panoramica di Application Insights
• Diagnostica delle prestazioni per le macchine virtuali di Azure

Risorse correlate

• Le linee guida per la scalabilità automatica descrivono come ridurre il sovraccarico di gestione riducendo la necessità di monitorare continuamente le prestazioni del sistema e prendere decisioni per aggiungere o rimuovere risorse.

• Il modello di monitoraggio degli endpoint di integrità descrive come implementare controlli funzionali all'interno di un'applicazione a cui gli strumenti esterni possono accedere a intervalli regolari tramite endpoint esposti.

• Modello di coda priorità descrive come classificare in ordine di priorità i messaggi in coda in modo che i sistemi ricevano ed elaborano richieste urgenti prima di messaggi meno urgenti.