Condividi tramite

Prospettiva di Azure Well-Architected Framework in Log Analytics

  • Articolo

Well-Architected Framework la funzionalità del carico di lavoro e le prestazioni devono essere monitorate in modi diversi e per motivi diversi. Le aree di lavoro Log Analytics di Monitoraggio di Azure sono il sink di log e metrica primario per una grande parte dei dati di monitoraggio. Le aree di lavoro supportano più funzionalità in Monitoraggio di Azure, tra cui query ad hoc, visualizzazioni e avvisi. Per i principi di monitoraggio generale, vedere Linee guida per il monitoraggio e la diagnostica. Le linee guida presentano principi di monitoraggio generali. Identifica i diversi tipi di dati. Identifica l'analisi necessaria supportata da Monitoraggio di Azure e identifica anche i dati archiviati nell'area di lavoro che abilita l'analisi.

Questo articolo presuppone che si comprendano i principi di progettazione del sistema. È inoltre necessaria una conoscenza funzionante delle aree di lavoro e delle funzionalità di Log Analytics in Monitoraggio di Azure che popolano i dati del carico di lavoro operativo. Per altre informazioni, vedere Panoramica dell'area di lavoro Log Analytics.

Importante

Come usare questa guida

Ogni sezione include un elenco di controllo di progettazione che presenta aree di interesse per l'architettura insieme alle strategie di progettazione localizzate nell'ambito della tecnologia.

Sono incluse anche raccomandazioni sulle funzionalità tecnologiche o sulle topologie di distribuzione che possono aiutare a materializzare tali strategie. Le raccomandazioni non rappresentano un elenco completo di tutte le configurazioni disponibili per le aree di lavoro Log Analytics e le relative risorse di Monitoraggio di Azure. Elencano invece le raccomandazioni principali mappate alle prospettive di progettazione. Usare i consigli per compilare il concetto di prova, progettare l'ambiente di monitoraggio del carico di lavoro o ottimizzare la soluzione di monitoraggio del carico di lavoro esistente.

Ambito tecnologico

Questa guida si concentra sulle decisioni correlate per le risorse di Azure seguenti.

  • Aree di lavoro di Log Analytics
  • Dati del log operativo del carico di lavoro
  • Impostazioni di diagnostica nelle risorse di Azure nel carico di lavoro

Affidabilità

Lo scopo del pilastro Affidabilità è quello di offrire funzionalità continue creando sufficienti resilienza e la capacità di ripristinare rapidamente gli errori.

I principi di progettazione di affidabilità forniscono una strategia di progettazione di alto livello applicata per singoli componenti, flussi di sistema e il sistema nel suo complesso.

Le situazioni di affidabilità da considerare per le aree di lavoro Log Analytics sono:

  • Disponibilità dell'area di lavoro.
  • Protezione dei dati raccolti nel raro caso di errore di un data center o di un'area di Azure.

Attualmente non è disponibile alcuna funzionalità standard per il failover tra aree di lavoro in aree diverse, ma esistono strategie da usare se si hanno requisiti specifici per la disponibilità o la conformità.

Elenco di controllo di progettazione per affidabilità

Avviare la strategia di progettazione in base all'elenco di controllo di revisione della progettazione per Affidabilità e determinare la relativa rilevanza per i requisiti aziendali, tenendo presente gli SKU e le funzionalità delle macchine virtuali e le relative dipendenze. Estendere la strategia per includere più approcci in base alle esigenze.

  • Esaminare i limiti del servizio per le aree di lavoro di Log Analytics. La sezione Limiti del servizio consente di comprendere le restrizioni relative alla raccolta e alla conservazione dei dati e ad altri aspetti del servizio. Questi limiti consentono di determinare come progettare correttamente la strategia di osservabilità del carico di lavoro. Assicurarsi di esaminare i limiti dei servizi di Monitoraggio di Azure poiché molte delle funzioni descritte in questo caso, ad esempio le query, funzionano a mano con le aree di lavoro Log Analytics.
  • Pianificare la resilienza e il ripristino dell'area di lavoro. Le aree di lavoro di Log Analytics sono a livello di area, senza supporto predefinito per la ridondanza tra aree o la replica. Inoltre, le opzioni di ridondanza della zona di disponibilità sono limitate. Di conseguenza, è necessario determinare i requisiti di affidabilità delle aree di lavoro e strategizzare per soddisfare tali destinazioni. I requisiti potrebbero stabilire che l'area di lavoro deve essere resiliente agli errori del data center o agli errori a livello di area oppure potrebbe stabilire che è necessario ripristinare i dati in una nuova area di lavoro in un'area di failover. Ognuno di questi scenari richiede risorse e processi aggiuntivi da mettere in atto per avere esito positivo, pertanto il bilanciamento delle destinazioni di affidabilità con costi e complessità deve essere considerato attentamente.
  • Scegliere le aree di distribuzione appropriate per soddisfare i requisiti di affidabilità. Distribuire l'area di lavoro Log Analytics e gli endpoint di raccolta dati (DCEs) che si trovano con i componenti del carico di lavoro che emettono dati operativi. La scelta dell'area appropriata in cui distribuire l'area di lavoro e i controller di dominio devono essere informati dalla posizione in cui si distribuisce il carico di lavoro. Potrebbe essere necessario valutare la disponibilità a livello di area di determinate funzionalità di Log Analytics, ad esempio cluster dedicati, rispetto ad altri fattori più centrali per l'affidabilità, i costi e le prestazioni del carico di lavoro.
  • Assicurarsi che i sistemi di osservabilità siano integri. Come qualsiasi altro componente del carico di lavoro, assicurarsi che i sistemi di monitoraggio e registrazione funzionino correttamente. A questo scopo, abilitare le funzionalità che inviano segnali di integrità ai team operativi. Configurare i segnali di integrità specifici per le aree di lavoro Log Analytics e le risorse associate.

Consigli di configurazione per affidabilità

