The [Prometheus] monitoring tool follows a white-box monitoring approach: Applications actively provide metrics about their internal state, and the Prometheus server pulls these metrics from the applications using HTTP.

If you can modify the application’s source code, it is straightforward to instrument an application with Prometheus metrics: Add the Prometheus client library as a dependency, call that library to maintain the metrics, and use the library to expose the metrics via HTTP.

However, DevOps teams do not always have the option to modify the source code of the applications they are running.

At this year’s [JavaZone] conference, Fabian Stäber did a [talk] on how to instrument Java Web Applications with Prometheus metrics without modifying the application’s source code.

more...

It’s about time for a new Sakuli release! Our latest release v1.2.0 is the first version to include a beta of Sakuli-UI, a web UI to help you develop and manage your tests.

The new release also brings a bunch of enhancements and bug-fixes, a detailed changelog is included in this post.

Once again, we want to say THANK YOU for the great support of our contributors, our valued supporting companies and of course ConSol!

more...

At this year’s [FOSDEM] conference I did a 30 minutes presentation on [Monitoring Legacy Java Applications with Prometheus]. The talk gives an overview of some of the options you have for monitoring Java applications with [Prometheus] when you cannot modify the application’s source code:

• Logfile monitoring ([grok_exporter]), and how it differs from [Elastic stack]
• Blackbox monitoring ([blackbox_exporter])
• JMX ([jmx_exporter])
• Write your own Java agent ([promagent.io])

The video is available below.

more...

In diesem Blogartikel wird gezeigt, wie das Monitoring-Plugin check_nwc_health auf eigene Bedürfnisse angepasst bzw. erweitert werden kann.

Ursprünglich sollte nur die Logik des Modes ha-role modifiziert werden, um den Status von Cluster-Nodes nur zu reporten, anstatt zu alarmieren. Heraus kam eine Statusanzeige im Thruk-Frontend auf Basis von Host-Macros…

more...

Just in time before X-Mas holidays starts, we crate a huge release of our open source end-to-end testing framework Sakuli. The v1.1.0 release brings a bunch of new features and a brand new documentation with. The list of the current changes you will find bellow. Also we created a Short Overview Presentation so that you be able to get quick intro about what purpose of Sakuli is.

Also we wan’t to say a big THANK YOU for the great support of our contributors, our valued supporting companies and at least ConSol for making this possible as open source software. Double Thumbs up!!!

more...

The Tutorial “Docker based E2E application monitoring with Xfce UI and OMD Labs” describes how to:

• Implement a complete containerized end-to-end monitoring environment
• Testing HTML content
• Testing native UI content
• Setting up a monitoring with OMD Labs:
  • Grafana graphs about the performance times (end user perspective)
  • Alerts on errors with screenshots
• Continuous execution of the test suite in a loop

Sources: see github.com/ConSol/sakuli-examples

more...

The [Prometheus] monitoring tool follows a white-box monitoring approach: Applications actively provide metrics about their internal state to the Prometheus server. In order to instrument an application with Prometheus metrics, you have to add a metrics library and call that library in the application’s source code. However, DevOps teams do not always have the option to modify the source code of the applications they are running.

At this year’s [Devoxx] conference, Fabian Stäber did a [talk] on how to instrument Java Web Applications with Prometheus metrics without modifying the application’s source code.

more...

Which programming language should we use to write monitoring check_plugins? This question rose some discussion and this post is trying to give some hints.

more...

Have you ever written a NEB (Nagios Event Broker) module? This article will explain a tool which makes this a lot easier, especially if the reason was that you are not familiar with C or C++. In this case the “Go NEB Wrapper” could come very handy and if you are new to this topic it is a good point to start with.

more...

The Prometheus monitoring tool follows a white-box monitoring approach: Applications actively provide metrics about their internal state to the Prometheus server. In order to instrument an application with Prometheus metrics, you have to add a metrics library and use that library in the application’s source code. However, DevOps teams do not always have the option to modify the source code of the applications they are running.

Promagent is a Java agent using Bytecode manipulation for instrumenting Java Web applications without modifying their source code. Promagent allows you to get white-box metrics for Java Web applications even if these applications do not implement any metrics library out-of-the-box.

more...

