Asynchrone Kommunikation im Web: Eine kleine Übersicht

Während das Web in den meisten Fällen mit dem klassischen Request-Response Modell funktioniert, benötigen heutzutage immer mehr Applikationen (spätestens wenn es um Kollaboration geht) die Möglichkeit, vom Server unaufgefordert Informationen zu bekommen. Mittlerweile gibt es dafür einen Wulst voller Bibliotheken und Schnittstellen.
Mein heutiger Blogpost soll gar nicht genau auf eine (oder alle) der Technologien vorstellen, sondern nur eine kurze Übersicht und Anregung geben, wenn man mal auf der Suche ist:

  • HTTP Polling oder lange blockierende HTTP Requests (Comet): Diese gehen immer und brauchen auch keine spezielle Bibliothek. Man stellt entweder sehr oft Anfragen und der Server sagt dann schon wenn etwas passiert, ansonsten nichts (Polling eben) oder der Server blockiert bis etwas passiert und sendet in diesem Falle die Antwort für den Request. Blockiert allerdings in älteren Browsern immer eine der häufig benötigten Verbindungen und ist (egal in welcher Variant) nur noch als Fallback für ältere Browser geeignet (Comet). Davon gibt es viele Varianten, im IFrame oder um Streaming zu ermöglichen, letzten Endes ists aber immer eine Krücke. Da das keine ‘offizielle Technik’, sondern eher ein Hack ist gibts als weiterführende Literatur nur die Wikipedia Seite.
  • Websockets: Ein eigenes Protokol das eigens für persistente bidirectionale Kommunikation mit dem Server gedacht ist. Läuft auch auf vielen Mobilgeräten und kann für ältere Browser (wenn man den Technologiebruch verkraften kann) über ein Flash Fallback wie websocket-as nachgerüstet werden. Bei Websockets läuft die Kommunikation über einen anderen Port als 80, daher kann eine restriktive Firewall hier den Spaß verderben. Die exzellente Mozilla Developer Network Seite weist den Weg, ein Blick in den Standard kann aber auch nicht schaden. Größter Nachteil: Der mangelnde Browsersupport und die z.T. auf Drafts aufbauende Implementierung in älteren Browsern.
  • Server-Sent Events: Eine W3C Recommendation, die es einem Server erlaubt, Events über einen offenen Kanal an Clients (!= Internet Explorer) zu senden. Das Protokoll ist extrem einfach und kommt mit HTTP Bordmitteln aus, im Gegensatz zu Websockets kann der Server aber über den gleichen Kanal keine Events empfangen (dafür muss man dann wieder neue Requests senden). Einen Vorteil gegenüber Websockets sehe ich darin, dass die Kommunikation über den HTTP Port geschieht, ich würde im Zweifel jedoch eher auf Websockets setzen. Die sind mittlerweile ein Standard und haben heute schon besseren Browsersupport. Die W3C Recommendation fängt mit guten Beispielen an, und Mozilla hat ein Beispiel in PHP.

Es gibt hiervon noch einige Varianten, bei der Auswahl einer Technologie muss man sich aber für Performance vs. Kompatibilität entscheiden. Meine klare Empfehlung ist daher, eine Bibliothek wie SockJS zu verwenden. Diese wählt für die aktuelle Platform das effizienteste Protokoll heraus und abstrahiert dessen Verwendung für den Nutzer. Durch die große Auswahl an Adaptern für verschiedene serverseitige Technologien ist es damit kinderleicht, asynchrone Nachrichten zwischen Browser und Server auszutauschen.
Ich hoffe zwar in Zukunft direkt mit Websockets arbeiten zu können, allerdings wird es wohl noch eine Weile dauern bis der Internet Explorer 10 in jeder Firma angekommen ist.

Chrome Devtools: CSS Helfer

