Condividi tramite

Migliori pratiche per i log di Azure Monitor

Questo articolo fornisce le procedure consigliate per l'architettura per i log di Monitoraggio di Azure. Le linee guida si basano sui cinque pilastri dell'eccellenza dell'architettura descritti in Azure Well-Architected Framework.

Affidabilità

Resilienza si riferisce alla capacità di un sistema di correggere gli errori e continuare a funzionare. L'obiettivo è ridurre al minimo gli effetti di un singolo componente con errori. Usare le informazioni seguenti per ridurre al minimo l'errore delle aree di lavoro Log Analytics e proteggere i dati raccolti.

Le aree di lavoro Log Analytics offrono un elevato livello di affidabilità. La pipeline di inserimento, che invia i dati raccolti all'area di lavoro Log Analytics, verifica che l'area di lavoro Log Analytics elabori correttamente ogni record di log prima di rimuovere il record dalla pipe. Se la pipeline di inserimento non è disponibile, gli agenti inviano il buffer dei dati e riprovano a inviare i log per molte ore.

Funzionalità dei log di Monitoraggio di Azure che migliorano la resilienza

I log di Monitoraggio di Azure offrono diverse funzionalità che migliorano la resilienza delle aree di lavoro a vari tipi di problemi. È possibile usare queste funzionalità singolarmente o in combinazione, a seconda delle esigenze.

Questo video offre una panoramica delle opzioni di affidabilità e resilienza disponibili per le aree di lavoro Log Analytics:

Protezione nell'area usando le zone di disponibilità

Ogni area di Azure che supporta le zone di disponibilità include un set di data center dotati di potenza, raffreddamento e infrastruttura di networking.

Le zone di disponibilità dei log di Monitoraggio di Azure sono ridondanti, il che significa che Microsoft distribuisce le richieste di servizio e replica i dati tra zone diverse nelle aree supportate. Se un evento imprevisto interessa una zona, Microsoft usa automaticamente una zona di disponibilità diversa nell'area. Non è necessario eseguire alcuna azione perché il passaggio tra le zone è facile.

Nella maggior parte delle aree, le zone di disponibilità dei log di Monitoraggio di Azure supportano resilienza dei dati, il che significa che i dati archiviati sono protetti da perdite di dati correlate a errori di zona, ma le operazioni del servizio potrebbero comunque essere interessate da eventi imprevisti a livello di area. Se il servizio non è in grado di eseguire query, non è possibile visualizzare i log finché il problema non viene risolto.

Un sottoinsieme delle zone di disponibilità che supportano la resilienza dei dati supporta anche la resilienza dei servizi, il che significa che le operazioni del servizio log di Azure Monitor - ad esempio l'inserimento dei log, le query e gli avvisi - possono continuare in caso di errore di zona.

Le zone di disponibilità proteggono da eventi imprevisti correlati all'infrastruttura, ad esempio errori di archiviazione. Non proteggono da problemi a livello di applicazione, ad esempio distribuzioni di codice difettoso o errori di certificato, che influiscono sull'intera area.

Backup dei dati da tabelle specifiche tramite l'esportazione continua

È possibile esportare continuamente i dati inviati a tabelle specifiche nell'area di lavoro Log Analytics negli account di archiviazione di Azure.

L'account di archiviazione in cui si esportano i dati deve trovarsi nella stessa area dell'area di lavoro Log Analytics. Per proteggere e avere accesso ai log inseriti, anche se l’area dell'area di lavoro è inattiva, usare un account di archiviazione con ridondanza geografica, come illustrato in Raccomandazioni di configurazione.

Il meccanismo di esportazione non fornisce protezione dagli eventi imprevisti che influisce sulla pipeline di inserimento o sul processo di esportazione stesso.

Annotazioni

È possibile accedere ai dati in un account di archiviazione dai log di Monitoraggio di Azure usando l'operatore externaldata. Tuttavia, i dati esportati vengono archiviati in BLOB di cinque minuti e l'analisi dei dati che si estendono su più BLOB può essere complessa. Pertanto, l'esportazione dei dati in un account di archiviazione è un buon meccanismo di backup dei dati, ma il backup dei dati in un account di archiviazione non è ideale se necessario per l'analisi nei log di Monitoraggio di Azure. È possibile eseguire query su grandi volumi di dati BLOB usando Esplora dati di Azure, Azure Data Factory o qualsiasi altro strumento di accesso alle risorse di archiviazione.

Protezione dei dati tra aree e resilienza del servizio tramite la replica dell'area di lavoro

La replica dell'area di lavoro è la soluzione di resilienza più estesa perché replica l'area di lavoro Log Analytics e i log in ingresso in un'altra area.