Mit steigender Zahl der im [Ansible]-Inventory gepflegten Hosts verlängert sich die Laufzeit eines Playbooks. Ansible erkennt zwar, welche Tasks nicht ausgeführt müssen (z.B. weil bestimmte Pakete bereits installiert sind), jedoch kostet auch diese Überprüfung Zeit. Früher oder später wird man deshalb den Playbook-Parameter --limit|-l einsetzen - und sich wundern, warum Teile des Playbooks plötzlich nicht mehr funktionieren. Dieser Blogpost zeigt, in welche Probleme man laufen kann bzw. wie man sie vermeidet und löst.

more...

Ansible meets DokuWiki

Dokumentation belegt in der Rangliste der beliebtesten Arbeiten eines Administrators sicher einen der hinteren Plätze. Neben der Beliebtheit der Aufgabe ist es auch mit zunehmender Anzahl der vorhandenen Systeme immer aufwändiger, die Dokumentation auf einem aktuellen Stand zu halten. Ein klassischer Fall also für Automatisierung.

Das Ziel in diesem Blog soll es sein, für jedes System eine DokuWiki Seite automatisch zu erzeugen. Weiter soll auf jeder Seite noch die Möglichkeit bestehen, individuelle Dokumentation mit einzufügen.

more...

[Prometheus] ist ein quelloffenes Monitoring- und Alarmierungs-Werkzeug. Seine Basis bildet eine Zeitreihen-Datenbank, auf deren Daten mit einer eingebauten, sehr mächtigen Abfragesprache zugegriffen werden kann.

Prometheus verfolgt den Ansatze des sogenannten “whitebox-monitoring”. Anwendungen stellen hier entweder nativ Metriken zur Verfügung, oder alternativ macht ein “[exporter]” Applikations- oder Geräte-Metriken für Prometheus abfragbar.

In diesem Artikel möchte ich zeigen, wie man mit Hilfe des [fritzbox_exporter] und des [speedtest_exporter] im Zusammenspiel mit [Grafana] Einblicke in die Performance seines Heimnetzwerks und seines Internetanschlusses bekommen kann. Die Hardware-Basis für dieses Projekt stellt ein RaspberryPi.

more...

Version 6.0 von [check_nwc_health] ist erschienen und hat neben Aufräumarbeiten unter der Haube ein paar neue Features zu bieten:

• interface-etherstats
• F5 Wide IPs
• Juniper VSD Memberstatus
• interface-stack-status

more...

SNMP-Traps und Nagios ist eins der Themen, um das man bislang gerne einen großen Bogen gemacht hat. Grundsätzlich gibt es seit etlichen Jahren die AddOns SNMPTT und Nagtrap, deren Konfiguration aber ein wenig mühsam ist. In einem Projekt, bei dem es um die Überwachung von mehreren Tausend Storage-Systemen ging, entstand eine Methode, welche ressourcenschonend und einfach automatisierbar ist.
Im ersten Teil dieses Artikels geht es um die entsprechende Vorbereitung eines OMD-Servers. Genauer gesagt darum, wie man dafür sorgt, daß ein eingehender Trap gleichzeitig an mehrere OMD-Sites (Test, Produktion, …) zugestellt wird.

more...

Kurz vor Ende des Jahres sind die Vortragsvideos der OSMC 2016 online verfügbar. Auch dieses Jahr war ich wieder Referent, diesmal mit einem Überblick über die letzten Entwicklungen von OMD, einige Umgebungen, in denen es eingesetzt wird und dem Ausblick auf das, was nach 2016 in die Distribution einfließen könnte.
Dauer des Videos: 60min.

OMD, die Open Monitoring Distribution, bildet heute in vielen Unternehmen das Rückgrat bei der Überwachung unterschiedlichster IT-Komponenten und Services. Für Anfänger ist OMD ein umfassendes Starterpaket, für Consultants eine solide Plattform für individuelle Monitoring-Landschaften. Seit dem Gründungsjahr 2010 wurde OMD kontinuierlich verbessert, mit der OMD-Labs-Edition wurden 2015 moderne Elemente wie InfluxDB und Grafana eingeführt. Das Thema Automatisierung wurde mittlerweile mit Ansible und Coshsh ebenso aufgegriffen. Der Wandel der IT-Welt in Richtung cloud-basierter Services und kurzlebigen Containern stellt eine besondere Herausforderung dar. Der Vortrag zeigt, wie OMD sich dieser in Zukunft stellen wird.