Recommendation Vantaggi
Non includere le aree di lavoro Log Analytics nel percorso critico del carico di lavoro. Le aree di lavoro sono importanti per un sistema di osservabilità funzionante, ma la funzionalità del carico di lavoro non deve dipendere da essi. Mantenere le aree di lavoro e le funzioni associate fuori dal percorso critico del carico di lavoro riduce al minimo il rischio di problemi che influiscono sul sistema di osservabilità dall'impatto sull'esecuzione del runtime del carico di lavoro.
Per supportare la durabilità elevata dei dati dell'area di lavoro, distribuire aree di lavoro Log Analytics in un'area che supporta la resilienza dei dati. La resilienza dei dati è possibile solo tramite il collegamento dell'area di lavoro a un cluster dedicato nella stessa area. Quando si usa un cluster dedicato, consente di distribuire le aree di lavoro associate in zone di disponibilità, che offrono protezione dalle interruzioni del data center. Se non si raccolgono dati sufficienti per giustificare un cluster dedicato, questa scelta regionale preemptive supporta la crescita futura.
Scegliere la distribuzione dell'area di lavoro in base alla prossimità al carico di lavoro.

Usare gli endpoint di raccolta dati (DCE) nella stessa area dell'area di lavoro Log Analytics.		 Distribuire l'area di lavoro nella stessa area delle istanze del carico di lavoro. L'uso dell'area di lavoro e dei controller di dominio nella stessa area del carico di lavoro riduce il rischio di interruzioni in altre aree.

I controller di dominio vengono usati dall'agente di Monitoraggio di Azure e dall'API inserimento log per inviare i dati operativi del carico di lavoro a un'area di lavoro Log Analytics. Potrebbe essere necessario più controller di dominio anche se la distribuzione dispone solo di una singola area di lavoro. Per altre informazioni su come configurare i controller di dominio per l'ambiente specifico, vedere Come configurare gli endpoint di raccolta dati in base alla distribuzione.<Br
Se il carico di lavoro viene distribuito in una progettazione attiva, prendere in considerazione l'uso di più aree di lavoro e controller di dominio distribuite tra le aree in cui viene distribuito il carico di lavoro.

La distribuzione di aree di lavoro in più aree aggiunge complessità all'ambiente. Bilanciare i criteri dettagliati in Progettare un'architettura dell'area di lavoro Log Analytics con i requisiti di disponibilità.
Se è necessario che l'area di lavoro sia disponibile in un errore di area o non si raccolgono dati sufficienti per un cluster dedicato, configurare la raccolta dati per inviare dati critici a più aree di lavoro in aree diverse. Questa procedura è nota anche come multicast dei log.

Ad esempio, configurare i controller di dominio per più aree di lavoro per l'agente di Monitoraggio di Azure in esecuzione nelle macchine virtuali. Configurare più impostazioni di diagnostica per raccogliere i log delle risorse dalle risorse di Azure e inviare i log a più aree di lavoro.
In questo modo, i dati operativi del carico di lavoro sono disponibili nell'area di lavoro alternativa se si verifica un errore a livello di area. Tuttavia, sapere che le risorse che si basano sui dati, ad esempio avvisi e cartelle di lavoro, non verranno replicate automaticamente nelle altre aree. Valutare la possibilità di archiviare modelli di Azure Resource Manager (ARM) per l'avviso critico con la configurazione per l'area di lavoro alternativa o distribuirli in tutte le aree, ma disabilitandoli per evitare avvisi ridondanti. Entrambe le opzioni supportano l'abilitazione rapida in un errore a livello di area.

Compromesso: questa configurazione comporta addebiti di inserimento e conservazione duplicati in modo da usarlo solo per i dati critici.
Se è necessario proteggere i dati in un data center o in un errore di area, configurare l'esportazione dei dati dall'area di lavoro per salvare i dati in una posizione alternativa.

Questa opzione è simile all'opzione precedente di multicasting dei dati in aree di lavoro diverse. Questa opzione, tuttavia, costa meno perché i dati aggiuntivi vengono scritti nell'archiviazione.

Usare le opzioni di ridondanza dell'archiviazione di Azure, tra cui archiviazione con ridondanza geografica e archiviazione con ridondanza geografica (GZRS) per replicare ulteriormente questi dati in altre aree.

L'esportazione dei dati non offre resilienza contro gli eventi imprevisti che influisce sulla pipeline di inserimento a livello di area.		 Anche se i dati dei log operativi storici potrebbero non essere facilmente queryabili nello stato esportato, garantisce che i dati superino un'interruzione a livello di area prolungata e possano essere accessibili e mantenuti per periodi estesi.

Se è necessaria l'esportazione di tabelle non supportate dall'esportazione dei dati, è possibile usare altri metodi di esportazione dei dati, tra cui App per la logica, per proteggere i dati.

Per questo motivo, questa strategia può funzionare come piano di ripristino valida, è necessario disporre di processi per riconfigurare le impostazioni di diagnostica per le risorse in Azure e in tutti gli agenti che forniscono dati. È anche necessario pianificare manualmente di riattivare i dati esportati in una nuova area di lavoro. Come per l'opzione descritta in precedenza, è anche necessario definire i processi per tali risorse che si basano sui dati come avvisi e cartelle di lavoro.
Per i carichi di lavoro cruciali che richiedono disponibilità elevata, è consigliabile implementare un modello di area di lavoro federato che usa più aree di lavoro per offrire disponibilità elevata se si verifica un errore a livello di area. Mission-critical fornisce indicazioni sulle procedure consigliate prescrittive per la progettazione di applicazioni altamente affidabili in Azure. La metodologia di progettazione include un modello di area di lavoro federata con più aree di lavoro Log Analytics per offrire la disponibilità elevata se si verificano più errori, tra cui l'errore di un'area di Azure.