Wer kennt das nicht: Man baut ein wenig an einer HTML Seite/Webanwendung (wohlmöglich einer, die man nicht selbst entwickelt hat) herum und möchte das Styling eines Elementes anpassen. Doch egal was man macht und wie laut man brüllt: Der Browser übernimmt die Änderungen einfach nicht. Grund sind meist irgendwelche zusätzliche CSS Regeln die die eigenen Überscheiben, oder sonstiger CSS Voodoo der (scheinbar) keinen Sinn ergibt.
Oft rutscht man dabei in ein iteratives Try & Error Prinzip:

  1. CSS Anpassen
  2. Seite neu aufrufen
  3. Fluchen
  4. CSS Anpassen

Spätestens ab Punkt 4. sollte man merken, dass hier etwas Ineffizient ist. Tools wie die eingebaute Entwicklerkonsole im Chrome können hier den totalen Nervenzusammenbruch (ungefähr bei der zehnten Iteration) verhindern. Natürlich gibt es ähnliche Features auch für die anderen Browser. Die Chrome Entwicklertools sind meiner Meinung nach nur am umfangreichsten und effizientesten, darum gehe ich hier nicht auf andere Tools ein.
Ruft man die Tools auf (Ctrl-Shift-i,  Cmd-Shift-I (Mac) oder Tools->Developer tools) und geht in den Elements Dialog, begrüßt einen folgendes Fenster (hier habe ich eine Seite des W3C CSS Tutorials aufgerufen) :

Chrome developer tools

Developer tools


Während die linke Seite den aktuell gerenderten DOM Baum anzeigt (also mit dynamisch hinzugefügten/geänderten Elementen) gibt die rechte Spalte Auskunft über das aktuelle ausgewählte Element (CSS Regeln, Maße, Eventlistener, etc).
Das 'Computed style' Feld zeigt alle Regeln, die angewendet werden

Das ‘Computed style’ Feld zeigt alle Regeln, die angewendet werden


Interessant für die CSS-Fehlersuche sind eigentlich nur die ersten drei Sektionen :

  • Computed Style gibt an, welche Regeln für dieses Element letztenendes wirklich angewendet werden, also in das Rendering einfliessen
  • Style gibt an, welche Regeln im ‘style=’ Attribut des Objektes hinterlegt sind
  • Matched CSS Rules zeigt alle CSS-Regeln und deren Quelldateien an, die für den aktuellen Knoten gelten. Dabei ist die Reihenfolge gleich der CSS Hierarchie, d.h.
    weiter oben liegende Regeln unterschreiben die generischen Regeln aus der Ebene darunter (Ausnahme: Regeln mit !important)

Sollte etwas nicht gehen muss der Blick zuerst auf die Computed Style Sektion gehen: Ist meine Regel hier vorhanden?
Wenn ja sollte die Regel überprüft werden: Passt das CSS auf das angegebene Element? Gibt es spezielle Bedingungen für die Regel? Passt der Kontext (z.B. bei Problemen mit float, hier müssen auch andere Knoten berücksichtigt werden).
Wenn die Regel nicht im Computed Style steht, kann man in dem Matched CSS Rules Feld hoffentlich sehen warum das so ist:

Kein tingting.mp3 für mich - nicht unterstützte Regeln zeigt Chrome netterweise an

Kein tingting.mp3 für mich – nicht unterstützte Regeln zeigt Chrome netterweise an

  • Erscheint die Regel nicht ist das CSS schlicht und ergreifend nicht korrekt (ist das CSS geladen? Passt die CSS Query auf den Knoten?)
  • Erscheint die Regel, jedoch durchgestrichen, lohnt sich ein Blick auf das gelbe Ausrufezeichen: Dann ist die Regel entweder invalide (hat z.b. einen Tippfehler) oder wird nicht unterstützt.
  • Ist die Regel vorhanden, aber der Wert im Computed Style ein anderer, sollte man schauen ob die Regel irgendwo überschrieben wird: Gibt es Regeln die über der eigenen liegen? Ist die Regel mit !important definiert?

