pixel
Seite wählen

NETWAYS Blog

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 https://nextcloud.example.com/remote.php/webdav/testdb/$i
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
Lead Senior Systems 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...

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
Lead Senior Systems 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...

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
Lead Senior Systems 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...

Is there a Company Backing PostgreSQL?

That’s a question I got asked when I was helping out at the PostgreSQL booth at this year’s FOSDEM.

I replied “yes”. And a second later, “there are even several!”.

But although the nerd density at FOSDEM is ridiculously high, I’m not sure he got that boolean joke “Are you going for lunch now or later?” “Yes.” … so, in the faint hope that, that guy will stumble upon this blogpost and hopefully as a nice read too many others, let me elaborate on that a bit.

PostgreSQL was Initially a Research Project

Back in the 1970’s, even in the US, universities could do research on things that would not directly lead to a patent for the corporate sponsor and a spinoff (owned predominantly by the corporate sponsor). They even received public money for such kind of research (whoo!), often from the DARPA.

Michael Stonebraker and Eugene Wong, who started PostgreSQL’s predecessor Ingres, were funded by a couple of military agencies, more detail here.

Stonebraker in fact did the spinoff “stunt” with Ingres which exists until today. However he returned to Berkeley to continue research on a “Post-Ingres” system, “Postgres”. Yada yada yada, long story short, Postgres was basically handed over to a group of enthusiast who kept working on it and turned it into PostgreSQL over time (we’re discussing the mid-90’s here). Some of those initial enthusiasts are still actively working on the project btw., one, Bruce Momjian, even attending FOSDEM on a regular basis!

It Today is a Community Project

The database system today is “owned”, which is in fact impossible due to the ridiculously open license, be the PostgreSQL Global Development Group, a non-profit that mainly runs the different postgresql.org sites. Alongside, there are several national & international non-profits, e.g. PgUS, PgEU and countless local usergroups, see the community page to get an idea.

… that allows a lot of Companies to generate Profit of it

So, people started doing serious stuff with Postgres, ran into problems and had them resolved, wanted advice on certain issues, get trained, or just someone to look after their databases on a regular base. Companies were founded, that specialised on PostgreSQL support and consulting. Some of these vanished, some still exist.

Some of these companies offer proprietary products that base on PostgreSQL. Also, there were “spinoffs”, companies that took the PostgreSQL code and ran with it, making something new of it. Just as well, some of these still exist and make good business.

… which some Feed Back partly into the Project

Many, if not most, of these companies contribute to PostgreSQL one way or the other. As a matter of fact, the vast majority of the core team members and major contributors work for a handful of companies.

Still, these people are probably working for those companies, because they are major contributers. E.g. Tom Lane these days works for Crunchy Data, but has been working for e.g. Red Hat and Salesforce before (rumours are that Salesforce hiring Tom was a huge factor in the Salesforce-Oracle “war” and led to their 2013 partnership – most probably due to a massive discount that Salesforce were willing to agree to…).

Corporate contributions are mostly code by hiring people, who hack on PostgreSQL and money by sponsoring infrastructure or events.

The community is rather small, so is the circle of corporate players. At the end of the days, everyone knows everyone and is engaged in a coopetition.

Most corporate code contributions stem from their customers’ requirements. Some improvements go to the proprietary variants first, very few go there only. However, the ultimate goal usually is to get a feature into the core product, so mainline, community PostgreSQL.

So how does this Model differ from Other Popular Projects?

Linux

These days, when we mention the kernel, we usually mean Linux, that has the Linux Foundation, essentially backed by all major players in IT, which realised that Linux is useful to them and decided to fund the development (essentially ending the UNIX wars).

There are only few, if at all, companies that “span off” the kernel, but the vast majority of code contribution these days is coming from corporations or their employees.

Some of these in turn “sell” Linux as distributions, essentially subscriptions today. Their share of Kernel contributions is a huge selling point.

