Condividi tramite

i calcoli e le opzioni dei costi dei log di Monitoraggio di Azure

  • Articolo

Gli addebiti più significativi per la maggior parte delle implementazioni di Monitoraggio di Azure sono in genere l'inserimento e la conservazione dei dati nelle aree di lavoro Log Analytics. Diverse funzionalità di Monitoraggio di Azure non hanno un costo diretto, ma si aggiungono ai dati dell'area di lavoro raccolti. Questo articolo descrive come vengono calcolati gli addebiti per i dati per le aree di lavoro Log Analytics e le varie opzioni di configurazione che influiscono sui costi.

Suggerimento

Per le strategie per ridurre i costi di Monitoraggio di Azure, vedere Ottimizzazione dei costi e Monitoraggio di Azure.

Modello di determinazione prezzi

L'impostazione predefinita dei prezzi per Log Analytics è un modello con pagamento in base al consumo basato sul volume di dati inserito e la conservazione dei dati. Ogni area di lavoro Log Analytics viene addebitata come servizio separato e contribuisce alla fatturazione per la sottoscrizione di Azure. I prezzi per i log di Monitoraggio di Azure vengono impostati a livello di area. L'importo per l'inserimento dati può essere notevole, a seconda di:

  • Set delle soluzioni di gestione abilitate e relativa configurazione.
  • Numero e tipo di risorse monitorate.
  • Tipi di dati raccolti da ciascuna risorsa monitorata.

Un elenco dei nomi dei contatori di fatturazione di Monitoraggio di Azure è disponibile qui.

Calcolo delle dimensioni dei dati

I log di Monitoraggio di Azure fatturano la quantità di dati inviati a un'area di lavoro Log Analytics in GB (10^9 byte).

I log di Monitoraggio di Azure calcolano le dimensioni fatturate di un singolo record in base a:

  • Rappresentazione di stringa delle voci di colonna che i log di Monitoraggio di Azure devono aggiungere nell'area di lavoro Log Analytics per tale record.

    Se si inviano voci di colonne che non corrispondono allo schema della tabella di destinazione, i log di Monitoraggio di Azure vengono fatturati per tali voci di colonna, anche se la tabella di destinazione non può archiviare i dati. Assicurarsi che le regole di raccolta dati corrispondano allo schema della tabella di destinazione per evitare addebiti per i dati che la tabella di destinazione non è in grado di archiviare.

    Nota

    Il calcolo del volume di dati fatturabile è in genere notevolmente inferiore rispetto alle dimensioni dell'intero evento in pacchetto JSON in ingresso. In media, in tutti i tipi di eventi, le dimensioni fatturate sono inferiori al 25% rispetto alle dimensioni dei dati in ingresso. Può essere fino al 50% per eventi di piccole dimensioni. La percentuale include l'effetto delle colonne standard escluse dalla fatturazione. È essenziale comprendere questo calcolo delle dimensioni dei dati fatturate quando si stimano i costi e si confrontano altri modelli di prezzi.

  • Tutti i dati nel record, indipendentemente dal fatto che i dati vengano raccolti dall'origine dati o aggiunti durante il processo di inserimento. Questo calcolo include tutte le colonne personalizzate aggiunte dall'API di inserimento dei log, dalle trasformazioni e dai campi personalizzati.

Colonne escluse

Le colonne standard seguenti sono comuni a tutte le tabelle e vengono escluse nel calcolo delle dimensioni del record. Tutte le altre colonne archiviate in Log Analytics sono incluse nel calcolo delle dimensioni del record. Colonne standard:

  • _ResourceId
  • _SubscriptionId
  • _ItemId
  • _IsBillable
  • _BilledSize
  • Type

Tabelle escluse

Alcune tabelle sono completamente prive di addebiti per l'inserimento dati, tra cui, ad esempio, AzureActivity, Heartbeat, Usage e Operation. Queste informazioni sono sempre indicate dalla colonna _IsBillable, che indica se un record è stato escluso dalla fatturazione per l'inserimento e la conservazione dei dati.

Addebiti per altri servizi e soluzioni

Alcune soluzioni hanno criteri più specifici sull'inserimento gratuito dei dati. Ad esempio, Azure Migrate rende gratuiti i dati di visualizzazione delle dipendenze per i primi 180 giorni di una valutazione server. I servizi come Microsoft Defender for Cloud, Microsoft Sentinel e gestione della configurazione dispongono di modelli di prezzi personalizzati.