La replica dell'area di lavoro protegge sia i log che le operazioni del servizio e consente di continuare a monitorare i sistemi in caso di eventi imprevisti a livello di infrastruttura o di aree correlate all'applicazione.

A differenza delle zone di disponibilità, gestite da Microsoft end-to-end, è necessario monitorare l'integrità dell'area di lavoro primaria e decidere quando passare all'area di lavoro nell’area secondaria e viceversa.

Elenco di controllo della progettazione

  • Per garantire la resilienza dei servizi e dei dati agli eventi imprevisti a livello di area, abilitare la replica dell'area di lavoro.
  • Per garantire la protezione nell'area dagli errori del data center, creare l'area di lavoro in un'area che supporta le zone di disponibilità.
  • Per il backup inter-regionale dei dati in tabelle specifiche, usare la funzionalità di esportazione continua per trasferire i dati a un account di memoria con replica geografica.
  • Monitorare l'integrità delle aree di lavoro Log Analytics.

Consigli sulla configurazione

Raccomandazione Beneficio
Per garantire il massimo grado di resilienza, abilitare la replica dell'area di lavoro. Resilienza tra aree per le operazioni su dati e servizi dell'area di lavoro.

La replica dell'area di lavoro garantisce un'alta disponibilità creando un'istanza secondaria dell'area di lavoro in un'altra regione e trasferendo i log in entrambe le aree di lavoro.

Quando necessario, passare all'area di lavoro secondaria fino a quando non vengono risolti i problemi che influiscono sull'area di lavoro primaria. È possibile continuare a inserire log, eseguire query sui dati usando dashboard, avvisi e Sentinel nell'area di lavoro secondaria. Inoltre è possibile accedere ai log inseriti prima del cambio di area.

Si tratta di una funzionalità a pagamento, quindi valutare se si desidera replicare tutti i log in ingresso o solo alcuni flussi di dati.
Se possibile, creare l'area di lavoro in un'area che supporta la resilienza del servizio Monitoraggio di Azure. Resilienza nell'area dei dati e delle operazioni del servizio dell’area di lavoro in caso di problemi del data center.

Le zone di disponibilità che supportano la resilienza del servizio supportano anche la resilienza dei dati. Ciò significa che anche se un intero data center diventa non disponibile, la ridondanza tra le zone consente le operazioni del servizio Monitoraggio di Azure, come inserimento ed esecuzione di query, continuità di funzionamento e disponibilità dei log inseriti.

Le zone di disponibilità offrono protezione nell'area, ma non proteggono da problemi che influiscono sull'intera area.

Per informazioni sulle aree che supportano la resilienza dei dati, vedere Migliorare la resilienza dei dati e dei servizi nei log di Monitoraggio di Azure con zone di disponibilità.
Creare l'area di lavoro in un'area che supporta la resilienza dei dati. Protezione nell'area da perdita dei log nell'area di lavoro in caso di problemi del data center.

La creazione dell'area di lavoro in un'area che supporta la resilienza dei dati significa che, anche se l'intero data center diventa non disponibile, i log inseriti sono sicuri.
Se il servizio non è in grado di eseguire query, non è possibile visualizzare i log finché il problema non viene risolto.

Per informazioni sulle aree che supportano la resilienza dei dati, vedere Migliorare la resilienza dei dati e dei servizi nei log di Monitoraggio di Azure con zone di disponibilità.
Configurare l'esportazione dei dati da tabelle specifiche in un account di archiviazione replicato tra aree. Mantenere una copia di backup dei dati di log in un'area diversa.

La funzionalità di esportazione dei dati di Monitoraggio di Azure consente di esportare continuamente i dati inviati a tabelle specifiche nell'archiviazione di Azure in cui è possibile conservarli per periodi prolungati. Usa un account di archiviazione ridondante a livello geografico (GRS) o un account di archiviazione ridondante a livello di zona geografica (GZRS) per proteggere i tuoi dati anche se un'intera regione diventa non disponibile. Per rendere i dati leggibili dalle altre aree, configurare l'account di archiviazione per l'accesso in lettura all'area secondaria. Per ulteriori informazioni, consultare la ridondanza dell'archiviazione di Azure in una regione secondaria e l'accesso in lettura ai dati dell'archiviazione di Azure nella regione secondaria.

Per tabelle che non supportano l'esportazione continua dei dati, è possibile usare altri metodi di esportazione dei dati, tra cui App per la logica, per proteggere i dati. Si tratta principalmente di una soluzione per soddisfare la conformità per la conservazione dei dati poiché i dati possono essere difficili da analizzare e ripristinare nell'area di lavoro.

