Microsoft AZ-204: Monitoraggio, Diagnostica e Integrazione DevOps di Azure — Guida allo studio

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

Fa parte della Microsoft Azure Developer Associate AZ-204 — Guida allo studio. Esercitati con risposte verificate nel centro esami Microsoft, oppure fai test cronometrati su ExamRoll.io.

Panoramica

Azure Monitor e Application Insights forniscono uno stack di osservabilità unificato e incentrato sugli sviluppatori per le applicazioni Azure. Application Insights raccoglie la telemetria dell’applicazione come richieste, dipendenze, eccezioni e tracce, mentre Azure Monitor aggrega metriche e log da tutte le risorse in un’area di lavoro Log Analytics e gestisce gli avvisi e le integrazioni DevOps. Padroneggiare le scelte di strumentazione, la semantica della telemetria, i test di disponibilità, il Kusto Query Language (KQL), gli avvisi con i gruppi di azioni, il tracciamento distribuito e l’Infrastructure as Code con i modelli ARM garantisce soluzioni affidabili, diagnosticabili e automatizzabili.

Strumentazione e telemetria di Application Insights

Le risorse di Application Insights vengono identificate per l’ingestion tramite una chiave di strumentazione (instrumentation key) o una stringa di connessione (connection string). La chiave di strumentazione è il GUID singolo legacy utilizzato dagli SDK per instradare la telemetria. La stringa di connessione è la raccomandazione attuale; include la chiave di strumentazione più i metadati degli endpoint (endpoint di ingestion e di Live Metrics) e consente l’instradamento verso endpoint non predefiniti (per cloud sovrani o privati). Utilizzare la stringa di connessione nel nuovo codice e nella configurazione; essa consente future modifiche agli endpoint senza dover ridistribuire il codice. All’interno di un App Service, abilitando Application Insights a livello di piattaforma, la stringa di connessione verrà inserita nelle impostazioni di ambiente per i runtime rilevati automaticamente.

La strumentazione può essere eseguita tramite SDK o auto-strumentazione. L’approccio SDK (ad esempio, Microsoft.ApplicationInsights.AspNetCore per .NET, applicationinsights per Node.js e l’agente Java di Application Insights) offre un controllo a livello di codice: eventi personalizzati, metriche e telemetria arricchita tramite TelemetryInitializers e processori, incluso il campionamento adattivo. L’auto-strumentazione (collegamento senza codice) è disponibile per App Service e alcuni stack di calcolo e utilizza estensioni/agenti del sito per raccogliere richieste in ingresso, dipendenze ed eccezioni senza modifiche al codice. Utilizzare la strumentazione SDK quando si necessita di eventi personalizzati, metriche di business o correlazione esplicita nei processi in background; utilizzare il collegamento senza codice per una visibilità rapida e a basso sforzo o per carichi di lavoro di tipo lift-and-shift. In entrambi i casi, impostare il nome del ruolo cloud per distinguere i servizi in un’architettura a microservizi e configurare attentamente il campionamento per bilanciare fedeltà e costi.

Application Insights emette diversi tipi di telemetria principali:

Le Richieste (Requests) acquisiscono le operazioni in ingresso (richieste HTTP, invocazioni di funzioni), con durata, codice di risposta e successo.
Le Dipendenze (Dependencies) acquisiscono le chiamate in uscita (HTTP, SQL, chiamate Azure SDK, code), con destinazione, tipo, durata e successo.
Le Eccezioni (Exceptions) acquisiscono gli errori generati, le tracce dello stack e le eccezioni gestite quando tracciate esplicitamente.
Le Tracce (Traces) acquisiscono i messaggi di log; gli SDK si integrano con i framework di logging più diffusi, in modo che log e telemetria condividano la correlazione.
Gli Eventi (Events) acquisiscono occorrenze personalizzate a livello di business tramite TrackEvent, supportando dimensioni e conteggi personalizzati.
Le Metriche (Metrics) acquisiscono misurazioni numeriche; è possibile tracciare metriche personalizzate per i KPI e ispezionarle in Metrics Explorer.

Il tracciamento distribuito in Application Insights si basa sulla correlazione. Ogni operazione end-to-end ha un ID operazione (trace ID in termini W3C) condiviso tra la telemetria correlata; ogni span ha relazioni padre-figlio applicate tramite gli header di propagazione. Gli SDK moderni utilizzano il W3C Trace Context (traceparent, tracestate). Operation_Id in KQL collega Richieste, Dipendenze, Eccezioni e Tracce per la stessa transazione. Assicurarsi che i client HTTP in uscita propaghino gli header; per .NET, System.Diagnostics.Activity e l’SDK di AI gestiscono questo automaticamente. Il tracciamento delle dipendenze strumenta i client comuni (HTTP, SQL, Service Bus, Storage). Quando i servizi attraversano i confini (ad es. da App Service ad AKS), una propagazione coerente produce una singola mappa delle transazioni connessa. Per i flussi asincroni e basati su messaggi, assicurarsi che gli SDK acquisiscano e trasmettano gli ID di correlazione nei metadati dei messaggi; la maggior parte degli SDK di Azure lo fa per impostazione predefinita.

