In Teil 1 dieser Reihe haben wir die Designphilosophie von Splunk Connect for Syslog (SC4S), die Designziele und die HEC-basierte Transportarchitektur vorgestellt. In diesem zweiten Teil nehmen wir uns die Grundkonfiguration von SC4S vor und verweisen dabei auf die relevanten Abschnitte der Dokumentation, in denen die Einzelheiten zu finden sind, die ihr für die Bereitstellung in einer Produktionsumgebung braucht.
Die SC4S-Konfiguration ist modular und Template-basiert. Es gibt separate syslog-ng-Konfigurationsabschnitte, die wir uns im Folgenden näher ansehen. In der Containerversion von SC4S ist der Großteil der Konfiguration für den Administrator gar nicht sichtbar, es gibt jedoch einen lokalen Einhängepunkt zum Mounten lokaler Konfigurationen. In der BYOE-Version dagegen kann die gesamte Konfiguration geprüft und geändert werden.
Im Folgenden wird die leicht abgeänderte Konfiguration von SC4S mit den Out-of-the-box-Datenquellen beschrieben.
Syslog-ng-Datenfluss
Wenn eine Meldung beim Syslog-Server ankommt, durchläuft sie eine Reihe von Filtern, mit denen bestimmt wird, wie sie verarbeitet werden soll. Im Fall von SC4S soll die Verarbeitung dazu führen, dass die Meldung an Splunk und den richtigen Index gesendet wird – korrekt formatiert und mit den richtigen Metadaten (Sourcetyp, Zeitstempel etc.). Für jedes gegebene Datenquellenformat (das meist, aber nicht immer der Hersteller definiert) wird ein Satz Filter entwickelt und in einem „Log-Pfad“ gekapselt. Diese Log-Pfade bestimmen, welche Filter in welcher Reihenfolge auf eine Meldung angewendet werden, damit man feststellen kann, in welche Kategorie sie gehört (im Fall von Splunk ist dies ein Sourcetyp).
Nach der Bestimmung der Kategorie werden Parser angewandt, damit die Meldung entsprechend formatiert wird, die Metadaten werden festgelegt, und das ganze Paket wird in einem JSON-Blob gebündelt und in Batches über den HEC-Endpunkt /event an Splunk gesendet. Bei Verwendung des Endpunkts /event können zusätzlich angereicherte Metadaten mitgesendet und zur weiteren Klassifizierung verwendet werden. Dies ist nützlich für PCI, die geografische Reichweite und viele andere Use Cases.
Anpassung der SC4S-Umgebung
Im Folgenden befassen wir uns mit der Container-Architektur; die BYOE-Architektur ist ähnlich und funktioniert nach denselben Konzepten. Grundsätzlich wird SC4S durch eine ganz spezielle Gruppe von Umgebungsvariablen konfiguriert, die in einer eigenen Datei gekapselt sind. Der Inhalt dieser Datei ist in der Dokumentation im Abschnitt „Getting Started“ und in den dazugehörigen Laufzeitdokumenten beschrieben; damit können Admins einen Großteil von SC4S anpassen, ohne dass sie umfassende Kenntnisse der syslog-ng-Syntax brauchen. Die folgenden Schritte beschreiben die wichtigsten Konfigurationsaufgaben bei SC4S.
Grundkonfiguration (erforderlich)
Für die Einrichtung von SC4S out of the box sind nur einige wenige Elemente wirklich notwendig:
- HEC-URL (entweder eine Liste mit Endpunkten oder eine Loadbalancer-VIP)
- HEC-Token
- ein Standardport für die Datenerfassung (meist 514)
- die Anzahl der HEC-Endpunkte (erforderlich für die richtige Konfiguration von syslog-ng für große Datenvolumen)
- die Größe des Pufferspeichers
- ein leeres Verzeichnis, das als Container für lokale Anpassungen „gemountet“ wird – es wird bei der ersten Ausführung von SC4S mit Template-Beispielen gefüllt; viele Unternehmen benötigen dies, um die Standardindizes zu überschreiben
Diese Einstellungen werden mittels der Umgebungsvariablen in der oben genannten Datei festgelegt. Wenn ihr nur die hier gelisteten Elemente konfiguriert, bekommt ihr bereits eine gut brauchbare SC4S-Einrichtung out of the box!
Anpassung vor der Instanziierung (optional)
Es gibt einige wichtige Einstellungen, die der Container vor dem Start „kennen“ muss:
- TCP-, UDP- oder TLS-Port(s) für das Listening (nicht der übliche Standardport TCP/UDP 514). Diese Ports können angepasst werden und sind oft das einzige Filterkriterium in einem Log-Pfad, das zur Bestimmung eines oder mehrerer Sourcetypen verwendet wird.
- Ob TLS und/oder benutzerdefinierte Zertifikate verwendet werden.
Diese Angaben müssen jeweils vor dem Start des Containers festgelegt werden und sind unabhängig von der Art des Datenverkehrs an den Listener-Ports. Um die zugrunde liegende syslog-ng-Konfiguration so zu ändern, dass diese Parameter richtig eingestellt sind, wird ein Templating-Vorgang durchgeführt, sodass syslog-ng mit den richtigen Port-/TLS-Parametern starten kann, die auf den vom Administrator festgelegten Werten der Umgebungsvariablen basieren. Diese Umgebungsvariablen sind in der Dokumentation unter „Configuration“ beschrieben. Der Templating-Vorgang erfolgt für die Out-of-the-box-Quellen automatisch. Bei der Entwicklung benutzerdefinierter Log-Pfade (siehe unten) sind bestimmte Elemente der Templates für den Administrator sichtbar und müssen entsprechend berücksichtigt werden.
Laufzeitanpassung (optional)
Zusätzlich zur oben beschriebenen Quellport-/TLS-Konfiguration könnt ihr SC4S auch auf der Grundlage anderer Merkmale der eintreffenden Daten anpassen. Datenquellen können nach Hostnamen-Platzhaltermustern (globs) sowie ankommenden CIDR-Blöcken kategorisiert (gefiltert) und (wie bei der Quellport-Konfiguration oben) als Mechanismen zur Unterscheidung bestimmter Sourcetypen verwendet werden. Abschließend bleibt zu diesem Anpassungsschritt zu sagen, dass alle Metadaten überschrieben oder geändert werden können.
Die Laufzeitanpassung unterscheidet sich von den oben genannten Schritten vor der Instanziierung in einem wichtigen Punkt: Hier ändert ihr keine Umgebungsvariablen, sondern es wird euch als Admins über einen lokalen Einhängepunkt des Containers ein kleiner Ausschnitt der zugrunde liegenden syslog-ng-Konfigurationsdatei offengelegt. Ihr müsst dabei auf die korrekte Syntax achten (das wird vor dem Start überprüft) – das ist auch die einzige Stelle, an der rudimentäres Wissen zur Syntax der syslog-ng-Konfigurationsdatei hilfreich ist. Ihr werdet schnell merken, dass der beste Weg zum Erfolg oft darin besteht, vorhandenen Code zu kopieren und an die eigenen Bedürfnisse anzupassen.
Entwicklung benutzerdefinierter Log-Pfade (optional)
Ein Teil des lokalen Einhängepunkts umfasst eine vollständige Verzeichnisstruktur, sodass ihr vor Ort benutzerdefinierte Log-Pfade und Filter entwickeln könnt (Zugriff vom Container aus über den lokalen Einhängepunkt). In Teil3 dieser Blog-Reihe werden wir uns diesen Vorgang ganz genau ansehen; hier bleiben wir vorerst bei den dokumentierten Beispielen im lokalen Verzeichnis, die euch bei diesem Prozess helfen. Außerdem steht die gesamte Palette der vordefinierten Filter, Rewrites und Parser von SC4S zur Verfügung. Auch hier gilt: Der beste Weg zum Erfolg besteht darin, sich das Muster anzuschauen und die nötigen Teile zu kopieren bzw. einzufügen (und die Kommentare darin zu beherzigen)!
Dies ist außerdem ein Bereich, in dem wir uns auf Unterstützung aus der Community freuen würden. Fragt im Slack-Kanal nach, ob jemand aus der Community bereits einen passenden oder ähnlichen Log-Pfad bzw. Filter erstellt hat, den ihr nutzen oder abwandeln könnt. Und wenn ihr selbst einen benutzerdefinierten Log-Pfad bzw. Filter für ein Gerät entwickelt, der einen allgemeineren Zweck erfüllt, dann wäre es schön, wenn ihr die Erweiterung über das Github-Repo als Pre-Release zur Aufnahme in eine zukünftige Version von SC4S einreichen würdet.
Splunk Connect for Syslog – Community
Splunk Connect for Syslog wird von Splunk voll unterstützt und ist als Open-Source-Projekt veröffentlicht. Wir hoffen auf eine engagierte Community, die uns mit Feedback, Verbesserungsvorschlägen, Kommunikation und vor allem der Erstellung von Log-Pfaden (Filtern) tatkräftig unterstützt! Für die aktive Teilnahme stellen wir die Git-Repos zur Verfügung, wo formelle Anfragen zur Aufnahme von Funktionen (insbesondere von Log-Pfaden/Filtern), Fehlerverfolgung usw. möglich sind. Wir gehen davon aus, dass es mit der Zeit deutlich weniger „lokale Filter“ geben wird, da immer mehr Beiträge der Community in den Out-of-the-box-Konfigurationen der Container gekapselt sein werden.
Splunk Connect for Syslog – Ressourcen
Es gibt eine ganze Menge von Ressourcen, die euch bei der erfolgreichen Nutzung von SC4S unterstützen! Neben dem Haupt-Repository und der Dokumentation gibt es zahlreiche weitere Informationsquellen, z.B. diese:
- Teil 1: Splunk Connect for Syslog – Entstehung, Designziele und Architektur
- Support und Community-Diskussionen: https://splunk-usergroups.slack.com, #splunk-connect-for-syslog
- Probleme oder Verbesserungen: https://github.com/splunk/splunk-connect-for-syslog/issues
Wir wünschen euch viel Erfolg mit SC4S. Macht mit, probiert es aus, stellt Fragen, tragt neue Datenquellen bei und findet neue Freunde!
*Dieser Artikel wurde aus dem Englischen übersetzt und editiert. Den Originalblogpost findet ihr hier: Splunk Connect for Syslog: Turnkey and Scalable Syslog GDI - Part 2.
