Hallo zusammen und willkommen zurück.
Im heutigen Video werden wir nun über die zentralisierte Protokollierung sprechen.
Jetzt in der Produktionsumgebung ist eine zentralisierte Protokollierung äußerst wichtig.
Andernfalls, wenn Sie es nicht haben und ein Vorfall auftritt, kann es sich um einen beliebigen Vorfall in
Bezug auf Zuverlässigkeit, Sicherheit usw. handeln. Wenn ein Vorfall auftritt, wurde beobachtet, dass das Team über
mehrere Konten und mehrere Server springen muss, um die Protokolldatei abzurufen, die Details zu diesem bestimmten Vorfall enthalten
kann.
Manchmal wurde auch beobachtet, dass aufgrund des vollen Speicherplatzes auf diesem Server die Protokolldatei
nie generiert wurde.
Um diese Probleme zu lösen, ist es wichtig, dass Sie die zentralisierte Protokollierung konfiguriert haben.
Und im heutigen Video werden wir uns diese Art von Architektur jetzt allgemein in Organisationen ansehen,
insbesondere in diesen Phasen, in denen sie der Multi-Account-basierten Architektur folgen.
Die Protokollüberwachung ist eines der wichtigsten Dinge, um die Sie sich kümmern müssen.
Nehmen wir an, in diesem Diagramm gibt es jetzt drei achtstellige Konten.
Viele der Dienste generieren ihre eigenen Protokolldateien.
Cloud generiert seine Protokolldatei, die Sie zum Generieren der Protokolldatei führt.
Wenn Sie eine Reihe von einfachen zwei Instanzen haben, gibt es Protokolle, dann
gibt es Protokolle zur Konfiguration usw. Dies ist also ein Teil und das Gleiche gilt auch für andere Konten.
Nun, was sie tun, wenn sie eine zentralisierte Überwachungslösung wie Splunk haben,
verknüpfen sie im Allgemeinen Splunk mit jedem einzelnen Konto, um die Protokolle jedes einzelnen
Dienstes abzurufen.
Splunk stellt also zuerst eine Verbindung zum Entwicklungskonto her und ruft die Protokolle des Cloud-Trails ab.
Wachdienst ist zwei Instanzen und so weiter, das gleiche für die Inszenierung, das gleiche für die Produktion und so weiter.
Dies scheint zwar ein guter Ausgangspunkt zu sein, aber wenn Sie Hunderte von Datenbankkonten haben,
ist dies nicht die beste Architektur, die verwendet werden kann.
Nun ist eine der empfohlenen Architekturen für die Protokollierung, dass Sie ein zentralisiertes Protokollierungskonto haben.
Was hier also wirklich passiert, ist, dass jedes einzelne Konto.
In diesem Fall haben Sie also ein Konto, Sie haben ein Konto, B usw. Jedes Konto ist so konfiguriert, dass es seine Protokolldateien
an ein zentrales Protokollkonto sendet.
Wenn Sie also einen Cloud-Dienst aktiviert haben, sendet die Cloud die Protokolle an das Center-Logging-Konto.
Wir werden wieder einen Konfigurationsdienst aktivieren, der an das zentrale Protokollierungskonto und Ihr Protokollüberwachungstool wie
Splunk gesendet wird.
Dieses Protokollüberwachungstool wird nur mit einem Konto verknüpft, in diesem Fall dem zentralen Protokollierungskonto,
und es ruft alle Daten von hier ab.
Auf diese Weise wird es also viel einfacher, selbst wenn Sie 100 Datenbankkonten haben, da alle diese Konten die
Protokolle an ein zentrales Protokollierungskonto hier senden.
Wenn Sie nun über eine protokollierungsbasierte Architektur verfügen, müssen Sie bestimmte Überlegungen
anstellen.
Die erste Überlegung ist, dass Sie frühzeitig eine Protokollaufbewahrungsanforderung und die Lebenszyklusrichtlinien definieren
müssen.
Jetzt würde die Protokollgröße in größeren Organisationen im Allgemeinen in Terabyte angegeben.
Benötigen Sie also alle Terabyte an Daten in Ihrem S3-Bucket oder können Sie sie auch nach Glacier verschieben?
Denn wenn Sie so viele Daten in S3 speichern, wird Ihre Rechnung ebenfalls riesig.
So viele Organisationen haben eine Log-Aufbewahrungspflicht.
Zum Beispiel werden die Protokolle für die ersten drei Monate ein notwendiger Eimer sein.
Nach drei Monaten gehen alle Stämme zum Gletscher und so weiter.
All dies hängt also wieder von den Protokollaufbewahrungsrichtlinien in Ihrer Organisation ab, wenn Sie Tools und Funktionen integrieren
müssen, um die Lebenszyklusrichtlinien zu automatisieren.
Wenn Sie also S3 verwenden, ist dies viel einfacher.
Der dritte wichtige Teil ist, dass Sie die Installation und Konfiguration des Protokollversands automatisieren müssen.
Stellen Sie sich zum Beispiel vor, Sie starten zehn neue Easy-to-Instanzen.
Jetzt werden nach diesem SC zwei Instanzen gestartet.
Sie müssen auch sicherstellen, dass alle diese einfach zu bedienenden Instanzen alle Protokolle sofort an das zentralisierte
Protokollkonto senden.
Vielleicht haben Sie in der Armee selbst Ihren Splunk-Agenten oder einen Logging-Agenten vorkonfiguriert.
Wenn also eine Instanz gestartet wird, beginnt der Agent damit, die Protokolle an das zentrale Konto zu senden.
Und die vierte Überlegung besteht darin, sicherzustellen, dass die Lösung hybride Umgebungen unterstützt, um die Anforderungen zu
erfüllen.
Es ist nicht erforderlich, dass alle Konten auf einer Datenbank basieren.
Es kann vorkommen.
Einige Konten basieren auf einer Hybridarchitektur, vielleicht Azure, vielleicht auf einer Prem-Umgebung, vielleicht acht
und so weiter.
Sie müssen also sicherstellen, dass Ihre Protokollierungsarchitektur auch solche hybriden Umgebungen unterstützt.
Lassen Sie uns also eine Sache tun, bevor wir weitermachen.
Sehen wir uns diese zentralisierte Protokollierungsarchitektur kurz an.
Für die heutige Demo habe ich zwei Konten in zwei verschiedenen Typen, die ausgeführt werden.
Das erste Konto bezeichnen wir als zentrales Protokollierungskonto, und das zweite Konto ist im Grunde das Produktionskonto.
Und ähnlich wie bei der besprochenen Architektur sendet das Produktionskonto die Daten an ein
zentrales Protokollierungskonto.
Also lass uns weitermachen und nachsehen.
Lassen Sie uns jetzt in diesem Protokollkonto schnell den Dienst drei öffnen.
Jetzt hier drinnen habe ich einen S3-Bucket-Call, Flucht, zentrale Protokolle, Cloud-Trail.
Jetzt können wir anhand des Namens selbst erkennen, dass dieser Bucket auch die Cloud-Protokolle von anderen Konten
hosten wird.
Wenn Sie nun diesen Bucket öffnen, haben Sie einen Ordner mit Protokollen.
Und in diesem Stadium gibt es ein Konto, das die Daten zu diesem S3-Bucket hinzufügt, und dieses Konto endet mit
vier, sieben, sechs, drei.
Und wenn Sie hier schauen, ist es nicht dasselbe Konto.
Die Kontonummer dieses Adresskontos, in dem dieser Bucket liegt, lautet also derzeit 9364.
Aber das ist ein ganz anderes Konto.
Dieses 4763-Konto läuft also grundsätzlich in einem anderen Typ.
Wenn es vier, sieben, sechs, drei ist.
Und unser Cloud-Service von diesem Produktionskonto sendet alle seine Protokolle an unser zentrales Protokollierungskonto.
Wenn Sie sich also mit der Konfiguration eines Cloud-Trails befassen würden, lassen Sie uns hier schnell einen Trail eröffnen.
Wenn Sie sehen, dass der Trail-Standort Escape zentrale Protokolle haben wird, Cloud Trail, was nichts anderes als dieser
spezifische Bucket in einem Logging-Konto-Raster ist.
Das ist also der grobe Überblick über die zentralisierte Protokollierung.
Nun noch ein paar wichtige Punkte, die wir beachten müssen.
Erstens können wir mehrere verwaltete Dienste nutzen, um eine zentralisierte Protokollierungslösung aufzubauen.
Sie können die Elasticsearch-Service-Cloud, Überwachungsprotokolle, Kinasen und sogar S3-Buckets verwenden, um diese zentralisierten
Protokolle zu hosten.
Ein weiterer wichtiger Teil, den wir beachten müssen, ist die Art und Weise, wie Sie die zentralisierte Protokollierung für jeden
Dienst wie Lastpfad, VPC, Flussprotokolle, Wachdienst usw. konfigurieren können. unterscheidet sich.
Jeder Dienst hat eine andere Art und Weise, wie Sie ihn verwenden können, um die Protokolle an ein zentrales Protokollierungskonto zu senden.
Einige der Wege sind ziemlich einfach.
Einige der Möglichkeiten erfordern etwas mehr Schritte, um konfiguriert zu werden.
Das ist also die Übersicht auf hoher Ebene, und damit wird das heutige Video abgeschlossen.