Seite wählen

NETWAYS Blog

Ceph auf Raspberry Pi als Bastelstorage

Ceph auf Raspberry Pi als Bastelstorage ist eine (relativ) einfache Möglichkeit, eine Technologie wie Ceph auszuprobieren, ohne gleich Racks voller Server anschaffen zu müssen. Ceph hat mich schon sehr lange gereizt, es mal intensiver ansehen zu können, aber mich hat immer der doch nicht unerhebliche Hardware-Aufwand abgeschreckt. Nach etwas Recherche habe ich aber herausgefunden, dass man, mit einigen Kompromissen, durchaus ein taugliches System auch mit einfacher Hardware zum Laufen bekommen kann.

Da ich oft höre, dass ich zu viele Worte mache, dachte ich, ich lass den technischen Teil diesmal großteils weg und verlinke dafür auf die Anleitung, die ich selber benutzt habe. Doch eine Warnung vorweg: Das, was man sich damit bastelt, ist sicherlich nicht das, was man „Best Practices“ oder auch nur „stabil für Produktion“ nennen würde. Meiner Erfahrung nach reicht es aber auf jeden Fall für’s Home Lab, als Storage für einen Proxmox mit diversen Services für Home Automation (z.B. Homeassistant und Grafana mit InfluxDB) und als Ablöse für eine 10 Jahre alte Qnap (mit entsprechendem Backup jedenfalls).

Was ich verändert habe, zu der Anleitung ist folgendes

  • Statt PoE werden meine Raspis direkt mit Strom versorgt
  • Ich habe nur 3 Raspberry Pi, dafür weitere Knoten (siehe unten)
  • Statt der mikrigen USB Sticks, die hauptsächlich für Tests taugen, hab‘ ich jedem Raspi eine 8TB USB Platte verpasst (Muhahaha!)

Durch die insgesamt 24TB Storage, die sich bei mir ergeben haben, habe ich, trotz ausreichender Redundanz tatsächlich genug Platz, meine VMs und eben den Inhalt der Qnap dorthin übernehmen zu können. Da meine Raspberry Pi jeweils nur 4GB Ram haben, bin ich schon sehr weit von „Best Practices“ entfernt. Aber was soll ich sagen: Es funktioniert doch erstaunlich gut. Aber, es hat sich auf jeden Fall bewährt, einige der Ceph-internen Dienste auf andere Hosts auszulagern. Im nächsten Abschnitt erkläre ich kurz, wie.

Das Ceph nutze ich als Storage Backend für 3 Proxmox Hosts, wofür die drei Raspberry Pi gerade noch ausreichend sind. Spätestens wenn man aber Ceph-FS (also das Filesystem, das man direkt einbinden kann) möchte, braucht man noch weitere Dienste. Das geht sich auf den Raspberry Pis dann insgesamt nicht mehr aus. Nach der Anleitung erhält man über das Ceph Dashboard eine Möglichkeit, Dienste auf Knoten im Cluster zu verschieben. Ein „Dienst“ In diesem Zusammenhang ist dann „unter der Haube“ ein Docker Container, der auf dem angegebenen Host gestartet wird. Dabei sucht sich Ceph per Default einfach Knoten aus, auf denen die Container gestartet werden – meist mehrere für Redundanz. Wenn man das steuern will, kann man den Knoten Tags verpassen und Services an Tags binden. Um jetzt die Last von den Raspberry Pi zu bekommen, habe ich nochmal drei Knoten mit Fedora Server hochgezogen, diesmal aber in Proxmox. Um kein Henne-Ei Problem zu erschaffen liegt deren Storage auf den lokalen SSDs der Proxmox Hypervisor. Damit beantwortet sich auch die Frage, ob man in Ceph verschiedene Architekturen mischen kann: Ja. Im Endeffekt sind jetzt die „OSD“, also die Dienste, die sich ums Storage Management kümmern, auf den Raspis und alles andere auf den VMs auf dem Proxmox.

Ceph-Dashboard

Screenshot meines Ceph Dashboard

Wie geht’s weiter

