Microsoft AZ-400: Monitoraggio, osservabilità e feedback — Guida allo studio

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

Fa parte della Microsoft DevOps Engineer Expert AZ-400 — Guida allo studio. Esercitati con risposte verificate nel centro esami Microsoft, oppure fai test cronometrati su ExamRoll.io.

Panoramica

I team DevOps moderni trattano il monitoraggio, l’osservabilità e il feedback come un ciclo continuo che guida le decisioni di ingegneria, operative e di prodotto. In Azure, la telemetria fluisce dalle applicazioni e dall’infrastruttura verso Azure Monitor e Log Analytics, dove viene interrogata, correlata e visualizzata. Il tracciamento distribuito lega i servizi in transazioni end-to-end, mentre gli avvisi e le integrazioni per la reperibilità (on-call) favoriscono una rapida risoluzione (remediation). Le dashboard di Azure DevOps, l’analisi degli elementi di lavoro e la sperimentazione chiudono il cerchio, fornendo insight che rientrano nella pianificazione e nella delivery. Questa sezione fornisce l’approfondimento necessario per progettare uno stack di osservabilità integrato che offra feedback utilizzabili (actionable) in ogni fase.

Telemetria, Tracciamento e Azure Monitor

Application Insights è il componente di Application Performance Monitoring (APM) di Azure Monitor. La strumentazione viene aggiunta tramite:

SDK e strumentazione automatica: .NET/.NET Core, Java, JavaScript, Node.js, Python e l’Application Insights Agent per .NET e Java. Utilizzare una stringa di connessione e impostare cloud_RoleName per distinguere i componenti.
Inizializzatori ed elaboratori di telemetria: aggiungono o modificano proprietà (es. tenantId) e filtrano le PII (Personally Identifiable Information) prima dell’invio.
Telemetria personalizzata: TrackEvent per azioni di business, TrackMetric per KPI numerici, TrackException per contesti di errore e TrackDependency per chiamate esterne che è necessario modellare esplicitamente.

I tipi di telemetria includono richieste, dipendenze (HTTP, SQL, Azure SDK), tracce, eccezioni, visualizzazioni di pagina, prestazioni di caricamento delle pagine, risultati dei test di disponibilità, eventi/metriche personalizzati e metriche in tempo reale (live metrics). Il campionamento (sampling) controlla il volume e i costi preservando il segnale: il campionamento adattivo dell’SDK regola automaticamente le frequenze per tipo per mantenere il throughput e la correlazione target; il campionamento a frequenza fissa fornisce un campionamento deterministico per la conformità. Preferire il campionamento lato SDK in modo che i sistemi a valle non elaborino mai gli elementi scartati. Mantenere il campionamento “sticky” per l’integrità delle tracce end-to-end.

Il tracciamento distribuito fornisce visibilità sulle transazioni end-to-end. Application Insights implementa lo standard W3C Trace-Context (traceparent/tracestate), propagando automaticamente gli ID di correlazione attraverso HTTP; propagare il contesto attraverso i confini asincroni e i protocolli personalizzati per evitare tracce interrotte. Il tracciamento delle dipendenze raccoglie automaticamente le chiamate in uscita comuni; emettere dipendenze personalizzate per i salti nelle code di messaggi o per RPC non standard per completare il grafo delle chiamate. App Map e Transaction Search visualizzano i flussi tra servizi, le latenze e gli hotspot di errore. Per la correlazione tra front-end e back-end, abilitare l’SDK JavaScript e assicurarsi che gli header di correlazione lato server siano accettati per misurare i tempi di caricamento reali delle pagine e i percorsi utente.

Azure Monitor unifica la telemetria della piattaforma e delle applicazioni:

Metriche: multidimensionali, quasi in tempo reale (granularità di un minuto o migliore). Utilizzare avvisi sulle metriche (metric alerts) con soglie statiche o dinamiche per rilevamenti rapidi e a bassa latenza.
Log: telemetria semi-strutturata in un’area di lavoro Log Analytics, interrogata con KQL per analisi approfondite e ricerca di anomalie (anomaly hunting).
Avvisi: le regole su metriche, log e log attività vengono instradate ai gruppi di azioni. Utilizzare soglie dinamiche, targeting multi-risorsa e uno schema di avviso comune per una gestione coerente.
Gruppi di azioni: e-mail/SMS/voce, notifiche push, webhook (inclusi PagerDuty/OpsGenie), connettori ITSM, Logic Apps, Azure Functions e runbook di Automation per la remediation.
Impostazioni di diagnostica: configurare ogni risorsa di Azure per inviare in streaming le metriche/log della piattaforma a Log Analytics, Azure Storage (per l’archiviazione) ed Event Hubs (per l’ingestione in sistemi SIEM). Garantire la coerenza con una distribuzione basata su policy.