Zum Experimentieren ausserdem sehr nett: Click man auf eine Regel kann man neue Attribute hinzufügen oder bestehende Attribute verändern. Chrome greift einem mit den Eigenschaften und Werten ein wenig unter die Arme. Kleinere CSS Experimente oder Wertänderungen kann man so direkt im Browser ausprobieren.
Man darf aber nicht vergessen dass einem die Tools nur helfen können Fehler zu finden – ein Blick in die Doku sollte bei Problemen immer als erstes Erfolgen. Wer nicht weiß, was sein CSS bewirkt wird auch mit den besten Tools nicht weit kommen (spätestens wenn ein anderer Browser das Dokument anders rendert).

Webprogrammierung: Welche Architektur ist die richtige für mich?

Die Messlatte von Webanwendungen und Webseiten hat sich in den letzten 10 Jahren stark erhöht, was nicht zuletzt dem erhöhten Einsatz von clientseitiger Logik geschuldet ist.
Daraus zu interpretieren JavaScript, Dynamik und Eyecandy hat alles besser gemacht ist allerdings ein falscher Schluss: Über die Funktionalität und Qualität will ich hier keine Aussage machen – es gab auch früher und gibt heute noch sehr viele statische Site-per-Site Anwendungen an denen sich neue Tools eine Scheibe abschneiden können.
Was aber auf der Hand liegt: Wer heute eine erfolgreiche Webanwendung entwickeln will muss sich mit dem Desktop messen (z.T. ist das heute auch schon umgekehrt so). Ein ‘das ist halt im Browser, das geht nicht anders’ frisst heute niemand mehr als Ausrede wenn sich eine Anwendung nicht so anfühlt wie erwartet. Und gleichzeitig ist man als Entwickler wie ein Kind im Süßigkeitenladen: Überall gibt es feine Sachen, will man aber alles auf einmal naschen wird man sich früher oder später übergeben.
Und damit wäre dieser epische Prolog auch schon am Knackpunkt: Wie entscheide ich mich für das ‘richtige’ Architekturmodell für meine Webanwendung? (mehr …)

Web Notifications – bald für (fast) alle

Screen Shot 2013-06-13 at 10.18.20 AM
Zugegeben, Web Notifications sind an sich ein etwas alter Hut – Google Chrome kann das schon lange und wer das Webinterface von GMail nutzt, kennt sicher auch die ‘Notify me about incoming mails’ Funktion. Dennoch habe ich mich bisher immer zurückgehalten einen Blogpost darüber zu schreiben, denn lange Zeit war das eine WebKit (und z.T. Chrome) Insellösung mit dem ‘webkit’ Prefix und ohne w3c Standard.
Web Notifications sind an sich nichts besonderes: Man erlaubt einer Webanwendung einfach, eine Notification am Desktop anzuzeigen, auch wenn der Browser gerade nicht aktiv ist. Google Mail ist da wohl auch gleich eines der logischen Beispiele: Wenn eine neue Mail kommt, will man darüber informiert werden, aber nicht andauernd auf das Fenster schauen.
(mehr …)

Release: EDBC 0.1.0beta & EventDB 2.0.5beta

Unsere EventDB gehört ja mittlerweile bei vielen Monitoringsystemen zur Grundausstattung sobald Syslog oder SNMP Traps ins Spiel kommen. Oft kam hier die Frage: “Kann ich damit auch gleiche Events zusammenfassen und automatisch Acknowledgen sobald ein passendes Clear Event kommt?”. Bisher musste ich immer beschämt sagen, dass wir so etwas geplant, aber noch nicht umgesetzt haben.
Ab heute ändert sich das – der EDBC ist in der ersten Beta da. Und mit ihm wird nicht ‘nur’ oben genanntes Szenario abgedeckt, sondern ein sehr mächtiges Werkzeug bereitgestellt um Nachrichten und Traps in ein Monitoringsystem einzubinden.
Die Hauptfeatures, die der EDBC derzeit bietet:

  • Empfangen von Ereignissen via Pipe, SNMP Handler und/oder Mail
  • Persistieren von Ereignissen in die EventDB, ggf. Vorfiltern der Ereignisse nach beliebigen Merkmalen (u.a. Netzwersegmente, OIDs, Teilstrings)
  • Erkennen logisch gleichartiger Events anhand von Feldwerten, Netzwerksegmenten, Teilstrings (via Regexp Gruppen), etc.
  • Zusammenfassen logisch gleichartiger Events
  • Erkennen von Clear Events und ggf. Acknowledgen aller zugehörigen Problemevents in der EventDB
  • Senden von Icinga/Nagios Kommandos bei bestimmten Events (…auch abhängig davon ob es ein neues Problem, ein bereits bekanntes Problem oder ein Clear event ist)
  • Einfache Erweiterbarkeit mit rudimentären Python Kenntnissen

