Seite wählen

NETWAYS Blog

Logstash 1.5 (bald) released

von | Mai 15, 2015 |

Während Version 1.5 von Logstash kurz vor dem Release steht, nehme ich mir kurz Zeit, schonmal einen Vorgeschmack darauf zu geben. Eine umfassende Liste der Änderungen findet man wie gewohnt im Changelog.
Besonders freue ich mich dabei auf folgende Neuerungen und Verbesserungen:

  • Plugin Manager: Man wird jetzt aus einer grösseren Menge an Plugins wählen und diese auch über Logstash nachinstallieren können. Ich hab‘ zwar noch kein konkretes Plugin, das mir abgehen würde, aber das eröffnet doch ganz neue Möglichkeiten.
  • Konfigurationsdateien können jetzt nicht nur aus dem lokalen Dateisystem, sondern auch über http angezogen werden. Vielleicht eine etwas abenteuerliche Methode, aber sicher ein Weg, Konfig auf mehrere Hosts zu verteilen. Andererseits setzt hoffentlich eh jeder Puppet ein, oder?
  • Filter, die neue Events generieren (split, multiline, etc) reichen diese jetzt korrekt an folgende Filter weiter.
  • Man kann jetzt ein Standardverzeichnis für eigene Patterns angeben. Damit spart man sich unter Umständen einiges an Tipparbeit.
  • Syslog Inputs, die mit Nachrichten in einem falschen Format gefüttert werden, schreiben jetzt eigene Tags, damit man sie leichter debuggen kann.logstash_01
  • Der Elasticsearch Output unterstützt jetzt https mit Anmeldung!
  • Mehrere Hosts im Elasticsearch Output für mehr Hochverfügbarkeit.
  • Heartbeat Information von Logstash, damit man ihn leichter monitoren kann.

Ausserdem wurden einige Teile anscheinend enorm in ihrer Performance verbessert, was sowieso nie schlecht ist und Kibana 3 verschwindet mit Logstash 1.5 auch aus dem Logstash Paket.
 

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...
Lies mehr von Thomas und triff unser Team

Elasticsearch Tribe Node

von | Apr 24, 2015 |

Elasticsearch hat sich einen Namen damit gemacht, in ungeahnte Grössen zu skalieren, aber manchmal ist ein Cluster einfach nicht genug. Für diese Fälle wurde der Elasticsearch Tribe Node eingeführt, eine spezielle Elasticsearch Instanz, die selber keine Daten hält, sondern mehrere Cluster miteinander verbindet und so den Zugriff auf die Daten der einzelnen Cluster erlaubt, als wären alle Daten in einem einzigen grossen Cluster vorhanden.
Allerdings wird der Tribe Node nicht verwendet, um Grössenbeschränkungen von Elasticsearch Clustern zu umgehen, da die Anzahl von Knoten innerhalb eines Clusters nur durch die zur Verfügung stehenden Ressourcen beschränkt ist. Dabei ist der Bedarf eines einzelnen Knoten so wenig, dass hunderte bis tausende Knoten innerhalb eines Clusters möglich sind.
Übliche Anwendungen des Tribe Node sind:

  • Organisatorische Einschränkungen: Verschiedene Teams sollen Zugriff auf ihren jeweils eigenen Cluster aber nicht auf die Cluster anderer Teams haben. Dennoch soll eine übergeordnete Instanz Zugriff auf alle Daten über eine gemeinsame Schnittstelle haben.
  • Rechtliche Einschränkungen: Wenn Daten in einer bestimmten geographischen Position (z.B. ein bestimmtes Land) gespeichert werden müssen, die Daten jedoch zentral abgefragt werden sollen. (Achtung, ich bin kein Jurist. Ob dieses Konstrukt wirklich solche Einschränkungen erfüllt, ist in den einzelnen Fällen extra zu ermitteln!)
  • Einschränken von Traffic: Besonders bei der Verwendung von Elasticsearch als Teil des ELK Stacks (also mit Logstash) werden oft sehr grosse Datenmengen in die Cluster geschrieben. Wird ein einzelner Cluster verwendet, um alle Daten aus Remote Offices oder verschiedenen Firewallzonen zu sammeln müssen entweder Daten vorgefiltert werden, wodurch auf Events verzichtet werden muss oder die grossen Datenmengen über Firewalls oder WAN Leitungen geschickt werden. Mit dem Tribe Node können die Daten lokal in eigenen Clustern gesammelt und zentral abgefragt werden, wobei nur die Anfrage und die aufbereitete Antwort übertragen werden müssen.