Questa strategia elimina i costi di uscita tra aree e rimane operativa con un errore di area. Ma richiede una maggiore complessità che è necessario gestire con la configurazione e i processi descritti in Modellazione dell'integrità e osservabilità dei carichi di lavoro cruciali in Azure.
Usare l'infrastruttura come codice (IaC) per distribuire e gestire le aree di lavoro e le funzioni associate. Quando si automatizza la maggior parte della distribuzione e i meccanismi per la resilienza e il ripristino, garantisce che queste operazioni siano affidabili. È possibile risparmiare tempo critico nei processi operativi e ridurre al minimo il rischio di errore umano.

Assicurarsi che le funzioni come le query di log salvate vengano definite anche tramite l'IaC per ripristinarle in una nuova area se è necessario il ripristino.
Progettare controller di dominio con un unico principio di responsabilità per mantenere semplici le regole del DCR.

Anche se un DCR può essere caricato con tutti gli input, le regole e le destinazioni per i sistemi di origine, è preferibile progettare regole incentrate in modo ristretto che si basano su un minor numero di origini dati. Usare la composizione delle assegnazioni di regole per arrivare all'ambito di osservabilità desiderato per la destinazione logica.

Inoltre, ridurre al minimo la trasformazione nei controller di dominio		 Quando si usano controller di dominio con stato limitato, riduce al minimo il rischio di errori di configurazione di una regola con un effetto più ampio. Limita l'effetto solo all'ambito per il quale è stato compilato il DCR. Per altre informazioni, vedere Procedure consigliate per la creazione e la gestione delle regole di raccolta dati in Monitoraggio di Azure.

Anche se la trasformazione può essere potente e necessaria in alcune situazioni, può essere difficile testare e risolvere i problemi relativi al lavoro del linguaggio di query delle parole chiave (KQL). Quando possibile, ridurre al minimo il rischio di perdita di dati inserendo i dati non elaborati e gestendo le trasformazioni downstream in fase di query.
Quando si imposta un limite giornaliero o un criterio di conservazione, assicurarsi di mantenere i requisiti di affidabilità inserendo e mantenendo i log necessari. Un limite giornaliero interrompe la raccolta di dati per un'area di lavoro una volta raggiunta una quantità specificata, che consente di mantenere il controllo sul volume di inserimento. Ma usare questa funzionalità solo dopo un'attenta pianificazione. Assicurarsi che il limite giornaliero non venga raggiunto con regolarità. In tal caso, il limite viene impostato in modo troppo restrittivo. È necessario riconfigurare il limite giornaliero in modo da non perdere i segnali critici provenienti dal carico di lavoro.

Analogamente, assicurarsi di adottare attentamente e attentamente l'abbassamento dei criteri di conservazione dei dati per assicurarsi che non si perdano accidentalmente dati critici.
Usare le informazioni dettagliate sull'area di lavoro Log Analytics per tenere traccia del volume di inserimento, dei dati inseriti rispetto al limite di dati, alle origini di log non rispondenti e alle query non riuscite tra gli altri dati. Creare avvisi 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. Questa strategia garantisce che sia possibile monitorare correttamente l'integrità delle aree di lavoro e agire in modo proattivo se l'integrità è a rischio di degrado. Come qualsiasi altro componente del carico di lavoro, è fondamentale conoscere le metriche di integrità e identificare le tendenze per migliorare l'affidabilità nel tempo.

Criteri di Azure

Azure non offre criteri correlati all'affidabilità delle aree di lavoro Log Analytics. È possibile creare criteri personalizzati per creare protezioni di conformità per le distribuzioni dell'area di lavoro, ad esempio per garantire che le aree di lavoro siano associate a un cluster dedicato.

Anche se non direttamente correlato all'affidabilità delle aree di lavoro Log Analytics, esistono criteri di Azure per quasi tutti i servizi disponibili. I criteri assicurano che le impostazioni di diagnostica siano abilitate per tale servizio e verificare che i dati di log del servizio vengano trasmessi in un'area di lavoro Log Analytics. Tutti i servizi nell'architettura del carico di lavoro devono inviare i dati di log a un'area di lavoro Log Analytics per le proprie esigenze di affidabilità e i criteri possono essere utili per applicarli. Analogamente, esistono criteri per garantire che le piattaforme basate su agente, ad esempio le macchine virtuali e Kubernetes, abbiano installato l'agente.

Azure Advisor

Azure non offre raccomandazioni di Azure Advisor relative all'affidabilità delle aree di lavoro Log Analytics.

Sicurezza

Lo scopo del pilastro Sicurezza è fornire garanzie di riservatezza, integrità e disponibilità al carico di lavoro.

I principi di progettazione della sicurezza forniscono una strategia di progettazione di alto livello per raggiungere questi obiettivi applicando approcci alla progettazione tecnica intorno alla soluzione di monitoraggio e registrazione.

Elenco di controllo per la progettazione per la sicurezza

