Condividi tramite

Suggerimenti per la strumentazione di un'applicazione

  • Articolo

Si applica a questa raccomandazione per l'eccellenza operativa di Azure Well-Architected Framework:

OE:07 Progettare e implementare un sistema di monitoraggio per convalidare le scelte di progettazione e informare le future decisioni di progettazione e business. Questo sistema acquisisce ed espone dati di telemetria operativi, metriche e log che emettono dall'infrastruttura e dal codice del carico di lavoro.

Guida correlata: Consigli per la progettazione e la creazione di un sistema di monitoraggio

Questa guida descrive le raccomandazioni per abilitare l'osservabilità dell'applicazione usando la strumentazione. Generare dati di telemetria significativi che possono essere inseriti e integrati nel sistema di monitoraggio. Usando la strumentazione, è possibile raccogliere informazioni senza accedere a un server di produzione remoto per eseguire manualmente la traccia o il debug. I dati di strumentazione includono metriche e log che è possibile usare per valutare le prestazioni, diagnosticare i problemi e prendere decisioni relative al carico di lavoro.

Strategie di progettazione chiave

Per ottimizzare i dati di telemetria per il carico di lavoro, instrumentare l'applicazione per generare i dati seguenti:

  • I log sono record timestamp di eventi discreti. Esistono tre forme di log: testo normale, strutturato e binario.

  • I log di traccia distribuiti consentono di visualizzare il percorso di una richiesta mentre passa attraverso diversi servizi e componenti.

  • Le metriche sono valori numerici che descrivono un aspetto di un sistema in un determinato momento.

Nota

È possibile usare strumenti come Application Insights, Dynatrace e Elastic Application Monitor prestazioni ing per instrumentare automaticamente l'applicazione. Questi strumenti semplificano la strumentazione, ma possono anche limitarsi. Se si usa uno strumento di strumentazione automatica, è possibile aggiungere altre funzionalità tramite la strumentazione manuale in base alle esigenze.

Usare log strutturati e traccia

Usare la registrazione strutturata per integrare facilmente i log nelle piattaforme di monitoraggio e analisi. Instrumentare l'applicazione in modo che sia possibile modificare i livelli di dettaglio. La registrazione dettagliata costante può sprecare risorse di archiviazione, quindi deve essere attivata e disattivata in base alle esigenze per la risoluzione dei problemi.

I log di traccia contengono dati testuali o dati binari creati da un evento di traccia, se l'applicazione usa Event Tracing for Windows (ETW). I log di sistema generano contenuto del log di traccia dagli eventi nell'infrastruttura, ad esempio il server Web. Il contenuto del log testuale è progettato per essere leggibile dagli esseri umani, ma è necessario assicurarsi che sia scritto in un formato che un sistema automatizzato possa analizzare anche.

Classificare i log e usare log separati per registrare l'output di traccia da ogni aspetto operativo del sistema. Se si classificano i log, è possibile filtrare rapidamente i messaggi di log anziché elaborare 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.

Nota

Un log può essere implementato come file nel file system oppure può essere mantenuto in un altro formato, ad esempio un BLOB nell'archivio BLOB. Le informazioni sui log possono essere contenute anche nell'archiviazione strutturata, ad esempio le righe di una tabella.

Acquisire le metriche dell'applicazione

Le metriche, o i campioni, sono un conteggio di alcuni aspetti o risorse nel sistema in un momento specifico, con uno o più tag o dimensioni associati. Una singola istanza di una metrica non è utile in isolamento, le metriche devono essere acquisite nel tempo. Prendere in considerazione le metriche da registrare e la frequenza. I dati generati troppo spesso possono imporre un carico elevato nel sistema, ma l'acquisizione di dati poco frequente può causare la mancata esecuzione delle circostanze che causano un evento significativo. La frequenza appropriata per l'acquisizione dei dati può variare da metrica a metrica. Ad esempio, l'utilizzo della CPU in un server può variare significativamente da secondo a secondo, ma l'utilizzo elevato diventa un problema solo se è coerente in molti minuti.

Facilitare la correlazione tra i componenti

È 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. Alcuni monitoraggio richiedono la correlazione dei dati durante la fase di analisi e diagnostica nella pipeline di monitoraggio. Questi dati possono assumere diverse forme e il processo di analisi deve essere fornito con 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 completa tale attività.

