Seite wählen

NETWAYS Blog

Wie man ein Icinga Plugin nicht schreiben sollte

(this is a cross-post with my private blog, you will find there the English version of this post)
oder: Frameworking falsch gemacht
Ich bin diese Woche bei einem Kunden auf etwas interessantes gestoßen. Einige Plugins für Icinga verursachten enorme CPU Last, sobald ein paar Checks gleichzeitig gestartet sind waren beide CPUs der VM auf 80-90%.
Als ich mir die Plugins angeschaut habe fand ich seltsamen PHP Code, sah ungefähr so aus:

<?php
require_once('phplib/Framework.php');
if(!FRAMEWORK_LOADED) Framework::initialize();
CheckLicenseManager::run();

So auf den ersten Blick wirkt es ja nicht mal schlecht, da wird halt ein Framework geladen, dass die jeweiligen Klassen bereitstellt und dann wird die jeweilige Klasse „ausführt“. Das Framework selbst bestand aus mehreren PEAR Klassen und selbst geschriebenen Klassen die die jeweiligen Checks implementieren.
Das faszinierende an der Geschichte war jedoch dass das Plugin knapp 6 Sekunden dafür gebraucht hat die „–help“ Ausgabe zu liefern, die eigentliche Funktion des Plugins ist in unter einer Sekunde fertig.
Ein strace des Skripts brachte dann das Problem recht schnell ans Tageslicht: das Framework tut nichts anderes als per PHP-Autoloadfunktion sämtliche PHP Dateien und Klassen im Verzeichnis zu laden, was ca. 90 Stück waren.
Ich erklärte dem Kunden das Problem, und dass ich wohl keine direkte Lösung anbieten könnte, außer eben die paar Plugins neu zu schreiben. Das machte ich dann auch und dem Server war wieder langweilig.
Ein paar Regeln für Icinga Plugins (die ich für mich gesetzt habe):

  • Keep it simple ™
  • Ordentlich kommentieren
  • eine verständliche –help Ausgabe mit Beispielen
  • bei komplexen Plugins: Verbose und Debug Funktionen für spätere Probleme und Tests
  • Möglichst in Perl oder Shell schreiben um weniger Abhängigkeitsprobleme zu haben
  • und last but not least:
    Wenn möglich veröffentlichen, denn dafür gibt’s monitoringexchange.org, denn irgendjemand kann es sicher auch gebrauchen!  😉

Weekly Snap: UNetbootin, Python Futures, AKCP sensors & Check_Interfaces

16 – 20 April got into the spring mood with ideas for data centers, live USB drives, and check plugin updates.
Starting with tips, Thilo recommended UNetbootin for no-fuss live USB drives, and Gunnar played with the “futures” feature in Python 3.2.
Georg got ready for warmer temperatures reviewing AKCP environment sensors for data centers, while Lennart announced version 1.2 of the check_interfaces plugin with two new features, ready for download on www.netways.org.
To end the week, Eva offered last minute tickets to our Open Source Data Center Conference that sold out just two days later. We look forward to seeing you for the kick off on Wednesday!

Weekly Snap: Averting Java Plugins, Playing with HTML 5 & Hooks

30 Jan – 3 Feb turned over a new month with expo reflections, an OSDC program, and a nifty Java idea for Icinga/Nagios plugins – all topped off with our 100th development blog post.
Bernd brought home a few impressions from his visit to the Cloud Expo Europe in London and Lennart found a way around writing Java plugins for Icinga / Nagios.
From the development team, Angsar toyed with the idea of programming games in HTML5 while Marius showed how to add hooks in Perl to make patching vendor code a little easier.
Pamela closed the Open Source Data Center conference Call for Papers, and announced the preliminary program of speakers. She also reminded early birds to get in before  15 February for special conference rates.

Switch monitoring via SNMP

Chances are you will at some point need to monitor a switch, and the Nagios community offers many plugins to do this.
Because no two setups are exactly the same, there are two interface checks actively maintained by NETWAYS which are designed for very different environments.
The first plugin was designed for monitoring large numbers of switches over low-bandwidth links, and is optimized for minimal system load.
check_interfaces (www.netways.org/projects/check-interfaces)

* very fast c-based plugin
* uses bulk get mode to reduce traffic
* runs on embedded appliances
* no external status files required
* SNMP v1, 2c and 3 supported
* 10GB port support
* fully integrated into Nagios 3 / Icinga
* 64 bit counter support
* Interface aliases
* Human-readable bandwidth measurement
* PNP compatible output

The second plugin is orientated towards large switches, and offers a graphical overview of the switch status.
check_interface_table_v2 (www.netways.org/projects/plugins/files)

* adapted from check_interface_table from ITdesign
* Perl-based plugin
* Separate colour HTML overview
* Monitor switch ports for changes
* VLAN support
* 64 bit counter support
* Interface aliases
* Human-readable bandwidth measurement
* PNP compatible output
Both are naturally GPL-Licensed and available for download from the usual places.

Christ Elektronik Stromleiste CLM5-IP: Neues Plugin

Christ Elektronik Stromleiste CLM5-IPFür die Stromleiste CLM5-IP von Christ Elektronik konnte ich heute ein passendes Nagios/Icinga-Plugin freigeben. Neben dem aktuellen Stromverbrauch der gewünschten Outlets lassen sich auch angeschlossene Temperatur-Sensoren oder sonstige analoge sowie digitale Sensoren abfragen – die jeweiligen Schwellwerte sind frei definierbar. Zudem werden jeweils Performance-Daten zur Erstellung von Trendgrafiken mit ausgegeben.
Das Plugin kann wie üblich unter www.netways.org heruntergeladen werden.

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.