Ciao a tutti e bentornati.
Ora nel video di oggi parleremo della registrazione centralizzata.
Ora nell'ambiente di produzione, avere una registrazione centralizzata è estremamente importante.
Altrimenti, se non ce l'hai e si verifica un incidente, può essere qualsiasi incidente relativo
all'affidabilità, alla sicurezza, ecc. Quando si verifica un incidente, è stato osservato che il team dovrà
passare attraverso più account, più server per recuperare il file di registro che può fornire dettagli relativi a quell'incidente specifico.
A volte è stato anche osservato che a causa dello spazio su disco pieno su quel server, il file di registro
non è mai stato generato.
Quindi, per superare questi problemi, è importante che tu abbia configurato la registrazione centralizzata.
E nel video di oggi esamineremo questo tipo di architettura ora generalmente nelle organizzazioni,
in particolare in queste fasi in cui seguono l'architettura basata su più account.
Il monitoraggio dei log è una delle cose cruciali di cui dovrai occuparti.
Ora, diciamo che in questo diagramma ci sono tre conti a otto posti ora attivi.
Molti dei servizi generano il proprio set di file di registro.
Cloud genera il suo file di registro guida l'utente a generare il file di registro.
Se hai un set di due istanze facili, ci saranno i log, quindi ci saranno
i log relativi alla configurazione, ecc. Quindi questa è una parte e lo stesso vale anche per altri account.
Ora generalmente molte organizzazioni, cosa fanno quando hanno una soluzione di monitoraggio
centralizzata come Splunk, associano Splunk a ogni singolo account per recuperare i registri di ogni singolo
servizio.
Quindi Splunk si connette prima all'account di sviluppo, recupera i registri del percorso cloud.
Il servizio di guardia è di due istanze e così via, lo stesso per la messa in scena, lo stesso per la produzione e così via.
Quindi, anche se questo sembra essere un buon punto di partenza, ma quando hai centinaia di account di database,
questa non è la migliore delle architetture che possono essere utilizzate.
Ora una delle architetture consigliate per la registrazione è che hai un account di registrazione centralizzato.
Quindi quello che succede davvero qui è che ogni singolo account.
Quindi in questo caso hai un account, hai un account, B, ecc. Ciascun account è configurato per inviare i propri file di
registro a un account di registrazione centrale.
Quindi, nell'account potresti avere un servizio cloud abilitato, il cloud invierà i registri al centro dell'account di registrazione dell'account.
Avremo di nuovo un servizio di configurazione abilitato che invierà all'account di registrazione centrale e al tuo strumento di monitoraggio del
registro come Splunk.
Questo strumento di monitoraggio del registro sarà associato a un solo account, in questo caso l'account di registrazione
del centro, e recupererà tutti i dati da qui.
Quindi, in questo modo, anche se hai 100 account di database, diventa molto più semplice perché tutti quegli account
invieranno i registri a un account di registrazione centrale qui.
Ora, quando hai un'architettura basata sulla registrazione, ci sono alcune considerazioni di cui dovrai
occuparti.
La prima considerazione è che dovrai definire un requisito di conservazione del registro e le politiche del ciclo di vita
all'inizio.
Ora, generalmente nelle organizzazioni più grandi, la dimensione del registro sarebbe in terabyte.
Quindi hai bisogno di tutti i terabyte di dati nel tuo bucket S3 o puoi spostarlo anche su Glacier?
Perché se memorizzi così tanti dati in S3, anche la tua bolletta sarà enorme.
Molte organizzazioni hanno un requisito di conservazione dei log.
Ad esempio, per i primi tre mesi i log saranno necessari secchio.
Dopo tre mesi, tutti i tronchi andranno al ghiacciaio e così via.
Quindi tutto ciò dipende dalle politiche di conservazione dei registri nella tua organizzazione, di nuovo è necessario incorporare strumenti e
funzionalità per automatizzare le politiche del ciclo di vita.
Quindi questo nel caso in cui stai usando S3, questo è molto più semplice.
La terza parte importante è che devi automatizzare l'installazione e la configurazione del log shipping.
Immagina, ad esempio, di lanciare dieci nuove istanze easy to.
Ora dopo che SC vengono avviate due istanze.
Devi anche assicurarti che tutte quelle istanze facili inviino immediatamente tutti i registri all'account
di registrazione centralizzato.
Quindi forse nell'esercito stesso potresti avere il tuo agente Splunk o un agente di disboscamento preconfigurato.
Pertanto, ogni volta che l'istanza viene avviata, l'agente procederà e inizierà a inviare i registri all'account centrale.
E la quarta considerazione è assicurarsi che la soluzione supporti ambienti ibridi per supportare le esigenze.
Non è necessario che tutti gli account siano basati su un database.
Può succedere.
Alcuni account sono basati su un'architettura ibrida, forse Azure, forse su un ambiente prem, forse otto
e così via.
Quindi devi assicurarti che la tua architettura di registrazione supporti anche questo tipo di ambienti ibridi.
Quindi facciamo una cosa prima di procedere oltre.
Facciamo una rapida demo su questa architettura di registrazione centralizzata.
Ora per la demo di oggi, ho due account in due tipi diversi in esecuzione.
Ci riferiremo al primo account come account di registrazione centrale e il secondo account è fondamentalmente l'account
di produzione.
E in modo simile all'architettura di cui stavamo discutendo, l'account di produzione invierà i dati
a un account di registrazione centrale.
Quindi andiamo avanti ed esaminiamo.
Ora in quell'account di registrazione, apriamo rapidamente i tre servizi.
Ora qui dentro ho un bucket S3 chiama, escape, central log, cloud trail.
Ora dal nome stesso, possiamo identificare che questo bucket ospiterà anche i log cloud di altri
account.
Ora, se apri questo bucket, hai una cartella di log.
E in questa fase c'è un account che sta aggiungendo i dati a questo bucket S3 e questo account termina con
quattro, sette, sei tre.
E se guardi qui, non è lo stesso account.
Quindi attualmente il numero di account di questo account indirizzo in cui si trova questo bucket è 9364.
Ma questo è un account completamente diverso.
Quindi questo account 4763 è sostanzialmente in esecuzione in un tipo diverso.
Se sono quattro, sette, sei tre.
E il nostro servizio cloud da questo account di produzione sta inviando tutti i suoi registri al nostro account di registrazione centrale.
Quindi, se desideri esaminare la configurazione di un percorso cloud, apriamo rapidamente un percorso qui.
Se vedrai la posizione del sentiero, l'evasione avrà registri centrali, cloud trail, che non è altro che questo specifico
bucket in una griglia dell'account di registrazione.
Quindi questa è la panoramica di alto livello sulla registrazione centralizzata.
Ora alcuni punti più importanti che dobbiamo notare.
Il primo è che possiamo utilizzare più servizi gestiti per creare una soluzione di registrazione centralizzata.
Puoi utilizzare il servizio cloud Elasticsearch, i log di controllo, le chinasi e persino il bucket S3 per ospitare questi
log centralizzati.
Insieme a questo, un'altra parte importante che dobbiamo notare è che i modi in cui puoi configurare la registrazione centralizzata
per ciascun servizio come trail di carico, VPC, log di flusso, servizio di guardia, ecc. differisce.
Ogni servizio ha un modo diverso in cui puoi usarlo per inviare i registri a un account di registrazione centrale.
Alcuni dei modi sono piuttosto semplici.
Alcuni dei modi richiedono alcuni passaggi in più per essere configurati.
Quindi questa è la panoramica di alto livello e questo concluderà il video di oggi.