Avviare la strategia di progettazione in base all'elenco di controllo della revisione della progettazione per La sicurezza e identificare vulnerabilità e controlli per migliorare il comportamento di sicurezza. Estendere la strategia in modo da includere più approcci in base alle esigenze.

  • Esaminare la baseline di sicurezza di Monitoraggio di Azure e Gestire l'accesso alle aree di lavoro Log Analytics. Questi argomenti forniscono indicazioni sulle procedure consigliate per la sicurezza.
  • Distribuire le aree di lavoro con la segmentazione come principio fondamentale. Implementare la segmentazione a livello di rete, dati e accesso. La segmentazione consente di garantire che le aree di lavoro siano isolate in base al livello appropriato e siano protette meglio dall'accesso non autorizzato al massimo livello possibile, rispettando comunque i requisiti aziendali per affidabilità, ottimizzazione dei costi, eccellenza operativa ed efficienza delle prestazioni.
  • Assicurarsi di poter controllare le operazioni di lettura e scrittura dell'area di lavoro e le identità associate. Gli utenti malintenzionati possono trarre vantaggio dalla visualizzazione dei log operativi. Un'identità compromessa può causare attacchi di inserimento dei log. Abilitare il controllo delle operazioni eseguite dal portale di Azure o tramite le interazioni con le API e gli utenti associati. Se non si è configurati per controllare l'area di lavoro, è possibile che l'organizzazione sia a rischio di violazione dei requisiti di conformità.
  • Implementare controlli di rete affidabili. Consente di proteggere l'accesso alla rete all'area di lavoro e ai log tramite funzioni firewall e isolamento di rete. I controlli di rete configurati in modo insufficiente potrebbero causare l'accesso da parte di attori non autorizzati o dannosi.
  • Determinare quali tipi di dati necessitano di immutabilità o conservazione a lungo termine. I dati di log devono essere trattati con lo stesso rigore dei dati del carico di lavoro all'interno dei sistemi di produzione. Includere i dati di log nelle procedure di classificazione dei dati per assicurarsi di archiviare correttamente i dati di log sensibili in base ai requisiti di conformità.
  • Proteggere i dati di log inattivi tramite la crittografia. La segmentazione da sola non proteggerà completamente la riservatezza dei dati di log. Se si verifica un accesso non elaborato non autorizzato, la crittografia dei dati di log inattivi consente di impedire agli attori malintenzionati di usare tali dati all'esterno dell'area di lavoro.
  • Proteggere i dati dei log sensibili tramite offuscamento. Analogamente ai dati del carico di lavoro che risiedono nei sistemi di produzione, è necessario adottare misure aggiuntive per garantire che la riservatezza venga mantenuta per informazioni riservate che potrebbero essere intenzionalmente o involontariamente presenti nei log operativi. Quando si usano metodi di offuscamento, consente di nascondere i dati di log sensibili da occhi non autorizzati.

Consigli di configurazione per la sicurezza

Recommendation Vantaggi
Usare le chiavi gestite dal cliente se è necessaria la propria chiave di crittografia per proteggere i dati e le query salvate nelle aree di lavoro.

Monitoraggio di Azure garantisce che tutti i dati e le query salvate vengano crittografati inattivi usando chiavi gestite da Microsoft (MMK). Se è necessaria la propria chiave di crittografia e si raccolgono dati sufficienti per un cluster dedicato, usare la chiave gestita dal cliente. È possibile crittografare i dati usando la propria chiave in Azure Key Vault, per controllare il ciclo di vita della chiave e revocare l'accesso ai dati.

Se si usa Microsoft Sentinel, assicurarsi di avere familiarità con le considerazioni riportate in Configurare la chiave gestita dal cliente di Microsoft Sentinel.		 Questa strategia consente di crittografare i dati usando la propria chiave in Azure Key Vault, per controllare il ciclo di vita della chiave e di revocare l'accesso ai dati.
Configurare il controllo delle query di log per tenere traccia degli utenti che eseguono query.

Configurare i log di controllo per ogni area di lavoro da inviare all'area di lavoro locale o consolidare in un'area di lavoro di sicurezza dedicata se si separano i dati operativi e di sicurezza. Usare le informazioni dettagliate sull'area di lavoro Log Analytics per esaminare periodicamente questi dati. Valutare la possibilità di creare regole di avviso per le query di log per notificare in modo proattivo se gli utenti non autorizzati tentano di eseguire query.		 Il controllo delle query di log registra i dettagli per ogni query eseguita in un'area di lavoro. Considerare questi dati di controllo come dati di sicurezza e proteggere la tabella LAQueryLogs in modo appropriato. Questa strategia rafforza il comportamento di sicurezza aiutando a garantire che l'accesso non autorizzato venga intercettato immediatamente, se mai accade.
Proteggere l'area di lavoro tramite misure di segmentazione e rete privata.

Usare la funzionalità di collegamento privato per limitare le comunicazioni tra le origini di log e le aree di lavoro alla rete privata.		 Quando si usa il collegamento privato, consente anche di controllare quali reti virtuali possono accedere a una determinata area di lavoro, oltre a rafforzare la sicurezza tramite la segmentazione.
Usare Microsoft Entra ID anziché le chiavi API per l'accesso all'API dell'area di lavoro, se disponibile. L'accesso basato su chiave API alle API di query non lascia un audit trail per client. Usare l'accesso in base all'ID Entra con ambito sufficiente in modo da poter controllare correttamente l'accesso a livello di codice.
Configurare l'accesso per diversi tipi di dati nell'area di lavoro necessaria per ruoli diversi nell'organizzazione.

Impostare la modalità di controllo di accesso per l'area di lavoro su Usa autorizzazioni risorsa o area di lavoro. Questo controllo di accesso consente ai proprietari di risorse di usare il contesto delle risorse per accedere ai dati senza concedere l'accesso esplicito all'area di lavoro.

Usare 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.		 Questa impostazione semplifica la configurazione dell'area di lavoro e consente agli utenti di non accedere ai dati operativi che non devono.

Assegnare il ruolo predefinito appropriato per concedere le autorizzazioni dell'area di lavoro agli amministratori a livello di sottoscrizione, gruppo di risorse o area di lavoro a seconda dell'ambito delle responsabilità.

Gli utenti con autorizzazioni di tabella hanno accesso a tutti i dati nella tabella indipendentemente dalle relative autorizzazioni per le risorse.

Per informazioni dettagliate sulle diverse opzioni per concedere l'accesso ai dati nell'area di lavoro, vedere Gestire l'accesso alle aree di lavoro Log Analytics .
Esportare i log che richiedono conservazione a lungo termine o immutabilità.

Usare l'esportazione dei dati per inviare dati a un account di archiviazione di Azure con criteri di immutabilità che consentono di proteggersi da manomissioni dei dati. Non tutti i tipi di log hanno la stessa rilevanza per la conformità, il controllo o la sicurezza, quindi determinare i tipi di dati specifici che devono essere esportati.		 È possibile raccogliere dati di controllo nell'area di lavoro soggetti a normative che richiedono la conservazione a lungo termine. I dati in un'area di lavoro Log Analytics non possono essere modificati, ma possono essere eliminati. L'esportazione di una copia dei dati operativi a scopo di conservazione consente di creare una soluzione che soddisfi i requisiti di conformità.
Determinare una strategia per filtrare o offuscare i dati sensibili nell'area di lavoro.