Kürzlich wurden zwei Schwachstellen von Nagios veröffentlicht, u.a. bei heise.de. Wir verwenden Nagios als einen von mehreren möglichen Cores innerhalb des Monitoring-Frameworks OMD. Eine Gefährdung liegt nicht vor. Bei besagten Schwachstellen handelt es sich um:

• CVE-2016-9565 - Betroffen ist das Web-Frontend von Nagios. Dieses zeigt nach dem Login einen RSS-Feed des Herstellers Nagios Enterprises an, dessen Inhalt so manipuliert werden kann, daß eingeschleuste Befehle im Kontext des www-data/nagios-Benutzers ausgeführt werden können. De Angreifer muss sich dazu jedoch als www.nagios.org ausgeben (durch einen DNS-Angriff) oder den Datenstrom als Man-in-the-Middle manipulieren. Abgesehen davon, daß die original Web-Gui von Nagios seit Erscheinen weitaus modernerer Oberflächen wie Thruk sowieso niemand mehr ernsthaft benutzt - die RSS-Funktionalität wurde bei OMD von Anfang an abgeschaltet bzw. rausgepatcht. Sie existiert schlichtweg nicht mehr und somit auch nicht die Schwachstelle.

• CVE-2016-9566 - Bei diesem Exploit wird ausgenutzt, daß Nagios, so denn der Prozeß unter dem root-Account gestartet wird, das Logfile /usr/local/nagios/var/nagios.log o.ä. zunächst mit den entsprechenden root-Privilegien öffnet, bevor diese mittels des Systemcalls setgid(pid des nagios-Benutzers) aufgegeben werden. Ein Angreifer mit Zugang zum Monitoring-Server, welcher die Möglichkeit hat, das Logfile durch einen Symlink zu systemkritischen Dateien wie z.b. /etc/ld.so.preload zu ersetzen, kann die Voraussetzungen zur deren Manipulation schaffen. Dazu muss er noch dafür sorgen, daß Nagios schadhaften Inhalt in die Datei schreibt. Eine Möglichkeit wäre, ein externes Kommando (entsprechend präpariert) in die Command-Pipe zu schicken, was einen Eintrag im Logfile (und somit in /etc/ls.so.preload) zur Folge hat. Auch diese Form des Angriffs ist unter OMD ausgeschlossen, da ein Nagios-Prozess zu keinem Zeitpunkt mit root-Privilegien läuft. Monitoring mit OMD spielt sich ausschließlich im Kontext stinknormaler Benutzer ab.

Ergo: alles OK und grün.

For FOSDEM 2017, there are two DevRooms where ConSol employees are among the organizers.

• Monitoring and Cloud Devroom
• Containers and Microservices Devroom

Accordingly, the two devrooms have combined CfPs, so that you can submit your container cloud talk in just one place. These devrooms are interested in talks about:

• Monitoring containerized services
• Automating cloud deployments
• Developing and administering microservices
• Container orchestration
• Continuous Integration & Deployment
• Prometheus, Kubernetes, Docker, CRIO, etc.
• New projects and technology
• Other container and cloud native talks

Submit Talk Proposals by November 26th on our CfP Page:

https://goo.gl/forms/bbfCH14ido5kMD4H3

[Prometheus] is an open source monitoring tool, which is conceptually based on Google’s internal Borgmon monitoring system. Unlike traditional tools like Nagios, Prometheus implements a white-box monitoring approach: Applications actively provide metrics, these metrics are stored in a time-series database, the time-series data is used as a source for generating alerts. Prometheus comes with a powerful query language allowing for statistical evaluation of metrics.

more...

Sakuli wird für EndToEnd mit Linux und Windows Applikationen bereits vielfach eingesetzt. Wie sieht es aber mit Android, dem verbreitetsten mobilen Betriebssystem, aus? Hierzu ein Beispiel.

more...

Wenn man einen Dienst überwachen möchte und man diesen nicht selbst betreut, fehlt meist die Erfahrung, wie sich dieser verhalten sollte und was als „normal“ gilt. Im Folgenden wird beschrieben, wie man (Un)Regelmäßigkeiten automatisch erkennen lassen kann.

more...

Oft kommt die Frage auf ob man mit den Performancedaten, die von Nagios und ähnlichen System erhoben werden, nicht auch Vorhersagen treffen kann, etwa wie sich die Systeme in den nächsten Tagen und Wochen entwickeln. Aus diesem Grund wird im Folgenden vorgestellt, wie man dies erreichen kann.