Vedere la documentazione per diversi servizi e soluzioni per qualsiasi calcolo di fatturazione univoco.

Livelli di impegno

In aggiunta al modello con pagamento in base al consumo, Log Analytics ha anche livelli di impegno, che possono consentire di risparmiare fino al 30% rispetto al prezzo con pagamento in base al consumo. Con i prezzi del livello di impegno, è possibile impegnarsi ad acquistare l'inserimento dati per un'area di lavoro, a partire da 100 GB al giorno, a un prezzo inferiore rispetto ai prezzi con pagamento in base al consumo. Qualsiasi utilizzo superiore al livello di impegno (eccedenza) viene fatturato allo stesso prezzo per GB fornito dal livello di impegno corrente. L'eccedenza viene fatturata usando lo stesso contatore di fatturazione del livello di impegno. Ad esempio, se un'area di lavoro è nel livello di impegno di 200 GB al giorno e inserisce 300 GB in un giorno, tale utilizzo viene fatturato come 1,5 unità del livello di impegno di 200 GB al giorno. I livelli di impegno hanno un periodo di impegno di 31 giorni dal momento in cui un livello di impegno viene selezionato o modificato.

  • Durante il periodo di impegno, è possibile passare a un livello di impegno superiore, che riavvia il periodo di impegno di 31 giorni. Per tornare al piano con pagamento in base al consumo o a un livello di impegno inferiore, è necessario attendere il termine del periodo di impegno.
  • Al termine del periodo di impegno, l'area di lavoro mantiene il livello di impegno selezionato e può essere spostata al piano con pagamento in base al consumo o a un livello di impegno inferiore in qualsiasi momento.
  • Se un'area di lavoro viene spostata inavvertitamente in un livello di impegno, contattare il supporto tecnico Microsoft per reimpostare il periodo di impegno in modo da poter tornare al piano tariffario con pagamento in base al consumo.

La fatturazione per i livelli di impegno viene eseguita ogni giorno per ogni area di lavoro. Se l'area di lavoro fa parte di un cluster dedicato, la fatturazione viene eseguita per il cluster. Vedere la sezione seguente "Cluster dedicati". Per un elenco dei livelli di impegno e dei relativi prezzi, vedere prezzi di Monitoraggio di Azure.

Gli sconti per l'impegno di Azure, ad esempio gli sconti ricevuti da Microsoft Contratto Enterprise, vengono applicati ai prezzi del piano di impegno dei log di Monitoraggio di Azure proprio come per i prezzi con pagamento in base al consumo. Gli sconti vengono applicati se l'utilizzo viene fatturato per area di lavoro o per cluster dedicato.

Suggerimento

La voce di menu Utilizzo e costi stimati per ogni area di lavoro Log Analytics mostra una stima degli addebiti per l'inserimento dati a ogni livello di impegno per scegliere il livello di impegno ottimale per i modelli di inserimento dati. Esaminare periodicamente queste informazioni per determinare se è possibile ridurre gli addebiti passando a un altro livello. Per informazioni su questa visualizzazione, vedere Utilizzo e costi stimati. Per esaminare gli addebiti effettivi, usare Gestione costi di Azure = Fatturazione.

Cluster Hub eventi Dedicato

Un cluster dedicato di log di Monitoraggio di Azure è una raccolta di aree di lavoro in un singolo cluster gestito di Esplora dati di Azure. I cluster dedicati supportano funzionalità avanzate, ad esempio chiavi gestite dal cliente e usano lo stesso modello di prezzi del livello di impegno delle aree di lavoro, anche se devono avere un livello di impegno di almeno 100 GB al giorno. Qualsiasi utilizzo superiore al livello di impegno (eccedenza) viene fatturato allo stesso prezzo per GB fornito dal livello di impegno corrente. Per i cluster non è disponibile alcuna opzione con pagamento in base al consumo.

Il livello di impegno del cluster ha un periodo di impegno di 31 giorni dopo l'incremento del livello di impegno. Durante il periodo di impegno non è possibile ridurre il livello di impegno, ma è possibile aumentarlo in qualsiasi momento. Quando le aree di lavoro sono associate a un cluster, la fatturazione per l'inserimento dati per tali aree di lavoro viene eseguita a livello di cluster usando il livello di impegno configurato.

