Vom Bordstein zur Skyline von Robert Waffen | OSMC 2019

This entry is part 2 of 2 in the series OSMC 2019 | Recap

 

Auf der Open Source Monitoring Conference (OSMC) 2019 in Nürnberg hat uns Robert Waffen mit seinem Vortrag “Vom Bordstein zur Skyline” in den Bann gezogen. Für den Fall, dass jemand nicht die Möglichkeit hatte, an seinem Vortrag teilzunehmen, haben wir hier etwas vorbereitet: Seht euch das Video von Roberts “Kriegsgeschichte” – wie er selbst es nennt – an und lest weiter unten eine Zusammenfassung.

Die OSMC ist das jährliche Treffen internationaler Monitoring-Experten, auf dem zukünftige Trends und Strategien festgelegt werden. Seit 2006 findet die Veranstaltung jedes Jahr im Herbst in Nürnberg, Deutschland, statt. Führende Spezialisten präsentieren die ganze Bandbreite des Open Source Monitorings und stehen bereit, um Fragen zu beantworten, und seien diese noch so schwierig. Lernt neue Techniken kennen, tauscht Wissen aus und diskutiert mit Top-Entwicklern.

Ausführliche Workshops am Tag vor der Konferenz und ein Hackathon bieten weitere Möglichkeiten, eure Fähigkeiten zu erweitern und euer Wissen im Bereich IT-Monitoring und -Management zu vertiefen.

Die nächste OSMC findet vom 16. bis 19. November 2020 in Nürnberg statt.
Weitere Informationen und Tickets unter osmc.de.


Vom Bordstein zur Skyline

Der Talk von Robert Waffen “Vom Bordstein zur Skyline” handelt von den Monitoring-Entwicklungsstufen des Unternehmens Publicis Pixelpark.

Wie war der bisherige Stand im Monitoring?

Bei Robert Waffen in der Firma war schon Xymon oder – noch früher – Zabbix im Einsatz, was nicht richtig gepflegt wurde. Und wenn, dann nur zum Teil. Das dadurch entstandene Wissen wurde abgewandelt und daraufhin auf zwei Elk-Instanzen umgestellt. Als Metriken wurden nur Default-Metriken verwendet, also das, was das System standardmäßig bereitstellt. Dazu gehörten Metriken in 5-Minuten-Intervallen.

Das ganze Monitoring war weder automatisiert noch teilautomatisiert. Konfigurationen oder Interfaces konnte man einchecken, wenn man sich durchklickte.

 

Xymon

Xymon hat natürlich wie jedes andere Monitoring-System Checks, wodurch Auswertungen gemacht werden, wie zum Beispiel Shell. Dabei wurde meistens sehr viel Output produziert. Und zwar nicht wie beispielsweise in Icinga eine Zeile, sondern ganze Prozesslisten. Das ganze Interface war nicht dynamisch und wurde in HTML vorgerendert, was wiederum eigene Vor- und Nachteile hatte. Bei HD-Grafen, die auch gerne ein bisschen größer werden, mussten diese gelöscht werden. Das eigentliche Problem war, dass es sehr hohe Check-Intervalle gab und keine Anbindung an Grafana oder sonstiges möglich war, da Xymon aus den 1990er-Jahren kommt. Zudem ein Thema, das immer wieder zu Problemen führte: Es gab keine richtige Verschlüsselung.

 

Zabbix

Bei Zabbix hingegen macht das GUI alles. Es gibt zwar ein Puppet-Modul, welches einen Server aufbauen kann, aber das Modul kann den Server nicht konfigurieren, was problematisch ist. Weiter war ein Update auf die neueste Version nicht möglich, weil interne Probleme auftraten. Das heißt, man ist bei einer älteren Version hängen geblieben.

Probleme wurden prinzipiell zwar immer angezeigt, aber nicht welcher Art. In einem Monitoring wurde der Alarm aktiviert. Daraufhin musste man in einem anderen System nachsehen und eventuell dort das Problem ausfindig machen. Man musste in mehreren Interfaces nachsehen, was sehr umständlich war.