Test di disponibilità e monitoraggio sintetico

I test di disponibilità convalidano la raggiungibilità esterna e la reattività da più aree geografiche. Il test di ping dell’URL invia richieste HTTP a una frequenza configurata da più località di test e convalida i codici di stato, lo stato SSL e la corrispondenza facoltativa dei contenuti. Utilizzare tentativi e più località per ridurre i falsi positivi e configurare avvisi sui fallimenti dei test per notifiche operative.

I test di disponibilità multi-passo eseguivano storicamente sequenze registrate di richieste HTTP con cookie stateful per verificare i flussi di lavoro. I test web multi-passo classici sono stati ritirati; per scenari multi-richiesta o autenticati, implementare test sintetici strumentando il proprio client o servizio utilizzando l’API TrackAvailability (o gli esportatori OpenTelemetry) per emettere AvailabilityTelemetry. Questo approccio consente l’autenticazione personalizzata, i payload e la validazione specifica del dominio, mantenendo al contempo il reporting e gli avvisi centralizzati.

TrackAvailability personalizzato offre il controllo su:

Nome del test, località di esecuzione e identificatori di sequenza per l’analisi delle tendenze e la deduplicazione.
Semantica della durata e del successo basata sulle proprie convalide, non solo sullo stato HTTP.
Messaggi dettagliati e dimensioni personalizzate per suggerimenti sulla causa principale e correlazione con la telemetria di backend.

Combinare i test di disponibilità con la telemetria delle dipendenze e delle richieste di backend per distinguere rapidamente i problemi di disponibilità degli endpoint (rete, DNS, TLS) dai fallimenti dell’applicazione (eccezioni, timeout) e dalle interruzioni a valle (SQL, API esterne). Collegare i fallimenti dei test di disponibilità ai gruppi di azioni per avviare i flussi di lavoro di gestione degli incidenti.

Dati di Azure Monitor, KQL e avvisi con gruppi di azioni

Azure Monitor acquisisce due tipi di dati principali: metriche e log. Le metriche sono serie temporali numeriche e leggere, con acquisizione quasi in tempo reale e suddivisione multidimensionale (ad es. per istanza, route API). Sono ideali per il rilevamento rapido (CPU, memoria, tasso di richieste, latenza, disponibilità) e supportano una conservazione predefinita fino a 93 giorni. I log sono record strutturati e interrogabili, archiviati in un’area di lavoro Log Analytics, e includono dati di Application Insights, log delle risorse della piattaforma e log personalizzati con conservazione configurabile. Utilizzare le impostazioni di diagnostica (Diagnostic settings) per instradare le metriche della piattaforma e i log delle risorse verso un’area di lavoro, un Event Hub o un account di archiviazione (Storage) per l’archiviazione e l’analisi.

Il Kusto Query Language (KQL) è alla base dell’analisi esplorativa, dei dashboard e degli avvisi sui log. I pattern principali includono:

Query di base: Table | take 10 per un campionamento rapido; limitare sempre l’intervallo di tempo con where TimeGenerated >= ago(…) all’inizio della query per migliorare le prestazioni.
Filtro e proiezione: Table | where Column == “Value” | project KeyColumns per ridurre il payload e focalizzare l’analisi.
Aggregazione: summarize count() by bin(TimeGenerated, 5m), Dimension per calcolare tassi, percentili o medie; usare percentile() e make-series per i grafici temporali.
Join: join kind=inner o leftouter su chiavi di correlazione come operation_Id per collegare Requests con Dependencies o Exceptions; per i join tra risorse diverse (cross-resource), assicurarsi che entrambe inviino i dati alla stessa area di lavoro o abilitare le query tra risorse.
Tabelle utili: requests, dependencies, exceptions, traces, availabilityResults per Application Insights; AzureDiagnostics e AzureActivity per i log della piattaforma; Perf e Heartbeat per VM insights.
Best practice: proiettare solo le colonne necessarie, filtrare all’inizio, usare bin su intervalli ragionevoli ed evitare costosi cross-join su ampie finestre temporali se non strettamente necessario.