Das schöne an Ceph ist, dass man beim Ausbau so flexibel ist. Wenn ich bei der Qnap mehr Speicher möchte, müsste ich aktuell eine neue Qnap kaufen und alle Platten ersetzen. Dagegen kann ich bei Ceph einfach noch einen Raspi mit einer weiteren Platte dazu stellen. Damit hätte ich nicht nur mehr Speicher, sondern auch mehr Durchsatz, mehr Ram, mehr CPU und vor allem mehr Redundanz.

Wenn’s mal zu langsam wird, könnte ich auch NUCs oder ähnliches Gerät mit anbinden und Dienste, die besonders viel Geschwindigkeit brauchen, dort laufen lassen.

Was waren die Probleme?

Am meisten geärgert hat mich, dass ich nicht kapiert hatte, dass die Ceph Container nur auf 64 bit Systemen laufen. Das heisst, man braucht erstens einen Raspberry Pi 4 (oder einen bestimmten 3er) und ein 64bit OS. Die Anleitung zeigt hier nur auf die Fedora Installationen. Die 64bit Variante muss man sich erst noch raus suchen. Bevor ich das kapiert hatte, musste ich meine Raspi ein paar mal neu aufsetzen.

Die 8TB Platten wurden mir lange nicht angezeigt. Man kann Platten in der Version des Dashboards, das mir installiert wurde, wohl nicht für die Verwendung vorbereiten. Dafür gibt’s dann folgenden Befehl, der die cephadm CLI in einem eigenen Container startet.

./cephadm ceph-volume lvm zap /dev/sda

Der Befehl plättet dann die Platte /dev/sda und stellt sie als ganzes für Ceph bereit.

Fazit

Sonderlich lange läuft meine Ceph Installation noch nicht, weshalb ich noch keine Langzeiterfahrungen damit anführen kann. Bisher lässt sie sich aber gut an, um Ceph mal kennen zu lernen und auch ausreichend Platz für zuhause bereitstellen zu können. Ich bin froh, dass ich es probiert habe und werde das System wohl langsam und nach Bedarf ausbauen.

Thomas Widhalm
Thomas Widhalm
Manager Operations

Pronomina: er/ihm. Anrede: "Hey, Du" oder wenn's ganz förmlich sein muss "Herr". Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 ist er bei der NETWAYS. Zuerst als Consultant, jetzt als Leiter vom Operations Team der NETWAYS Professional Services, das unter anderem zuständig ist für Support und Betriebsunterstützung. Nebenbei hat er sich noch auf alles mögliche rund um den Elastic Stack spezialisiert, schreibt und hält Schulungen und macht auch noch das eine oder andere Consulting zum Thema. Privat begeistert er sich für Outdoorausrüstung und Tarnmuster, was ihm schon mal schiefe Blicke einbringt...

Mermaid zum Visualisieren von Graphen

Gerade im Umfeld von Logstash-Pipelines steht man oft vor dem Problem, wie die einzelnen Code Teile zusammenhängen. Dafür hat sich für mich Mermaid bewährt.

Was mir an Mermaid besonders gefällt ist, dass man mit einer relativ einfachen Syntax Graphen definieren kann, die dann in verschiedenen Systemen gerendert werden können. Das kommt meiner Arbeitsweise beim Schreiben von Doku entgegen. Bietet aber auch die Möglichkeit, Konfiguration einfacher automatisch generieren zu lassen. Die Erstellung solcher Abhängigkeiten gestaltet sich damit einfacher als z.B. mit Graphviz. Klar sind die Möglichkeiten etwas eingeschränkt, aber wenn sie genau das bieten, was man braucht, dann stört das auch gar nicht.

Ich nutze den Mermaid Live Editor mittlerweile auch gern während unserer Elastic Stack Logmanagement Schulungen um interaktiv zu zeigen, wie sich eine Pipelinekonstruktion entwickeln kann. Natürlich kann man damit auch den Zusammenhang zwischen Komponenten eines Elastic Stack oder ähnliches wunderbar visualisieren.