Esistono due modalità di fatturazione per un cluster specificato quando si crea il cluster:

  • Cluster (impostazione predefinita): la fatturazione per i dati inseriti viene eseguita a livello di cluster. Le quantità di dati inseriti da ogni area di lavoro associata a un cluster vengono aggregate per calcolare la fattura giornaliera per il cluster. Le allocazioni per nodo da Microsoft Defender per il cloud vengono applicate a livello di area di lavoro prima di questa aggregazione di dati in tutte le aree di lavoro del cluster.

  • Aree di lavoro: i costi del livello di impegno per il cluster vengono attribuiti proporzionalmente alle aree di lavoro nel cluster, in base al volume di inserimento dati di ogni area di lavoro (dopo aver contabilizzato le allocazioni per nodo da Microsoft Defender per il cloud per ogni area di lavoro).

    Se il volume di dati totale inserito in un cluster per un giorno è inferiore al livello di impegno, ogni area di lavoro viene fatturata per i dati inseriti alla tariffa effettiva del livello di impegno per GB fatturando loro una frazione del livello di impegno. La parte inutilizzata del livello di impegno viene quindi fatturata alla risorsa cluster.

    Se il volume di dati totale inserito in un cluster per un giorno è maggiore del livello di impegno, ogni area di lavoro viene fatturata per una frazione del livello di impegno, in base alla frazione dei dati inseriti quel giorno e a ogni area di lavoro per una frazione dei dati inseriti al di sopra del livello di impegno. Se il volume di dati totale inserito in un'area di lavoro per un giorno supera il livello di impegno, non viene addebitato alcun costo alla risorsa cluster.

Esempi di funzionamento della fatturazione del cluster in ognuna di queste modalità sono disponibili qui.

La conservazione dei dati viene fatturata per ogni area di lavoro, come per le aree di lavoro non aggiunte a un cluster.

La fatturazione del cluster viene avviata quando viene creato il cluster, indipendentemente dal fatto che le aree di lavoro siano state associate al cluster.

Quando si collegano le aree di lavoro a un cluster, il piano tariffario viene modificato in cluster e l'inserimento viene fatturato in base al livello di impegno del cluster. Le aree di lavoro associate a un cluster non hanno più il proprio piano tariffario. Le aree di lavoro possono essere scollegate da un cluster in qualsiasi momento e il piano tariffario può essere modificato in "per GB".

Se l'area di lavoro collegata usa il piano tariffario legacy per nodo, viene fatturata in base ai dati inseriti rispetto al livello di impegno del cluster e non più per nodo. Le allocazioni di dati per nodo da Microsoft Defender per il cloud continueranno a essere applicate.

Se un cluster viene eliminato, la fatturazione per il cluster si arresta anche se il cluster rientra nel periodo di impegno di 31 giorni.

Per altre informazioni su come creare un cluster dedicato e specificarne il tipo di fatturazione, vedere Creare un cluster dedicato.

Piani di tabella basic e ausiliari

È possibile configurare determinate tabelle in un'area di lavoro Log Analytics in modo che usi Piani di tabella basic e ausiliari. I dati in queste tabelle hanno un addebito di inserimento notevolmente ridotto. È previsto un addebito per eseguire query sui dati in queste tabelle.

L'addebito per l'esecuzione di query sui dati nelle tabelle basic e ausiliarie si basa sui GB di dati analizzati durante l'esecuzione della ricerca.

Per altre informazioni sui piani di tabella basic e ausiliari, vedere Panoramica dei log di Monitoraggio di Azure: piani di tabella.

Conservazione dei dati di log

Oltre all'inserimento dati, è previsto un addebito per la conservazione dei dati in ogni area di lavoro Log Analytics. È possibile impostare il periodo di conservazione per l'intera area di lavoro o per ogni tabella. Dopo questo periodo, i dati vengono rimossi o mantenuti nella conservazione a lungo termine. Durante il periodo di conservazione a lungo termine, si paga un addebito di conservazione ridotto ed è previsto un addebito per recuperare i dati usando un processo di ricerca. Usare la conservazione a lungo termine per ridurre i costi per i dati che è necessario archiviare per la conformità o le indagini occasionali.