Il sistema di avvisi copre sia le metriche che i log. Gli avvisi sulle metriche (Metric alerts) valutano le soglie delle metriche quasi in tempo reale, supportano le dimensioni e la suddivisione per dimensione, e possono usare soglie statiche o dinamiche (basate su baseline di ML). Sono stateful e possono attivarsi e risolversi automaticamente in base ai risultati della valutazione, producendo una sola notifica quando lo stato cambia. Gli avvisi sui log (Log alerts o scheduled query alerts) eseguono query KQL a una cadenza prestabilita e si attivano in base ai risultati della query (numero di corrispondenze o soglie su una misura). Utilizzare gli avvisi sui log quando le condizioni dipendono da pattern complessi che coinvolgono più tabelle o richiedono analisi del testo. Gli avvisi di Smart Detection e di anomalia in Application Insights possono evidenziare regressioni senza bisogno di soglie esplicite.

I gruppi di azioni (Action groups) definiscono set di risposte riutilizzabili per gli avvisi. I tipi di notifica includono e-mail, SMS, chiamate vocali e notifiche push sull’app mobile di Azure. Le integrazioni includono:

Webhook (v1 e v2) con Common Alert Schema per payload coerenti; impostare header personalizzati per l’autenticazione e instradare verso sistemi di gestione degli incident (es. PagerDuty o ricevitori personalizzati).
Azure Functions, Logic Apps e runbook di Automation per la remediation programmatica e l’arricchimento dei dati; usare Logic Apps per trasformazioni flessibili e connettori.
Connettori ITSM (es. ServiceNow) per aprire incident con campi mappati. Associare i gruppi di azioni a regole di elaborazione degli avvisi (alert processing rules) per sopprimerli durante la manutenzione, instradarli per gravità o applicare azioni dinamiche. Per la sicurezza dei webhook in uscita, limitare il ricevitore agli IP di Azure o richiedere firme/header e validare le proprietà del Common Alert Schema come Essentials.AlertRule e AlertContext.

Template ARM per monitoraggio e distribuzione ripetibile

I template di Azure Resource Manager (ARM) definiscono in modo dichiarativo le risorse e la configurazione del monitoraggio come codice. La struttura di un template include:

$schema e contentVersion per identificare la versione del template.
parameters per i valori esternalizzati (es. nomi dei workspace, località, SKU). Utilizzare secureString/secureObject per i segreti.
variables per i valori calcolati per evitare ripetizioni.
resources per la distribuzione dichiarativa di Application Insights, workspace di Log Analytics, regole di avviso, gruppi di azioni e impostazioni di diagnostica.
outputs per emettere valori come la connectionString di Application Insights per le fasi di distribuzione a valle.

Utilizzare template collegati o annidati per comporre distribuzioni complesse. Una risorsa di distribuzione (Microsoft.Resources/deployments) fa riferimento a un template figlio tramite templateLink (URI esterno) o lo incorpora inline. Passare oggetti di parametri tramite parameters o parametersLink, definire dependsOn per l’ordinamento e riutilizzare i moduli tra i vari ambienti. Esempi di monitoraggio “by default” tramite ARM:

Distribuire un workspace di Log Analytics e impostare gli output workspaceResourceId utilizzati dalle risorse di Application Insights (modalità basata su workspace).
Creare Application Insights (basato su workspace) ed emettere in output la sua connectionString; evitare di esporre le chiavi di strumentazione legacy.
Abilitare le impostazioni di diagnostica (Diagnostic settings) sulle risorse (es. App Service, Key Vault, Storage) per trasmettere log e metriche al workspace e/o a Event Hub.
Effettuare il provisioning di avvisi sulle metriche (microsoft.insights/metricAlerts) con criteri e dimensioni, e di avvisi su query pianificate (microsoft.insights/scheduledQueryRules) con KQL, collegando i gruppi di azioni tramite ID di risorsa.
Definire gruppi di azioni (microsoft.insights/actionGroups) con destinatari email/SMS e webhook; parametrizzare indirizzi ed endpoint per un instradamento specifico per ambiente.

Adottare condizioni e cicli di copia (copy loops) per distribuzioni scalabili (es. applicare le impostazioni di diagnostica a un set di ID di risorsa). Utilizzare funzioni ARM come resourceId, subscriptionResourceId, reference, concat e guid per costruire riferimenti dinamici e nomi stabili. Mantenere la configurazione della telemetria coerente tra i servizi centralizzando le convenzioni sui nomi dei ruoli e il campionamento nelle impostazioni dell’app fornite tramite ARM o risorse di configurazione di App Service.

Scenario pratico

Adobe necessita di osservabilità end-to-end per una nuova pipeline di elaborazione multimediale multi-regionale basata su API di Azure App Service e microservizi AKS. Richiedono il rilevamento rapido di regressioni di latenza, il tracciamento distribuito tra i servizi, controlli proattivi di disponibilità per gli endpoint pubblici e l’instradamento automatizzato degli incident al loro sistema di reperibilità, con la ripetibilità garantita dall’infrastructure-as-code.

Strumentare i servizi con Application Insights utilizzando le stringhe di connessione