Der Aufbau der GUI in Zabbix war auch nicht logisch, wenn man es mit anderen Monitoring-Systemen vergleicht. Es zeigte nur an, wenn ein Problem auftrat. Das Host-Objekt an sich gibt es in Zabbix gar nicht, an dem man sieht, dass der Host up ist und der Host folgende Daten hat… Das wird nicht angezeigt, man muss erst nach diesen Informationen suchen.

 

ELK

Zudem gibt es zwei verschiedene ELK-Stacks. Ein Stack ist schon etwas älter und beinhaltet sensible Daten eines langjährigen Kunden, die auch separat gehalten werden sollen. Daneben gibt es einen neueren Stack der Version 6 mit entsprechender Umgebung. Die Stacks sind alle manuell aufgesetzt und eine nachträgliche Automatisierung scheint nicht möglich, da sonst Indexe oder ganze Konfigurationen verworfen werden oder ähnliches. Deswegen wird hier ein Neuaufbau geplant.

 

Graylog

Als Alternative zum ELK gibt es auch noch Graylog. Das wird für neuere Kunden eingesetzt und funktioniert ganz gut.

 

Wie ist der aktueller Stand im Monitoring?

Aktuell sieht das Monitoring bei Robert so aus: Zabbix und Xymon dienen als Hauptmonitoring. Hier wurde ein Grafana mit diversen Quellen hinzugebaut, wie InfluxDB, Prometheus, Graphite oder ElasticSearch. Daneben existiert ein Proof of Concept für Icinga 2 und ELK 7.

 

Prometheus

Wir haben von null angefangen und ein Prometheus aufgesetzt. Wenn man sich damit beschäftigt, meint man erst, oh, ja, Kubernetes, da ist alles schön und toll. Da deployed man sein YAMLs und es ist alles schön und sicher – bis man von Systemen außerhalb von Kubernetes auf Metriken zugreifen möchte. Mit einem Reverse Proxy davorgebaut, mit einem Apache und HTTPS, und einem IP Require, so dass nur der Prometheus-Server den Node Exporter abfragen darf.

 

Icinga 2

Bei Icinga 2 hat man einen Pock aufgesetzt, der vollautomatisch aus dem Puppet generiert wird. Das heißt, wenn man den Host wegreißt und neu startet, werden alle Hosts, Konfigurationen, Checks wie vorher angezeigt.

So weiß man, woher der Check kommt. In Vergleich mit Zabbix und Xymon weiß man weißt nicht, woher die Checks kommen und warum etwas anspringt. Viele sagen, man brauche Automatisierung erst dann, wenn man mehrere Server hat. Aber es geht auch darum, nachvollziehbar zu arbeiten, um Konfigurationen einsehen zu können.

 

Wie soll Monitoring in Zukunft aussehen?

Host-Inventarisierung: Wir haben viele Hosts, die keine Puppet-Module haben, Puppet ausgeschaltet ist oder eine alte Puppet-Version installiert ist. Wir müssen diese updaten und installieren und das ist teilweise schwierig wegen Solaris.

Benachrichtigungsplan erstellen: Man muss man sich ein Konzept überlegen, über was wann benachrichtigt werden soll. Zum Beispiel wenn ein Server nur tagsüber wichtig ist, braucht man keine Notifications in der Nacht. Dies ist zum Beispiel bei Testmaschinen der Fall, wenn es in der Testumgebung Probleme gibt. Wenn es sich allerdings um eine Produktionsumgebung handelt, möchte man rund um die Uhr benachrichtigt werden.

 

Saeid Hassan-Abadi
Saeid Hassan-Abadi
Junior Consultant

Saeid hat im September 2019 seine Ausbildung zum Fachinformatiker im Bereich Systemintegration gestartet. Der gebürtige Perser hat in seinem Heimatland Iran Wirtschaftsindustrie-Ingenieurwesen studiert. Er arbeitet leidenschaftlich gerne am Computer und eignet sich gerne neues Wissen an. Seine Hobbys sind Musik hören, Sport treiben und mit seinen Freunden Zeit verbringen.

Versteckte Director-Features: Update-Only Sync-Regeln

Heute möchte ich ein neues kleines Feature im Icinga-Director vorstellen: die Möglichkeit, mit Sync-Regeln keine vollständigen Objekte zu verwalten, sondern nur bestimmte Eigenschaften von bestehenden Objekten zu steuern. Das klingt erst mal banal, also wozu das Ganze?

Bereits seit der ersten Director-Version ist es möglich, mehrere Import-Quellen in einer Sync-Regel miteinander zu kombinieren. Allerdings ist das in der Praxis nicht immer ganz so einfach. Spätestens wenn die zweite Quelle nur Zusatzinfos liefern soll, dabei aber mehr Hosts als die erste enthält – dann wird es kompliziert. Viele Import-Quellen lassen sich filtern, da kommt man schon weiter. Und seit einiger Zeit gibt es auch wenn die Quelle das nicht kann die Möglichkeit, via Property-Modifier Zeilen filterbasiert zuzulassen oder abzuweisen.

Der übliche Trick an der Stelle ist dann aber häufig das Anlegen von entsprechenden Datenlisten im Director. Diese befüllt man über dedizierte Sync-Regeln mit Leben und kann sie dann via Map-Modifier am primären Host-Import nutzen. Das funktioniert einwandfrei, ist aber ein wenig umständlich.

Director Sync-Rule - Update-Only

Director Sync-Rule – Update-Only

Beides ist mittlerweile nicht mehr erforderlich. Im aktuellen Master-Branch und in der kommenden Version 1.8 gibt es die Möglichkeit, sogenannte “Update-only” Sync-Regeln anzulegen. Dabei kann man einem beliebigen Objekt-Typ (meist Hosts) eine Reihe von zusätzlichen Eigenschaften aus einer anderen Quelle verpassen, ohne aber zu riskieren dass diese Zweitquelle jetzt ungewollt Hosts hinzufügt oder gar entfernt.

Einfach, aber nützlich. Und das war’s auch schon für heute, wünsche euch ein schönes Wochenende!

Thomas Gelf
Thomas Gelf
Principal Consultant

Der gebürtige Südtiroler Tom arbeitet als Principal Consultant für Systems Management bei NETWAYS und ist in der Regel immer auf Achse: Entweder vor Ort bei Kunden, als Trainer in unseren Schulungen oder privat beim Skifahren in seiner Heimatstadt Bozen. Neben Icinga und Nagios beschäftigt sich Tom vor allem mit Puppet.

Benachrichtigung mal einfach


Neulich beim Kunden, sollte folgendes Szenario zur Benachrichtigung umgesetzt werden. Der Weg, also ob Mail, Slack oder Telegram, soll vom Benutzer abhängig sein, je nach dessen Vorliebe. Ist beim Benutzer eine Mailadresse gesetzt, wird er auch per Mail informiert. Soll die Benachrichtigung hingegen via Telegram bzw. Slack erfolgen, muss der notwendige Empfangs-Hook über ein User-Custom-Attribute angegeben werden.

Wer zu benachrichtigen ist, wird am Host-Objekt angegeben. Die zu benachrichtigen Benutzer können hierbei in einer Liste (host.vars.notification.user) oder über die Mitgliedschaft in einer Gruppe, die ebenfalls am Host in einer Liste (host.vars.notification.groups) angegeben werden, zu gewiesen.

Sei ein Benutzer admin Mitglied der Gruppen icingaadmins und linuxadmins. Soll bei folgendem Host

object Host "localhost" {
  import "generic-host"

  address = "127.0.0.1"

  vars.notifiction = {
    groups = [ "icingaadmins", "linuxadmins", "vips" ]
  }
}

für den Benutzer admin, aber keine doppelten Nachrichten versandt werden, kann dies zunächst mit dieser Regel umgesetzt werden:

apply Notification "mail-admin to Host {
  import "mail-host-notification"
  users = [ "admin" ]

  assign where "admin" in host.vars.notification.users || f("admin", host.vars.notification.groups)
}

Über den ersten Teil der assign-Regel wäre das Vorhandensein von admin in der Liste der zu benachrichtigen Benutzer am Host abgehandelt. Der zweite Teil ist eine selbstdefinierte Funktion die ein true zurück liefert, sofern der Benutzer mindestens einer der Gruppen aus der Liste angehört.

function f(user,groups) {
  if (typeof(groups) == Array) {
    for (grp in groups) {
      if (grp in get_user(user).groups) {
        return true
      }
    }
  }
  return false
}

Nun möchte man nicht für jeden Benutzer am Icinga-System eine solche Notification definieren, zumal die Services noch nicht berücksichtigt sind, dann wären deren für jeden Benutzer, immer gleich zwei Notification-Definitionen. Notifications werden vom Config-Compiler immer nach den User- und Usergroup-Objekten ausgewertet, somit kann die Notification zu ein Notification-for, die eine Schleife über alle bekannten Benutzer führt, umgewandelt bzw. erweitert werden:

apply Notification for (user in get_objects(User)) to Host {
  import "mail-host-notification"
  users = [ user.name ]

  assign where user.name in host.vars.notification.users || f(user.name, host.vars.notification.groups)
  ignore where ! get_user(user.name).email
}

Die abschließende ignore-Klausel stellt sich, dass keine Notification für Benutzer erzeugt wird, die keine Mailadresse angegeben haben. Sollen nun die selben Benutzer, nicht nur für den Host, sondern auch über Probleme bei den zum Host gehörigen Services benachrichtigt werden, ist das ganze nur noch eine Fingerübung:

apply Notification for (user in get_objects(User)) to Service {
  import "mail-service-notification"
  users = [ user.name ]

  assign where user.name in host.vars.notification.users || f(user.name, host.vars.notification.groups)
  ignore where ! get_user(user.name).email
}

Äquivalente Notifications lassen sich damit auch für die alternativen Benachrichtigungswege Slack, Telegram und weitere erstellen.

Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.
Bringing Bulk Editing to a new Level with Icinga DB

Bringing Bulk Editing to a new Level with Icinga DB

Those of you, who already tried out the new Icinga DB Web Module might have noticed a new button next to the search bar in list views.

With Icinga DB we are proud to introduce a powerful new feature for bulk editing multiple objects.

You might be already familiar with the present multiselect feature, which enables you to select multiple list objects by Ctrl(Cmd on Mac)- or Shift-clicking. It enabled you to do bulk actions on multiple objects. This was helpful, but reached its limits – usability and perfomance-wise – when you were intending to deal with a large number of objects.

Continue With Filter goes beyond that and brings bulk editing to a whole new level. Setting downtimes, comments or acknowledgements works now a lot more efficient, because you can apply them to a filtered set of objects.

Setting downtimes to a large number of objects

So, let’s say you want to set downtimes on functional services on a certain host.

1) Create a filter with the filter editor
2) Select all resulting objects by clicking “Continue with filter”
3) You can now execute actions on all of the objects

See it in action

 

For the realisation of this feature we made multiselect urls handle filter parameters. And because it is also more performant, we use it in different places all around the new web module:

* The new badges in the host and service groups view
* The new service widget in the host detail view

You can now reach a new bulk object detail view by passing the filter syntax via the url.

`/icingadb/hosts?([filter syntax])`

It can also be easily added among other parameters, e.g.

`/icingaweb2/icingadb/hosts?state.soft_state=0&([filter syntax])`

To learn more about the new UI Features of the Icinga DB Web module, you can have a look at this post.

Happy bulk editing!

Florian Strohmaier
Florian Strohmaier
Senior UX Designer

Mit seinen Spezialgebieten UI-Konzeption, Prototyping und Frontendentwicklung unterstützt Florian das Dev-Team bei NETWAYS. Trotz seines Design-Backgrounds fühlt er sich auch in der Technik zuhause. Gerade die Kombination aus beidem hat für ihn einen besonderen Reiz.

HP controller firmware issues to check

Just about a week ago I posted a short blog post introducing a new check to verify firmware of SSD disks by HPE. Since our customer informed us about another bulletin he has to take care of, we extended the check to support RAID controllers, and verify if a problematic firmware needs to be patched.

HPE says about the issue in bulletin a00097210:

HPE Smart Array SR Gen10 Controller Firmware Version 2.65 (or later) provided in the Resolution section of this document is required to prevent a potential data inconsistency on select RAID configurations with Smart Array Gen10 Firmware Version 1.98 through 2.62, based on the following scenarios. HPE strongly recommends performing this upgrade at the customer’s earliest opportunity per the “Action Required” in the table located in the Resolution section. Neglecting to perform the recommended resolution could result in potential subsequent errors and potential data inconsistency.