Als einfaches Beispiel sei hier ein Setup gezeigt, das in einer Pipeline sowohl syslog als auch journald Events annimmt. Der Header und das Format unterscheiden sich, aber der eigentliche Inhalt ist gleich. Ausserdem sind hier noch zwei Pipelines, die Secure-Log und Cron Lognachrichten weiter zerlegen. Alle anderen Nachrichten werden nur vom Header befreit und gehen vorerst direkt weiter an Elasticsearch.

graph TD
    A[shipper] -->|syslog| B[syslog]
    A --> C[journald]
    B --> D[secure]
    C --> D 
    D --> E[forwarder]
    A --> E
    B --> E
    C --> E
    B --> F[Cron]
    C --> F
    F --> E

Direkt gerendert sieht das dann so aus:

Für die ganz Neugierigen sei noch gesagt, dass die Pfeile hier jeweils eine Übergabe per Redis-Key symbolisieren sollen. Der Übersicht halber wurde hier nur der syslog Key beschriftet. Man kann sich aber vorstellen, dass das entsprechend einfach auch mit den anderen funktionieren würde. Mermaid kümmert sich dann dabei darum, dass der Graph immer wieder so umgebogen wird, dass alles schön lesbar ist.

Die Namen der einzelnen Pipelines, bzw. deren Beschriftung, muss nur einmal angegeben werden. Der Mermaid-interne Name, hier immer nur ein Buchstabe, kann dann immer wieder verwendet werden, ohne den Namen jedesmal wieder anzugeben. Natürlich kann man sich auch die Zeit nehmen, die internen Namen sprechender zu gestalten, was durchaus für Übersicht sorgt.

Mermaid ist ein JS Projekt, das sich auch in andere Tools wie Wikisoftware integrieren lässt.

Und, Spoiler Alert!, Pipelines, die hier dargestellt werden, befinden sich auch recht aktiv in Entwicklung und sind für die Veröffentlichung geplant. Es gibt jetzt mit dem Elastic Common Schema endlich eine Nomenklatur für Felder, die es erlaubt, wiederverwendbare Pipelines zu bauen. Bei früheren Versionen war ja immer das das große Problem. Wenn jedes Setup ein Feld für den selben Inhalt beliebig benennen kann, wird’s schwierig mit dem wiederverwenden von Code. Das ist jetzt vorbei und wir versuchen, entsprechend Code zu produzieren.

Thomas Widhalm
Thomas Widhalm
Manager Operations

Pronomina: er/ihm. Anrede: "Hey, Du" oder wenn's ganz förmlich sein muss "Herr". Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 ist er bei der NETWAYS. Zuerst als Consultant, jetzt als Leiter vom Operations Team der NETWAYS Professional Services, das unter anderem zuständig ist für Support und Betriebsunterstützung. Nebenbei hat er sich noch auf alles mögliche rund um den Elastic Stack spezialisiert, schreibt und hält Schulungen und macht auch noch das eine oder andere Consulting zum Thema. Privat begeistert er sich für Outdoorausrüstung und Tarnmuster, was ihm schon mal schiefe Blicke einbringt...

Riesige Datenmengen transportieren – ein Ding der Unmöglichkeit?

Zugegeben, vor dem konkreten Problem, eine fast 2 TB große Datei von einem System zu transportieren, auf das man nur über mehrere Hops Zugriff hat, steht man nicht jeden Tag. Aber wenn doch, dann bietet eine ganze Sammlung an Tools eine gemeinsame Lösung an.

Mit „mehrere Hops“ ist gemeint, dass es nicht möglich ist, mit den üblichen Bordmitteln wie scp oder rsync Daten zu kopieren. Ein Beispiel könnte ein Citrix-Zugang mit PuTTy sein, der zwar Shell-Zugriff erlaubt, aber kein Kopieren. Im konkreten Fall „durften“ die Daten natürlich kopiert werden, es war schlicht nur technisch nicht „möglich“. Der Host, auf dem die Daten lagen, hatte Zugriff auf Websites im Internet durfte aber keine anderen Protokolle „nach draussen“ benutzen.

Zerhacken und Zerteilen um riesige Datenmengen transportieren zu können