È improbabile che sia presente una mappa 1:1 tra thread e richieste utente, perché le operazioni asincrone potrebbero riutilizzare gli stessi thread per più di un utente. Per complicare ulteriormente le cose, una singola richiesta può essere correlata a più thread mentre scorre attraverso il sistema. Se possibile, è consigliabile associare ogni richiesta a un ID attività univoco propagato attraverso il sistema nell'ambito del contesto della richiesta. La tecnica per la generazione e l'inserimento di ID attività nelle informazioni di traccia dipende dalla tecnologia usata per acquisire i dati di traccia.

Tutti i dati di monitoraggio devono riportare il timestamp nello stesso modo. Per coerenza, registrare tutte le date e le ore tramite Coordinated Universal Time.

Nota

I computer che operano in fusi orari e reti diversi potrebbero non essere sincronizzati. Evitare di affidarsi solo ai timestamp per la correlazione dei dati di strumentazione che si estendono su più computer.

Acquisire dati pertinenti

Quando si decide quali dati di strumentazione è necessario raccogliere, prendere in considerazione i punti seguenti.

Dati leggibili

Assicurarsi che le informazioni acquisite dagli eventi di traccia siano sia computer che leggibili. Adottare schemi ben definiti per queste informazioni per implementare l'elaborazione automatizzata dei dati di log nei sistemi e garantire coerenza per le operazioni e il personale tecnico che legge i log.

Includere le informazioni ambientali seguenti nei dati:

  • Ambiente di distribuzione
  • Computer di elaborazione
  • Dettagli del processo
  • Stack di chiamate

Investire nella tracciabilità e nella correlazione

Fornire contesto sufficiente, ad esempio un ID attività associato a un'istanza specifica di una richiesta, in modo che lo sviluppatore o l'amministratore possa determinare l'origine di ogni richiesta.

Il contesto dei dati può includere anche informazioni usate per correlare 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 direttamente o indirettamente un riferimento al cliente che ha causato la richiesta. Questo contesto fornisce informazioni utili sullo stato dell'applicazione nel momento in cui sono stati acquisiti i dati di monitoraggio.

Acquisire tutti i dati pertinenti

Registrare tutte le richieste e le località o le aree in cui vengono effettuate. È possibile usare queste informazioni per identificare gli hotspot specifici della posizione. Queste informazioni sono utili anche per stabilire se ripartizionare un'applicazione o i dati che questa usa.

Registrare e acquisire i dettagli delle eccezioni con attenzione. Le informazioni di debug critiche vengono spesso perse a causa di una gestione delle eccezioni insufficiente. Acquisire tutti i dettagli dell'eccezione generati dall'applicazione, incluse eventuali eccezioni interne o altre informazioni contestuali, ad esempio lo stack di chiamate, se possibile.

Cercare la coerenza dei dati

I dati coerenti consentono 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. I pacchetti di registrazione consentono di evitare la dipendenza dagli sviluppatori per adottare l'approccio in quanto implementano parti diverse del sistema.

Raccogliere dati, ad esempio il volume di input/output, il numero di richieste e la memoria, la rete e l'utilizzo della CPU, dai contatori delle prestazioni principali. Alcuni servizi di infrastruttura forniscono contatori delle prestazioni personalizzati, ad esempio:

  • Numero di connessioni a un database.
  • Frequenza delle transazioni.
  • Numero di transazioni riuscite o non riuscite.

Le applicazioni possono anche definire contatori delle prestazioni personalizzati.

Prendere in considerazione le dipendenze esterne

Registrare tutte le chiamate al servizio esterno. È possibile effettuare chiamate esterne a:

  • Sistemi di database.
  • Servizi Web.
  • Altri servizi a livello di sistema che fanno parte dell'infrastruttura.

Registrare informazioni sulla durata di ogni chiamata e sull'esito positivo o negativo della chiamata. Se possibile, acquisire informazioni su tutti i tentativi ed errori per eventuali errori temporanei.

Verificare la compatibilità del sistema di telemetria

In molti casi, le informazioni sulla strumentazione sono generate sotto forma di una serie di eventi e vengono passate a un sistema di telemetria separato per l'elaborazione e l'analisi. Un sistema di telemetria è in genere indipendente da qualsiasi applicazione o tecnologia specifica.

I sistemi di telemetria usano schemi definiti per analizzare le informazioni. 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 l'arrivo dei dati da diverse piattaforme e dispositivi. Uno schema comune deve includere campi rilevanti per tutti gli eventi di strumentazione, ad esempio:

  • Nome evento.
  • Ora evento.
  • Indirizzo IP del mittente.
  • Dettagli necessari per la correlazione degli eventi, tra cui:
    • ID utente
    • ID dispositivo
    • ID applicazione

