Logstash-Konfiguration im Team

Das folgende Setup hat sich als Entwurf bei einem Kundenprojekt ergeben. Es ist noch nicht in die Realität umgesetzt, aber ich fand es interessant genug, um es hier teilen zu wollen.

Aufgabe

Hier kurz die Ausganslage, für die das Konzept erstellt wurde.

  • Mehrere Teams wollen Logs über den Elastic Stack verarbeiten
  • Die Logs sind teilweise Debuglogs aus Eigenentwicklungen. (Erfahrene Logmanagement-Admins lesen hier “sich häufig ändernde und nicht immer klar strukturierte Logformate”)
  • Die Logmanagement-Admins haben nicht die Kapazität, Logstash-Regeln für alle verwalteten Applikationen zu schreiben und vor allem nicht ständig anzupassen
  • Das zentrale Logmanagement ist sehr wichtig und soll durch unerfahrene Anwender nicht gefährdet werden

Lösungsansatz

Im Gespräch hat sich dann ein Setup ergeben, das ungefähr so aussehen soll:

  • Es wird eine Entwicklungsmaschine geschaffen, auf der die einzelnen Teammitglieder ssh-Logins bekommen. Auf dieser Maschine ist Logstash installiert, wird aber nicht ausgeführt
  • Jedes Team bekommt ein Repository in der zentralen Versionsverwaltung (z.B. GitLab ) und kann das auf der Entwicklungsmaschine auschecken. In diesem Repository befindet sich die gesamte Logstash-Konfiguration einer Pipeline und ggf. Testdaten (siehe weiter unten)
  • Die Mitglieder des Teams entwickeln ihre Pipeline und nutzen den lokalen Logstash zum Testen auf syntaktische Richtigkeit.
  • Optional können zusätzliche Pipelines zur Verfügung gestellt werden, die Beispieldaten einlesen und wieder in Dateien rausschreiben. Diese beiden Dateien können mit eingecheckt werden, man muss nur darauf achten, sie nicht so zu benennen, dass Logstash sie als Konfiguration ansieht. Es empfiehlt sich, die Beispieldaten aus allen möglichen Logzeilen der Applikation zusammenzusetzen. Bei Änderungen sollten auch alte Zeilen belassen werden, um Logs aller möglichen Versionen einlesen zu können. Sollen die Daten mit Elasticsearch und Kibana veranschaulicht werden, kann in den Beispieldaten ein Platzhalter für den Zeitstempel verwendet werden, der vor dem Einlesen durch die aktuelle Zeit ersetzt wird. Die Pipelines werden einmal eingerichtet und bleiben dann statisch, sie werden nicht von den Teams bearbeitet und befinden sich nicht in zugänglichen Repositories
  • Beim Commit der Konfiguration in Git wird ein pre-commit-hook ausgeführt, der nochmal mit Logstash testet, ob die Konfiguration fehlerfrei ist. (Vertrauen ist gut, etc.)
  • Ist der Commit gut verlaufen, wird nach dem Push ein CI Tool wie Jenkins benutzt, um die aktuellen Stände sämtlicher Pipelines auf einer Testmaschine auszurollen. Dort wird Logstash dann kurz gestartet, mit fest konfigurierten Pipelines, die Daten einlesen und ausgeben. Statt wie auf einem Produktionssystem Ports zu öffnen und an Elasticsearch oder Icinga zu schreiben, werden die Logdaten aus den eingecheckten Dateien mit Beispieldaten gelesen und in Dateien geschrieben. Dabei ist es wichtig, dass alle Daten von allen Teams in die selbe Instanz gelesen werden. Nur so kann verhindert werden, dass sich die Teams  gegenseitig “dreinpfuschen”
  • Die ausgegebene Dateien werden auf ihre Richtigkeit geprüft. Das klingt aufwändiger als es ist. Es reicht eigentlich, eine funktionierende Konfiguration mit den oben genannten in- und outputs laufen zu lassen und das Ergebnis als Vorlage zu verwenden. Diese Vorlage wird dann mit dem tatsächlichen Ergebnis verglichen. Arbeiten die Teams schon im ersten Schritt mit den optionalen In- und Outputdateien, kann dieser Punkt stark vereinfacht werden, da man davon ausgehen kann, dass jeder seine eigenen Outputdateien schon berichtigt hat und sie nur mehr geprüft werden müssen
  • Abweichungen von der Vorlage werden überprüft und danach entweder die Logstash-Konfiguration erneut angepasst oder die Vorlage angepasst, sodass weitere Tests erfolgreich sind
  • War der Test erfolgreich, kann die Konfiguration getagged und auf den Produktionsservern ausgerollt werden