È possibile raccogliere dati che includono informazioni riservate. Filtrare i record che non devono essere raccolti usando la configurazione per l'origine dati specifica. Utilizzare una trasformazione se devono essere rimosse o offuscate solo colonne particolari nei dati.

Se si dispone di standard che richiedono che i dati originali non vengano modificato, è possibile usare il valore letterale "h" nelle query KQL per offuscare i risultati delle query visualizzati nelle cartelle di lavoro.		 Offuscare o filtrare i dati sensibili nell'area di lavoro consente di mantenere la riservatezza sulle informazioni riservate. In molti casi, i requisiti di conformità determinano i modi in cui è possibile gestire le informazioni riservate. Questa strategia consente di rispettare i requisiti in modo proattivo.

Criteri di Azure

Azure offre criteri correlati alla sicurezza delle aree di lavoro Log Analytics per applicare il comportamento di sicurezza desiderato. Esempi di tali criteri sono:

Azure offre anche numerosi criteri che consentono di applicare la configurazione dei collegamenti privati, ad esempio le aree di lavoro Log Analytics devono bloccare l'inserimento dei log e l'esecuzione di query da reti pubbliche o anche configurare la soluzione tramite criteri DINE, ad esempio Configurare Monitoraggio di Azure collegamento privato Ambito per l'uso di zone DNS private.

Azure Advisor

Azure non offre raccomandazioni di Azure Advisor relative alla sicurezza delle aree di lavoro Log Analytics.

Ottimizzazione dei costi

Ottimizzazione dei costi è incentrata sul rilevamento dei modelli di spesa, sulla definizione delle priorità degli investimenti in aree critiche e sull'ottimizzazione in altri casi in modo da soddisfare il budget dell'organizzazione, rispettando al tempo stesso i requisiti aziendali.

I principi di progettazione di Ottimizzazione costi forniscono una strategia di progettazione di alto livello per raggiungere tali obiettivi aziendali. Consentono inoltre di effettuare compromessi in base alle esigenze nella progettazione tecnica relativa alla soluzione di monitoraggio e registrazione.

Per altre informazioni sul modo in cui vengono calcolati gli addebiti per i dati per le aree di lavoro Log Analytics, vedere Calcoli e opzioni dei costi dei log di Monitoraggio di Azure.

Elenco di controllo per la progettazione per l'ottimizzazione dei costi

Avviare la strategia di progettazione in base all'elenco di controllo della revisione della progettazione per l'ottimizzazione dei costi per gli investimenti e ottimizzare la progettazione in modo che il carico di lavoro sia allineato al budget allocato per il carico di lavoro. La progettazione deve usare le funzionalità di Azure appropriate, monitorare gli investimenti e trovare opportunità per ottimizzare nel tempo.

  • Eseguire esercizi di modellazione dei costi. Queste attività consentono di comprendere i costi correnti dell'area di lavoro e prevedere i costi relativi alla crescita dell'area di lavoro. Analizzare le tendenze di crescita nel carico di lavoro e assicurarsi di comprendere i piani di espansione del carico di lavoro per prevedere correttamente i costi di registrazione operativa futuri.
  • Scegliere il modello di fatturazione corretto. Usare il modello di costo per determinare il modello di fatturazione migliore per lo scenario. Il modo in cui si usano attualmente le aree di lavoro e come si prevede di usarle man mano che il carico di lavoro si evolve determina se un modello con pagamento in base al consumo o un modello di livello di impegno è la scelta migliore per lo scenario.

    Tenere presente che è possibile scegliere modelli di fatturazione diversi per ogni area di lavoro ed è possibile combinare i costi dell'area di lavoro in determinati casi, in modo da poter essere granulari nell'analisi e nel processo decisionale.
  • Raccogliere solo la giusta quantità di dati di log. Eseguire regolarmente l'analisi pianificata delle impostazioni di diagnostica sulle risorse, la configurazione delle regole di raccolta dati e la registrazione del codice dell'applicazione personalizzata per assicurarsi di non raccogliere dati di log non necessari.
  • Trattare ambienti non di produzione in modo diverso rispetto alla produzione. Esaminare gli ambienti non di produzione per assicurarsi di aver configurato le impostazioni di diagnostica e i criteri di conservazione in modo appropriato. Questi possono spesso essere significativamente meno affidabili rispetto alla produzione, soprattutto per ambienti di sviluppo/test o sandbox.

Consigli di configurazione per l'ottimizzazione dei costi

Recommendation Vantaggi
Configurare il piano tariffario per la quantità di dati raccolti in genere da ogni area di lavoro Log Analytics. Per impostazione predefinita, le aree di lavoro Log Analytics usano prezzi con pagamento in base al consumo senza volume di dati minimo. Se si raccolgono dati sufficienti, è possibile ridurre significativamente il costo usando un livello di impegno, che consente di eseguire il commit in un minimo giornaliero di dati raccolti in cambio di un tasso inferiore. Se si raccolgono dati sufficienti tra aree di lavoro in una singola area, è possibile collegarli a un cluster dedicato e combinare il volume raccolto usando i prezzi del cluster.