Zwar ist es heutzutage eigentlich problemlos möglich, auch riesige Datenmengen von A nach B zu kopieren. Da wir hier aber von einem nicht unerheblichen Zeitraum sprechen, den die Kopie braucht und ein kurzer Abbruch wertvolle Zeit gekostet hätte, war der Ansatz erstmal folgender:

  • Die Daten so klein komprimieren wie es sinnvoll ist (hier mit bzip2)
  • Die Daten klein hacken (mit split)
  • Die einzelnen Stücke dann hochladen
  • Beim Empfänger zusammensetzen und entpacken

Das lässt sich ganz gut per Shell realisieren.

nohup time tar cjvf testdb.tar.bz ../backups/full/ &
split -b5000000000 testdb.tar.bz

Die Datenbank bestand dabei aus einigen sehr kleinen Dateien und einigen, die etliche GB und teilweise sogar über 1 TB groß waren. Es zahlte sich also nicht aus, die Dateien einzeln zu kopieren.

  • nohup lässt den Befehl weiterlaufen, auch wenn die Verbindung abbricht und schreibt den Output nach nohup.out
  • time gibt ab, wie lang das Komprimieren braucht. Weil ich einfach ein neugieriger Mensch bin
  • tar mit -j komprimiert die Dateien mit bzip2 statt gzip was in vielen Fällen zwar länger dauert aber deutlich kleinere Dateien hervorbringt
  • split hackt eiskalt die Dateien in kleine Teile. In diesem Fall jeweils 5 GB groß. Dabei hat der Befehl noch einige Optionen um einem das Leben leichter zu machen. Es zahlt sich aus, da etwas mehr nachzustöbern als ich das damals gemacht hab

Somit hat man dann eine große Anzahl „ausreichend kleiner“ Dateien. Mit tail -f nohup.out kann man beobachten, was sich gerade tut. Das geht auch, wenn disconnected wurde. Alternativ kann man auch screen oder tmux nehmen. Da diese Tools aber Probleme mit manchen remote Verbindungen machen und nicht immer zur Verfügung stehen, bleib‘ ich persönlich lieber bei nohup.

Übrigens sollte man nicht unbedingt an die maximale Obergrenze des Uploads gehen. Beim ersten Versuch hab‘ ich das getan und die Daten wurden teilweise von NextCloud verworfen. Warum, hab‘ ich nicht mehr versucht herauszufinden, weil es bei der Methode eigentlich egal ist, ob man wenige große oder sehr viele sehr kleine Dateien nimmt. 5 GB haben aber gut funktioniert.

Der Transporter

Zugegeben, ich hatte den Vorteil, eine NextCloud Instanz nutzen zu können, die noch dazu genug Platz bot. Der Trick funktioniert bis hier her aber natürlich auch mit jedem anderen Übertragungsweg. Auch wenn man die Dateien ggf. kleiner hacken muss.

Für den weiteren Schritt baut man sich ein kleines Script.

#!/bin/bash
for i in $(ls x*)
do
  curl -T $i -u transportuser:$MYPASSWORD 
done

Auch dazu ein paar Erklärungen.

  • ls x* gibt alle Dateien aus, die split erstellt hat. Ohne weitere Optionen startet der Name aller zerlegten Dateien mit x
  • In der NextCloud wird im Home von User transportuser der Ordner testdb angelegt
  • curl nutzt WebDAV um die einzelnen Schnippsel hochzuladen
  • Der User transportuser wurde dafür extra angelegt und der Ordner testdb den eigentlichen Empfängern freigegeben. Das erleichtert das Management und vor allem das Passworthandling
  • Das Passwort kommt im nächsten Schritt

Tatsächlich riesige Datenmengen transportieren

Das Script hat noch eine Einschränkung. Da es auf einem „fremden“ System liegt, möchte man darin natürlich nicht das Passwort eines NextCloud Users hinterlegen. Wir haben einige Möglichkeiten ausprobiert und dabei auch bedacht, dass man es evtl. aus der Shell-History oder der Prozessliste auslesen könnte. Das beste, das wir bisher gefunden haben ist eine Umgebungsvariable, die nicht in der History landet.

 export MYPASSWORD=mysupersecret
