This entry is part 9 of 11 in the series logstash

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

Autor: Thomas Widhalm

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 Schulungen und erstellt Schulungsunterlagen zu diesem faszinierenden Tool.
Seit 2017 stellt er sich neuen Herausforderungen als Lead Support Engineer und versucht sein Wissen aus den vorgenannten Tätigkeiten im Produktsupport umzusetzen.