Su AZ-400 il monitoraggio non è “installare un agente”: è decidere quale segnale serve a chi, dove atterra e cosa succede quando degrada. La differenza fra un ambiente strumentato e uno che raccoglie dati inutili sta nelle scelte di design: quale piano di raccolta per quale layer, dove porre il confine fra telemetria applicativa e di piattaforma, e in quale punto del rilascio il segnale diventa una decisione automatica. Diamo per acquisiti i meccanismi base e concentriamoci sui trade-off.

Dove atterra la telemetria e perché il confine conta

La prima decisione architetturale è la topologia dei workspace. Tutta la telemetria di Azure Monitor confluisce in due piattaforme di dati: metriche, ottimizzate per serie temporali dense e alert a bassa latenza, e log, archiviati in un Log Analytics workspace e interrogabili con KQL. Anche Application Insights archivia i propri dati in Log Analytics, quindi il workspace è di fatto il perimetro entro cui puoi fare join fra segnali diversi.

Questo è il trade-off dominante. Un workspace centralizzato rende banale correlare le eccezioni di un servizio con i log del cluster che lo ospita e con gli eventi di audit della piattaforma DevOps, ma obbliga a governare RBAC e retention a livello di tabella. Molti workspace per team o per ambiente danno isolamento e cost attribution naturali, al prezzo di query cross-workspace e dashboard più fragili. Regola di design: allinea i workspace ai confini di ownership e di retention, non a quelli di sottoscrizione.

La retention è parte della decisione: prolungarla oltre il default comporta costi aggiuntivi, e se il requisito è conservare gli audit oltre la finestra nativa del prodotto di origine la risposta è quasi sempre lo stream verso un workspace o uno storage esterno, non l’aumento della retention del prodotto.

Scegliere il piano di raccolta per ciascun layer

Azure Monitor offre piani di raccolta distinti perché rispondono a domande diverse. Sceglierne uno “in più” è ingestione sprecata; sceglierne uno “in meno” produce un punto cieco.

Livello applicativo: Application Insights. È lo strumento di APM. Fornisce viste su fallimenti, performance, ricerca telemetria e transaction diagnostics end-to-end, con il Gantt della singola transazione che attraversa più componenti, e supporta OpenTelemetry. La decisione di design tipica riguarda il campionamento: riduce costo e volume, ma le viste del portale mostrano solo ciò che è sopravvissuto al sampling, quindi se il requisito è “nessun evento perso” serve un percorso di log dedicato. Seconda decisione ricorrente: Cloud Role Name e Cloud Role Instance vanno impostati deliberatamente, perché sono la dimensione con cui filtri per servizio e per istanza in un’architettura a microservizi.

Livello macchina. Per le VM il segnale si divide in host metrics, raccolte automaticamente senza costo, e guest metrics e log, che richiedono l’Azure Monitor Agent e una data collection rule che dichiari cosa raccogliere e dove inviarlo. Il pattern di troubleshooting che l’esame premia è proprio questo salto di livello: parti dalle host metrics per capire quale macchina è sotto pressione, poi scendi nel guest per capire perché. Abilitare a scala si fa con IaC o Azure Policy, mai macchina per macchina.

Livello Kubernetes. Qui i piani sono complementari. Container Insights raccoglie, tramite una versione containerizzata dell’agente, i log stdout/stderr e gli eventi Kubernetes dai nodi, portandoli nel workspace. Le metriche cloud-native passano invece da Azure Monitor managed service for Prometheus, compatibile con PromQL e con gli alert Prometheus, tipicamente visualizzato con Azure Managed Grafana. I log del control plane sono resource log: servono una diagnostic setting per portarli nello stesso workspace. Il design corretto non è quindi “Container Insights oppure Prometheus”, ma log dai container, metriche da Prometheus, control plane via diagnostic setting, con le applicazioni sul cluster comunque strumentate con Application Insights.

Instrumentare il ciclo di rilascio, non solo il runtime

Il salto di livello richiesto a un DevOps engineer è legare la telemetria al deployment. Il meccanismo canonico sono le release annotation di Application Insights: marcatori che segnano i deployment sui grafici e permettono di correlare una regressione di performance con la release che l’ha introdotta. Azure Pipelines le crea automaticamente quando il deployment usa una delle task supportate e la risorsa target è collegata ad Application Insights tramite la connection string, nella stessa sottoscrizione. Quando il pipeline non usa quelle task, la scelta di design è uno script inline che chiama l’API delle annotation valorizzando metadata di build e release. Dettaglio che vale la sequenza: le annotation compaiono nelle viste Performance, Failures, Usage e nei workbook, ma non nel pannello Metrics.