nohup time ./thetransporter.sh

Und wieder Erläuterungen.

  • Die erste Zeile ist um eine Stelle eingerückt. Das verhindert (üblicherweise!) dass sie in die Shell History aufgenommen wird. Bevor man sich darauf verlässt, sollte man das unbedingt testen!
  • Die zweite Zeile ruft schlicht das Script von oben auf, wo die Umgebungsvariable genutzt wird

Andere Lösungen, wie eine interaktive Angabe beissen sich sich mit nohup.

Ganz unabhängig davon, ob das Passwort hier sicher genug war oder nicht, schadet ein Wechsel des Passworts direkt im Anschluss sicher nicht. Hat man sich einen eigenen User für den Transport angelegt, kann man ihn auch einfach wieder entfernen.

Die Auflösung

Hat man die Daten so in die NextCloud gepushed, kann man sie einfach mit dem NextCloud Client auf ein eigenes Gerät synchronisieren lassen. Tip: Man kann im Client angeben, welche Ordner synchronisiert werden sollen und welche nicht, falls man mehrere Geräte angeschlossen hat.

Um die Daten wieder zusammenzubauen reicht ein schlichtes cat.

cat x* > testdb.tar.bz2
tar xvf testdb.tar.bz2

Und was? Ja, Erläuterungen.

  • split benennt die Dateien so, dass die alphabetische Sortierung von cat sie wieder richtig zusammenbaut
  • tar ist inzwischen so schlau, dass man die Kompressionsmethode nicht mehr angeben muss. Schadet zwar nicht, sieht aber irgendwie cooler aus so

Besonders charmant finde ich daran, dass es den Tools völlig wurscht ist, was in den Dateien drin ist. Ob das Klartext, binaries oder was auch immer sind. Sie tun ja nichts mit dem Inhalt, zerhacken sie nur und stückeln sie zusammen.

Wer uns gern an solchen Lösungen kiefeln und werkeln sehen möchte, schliesst am besten gleich einen Support-Vertrag bei uns ab.

Thomas Widhalm
Thomas Widhalm
Manager Operations

Pronomina: er/ihm. Anrede: "Hey, Du" oder wenn's ganz förmlich sein muss "Herr". Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 ist er bei der NETWAYS. Zuerst als Consultant, jetzt als Leiter vom Operations Team der NETWAYS Professional Services, das unter anderem zuständig ist für Support und Betriebsunterstützung. Nebenbei hat er sich noch auf alles mögliche rund um den Elastic Stack spezialisiert, schreibt und hält Schulungen und macht auch noch das eine oder andere Consulting zum Thema. Privat begeistert er sich für Outdoorausrüstung und Tarnmuster, was ihm schon mal schiefe Blicke einbringt...

Einsamkeit im Home Office. Ein Ansatz dagegen

„Man kann keine sozialen Probleme mit technischen Mitteln lösen“ hört man manchmal. Naja, als IT-Nerds können wir’s wenigstens mal versuchen. Ich werd‘ Dir jetzt nicht erzählen, dass wir gerade mitten in einer Pandemie stecken und man sich am besten von anderen Menschen fernhält. Falls Du das nicht glaubst, bist Du hier eh falsch. Da NETWAYS die Lage ernst nimmt und möglichst umfassendes Home Office ermöglicht bzw. fördert, sitzen viele von uns jetzt noch mehr zu Hause als sonst auch schon. Schon recht bald haben wir akzeptiert, dass das noch länger so bleiben wird und die Einsamkeit im Home Office uns einholen wird. Also haben wir begonnen, nach Lösungen zu suchen.

Eine kurze Vorgeschichte

Dass die NETWAYS Family großen Wert auf Zusammenhalt legt, sollte allen, die uns kennen klar sein. Deshalb gibt’s auch regelmäßig die „Startup-Days“. Davon wurde hier schon berichtet, deshalb nur die Kurzfassung: Alle können Vorschläge für Projekte einreichen und aus der ganzen Gruppe finden sich Teams zusammen, die daran arbeiten. So ergibt es sich, dass man mal mit Leuten gemeinsam eine Aufgabe angehen kann, mit denen man sonst nur selten Berührung hat. Ganz nebenbei fallen dabei auch immer einige Projekte raus, die weiterverfolgt werden und unser aller Leben bereichern