Weitere wichtige Punkte

Hier noch ein paar Punkte, die beim Umsetzen helfen sollen.

  • Logstash kann mit der Option -t auf der Shell gestartet werden. Dann prüft er nur die Konfiguration und beendet sich gleich wieder. Das kann auch in der logstash.yml hinterlegt werden
  • Um letztendlich zu verhindern, dass zwei Teams das selbe Feld mit unterschiedlichem Typ schreiben muss extra Aufwand betrieben werden. Entweder muss sich jeder an eine bestimmte Nomenklatur halten, oder jedes Team bekommt ein eigenes Feld und darf nur Unterfelder davon anlegen oder jedes Team schreibt in einen eigenen Index
  • Wenn jedes Team eine eigene Pipeline mit eigenem Input und Output bekommt, kann die Gefahr einer gegenseitigen Beeinflussung minimiert werden. Das ist aber nicht immer möglich oder sinnvoll. Oft schreibt ein Beat Logs von verschiedenen Applikationen oder es gibt nur einen gemeinsamen UDP/TCP input für syslog.
  • Jedes Team kann sich nach wie vor die eigene Konfig zerstören, aber mit dem oben geschilderten Setup kann man ziemlich umfassend sicherstellen, dass auch wirklich jeder nur seine eigene Konfig zerlegt und nicht alle anderen in den Tod reisst.
  • Die von den Teams verwalteten Pipelines haben jeweils nur einen Input aus einem Messagebroker (z.B. Redis) und einen Output ebenfalls in einen Messagebroker. Das kann der selbe sein, wobei dann darauf zu achten ist, dass der verwendete key ein anderer ist. So kann auf den verschiedenen Maschinen jeweils eine völlig andere Pipeline in den Broker schreiben oder raus lesen. Auf den Entwicklungsmaschinen wären es Pipelines, die mit Dateien interagieren, auf der Produktion dagegen z.B. ein beats input und ein elasticsearch output. Diese ändern sich ja nicht und können weitgehend statisch bleiben.
  • Das ganze ist momentan ein Konzept. Es kann natürlich sein, dass in der Umsetzung noch das eine oder andere Problem auftaucht, das bisher nicht bedacht wurde. Über Feedback würde ich mich auf jeden Fall freuen.
Thomas Widhalm
Thomas Widhalm
Lead Support Engineer

Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 möchte er aber lieber die große weite Welt sehen und hat sich deshalb dem Netways Consulting Team angeschlossen. Er möchte ausserdem möglichst weit verbreiten, wie und wie einfach man persönliche Kommunikation sicher verschlüsseln kann, damit nicht dauernd über fehlenden Datenschutz gejammert, sondern endlich was dagegen unternommen wird. Mittlerweile wird er zum logstash - Guy bei Netways und hält...

Things done wrong: Custom Packages