L'esportazione dei dati è soggetta a eventi imprevisti a livello di area perché si basa sulla stabilità della pipeline di inserimento di Monitoraggio di Azure nell'area. Non offre resilienza contro gli eventi imprevisti che influiscono sulla pipeline di inserimento a livello di area.
Monitorare l'integrità delle aree di lavoro Log Analytics. Usare le informazioni dettagliate dell'area di lavoro Log Analytics per tenere traccia delle query non riuscite e creare un avviso sullo stato di integrità per notificare in modo proattivo se un'area di lavoro non è più disponibile a causa di un data center o di un errore a livello di area.

Confrontare le funzionalità di resilienza dei log di Monitoraggio di Azure

Caratteristica / Funzionalità Resilienza del servizio Backup dei dati Disponibilità elevata Ambito di protezione Configurazione Costo
Duplicazione dell'area di lavoro ✅ ✅ ✅ Protezione tra aree contro gli eventi imprevisti a livello di area Abilitare la replica dell'area di lavoro e delle regole di raccolta dati correlate. Passare da un'area all'altra in base alle esigenze. In base al numero di GB replicati e all'area.
Zone di disponibilità ✅
Nelle regioni supportate		 ✅ ✅ Protezione nell'area da problemi del data center Abilitata automaticamente nelle aree supportate. Nessun costo
Esportazione dati continua ✅ Protezione dalla perdita di dati a causa di un errore a livello di area 1 Abilitare per tabella. Costo dell'esportazione dei dati + BLOB di archiviazione o Hub eventi

1 L'esportazione dei dati fornisce protezione tra regioni se si esportano i log in un account di archiviazione geo-riplicato. In caso di evento imprevisto, i dati esportati in precedenza vengono sottoposti a backup e resi prontamente disponibili; tuttavia, un'ulteriore esportazione potrebbe non riuscire, a seconda della natura dell'evento imprevisto.

Sicurezza

La sicurezza è uno degli aspetti essenziali di qualsiasi architettura. Azure Monitor offre funzionalità che usano sia il principio dei privilegi minimi che la difesa in profondità. Usare le informazioni seguenti per ottimizzare la sicurezza delle aree di lavoro Log Analytics e assicurarsi che solo gli utenti autorizzati accedano ai dati raccolti.

Concedere l'accesso ai dati nell'area di lavoro in base alle esigenze

  1. Impostare la modalità di controllo di accesso dell'area di lavoro su Usare le autorizzazioni delle risorse o dell'area di lavoro per consentire ai proprietari delle risorse di usare il contesto delle risorse per accedere ai dati senza concedere l'accesso esplicito all'area di lavoro. Ciò semplifica la configurazione dell'area di lavoro e consente agli utenti di accedere solo ai dati necessari.
    Istruzioni: Gestire l'accesso alle aree di lavoro Log Analytics
  2. Assegnare il ruolo predefinito appropriato per concedere le autorizzazioni per l'area di lavoro agli amministratori a livello di sottoscrizione, gruppo di risorse o area di lavoro a seconda dell'ambito delle responsabilità.
    Istruzioni: Gestire l'accesso alle aree di lavoro Log Analytics
  3. Applicare il controllo degli accessi in base al ruolo a livello di tabella per gli utenti che richiedono l'accesso a un set di tabelle tra più risorse. Gli utenti con autorizzazioni di tabella hanno accesso a tutti i dati nella tabella indipendentemente dalle relative autorizzazioni per le risorse.
    Istruzioni: Gestire l'accesso alle aree di lavoro Log Analytics

Proteggere i dati dei log in transito

Se si usano agenti, connettori o API di log per eseguire query o inviare dati all'area di lavoro, usare Transport Layer Security (TLS) 1.2 o versione successiva per garantire la sicurezza dei dati in transito. Le versioni precedenti di TLS e SECURE Sockets Layer (SSL) presentano vulnerabilità e, anche se potrebbero continuare a funzionare per garantire la compatibilità con le versioni precedenti, non sono consigliate e il settore si è spostato rapidamente per abbandonare il supporto per questi protocolli meno recenti.

Il PCI Security Standards Council ha fissato una scadenza del 30 giugno 2018 per disabilitare le versioni precedenti di TLS/SSL e l'aggiornamento a protocolli più sicuri. Quando Azure elimina il supporto legacy, i client che non comunicano completamente tramite TLS 1.2 o versione successiva non potranno inviare o eseguire query sui dati ai log di Monitoraggio di Azure.