Die Konfiguration des Tribe Node ist denkbar einfach. Man gibt die Namen des Clusters in den folgenden Optionen in der /etc/elasticsearch/elasticsearch.yml an und startet den Dienst. Dabei sollte der Tribe node selbst jedoch keine Daten enthalten.

tribe:
  es1:
    cluster.name: cluster1
    discovery:
      zen:
        ping:
          multicast:
            enabled: false
          unicast:
            hosts:
              - 192.168.23.228:9300
  es2:
    cluster.name: cluster2
    discovery:
      zen:
        ping:
          multicast:
            enabled: false
          unicast:
            hosts:
              - 192.168.69.229:9300

Da sich die Cluster oft in verschiedenen Subnetzen befinden, wurde hier auch gleich multicast discovery deaktiviert und die Verbindungen zu Knoten aus den einzelnen Clustern per unicast htribe-nodeergestellt.
Wichtig ist, dass man am Tribe Node zwar lesen und schreiben, jedoch keine Indices anlegen kann. Will man also Kibana auf so einem Tribe Node nutzen, muss man den von Kibana zu nutzenden Index für eigene Daten (Dashboards, etc.) in einem der im Tribe Node zusammengefassten Cluster selbst anlegen bzw. Kibana erst mit einem der Cluster verbinden und den Index anlegen lassen, bevor man es auf den Tribe Node umleitet.
 
Mehr Info zum Tribe Node gibt’s in der Elasticsearch Dokumentation.

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...
Lies mehr von Thomas und triff unser Team

OSDC 2015 – Enterprise integration with open source, day 2

von | Apr 23, 2015 |

Attending conferences of a certain size always brings the pain of deciding what talks to listen to. I really wished I could listen to all of them live but at least there are the OSDC archives, so I will be able to watch what I’ve missed when the videos will be edited and uploaded. Following are my personal impressions of the talks I chose from the tracks.
Despite being at least a bit tired from attending the OSDC evening event at the Paulaner Bavarian restaurant in Berlin yesterday talks were interesting enough that from the first talk on day 2 of the Open Source Datacenter Conference on the two rooms where talks were given were full of attendees again.
As first talk of day 2 Timo Derstappen used the Pixar movie plot schema „Once upon a time…“ to give an introduction into microservices and how orchestrate them using the „ambassador pattern“. He showed with his demo that systemd and fleet on CoreOS can be a real alternative when running multiple containers depending on each other.
After the first coffee break of the day Ingo Friepoertner gave a short overview over the history of databases and why NoSQL databases will not replace relational databases but are the better alternative for many applications. Using the concept of „Polyglot Persistence“ you will want to use the right store for the right job, so split data into different databases: Financial data in an RDBMS, user sessions in a KeyValue store and recommendations into a graph database and so on. To avoid getting stuck in a swamp of many different databases from many different vendors you can use multi-model databases to consolidate several of the beforementioned technologies into one product.

Ingo Friepoertner with Polyglot Persistence & Multi-Model #nosql Databases in MOA 4 #OSDC /eh pic.twitter.com/YQaUJamRh7

— netways (@netways) April 23, 2015


