"Wie Jede:r weiß, hat JEDER Monat 31 Tage"

Der Code von Monitoring-Plugins spielt für gewöhnlich in einer eigenen Liga: Leider tendenziell in der Kreisliga. Das Phänomen scheint so systematisch zu sein, dass es eine eigene Kategorie an DevOps-Desastern rechtfertigen würde. Und deswegen jetzt und hier die neue Kategorie Monitoring.

Eine fundierte Erklärung für das Phänomen kann ich nicht liefern, daher muss ich es bei Vermutungen belassen. Monitoring-Plugins werden in erster Linie von Ops-Menschen entwickelt, die ihren Software-Stack monitoren müssen. Und in dem Maße, wie die Dev-Fraktion die Aspekte von stabilen Operations nicht auf dem Schirm hat, mangelt es in der Gegenrichtung an fundiertem Dev-Wissen rund um Clean Code und saubere Software-Architektur (…und wenn ich dem Feedback aus unseren Dev-Teams Glauben schenken darf, bin ich nicht frei von diesem Phänomen hust). Deswegen heißt diese Seite auch DevOps-Disasters, oder was habt ihr erwartet?

Uraufführung heute mit einem Sensu-Plugin für Elasticsearch. Elasticsearch wird oft in Kombination mit Logstash und Kibana eingesetzt, um große Mengen Logdaten einzusammeln und auszuwerten. Die ganze Konstruktion ist unter dem Namen ELK-Stack bekannt. In Elasticsearch werden sogenannte Indizes angelegt, in denen die Logdaten gespeichert werden. In der Default-Konfiguration legt Logstash täglich einen solchen Index an.

Wenn nun das Sensu-Plugin ums Eck kommt und in die Elasticsearch-Datenbank schaut, um die oben beschriebenen Indizes zu inspizieren, muss es herausfinden, welche Indizes untersucht werden sollen. Will ich beispielsweise wissen, ob in der letzten Woche sinnvolle Daten geschrieben worden sind oder es signifikante Ausreißer gibt, die ein Fehlverhalten andeuten, müssen die letzten sieben Indizes betrachtet werden. Will ich sicherstellen, dass alte Logdaten sauber gelöscht werden, um z.B. den Anforderungen der DSGVO zu genügen, brauche ich alle Indizes älter als 3 Monate. Das Sensu-Plugin muss also ausrechnen, welche Tage gemeint sind. Und hier ist der Code, der genau das versucht ¹:

curr = end_time.to_i
start = curr

if config[:minutes_previous] != 0
  start -= (config[:minutes_previous] * 60)
end
if config[:hours_previous] != 0
  start -= (config[:hours_previous] * 60 * 60)
end
if config[:days_previous] != 0
  start -= (config[:days_previous] * 60 * 60 * 24)
end
if config[:weeks_previous] != 0
  start -= (config[:weeks_previous] * 60 * 60 * 24 * 7)
end
if config[:months_previous] != 0
  start -= (config[:months_previous] * 60 * 60 * 24 * 7 * 31)
end

Was die Entwickler:innen dieses Monitoring-Plugins über Zeit glauben:

• Jede Minute hat 60 Sekunden.
• Jeder Tag hat 24 Stunden.
• Jeder Monat hat 31 Tage (muss ich nicht verlinken, oder?).

Im Quelltext finden sich darüber hinaus noch weitere kühne Annahmen:

• Elasticsearch wird immer in Kombination mit Logstash benutzt.
• Logstash-Indizes werden immer täglich oder stündlich angelegt.
• Alle Elasticsearch-Server werden mit UTC betrieben.

Lessons learned?

Der Umgang mit Datum, Uhrzeit und Zeitzonen ist kompliziert und voller Fallstricke. Neben naheliegenden Stolpersteinen wie Zeitumstellung, Schaltjahren und Zeitzonen gibt es weniger offensichtliche Schmankerl à la Zeit vor dem 01.01.1970 oder die Zeitzone LMT. Warsaw mean time anyone? Der Versuch, diesem Durcheinander mit selbstgestricktem Code beizukommen, ist zum Scheitern verurteilt. Glücklicherweise unterstützen alle modernen Betriebssysteme den Umgang mit Zeit und gängige Programmiersprachen bringen etablierte Bibliotheken mit, die darauf aufsetzen (bspw. Python, Ruby/Rails, PHP). Ihr habt in eurem Code mit Zeit zu tun? Nutzt diese Bibliotheken!

Darüber hinaus ist Monitoring-Code Quellcode und es gelten dieselben Ansprüche, wie an jeden anderen Anwendungscode auch: KISS; DRY; Clean-Code; Designpatterns; Unit-Tests & Co. DevOps bedeutet nicht nur, dass Devs mehr Ops auf dem Schirm haben, sondern auch umgekehrt.

Tags

Monitoring

Weitere Kategorien

CI/CD 1

Config handling 2

Monitoring 2