Per altre informazioni sui livelli di impegno e indicazioni su come determinare il livello di utilizzo più appropriato, vedere Calcoli e opzioni dei costi dei log di Monitoraggio di Azure. Per visualizzare i costi stimati per l'utilizzo in piani tariffari diversi, vedere Utilizzo e costi stimati.
Configurare la conservazione e l'archiviazione dei dati. È previsto un addebito per la conservazione dei dati in un'area di lavoro Log Analytics oltre il valore predefinito di 31 giorni. Si tratta di 90 giorni se Microsoft 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 facilmente disponibili per le query di log. È possibile ridurre significativamente i costi configurando i log archiviati. I log archiviati consentono di conservare i dati per un massimo di sette anni e di accedervi occasionalmente. È possibile accedere ai dati usando i processi di ricerca o ripristinando un set di dati nell'area di lavoro.
Se si usa Microsoft Sentinel per analizzare i log di sicurezza, è consigliabile usare un'area di lavoro separata per archiviare tali log. Quando si usa un'area di lavoro dedicata per i dati di log usati da SIEM, è possibile controllare i costi. Le aree di lavoro usate da Microsoft Sentinel sono soggette ai prezzi di Microsoft Sentinel. I requisiti di sicurezza determinano i tipi di log necessari per essere inclusi nella soluzione SIEM. È possibile escludere i log operativi, che verranno addebitati in base ai prezzi standard di Log Analytics se si trovano in un'area di lavoro separata.
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 configurate per i log di base hanno un costo di inserimento inferiore in cambio di funzionalità limitate e un addebito per le query di log. Se si eseguono query su queste tabelle raramente e non vengono usate per l'invio di avvisi, il costo della query può essere superiore a quello del 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. Assicurarsi di raccogliere non più dati di quanto necessario per valutare l'integrità e le prestazioni dei servizi e delle applicazioni. Per ogni risorsa, selezionare le categorie appropriate per le impostazioni di diagnostica configurate per fornire la quantità di dati operativi necessari. Consente di gestire correttamente il carico di lavoro e di non gestire i dati ignorati.

Potrebbe verificarsi un compromesso tra i costi e i requisiti di monitoraggio. Ad esempio, potrebbe essere possibile rilevare un problema di prestazioni più rapidamente con una frequenza di campionamento elevata, ma potrebbe essere necessario ridurre la frequenza di campionamento per risparmiare i costi. La maggior parte degli ambienti dispone di più origini dati con diversi tipi di raccolta, quindi è necessario bilanciare i requisiti specifici con le destinazioni di costo per ognuna. Per consigli sulla configurazione della raccolta per origini dati diverse , vedere Ottimizzazione dei costi in Monitoraggio di Azure .
Analizzare regolarmente i dati di utilizzo dell'area di lavoro 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. Analizzare ulteriormente la raccolta dei dati usando i metodi in Analizzare l'utilizzo nell'area di lavoro Log Analytics per determinare se sono presenti altre configurazioni che possono ridurre ulteriormente l'utilizzo.		 Aiutandoti a comprendere la quantità di dati raccolti da origini diverse, identifica le anomalie e le tendenze verso l'alto nella raccolta dei dati che potrebbero comportare costi in eccesso. Questa considerazione è importante quando si aggiunge un nuovo set di origini dati al carico di lavoro. Ad esempio, se si aggiunge un nuovo set di macchine virtuali, abilitare nuove impostazioni di diagnostica di Azure in un servizio o modificare i livelli di log nell'applicazione.
Creare un avviso quando la raccolta dati è elevata. Per evitare fatture impreviste, è consigliabile ricevere una notifica proattiva ogni volta che si verifica un utilizzo eccessivo. La notifica consente di risolvere eventuali potenziali anomalie prima della fine del periodo di fatturazione.
Considerare un limite giornaliero come misura preventiva per assicurarsi di non superare un budget specifico. Un limite giornaliero disabilita la raccolta dati in un'area di lavoro Log Analytics per il resto del giorno dopo il raggiungimento del limite configurato. Non usare questa procedura come metodo per ridurre i costi come descritto in Quando usare un limite giornaliero, ma per evitare l'inserimento in fuga a causa di errori di configurazione o abusi.

Se si imposta un limite giornaliero, creare un avviso quando viene raggiunto il limite. Assicurarsi di creare anche una regola di avviso quando viene raggiunta una percentuale. Ad esempio, è possibile impostare una regola di avviso per quando viene raggiunta la capacità del 90%. Questo avviso consente di analizzare e risolvere la causa dell'aumento dei dati prima che il limite arresti la raccolta di dati critici dal carico di lavoro.

Criteri di Azure

Azure non offre criteri correlati all'ottimizzazione dei costi delle aree di lavoro Log Analytics. È possibile creare criteri personalizzati per creare protezioni di conformità per le distribuzioni dell'area di lavoro, ad esempio per garantire che le aree di lavoro contengano le impostazioni di conservazione appropriate.

Azure Advisor

Azure Advisor offre raccomandazioni per spostare tabelle specifiche in un'area di lavoro nel piano dati di log di base a basso costo per le tabelle che ricevono un volume di inserimento relativamente elevato. Comprendere le limitazioni usando i log di base prima di passare. Per altre informazioni, vedere Quando usare i log di base?. Azure Advisor potrebbe anche consigliare di modificare il piano di impegno tariffario per l'intera area di lavoro in base al volume di utilizzo complessivo.

Eccellenza operativa

L'eccellenza operativa si concentra principalmente sulle procedure per le procedure di sviluppo, l'osservabilità e la gestione del rilascio.

I principi di progettazione dell'eccellenza operativa forniscono una strategia di progettazione di alto livello per raggiungere tali obiettivi verso i requisiti operativi del carico di lavoro.

Elenco di controllo per la progettazione per l'eccellenza operativa