In the next talk Matthias Klein showed us how to keep development close to production by creating your own package repositories and copy only selected packages into them. Then use vagrant or Xen and puppet to create test hosts that resemble the production hosts as close as possible to roll out new packages, run tests from Jenkins and, if all went well, deploy the same packages on production systems. One of the most important factors will be to convince everyone that only packages in your repositories are allowed and that every configuration change has to be implemented in puppet so it can be reviewed more easily and tested on test hosts before the same configuration (with just some parameters replaced) goes on production hosts.
After the great lunch John Spray showed us what CephFS is, how it developed lately and what the current state is. Being not so familiar with Ceph like I wished I was, I was glad hearing that CephFS, a distributed filesystem on the Ceph backend, is available now (even if it’s not supported for enterprise use) and CephFS volumes can be mounted simultanousely on different hosts just like a network share. A great „new“ feature (which is available for about a year now, which is almost no age for enterprise grade software) is the combination of Cache Tiering and Erasure Coding which basically means having a fast but small pool of disks (preferably SSDs) that handles all of your I/O and a second pool of big, slow disks where data is not replicated like in standard Ceph pools but split like on RAID 5 / 6 / Z systems where automatically „cold“ data, which is rarely used, is moved to.

A really cool talk about @Ceph by @jcspray. Thanks for coming over! #osdc /be pic.twitter.com/4QV7wYkxgc

— netways (@netways) April 23, 2015


Next was a talk I anticipated a lot, personally. Pere Urbon talked about one of my most favourite toolsets, the ELK stack. He gave a quick explanation about what Elasticsearch, Logstash and Kibana are and what they are used for. Then he dug a bit into some real life examples about scaling the stack, especially by using a broker like Redis or RabbitMQ. In fact, RabbitMQ might be a real alternative to Redis and I will definitely see into the different possibilities, the various brokers have to offer. Not only Redis and RabbitMQ but Apache Kafka and some others. During the talk we learned a bit about the new features of the to-be-released-today Logstash 1.5 and the coming-someday Logstash 2.0. After the talk there was only one question unanswered: How is the Green Lantern Corps logo out of the slides related to the Marvel comic multiverse, Elastic normally gets most of its names out? 😉

Pere Urbon talks about Scaling #Logstash:A Collection oft War Stories in MOA 5 #OSDC /eh pic.twitter.com/4fqeiDUZoO

— netways (@netways) April 23, 2015


The last talk of the day I attended was Bernds talk about why to use Icinga instead of Nagios. Whoever reads this blog should already know that Icinga (2) is way cooler than Nagios so I will not go into detail about his talk. But you should definitely look at the video in the archive when it’s online even if you’re already convinced because Bernd’s talks are always worth the while.

OH: "I will focus on #icinga2 cause that's our new hot shit" – @gethash at #osdc 😀

— Michael Friedrich (@dnsmichi) April 23, 2015


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...
Lies mehr von Thomas und triff unser Team

Login Logs? Gern, aber bitte anonymisiert

von | Mrz 13, 2015 |

Wir werden bei unseren Terminen zu Logstash und ELK Stack, zum Glück, oft nach Möglichkeiten zur Anonymsierung von Informationen gefragt. Logstash bietet da schon out of the box Filter an, um sensible Daten zu schützen.
Die folgende Beispielkonfiguration zeigt gleich zwei Wege, automatisiert zu anonymisieren.

input {
  exec {
    command => "echo host=pc01.rbpd.le,user=SamuelReynolds,password=6oben1unten"
    interval => 30
  }
}
filter {
  kv {
    field_split => ","
    trim => "\n"
  }
  noop {
    remove_field => [ "password", "message" ]
  }
  anonymize {
    fields => "user"
    algorithm => "SHA1"
    key => "TheSnake"
  }
  noop {
    add_field => { "message" => "message was anonymized" }
  }
}
output {
  stdout {
    codec => "rubydebug"
  }
}