Tenere presente che molti dispositivi possono generare eventi per la stessa applicazione, quindi lo schema non deve dipendere dal tipo di dispositivo. L'applicazione deve supportare la distribuzione di roaming o tra dispositivi. Lo schema può includere anche campi di dominio pertinenti per uno scenario specifico comune tra le applicazioni, ad esempio:

  • Informazioni sulle eccezioni.
  • Eventi di inizio e fine dell'applicazione.
  • Esito positivo o negativo delle chiamate API del servizio Web.

Stabilire campi di dominio che producono lo stesso set di eventi per creare un set di report e analisi comuni tra applicazioni. Potrebbe essere necessario configurare uno schema per contenere campi personalizzati per acquisire i dettagli degli eventi specifici dell'applicazione.

OpenTelemetry è una raccolta indipendente dal fornitore di API, SDK e altri strumenti. È possibile usare OpenTelemetry per instrumentare le applicazioni e generare dati di telemetria significativi in modo coerente tra i linguaggi. OpenTelemetry è indipendente dallo strumento, quindi è compatibile con molte piattaforme di osservabilità, tra cui offerte open source e commerciali. Microsoft sta adottando OpenTelemetry come strumento standard per la strumentazione.

Ottimizzare il codice di strumentazione

Nell'elenco seguente sono riepilogate le procedure consigliate per la strumentazione di un'applicazione distribuita in esecuzione nel cloud:

  • Semplificare i log per la lettura e l’analisi. Utilizzare la registrazione strutturata dove possibile.

  • Essere concisi e descrittivi nei messaggi di log.

  • Identificare l'origine del log.

  • Aggiungere informazioni sul timestamp durante la scrittura di ogni record di log.

  • Usare lo stesso fuso orario e lo stesso formato per tutti i timestamp.

  • Classificare i log e scrivere messaggi nella posizione appropriata.

  • Non rivelare informazioni riservate sul sistema o sulle informazioni personali sugli utenti. Eseguire lo scrub di queste informazioni prima della registrazione, ma mantenere tutti i dettagli pertinenti.

  • Registrare tutte le eccezioni critiche, ma consentire all'amministratore di attivare e disattivare la registrazione in base alle esigenze per un minor numero di eccezioni e avvisi.

  • Acquisire e registrare tutte le informazioni di logica di ripetizione. Questi dati sono utili per monitorare l'integrità temporanea del sistema.

  • Tracciare le chiamate di processo, ad esempio le richieste a servizi Web o a database esterni.

  • Non combinare i messaggi di log con requisiti di sicurezza diversi nello stesso file di log.

  • Assicurarsi che tutte le chiamate di registrazione siano operazioni fire-and-forget che non bloccano lo stato di avanzamento delle operazioni aziendali. Escludere gli eventi di controllo da questa regola perché sono fondamentali per l'azienda.

  • Assicurarsi che la registrazione sia estendibile e non abbia dipendenze dirette da una destinazione concreta.

  • Assicurarsi che tutte le registrazioni siano sicure e non attivino errori a catena.

  • Considerare la strumentazione come processo iterativo in corso ed esaminare regolarmente i log.

Usare la profilatura delle applicazioni

  • Implementare la profilatura solo quando necessario perché può imporre un sovraccarico significativo sul sistema. Usando la strumentazione, la profilatura registra un evento, ad esempio una chiamata al metodo, ogni volta che si verifica. Tuttavia, il campionamento registra solo gli eventi selezionati.

  • Le selezioni di profilatura possono essere basate sul tempo, ad esempio una volta ogni n secondi o basate sulla frequenza, ad esempio una volta ogni n richieste. Se gli eventi si verificano frequentemente, la profilatura potrebbe causare una quantità eccessiva di carico sul sistema e influire sulle prestazioni complessive. In questo caso, l'approccio di campionamento è preferibile. Se la frequenza degli eventi è bassa, tuttavia, il campionamento potrebbe perderli. In questo caso, la profilatura potrebbe essere l'approccio migliore.

Facilitazione di Azure

La strumentazione automatica è disponibile per molti tipi di applicazioni di Azure e locali monitorate con Application Insights. La funzione di strumentazione automatica configura automaticamente l'applicazione per fornire dati di telemetria avanzati ad Application Insights e offre un facile accesso alle esperienze, ad esempio il dashboard dell'applicazione e la mappa delle applicazioni. Per le piattaforme di hosting e i linguaggi di sviluppo supportati, vedere Ambienti, linguaggi e provider di risorse supportati.

Elenco di controllo per l'eccellenza operativa

Fare riferimento al set completo di raccomandazioni.

Elenco di controllo per l'eccellenza operativa