Interrogazioni e Analisi con Log Analytics (KQL)

Un’area di lavoro Log Analytics è il confine di interrogazione e governance per i log. Pianificare in base all’ambiente e alla sovranità dei dati: aree di lavoro separate per produzione e non produzione possono semplificare le policy di RBAC e di conservazione (retention); la centralizzazione facilita la correlazione tra servizi. Le origini dati includono Azure Diagnostics (log/metriche di piattaforma), agenti VM (eventi Syslog/Windows, contatori delle prestazioni), Container Insights/AKS, log dei componenti di Application Insights (unificati sotto Azure Monitor Logs), accessi ad Azure AD, log personalizzati tramite API di ingestione e Data Collection Rules per un instradamento e una trasformazione precisi dei flussi.

Il Kusto Query Language (KQL) è ottimizzato per l’analisi di serie temporali e telemetria:

Operatori principali: where (filtra), project (seleziona), extend (deriva), summarize by (aggrega), join/union (correla), parse/parse_json (estrae), mv-expand (array), make-series e bin per il raggruppamento temporale (time bucketing), render per la creazione di grafici.
Pattern: consumo del budget di errore (error budget burn, tassi di fallimento ponderati nel tempo), distribuzioni di latenza p50/p95, rilevamento di outlier nelle dipendenze, tasso di successo delle richieste rispetto al traffico e rilevamento di anomalie tramite series_decompose_anomalies per avvisi consapevoli della stagionalità.
Governance: query e funzioni salvate promuovono il riutilizzo; RBAC e accesso a livello di tabella limitano l’accesso a set di dati sensibili.
Interrogazioni tra risorse e aree di lavoro: utilizzare workspace("workspaceNameOrId").Table e la funzione workspaces() per combinare set di dati tra ambienti e sottoscrizioni; utilizzare resource() per join tra risorse. Applicare i let binding e materialize() per controllare le prestazioni su join di grandi dimensioni.

Visualizzazione e Feedback Agile in Azure DevOps

Le dashboard in Azure DevOps comunicano lo stato di salute sia operativo che di processo. Le dashboard a livello di team si concentrano sul backlog, le iterazioni e il WIP di un team; le dashboard a livello di progetto mostrano viste trasversali ai team e di portfolio. I widget includono Sprint Burndown, Burnup, Velocity, Cumulative Flow Diagram (CFD), Cycle Time, Lead Time, Work Item Chart/Query Results, riepiloghi di Build/Release e Markdown per i runbook e lo stato degli SLO. Proteggi i widget con le autorizzazioni della dashboard e definisci l’ambito delle query in modo rigoroso per team/aree per evitare la fuga di informazioni tra team.

Le query di Boards (tramite il query builder o WIQL) alimentano molti widget. Parametrizza le query per area path/iterazione del team per il riutilizzo; preferisci i widget basati su Analytics quando disponibili per accuratezza e prestazioni. Metriche di flusso chiave:

Cycle time: Tempo trascorso dallo stato Active (in corso) a Done; utilizza il widget Cycle Time per monitorare l’efficienza dell’esecuzione.
Lead time: Tempo trascorso dalla creazione/impegno a Done; segnala il ritardo totale del sistema percepito dai clienti.
Throughput: Elementi completati per intervallo di tempo; confronta con le policy di WIP per individuare i colli di bottiglia.
Cumulative Flow Diagram: Visualizza le dimensioni delle code per stato nel tempo; le bande che si allargano espongono vincoli e context-switching. Per il tracciamento degli sprint, usa il Burndown (tendenza del lavoro rimanente verso lo zero) e il Burnup (ambito totale vs completato, resiliente ai cambiamenti di ambito). La Velocity riporta lo sforzo medio completato per sprint e supporta la pianificazione della capacità (capacity planning); aggrega solo unità di stima omogenee tra i team.

Dove è necessaria l’analisi di prodotto, collega Azure DevOps Analytics a Power BI per unire le metriche di delivery con la telemetria operativa (ad es., lead time vs defect escape rate) per dare priorità ai miglioramenti.

← Strategia di test e ingegneria della qualità · Tutti i domini · Gestione dei pacchetti e gestione degli artefatti →

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