L'eliminazione di una tabella personalizzata non rimuove i dati associati a tale tabella, quindi gli addebiti per la conservazione interattiva e a lungo termine continuano a essere applicati.

Per altre informazioni sulla conservazione dei dati, tra cui come configurare queste impostazioni e accedere ai dati nella conservazione a lungo termine, vedere Gestire la conservazione dei dati in un'area di lavoro Log Analytics.

Nota

L'eliminazione dei dati dall'area di lavoro Log Analytics tramite la funzionalità di eliminazione di Log Analytics non influisce sui costi di conservazione. Per ridurre i costi di conservazione, ridurre il periodo di conservazione per l'area di lavoro o per tabelle specifiche.

Processi di ricerca

Recuperare i dati dalla conservazione a lungo termine eseguendo processi di ricerca. I processi di ricerca sono query asincrone che recuperano record in una nuova tabella di ricerca nell'area di lavoro per un'analisi ulteriore. I processi di ricerca vengono fatturati in base al numero di GB di dati analizzati ogni giorno a cui si accede per eseguire la ricerca.

Ripristino dei dati di log

Quando è necessario eseguire query su volumi elevati di dati o dati con conservazione a lungo termine con le funzionalità di query analitiche complete, la funzionalità di ripristino dati è uno strumento potente. L'operazione di ripristino rende disponibile un intervallo di tempo specifico di dati in una tabella nella cache ad accesso frequente per le query con prestazioni elevate. Al termine, è possibile ignorare i dati in un secondo momento. Il ripristino dei dati di log viene fatturato in base alla quantità di dati ripristinati e al momento in cui il ripristino viene mantenuto attivo. I valori minimi fatturati per qualsiasi ripristino dei dati sono di 2 TB e 12 ore. I dati ripristinati di più di 2 TB e/o più di 12 ore di durata vengono fatturati in base a una valutazione proporzionale.

Esportazione dei dati di log

L'esportazione dei dati in un'area di lavoro Log Analytics consente di esportare continuamente i dati per ogni tabella selezionata nell'area di lavoro in un account di archiviazione di Azure o in Hub eventi di Azure man mano che arrivano a una pipeline di Monitoraggio di Azure. Gli addebiti per l'utilizzo dell'esportazione dei dati si basano sulla quantità di dati esportati. Le dimensioni dei dati esportati sono il numero di byte nei dati in formato JSON esportati.

Fatturazione di Application Insights

Siccome le risorse Application Insights basate sull'area di lavoro archiviano i propri dati in un'area di lavoro Log Analytics, la fatturazione per l'inserimento e la conservazione dei dati viene effettuata dall'area di lavoro in cui si trovano i dati di Application Insights. Per questo motivo, è possibile usare tutte le opzioni del modello di prezzi di Log Analytics, inclusi i livelli di impegno, insieme al pagamento in base al consumo.

Suggerimento

Si vuole modificare le impostazioni di conservazione nelle tabelle di Application Insights? I nomi delle tabelle sono stati modificati per i componenti basati sull'area di lavoro, vedere Struttura di tabelle di Application Insights

L'inserimento dati e la conservazione dei dati per una risorsa classica di Application Insights seguono gli stessi prezzi del piano con pagamento in base al consumo delle risorse basate sull'area di lavoro, ma non possono usare i livelli di impegno.

I dati di telemetria dei test del ping e dei test in più passi vengono addebitai allo stesso costo del consumo dati per altri dati di telemetria provenienti dall'app. L'utilizzo dei test Web e l'abilitazione degli avvisi sulle dimensioni della metriche personalizzate vengono comunque segnalati tramite Application Insights. Non è previsto alcun addebito relativo al volume di dati per l'utilizzo di Live Metrics Stream.

Per altre informazioni sui livelli legacy disponibili per gli early adopter di Application Insights, vedere piano tariffario enterprise legacy (per nodo) di Application Insights.

Aree di lavoro con Microsoft Sentinel

Quando Microsoft Sentinel è abilitato in un'area di lavoro Log Analytics, tutti i dati raccolti in tale area di lavoro sono soggetti agli addebiti di Microsoft Sentinel insieme agli addebiti di Log Analytics. Per questo motivo, spesso si separano i dati operativi e di sicurezza in aree di lavoro diverse, in modo che non vengano applicati addebiti di Microsoft Sentinel per i dati operativi.