Non configurare in modo esplicito gli agenti, i connettori dati o le applicazioni API per l'uso solo di TLS 1.2, a meno che non sia necessario. È consigliabile consentire loro di rilevare, negoziare e sfruttare automaticamente gli standard di sicurezza futuri. Diversamente, si potrebbe perdere la sicurezza aggiunta degli standard più recenti ed eventualmente riscontrare problemi se TLS 1.2 dovesse mai essere deprecato a favore di tali standard più recenti.

Importante

In linea con il ritiro del TLS legacy in tutto Azure, il protocollo TLS 1.0/1.1 verrà completamente bloccato per i Azure Monitor Logs in base alle date riportate nella tabella seguente. Per fornire la crittografia di livello migliore, i log di Monitoraggio di Azure usano già TLS 1.2/1.3 come meccanismi di crittografia scelti.

Data di imposizione Eseguire query sugli endpoint dell'API Versione del protocollo TLS
1° luglio 2025 Log degli endpoint dell'API query TLS 1.2 o versione successiva
1 marzo 2026 Endpoint dell'API di ingestione dei log TLS 1.2 o versione successiva

Per evitare potenziali interruzioni del servizio, verificare che le risorse che interagiscono con gli endpoint dell'API Logs non abbiano dipendenze dai protocolli TLS 1.0 o 1.1.


Fare clic qui per un'azione consigliata che è possibile eseguire per controllare le macchine virtuali.

Verificare le risorse della macchina virtuale usando un agente di monitoraggio con una dipendenza TLS non supportata

  1. Usare una query di Azure Resource Graph per controllare le versioni del sistema operativo delle macchine virtuali in cui è installata una versione dell'agente di monitoraggio.
  2. Dal portale di Azure passare a Resource Manager e selezionare Resource Graph Explorer. La query seguente trova tutte le macchine virtuali nell'ambito specificato in cui è installata un'estensione. Se le macchine virtuali vengono avviate, vengono elencati anche il nome e la versione del sistema operativo. Cercare le macchine virtuali con l'agente di Monitoraggio di Azure o uno degli agenti legacy installati.
Resources
| where type =~ 'microsoft.compute/virtualmachines' 
 | project id,
  JoinID = toupper(id),
  ComputerName = tostring(properties.osProfile.computerName),
  OSName = tostring(properties.extended.instanceView.osName),
  OSVersion = tostring(properties.extended.instanceView.osVersion),
  osOffer = tostring(properties.storageProfile.imageReference.offer),
  osSku = tostring(properties.storageProfile.imageReference.sku)
| join kind=leftouter(
  Resources
  | where type == 'microsoft.compute/virtualmachines/extensions'
  | project
    MachineId = toupper(substring(id, 0, indexof(id, '/extensions'))),
    ExtensionName = name,
    ExtensionVersion = properties.typeHandlerVersion
) on $left.JoinID == $right.MachineId
| summarize Extensions = make_list(ExtensionName) by id, ComputerName, OSName, OSVersion, osOffer, osSku, tostring(ExtensionVersion)
| order by tolower(OSName) asc
  1. Usare quindi questa tabella delle versioni supportate di TLS in Windows per determinare quali macchine virtuali Windows nei risultati della query è necessario verificare l'abilitazione TLS.
  2. Disabilitare TLS 1.0 e 1.1 e abilitare TLS 1.2. Per altre informazioni, vedere Configurare TLS 1.2 per l'agente.

Praticamente qualsiasi versione di Windows precedente alle versioni più recenti ha ancora TLS 1.0 o 1.1 disponibile. Windows 7 e versioni successive possono abilitare TLS 1.2, ma non disabilitano automaticamente TLS 1.0 e 1.1. Solo le prossime versioni di Windows prevedono di disattivarli per impostazione predefinita. Identificare i sistemi senza la possibilità di supportare TLS 1.2 e i sistemi che richiedono un aggiornamento o una modifica del Registro di sistema per supportare TLS 1.2.

In Linux, il supporto del protocollo TLS viene fornito dalle librerie (ad esempio OpenSSL, NSS, GnuTLS) fornite con il sistema operativo. Molte versioni diLinux precedenti alla versione 2018-2020 supportano TLS 1.0 e 1.1 e le lasciano abilitate per impostazione predefinita. Le versioni più recenti hanno iniziato a disabilitare TLS legacy per impostazione predefinita.

Per domande generali sul problema TLS legacy o su come testare i pacchetti di crittografia supportati, vedere Risoluzione dei problemi TLS e supporto TLS di Azure Resource Manager.