Dieses Beispiel lässt sich einfach in eine Textdatei kopieren und mit Logstash auf der Commandline ausführen, ohne, dass Elasticsearch oder Kibana bemüht werden müssten.
/opt/logstash/bin/logstash -f ./blogartikel.conf
Dabei sendet diese Konfiguration alle 30 Sekunden eine Beispielnachricht, die zerlegt und anonymisiert wird und gibt sie auf stdout aus.
Der kv Filter zerlegt die Nachricht in einzelne Key-Value Paare und macht daraus Felder mit dem Namen des Key und dem Wert des Value. Liesse man die weiteren Filter weg, sähe die Nachricht wie folgt aus:

{
       "message" => "host=pc01.rbpd.le,user=SamuelReynolds,password=6oben1unten\n",
      "@version" => "1",
    "@timestamp" => "2015-03-12T00:05:25.628Z",
          "host" => "pc01.rbpd.le",
       "command" => "echo host=pc01.rbpd.le,user=SamuelReynolds,password=6oben1unten",
          "user" => "SamuelReynolds",
      "password" => "6oben1unten"
}

Da das Passwort Feld eigentlich gar nicht in nachfolgenden Tools wie Elasticsearch auftauchen soll, wird es durch die remove_field Option des ersten noop Filters komplett entfernt. Ebenso wie das message Feld, das die zu anonymisierenden Daten ja ebenfalls enthält.
Der anonymize Filter erstellt aus dem Usernamen einen Hash, damit auch dieser nicht im Klartext vorliegt. Das hat den Vorteil, dass man weitere Abfragen und Kibana Dashboards verwenden kann, um festzustellen, ob z.B. ein bestimmter User versucht, sich auf verschiedenen Hosts mit falschem Passwort anzumelden oder an einem Host viele gleiche Logmeldungen produziert. Aber man sieht in Kibana eben nicht den Usernamen des Users. Sollte es nötig sein, kann mit dieser Information ein Admin, der Zugriff auf die Originallogs am sendenden Host hat, nachsehen, wie der User tatsächlich heisst, aber nicht jeder, der Zugriff auf Kibana hat, hat auch gleich alle echten Usernamen.logstash_logo
Achtung – SHA1 gilt nicht mehr als sicher und sollte nicht mehr für sensible Daten verwendet werden. Hier wird er verwendet, um den resultierenden Hash kurz zu halten und den Blogartikel nicht mit einem zu langen Hash zu füllen. Sollte es sich um Daten handeln, die „nicht einfach zugänglich“ gemacht werden sollen, aber nicht sicherheitsrelevant sind, kann durchaus auch SHA1 in Betracht gezogen werden, um nicht übermässig lange Lognachrichten zu produzieren und keine Ressourcen zur Berechnung unnötig langer Hashes zu verbrauchen. Diese Einschätzung muss aber von Fall zu Fall getroffen werden.
Der nachfolgende noop Filter fügt ein neues message Feld hinzu, um überhaupt ein solches Feld zu haben, da normalerweise jedes Event ein solches Feld hat und Filter und Dashboards sich üblicherweise darauf verlassen.
Mit den gezeigten Filtern sieht die Nachricht folgendermassen aus:

{
      "@version" => "1",
    "@timestamp" => "2015-03-11T23:22:35.293Z",
          "host" => "pc01.rbpd.le",
       "command" => "echo host=pc01.rbpd.le,user=SamuelReynolds,password=6oben1unten",
          "user" => "ee8a9e70ee30f82b7d169b4e259b052d3e6ef2db",
       "message" => "message was anonymized"
}

Da echte Daten nicht einfach vom exec Filter erzeugt werden, wird das command Feld für das Beispiel ignoriert, das hier ja auch wieder die sensiblen Daten enthält.
Um Anonymisierung bei Bedarf umkehrbar zu machen, kann der crypt Filter verwendet werden. Damit sind damit bearbeitete Felder für Kibana noch immer unlesbar, aber bei Bedarf und nach Freigabe können Admins mit Zugang zur Logstash Konfiguration die Felder wieder entschlüsseln.
P.S. Uns ist nicht entgangen, dass Kibana 4 released wurde. Da aber aktuell noch keine Pakete zur Verfügung stehen werden wir mit dem nächsten Artikel dazu noch etwas warten.

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...
Lies mehr von Thomas und triff unser Team