In alcuni scenari, la combinazione di questi dati può comportare risparmi sui costi. In genere, questa situazione si verifica quando non si raccolgono dati operativi e di sicurezza sufficienti per ognuno per raggiungere un livello di impegno autonomo, ma i dati combinati sono sufficienti per raggiungere un livello di impegno. Per altre informazioni, vedi:

Aree di lavoro con Microsoft Defender per il cloud

Microsoft Defender per server (parte di Defender per il cloud) esegue la fatturazione in base al numero di servizi monitorati. Include 500 MB per server al giorno di allocazione dei dati applicata al subset seguente di tipi di dati di sicurezza:

Se l'area di lavoro è nel piano tariffario legacy per nodo, le allocazioni di Defender per il cloud e Log Analytics vengono combinate e applicate congiuntamente a tutti i dati fatturabili inseriti. Se nell'area di lavoro è abilitato Microsoft Sentinel, se Sentinel usa un piano tariffario classico, l'allocazione dei dati di Defender si applica solo per la fatturazione per l'inserimento dei dati di Log Analytics, ma non per la fatturazione classica di Sentinel. Se Sentinel usa un piano tariffario semplificato, l'allocazione dei dati di Defender si applica alla fatturazione unificata di Sentinel. Per altre informazioni su come i clienti di Microsoft Sentinel possono trarre vantaggio, vedere la pagina dei prezzi di Microsoft Sentinel.

Il conteggio dei server monitorati viene calcolato con una granularità oraria. I contributi di allocazione dei dati giornalieri di ogni server monitorato vengono aggregati a livello di area di lavoro. Se l'area di lavoro è nel piano tariffario legacy per nodo, le allocazioni di Microsoft Defender per il cloud e Log Analytics vengono combinate e applicate congiuntamente a tutti i dati fatturabili inseriti.

Piani tariffari legacy

Le sottoscrizioni che contengono un'area di lavoro Log Analytics o una risorsa di Application Insights il 2 aprile 2018 o che sono collegate a un Contratto Enterprise avviato prima del 1° febbraio 2019 e ancora attivo, continueranno a disporre dell'accesso per usare i piani tariffari legacy seguenti:

  • Autonomo (per GB)
  • Per nodo (Operations Management Suite [OMS])

L'accesso al piano tariffario Versione di valutazione gratuita legacy è stato limitato il 1° luglio 2022. Le informazioni sui prezzi per i piani tariffari Autonomo e Per nodo sono disponibili qui.

Un elenco dei nomi dei contatori di fatturazione di Monitoraggio di Azure, inclusi questi piani legacy, è disponibile qui.

Importante

I piani tariffari legacy non supportano l'accesso ad alcune delle funzionalità più recenti di Log Analytics, ad esempio l'inserimento di dati nelle tabelle con i piani di tabella basic e ausiliari.

Piano tariffario Versione di valutazione gratuita

Le aree di lavoro nel piano tariffario Versione di valutazione gratuita hanno un inserimento dati giornaliero limitato a 500 MB (ad eccezione dei tipi di dati di sicurezza raccolti da Microsoft Defender per il cloud). La conservazione dei dati è limitata a sette giorni. Il piano tariffario Versione di valutazione gratuita è destinato solo a scopo di valutazione, nessun carico di lavoro di produzione. Per il livello Versione di valutazione gratuita non è disponibile alcun Contratto di servizio.

Nota

La creazione di nuove aree di lavoro o lo spostamento di aree di lavoro esistenti nel piano tariffario Versione di valutazione gratuita legacy era possibile solo fino al 1° luglio 2022.

Piano tariffario Autonomo

L'utilizzo nel piano tariffario Autonomo viene fatturato in base al volume di dati inserito. Viene segnalato nel servizio Log Analytics e il contatore è denominato "Dati analizzati". Le aree di lavoro nel piano tariffario Autonomo prevedono una conservazione configurabile dall'utente da 30 a 730 giorni. Le aree di lavoro nel piano tariffario Autonomo non supportano l'uso di piani di tabella basic e ausiliari.

Piano tariffario per nodo