(mehr …)

Kraut und Rüben: Kleine Helfer für Entwickler und Admins

Heute kurz und schmerzlos: Tools und Features, die ich sehr praktisch finde und niemanden verheimlichen will (..der sie noch nicht kennt).

PSTree

Mit pstree kann man sich seine Prozesse als hierarchischen Baum darstellen lassen. Sehr praktisch um Prozessabhängigkeiten zu erkennen, bzw. zu sehen welcher Prozess was geforkt hat.
Das sieht dann z.B. so aus:


[moja@localhost icinga-core]# pstree -ps 9975
systemd(1)───firefox(9975)─┬─{firefox}(9998)
                           ├─{firefox}(9999)
                           ├─{firefox}(10000)
                           ├─{firefox}(10001)
                           ├─{firefox}(10002)
                           ....
                           ├─{firefox}(20879)
                           └─{firefox}(20925)

Chrome Network Tools – Copy as Curl

In Chrome/ium kam vor kurzen ein neues, sehr praktisches Feature in die Netzwerktools: Mit der ‘Copy as curl’ Funktion kann man einen Request mit allen Headern und Parametern direkt als curl(1) Aufruf in die Zwischenablage kopieren:
Copy as Curl
Kleiner Tipp: Da als ‘Accept-Encoding’ gerne ‘gzip,deflate’ gesetzt ist und man damit eine gezippte Antwort bekommt sollte man entweder den -H “Accept-Encoding” Parameter aus der Anfrage entfernen oder das Ergebnis durch gzip pipen, um Zeichensalat zu verhindern.

Vim

Und ein paar kleine Vim Befehle gehen immer zum Abschluss:

  • tabnew, tabnext und tabprev Erstellen und Navigieren Tabs im VIM. Will man dann noch im Kommandomodus mit Tab zwischen den Tabs wechseln kann man folgendes in seine .vimrc hinzufügen:
    map  :tabnext <CR>
    map  :tabprev <CR>
  • earlier und later erlauben es, undo und redo mit Zeitangabe zu machen, z.B. earlier 5m (springe zu dem Zustand vor 5 Minuten)
  • Rechtschreibprüfung aktivieren (de_de für Deutsch einfügen):
    setlocal spell spelllang=en_us
  • Alle geöffneten Dateien, Fenster, Tabs, etc. speichern und wiederherstellen:
    mksession ~/.lastSession.vim
    vim -S ~/.lastSession.vim

Sneak Peak : HTTP 2.0

Wer ein wenig verfolgt, wie sich das Web entwickelt (z.B. indem man den W3C Blog in Google Reader abonniert!) hat vielleicht am Rande mitbekommen, dass die Spezifikation für HTTP 2.0 so langsam aber sicher beginnt.Google freut sich, denn das SPDY Protokoll wird hierfür als Grundlage genommen – auch wenn der finale Entwurf damit eventuell nicht mehr viel Gemein haben muss.
Jetzt ist natürlich die Frage, warum man einen Artikel über ein Protokoll schreiben soll das bisher noch nicht existiert. Den meisten Menschen ist es Bums, ob jetzt HTML über SPDY oder HTTP 1.1 versendet wird wenn Sie eine Abfrage abschicken. Hauptsache es geht.
Und die Anzahl der Webanwendungen, die aufgrund konkreter Limitierungen in HTTP nicht umgesetzt werden können sollte eher gering sein. Aber ehrlich: Da geht noch mehr. Seit HTTP 1.1 (1999) hat sich in der Netz- und Anwendungs- und Gerätewelt die ein oder andere Sache geändert (wer das noch nicht bemerkt hat soll doch über sein Tablet mal ‘mobile web’ googeln, sofern der WLAN Hotspot des Smartphones noch nicht den Akku gefressen hat).
Ich bin mir sicher (und hoffe es!), dass wir in Zukunft einen Aha-Effekt haben wenn wir auf das Jahr 2013 zurückblicken. Ungefähr so, wie wenn man heute mit einem älteren Firefox surft und sich wundert warum man damals so begeistert über dessen Geschwindigkeit war.
Da vieles bereits in ein paar Monaten obsolet ist, lass ich Protokolldetails aus und spreche nur ein paar Grundpfeiler des neuen Protokolls an. Die Drafts finden sich ja im Netz.
(mehr …)