Homer Simpson
Als Consultant begegne ich öfter Konzepten jeglicher Art, sei es das ich sie erstellen darf oder mich bei der Umsetzung an diese halten muss. Besonders wenn letztere unkommentiert als Firmenrichtlinie hinzunehmen sind, komme ich oft nicht mehr aus dem Kopfschütteln raus. In diesem Blogpost will ich nun anfangen mit solchen Konzepten abzurechnen und werde wohl immer wieder neue Themen folgen lassen. Ich werde hierbei keine Kundenbeispiele direkt übernehmen sondern Beispiele mischen um es noch weiter zu überspitzen. Auch soll sich natürlich niemand angegriffen fühlen, wenn sein Konzept ähnlich aussieht, denn meist lässt es sich mit historisch gewachsen begründen. Aber vor allem will ich Probleme aufzeigen, die durch die Konzepte erstehen und dazu anregen solche veralteten Konzepte auf den Prüfstand zu stellen.
Das erste Thema, das ich aufgreifen möchte, ist das Thema Softwareinstallation. Die meisten Projekte und Administratoren haben mittlerweile eingesehen, dass lokale Installation aus dem Quelltext-Archiv nicht mehr zeitgemäß ist. Darum liefern Projekte oftmals auch direkt Pakete aus oder stellen zumindest die dazu nötigen SPEC-Files bereit. Die Gründe hierfür sind meist Nachvollziehbarkeit, geringerer Aufwand, kein Kompiler auf dem System, kein mühsames Ermitteln von Abhängigkeiten, etc. Daher existieren viele Konzepte für das Paketieren von Software, welche nicht vom Distributor ausgeliefert wird. Genau mit diesen möchte ich mich beschäftigen.
Nun auf welche Vorgaben trifft man häufig?
* Selbst paketierte Software soll in ein bestimmtes Verzeichnis installiert werden
* Die Software soll einem speziellen eigenem Benutzer gehören
* Alles soll aus einem einzelnen Paket kommen
* Das Paket soll schon die fertige Konfiguration enthalten
* Pakete müssen parametrierbar sein, da je nach Umgebung andere Pfade, Benutzer, etc. verwendet werden sollen.
Mit diesen Vorgaben möchte ich mich nun im Folgenden auseinandersetzen.
Das Argument selbst paketierte Software in ein eigenes Verzeichnis zu installieren ist üblicherweise Sicherheit. Dieser Mythos hält sich erstaunlicherweise und ich suche den Sicherheitsgewinn ähnlich verzweifelt wie den Yeti oder Nessie. Vielleicht lässt sich hier noch entsprechend argumentieren wenn das Verzeichnis mit speziellen Mount-Optionen als separate Partition eingehängt ist. Aber die Optionen, die einen wirklichen Sicherheitsgewinn bieten wie ACLs oder das Abschalten gewisser Optionen wie das Ausführen von Dateien, Uid-Flags, Devices, werden hier meist nicht genutzt. Zudem könnten diese meist besser und gezielter eingesetzt werden, wenn das Paket in Standardpfaden installiert ist und nur gewisse Verzeichnisse ausgehängt werden, zum Beispiel für temporäre Daten.
Gefährlich wird dies meist in Kombination mit der Vorgabe alles einem bestimmten Benutzer zu übereignen. Eigentlich ist ein Benutzername völlig egal. Benutzer unter denen ein Dienst läuft sollten sich aber üblicherweise nicht am System anmelden können und auch nicht auf schreibend auf ihre Konfiguration oder gar Binärdateien zugreifen können. Die Vorgabe kommt meist daher, dass der Benutzer dann allerdings zur Administration verwendet wird statt administratives und Dienstkonto zu trennen. Kann der Dienst nun seine Konfiguration schreiben, eröffnet dies viele Möglichkeiten für Exploits, denn es hat meist seinen Grund warum ein Dienst mit einem unpriviligierten Benutzer läuft. Noch besser wird es wenn der Benutzer den Dienst mittels sudo als root starten darf und Startskript, in dieses eingebundene Dateien oder Binärdateien verändern kann, damit sind in Sekunden die Rechte ausgeweitet, also genau das Gegenteil vom Ziel der Vorgabe erreicht.
Auch andere Sicherheitskonzepte wie SELinux werden durch die verbogenen Pfade schnell unwirksam, denn ohne die entsprechenden Dateikontexte greift die Policy nicht mehr. Der Aufwand Pakete so umzubiegen und dann weiterzupflegen, insbesondere wenn auch Python-, Perl- oder ähnliche Pfade umgebogen werden, ist dann üblicherweise auch so groß, dass Updates seltener gemacht werden als wenn die Software ohne weiteren Aufwand bezogen werden könnte. Auch dies setzt die Sicherheit weiter herunter.
Natürlich gibt es auch Konzepte, die den Aufwand gering halten, wie die von Red Hat eingeführten Software Collections, trotzdem muss immer noch selbst Aufwand betrieben werden. Der Aufwand ist dann besser darin investiert ein Konzept zu erstellen, welches dem Administrator der Zusatzsoftware erlaubt entsprechende Befehle mit sudo aufzurufen und Konfigurationsdateien über ACLs zu editieren, Logdateien zu lesen, …
Die Vorgaben zusätzliche Dateien oder angepasste Konfigurationen schon mit dem Paket mitzuliefern sind zwar machbar, erhöhen aber die Komplexität weiter und es lässt sich schwerer nachvollziehen woher Dateien ursprünglich kommen. Zusätzliche Dateien sollten also in eigene Pakete, Konfigurationen wenn man nicht auf eine Konfigurationsmanagementlösung setzen möchte in ein eigenes Konfigurationspaket. Über Befehle wie rpm -qf lässt sich dann nachprüfen aus welchem Paket eine Datei kommt, mit rpm -qi erhält man Informationen wie die Bezugsquelle und rpm -qV zeigt welche Dateien nachträglich verändert wurden.
Die Anforderung Pakete parametrierbar zu machen finde ich besonders seltsam, da es beim Paketieren nicht nur darum geht Software nicht auf dem System zu übersetzen, sondern auch Nachvollziehbarkeit in allen Aspekten zu schaffen. Da sich nie ausschließen lässt, dass ein anders gesetzter Parameter die ausgeführte Software beeinflusst, geht hierdurch für mich viel Nachvollziehbarkeit verloren. Diese möchte man besonders beim Updaten haben um Probleme auszuschließen.
Ich hoffe zum Nachdenken angeregt zu haben und Argumentationsgrundlagen für entsprechende Konzepte geliefert zu haben. Die nächsten Konzepte, die ich bei Gelegenheit betrachten möchte, sind das Benutzer- und Softwaremanagement und danach fällt mir bestimmt noch weiteres ein, wenn Interesse besteht. Und wer sein Konzept von mir zerpflückt haben möchte oder eins geschrieben braucht, ich bin natürlich ebenso käuflich wie die Kollegen. 😉

