Cloud

Monitoring e osservabilità in azione

Questa è la seconda parte di un blog diviso in due parti. Nella prima parte abbiamo spiegato come Monitoring e osservabilità vadano di pari passo. In questo blog descriviamo come implementiamo l'osservabilità e il monitoraggio dei servizi Public Cloud Services (PCMS) per i nostri clienti nell'ambito della nostra offerta di Managed Service.

Come implementiamo l'osservabilità e il Monitoring nel PCM

Vorrei iniziare dicendo che il panorama degli impianti infrastrutturali e delle applicazioni dei nostri clienti è in continua evoluzione. Con la crescita dell'effettivo di clienti e della diversità, cresce anche la personalizzazione dei prodotti per il mercato. Una delle nostre sfide è l'onboarding di nuovi clienti, che quasi sempre significa capire come monitorare nuovi servizi e applicazioni nel cloud, saltuariamente in un ambiente nativo e in un ambiente ibrido.

Un'immagine vale più di mille parole. Il diagramma qui sopra mostra i dettagli dell'osservabilità e del monitoraggio di PCMS per Azure (abbiamo anche clienti AWS, ma questo è un altro post del blog per un altro giorno).

Il primo livello, la telemetria, si trova in alto a destra. Include fonti di dati provenienti dai nostri clienti cloud pubblici, come diversi tipi di log delle risorse cloud PaaS e SaaS, ad esempio i log delle attività o i log di login raccolti con EventHub, e le loro metriche raccolte da Azure Monitor. Inoltre, le risorse IaaS canalizzano le loro metriche e i loro log direttamente al nostro Elastic Stack utilizzando gli agenti Beats e raccolgono anche i protocolli di gestione e di attività delle offerte cloud O365 e M365 per fornire Resolution per l'osservazione e il monitoraggio del dominio del cloud workspace. L'ultima, ma non meno importante, è la tendenza a creare scenari ibridi, in cui i nostri clienti connettono i loro diversi cloud e impianti infrastrutturali del cloud. Raccogliamo protocolli e metriche di alcuni mezzi di esercizio, saltuariamente direttamente e saltuariamente tramite offerte cloud pubbliche come Azure Arc e AWS Outpost.

Il secondo livello è la conservazione dei dati. Prima di entrare nel merito, è importante capire l'importazione dei dati. Esistono due endpoint per l'inserimento dei dati. Possono essere facilmente suddivisi in modalità push e pull. I nostri ausiliari Metricbeat e Filebeat funzionano sull'impianto infrastrutturale di Cloud e prelevano metriche, log e tracce dalle infrastrutture del cloud pubblico. Questo riguarda principalmente le risorse PaaS e SaaS. L'eccezione è rappresentata dai log delle attività, che si applicano a tutti i tipi di risorse. Il secondo endpoint per l'ingest è il nostro Elastic Ingest Node, che si trova direttamente nel nostro Elastic Stack. Gli ausiliari, che vengono eseguiti su IaaS o saltuariamente su dispositivi cloud basati sul calcolo, inviano le loro metriche, i log e le tracce direttamente al nostro Elastic Stack. Non appena i dati vengono letti, vengono archiviati in indici Lucene nel backend. La ritenzione dei dati dipende dal tipo di dati e dal caso aziendale. Tuttavia, può essere configurata per ogni set di dati per supportare i clienti con ritenzione specifica.

Il terzo e ultimo livello è quello delle prestazioni effettive; è qui che avviene la magia. La prima parte è il monitoraggio dello stato dei singoli componenti, che deriva dai profili di Monitoring. Un tipico profilo di Monitoring contiene più di uno dei seguenti componenti:

  • Avvisi basati su metriche, protocolli e tracce
  • Impieghi automatici, rilevamento di anomalie basate su set di dati
  • SIEM, eventi di sicurezza basati sul set di dati in entrata
  • Dashboard e visualizzazioni basate sui set di dati in entrata
  • Ricerche salvate relative ai record di dati in arrivo

Un'altra prestazione del nostro stack di osservabilità e monitoraggio è quella di consentire ai team operativi di comprendere i cambiamenti. Grazie alla possibilità di interrogare direttamente i set di dati sottostanti, che consistono in tutti i tipi di protocolli e metriche, i team operativi possono rispondere alla domanda "Cosa ha causato il Change?". Il tutto può essere riassunto come segue:

  • Fornitura del servizio
  • Sposta la configurazione
  • Variazione del carico di lavoro
  • Una dipendenza dal cloud non funzionante

Oppure: "Che impatto avrà questo cambiamento?". Questo può essere riassunto come segue:

  • Esperienza del cliente
  • Salute e prestazioni del servizio (note anche come SLO)
  • Consumo di risorse e costi operativi.

Per ripetere l'ultima parola della prima parte della serie sugli standard: il monitoraggio e l'osservabilità vanno di pari passo, l'uno non sostituisce l'altro, ma consente e migliora i risultati aziendali definiti congiuntamente. Questa è la seconda parte di un blog diviso in due parti. La prima parte, che spiega come il monitoraggio e l'osservabilità vadano di pari passo, è disponibile qui.

Chetan Goswami

Chetan Goswami

DevOps Engineer

Altri articoli getIT

Pronti per Swisscom

Trova il posto di lavoro o il percorso di carriera che fa per te. Dove dare il tuo contributo e crescere professionalmente.

Ciò che tu fai, è ciò che siamo.

Vai ai percorsi di carriera

Vai alle posizioni vacanti cibersicurezza