Procedure consigliate per l'architettura per Log Analytics

Esaminare i limiti del servizio per le aree di lavoro Log Analytics: La sezione limiti del servizio illustra le restrizioni relative alla raccolta dei dati, alla conservazione dei dati e ad altri aspetti del servizio. Questi limiti consentono di progettare una strategia efficace di osservabilità del carico di lavoro. Assicurarsi di esaminare i limiti del servizio Monitoraggio di Azure perché molte funzioni, ad esempio le query, funzionano in combinazione con le aree di lavoro Log Analytics.

Pianificare la resilienza e il ripristino dell'area di lavoro: Le aree di lavoro Log Analytics sono a livello di area e non dispongono del supporto predefinito per la ridondanza o la replica tra aree. Le opzioni di ridondanza della zona di disponibilità sono limitate. A causa di queste limitazioni, è necessario determinare i requisiti di affidabilità delle aree di lavoro e strategare per soddisfare tali destinazioni.

I requisiti potrebbero prevedere che l'area di lavoro sia resiliente agli errori del data center o agli errori a livello di area. Oppure potrebbero prevedere che sia necessario essere in grado di ripristinare i dati in una nuova area di lavoro in un'area di failover.

Ognuno di questi scenari richiede risorse e processi aggiuntivi per avere successo, quindi valutare attentamente come bilanciare gli obiettivi di affidabilità con costi e complessità.

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 con i componenti del carico di lavoro che generano dati operativi. Dove si distribuisce il carico di lavoro deve informare la scelta dell'area appropriata in cui distribuire l'area di lavoro e i controller di dominio.

Potrebbe essere necessario valutare la disponibilità a livello di area di funzionalità specifiche di Log Analytics, ad esempio cluster dedicati, rispetto ad altri fattori più centrali per l'affidabilità, i costi e i requisiti di prestazioni del carico di lavoro.

Escludere le aree di lavoro dalle dipendenze del percorso critico: Le aree di lavoro Log Analytics fungono da componenti importanti del sistema di osservabilità, ma non devono essere incluse nel percorso critico del carico di lavoro. Queste aree di lavoro raccolgono e archiviano i dati operativi essenziali per il monitoraggio e la risoluzione dei problemi. Tuttavia, la funzionalità di base del carico di lavoro deve rimanere indipendente dalla disponibilità dell'area di lavoro. Questa separazione dell'architettura garantisce che le interruzioni del sistema di osservabilità non si propagano in errori di runtime 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. Per ottenere un'osservabilità affidabile, abilitare le funzionalità che inviano segnali di dati sull'integrità ai team operativi. Configurare i segnali di dati di integrità specifici per le aree di lavoro Log Analytics e le risorse associate.

Esaminare le procedure consigliate per la sicurezza: Esaminare le procedure consigliate per la sicurezza negli articoli Baseline di sicurezza di Monitoraggio di Azure e Gestire l'accesso alle aree di lavoro Log Analytics .

Distribuire le aree di lavoro con la segmentazione come principio fondamentale: Implementare la segmentazione ai livelli di rete, dati e accesso. La segmentazione garantisce che le aree di lavoro siano isolate in base al grado appropriato. Consente inoltre di proteggere le aree di lavoro dall'accesso non autorizzato al massimo livello possibile, rispettando al tempo stesso i requisiti aziendali per l'affidabilità, l'ottimizzazione dei costi, l'eccellenza operativa e l'efficienza delle prestazioni.

Assicurarsi che sia possibile 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 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: Proteggere l'accesso alla rete all'area di lavoro e ai log tramite funzioni firewall e isolamento della rete. I controlli di rete configurati in modo insufficiente aumentano il rischio di accesso non autorizzato o dannoso.

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 dei log sensibili in base ai requisiti di conformità.

Proteggere i dati di log inattivi tramite crittografia: La segmentazione da sola non proteggerà completamente la riservatezza dei dati di log. Se si verifica l'accesso non autorizzato, la crittografia dei dati di log inattivi consente di evitare che gli attori malintenzionati usino tali dati all'esterno dell'area di lavoro.

Proteggere i dati di log sensibili tramite offuscamento: Proprio come i 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 dall'accesso non autorizzato.

Eseguire esercizi di modellazione dei costi: Questi esercizi 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 per l'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 attualmente si usano le aree di lavoro e come si prevede di usarle man mano che il carico di lavoro evolve determina se un modello di livello con pagamento in base al consumo o di impegno è più adatto per lo scenario in uso.

Tenere presente che è possibile scegliere modelli di fatturazione diversi per ogni area di lavoro. È anche possibile combinare i costi dell'area di lavoro in casi specifici, 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.

Gestire gli ambienti non di produzione in modo diverso rispetto agli ambienti di produzione: Esaminare gli ambienti non di produzione per assicurarsi che le impostazioni di diagnostica e i criteri di conservazione siano configurati in modo appropriato. Queste impostazioni e criteri possono spesso essere notevolmente meno affidabili rispetto all'ambiente di produzione, soprattutto per gli ambienti di sviluppo/test o sandbox.

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 dall'amministrazione manuale e dal funzionamento manuale della raccolta di log, dell'inserimento, dell'archiviazione e delle funzioni di query, incluse le query salvate e i query pack, automatizzando il maggior numero possibile di tali 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 di ricevere una notifica quando si verificano problemi: Come qualsiasi altro componente del carico di lavoro, le aree di lavoro possono riscontrare problemi. Questi problemi possono consumare tempo prezioso e risorse per diagnosticare e correggere e lasciare il team non a conoscenza dello stato del carico di lavoro di produzione. Il monitoraggio proattivo delle aree di lavoro e la mitigazione anticipata dei problemi consentono ai team operativi di ridurre il tempo dedicato alla risoluzione dei problemi e alle riparazioni.

Separare la produzione dai carichi di lavoro non di produzione: Evitare complessità superflue che possono causare 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.

Preferire strumenti e funzioni predefiniti rispetto alle soluzioni non Microsoft: Usare gli strumenti predefiniti per estendere le funzionalità dei sistemi di monitoraggio e registrazione. Potrebbe essere necessario inserire configurazioni aggiuntive per supportare requisiti come la recuperabilità o la sovranità dei dati che non sono disponibili automaticamente con le aree di lavoro Log Analytics. In questi casi, quando pratico, usare strumenti nativi di Azure o Microsoft per ridurre al minimo il numero di strumenti che l'organizzazione deve supportare.

Considerare le aree di lavoro come componenti statici anziché temporanei: Analogamente ad 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 addestrato nel 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 query, può rallentare la risoluzione dei problemi critici o altre funzioni perché gli operatori devono affidarsi ad altri team per eseguire questa operazione.

Acquisire familiarità con i concetti fondamentali della 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 di Monitoraggio di Azure.

Comprendere i fattori e il comportamento di latenza normale consentono 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 della produzione attenuano qualsiasi sovraccarico che i sistemi non di produzione potrebbero introdurre. La separazione 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 i controller di dominio vicini al carico di lavoro. Dove si distribuisce il carico di lavoro deve informare la scelta dell'area appropriata in cui distribuire l'area di lavoro e i controller di dominio.

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 in base 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.