Avviare la strategia di progettazione in base all'elenco di controllo della revisione della progettazione per l'eccellenza operativa per definire i processi per l'osservabilità, il test e la distribuzione correlati alle aree di lavoro Log Analytics.

  • Usare l'infrastruttura come codice (IaC) per tutte le funzioni correlate alle aree di lavoro Log Analytics del carico di lavoro. Ridurre al minimo il rischio di errori umani che possono verificarsi con l'amministrazione manuale e l'esecuzione manuale delle funzioni di raccolta, inserimento, archiviazione e query, incluse query salvate e query pack, automatizzando il maggior numero possibile di queste funzioni tramite il codice. Includere anche avvisi che segnalano modifiche dello stato di integrità e la configurazione delle impostazioni di diagnostica per le risorse che inviano log alle aree di lavoro nel codice IaC. Includere il codice con l'altro codice correlato al carico di lavoro per assicurarsi che le procedure di distribuzione sicure vengano mantenute per la gestione delle aree di lavoro.
  • Assicurarsi che le aree di lavoro siano integre e quando si verificano problemi. Come qualsiasi altro componente del carico di lavoro, le aree di lavoro possono riscontrare problemi. I problemi possono costare tempo prezioso e risorse per risolvere e potenzialmente lasciare il team inconsapevole dello stato del carico di lavoro di produzione. La possibilità di monitorare in modo proattivo le aree di lavoro e attenuare i potenziali problemi consente ai team operativi di ridurre al minimo il tempo trascorso per la risoluzione e la risoluzione dei problemi.
  • Separare la produzione da carichi di lavoro non di produzione. Evitare complessità inutili che possono causare un lavoro aggiuntivo per un team operativo usando aree di lavoro diverse per l'ambiente di produzione rispetto a quelle usate dagli ambienti non di produzione. I dati in arrivo possono anche causare confusione perché le attività di test potrebbero sembrare eventi nell'ambiente di produzione.
  • Preferisce strumenti e funzioni predefiniti su soluzioni non Microsoft Usare gli strumenti predefiniti per estendere le funzionalità dei sistemi di monitoraggio e registrazione. Potrebbe essere necessario inserire configurazioni aggiuntive al posto per supportare i requisiti, ad esempio la ripristinabilità o la sovranità dei dati che non sono disponibili in un'area di lavoro di Log Analytics. In questi casi, ogni volta che è pratico, usare strumenti nativi di Azure o Microsoft per mantenere il numero di strumenti che l'organizzazione deve supportare almeno.
  • Considerare le aree di lavoro come componenti statici anziché effimerali Come altri tipi di archivi dati, le aree di lavoro non devono essere considerate tra i componenti temporanei del carico di lavoro. Il framework Well-Architected in genere favorisce l'infrastruttura non modificabile e la possibilità di sostituire rapidamente e facilmente le risorse all'interno del carico di lavoro come parte delle distribuzioni. Tuttavia, la perdita di dati dell'area di lavoro può essere irreversibile e irreversibile. Per questo motivo, lasciare le aree di lavoro fuori dai pacchetti di distribuzione che sostituiscono l'infrastruttura durante gli aggiornamenti e eseguono solo aggiornamenti sul posto nelle aree di lavoro.
  • Assicurarsi che il personale operativo sia sottoposto a training su Linguaggio di query Kusto Formare il personale per creare o modificare le query quando necessario. Se gli operatori non sono in grado di scrivere o modificare le query, può rallentare la risoluzione dei problemi critici o altre funzioni perché gli operatori devono basarsi su altri team per eseguire questa operazione.

Consigli di configurazione per l'eccellenza operativa

Recommendation Vantaggi
Progettare una strategia dell'area di lavoro per soddisfare i requisiti aziendali.

Per indicazioni sulla progettazione di una strategia per le aree di lavoro di Log Analytics, vedere Progettare un'architettura dell'area di lavoro Log Analytics . Includere il numero di creazione e la posizione in cui inserirli.

Se è necessario che il carico di lavoro usi un'offerta centralizzata del team della piattaforma, assicurarsi di impostare tutti gli accessi operativi necessari. Creare anche avvisi per garantire che vengano soddisfatte le esigenze di osservabilità del carico di lavoro.		 Un numero singolo o minimo di aree di lavoro ottimizza l'efficienza operativa del carico di lavoro. Limita la distribuzione dei dati operativi e di sicurezza, aumenta la visibilità sui potenziali problemi, semplifica l'identificazione dei modelli e riduce al minimo i requisiti di manutenzione.

Potrebbero essere necessari 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à. Assicurarsi quindi di disporre di processi appropriati per gestire questa maggiore complessità.
Usare l'infrastruttura come codice (IaC) per distribuire e gestire le aree di lavoro e le funzioni associate. Usare l'infrastruttura come codice (IaC) per definire i dettagli delle aree di lavoro nei modelli di Resource Manager, Azure BICEP o Terraform. Consente di usare i processi DevOps esistenti per distribuire nuove aree di lavoro e Criteri di Azure per applicare la configurazione.

Il colocating di tutto il codice IaC con il codice dell'applicazione consente di garantire che le procedure di distribuzione sicure vengano mantenute per tutte le distribuzioni.
Usare le informazioni dettagliate sull'area di lavoro Log Analytics per tenere traccia dell'integrità e delle prestazioni delle aree di lavoro Log Analytics e creare avvisi significativi e utilizzabili per ricevere una notifica proattiva dei problemi operativi.

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.

Ogni area di lavoro include una tabella delle operazioni che registra attività importanti che interessano l'area di lavoro.		 Esaminare le informazioni fornite regolarmente dalle informazioni dettagliate di Log Analytics per tenere traccia dell'integrità e dell'operazione di ognuna delle aree di lavoro. Quando si usano queste informazioni, consente di creare visualizzazioni facilmente comprensibili come dashboard o report che le operazioni e gli stakeholder possono usare per tenere traccia dell'integrità delle aree di lavoro.

Creare regole di avviso basate su questa tabella per ricevere una notifica proattiva quando si verifica un problema operativo. È possibile usare avvisi consigliati per l'area di lavoro per semplificare la creazione delle regole di avviso più critiche.
Praticare un miglioramento continuo rivedendo di frequente le impostazioni di diagnostica di Azure nelle risorse, nelle regole di raccolta dati e nella verbosità del log dell'applicazione.