Nicht nur für mobile Endgeräte: Responsive-Web mit Media-Queries

Im Buzzwort-Bingo hat beim heutigen Blogpost ‘Responsive Web’ zugeschlagen.
Nachdem Tablets und Smartphones in sehr kurzer Zeit zur potentiellen Zielgruppe für die meisten Webapplikationen gelten, geistert ‘Responsive Web’ als Paradigma durch das Web – und meint damit eigentlich nur, dass man jetzt wirklich darauf achten sollte dass Webseiten auch auf kleineren Displaygrößen benutzbar sind. Man tut dem ganzen aber Unrecht wenn man es nur als Mobile-Thema abtut – auch wer ‘nur’ mit dem Desktopbrowser surft kann von den Techniken profitieren.
Kernelement des ganzen sind CSS Media Queries. Diese stellen im Grunde eine Verfeinerung der media-types da, die alle Browser (ausser IE, der kann es ohne Hacks erst ab Version 9) seit Urzeiten unterstützen. mit
@media print {
... CSS für Druckausgabe ...
}
@media screen {
... CSS für Bildschirmausgabe ...
}

… stellen unzählige Angebote bereits Ihre Druckseiten anders dar als die Browseransicht (z.B. andere Schriftgrößen).
Media-Queries gehen noch einen Schritt weiter: Mit ihnen kann man CSS in Abhängigkeit der Fenstergröße, der Bildschirmorientierung (z.B. wenn man das Tablet dreht), des Höhe/Breite Verhältnisses, der Pixeldichte und vielen mehr anpassen. Die Query
@media screen and (max-width: 1024px) {
... css ...
}

definiert z.B. Regeln,die nur dann gelten, wenn das Browserfenster 1024px klein ist und greift auch, sobald der Nutzer das Fenster kleiner zieht. Meistens sieht man so etwas wenn es darum geht Mobilgeräte zu unterstützen, z.B. indem Werbebanner anders angezeigt werden sobald ein Gerät mit bestimmter Pixeldichte und Auflösung auf die Seite kommt. Man muss sich jedoch bewusst sein dass auch ein Desktopbrowser mit den gleichen Eigenschaften gerade die Seite anschauen könnte. Einen eigenen Medientyp für Smartphones oder Tablets gibt es nämlich nicht.
Allerdings sind media-queries in variablen Umgebungen wie dem Desktop-Browser fast praktischer: Da die Fenstergröße hier von sehr groß bis klein variieren kann sollte man als Entwickler auf Skalierbarkeit achten. Das fängt bei Netbooks an, geht zu Nutzern weiter die auch mal ein einzelnes Fenster klein gezogen haben, bis zu der (nicht mal so unpraktischen) Split-View von Windows 8.
Hier kann man mit Media-Queries ohne viel Aufwand auf Größenänderungen reagieren und die Seite anhand des vorhandenen Platzes anpassen. Denkbar wäre es je nach vorhandener Breite z.B. Icons kleiner zu machen, Bereiche nicht mehr nebeneinander, sondern untereinander darzustellen, u.v.m.
Als Demo habe ich mal ein kleines (extrem gestyltes) Szenario erstellt. Zieht man das Result-Fenster kleiner, ändert sich die Icongröße, der Text wird abgeschnitten und nur bei Mouseover angezeigt.
Zwar ist das keine Wunderwaffe für alle Szenarien, gezielt eingesetzt kann man damit aber den vorhandenen Platz oft besser Ausnutzen – ohne massig JavaScript schreiben zu müssen.

