Azure Log Analytics: come raccogliere, interrogare e governare i log con Azure Monitor
Azure Log Analytics è lo strumento di Azure Monitor utilizzato per esplorare e interrogare i dati di log raccolti in uno o più Log Analytics workspace. Nel modello attuale di Microsoft, Log Analytics non va considerato come un prodotto di monitoraggio isolato: è la componente di analisi dei log di Azure Monitor, utilizzata per investigare eventi, costruire query KQL, alimentare alert e workbook e supportare scenari operativi e di sicurezza.
Per le aziende che utilizzano Microsoft Azure, il valore non è semplicemente “conservare i log”, ma costruire una pipeline controllata che stabilisca quali dati raccogliere, da quali risorse, con quale retention, con quali permessi e per quali casi d’uso.
Che cos’è Azure Log Analytics oggi
Log Analytics è l’interfaccia del portale Azure con cui si eseguono e si testano query sui dati archiviati in Azure Monitor Logs. Il repository che contiene i dati è il Log Analytics workspace: uno spazio logico composto da tabelle nelle quali confluiscono dati provenienti da risorse Azure, server, applicazioni e sorgenti esterne.
La distinzione è utile perché evita una confusione ancora frequente:
- Azure Monitor è il servizio complessivo di osservabilità e monitoraggio.
- Azure Monitor Logs è la piattaforma che raccoglie e gestisce i dati di log.
- Un Log Analytics workspace è l’archivio logico che contiene tabelle e dati.
- Log Analytics è lo strumento con cui si esplorano e interrogano questi dati, anche tramite KQL.
Questa architettura permette di usare gli stessi dati per analisi operative, troubleshooting, alerting, dashboard e scenari di sicurezza, mantenendo separati raccolta, archiviazione, accesso e interrogazione.
il workspace di azure log analytics. credits: www.petri.com
Architettura: workspace, tabelle, agenti e regole di raccolta
Un’implementazione moderna di Azure Monitor Logs parte dalla progettazione del workspace e della pipeline di ingestion. Non tutte le risorse devono inviare tutto: volume, criticità, frequenza, retention e finalità devono essere definiti prima di abilitare la raccolta su larga scala.
Log Analytics workspace
Il workspace organizza i dati in tabelle. Le impostazioni a livello di workspace e di tabella consentono di governare accesso, conservazione, modalità di utilizzo e costi. In ambienti articolati, la scelta tra un singolo workspace e più workspace deve tenere conto di tenant, segregazione amministrativa, compliance, regioni, ruoli operativi e utilizzo di servizi come Microsoft Sentinel.
Azure Monitor Agent e Data Collection Rules
Azure Monitor Agent (AMA) è l’agente corrente per la raccolta di dati da macchine Windows e Linux in Azure, on-premises e in altri cloud. La configurazione avviene tramite Data Collection Rules (DCR), che definiscono sorgenti, trasformazioni e destinazioni dei dati.
Il precedente Log Analytics Agent, noto anche come Microsoft Monitoring Agent (MMA) o OMS agent, è stato ritirato. Le infrastrutture che lo utilizzano ancora devono essere migrate ad Azure Monitor Agent: mantenere configurazioni legacy significa dipendere da un componente non più supportato e da un percorso di ingestion ormai dismesso.
Quali dati può raccogliere Azure Monitor Logs
A seconda dell’architettura e delle regole di raccolta, un workspace può centralizzare dati provenienti da sorgenti molto diverse. Tra i casi più comuni:
- macchine virtuali Windows e Linux e server gestiti tramite Azure Arc;
- Azure Activity Log e diagnostic settings delle risorse Azure;
- eventi Windows, Syslog e log applicativi;
- metriche e dati di performance necessari al troubleshooting;
- telemetria di servizi e applicazioni integrati con Azure Monitor;
- dati personalizzati acquisiti tramite pipeline e API di ingestion;
- dati utilizzati da servizi di sicurezza e da Microsoft Sentinel, quando il workspace viene abilitato per tali scenari.
La raccolta va progettata per caso d’uso. Inviare indiscriminatamente ogni evento aumenta rumore e costi senza necessariamente migliorare la capacità di troubleshooting o detection.
Interrogare i log con Kusto Query Language (KQL)
KQL è il linguaggio utilizzato da Azure Monitor Logs per interrogare i dati. Le query sono read-only e possono filtrare, aggregare, correlare e trasformare grandi volumi di eventi in risultati utilizzabili per analisi, alert e dashboard.
Un esempio semplice per verificare l’ultima telemetria ricevuta dalle macchine è:
Heartbeat |
Le query possono poi diventare la base per log search alert, workbook, investigazioni operative e automazioni. La qualità del risultato dipende però dalla qualità dei dati raccolti e dalla normalizzazione adottata nella fase di ingestion.
Alert, workbook e automazione operativa
Log Analytics non serve soltanto per interrogazioni manuali. Una query validata può essere riutilizzata per costruire controlli continuativi e rendere operativo il dato raccolto.
- Alert basati su query: notificano quando un pattern o una soglia soddisfa determinate condizioni.
- Azure Monitor Workbooks: trasformano query e metriche in viste operative e dashboard interattive.
- Action Groups: instradano notifiche e azioni verso email, SMS, webhook, Logic Apps o altri target supportati.
- Automazioni: integrano il risultato del monitoraggio con processi di risposta, ticketing e orchestrazione.
Costi, retention e controllo dell’ingestion
La precedente logica basata su un prezzo fisso “per GB” e su una retention standard unica non è più sufficiente per descrivere Azure Monitor Logs. Il costo effettivo dipende dal volume di dati ingeriti, dal piano delle tabelle, dalla retention scelta e dalle funzionalità utilizzate.
Per governare correttamente i costi è utile intervenire prima della fatturazione, cioè sulla progettazione della raccolta:
- raccogliere solo i log necessari ai casi d’uso definiti;
- usare DCR e trasformazioni per filtrare o trasformare i dati prima dell’ingestion quando appropriato;
- differenziare retention e modalità di utilizzo in base alla tipologia di tabella e al valore del dato;
- monitorare trend di ingestion, query e crescita del workspace;
- valutare export o retention di lungo periodo quando esistono requisiti di audit, integrazione o conservazione estesa.
Una buona progettazione riduce sia i costi sia il rumore operativo: più dati non significano automaticamente maggiore osservabilità.
Azure Log Analytics e Microsoft Sentinel
Microsoft Sentinel utilizza un Log Analytics workspace come una delle basi per la raccolta e l’analisi dei dati necessari alle attività SIEM. Abilitare Sentinel su un workspace non trasforma però ogni log operativo in un log di sicurezza: architettura, sorgenti, retention e costi vanno progettati in funzione dei casi d’uso SOC e delle esigenze di detection e investigation.
Per gli aspetti di hardening, logging e governance della piattaforma consulta anche Azure Security Best Practice. La pagina Log Analytics deve restare focalizzata su raccolta, interrogazione e gestione dei log.
Sicurezza e governance del workspace
Un workspace può contenere dati operativi e di sicurezza sensibili. La sua configurazione deve quindi includere controlli di accesso e governance coerenti con il modello organizzativo.
- RBAC e privilegi minimi per amministratori, operatori e analisti;
- segmentazione degli accessi ai dati quando reparti e ruoli hanno esigenze differenti;
- valutazione di isolamento di rete e accesso privato dove richiesto;
- retention coerente con necessità operative, contrattuali e di compliance;
- monitoraggio dell’utilizzo del workspace e delle modifiche alla configurazione;
- governo delle DCR per evitare raccolte duplicate, sovradimensionate o non documentate.
Checklist per una implementazione moderna di Azure Log Analytics
- Definire i casi d’uso: troubleshooting, performance, audit, security monitoring o più scenari distinti.
- Inventariare sorgenti e dati realmente necessari.
- Progettare workspace, accessi e retention prima dell’onboarding massivo.
- Utilizzare Azure Monitor Agent e Data Collection Rules per le macchine supportate.
- Validare l’ingestion e costruire query KQL ripetibili.
- Trasformare le query utili in alert, workbook e procedure operative.
- Misurare regolarmente ingestion, retention e costi.
- Documentare ownership, DCR, query critiche, alert e dipendenze con Microsoft Sentinel o altri servizi.
Quando serve una revisione dell’architettura di monitoraggio Azure
La revisione è particolarmente utile quando esistono più workspace senza una logica chiara, agenti legacy ancora attivi, costi di ingestion in crescita, retention incoerente, alert difficili da mantenere o una sovrapposizione tra monitoraggio operativo e SIEM.
Valuta la consulenza cloud per aziende di Nexsys per progettare o razionalizzare monitoraggio, governance e architettura Azure.
Formazione Azure per amministratori e team IT
Per gestire Azure Monitor, Log Analytics, identità, networking, compute, storage e governance è necessario comprendere l’architettura complessiva della piattaforma, non solo il singolo workspace.
Corso AZ-104 Microsoft Azure Administrator per sviluppare competenze operative sulla gestione di Microsoft Azure.
FAQ su Azure Log Analytics
Qual è la differenza tra Azure Monitor e Log Analytics?
Azure Monitor è il servizio complessivo di monitoraggio e osservabilità di Azure. Log Analytics è lo strumento del portale utilizzato per interrogare e analizzare i dati presenti in Azure Monitor Logs.
Che cos’è un Log Analytics workspace?
È un archivio dati organizzato in tabelle nel quale vengono raccolti log provenienti da risorse Azure e non Azure. Il workspace consente di governare accesso, retention, interrogazione e utilizzo dei dati.
Azure Log Analytics usa KQL?
Sì. Azure Monitor Logs utilizza Kusto Query Language (KQL) per filtrare, aggregare, correlare e analizzare i dati di log. Le query possono essere riutilizzate per alert, workbook e investigazioni.
Il vecchio Microsoft Monitoring Agent è ancora supportato?
No. Il Log Analytics Agent, noto anche come Microsoft Monitoring Agent (MMA) o OMS agent, è stato ritirato. Per i nuovi scenari di raccolta su macchine Windows e Linux va utilizzato Azure Monitor Agent con Data Collection Rules.
È possibile raccogliere log da server on-premises?
Sì. Azure Monitor Agent supporta anche scenari non Azure; per i server on-premises viene normalmente utilizzato insieme ad Azure Arc per rendere le macchine gestibili e indirizzabili dai servizi Azure.
Come si controllano i costi di Log Analytics?
I costi dipendono principalmente da ingestion, piano delle tabelle, retention e funzionalità utilizzate. La misura più efficace è progettare correttamente la raccolta, filtrare i dati non necessari e applicare retention coerenti con i casi d’uso.
Microsoft Sentinel usa Log Analytics?
Sì. Microsoft Sentinel utilizza un Log Analytics workspace per diversi scenari di raccolta e analisi SIEM. Quando un workspace viene utilizzato con Sentinel, architettura, dati e costi devono essere progettati tenendo conto dei casi d’uso di sicurezza.