Aus gegebenem Anlass hab‘ ich dann vorgeschlagen, wir könnten doch nach Ansätzen suchen, um die Einsamkeit im Home Office möglichst zu minimieren. Dabei ist der Begriff „Einsamkeit“ so weit wie möglich gefasst. Damit ist nicht nur gemeint, dass man all jenen hilft, die alleine wohnen und so gar niemand zum Unterhalten außerhalb vom Job haben. Auch einfach um zu verhindern, dass man die anderen lieben Leute von NETWAYS zu sehr vermisst oder neu hinzu Gekommenen den Einstieg zu erleichtern, sollte die Lösung beitragen.

Außerhalb von Pandemie-Zeiten gab’s am Montag immer ein umfassendes Standup, bei dem alle sich im Kreis aufgestellt und der Reihe nach einen kurzen Überblick über die Pläne für die aktuelle Woche gegeben haben. Weil unser Bernd ein optimistischer Mensch ist, hat er den Termin auch gleich mal im Kalender von allen gelassen – nur wurde der eben nicht mehr wahrgenommen. Der Termin, nicht der Bernd.

Arbeitsgruppe gegen Einsamkeit im Home Office

Der Vorschlag, da etwas zu unternehmen, fand einigen Anklang und bald war auch eine kleine Gruppe beisammen, um sich auf die Suche nach der Lösung zu machen. Wie’s so ist mit weltumfassenden Problemen, dafür braucht sogar ein Spezialist:innenteam der NETWAYS mehr als 2 Tage, weshalb wir die Ziele bald mal etwas reduziert haben. Nach einem umfassenden Gehirnstürmen haben wir uns entschieden, erstmal mit einem Chatbot für unseren Rocket.Chat anzufangen, der die Einsamkeit im Home Office bekämpfen soll. Chatbot – echt jetzt? Ja, Chatbot.

Warum jetzt echt ein Chatbot? Weil wir etwas ausnutzen wollten, das man häufig erlebt, wenn gute Menschen unter Belastung stehen: Alle wissen, dass es Dinge gibt, die man tun könnte, die helfen könnten, viele planen, sie auch umzusetzen und fast alle sind dann doch zu eingespannt oder zu erschöpft um neben Arbeit und Alltag auch noch Gutes für sich und andere zu tun. Wenn aber jemand kommt und diese Menschen anstubst, dann raffen sich doch einige auf und gehen’s an. Es wird immer die geben, die sagen „Jo, eh“ und es dann einfach lassen, aber das muss auch mal ok sein. Das Ziel war nicht, alle zu etwas zu zwingen, sondern einfach das bisserl mehr Antrieb zu liefern, um es dann doch mal anzugehen.

Eine der ersten Funktionen des Chatbot war dann auch, in zufälligen Abständen zufällige Menschen in der Firma anzuschreiben und einen Vorschlag für eine gute Tat gegen Einsamkeit im Home Office zu unterbreiten. Explizit ohne Auswertung, ohne Fingerzeigen, ohne Zwang. Wer kann, macht, wer nicht, schafft’s vielleicht beim nächsten Mal. Das können so Dinge sein wie „Schlag doch mal ein kleines soziales Projekt vor“ (Yeah, Singularität in sozialen Projekten), „Schreib eine handschriftliche Grußkarte an $KOLLEG“, „Frag doch mal $KOLLEG wie’s gerade so läuft“. Um es kurz zu machen: Diese Funktionalität ist aktuell nicht aktiv. Aktuell wird nämlich eine andere verfeinert. Dazu gleich mehr.

Standup für alle aber nur mit wenigen