Simpel, schnell und praktisch – Webapplikationen mit Flask erstellen

Auf dem Planeten der serverseitigen Webtechnologien herrscht eine unbegrenzte Artenvielfalt. In den verschiedensprachigen Ländern und Inseln (Java, Pythonien, etc.) tummeln sich viele kleine Technologievölker und verehren ihre vielen Frameworks, die allesamt unermesslich Mächtig und Allumfassend sind. Unerbittliche Kriege werden geführt, welches Framework und welche Sprache besser ist, Neulinge kämpferisch missioniert und für die eigene Sache geworben.
Manchmal wünscht man sich einen kleinen Kometen, der ein wenig für Ordnung sorgt. Daher will ich zumindest in Python einen kleinen Tipp geben, wenns mal weniger sein darf:
Zur Vorgeschichte: Auch ich bin auf den Raspberry Pi Zug aufgesprungen und finde die Kiste als kleinen Programmierspielkasten wirklich sehr spaßig. Da ich für kleinere Spielereien Python oder NodeJS bevorzuge, war ich also auf der Suche nach einem kleinen Python Webframework – direkt gegen die WSGI zu programmieren empfinde ich doch als etwas unkomfortabel. Nun ist es hier nicht so einfach, ein passendes Framework zu finden, das mir nicht von vornherein MV* aufdrängt (manchmal braucht man das nicht, ehrlich), klein ist und sich ‘elegant anfühlt’.
Nachdem die Liste im Python wiki überflogen habe, bin ich erstmal aus dem Raum gegangen und habe ein wenig geweint. Django, Pylon, Zope… das war mir alles (auf den ersten Blick) zu groß, zu Vereinnahmend. Klar, große Frameworks mit ORM, SOAP support, MVC und allen möglichen Schnittstellen, Helfern und Features haben Ihren Sinn, aber manchmal ist auch bei der Webentwicklung weniger mehr (und mit NodeJS habe ich ja auch in ein paar Zeilen einen HTTP Server laufen ohne vorher ein Projektskeleton auf der Konsole zu erstellen).
Dann bin ich über Flask gestolpert und allein schon das Beispiel auf der Startseite hat die Tränen etwas trocknen lassen. Ein paar Zeilen, schon hat man einen Webdienst am Laufen, ein paar Zeilen mehr und man kann komplexe Templates einbinden. Formulare, Uploads, Routing, etc. – alles ist vorhanden. Dabei ist es egal ob man ein paar Funktionen über Urls ansprechen will oder man auf Klassenbasierte Views setzt – das Framework skaliert hier recht gut mit (aber zugegeben: Letzteres haben andere Frameworks schon eleganter umgesetzt).
Für mich wird das wohl das Pythonframework meiner Wahl für kleine und mittelgroße Projekte im Web (auch wenn es natürlich auch andere Frameworks, wie z.B. bottle gibt, die ähnlich kompakt sind). Für wirklich größere Anwendungen mit vielen Schnittstellen, Ausgabeformaten, Lokalisierung, etc. würde ich dann allerdings doch auf Django oder Zope umsteigen, hier ergibt der Mehraufwand beim Konfigurieren und der Größe dann auch wirklich Sinn.

InGraph – The ultimate guide 4/5