Others, take NIC or SCSI controller manufacturers for example, were initially (like, 25 or 20 years ago) just hoping to sell a few more of their products by offering some nerd enthusiasts specs and technical documentation. Today, they know they just can’t sell anything that isn’t properly supported by Linux, and thus are willing to hire full-time developers to ensure so.

All of those contributions still go over the “benevolent dictator“‘s desk or one of his aides’ and thus have to fulfil certain requirements. And the distributors agreed years ago to only include mainline features in their products, to avoid fragmentation.

A major difference to PostgreSQL: all those companies (distributors aside) use Linux for their resp. products, not as their product.

MySQL / MariaDB

MySQL initially was written by the founders of MySQL AB, which was acquired by SUN in 2008, which in turn was acquired by Oracle in 2010.

While being an Open Source product and even being GPL-licensed as Free Software, MySQL was never renowned for being very open to contributions, however MySQL AB and SUN were striving to improve the product, based on what the “community” was wishing.

Oracle, being the major player in the RDBMS market, obviously has no interest in improving a “free” piece of software to a degree that it could effectively cannibalise their core product … so, the MySQL founders founded MariaDB and took a significant part of the MySQL developers with them.

Both products still evolve, but development is steered and driven by Oracle and MariaDB respectively (no idea what I should think of the MariaDB Foundation, to be totally honest), so probably to a good degree by the marketing departments and in Oracle’s case, fenced by the limitations from “above”.

Sure, you can get support from independent companies (many of those also offering PostgreSQL services, btw.). However, any large customer like financial institutions, the public sector, etc. prefer to go “straight to the source”, so chances are that offering support will stay a niche market. Percona maybe being the exception.

MongoDB et. al.

The “NoSQL” market is (IMHO) to a certain degree a reply to the pricing policy of RDBMS vendors and the “better safe than sorry” mentality of many IT managers. But that’s a different story …

However, a certain pattern has evolved over the last years:
Some Open Source projects become popular, companies are founded, the development is centralized there, conferences and trainings are offered etc.
And at some point, someone decides that actually earning money would be a nice idea …

So, an “enterprise” product is introduced, or a dual-license model, or a cloud service with limitation of competitors’ ability to offer such, etc. pp.

In essence, these are often Open Source products, but not Free Software. They sometimes get crippled beyond recognition.
The communities could sometimes be called that way because the mawning people in the forums are “managed” by “community members”.

Is this healthy? Couldn’t a Company buy PostgreSQL, like Oracle did with MySQL?

Short: No.
Longer: Sure, e.g. Oracle could probably buy one or most of those companies, but the product PostgreSQL is not “theirs”. I mean, even MySQL was forked after the acquisition of SUN …

We’ve seen PostgreSQL companies get bought, sometimes they even disappear from their “natural” markets.
But that had no significant impact on the project’s structure, pace or harmony.

PostgreSQL

  • is “smaller” than MySQL, Linux or many other important FOSS projects
  • we don’t have the Kernel.org power
  • nor Oracle’s cash and licensing department
  • is not controlled by any single entity, thus
  • “more free” than many other “open source” projects/products
  • can not be bought, shut down or in any way be tampered with
  • will never change its license
  • will never disappear
  • yet feeds a lot of mouths directly and many, many more indirectly, like your humble author here
  • many contribute back one way or the other

PostgreSQL is much closer to the Linux model, coopetition of many companies, plus a fair share of “private” contributors, than to any other Open Source DBMS, relational or not.

This worked very good for the last 25 years, and I doubt it will ever change.

As someone (was it Bernd Erk?) coined:
> “PostgreSQL doesn’t have a community, it is one!”

I second that!

Über den Author:

Gunnar “Nick” Bluth hat seine Liebe zu relationalen Datenbanken Ende des letzten Jahrtausends entdeckt. Über MS Access und MySQL 3.x landete er sehr schnell bei PostgreSQL und hat nie zurückgeschaut, zumindest nie ohne Schmerzen. Er verdient seine Brötchen seit beinahe 20 Jahren mit FOSS (Administration, Schulungen, Linux, PostgreSQL). Gelegentlich taucht er auch tiefer in die Programmierung ein, so als SQL-Programmierer bei der Commerzbank oder in App-Nebenprojekten.
Thomas Widhalm
Thomas Widhalm
Lead Senior Systems 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...