Was tun wir jetzt konkret? Der Chatbot generiert zu dem Zeitpunkt, an dem üblicherweise das NETWAYS weite Standup stattfindet einige Meetingräume im Jitsi, würfelt dann genau so viele Gruppen von Leuten zusammen und schickt allen den jeweiligen Link. So sind immer ein paar Leute gemeinsam in einer Jitsi-Session. Egal aus welchem Bereich von NETWAYS (oder Icinga). Da es immer nur eine handvoll Menschen sind, bleibt für alle genug Zeit, mal ein bissl was zu erzählen. So sieht man sich wieder, kann mal ein paar Worte wechseln und verliert sich nicht ganz aus den Augen.

Um den Vorschlag von vorhin wieder aufzugreifen schickt der Bot manchmal einzelnen Teilnehmer:innen einen Vorschlag mit, worüber man reden könnte. z.B. „Erzähl von dem, was Du diese Woche vorhast“ oder „Schlag ein kleines soziales Projekt vor“.

Wo viele Menschen zusammenkommen, menschelt’s und was zu erwarten war, ist gleich mal eingetreten. Die ersten waren zu beschäftigt oder was auch immer, um sich vom Chatbot ablenken zu lassen. Deshalb wurde auch gleich mal eine Blockliste eingeführt, auf dass manche nicht mehr behelligt werden. Der Bernd in seiner Weisheit weiß allerdings, dass es manchmal doch möglich und nötig ist, jemandem zum Glück zu zwingen und hat die wieder entfernen lassen. (Die Blocklist, um Missverständnissen vorzubeugen) In der Zwischenzeit hört man nix negatives mehr und ich geh mal davon aus, dass jetzt alle doch ganz froh sind, dass sie mal wieder mit den anderen Kontakt haben. Ok, als der Bot die Zeitumstellung verpennt hat, gab’s ein paar Sticheleien. Aber hey, so merkt man wenigstens, dass alle schon drauf warten, in die Standup-Runde eingeladen zu werden, um etwas weniger Einsamkeit im Home Office zu erleben.

Thomas Widhalm
Thomas Widhalm
Manager Operations

Pronomina: er/ihm. Anrede: "Hey, Du" oder wenn's ganz förmlich sein muss "Herr". Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 ist er bei der NETWAYS. Zuerst als Consultant, jetzt als Leiter vom Operations Team der NETWAYS Professional Services, das unter anderem zuständig ist für Support und Betriebsunterstützung. Nebenbei hat er sich noch auf alles mögliche rund um den Elastic Stack spezialisiert, schreibt und hält Schulungen und macht auch noch das eine oder andere Consulting zum Thema. Privat begeistert er sich für Outdoorausrüstung und Tarnmuster, was ihm schon mal schiefe Blicke einbringt...

Events im Elastic Stack verfolgen

Im folgenden gebe ich einen kurze Übersicht über ein paar Handgriffe, die sich beim Debuggen des Elastic Stack bewährt haben. Vor allem beim Beantworten der Frage „Wo verdammt sind meine Events?“

In Kibana

Zuerst wird man wohl bemerken, dass Events fehlen, wenn man sie in Kibana nicht finden kann. Bevor man sich aber in die Tiefen der Konfiguration begibt, sollte man also erstmal die Möglichkeiten des Webinterface völlig ausschöpfen.

  • Ist ein Filter gesetzt, der die Nachrichten ausblendet?
  • Wurde ein falscher Zeitbereich gewählt?
  • Kann es sein, dass der sendende Host eine falsche Zeiteinstellung hat und die Events deshalb an einer falschen Position des Zeitstrahls angezeigt werden?
  • Wurde das falsche Index-Pattern gewählt?

Einfach zurück setzen kann man die meisten dieser Einstellungen durch einen Klick auf die „New“ Schaltfläche im Kibana-Discover.

Führt all das nicht zum Erfolg, folgen tiefer greifende Schritte.

Message Broker

Sehr leicht nachvollziehen kann man, ob Nachrichten im Message broker festhängen, falls man denn einen benutzt. Füllen sich Redis, Kafka oder ähnliches, dann ist auf jeden Fall im Ablauf etwas falsch oder der Stack zu klein gesized. Bei mehreren Pipelines kann hier auch gut nachvollzogen werden, an welcher Stelle es klemmt. Dabei helfen aussagekräftige Namen beim Ablegen im Broker z.B. für Keys in Redis.