Configurare il controllo delle query di log

  1. Configurare il controllo delle query di log per registrare i dettagli di ogni query eseguita in un'area di lavoro.
    Istruzioni: Controllare le query nei log di Monitoraggio di Azure
  2. Considerare i dati di controllo delle query di log come dati di sicurezza e proteggere l'accesso alla tabella LAQueryLogs in modo appropriato.
    Istruzioni: configurare l'accesso ai dati nell'area di lavoro in base alle esigenze.
  3. Se si separano i dati operativi e di sicurezza, inviare i log di controllo per ogni area di lavoro all'area di lavoro locale o consolidare in un'area di lavoro dedicata per la sicurezza.
    Istruzioni: configurare l'accesso ai dati nell'area di lavoro in base alle esigenze.
  4. Usare le informazioni dettagliate sull'area di lavoro Log Analytics per esaminare periodicamente i dati di controllo delle query di log.
    Istruzioni: Informazioni dettagliate sull'area di lavoro Log Analytics.
  5. Creare regole di avviso di ricerca log per notificare se gli utenti non autorizzati tentano di eseguire query.
    Istruzioni: Regole di avviso di ricerca nei log.

Garantire l'immutabilità dei dati di controllo

Azure Monitor è una piattaforma di dati a sola aggiunta, ma include delle disposizioni per eliminare i dati a scopo di conformità. Per proteggere i dati di controllo:

  1. Impostare un blocco nell'area di lavoro Log Analytics per bloccare tutte le attività che potrebbero eliminare i dati, tra cui ripulitura, eliminazione di tabelle e modifiche di conservazione dei dati a livello di area di lavoro o a livello di area di lavoro. Tenere tuttavia presente che questo blocco può essere rimosso.
    Istruzioni: Bloccare le risorse per proteggere l'infrastruttura

  2. Se è necessaria una soluzione completamente a prova di manomissione, è consigliabile esportare i dati in una soluzione di archiviazione non modificabile:

    1. Determinare i tipi di dati specifici da esportare. Non tutti i tipi di log hanno la stessa rilevanza per la conformità, il controllo o la sicurezza.
    2. Usare l'esportazione dei dati per inviare dati a un account di archiviazione di Azure.
      Istruzioni: Esportazione dati dell'area di lavoro Log Analytics in Azure Monitor
    3. Impostare criteri di immutabilità per la protezione da manomissioni dei dati.
      Istruzioni: Configurare i criteri di immutabilità per le versioni BLOB

Filtrare o offuscare i dati sensibili nell'area di lavoro

Se i dati di log includono informazioni riservate:

  1. Filtrare i record che non devono essere raccolti usando la configurazione per l'origine dati specifica.
  2. Usare una trasformazione se devono essere rimosse o offuscate solo determinate colonne nei dati.
    Istruzioni: Trasformazioni in Monitoraggio di Azure
  3. Se si dispone di standard che richiedono che i dati originali non vengano modificato, usare il valore letterale "h" nelle query KQL per offuscare i risultati delle query visualizzati nelle cartelle di lavoro.
    Istruzioni: Stringhe letterali offuscate

Eliminare i dati sensibili raccolti accidentalmente

  1. Controllare periodicamente la presenza di dati privati che potrebbero essere raccolti accidentalmente nell'area di lavoro.
  2. Usare l'eliminazione dei dati per rimuovere i dati indesiderati. Si noti che i dati nelle tabelle con il piano ausiliario non possono essere eliminati.
    Istruzioni: Gestione dei dati personali nei log di Monitoraggio di Azure e in Application Insights

Monitoraggio di Azure crittografa tutti i dati inattivi e le query salvate usando chiavi gestite da Microsoft (MMK). Se si raccolgono dati sufficienti per un cluster dedicato, collegare l'area di lavoro a un cluster dedicato per le funzionalità di sicurezza avanzate, tra cui:

Istruzioni: Creare e gestire un cluster dedicato nei log di Monitoraggio di Azure

Microsoft protegge le connessioni agli endpoint pubblici con la crittografia end-to-end. Se è necessario un endpoint privato, usare il collegamento privato di Azure per consentire alle risorse di connettersi all'area di lavoro Log Analytics tramite reti private autorizzate. È anche possibile usare il collegamento privato per forzare l'inserimento dei dati dell'area di lavoro tramite ExpressRoute o una VPN.

Istruzioni: Progettare la configurazione del collegamento privato di Azure

Ottimizzazione dei costi

L'ottimizzazione dei costi riguarda l'analisi dei modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. È possibile abbattere i costi per Monitoraggio di Azure in modo significativo analizzando le diverse opzioni di configurazione e le opportunità che consentono di ridurre la quantità di dati raccolti. Vedere Costi e utilizzo di Monitoraggio di Azure per comprendere i diversi modi in cui Monitoraggio di Azure effettua gli addebiti e come visualizzare la fattura mensile.