Namen sind Schall und Rauch? Lieber nicht.

Das Problem

Bei vielen Projekten zu Logmanagement stellt sich recht schnell die Frage nach der Benamsung der Felder, in die Events zerlegt werden sollen. Da man sie weitestgehend frei wählen kann, startet so schnell ein gewisser Wildwuchs und das unabhängig davon, ob der Elastic Stack oder Graylog verwendet wird, um die Nachrichten zu “zergrokken”, wie es mal ein Kunde so schön formuliert hat.

Das Kuddelmuddel rund um die Feldnamen hat einige Nachteile, die früher oder später zuschlagen:

  • Ein Feld innerhalb eines Index darf nur einen Typ haben. Wenn also zufällig zwei Regeln ein Feld namens errorlevel anlegen und eine schreibt debug rein, die andere 4 wird das früher oder später dazu führen, dass Events von Elasticsearch abgelehnt werden
  • Gemeinsame Dashboards gestalten sich schwierig, wenn die IP des sich verbindenden Hosts mal in client , mal in client_ip und mal in anfragenderhost drin steht
  • Andere Tools und mitgelieferte Regeln / Dashboards haben keine Möglichkeit, vorherzusagen wie Felder heissen werden, deren Informationen sie brauchen

Schon immer galt die Empfehlung, sich ein Namensschema zu überlegen und sich strikt dran zu halten. Das klappt leider meist schon nicht, wenn nur eine Person dran arbeitet und wird nahezu unmöglich, wenn mehrere Teams eine gemeinsame Konfiguration pflegen. Das muss gar nicht einer gewissen Nachlässigkeit geschuldet sein, sondern kann alleine schon daraus resultieren, dass die gleichen Dinge manchmal in verschiedenen Teams einfach unterschiedlich genannt werden. Man muss nur an die Diskussion rund um “Satellite” oder “Slave” bei Icinga 2 oder die verschiedenen Logstash Instanzen (“Shipper”, “Indexer”, “Forwarder”, “häh?”) denken, um ein naheliegendes Beispiel zu haben.

ECS to the rescue

Elastic hat nun eine schöne, wenn auch noch nicht umfassende Lösung dafür geschaffen: Das “Elastic Common Schema”, kurz ECS.

Beschrieben in einem eigenen Abschnitt der Dokumentation. Darin sind Regeln festgelegt, wie Felder heissen müssen, die bestimmte Daten beinhalten. So gibt es z.B. nicht mehr logsource oder beat.hostname sondern host.hostname (der Host, auf dem das Event passiert ist, das den Logeintrag ausgelöst hat) und agent.name (Name des Agenten, der die Nachricht verschickt hat – kann der Hostname sein, aber auch ein Custom Name, falls z.b. mehrere Filebeat auf einem Host laufen)

Definiert im ECS sind eine ganze Menge von Überkategorien unter denen dann verschiedene Unterfelder definiert sind, die dann wiederum einen “Level” haben. Der Level gibt an, ob die Felder nach Möglichkeit befüllt werden sollen (“core”) oder eher optional sind (“extended”). Die core-Felder werden auch von diversen Tools des Elastic Stack genutzt, um automatische Auswertungen zu erlauben, was gleich einen riesigen Vorteil des ECS offenbart: Man kann damit viel einfacher fertige Lösungen verschicken, weil man nicht mehr rätseln muss, wie denn die Felder heissen könnten, in denen die wertvollen Informationen stecken.

So wird den meisten langjährigen Usern von Kibana aufgefallen sein, dass es inzwischen eine grosse Menge weiterer Tools in Kibana gibt als die klassischen “Discover”, “Visualize” und “Dashboard”. Die neuen Tools wie SIEM oder Infrastructure verlassen sich darauf, dass die benötigten Informationen in den richtigen Feldern abgelegt sind. Wenn man also ECS umsetzt, dann funktioniert z.B. der SIEM Teil von Kibana mehr oder weniger ohne weiteres zutun.