Get up and meet those pretty tags, tags, tags

von | Nov 21, 2014 |

Heute gibt es mal einen Tip direkt aus der Praxis. Wer sich schon länger mit logstash beschäftigt, wird bemerkt haben, dass sich das Format der Konfigurationsdateien mit der Version 1.3 etwas verändert hat, wobei die alte Form nach wie vor gültig ist. Geändert hat sich vor allem der Weg, wie tags und types zum Festlegen der Filter und Outputs verwendet werden, die ein Event durchläuft.
Dass es durchaus seine Tücken haben kann, dass das alte Format weiterhin seine Gültigkeit hat, habe ich kürzlich in einer Schulung am eigenen Leib erfahren müssen. Das hat allerdings auch sein Gutes. Erstens wird mir das ganz sicher nicht mehr passieren und zweitens habe ich so ein Thema, über das ich bloggen kann.
Auch wenn neuere User sicherlich inzwischen das neue Format verwenden, so stösst man doch immer wieder online auf Beispiele im alten Format und wenn man die per copy&paste übernimmt, passieren ganz leicht Dinge, die man so nicht vorhergesagt hätte.
logstash_01
Zum Vergleich erstmal, wie sich tags im alten Format verhalten. In input Blöcken bedeutet die Option tags, dass Tags zum Event hinzugefügt werden. In filter und output Blöcken, dass der Filter oder der Output nur auf Events angewendet wird, die dieses Tag bereits haben. Seit logstash 1.3 verwendet man stattdessen if Verzweigungen. Um tags in Filtern und Outputs hinzuzufügen, verwendet man übrigens add_tag
Mit Types verhält es sich ganz ähnlich, auch wenn man den nur im ersten logstash Input, den das Event durchläuft, setzen und nicht mehr verändern kann.
Also wird der erste noop Filter im folgenden Beispiel nur auf Events aus dem ersten Input angewendet, der zweite noop nur auf Events aus dem zweiten Input.

input {
  stdin {
    tags => stdin
    type => debuglog
  }
  tcp {
    port => 5514
    tags => tcp
    type => syslog
  }
}
filter {
  noop {
    tags => stdin
    add_tag => noop1
  }
  noop {
    type => syslog
    add_tag => noop2
}

Also merke: tags ist nicht gleich tags
In der neueren und aktuellen Form würde man das Beispiel von oben übrigens folgendermassen schreiben.

input {
  stdin {
    tags => stdin
    type => debuglog
  }
  tcp {
    port => 5514
    tags => tcp
    type => syslog
  }
}
filter {
  if ¨stdin¨ in [tags] {
    noop {
      add_tag => noop1
    }
  }
  if [type] == ¨syslog¨ {
    noop {
      add_tag => noop2
    }
  }
}

Das Beispiel soll möglichst deutlich zeigen, was das Verwirrende an dem Unterschied der beiden Schreibweisen ist und ist deshalb selbst bewusst nicht verwirrend gehalten.
Was dadurch regelmässig passiert ist, dass jemand die Option tags in einem Filter oder Output sieht und davon ausgeht, dass dadurch ein weiterer Tag gesetzt wird, nicht, dass dies eine Einschränkung auf gewisse Events darstellt. Will ich fälschlicherweise ein bisher nicht vorhandenes Tag mit tags in einem Filter setzen, wird dieser Filter natürlich nie angewandt, da ja nie ein Event mit diesem Tag kommen wird, da ich ihn ja erst setzen möchte. Für Neulinge ist das ein Stolperstein, bis diese Möglichkeit aus dem Format entfernt wird, aber auch Leuten, die intensiv mit logstash arbeiten, kann sowas als Flüchtigkeitsfehler passieren, wie ich mir eben vor kurzem selbst bewiesen habe.

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...
Lies mehr von Thomas und triff unser Team

Trainings

Web Services

Events