Im vorletzten Teil unseres großen InGraph Reiseführers geht es nicht direkt um das Graphing an sich, sondern um das Monitoring Plugin check_ingraph, das InGraph mitliefert.
Viele Probleme sind zum Glück schnell erklärt, aber leider auch genauso schnell verursacht: Switch kaputt, Festplatte tot, Zahlendreher beim ‘kill’.
Gelegentlich gibt es aber Situationen, die nicht einfach ad-hoc erscheinen, sich für das Adlerauge eines Sysadmins jedoch am Graphen erkennen lassen. Wenn normale, zeitlich begrenzte Lastanstiege im Lauf der Zeit immer stärker ausschlagen, kann man das im Wochenverlauf des Graphen erkennen – noch bevor es kritisch wird.
Aber: Schön und gut wenn man solche Probleme an den Werten des Graphen erkennt – nur wer vergleicht schon jeden Tag die aktuelle Last mit der Last von letzter Woche (vor allem wenn die Maschinen keine Probleme bereiten) ?
Ich weiß wer: check_ingraph!
Der kleine Streber ist simpel, aber effizient: Das Plugin vergleicht bestimme Werte (hier z.B. die Serverlast) aus einem Interval mit den Werten eines Intervals aus der Vergangenheit und geht auf Warning/Critical wenn sich zu starke Abweichungen zwischen den Intervallen ergeben. Man kann so z.B. überprüfen, ob die Lastwerte der letzten 2 Stunden sich stark von den Lastwerten der letzten zwei Stunden vor einer Woche unterscheiden. Im Falle des Falles kann das Plugin dann präventiv darauf hinweisen, dass die Last im Vergleich ungewöhnlich hoch ist (selbst wenn Sie noch nicht im kritischen Rahmen für das System ist).
In der unteren Grafik ist ein check_ingraph Check grafisch dargestellt, der prüft ob die Werte der letzten Woche sich stark von denen dieser Woche unterscheiden:
Screen Shot 2012 11 22 at 11.49.05 AM
Der Aufruf ist dabei wie folgt:
check_ingraph -H http1 -S "Current Load" -P load1 -F average -f -360 -g -192 -s -192 -t 0 -w 10 -c 20
Und, damit ich nicht einfach die tolle Dokumentation kopiere, etwas genauer:

  • -H http1 -S “Current Load” : -H ist der Parameter für den Host, -S für den Service. Hier überprüfen wir also den Current Load check vom Host ‘http1’
  • -P load1 : Perfdaten können ja beliebig viele Parameter enthalten, hier entscheiden wir uns für die Werte, die als load1 bezeichnet sind
  • -F average: Gibt an, dass der Durchschnitt der Intervalle verglichen wird. Hier kann man auch ‘trend’ für Trendwerte, ‘stddev’ für die Standardabweichung oder ‘hw’ für Holt-Winters Forecasting verwenden
  • -f -360: Das erste Interval beginnt vor 15 Tagen  (= -1 (da in der Vergangenheit) * 15  * 24 (Stunden))
  • -g -192: Das erste Interval endet vor 8 Tagen
  • -s 192: Das zweite Interval beginnt vor 8 Tagen
  • -t 0 : Das zweite Interval endet genau jetzt
  • -w 10: Bei 10% Abweichung wird ein warning zurückgegeben
  • -c 20: Bei 20% Abweichung wird ein critical zurückgegeben

Das sind zugleich auch die wichtigsten Parameter für die meisten Checks.
Zwar ist das Plugin recht einfach zu bedienen, die Effizienz hängt jedoch stark vom individuellen Anwendungsfall ab. Hier ein paar Fragen, die man sich beim Konfigurieren gerne stellen kann:

  • Ist meine Intervallgröße passend gewählt? Zu große Intervalle neigen dazu Abweichungen zu verschlucken, zu kleine Intervalle geben kleinen Abweichungen zu viel Gewicht.
  • Ergeben meine Intervalle Sinn? Wenn ein Datenbankserver nur unter der Woche belastet wird ergibt ein Vergleich zum Vortag keinen Sinn, da Samstage und Montage immer Alarm schlagen werden.
  • Ergibt Forecasting einen Sinn? Wenn ja – ergibt es einen Sinn bei meinem Intervall?

Check_ingraph bietet damit eine sinnvolle Ergänzung zum visuellen Monitoring mit Graphen. Der ein oder andere schleichende Ausfall lässt sich beim richtigen Einsatz des Plugin früh erkennen und der Admin schläft damit mal wieder etwas ruhiger.
Also runterladen und ausprobieren!