Il piano tariffario Per nodo viene addebitato per ogni macchina virtuale monitorata (nodo) in base a una granularità oraria. Per ogni nodo monitorato, all'area di lavoro vengono allocati 500 MB di dati al giorno che non vengono fatturati. Questa allocazione viene calcolata con granularità oraria e viene aggregata a livello di area di lavoro ogni giorno. I dati inseriti in eccedenza rispetto all'allocazione giornaliera aggregata di dati vengono fatturati per GB come eccedenza di dati. Il piano tariffario Per nodo è un livello legacy, disponibile solo per le sottoscrizioni esistenti che soddisfano i requisiti per piani tariffari legacy.

Nella fattura il servizio sarà Informazioni dettagliate e analisi per l'utilizzo di Log Analytics se l'area di lavoro rientra nel piano tariffario Per nodo. Le aree di lavoro nel piano tariffario Per nodo prevedono una conservazione configurabile dall'utente da 30 a 730 giorni. Le aree di lavoro nel piano tariffario Per nodo non supportano l'uso di piani di tabella basic e ausiliari. L'utilizzo è riportato su tre contatori:

  • Node: utilizzo per il numero di nodi monitorati (VM) in unità di mesi di nodo.
  • Eccedenza dei dati per nodo: numero di GB di dati inseriti in eccesso rispetto all'allocazione di dati aggregati.
  • Dati inclusi per nodo: quantità di dati inseriti coperti dall'allocazione di dati aggregati. Questo contatore viene usato anche quando l'area di lavoro si trova in tutti i piani tariffari per mostrare la quantità di dati coperti da Microsoft Defender per il cloud.

Suggerimento

Se l'area di lavoro ha accesso al piano tariffario Per nodo, ma non si è sicuri se il costo nel livello con pagamento in base al consumo sarebbe inferiore, usare la query seguente per ottenere un suggerimento.

Piani tariffari Standard e Premium

Le aree di lavoro non possono essere create o spostate nei piani tariffari Standard o Premium dal 1° ottobre 2016. Le aree di lavoro già presenti in questi piani tariffari possono continuare a usarli, ma se un'area di lavoro viene spostata all'esterno di questi livelli, non può essere spostata di nuovo. I piani tariffari Standard e Premium hanno una conservazione dei dati fissa rispettivamente di 30 giorni e 365 giorni. Le aree di lavoro in questi piani tariffari non supportano l'uso di piani di tabella basic e ausiliari e la conservazione dei dati a lungo termine. I contatori di inserimento dati nella fattura di Azure per questi livelli legacy sono denominati "Dati analizzati".

Piani tariffari legacy di Microsoft Defender per il cloud

Le considerazioni seguenti riguardano i livelli di Log Analytics legacy e il modo in cui viene fatturato l'utilizzo per Microsoft Defender per il cloud:

  • Se l'area di lavoro è nel piano Standard o Premium legacy, la fattura per Microsoft Defender per il cloud viene emessa solo per l'inserimento dati di Log Analytics e non per nodo.
  • Se l'area di lavoro è nel livello legacy per nodo, la fattura per Microsoft Defender per il cloud viene emessa usando il modello di determinazione prezzi corrente basato su nodi di Microsoft Defender per il cloud.
  • In altri piani tariffari (inclusi i livelli di impegno), se Microsoft Defender per il cloud è stato abilitato prima del 19 giugno 2017, la fattura per Microsoft Defender per il cloud viene emessa solo per l'inserimento dati di Log Analytics. Altrimenti, la fattura per Microsoft Defender per il cloud viene emessa usando il modello di determinazione prezzi corrente basato su nodi di Microsoft Defender per il cloud.

Altre informazioni sulle limitazioni dei piani tariffari sono disponibili in Sottoscrizione di Azure e limiti, quote e vincoli dei servizi.

Nessuno dei piani tariffari legacy ha prezzi basati sull'area.

Nota

Per usare i diritti che derivano dall'acquisto di OMS E1 Suite, OMS E2 Suite o un componente aggiuntivo di OMS per System Center, scegliere il piano tariffario Per nodo di Log Analytics.

Valutare il piano tariffario Per nodo legacy

È spesso difficile determinare se le aree di lavoro con accesso al piano tariffario Per nodo legacy sono migliori rispetto al piano con pagamento in base al consumo o al livello di impegno. Questo implica la comprensione del compromesso tra il costo fisso per ogni nodo monitorato nel piano tariffario Per nodo e l'allocazione dei dati inclusa di 500 MB per nodo al giorno e il costo di pagamento per i dati inseriti nel piano con pagamento in base al consumo (per GB).

Usare la query seguente per formulare un suggerimento per il piano tariffario ottimale in base ai modelli di utilizzo di un'area di lavoro. Questa query esamina i nodi monitorati e i dati inseriti in un'area di lavoro negli ultimi sette giorni. Per ogni giorno, valuta quale piano tariffario sarebbe stato ottimale. Per usare la query, è necessario specificare:

  • Se l'area di lavoro usa Microsoft Defender per il cloud impostando workspaceHasSecurityCenter su true o false.
  • Aggiornare i prezzi se si dispone di sconti specifici.
  • Specificare il numero di giorni per cui eseguire la ricerca e l'analisi impostando daysToEvaluate. Questa opzione è utile se la query richiede troppo tempo per esaminare sette giorni di dati.
// Set these parameters before running query
// For pay-as-you-go (per-GB) and commitment tier pricing details, see https://azure.microsoft.com/pricing/details/monitor/.
// You can see your per-node costs in your Azure usage and charge data. For more information, see https://learn.microsoft.com/azure/cost-management-billing/understand/download-azure-daily-usage.  
let workspaceHasSecurityCenter = true;
let daysToEvaluate = 7;
let PerNodePrice = 15.; // Monthly price per monitored node
let PerNodeOveragePrice = 2.30; // Price per GB for data overage in the Per Node pricing tier
let PerGBPrice = 2.30; // Enter the pay-as-you-go price for your workspace's region (from https://azure.microsoft.com/pricing/details/monitor/)
let CommitmentTier100Price = 196.; // Enter your price for the 100 GB/day commitment tier
let CommitmentTier200Price = 368.; // Enter your price for the 200 GB/day commitment tier
let CommitmentTier300Price = 540.; // Enter your price for the 300 GB/day commitment tier
let CommitmentTier400Price = 704.; // Enter your price for the 400 GB/day commitment tier
let CommitmentTier500Price = 865.; // Enter your price for the 500 GB/day commitment tier
let CommitmentTier1000Price = 1700.; // Enter your price for the 1000 GB/day commitment tier
let CommitmentTier2000Price = 3320.; // Enter your price for the 2000 GB/day commitment tier
let CommitmentTier5000Price = 8050.; // Enter your price for the 5000 GB/day commitment tier
// ---------------------------------------
let SecurityDataTypes=dynamic(["SecurityAlert", "SecurityBaseline", "SecurityBaselineSummary", "SecurityDetection", "SecurityEvent", "WindowsFirewall", "MaliciousIPCommunication", "LinuxAuditLog", "SysmonEvent", "ProtectionStatus", "WindowsEvent", "Update", "UpdateSummary"]);
let StartDate = startofday(datetime_add("Day",-1*daysToEvaluate,now()));
let EndDate = startofday(now());
union * 
| where TimeGenerated >= StartDate and TimeGenerated < EndDate
| extend computerName = tolower(tostring(split(Computer, '.')[0]))
| where computerName != ""
| summarize nodesPerHour = dcount(computerName) by bin(TimeGenerated, 1h)  
| summarize nodesPerDay = sum(nodesPerHour)/24.  by day=bin(TimeGenerated, 1d)  
| join kind=leftouter (
    Heartbeat 
    | where TimeGenerated >= StartDate and TimeGenerated < EndDate
    | where Computer != ""
    | summarize ASCnodesPerHour = dcount(Computer) by bin(TimeGenerated, 1h) 
    | extend ASCnodesPerHour = iff(workspaceHasSecurityCenter, ASCnodesPerHour, 0)
    | summarize ASCnodesPerDay = sum(ASCnodesPerHour)/24.  by day=bin(TimeGenerated, 1d)   
) on day
| join (
    Usage 
    | where TimeGenerated >= StartDate and TimeGenerated < EndDate
    | where IsBillable == true
    | extend NonSecurityData = iff(DataType !in (SecurityDataTypes), Quantity, 0.)
    | extend SecurityData = iff(DataType in (SecurityDataTypes), Quantity, 0.)
    | summarize DataGB=sum(Quantity)/1000., NonSecurityDataGB=sum(NonSecurityData)/1000., SecurityDataGB=sum(SecurityData)/1000. by day=bin(StartTime, 1d)  
) on day
| extend AvgGbPerNode =  NonSecurityDataGB / nodesPerDay
| extend OverageGB = iff(workspaceHasSecurityCenter, 
             max_of(DataGB - 0.5*nodesPerDay - 0.5*ASCnodesPerDay, 0.), 
             max_of(DataGB - 0.5*nodesPerDay, 0.))
