Ottimizzazione dei costi in Monitoraggio di Azure
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. Prima di usare questo articolo, è consigliabile vedere Costi e utilizzo di Monitoraggio di Azure per prendere visione delle diverse modalità di addebito di Monitoraggio di Azure e del modo in cui visualizzare la fattura mensile.
Questo articolo illustra l'ottimizzazione dei costi per Monitoraggio di Azure come parte di Azure Well-Architected Framework. Azure Well-Architected Framework è una serie di principi guida utilizzabili per migliorare la qualità dei carichi di lavoro. Il framework è costituito da cinque pilastri di eccellenza dell'architettura:
- Affidabilità
- Sicurezza
- Ottimizzazione dei costi
- Eccellenza operativa
- Efficienza delle prestazioni
Log 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 per le raccomandazioni sui costi di Azure Advisor per le aree di lavoro Log Analytics.
Raccomandazioni per la configurazione
Elemento consigliato | Vantaggio |
---|---|
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 per le raccomandazioni sui costi di 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:
|
Risorse di Azure
Elenco di controllo della progettazione
- Raccogliere solo i dati critici del log delle risorse dalle risorse di Azure.
Raccomandazioni per la configurazione
Elemento consigliato | Vantaggio |
---|---|
Raccogliere solo i dati critici del log delle risorse dalle risorse di Azure. | Quando si creano impostazioni di diagnostica per inviare i log delle risorse per le risorse di Azure a un database di Log Analytics, specificare solo le categorie necessarie. Poiché le impostazioni di diagnostica non consentono il filtro granulare dei log delle risorse, è possibile usare una trasformazione dell'area di lavoro per filtrare i dati non necessarie per le risorse che usano una tabella supportata. Per informazioni dettagliate su come configurare le impostazioni di diagnostica e usare le trasformazioni per filtrare i dati, vedere Impostazioni di diagnostica in Monitoraggio di Azure. |
Avvisi
Elenco di controllo della progettazione
- Gli avvisi del log attività, gli avvisi di integrità dei servizi e gli avvisi di integrità delle risorse sono gratuiti.
- Quando si usano gli avvisi di ricerca log, ridurre al minimo la frequenza dei relativi avvisi.
- Quando si usano gli avvisi delle metriche, ridurre al minimo il numero di risorse monitorate.
Raccomandazioni per la configurazione
Elemento consigliato | Vantaggio |
---|---|
Tenere presente che gli avvisi del log attività, gli avvisi di integrità dei servizi e gli avvisi di integrità delle risorse sono gratuiti. | Gli avvisi di attività di Monitoraggio di Azure, gli avvisi sull'integrità dei servizi e gli avvisi di integrità delle risorse sono gratuiti. Se è possibile eseguire il monitoraggio con questi tipi di avviso, usarli. |
Quando si usano gli avvisi di ricerca log, ridurre al minimo la frequenza dei relativi avvisi. | Quando si configurano gli avvisi di ricerca log, tenere presente che più frequente è la valutazione delle regole, maggiore sarà il costo. Configurare le regole di conseguenza. |
Quando si usano gli avvisi delle metriche, ridurre al minimo il numero di risorse monitorate. | Alcuni tipi di risorse supportano regole di avviso delle metriche che possono monitorare più risorse dello stesso tipo. Per questi tipi di risorse, tenere presente che la regola può diventare costosa se la regola monitora molte risorse. Per ridurre i costi, è possibile ridurre l'ambito della regola di avviso della metrica o usare le regole di avviso di ricerca log, che sono meno costose, per monitorare un numero elevato di risorse. |
Macchine virtuali
Elenco di controllo della progettazione
- Eseguire la migrazione dall'agente di Log Analytics all'agente di Monitoraggio di Azure per un filtro granulare dei dati.
- Filtrare i dati non necessari per gli agenti.
- Determinare se si useranno informazioni dettagliate sulle macchine virtuali e quali dati raccogliere.
- Ridurre la frequenza di polling dei contatori delle prestazioni.
- Assicurarsi che le macchine virtuali non inviino dati duplicati.
- Usare le informazioni dettagliate sull'area di lavoro Log Analytics per analizzare i costi fatturabili e identificare le opportunità di risparmio sui costi.
- Eseguire la migrazione dell'ambiente SCOM a Istanza gestita di SCOM di Monitoraggio di Azure.
Raccomandazioni per la configurazione
Suggerimento | Descrizione |
---|---|
Eseguire la migrazione dall'agente di Log Analytics all'agente di Monitoraggio di Azure per un filtro granulare dei dati. | Se sono ancora presenti macchine virtuali con l'agente di Log Analytics, eseguirne la migrazione all'agente di Monitoraggio di Azure in modo da poter trarre vantaggio da un miglior filtro dei dati e usare configurazioni univoche con diversi set di macchine virtuali. La configurazione per la raccolta dei dati da parte dell'agente di Log Analytics viene eseguita nell'area di lavoro, in modo che tutti gli agenti ricevano la stessa configurazione. Le regole di raccolta dati usate dall'agente di Monitoraggio di Azure possono essere ottimizzate in base ai requisiti di monitoraggio specifici di diversi set di macchine virtuali. L'agente di Monitoraggio di Azure consente anche di usare trasformazioni per filtrare i dati raccolti. |
Filtrare i dati non necessari per gli agenti. | Ridurre i costi di inserimento dei dati filtrando i dati che non si usano per l'invio di avvisi o l'analisi. Vedere Monitorare le macchine virtuali con Monitoraggio di Azure: raccogliere dati per indicazioni sui dati da raccogliere per diversi scenari di monitoraggio e Controllare i costi per indicazioni specifiche sul filtraggio dei dati per ridurre i costi. |
Determinare i dati da raccogliere con informazioni dettagliate sulle macchine virtuali. | Le informazioni dettagliate sulle macchine virtuali costituiscono un'ottima risorsa per iniziare a monitorare le macchine virtuali in modo rapido e offrono funzionalità avanzate, ad esempio Mappa e visualizzazioni di tendenze delle prestazioni. Se non si usa la funzionalità Mappa o i dati da essa raccolti, è necessario disabilitare la raccolta di processi e dati di dipendenza per la configurazione delle informazioni dettagliate sulla macchina virtuale per risparmiare sui costi di inserimento dei dati. |
Ridurre la frequenza di polling dei contatori delle prestazioni. | Se si usa una regola di raccolta dati per inviare dati sulle prestazioni all'area di lavoro Log Analytics, è possibile ridurre la frequenza di polling per diminuire la quantità di dati raccolti. |
Assicurarsi che le macchine virtuali non inviino dati duplicati. | Se si dispone di agenti multi-home o si creano regole di raccolta dati simili, assicurarsi di inviare dati univoci a ogni area di lavoro. Vedere Analizzare l'utilizzo nell'area di lavoro Log Analytics per indicazioni sull'analisi dei dati raccolti in modo da assicurarsi di non raccogliere dati duplicati. Se si esegue la migrazione tra agenti, continuare a usare l'agente di Log Analytics fino a quando non si esegue la migrazione all'agente di Monitoraggio di Azure, anziché usarli entrambi insieme, a meno che non sia possibile assicurarsi che ognuno di essi raccolga dati univoci. |
Usare le informazioni dettagliate sull'area di lavoro Log Analytics per analizzare i costi fatturabili e identificare le opportunità di risparmio sui costi. | Le informazioni dettagliate sull'area di lavoro Log Analytics mostrano i dati fatturabili raccolti in ogni tabella e da ogni macchina virtuale. Usare queste informazioni per identificare i macchinari e le tabelle principali, poiché rappresentano la migliore opportunità per ridurre i costi filtrando i dati. Usare queste informazioni dettagliate e le query di log in Analizzare l'utilizzo nell'area di lavoro Log Analytics per analizzare ulteriormente gli effetti delle modifiche alla configurazione. |
Eseguire la migrazione dell'ambiente SCOM a Istanza gestita SCOM di Monitoraggio di Azure. | Eseguire la migrazione dell'ambiente SCOM esistente a Istanza gestita SCOM di Monitoraggio di Azure per supportare tutti i pacchetti di gestione che non possono essere sostituiti da Monitoraggio di Azure. Istanza gestita SCOM non richiede la manutenzione dei server di gestione e dei server di database locali, riducendo così i costi complessivi di manutenzione dell'infrastruttura SCOM. |
Contenitori
Elenco di controllo della progettazione
- Abilitare la raccolta di metriche tramite il servizio gestito di Monitoraggio di Azure per Prometheus.
- Configurare la raccolta di agenti per modificare la raccolta dei dati in Informazioni dettagliate sui contenitori.
- Modificare le impostazioni per la raccolta dei dati sulle metriche in base a Informazioni dettagliate sui contenitori.
- Disabilitare la raccolta di dati sulle metriche da parte di Informazioni dettagliate sui contenitori se non si usa tale strumento nel portale di Azure.
- Se non si esegue regolarmente una query sulla tabella dei log del contenitore o la si usa per gli avvisi, configurarla come log di base.
- Limitare la raccolta dei log della risorsa non necessari.
- Usare la registrazione specifica delle risorse per i log delle risorse del servizio Azure Kubernetes e configurare le tabelle come log di base.
- Usare OpenCost per raccogliere informazioni dettagliate sui costi di Kubernetes.
Raccomandazioni per la configurazione
Elemento consigliato | Vantaggio |
---|---|
Abilitare la raccolta di metriche tramite il servizio gestito di Monitoraggio di Azure per Prometheus. Assicurarsi di non inviare anche le metriche di Prometheus a un'area di lavoro Log Analytics. | È possibile usare il servizio gestito per Prometheus di Monitoraggio di Azure per lo scorporo delle metriche di Prometheus dal cluster abilitando Prometheus gestito. Si noti che è possibile configurare Informazioni dettagliate sui contenitori per raccogliere le metriche di Prometheus nell'area di lavoro Log Analytics, sebbene non sia consigliabile in quanto i dati di Prometheus gestito sono ridondanti e comportano costi aggiuntivi. Per informazioni dettagliate, vedere Prezzi di Prometheus gestito. |
Configurare l'agente per modificare la raccolta dati in Informazioni dettagliate sui contenitori. | Analizzare i dati raccolti da Informazioni dettagliate contenitore come descritto in Ottimizzare i costi di monitoraggio per le informazioni dettagliate sui contenitori e modificare la configurazione per interrompere la raccolta dei dati non necessari. |
Modificare le impostazioni per la raccolta dei dati sulle metriche in base a Informazioni dettagliate sui contenitori. | Per informazioni dettagliate sulla modifica della frequenza di raccolta dei dati delle metriche e sugli spazi dei nomi raccolti da Informazioni dettagliate sui contenitori, vedere Abilitare le impostazioni di ottimizzazione dei costi. |
Disabilitare la raccolta di dati sulle metriche da parte di Informazioni dettagliate sui contenitori se non si usa tale strumento nel portale di Azure. | Informazioni dettagliate sui contenitori raccoglie in gran parte gli stessi valori delle metriche di Prometheus gestito. È possibile disabilitare la raccolta di tali metriche configurando Informazioni dettagliate sui contenitori in modo che raccolga solo Log ed eventi, come descritto in Abilitare le impostazioni di ottimizzazione dei costi in Informazioni dettagliate sui contenitori. Questa configurazione disabilita l'esperienza di Informazioni dettagliate sui contenitori nel portale di Azure. È tuttavia possibile usare Grafana per visualizzare le metriche di Prometheus e Log Analytics in modo da analizzare i dati di log raccolti da Informazioni dettagliate sui contenitori. |
Se non si esegue regolarmente una query sulla tabella dei log del contenitore o la si usa per gli avvisi, configurarla come log di base. | Convertire lo schema di Informazioni dettagliate contenitore in ContainerLogV2, che è compatibile con i log di base e può offrire risparmi significativi sui costi come descritto in Ottimizzare i costi di monitoraggio per le informazioni dettagliate sui contenitori. |
Limitare la raccolta dei log della risorsa non necessari. | I log del piano di controllo per i cluster del servizio Azure Kubernetes vengono implementati come log delle risorse in Monitoraggio di Azure. Creare un'impostazione di diagnostica per inviare questi dati a un'area di lavoro Log Analytics. Per indicazioni sulle categorie da raccogliere, vedere Raccogliere i log del piano di controllo per i cluster del servizio Azure Kubernetes. |
Usare la registrazione specifica delle risorse per i log delle risorse del servizio Azure Kubernetes e configurare le tabelle come log di base. | Il servizio Azure Kubernetes supporta la modalità di diagnostica di Azure o la modalità specifica della risorsa per i log della risorsa. Specificare i log della risorsa per abilitare l'opzione di configurazione delle tabelle per i log di base, che offrono un addebito ridotto per l'ingestione dei log di cui si esegue una query solo occasionalmente e che non vengono usati per gli avvisi. |
Usare OpenCost per raccogliere informazioni dettagliate sui costi di Kubernetes. | OpenCost è un progetto sandbox CNCF open-source e indipendente dal fornitore che consente di comprendere i costi di Kubernetes e di supportare la possibilità di ottenere la visibilità dei costi del servizio Azure Kubernetes. Esporta dati dettagliati sui costi, oltre ai prezzi di Azure specifici per il cliente, in Archiviazione di Azure per consentire all'amministratore del cluster di analizzare e categorizzare i costi. |
Application Insights
Elenco di controllo della progettazione
- Passare ad Application Insights basato sull'area di lavoro.
- Usare il campionamento per ottimizzare la quantità di dati raccolti.
- Limitare il numero di chiamate AJAX.
- Disabilitare i moduli non necessari.
- Preaggregare le metriche da qualsiasi chiamata a TrackMetric.
- Limitare l'uso di metriche personalizzate, se possibile.
- Garantire l'uso di kit di sviluppo software (SDK) aggiornati.
- Limitare la traccia host indesiderata e la registrazione di traccia generale usando i livelli di log.
Raccomandazioni per la configurazione
Elemento consigliato | Vantaggio |
---|---|
Passare ad Application Insights basato sull'area di lavoro. | Assicurarsi che le risorse di Application Insights siano basate sull'area di lavoro. Le risorse di Application Insights basate sull'area di lavoro possono applicare nuovi strumenti di risparmio sui costi, ad esempio log di base, livelli di impegno e conservazione in base al tipo di dati e a lungo termine. |
Usare il campionamento per ottimizzare la quantità di dati raccolti. | Il campionamento è lo strumento principale che è possibile usare per ottimizzare la quantità di dati raccolti da Application Insights. Usare il campionamento per ridurre la quantità di dati di telemetria inviati dalle applicazioni con una distorsione minima delle metriche. |
Limitare il numero di chiamate AJAX. | Limitare il numero di chiamate Ajax che possono essere segnalate in ogni visualizzazione pagina o disabilitare la creazione di report Ajax. Se si disabilitano le chiamate Ajax, si disabilita anche la correlazione JavaScript. |
Disabilitare i moduli non necessari. | Disattivare i moduli di raccolta non necessari modificando il file ApplicationInsights.config. Ad esempio, si potrebbe decidere che i contatori delle prestazioni o i dati sulle dipendenze non sono necessari. |
Preaggregare le metriche da qualsiasi chiamata a TrackMetric. | Se sono state inserite chiamate a TrackMetric nell'applicazione, è possibile ridurre il traffico usando l'overload che accetta il calcolo della media e la deviazione standard di un batch di misurazioni. In alternativa, è possibile usare un pacchetto di preaggregazione. |
Limitare l'uso di metriche personalizzate. | L'opzione Application Insights che consente di Abilitare gli avvisi sulle dimensioni delle metriche personalizzate può aumentare i costi. L'uso di questa opzione può comportare la creazione di più metriche di preaggregazione. |
Garantire l'uso di kit di sviluppo software (SDK) aggiornati. | Le versioni precedenti di ASP.NET Core SDK e Worker Service SDK raccolgono molti contatori per impostazione predefinita, che erano stati acquisiti come metriche personalizzate. Usare le versioni successive per specificare solo i contatori obbligatori. |
Limitare la registrazione delle tracce indesiderate. | Application Insights include diverse origini log possibili. I livelli di log possono essere usati per ottimizzare e ridurre i dati di telemetria del log di traccia. La registrazione può essere applicata anche all'host. Ad esempio, i clienti che usano il servizio Azure Kubernetes devono modificare il piano di controllo e i log del piano dati. Analogamente, i clienti che usano Funzioni di Azure devono adattare i livelli di log e l'ambito per ottimizzare il volume e i costi dei log. |