Annotazioni

Vedere Ottimizzare i costi in Monitoraggio di Azure per consigli sull'ottimizzazione dei costi in tutte le funzionalità di Monitoraggio di Azure.

Elenco di controllo della progettazione

  • Determinare se combinare i dati operativi e i dati sulla sicurezza nella stessa area di lavoro Log Analytics.
  • Configurare il piano tariffario in base alla quantità di dati in genere raccolti da ogni area di lavoro Log Analytics.
  • Configurare la conservazione e l'archiviazione dei dati.
  • Configurare le tabelle usate per il debug, la risoluzione dei problemi e il controllo come log di base.
  • Limitare la raccolta dati dalle origini dati per l'area di lavoro.
  • Analizzare regolarmente i dati raccolti per identificare tendenze e anomalie.
  • Creare un avviso quando la raccolta dati raggiunge quantità elevate.
  • Prendere in considerazione un limite massimo giornaliero come misura preventiva per assicurarsi di non superare un determinato budget.
  • Configurare avvisi sulle raccomandazioni sui costi fornite da Azure Advisor per le aree di lavoro Log Analytics.

Consigli sulla configurazione

Raccomandazione Beneficio
Determinare se combinare i dati operativi e i dati sulla sicurezza nella stessa area di lavoro Log Analytics. Poiché tutti i dati presenti in un'area di lavoro Log Analytics sono soggetti ai prezzi di Microsoft Sentinel, nel caso in cui sia abilitato, la combinazione di questi dati potrebbe avere implicazioni in termini di costi. Per informazioni dettagliate sulla decisione da prendere per l'ambiente, in modo da bilanciarla con i criteri degli altri pilastri, vedere Progettare una strategia per l'area di lavoro Log Analytics.
Configurare il piano tariffario in base alla quantità di dati in genere raccolti da ogni area di lavoro Log Analytics. Per impostazione predefinita, le aree di lavoro Log Analytics useranno i prezzi con pagamento in base al consumo che non prevedono un volume minimo di dati. Se si raccoglie una quantità sufficiente di dati, è possibile ridurre significativamente il costo usando un livello di impegno, che consente di eseguire il commit a un minimo giornaliero di dati raccolti in cambio di un tasso inferiore. Se si raccoglie una quantità sufficiente di dati tra aree di lavoro in una singola regione, è possibile collegarli a un cluster dedicato e combinare il volume raccolto usando i prezzi del cluster.

Per informazioni dettagliate sui livelli di impegno e indicazioni su come determinare quale sia il più appropriato per il livello di utilizzo, vedere Calcoli dei costi e opzioni di Log di Monitoraggio di Azure. Vedere Utilizzo e costi stimati per visualizzare i costi stimati per l'utilizzo in piani tariffari diversi.
Configurare la conservazione dei dati interattiva e a lungo termine. È previsto un addebito per la conservazione dei dati in un'area di lavoro Log Analytics oltre il valore predefinito di 31 giorni (90 giorni se Sentinel è abilitato nell'area di lavoro e 90 giorni per i dati di Application Insights). Prendere in considerazione i requisiti specifici per avere i dati prontamente disponibili per le query di log. È possibile ridurre i costi in modo significativo configurando la conservazione a lungo termine, che consente di conservare i dati per un massimo di dodici anni e di accedervi occasionalmente usando processi di ricerca o ripristinando un set di dati nell'area di lavoro.
Configurare le tabelle usate per il debug, la risoluzione dei problemi e il controllo come log di base. Le tabelle in un'area di lavoro Log Analytics configurata per i log di base hanno un costo di inserimento inferiore in cambio di funzionalità limitate e di un addebito per le query di log. Se si esegue una query su queste tabelle raramente e non vengono usate per l'invio di avvisi, il costo della query può essere più che compensato dal costo di inserimento ridotto.
Limitare la raccolta dati dalle origini dati per l'area di lavoro. Il fattore principale per il costo di Monitoraggio di Azure è la quantità di dati raccolti nell'area di lavoro Log Analytics, quindi è consigliabile assicurarsi di non raccogliere più dati di quelli necessari per valutare l'integrità e le prestazioni dei servizi e delle applicazioni. Per informazioni dettagliate sulla decisione da prendere per l'ambiente, in modo da bilanciarla con i criteri degli altri pilastri, vedere Progettare un’architettura per l'area di lavoro Log Analytics.