Configurare ogni carico di lavoro di App Service e AKS per utilizzare la stringa di connessione (connection string) di Application Insights anziché le chiavi legacy, garantendo endpoint di inserimento corretti e un instradamento a prova di futuro. Impostare i nomi dei ruoli cloud (cloud role names) per ogni servizio per abilitare filtri e mappe chiari. Scegliere la strumentazione basata su SDK nelle API principali per emettere eventi di dominio e metriche; abilitare il collegamento senza codice (codeless attach) per i servizi ausiliari per accelerare la copertura. Perché: Le stringhe di connessione consentono flessibilità sugli endpoint; gli SDK forniscono telemetria personalizzata mentre il collegamento senza codice (codeless attach) mantiene basso il costo di adozione.

Abilitare il tracciamento distribuito e il rilevamento delle dipendenze

Assicurarsi che i client HTTP in uscita e gli SDK di Azure propaghino il contesto di traccia W3C; verificare la continuità dell’operation_Id in KQL. Per i flussi di messaggi in background (Service Bus), confermare che la correlazione sia iniettata ed estratta dagli SDK; integrare con TelemetryInitializers dove vengono utilizzate intestazioni personalizzate. Perché: Una propagazione coerente della traccia produce una latenza end-to-end accurata e un’attribuzione dei fallimenti corretta tra i microservizi.

Implementare test di disponibilità e controlli sintetici personalizzati

Configurare test di ping degli URL (URL ping tests) per le API pubbliche da più aree geografiche con una corrispondenza del contenuto (content match) su un endpoint di integrità leggero. Per i flussi autenticati (acquisizione di token e invio di media), implementare un client sintetico che chiama il flusso di lavoro ed emette risultati TrackAvailability con la località di esecuzione e messaggi dettagliati. Perché: I ping degli URL forniscono una verifica esterna rapida; TrackAvailability supporta flussi di business complessi e autenticati che vanno oltre i semplici ping.

Centralizzare i dati in un workspace di Log Analytics e instradare i log della piattaforma

Distribuire un workspace e configurare le impostazioni di diagnostica (Diagnostic settings) su App Services, sui log del control plane di AKS, su Key Vault e su Storage per trasmettere log e metriche nel workspace. Assicurarsi che le risorse di Application Insights siano basate su workspace per unificare le query. Perché: Un singolo workspace abilita query KQL tra servizi, unendo richieste, dipendenze e log della piattaforma per un’indagine olistica.

Creare avvisi su metriche e log con gruppi di azioni

Definire avvisi sulle metriche (metric alerts) sui percentili di durata delle richieste e sulla disponibilità per località con soglie dinamiche, suddividendo per nome del ruolo cloud. Aggiungere avvisi su query pianificate (scheduled query alerts) che rilevano picchi di errori per nome dell’operazione e li correlano con fallimenti delle dipendenze utilizzando un join KQL su operation_Id. Perché: Gli avvisi sulle metriche forniscono un rilevamento quasi in tempo reale; gli avvisi sui log catturano pattern complessi non esprimibili come semplici soglie.

Integrare la risposta agli incident tramite gruppi di azioni e webhook

Configurare un gruppo di azioni con email per i proprietari dei servizi, SMS per i responsabili della reperibilità e un webhook sicuro verso la piattaforma di incident di Adobe utilizzando il Common Alert Schema. Aggiungere un destinatario Logic App per arricchire i payload con i risultati di query KQL recenti e metadati sulla topologia. Perché: Le notifiche multicanale riducono l’MTTA; webhook e Logic App abilitano il ticketing automatizzato e la creazione di incident ricchi di contesto.

Codificare il monitoraggio con i template ARM

Creare template ARM per distribuire il workspace di Log Analytics, Application Insights (basato su workspace), le impostazioni di diagnostica, gli avvisi sulle metriche, gli avvisi su query pianificate e i gruppi di azioni. Parametrizzare i nomi degli ambienti, le regioni e i punti di contatto; emettere in output la connectionString di Application Insights per la configurazione a valle delle applicazioni. Utilizzare template collegati per i moduli di proprietà dei team (piattaforma vs. applicazione). Perché: L’infrastructure-as-code garantisce un’osservabilità coerente e ripetibile tra gli ambienti di sviluppo, staging e produzione e supporta la CI/CD.

Convalidare con dashboard KQL

Costruire dashboard utilizzando KQL che riepilogano la latenza per servizio (riepilogare i percentili per bin e ruolo), i tassi di errore uniti con le destinazioni delle dipendenze e la disponibilità sintetica per località. Incorporare filtri per intervalli di tempo e funzionalità di drill-through per accedere a tracce ed eccezioni. Perché: KQL fornisce analisi flessibili e visualizzazioni utili all’azione per i team di ingegneria e operations.

← Caching · Tutti i domini

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →