Tagmonitoring

Icinga2 im Docker Container – Warum oder Warum nicht?

Ich betreue jetzt seit Version 2.7.1 Docker Container, die man sich bei Dockerhub herunterladen kann.

Während ich Anfangs auf alpine als Basis setzte (klein und schlank) musste ich in der Zwischenzeit auf debian schwenken.
Die Paketbetreuer bei alpine waren – für meinen Releasezyklus – etwas zu langsam und in letzter Zeit gibt es größere Probleme mit der libc Implementierung (musl-lib), die bei alpine die Basis bildet.
Immer wieder stürzte der icinga2 Prozess ab und ich konnte dem ganzen nicht mit einem Debbuger beikommen. Dazu gibt es einen entsprechenden Thread im Monitoring Portal so wie einen Bugreport bei alpine.

Aber was unterscheidet jetzt meine Container Implementierung von der anderer (zum Beispiel Christoph Wiechert)?
Ich gebe es zu, ich bediene mich ab un an bei Christoph. Sein Container ist gut, auch wenn er CentOS benutzt. ;)

(Vorsicht, jetzt könnte eine Menge Eigenwerbung folgen! ;) )

Mein Container kann aktuell in zwei verschiedenen Flavours laufen:

  1. als Icinga2 Master
  2. als Icinga2 Satellite

Continue reading

Überwachung von Java-Anwendungen: Speichernutzung, Threads und andere JRE-Metriken

Intro

In diesem Blogpost möchte ich kurz anreissen, wie man die Java Runtime Environment (JRE) überwacht.
Es folgt eine Beschreibung, wie man die Leistung einer Java-Anwendung bewerten kann, in dem man den Speicherverbrauch, die Garbage-Collector-Metriken, die Überwachung von Java-Daemon- und User-Threads und andere grundlegende JRE-Metriken analysiert.

Wenn man an einer großen Java-Anwendung arbeitet, ist es wahrscheinlich, dass etwas irgend wann fehlschlägt, sich schlecht benimmt oder dass man eine (überraschende) OutOfMemoryException bekommt.

Und wenn man Java-Anwendung auch als Containerisierten Microservice einsetzt, kann die Überwachung von Java in Docker und Kubernetes neue und unerwartete Herausforderungen mit sich bringen.

Ich werde (leider) ein einigermaßen verständliches ‚Denglisch‘ benutzen, damit die Begrifflichkeiten erhalten bleiben. ;)

Continue reading

Der Monitoringstack bekommt ein UI …

APIs sind toll, ich mag APIs!
Allerdings sind diese nicht immer „Enduser“ kompatibel.

Ich arbeite bei CoreMedia seit einiger Zeit an (m)einem Monitoringstack um zu zeigen, was in einem produktiv betriebenen CoreMedia System für eine Bereitschaft umgesetzt werden kann (und sollte).
Dabei ist der ganze Stack so aufgebaut, dass er sich seine Informationen selber besorgt und dem entsprechende Grafanagraphen importiert und Systemchecks für Icinga2 anlegt.

Das ganze funktioniert bei uns in einer Jenkins Pipeline völlig automatisiert seit Monaten sehr zufriedenstellend.
Den Stack habe ich bei der letzten OSMC vorgestellt. (siehe den vorherigen Blogpost)
Continue reading

Auslesen und verarbeiten von MBeans

Es gibt viele Möglichkeiten, die Leistung und den Status eines Java Applikations Clusters zu überwachen.
Aus historischen Gründen ist dabei JMX (Java Management Extensions) weit verbreitet.

Um diese Daten auslesen zu können, gibt es verschiedene Tools, die ich einmal kurz vorstellen möchte:

jmx4perl ist ein Befehlszeilenprogramm für einen einfachen Zugriff auf einen Anwendungsserver.
check_jmx4perl ist ein NRPE Plugin für die Überwachung von Java Anwendungen.
jmxdump ist ein Bestandteil der CoreMedia Toolsuite
jolokia ist ein REST Service, der einen erweiterten Zugriff auf die JMX Daten bietet.
jconsole / jmc sind grafische Frontends, welche direkt mit einem oder mehreren JMX Endpunkten verbunden sein können.
j4psh ist ein Frontend zu JMX::Jmx4Perl. Es bietet eine interaktive Shell für den Zugriff auf die JMX MBeans.
Continue reading

monitoringlove #6 – icinga2 – Notifications mit Telegram

Wenn man einen icinga2 Service betreibt, möchte man irgendwann auch erfahren, wenn sich ein Status eines Service ändert.
Über Jahre hin etabliert und auch (in Grenzen) ausfallsicher ist und bleibt eine SMS. Vor allem, weil man damit unabhängig vom Netzzuganges seines ISPs bleibt.
Dafür reicht es, ein altes GSM-Handy mit einer SIM Karte auszurüsten und dieses über einen USB-Anschluss mit dem Monitoring-Host zu verbinden.
Die Softwareseitige Integration sollte dann nicht mehr so kompliziert sein.
Das kann man aber nur machen, wenn man dem Server im eigenen Zugriff hat.
Continue reading

monitoringlove #5 – icinga2 und der LiveStatus

Wenn man ein großes Setup betreut in dem häufig eine neue Software ausgerollt wird, wird es vor kommen, dass man Downtimes dynamisch definieren und ausrollen möchte.
Im Idealfall auch nicht per Hand sondern von außen angetriggert … man ist ja ein wenig faul. ;)

Vor Version 2.4.0 von Icinga2 musste man auf die Nutzung von LiveStatus zurückgreifen, das man ja noch von Nagios kennen sollte.

(Wie man den LiveStatus über puppet aktiviert hatte ich bereits in einem vorherigen Blogpost beschrieben)

Mit dem LiveStatus ist man allerdings auf ein Set festgelegter Kommandos beschränkt. Und hierbei ist beschränkt auch ernst zu nehmen.

Für das herumprobieren kann man sich die folgende Beispiele ansehen und damit herumprobieren. Continue reading

monitoringlove #3 – icinga2 checks mit puppet (update)

Aufbauend auf dem vorherigen Teil, möchte ich hier beschreiben, wie man Host- und Servicechecks über puppet definiert und ausrollt.

Das zusammenführen von Host- und Servicechecks ist mittels apply Regel in icinga2 geradezu kinderleicht geworden.
Da haben sich die Jungs echt was tolles ausgedacht!

Aber genug des Smalltalks!
Continue reading

monitoringlove #2 – icinga2 mit puppet (update)

Wenn man sich – so wie ich – mit einer Großzahl an zu überwachenden Servern beschäftigt, macht man sich ziemlich schnell Gedanken darüber, wie man das ganze einfach, schnell und nachvollziehbar etabliert.
Ich begann in einem früheren Post bereits über meine Erfahrungen zu schreiben und möchte hiermit fortfahren.

Diesmal geht es um die Grundinstallation des icinga2-Core mittels puppet.
Hilfreich sind dabei Grundkenntnisse in puppet, der Konfiguration und dem logischen Aufbau von hiera.
Des weiteren nutzen wir ein Ruby Feature namens deep_merge. Das müsste ggf. noch mittels gem install deep_merge / emerge dev-ruby/deep_merge installiert werden.
Ich gehe bewusst nicht auf die von mir genutzte hiera-Struktur ein, da jeder seinen eigenen Weg verfolgt.
So bald ich das ganze hier aber herunter geschrieben habe, werde ich eine lauffähige Konfiguration in meinem github Account packen. Versprochen! ;)

Continue reading

monitoringlove #1 – java Applikationen (update)

Okay, der Artikel greift massiv vorweg, ist aber schneller zusammen geschrieben! :)

Ich möchte hier die unterschiedlichen Möglichkeiten des Monitorings von Applikationen beschreiben.

Wobei mein Schwerpunkt auf Tomcat und Java liegen wird.

Das ganze habe ich auch in ein (spezialisiertes) puppet-Modul einfließen lassen, was man sich bei github ansehen und forken kann. Über Pull-Request oder Anregen freue ich mich natürlich ebenso!

Continue reading

Monitoringlove

Ich beschäftige mich – arbeitsbedingt – seit einigen Jahren mit Monitoringsystemen.
Begonnen hat alles mit etwas selbstgebauten, welches ich damals sinnvollerweise gegen nagios tauschte.
Es folgten munin, ging später weiter mit icinga, welches vor einiger Zeit gegen Icinga2 ausgewechselt wurde.
Und das gute alte munin – über all die Jahre schon etwas angestaubt – wird aktuell gegen Graphite ausgetauscht.

In der Regel übernehmen Systeme wie Nagios / Icinga auch noch eine Alarmierung, wenn eine 24/7 Bereitschaft darauf angewiesen ist.
(Bei meinem aktuellen Arbeitgeber übernimmt das noch immer ein handgeschriebenes Tool, welches direkt aus der Hölle zu kommen scheint)
Nagios / Icinga haben die Möglichkeit zwischen weichen und harten Fehlern zu unterscheiden und entsprechende Abhängigkeiten zwischen Ausfällen von Services oder Host abzubilden … Was will man mehr?

Neben den üblichen Standards – Systemparameter wie Auslastung von CPU, Speicher, Festplatten – kommen logischwerweise noch die Applikationsparameter hinzu.
Continue reading