Compromesso: potrebbe sussistere un compromesso tra il costo e i requisiti di monitoraggio. Ad esempio, si potrebbe essere in grado di rilevare un problema di prestazioni più rapidamente con una frequenza di campionamento elevata, ma al contempo voler ridurre la frequenza di campionamento per risparmiare sui costi. La maggior parte degli ambienti dispone di più origini dati con tipi di raccolta diversi, per cui è necessario bilanciare i requisiti specifici con gli obiettivi di costo per ognuno di essi. Per raccomandazioni sulla configurazione della raccolta per origini dati diverse, vedere Ottimizzazione dei costi in Monitoraggio di Azure.
Analizzare regolarmente i dati raccolti per identificare tendenze e anomalie. Usare le informazioni dettagliate sull'area di lavoro Log Analytics per esaminare periodicamente la quantità di dati raccolti nell'area di lavoro. Oltre a consentire la comprensione della quantità di dati raccolti da origini diverse, il sistema identifica anomalie e tendenze al rialzo nella raccolta di dati che potrebbero comportare un eccesso di costi. Analizzare in modo più approfondito la raccolta dei dati usando i metodi illustrati in Analisi dell’utilizzo nell'area di lavoro Log Analytics per determinare se è disponibile una configurazione aggiuntiva in grado di ridurre ulteriormente l'utilizzo. Questo approccio si rivela particolarmente importante quando si aggiunge un nuovo set di origini dati, ad esempio un nuovo set di macchine virtuali, o si esegue l'onboarding di un nuovo servizio.
Creare un avviso quando la raccolta dati raggiunge quantità elevate. Per evitare fatture impreviste, si dovrebbe ricevere una notifica in modo proattivo ogni volta che si verifica un utilizzo eccessivo. La notifica consente di risolvere eventuali anomalie potenziali prima della fine del periodo di fatturazione.
Prendere in considerazione un limite massimo giornaliero come misura preventiva per assicurarsi di non superare un determinato budget. Il limite massimo giornaliero disabilita la raccolta dei dati in un'area di lavoro Log Analytics per il resto del giorno dopo il raggiungimento del limite configurato. È consigliabile non usare questo metodo per ridurre i costi, secondo quanto descritto in Quando usare un limite massimo giornaliero.

Se si imposta un limite massimo giornaliero, oltre alla creazione di un avviso quando viene raggiunto tale limite, assicurarsi anche di creare una regola di avviso per ricevere una notifica quando viene raggiunta una determinata percentuale (ad esempio, il 90%). In questo modo si ha l’opportunità di esaminare con attenzione e risolvere la causa dell'aumento dei dati, prima che il limite interrompa la raccolta dati.
Configurare avvisi sulle raccomandazioni sui costi fornite da Azure Advisor per le aree di lavoro Log Analytics. Le raccomandazioni di Azure Advisor per le aree di lavoro di Log Analytics inviano avvisi in modo proattivo quando si presenta l'opportunità di ottimizzare i costi. Creare avvisi di Azure Advisor per le raccomandazioni sui costi seguenti:
  • Valutare la possibilità di configurare il piano di log di base conveniente nelle tabelle selezionate: è stato identificato l'inserimento di più di 1 GB al mese nelle tabelle idonee per il piano dati di log Basic a basso costo. Il piano di log di base offre funzionalità di query per il debug e la risoluzione dei problemi a un costo inferiore.
  • Prendere in considerazione la modifica del piano tariffario: in base al volume di utilizzo corrente, valutare la possibilità di modificare il piano tariffario (impegno) per ottenere uno sconto e ridurre i costi.
  • Prendere in considerazione la rimozione delle tabelle ripristinate inutilizzate: nell'area di lavoro sono presenti una o più tabelle con dati ripristinati attivi. Se non si usano più i dati ripristinati, eliminare la tabella per evitare addebiti non necessari.
  • È stata rilevata un'anomalia nell’inserimento dati: è stata identificata una frequenza di inserimento molto più elevata nell'ultima settimana, in base all'inserimento delle tre settimane precedenti. Prendere nota di questa modifica e della variazione prevista dei costi.
È anche possibile visualizzare le raccomandazioni generate automaticamente selezionando Informazioni generali>Raccomandazioni o Raccomandazioni di Advisor dal menu delle risorse dell'area di lavoro Log Analytics.

Eccellenza operativa

L'eccellenza operativa si riferisce ai processi operativi necessari per mantenere un servizio in esecuzione in modo affidabile nell'ambiente di produzione. Usare le informazioni seguenti per ridurre al minimo i requisiti operativi per il supporto delle aree di lavoro Log Analytics.