more...

Kiel, 24 Grad, 50 Mann an Bord. Bei unerwartet schönstem Sommerwetter wurde in der Kieler Fachhochschule am 7. und 8. September der elfte Workshop der Monitoring-Community veranstaltet. Das ConSol-Monitoringteam trug mit acht Vorträgen zum Gelingen der Veranstaltung bei. Eine kurze Zusammenfassung:

Bereits mit dem erstem Vortrag nach der Begrüßung, “E2E-Monitoring mit Sakuli”, sorgte Simon Meggle für einen würdigen und technisch anspruchsvollen Auftakt der Veranstaltung. Die Möglichkeit, Sakuli in Docker-Containern einzusetzen und End-to-End-Tests somit praktisch beliebig zu parallelisieren, sorgte für viel Gesprächsstoff.

Damit es jeder zu Hause nachmachen kann, führte Simon dann am zweiten Tag die Teilnehmer in einer Live-Demo durch sein Tutorial “Sakuli-Tests im Docker-Container”.

more...

[PromCon 2016] was the first conference around the [Prometheus] monitoring system. It took place from August 25 - 26 2016 at Google Berlin as a single-track event with space for 80 attendants.

We took the opportunity and did a lightning talk introducing [grok_exporter], which is a tool for extracting Prometheus metrics from application logs.

more...

Counting the number of error messages in log files and providing the counters to [Prometheus] is one of the main uses of [grok_exporter], a tool that we introduced in the [previous post].

The counters are collected by the [Prometheus] server, and are evaluated using Prometheus’ query language. The query results can be visualized in [Grafana] dashboards, and they are the basis for defining [alerts].

We found that evaluating error counters in Prometheus has some unexpected pitfalls, especially because Prometheus’ [increase()] function is somewhat counterintuitive for that purpose. This post describes our lessons learned when using [increase()] for evaluating error counters in Prometheus.

more...

Am 27.7. fand bei ConSol das Sommer-Meetup der Gruppe “Münchner Monitoring-Stammtisch” statt. Das Thema war diesmal “Ansible im Monitoring-Umfeld”.
Ansible ist ein Framework, mit dem üblicherweise Server nach der Grundinstallation nachkonfiguriert und mit ausgewählten Softwarepaketen versorgt werden. Oder mit dem im laufenden Betrieb immer wieder Patches und sonstige Updates ausgerollt werden. Dabei wird in einem sogenannten Ansible-Playbook lediglich der Soll-Zustand beschrieben und Ansible kümmert sich im Hintergrund um die dazu nötigen Aktionen. Das hat grundsätzlich noch nichts mit Monitoring zu tun, aber da wir über den Tellerrand hinausschauen und bei allen Kunden keine Insel installieren, sondern Teil einer Unternehmens-IT mit allen möglichen Verflechtungen sind, gehört Ansible seit längerem zum Werkzeugkasten des ConSol-Monitoring-Teams. Es gibt übrigens auch eine eigene Ansible-Meetup-Gruppe, die unsere Veranstaltung freundlicherweise auch auf ihrer Seite ankündigte.
Die Fachsimpelei bei Augustiner und Pizza wurde immer wieder durch einen Vortrag unterbrochen, als da waren:

• Michael Kraus - Überblick über Ansible, erste Schritte, coole Features
• Simon Meggle - Rollout und Administration einer verteilten Monitoring-Umgebung mit Ansible
• Matthias Gallinger - Erstinstallation und kontinuierliche Betankung von Monitoring-Clients mit Plugins

more...

[Prometheus] is an open-source systems monitoring and alerting toolkit. At its core, Prometheus uses time-series data, and provides a powerful query language to analyze that data. Most Prometheus deployments integrate [Grafana] dashboards and an [alert manager].

Prometheus is mainly intended for white box monitoring: Applications either provide Prometheus metrics natively, or they are instrumented with an [exporter] to make application-specific metrics available.

For some applications, parsing log files is the only way to acquire metrics. The [grok_exporter] is a generic Prometheus exporter extracting metrics from arbitrary unstructured log data.

This post shows how to use [grok_exporter] to extract metrics from log files and make them available to the Prometheus monitoring toolkit.

more...