Assicurarsi di ottimizzare la strategia di raccolta log tramite verifiche frequenti delle impostazioni delle risorse. Da un punto di vista operativo, cercare di ridurre il rumore nei log concentrandosi su tali log che forniscono informazioni utili sullo stato di integrità di una risorsa.		 Ottimizzando in questo modo, gli operatori possono analizzare e risolvere i problemi quando si verificano o eseguire altre attività di routine, improvvisate o di emergenza.

Quando vengono rese disponibili nuove categorie di diagnostica per un tipo di risorsa, esaminare i tipi di log generati con questa categoria per comprendere se abilitarli potrebbero aiutare a ottimizzare la strategia di raccolta. Ad esempio, una nuova categoria potrebbe essere un subset di un set più ampio di attività acquisite. Il nuovo subset può consentire di ridurre il volume dei log in arrivo concentrandosi sulle attività importanti per tenere traccia delle operazioni.

Criteri di Azure e Azure Advisor

Azure non offre criteri né raccomandazioni di Azure Advisor correlate all'eccellenza operativa delle aree di lavoro Log Analytics.

Efficienza delle prestazioni

L'efficienza delle prestazioni riguarda la gestione dell'esperienza utente anche quando si verifica un aumento del carico gestendo la capacità. La strategia include la scalabilità delle risorse, l'identificazione e l'ottimizzazione di potenziali colli di bottiglia e l'ottimizzazione per le prestazioni massime.

I principi di progettazione dell'efficienza delle prestazioni forniscono una strategia di progettazione di alto livello per raggiungere tali obiettivi di capacità rispetto all'utilizzo previsto.

Elenco di controllo di progettazione per l'efficienza delle prestazioni

Avviare la strategia di progettazione in base all'elenco di controllo della revisione della progettazione per l'efficienza delle prestazioni per definire una linea di base per le aree di lavoro Log Analytics e le funzioni associate.

  • Acquisire familiarità con le nozioni fondamentali sulla latenza di inserimento dei dati di log in Monitoraggio di Azure. Esistono diversi fattori che contribuiscono alla latenza durante l'inserimento dei log nelle aree di lavoro. Molti di questi fattori sono intrinseci alla piattaforma Monitoraggio di Azure. Comprendere i fattori e il normale comportamento di latenza consente di impostare le aspettative appropriate all'interno dei team operativi del carico di lavoro.
  • Separare i carichi di lavoro non di produzione e di produzione. Le aree di lavoro specifiche per la produzione limitano qualsiasi sovraccarico che i sistemi non di produzione potrebbero introdurre. Riduce il footprint complessivo delle aree di lavoro, richiedendo meno risorse per gestire l'elaborazione dei dati dei log.
  • Scegliere le aree di distribuzione appropriate per soddisfare i requisiti di prestazioni. Distribuire l'area di lavoro Log Analytics e gli endpoint di raccolta dati (DCE) vicini al carico di lavoro. La scelta dell'area appropriata in cui distribuire l'area di lavoro e i controller di dominio devono essere informati dalla posizione in cui si distribuisce il carico di lavoro. Potrebbe essere necessario valutare i vantaggi delle prestazioni della distribuzione delle aree di lavoro e dei controller di dominio nella stessa area del carico di lavoro rispetto ai requisiti di affidabilità se il carico di lavoro è già stato distribuito in un'area che non può supportare tali requisiti per i dati di log.

Consigli di configurazione per l'efficienza delle prestazioni

Recommendation Vantaggi
Configurare il controllo delle query di log e usare 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 fino a quando non vengono restituiti i risultati. Le informazioni dettagliate sull'area di lavoro di Log Analytics usano questi dati per elencare query potenzialmente inefficienti nell'area di lavoro. È consigliabile riscrivere queste query per migliorare le prestazioni. Per indicazioni sull'ottimizzazione delle query di log in Monitoraggio di Azure, vedere Ottimizzare le query di log.		 Le query ottimizzate restituiscono risultati più veloci e usano meno risorse sul back-end, che rende anche più efficienti i processi che si basano su tali query.
Informazioni sui limiti del servizio per le aree di lavoro Log Analytics.

In determinate implementazioni di traffico elevato, è possibile che si verifichino limiti di servizio che influiscono sulle prestazioni e sulla progettazione dell'area di lavoro o del carico di lavoro. Ad esempio, l'API di query limita il numero di record e volume di dati restituiti da una query. L'API di inserimento log limita le dimensioni di ogni chiamata API.

Per un elenco completo dei limiti e dei limiti delle aree di lavoro di Monitoraggio di Azure e Log Analytics specifici dell'area di lavoro stessa, vedere Limiti del servizio Monitoraggio di Azure.		 Comprendere i limiti che potrebbero influire sulle prestazioni dell'area di lavoro consente di progettarli in modo appropriato per attenuarli. È possibile decidere di usare più aree di lavoro per evitare di raggiungere i limiti associati a una singola area di lavoro.

Pesare le decisioni di progettazione per attenuare i limiti del servizio rispetto ai requisiti e agli obiettivi per altri pilastri.
Creare controller di dominio specifici per i tipi di origine dati all'interno di uno o più ambiti di osservabilità definiti. Creare controller di dominio separati per le prestazioni e gli eventi per ottimizzare l'utilizzo del calcolo dell'elaborazione back-end. Quando si usano controller di dominio separati per le prestazioni e gli eventi, consente di attenuare l'esaurimento delle risorse back-end. Con controller di dominio che combinano eventi di prestazioni, forza ogni macchina virtuale associata a trasferire, elaborare ed eseguire configurazioni che potrebbero non essere applicabili in base al software installato. Un utilizzo eccessivo delle risorse di calcolo e errori nell'elaborazione di una configurazione potrebbe verificarsi e causare la mancata risposta dell'agente di Monitoraggio di Azure.

Criteri di Azure e Azure Advisor

Azure non offre criteri né raccomandazioni di Azure Advisor correlate alle prestazioni delle aree di lavoro Log Analytics.

Passaggio successivo