Important: Please read the full document and verify with your used hardware.

For controllers, the check will alert you with a CRITICAL when the firmware is in the affected range with:

  • if you have RAID 1/10/ADM – update immediately!
  • if you have RAID 5/6/50/60 – update immediately!

And it will add a short note when firmware older than affected or firmware has been updated. At the moment the plugin does not verify configured logical drives, but we believe you should update in any case.

Please see the repository and README on GitHub for all details, you can download the binaries from releases.

All information about affected disks can be found on GitHub or the previous blogpost.

OK - All 2 controllers and 33 drives seem fine
[OK] controller (0) model=p816i-a serial=XXX firmware=1.65 - firmware older than affected
[OK] controller (4) model=p408e-p serial=XXX firmware=1.65 - firmware older than affected
[OK] (0.9 ) model=MO003200JWFWR serial=XXX firmware=HPD2 hours=8086
[OK] (0.11) model=EK000400GWEPE serial=XXX firmware=HPG0 hours=8086
[OK] (0.12) model=EK000400GWEPE serial=XXX firmware=HPG0 hours=8086
[OK] (0.14) model=MO003200JWFWR serial=XXX firmware=HPD2 hours=8086
[OK] (4.0 ) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.1 ) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.2 ) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.3 ) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.4 ) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.5 ) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.6 ) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.24) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.25) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.26) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.27) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.28) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.29) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.30) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.31) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.50) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.51) model=MO003200JWFWR serial=XXX firmware=HPD2 hours=7568
...
Markus Frosch
Markus Frosch
Principal Consultant

Markus arbeitet bei NETWAYS als Principal Consultant und unterstützt Kunden bei der Implementierung von Nagios, Icinga und anderen Open Source Systems Management Tools. Neben seiner beruflichen Tätigkeit ist Markus aktiver Mitarbeiter im Debian Projekt.

Das Runde ist das Fleckige

Pandemie. Es sollte wohl so sein,
Jetzt hab ich Zeit und bin daheim.
Blöd gelaufen, doch was mach ich nun?
Ach, es gibt doch immer was zu tun.

Jetzt ist Icinga hier am Start,
Das ging schnell, war nicht hart.
Die Installation ging flott voran,
Doch der Stress fing dann erst an.

Schließlich will ich alles messen
Und dabei auch nichts vergessen.
Dabei war ich ganz beflissen
Um alles überwacht zu wissen.

Ich hab an diesen freien Tagen
Manchen Sensor neu vergraben,
Den halben Garten neu verrohrt
Und manchen Türstock angebohrt.

Kann Kälte und auch Wärme messen,
Weiß wer den ganzen Strom gefressen.
Bewegungsmelder und 'ne Webcam dran:
So seh ich was der Rasenmäher kann.

Mit Gewichtssensor und ein paar Platten
Muss ich jetzt auch nicht mehr raten
Wieviel von diesem schwarzbraunweißen
Zeug die Tauben täglich runter... schmeißen.

Und so meint' ich alles wär bedacht,
Doch wurd ich überrumpelt über Nacht.
Ungeplant war da ein Change passiert
Frech, unverhofft und ungeniert.

Eine Notification gab es nicht,
Keine Webcam hielt was sie verspricht.
Der ganze Garten voll, in jeder Ecke
Ihr glaubt es kaum was ich entdecke.

Das muss wohl dies' Corona sein
Jetzt zieht es auch bei mir hier ein.
Ich flipp gleich aus, das Zeugs ist rund
Sieht aus Eier - doch in bunt!

Thomas Gelf
Thomas Gelf
Principal Consultant

Der gebürtige Südtiroler Tom arbeitet als Principal Consultant für Systems Management bei NETWAYS und ist in der Regel immer auf Achse: Entweder vor Ort bei Kunden, als Trainer in unseren Schulungen oder privat beim Skifahren in seiner Heimatstadt Bozen. Neben Icinga und Nagios beschäftigt sich Tom vor allem mit Puppet.