Dirk Götz
Dirk Götz
Senior Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.

Neu im NETWAYS Portfolio – Puppet Starterpaket

Puppet_LogoBei Puppet handelt es sich um ein OpenSource Konfigurationsmanagement System, welches vom amerikanischen Unternehmen PuppetLabs entwickelt wird.
Puppet bietet den Vorteil, Administratoren bei z.B. regelmäßigen Aufgaben wie Paketinstallation, Serverinstallationen oder Konfigurationsänderungen zu entlasten.
Das gesuchte Stichwort heißt: Automatisierung.
Um Unternehmen beim Einstieg in die Puppet-Welt zu unterstützen, bieten wir seit einiger Zeit das Puppet Starterpaket in zwei Varianten an:
Puppet Starterpaket Standard
Dieses Paket besteht aus einem 4-Tages-Workshop mit einem unserer Puppet-Consultants, welcher eine Evaluierung einer vorhanden IT-Umgebung vornimmt und anschließend eine mögliche Konzeptionierung aufzeigt, um Puppet erfolgreich zu implementieren. Anschließend wird der Puppet-Master sowie ein Versionskontrollsystem (z.B. SVN, Git, etc.) installiert, um Änderungen an den Puppet-Modulen nachzuvollziehen. Für einen noch besseren Einstieg, werden zusätzlich einige Beispielmodule erstellt, welche im späteren Verlauf natürlich weiter angepasst werden können.
Puppet Starterpaket Premium
Für komplette Einsteiger im Puppet-Bereich, die bisher noch keine persönlichen Berührungspunkte hatten, bieten wir im Premium-Starterpaket zusätzlich zu den 4 Workshop-Tagen noch 3 Tage Vor-Ort Schulung für 3 Teilnehmer an (weitere Teilnehmer gegen Aufpreis möglich).
Die Schulungsinhalte werden 1:1 von unserer Puppet Fundamentals-Schulung übernommen, inkl. Schulungsnotebooks, Schulungsunterlagen sowie ein Teilnehmerzeugnis.
Je nachdem wie komplex die Umgebung und die jeweiligen Anforderungen an das Puppet-System sind, können folgende Themen im Rahmen des Workshops noch mit aufgenommen werden:

  • Einrichtung von Foreman
  • Einrichtung der PuppetDB
  • Anbindung von externen Datenquellen

Selbstverständlich unterstützen wir auch bei individuellen Anfragen zum Thema Puppet oder beim Betrieb einer bereits vorhanden Puppet-Umgebung, auf Basis unserer Supportverträge oder von Consulting-Dienstleistungen.
Für einen persönlichen Kontakt stehen wir ebenfalls sehr gerne zur Verfügung – weitere Details für eine Kontaktaufnahme sind in unserem Kontaktformular zu finden!

Christian Stein
Christian Stein
Lead Senior Account Manager

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Senior Sales Engineer und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".