Il secondo meccanismo è il deployment gate. Un gate raccoglie un segnale di salute esterno e decide se promuovere. Fra i gate disponibili di default c’è Query Azure Monitor alerts, che verifica la presenza di alert attivi sulle regole configurate, insieme a gate su funzioni, REST API, work item e compliance di Azure Policy. Il design sta nei parametri, non nel gate: il delay before evaluation deve coprire il tempo perché l’applicazione si stabilizzi e gli incidenti vengano registrati, l’intervallo di rievalutazione deve superare il tempo di risposta tipico del gate, il timeout definisce quando la release viene rifiutata. Tutti i gate devono risultare positivi nello stesso intervallo di campionamento.

Terzo meccanismo: portare gli eventi della piattaforma DevOps dentro la piattaforma di analisi. Azure DevOps supporta lo streaming degli audit log verso destinazioni tra cui Azure Monitor Logs, dove atterrano nella tabella AzureDevOpsAuditing, interrogabile e allertabile, con Microsoft Sentinel collegabile al workspace. L’auditing richiede un’organizzazione collegata a Microsoft Entra ID. Lato GitHub, l’audit log enterprise può essere trasmesso verso endpoint tra cui Azure Event Hubs e Azure Blob Storage. In entrambi i casi la motivazione di design è la stessa: superare la finestra di retention nativa e unificare la detection.

Insight e alert sul lato GitHub

GitHub espone una propria analitica, che non è telemetria applicativa e non va confusa con essa. A livello di repository trovi grafici tra cui Pulse, Contributors, Traffic, Commits, Code frequency e Network, con limitazioni sui repository molto grandi e differenze di disponibilità fra piani sui repository privati.

Per la pipeline la distinzione da tenere è fra le due famiglie di metriche Actions. Le usage metrics rispondono a “quanto consumiamo”: minuti per workflow, job, repository, sistema operativo del runner e tipo di runner. Le performance metrics rispondono a “quanto siamo efficaci”: tempi di esecuzione, tempi di coda e tassi di fallimento sulle stesse dimensioni. Se il requisito parla di costo o di capacità dei runner, la risposta sono le usage metrics; se parla di lead time, code o flakiness, sono le performance metrics. L’accesso a livello di organizzazione richiede il permesso dedicato, concedibile via ruolo personalizzato.

Per l’alerting cross-piattaforma il ponte è l’action group di Azure Monitor, che separa nettamente notifiche (tra cui email, SMS, voce e push) da azioni automatiche (tra cui webhook, secure webhook, Azure Functions, Logic Apps, Event Hubs, runbook e ITSM). Quando il requisito è “l’alert deve creare un ticket o innescare una remediation”, la risposta non è la notifica ma l’azione, e la scelta fra webhook e Logic Apps si gioca sulla necessità di trasformare lo schema del payload verso il formato atteso dal destinatario.

Trappole tipiche d’esame

  • “Correlare un degrado di latenza con la release che lo ha causato” → release annotation di Application Insights, automatiche con le task Azure Pipelines supportate o via script inline; ricorda che non compaiono nel pannello Metrics.
  • “Bloccare la promozione a produzione se ci sono alert attivi” → gate Query Azure Monitor alerts in post-deployment, con delay di stabilizzazione adeguato e timeout esplicito, non un’approvazione manuale.
  • “Servono i log dei container e le metriche del cluster in un unico posto” → Container Insights per i log, managed Prometheus per le metriche, diagnostic setting per i log del control plane; non un solo strumento per tutto.
  • “Conservare gli eventi di audit oltre la finestra nativa e allertarci sopra” → audit streaming verso Azure Monitor Logs e query sulla tabella AzureDevOpsAuditing; lato GitHub, streaming verso Event Hubs o Blob Storage.
  • “Capire quali workflow ci costano più minuti” → usage metrics di GitHub Actions; le performance metrics servono per code e failure rate, non per il costo.
  • “L’alert deve aprire un ticket nel sistema ITSM” → action group con azione ITSM o Logic Apps, non un semplice destinatario email.
  • “Individuare quale VM è satura e poi la causa nel sistema operativo” → host metrics per la selezione, poi Azure Monitor Agent e data collection rule per guest metrics e log; abilitazione a scala via IaC o Azure Policy.