Hochgradig skalierbare Ereignisprotokollierung auf AWS

Druckfreundlich, PDF & E-Mail

Die meisten Anwendungen generieren Konfigurations- und Zugriffsereignisse. Administratoren müssen Aufschluss über diese Ereignisse erhalten können. Der Barracuda Email Security Service bietet Transparenz und Aufschluss zu vielen solchen Ereignissen, um Administratoren die Feinabstimmung sowie das Verständnis des Systems zu erleichtern. So können sie z. B. erfahren, wer sich wann bei einem Konto angemeldet hat – oder wer die Konfiguration einer bestimmten Richtlinie hinzugefügt, geändert oder gelöscht hat.

Bei der Erstellung eines solchen dezentralen und durchsuchbaren Systems kommen viele Fragen auf, z. B.:

  • Wie soll man alle diese Protokolle von all diesen Anwendungen, Services und Geräten aus an einem zentralen Ort aufzeichnen?
  • Welches Standardformat sollen die Protokolldateien aufweisen?
  • Wie lange sollen diese Protokolle aufbewahrt werden?
  • Wie soll man Ereignisse von verschiedenen Anwendungen zueinander in Beziehung setzen?
  • Wie kann man einen einfachen, raschen Suchmechanismus über eine Benutzeroberfläche für den Administrator zur Verfügung stellen?
  • Wie kann man diese Protokolle über ein API verfügbar machen?

Wenn man an verteilte Suchmaschinen denkt, fällt einem als Erstes Elasticsearch ein. Sie ist hochgradig skalierbar, ermöglicht eine Suche nahezu in Echtzeit und ist in AWS als vollständiger Managed Service verfügbar. Es begann also alles mit dem Gedanken, diese Ereignisprotokolle in Elasticsearch und all den verschiedenen Anwendungen zu speichern, die Protokolle über Kinesis Data Firehose an Elasticsearch senden.

An dieser Architektur beteiligte Komponenten

  1. Kinesis Agent – Amazon Kinesis Agent ist eine eigenständige Java-Software-Anwendung, die eine einfache Möglichkeit bietet, Daten zu erfassen und an Kinesis Data Firehose zu senden. Der Agent überwacht kontinuierlich Ereignisprotokolldateien auf den EC2-Linux-Instanzen und sendet sie an den konfigurierten Kinesis Data Firehose-Auslieferungsstream. Der Agent ist für Dateirotation, Checkpointing und erneutes Versuchen nach Fehlschlägen verantwortlich. Er stellt alle Daten auf zuverlässige, schnelle und unkomplizierte Art und Weise bereit. Hinweis: Wenn es sich bei der Anwendung, die Daten in Kinesis Firehose schreiben soll, um einen Fargate-Container handelt, benötigen Sie einen Fluentd-Container. Dabei liegt der Fokus jedoch auf der Anwendung, die in den Amazon EC2-Instanzen läuft.
  2. Kinesis Data Firehose – Die Direct-Put-Methode von Amazon Kinesis Data Firehose kann die Daten im JSON-Format in Elasticsearch schreiben. So werden keine Daten im Stream gespeichert.
  3. S3 – Ein S3-Bucket kann für das Backup entweder aller Datensätze oder nur der Datensätze, die nicht für Elasticsearch bereitgestellt werden konnten, verwendet werden. Lifecycle-Richtlinien können auch für eine automatische Archivierung von Protokollen konfiguriert werden.
  4. Elasticsearch – Elasticsearch, gehostet von Amazon. Es kann der Zugriff auf Kibana aktiviert werden, um die Protokolle zu Debugging-Zwecken abzufragen und zu durchsuchen.
  5. Curator – AWS empfiehlt den Einsatz von Lambda und Curator zur Verwaltung der Indizes und Momentaufnahmen des Elasticsearch-Clusters. AWS bietet Ihnen hier weitere Informationen und Implementierungsbeispiele.
  6. REST-API-Schnittstelle – Sie können die API als Abstraktion von Elasticsearch erstellen. Sie lässt sich gut mit der Benutzeroberfläche integrieren. API-gestützte Microservice-Architekturen sind nachweislich in vielerlei Hinsicht die besten, z. B. in Bezug auf Sicherheit, Compliance und Integration mit anderen Services.

 

Skalierung

  • Kinesis Data Firehose: Standardmäßig lässt sich der Firehose-Auslieferungsstream auf bis zu 1.000 Datensätze/Sek. oder 1 MiB/Sek. für „US East Ohio“ skalieren. Dies ist eine flexible Beschränkung, die auf bis zu 10.000 Datensätze/Sekunde erhöht werden kann. Dies ist regionsspezifisch.
  • Elasticsearch: Der Elasticsearch-Cluster lässt sich sowohl im Hinblick auf Speicherplatz als auch auf Rechenleistung auf AWS skalieren. Auch Versionsupgrades sind möglich. Amazon ES verwendet beim Aktualisieren von Domains einen Bereitstellungsprozess vom Typ „blau/grün“. Somit kann die Anzahl von Nodes in dem Cluster vorübergehend ansteigen, während Ihre Änderungen übernommen werden.

Vorteile dieser Architektur

  1. Die Pipeline-Architektur wird effektiv vollständig verwaltet und überzeugt mit einem sehr geringen Wartungsaufwand.
  2. Im Falle eines Fehlschlagens des Elasticsearch-Clusters kann Kinesis Firehose Datensätze bis zu 24 Stunden lang aufbewahren. Zudem wird auch ein Backup auf S3 für alle Datensätze erstellt, die nicht bereitgestellt werden konnten, erstellt.

Mit diesen verfügbaren Optionen ist die Wahrscheinlichkeit von Datenverlusten gering.

  1. Es ist eine detaillierte Zugangskontrolle für die Kibana- und Elasticsearch-API über IAM-Richtlinien möglich.

Nachteile

  1. Die Preisgestaltung muss sorgfältig durchdacht und überwacht werden. Die Kinesis Data Firehose kann mühelos umfangreiche Dateneinspeisungen bewältigen. Wenn ein „wild gewordener“ Service auf einmal große Datenmengen protokolliert, liefert Kinesis Data Firehose sie ohne zu Fragen aus. Dies kann zu hohen Kosten führen.
  2. Die Integration von Kinesis Data Firehose mit Elasticsearch wird nur für Nicht-VPC-Elasticsearch-Cluster unterstützt.
  3. Die Kinesis Data Firehose kann derzeit keine Protokolle für Elasticsearch-Cluster bereitstellen, die nicht von AWS gehostet werden. Wenn Sie Elasticsearch-Cluster selbst hosten möchten, funktioniert diese Option nicht. 

Fazit

Wenn Sie nach einer Lösung suchen, die vollständig verwaltet ist und sich (meist) ohne Eingreifen skalieren lässt, wäre dies eine gute Option. Das automatische Backup auf S3 mit Lifecycle-Richtlinien löst auch ganz unkompliziert das Problem hinsichtlich der Aufbewahrung und Archivierung von Protokollen.

Nach oben scrollen
Twittern
Teilen
Teilen