Im ECS ist auch definiert, welchen Typ welches Feld haben sollte. Sprechen Beats direkt mit Elasticsearch, kümmern sie sich darum, dass das richtig gesetzt wird. Baut man seine eigene Zerlegung in Logstash oder Graylog, dann sollte man darauf achten, dass die Felder auch entsprechend typisiert sind. In den meisten Fällen ergibt sich das aus der Art von Information, die im Feld gespeichert wird automatisch – man sollte dennoch immer wieder mal kontrollieren, ob nicht das eine oder andere durchgeschlüpft ist. Es sollte aber auch nichts dagegen sprechen, die Multifields von Elastic Search zu nutzen. Wird also ein Feld vom Typ keyword gefordert, kann man es auch als string in Elasticsearch schreiben, da der immer sowohl als text und als keyword abgelegt wird.

Der Umstieg

Wer schon ein funktionierendes Logmanagement hat, kann übrigens ziemlich sanft auf ECS umsteigen. ECS erlaubt nämlich ausdrücklich auch, eigene Felder zu definieren. Anders ausgedrückt sollten die relevanten Informationen in den angegebenen Feldern vorhanden sein. Ausser der dabei entstehenden Ressourcenverschwendung spricht aber nichts dagegen, die Daten auch in den zuvor genutzten Feldern vorzuhalten, solange man migriert. Man kann also die Information durchaus duplizieren, falls das nötig ist.

Wer noch ältere Clients im Einsatz hat, muss ohnedies vorsichtig sein, da Elastic die Standardfelder, die automatisch hinzugefügt werden, im Laufe der Zeit in einer nicht abwärtskompatiblen Art verändert hat. So kommen insbesondere Logs, die über Syslog verschickt wurden mit einem host Feld, in dem schlicht der Hostname drin steht. Laut ECS (und damit auch in Events von Beats) ist host aber ein “Nested Field”, das selbst wieder Unterfelder beinhaltet. Schickt man also in den selben Index Events, die man über Syslog-Protokoll erhalten hat und solche, die via Beats eingeliefert wurden, dann hat man leicht einen type mismatch. Dabei ist das nur eines von mehreren möglichen Beispielen. Die Logs von Elasticsearch und Logstash bzw. Graylog zeigen, wenn Events abgelehnt werden und üblicherweise auch wieso.

Eine gewisse Herausforderung ist dabei wieder, sich in die verschiedenen Positionen hineinzuversetzen. Aus Sicht des Logadmins ist der Client vielleicht der Agent, der die Nachricht verschickt, aber aus der Sicht dessen, der die Nachricht zur Überwachung seiner Applikation benötigt, ist der Client der, der mit seiner Applikation gesprochen hat. Dafür gibt es eben eigene Felder wie agent oder event, die Metadaten beinhalten können, die sich nur auf das Logmanagement beziehen, nicht auf den Inhalt der Nachricht. Das Problem ist aber nicht ECS spezifisch, sondern allgemein etwas, das Logadmins plagt.

Abschliessendes

Wer neue Regeln zum Zerlegen von Events anlegt, sollte aber von vornherein darauf achten, dass das ECS eingehalten wird. Dazu sollte man noch ein Feld mitgeben, das die ECS Version anzeigt, um in Kibana für Klarheit zu sorgen und ggf. noch ein paar Regeln kurz vor den Outputs einzuführen, die alte Nachrichten nachbessern. Das haben wir z.B. auch in der Logstash Pipeline für Icinga Logs getan.

Wer sich dazu noch etwas ausführlicher erzählen lassen möchte, kann ja mal in einer unserer Elastic Stack Schulungen vorbei schauen.

Thomas Widhalm
Thomas Widhalm
Lead Senior Systems 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...