Elenco di controllo della progettazione

  • Progettare un'architettura dell'area di lavoro con il numero minimo di aree di lavoro per soddisfare i requisiti aziendali.
  • Usare Infrastructure as Code (IaC) quando si gestiscono più aree di lavoro.
  • Usare le informazioni dettagliate sull'area di lavoro Log Analytics per tenere traccia dell'integrità e delle prestazioni delle aree di lavoro Log Analytics.
  • Creare regole di avviso per ricevere notifiche proattive sui problemi operativi nell'area di lavoro.
  • Assicurarsi di disporre di un processo operativo ben definito per la separazione dei dati.

Consigli sulla configurazione

Raccomandazione Beneficio
Progettare una strategia dell'area di lavoro per soddisfare i requisiti aziendali. Vedere Progettare un'architettura dell'area di lavoro Log Analytics per indicazioni sulla progettazione di una strategia per le aree di lavoro Log Analytics, tra cui quante crearne e dove inserirle.

Una singola area di lavoro o almeno un numero minimo di aree di lavoro ottimizzano l'efficienza operativa perché limitano la distribuzione dei dati operativi e di sicurezza, aumentando la visibilità su potenziali problemi, semplificando l'identificazione dei modelli e riducendo al minimo i requisiti di manutenzione.

Potrebbero essere previsti requisiti per più aree di lavoro, ad esempio più tenant, oppure potrebbero essere necessarie aree di lavoro in più aree per supportare i requisiti di disponibilità. In questi casi, assicurarsi di disporre di processi appropriati per gestire questa maggiore complessità.
Usare Infrastructure as Code (IaC) quando si gestiscono più aree di lavoro. Usare Infrastructure as Code (IaC) per definire i dettagli delle aree di lavoro in ARM, BICEPo Terraform. In questo modo è possibile sfruttare i processi DevOps esistenti per distribuire nuove aree di lavoro e Criteri di Azure per applicare la configurazione.
Usare le informazioni dettagliate sull'area di lavoro Log Analytics per tenere traccia dell'integrità e delle prestazioni delle aree di lavoro Log Analytics. Le informazioni dettagliate sull'area di lavoro Log Analytics offrono una visualizzazione unificata dell'utilizzo, delle prestazioni, dell'integrità, degli agenti, delle query e del log delle modifiche per tutte le aree di lavoro. Esaminare queste informazioni a intervalli regolari per tenere traccia dell'integrità e del funzionamento di ognuna delle aree di lavoro.
Creare regole di avviso per ricevere notifiche proattive sui problemi operativi nell'area di lavoro. Ogni area di lavoro include una tabella delle operazioni che registra attività importanti che interessano l'area di lavoro. Creare regole di avviso basate su questa tabella per ricevere una notifica proattiva quando si verifica un problema operativo. È possibile usare gli avvisi consigliati per l'area di lavoro per semplificare la creazione delle regole di avviso più critiche.
Assicurarsi di disporre di un processo operativo ben definito per la separazione dei dati. Potrebbero essere previsti requisiti diversi per i diversi tipi di dati archiviati nell'area di lavoro. Assicurarsi di comprendere chiaramente tali requisiti, ad esempio la conservazione dei dati e la sicurezza quando si progetta la strategia dell'area di lavoro e si configurano impostazioni come le autorizzazioni e la conservazione a lungo termine. È inoltre necessario disporre di un processo chiaramente definito per l'eliminazione occasionale dei dati con informazioni personali raccolti accidentalmente.

Efficienza delle prestazioni

L'efficienza delle prestazioni è la capacità di dimensionare il carico di lavoro per soddisfare in modo efficiente le richieste poste dagli utenti. Usare le informazioni seguenti per assicurarsi che le aree di lavoro Log Analytics e le query di log siano configurate per ottenere prestazioni ottimali.

Elenco di controllo della progettazione

  • Configurare il controllo delle query di log e usare le informazioni dettagliate sull'area di lavoro Log Analytics per identificare query lente e inefficienti.

Consigli sulla configurazione

Raccomandazione Beneficio
Configurare il controllo delle query di log e usare le informazioni dettagliate sull'area di lavoro Log Analytics per identificare query lente e inefficienti. Il controllo delle query di log archivia il tempo di calcolo necessario per eseguire ogni query e il tempo necessario per restituire i risultati. Le informazioni dettagliate sull'area di lavoro Log Analytics usano questi dati per elencare query potenzialmente inefficienti nell'area di lavoro. Valutare la possibilità di riscrivere queste query per migliorare le prestazioni. Per indicazioni sull'ottimizzazione delle query di log, vedere Ottimizzare le query di log in Monitoraggio di Azure.

Passaggio successivo

  • Last updated on