Den Füllstand des Brokers sollte man übrigens auch deshalb ständig im Blick haben. Das check_redis.pl Plugin für Icinga bietet sich dafür an.

Logstash

Bevor an der Konfiguration Änderungen vorgenommen werden, sollte unbedingt das Log von Logstash und Elasticsearch geprüft werden. Ein häufiges Problem ist ein „type mismatch“ in einem Feld, das verhindert, dass ein Event in Elasticsearch geschrieben wird. Beim Verwenden von dynamic mapping (dem default) wird jedem Feld der Typ verpasst, den das erste Event aufweist, das in diesen Index geschrieben wird. Steht also in client.port eine Nummer, wird Elasticsearch hier den Typ int zuweisen. Kommt später ein Event, wo client.port Text enthält (warum auch immer), dann wird dieses Event mit einer Meldung im Logstash Log verworfen.

Führt auch das nicht zum Erfolg, gibt es einige Tricks, die man anwenden kann, um die Funktionsweise genauer zu durchleuchten.

  • Einzelne Pipelines können in der pipelines.yml vorübergehend deaktiviert werden. Das bietet sich vor allem für „output“ oder „forwarder“ pipelines an, die an Elasticsearch schreiben
  • Jedem Filter eine id zu vergeben ist immer eine gute Idee. Damit kann man auch sehr gut im Kibana Monitoring sehen, welcher Filter wie viele Events verarbeitet
  • Praktisch ist auch, sich Konfigdateien zurecht zu legen, die nur für’s Debugging gebraucht werden. Bei Bedarf kann man diese in die Verzeichnisse der Pipelines kopieren und danach wieder löschen. Ich verwende dabei gern einen mutate Filter, der einfach nur ein Tag setzt, um zu sehen, ob überhaupt bestimmte Events durch eine Pipeline kommen. Außerdem eine weitere Datei mit einem file Output, der mir alle Events in der Pipeline in eine Testdatei schreibt. Optional kombiniert mit dem dot Codec kann man so sehen, wie viel durch fließt, wenn die genauen Events gar nicht relevant sind. Diese Files kann man dann einfach in die einzelnen Pipelines legen und wieder raus nehmen. Verwendet man sie mehrfach, muss man aber darauf achten, Doubletten zu vermeiden, also verschiedene Namen für Tags, verschiedene Files als Ziel etc.
  • Der obige Tip funktioniert natürlich auch mit mutate Filtern, die man kurzerhand mitten in die eigene Konfig schreibt – z.B. in ein if – um dort Tags und Felder mitzugeben, nach denen man dann sucht
  • Falls Logstash eine Pipeline nicht starten kann, liegt das häufig an Tippfehlern in der Konfiguration. Um diese zu finden kann man den Pfad der Konfig einer Pipeline aus der pipelines.yml kopieren und durch cat anzeigen lassen. Dieser Copy&Paste Ansatz verhindert, dass man z.B. nur eine einzige Datei in der pipelines.yml angegeben hat, aber erwartet, dass das ganze Verzeichnis angezogen wird. Wichtig dabei zu wissen ist, dass Logstash durchaus auch eine einzelne Pipeline offline nehmen kann und der Rest weiter läuft

Wer noch mehr zum Thema Troubleshooting bei Elastic Stack wissen will und das auch mal praktisch ausprobieren möchte, hat dazu in unseren Elastic Stack Schulungen zum Thema Logmanagement Gelegenheit.

Thomas Widhalm
Thomas Widhalm
Manager Operations

Pronomina: er/ihm. Anrede: "Hey, Du" oder wenn's ganz förmlich sein muss "Herr". Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 ist er bei der NETWAYS. Zuerst als Consultant, jetzt als Leiter vom Operations Team der NETWAYS Professional Services, das unter anderem zuständig ist für Support und Betriebsunterstützung. Nebenbei hat er sich noch auf alles mögliche rund um den Elastic Stack spezialisiert, schreibt und hält Schulungen und macht auch noch das eine oder andere Consulting zum Thema. Privat begeistert er sich für Outdoorausrüstung und Tarnmuster, was ihm schon mal schiefe Blicke einbringt...