| extend PerNodeDailyCost = nodesPerDay * PerNodePrice / 31. + OverageGB * PerNodeOveragePrice
| extend billableGB = iff(workspaceHasSecurityCenter,
             (NonSecurityDataGB + max_of(SecurityDataGB - 0.5*ASCnodesPerDay, 0.)), DataGB )
| extend PerGBDailyCost = billableGB * PerGBPrice
| extend CommitmentTier100DailyCost = CommitmentTier100Price + max_of(billableGB - 100, 0.)* CommitmentTier100Price/100.
| extend CommitmentTier200DailyCost = CommitmentTier200Price + max_of(billableGB - 200, 0.)* CommitmentTier200Price/200.
| extend CommitmentTier300DailyCost = CommitmentTier300Price + max_of(billableGB - 300, 0.)* CommitmentTier300Price/300.
| extend CommitmentTier400DailyCost = CommitmentTier400Price + max_of(billableGB - 400, 0.)* CommitmentTier400Price/400.
| extend CommitmentTier500DailyCost = CommitmentTier500Price + max_of(billableGB - 500, 0.)* CommitmentTier500Price/500.
| extend CommitmentTier1000DailyCost = CommitmentTier1000Price + max_of(billableGB - 1000, 0.)* CommitmentTier1000Price/1000.
| extend CommitmentTier2000DailyCost = CommitmentTier2000Price + max_of(billableGB - 2000, 0.)* CommitmentTier2000Price/2000.
| extend CommitmentTier5000DailyCost = CommitmentTier5000Price + max_of(billableGB - 5000, 0.)* CommitmentTier5000Price/5000.
| extend MinCost = min_of(
    PerNodeDailyCost,PerGBDailyCost,CommitmentTier100DailyCost,CommitmentTier200DailyCost,
    CommitmentTier300DailyCost, CommitmentTier400DailyCost, CommitmentTier500DailyCost, CommitmentTier1000DailyCost, CommitmentTier2000DailyCost, CommitmentTier5000DailyCost)
| extend Recommendation = case(
    MinCost == PerNodeDailyCost, "Per node tier",
    MinCost == PerGBDailyCost, "Pay-as-you-go tier",
    MinCost == CommitmentTier100DailyCost, "Commitment tier (100 GB/day)",
    MinCost == CommitmentTier200DailyCost, "Commitment tier (200 GB/day)",
    MinCost == CommitmentTier300DailyCost, "Commitment tier (300 GB/day)",
    MinCost == CommitmentTier400DailyCost, "Commitment tier (400 GB/day)",
    MinCost == CommitmentTier500DailyCost, "Commitment tier (500 GB/day)",
    MinCost == CommitmentTier1000DailyCost, "Commitment tier (1000 GB/day)",
    MinCost == CommitmentTier2000DailyCost, "Commitment tier (2000 GB/day)",
    MinCost == CommitmentTier5000DailyCost, "Commitment tier (5000 GB/day)",
    "Error"
)
| project day, nodesPerDay, ASCnodesPerDay, NonSecurityDataGB, SecurityDataGB, OverageGB, AvgGbPerNode, PerGBDailyCost, PerNodeDailyCost, 
    CommitmentTier100DailyCost, CommitmentTier200DailyCost, CommitmentTier300DailyCost, CommitmentTier400DailyCost, CommitmentTier500DailyCost, CommitmentTier1000DailyCost, CommitmentTier2000DailyCost, CommitmentTier5000DailyCost, Recommendation 
| sort by day asc
//| project day, Recommendation // Comment this line to see details
| sort by day asc

Questa query non è una replica esatta del modo in cui viene calcolato l'utilizzo, ma fornisce raccomandazioni sui piani tariffari nella maggior parte dei casi.

Nota

Per usare i diritti che derivano dall'acquisto di OMS E1 Suite, OMS E2 Suite o un componente aggiuntivo di OMS per System Center, scegliere il piano tariffario Per nodo di Log Analytics.

Passaggi successivi