Endlich ist es da – check_netways

check_netwaysEs gibt Tage an denen man einfach nur glücklich ist und heute ist einer dieser Tage. Nach über 2 Jahren Entwicklung sind wir stolz check_netways endlich der Öffentlichkeit vorzustellen.
Auch wenn Nagios und Icinga über das größte Ökosystem im Bereich Monitoring verfügen, gibt es immer wieder Anwendungsfälle die mit den vorhandenen Mitteln nicht besonders einfach und intuitiv gelöst werden können. Wer kennt den täglichen Kampf mit Business-Anforderungen nicht!? Business-Rule-Definition, Event-Correlation oder einfach nur die automatische Überwachung eines dedizierten Netzwerks. Ständig brechen diese wechselnden Anforderungen über die Monitoring-Admins herein und man muss sich dann bei verschiedenen Plugin-Plattformen auf die Suche nach einer geeigneten Lösung begeben.
Damit ist heute Schluss! – Mit check_netways beginnt ein neues Zeitalter im Bereich Open Source Monitoring. Ob Geschäftsprozessüberwachung, Virtualisierungsmanagement oder schlichtweg die Überwachung des kompletten Rechenzentrums. All das ist dank check_netways nun kein Problem mehr! Das sind nur ein paar kleine Beispiele, denn die Möglichkeiten sind nahezu unbegrenzt. Und das Beste ist, auch die Performancewerte sind bei jedem Modul schon dabei.
Nachfolgend  stellen wir gleich ein paar Beispiele und Möglichkeiten des neuen Plugins vor:

  • Mit der ausführlichen Onlinehilfe gehören lästige Markdown- oder Docbook-Orgien der Vergangenheit an
./check_netways.sh
Missing parameters! Syntax: ./check_netways.sh MODE SYSTEM
  • Komplexe Geschäftsprozesse können mit nur einer Kommandozeile konfiguriert und in der Folge auf Basis von verschiedenen UND/ODER Abhängigkeiten ausgewertet und überwacht werden. Ihr Geschäftsprozess setzt die Verfügbarkeit eines entfernten Fileservers voraus? check_netways hat für jede Herausforderung eine Lösung und erkennt Außenstandorte sowie zugeordnete Betriebsstätten und Rechenzentren automatisch.
./check_netways.sh BPRULES webserverANDdbserverORminONEfileserverSOMEWHERE
OK - BPRULES for webserverANDdbserverORminONEfileserverSOMEWHERE works great | performance=100%;errors=0

Zusammen mit dem neuen Icinga-Webinterface erkennt man schnell die Potentiale in check_netways. Schnelle Überwachung und 100% Verfügbarkeit werden somit Realität.

icingaweb

  • Korrelation aller eingehenden Syslog-Nachrichten zwischen 8 und 12 Uhr. Während bisherige Lösungen eine aufwendige Konfiguration von Zielsystemen und Korrelationsregeln benötigen, erkennt check_netways automatisch alle verfügbaren Logfiles und  teilt auf Basis einer MD5-Checksumme die notwendigen Filter zu. Die integrierte Correlation- und Aggregation-Engine kann mit Hilfe einer simplen Camel-Case-Syntax an die notwendigen Rahmenbedingungen angepasst und performant ausgeführt werden.
./check_netways.sh CORRELATION AllSyslogEventsBetween8and12
OK - CORRELATION for AllSyslogEventsBetween8and12 works great | performance=100%;errors=0
  • Überwachung einer nicht vorhandenen OpenStack-Cloud. Komplexe Infrastrukturlösungen wie OpenStack oder Eucalyptus sind bei der Neuimplementierung mit nicht unerheblichen Aufwänden verbunden. Die Vielzahl an Komponenten macht es hinzu  sehr schwer, alle notwendigen System im Monitoring zu erfassen. check_netways bringt für alle gängigen Virtualisierungsumgebungen bereits ein fertiges Regelset mit und erleichtert so den Einstieg in den Themenkomplex Cloud-Monitoring. Aktuell unterstützt check_netways bereits OpenNebula, OpenStack, Eucalyptus und Bambus.
./check_netways.sh CLOUD OpenStack
OK - CLOUD for OpenStack works great | performance=100%;errors=0
  • Autodiscovery eines spezifischen Subnetzes mit Ausschluss einer IP-Adresse

Autodiscovery ist eine beliebte Methode um die teils unbekannte Infrastruktur in ein Monitoringsystem zu integrieren. Der Scan von Netzwerk und den darin befindlichen Objekten muss schnell und einfach zu starten und die gefundenen Services von guter Qualität sein. Im den Bereichen Usability und Performance setzt check_netways hier neue Massstäbe. Bereits nach einer knappen Sekunde ist das komplette Netz gescannt und sämtliche Dienste sowie bereits ausgebaute Festplatten und Netzwerkkarten werden automatisch in die Monitoringlösung integriert. Bei Verwendung von time erkennt der Spezialist sofort. dass hier ordentliche Entwicklungsarbeit geleistet wurde. Sämtliche Scan-Aufträge werden unter Berücksichtigung der zur Verfügung stehenden Ressourcen auf mehrere Prozessorkerne aufgeteilt und parallelisiert ausgeführt.

time ./check_netways.sh AUTODISCOVERY 10.10.10/24 without 10.10.10.2
OK - AUTODISCOVERY for 10.10.10/24 works great | performance=100%;errors=0
real	0m0.004s
user	0m0.002s
sys	0m0.002s

Natürlich könnt ihr check_netways gleich hier herunterladen und Euch mit der einfachen Überwachungssyntax vertraut machen. Schon nach kurzer Zeit hat man sich an die einfache Konfiguration und den lingualen Konfigparser gewöhnt und kann  sich ein Leben ohne immergrünes Monitoring nicht mehr vorstellen. Mit der integrierten Unterstützung für SDN, SDI und DevOps hat check_netways das Potential auch in anderen Infrastrukturbereichen massgeblich am Unternehmenserfolg beizutragen. Wir wünschen viel Spass damit und freuen uns wie immer auf Euer Feedback.

Bernd Erk
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startet er das wöchentliche Lexware-Backup und investiert seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinem Sohn.

Was ist DevOps und was nicht?

Natürlich sagt Euch der Begriff DevOps was, oder? Auf diesem Blog sind nur Profis, IT-Veteranen, Geeks, Nerds oder kurzum die besten Leser der Welt unterwegs. Somit gehe ich also davon aus, dass ihr das Wort DevOps schon mal mehrfach gehört habt und es grob einordnen könnt. Für alle anderen (Herzlich Willkommen) trotzdem ein paar Worte zum Hintergrund. Der Ursprung dieses aus Development und Operations zusammengesetzten und dann gekürzten Hauptworts liegt in Belgien. Neben EU-Richtlinien und erträglichem Bier wurde der Begriff durch die DevOpsDay 2009 in Ghent, genauer Patrick Debois, geprägt. Seitdem gibt es eine wachsende Gruppe von “Hardcore-Hackern”, welche die DevOps Kultur in alle Welt tragen.
Mit dem Wort Kultur ist bereits auch ganz gut beschrieben, was DevOps ist bzw. sein könnte. Dem ein oder anderen Produktmanager und Business-Developer wird es jetzt eiskalt den Rücken runterlaufen. Kein Tool, kein Standard, keine Zertifizierung -> Da kann ich doch zum Quartalsende gar kein Lizenzbundle draus machen. Nun Freunde, ich arbeite lange genug in der IT um Tools dieser Art trotzdem vorauszusagen und vielleicht steht der Oracle DevOps Developer oder Borland DevOps Builder ja schon in den Startlöchern und wird zur nächsten CeBIT 2013 released.
Kommt schon Jungs!
Eigentlich, zumindest verstehe ich es so, ist DevOps nur der Versuch mit dem Kastendenken innerhalb der IT, aber auch innerhalb eines Teams aufzuräumen. Die Knackpunkte sind hier sowohl in der Zusammenarbeit, als auch in den grundsätzlichen Entscheidungsfindungsprozessen.
Das Hin-und-her zwischen Entwicklung und Betrieb ist nicht selten ein etablierter Bestandteil des täglichen Miteinanders in großen IT-Bereichen. Ob nun die Entwickler nicht sauber dokumentiert haben oder der Betrieb einfach nur unfähig ist, die Software zu installieren, lässt dabei meist nicht final klären, sicher ist nur das mehr Energie in Schuldzuweisungen verpufft, als in der Lösungssuche. Hat man vor einigen Jahren noch im Wasserfall-Prinzip und großen Iterationszyklen entwickelt, so geht es heute fast täglich heiß her. Die Anforderungen an eine schnelle und gute Zusammenarbeit zwischen Betrieb und Entwicklung sind daher elementar und vermutlich auch einer der Hauptgründe der DevOps-Bewegung. Konnte man sich früher nach einem unglücklichen Release noch einige Wochen in der Kantine aus dem Weg gehen, steht der Entwickler heute am nächsten Tag schon wieder vor der Tür und will einen Fix einspielen. An das “Schau mal, die Trottel von der Entwicklung” kann ich mich übrigens noch wahrhaftig erinnern, jedoch ist es schon fast 15 Jahre her.
Diese Barriere zu brechen, und das ist wahrlich eine schwierige Herausforderung, wäre eine der größten Leistungen, die DevOps erbringen könnte. Und keine Angst, vielleicht sitzt man hier und dort schon nebeneinander, hat den Admin mit Ruby-Fähigkeiten ins Dev-Team integriert und installiert zusammen das neueste Release. Dann, auch wenn es nicht so genannt wird, seid ihr vielleicht schon Ultra-DevOps!
Was brauch ich und wie geht’s?
Wer bis zu diesem Absatz vorgedrungen ist, hat auf jeden Fall Geduld mitgebracht und vermutlich ist schon lange klar, dass die Frage nach dem “Was brauch ich und wie geht’s?” nicht allgemein beantwortet werden kann. Neben der Bereitschaft, Fehler zu machen und den Möglichkeiten, diese auch schnell zu beheben, gibt es jedoch einige Tools, die es einfacher machen mit schnellen Releasezyklen, vielen Abhängigkeiten und utopischen Anforderungen aus dem Produktmanagement umzugehen. Dies fängt bei Continuous Integration mit bspw. Jenkins an. Nur nur durch permanente Qualitätskontrolle und Review der durchgeführten Änderungen können Fehler auch langfristig zurückverfolgt und im Idealfall vor dem Release identifiziert und beseitigt werden. Darauf aufbauend empfiehlt sich auf jeden Fall ein methodischer Prozess der automatischen Softwareverteilung und Installation mit Puppet, Chef oder CFEngine. Ein ordentlich beschriebener Konfigurationsprozess ist hinzu schon die halbe Doku. Das sind nur ein paar Beispiele und die Tools, die das Leben leichter machen, werden täglich mehr. Leider sind sie dank der Faulheit mancher Entwickler nur durch stundenlanges Rumsuchen auf GitHub zu finden. Arghh, jetzt kommen meine Operations-Wurzeln wieder durch.
Wenn ich es nicht überwachen kann, dann existiert es nicht!

Ein ganz wichtiger Teil der DevOps-Kultur ist aus meiner Sicht das Treffen von Entscheidung auf Basis von Messwerten. Ob die verwendeten Werte hierbei aus traditionellen Tools wie Icinga und Nagios oder neueren Trends wie collectd, logstash, Graylog oder später zur Darstellung Graphite kommen, spielt dafür keine Rolle. Entscheidend ist eben die Arbeit auf Basis von Fehlern, Erkenntnissen und Messwerten und nicht auf Basis von HIPPO*-Decisions.  Dies ist nicht immer einfach, und wenn ein Vorschlag mit der Antwort “Proof it” in Frage gestellt wird, vielleicht auch aufwändig. Am Ende werden regelmäßige Iteration und der ehrliche Umgang miteinander jedoch fast automatisch zum besten Ergebnis führen. Und mal ehrlich, wenn wir ITler nicht in der Lage sind, unsere Entscheidungen auf Basis von Messwerten zu treffen, wer soll es sonst schaffen. Jeder Controller und Unternehmensprüfer, der wochenlang Zahlen aus Ordnern akribisch in Excel-Listen überführen muss, würde sich zwei Finger abhacken, wenn ihm alle Informationen digitalisiert zur Verfügung gestellt würden. Wir sind nur häufig einfach zu faul, was daraus zu machen. An den möglichen Stellen konfigurieren und tunen wir dann so lange ohne Zwischenmessung rum, bis es letztendlich besser läuft als am Anfang. Warum weiß dann eben auch keiner und die Reproduzierbarkeit ist fast unmöglich.
Um was geht es eigentlich?
Man sollte ja eigentlich glauben, dass “To-Be-Online” die übergeordnete Motivation der täglichen Arbeit ist. Kurz also den oder die Services für interne und/oder externe Kunden zur Verfügung zu stellen und damit die Wertschöpfungskette aufrecht zu  erhalten. Kurz gesagt: Womit verdienen wir eigentlich unser Geld. Diese Betrachtung kommt ihm Dickicht der Schuldzuweisungen und bei heissen Diskussionen häufig zu kurz. Kann man seine internen Leitlinien jedoch dem Grundsatz “Service First” unterstellen, verschwinden die unüberwindbaren Grenzen zwischen Development und Operations. Das gemeinsame Ziel der Verfügbarkeit macht es leichter und der ggf. notwendige Rollback geht zusammen mit dem zuständigen Developer mit Sicherheit leichter von der Hand. Die Verantwortung für das Produkt X motiviert dabei auch um Längen mehr, als die Bereitstellung eines WAR-Files in irgendeinem einem Tomcat oder JBoss.
Mein Fazit
Zusammengefasst ist DevOps für mich:

  • Offenheit: Jeder, der kann, darf auch, aber bitte mit Hirn.
  • Automatisierung: Voraussetzung für schnelle reproduzierbare Arbeit mit Korrekturmöglichkeit
  • Entscheidungsklarheit: “Trial and Error” und das auf  Basis von messbaren Informationen
  • Produktsicht: Funktionsfähigkeit kommt vor technischen Unzulänglichkeiten
Dabei sollte an dieser Stelle aber auch nicht unerwähnt bleiben, was DevOps für mich nicht ist:
  • Maßnahmenkatalog: Ich erwarte mit Sorge das erste Zertifizierungsprogramm
  • Stellenbeschreibung: Versucht nicht den Senior DevOps Manager einzustellen
  • Consulting-Packet: Das DevOps Paket für den Mittelstand – Bitte nicht!
Mit zunehmender Popularität wachsen die Misshandlungen an einst nicht kommerziellen Ideen. Es wird nicht so einschlagen wie die CLOUD, aber man wird sich kreativ damit auseinandersetzen und Ideen dazu entwickeln. Der gegenseitige Erfahrungsaustausch und die Bereitschaft Neues zu versuchen sollte genügen um sich einiger Ideen der DevOps Bewegung zu bedienen. Wer dann trotzdem noch Consulting braucht, der kommt dann natürlich zu uns 🙂

* Highest Paid Person Opinion (DANKE KRIS)
(Monitoring-Picture von Noah Sussmann)

Bernd Erk
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startet er das wöchentliche Lexware-Backup und investiert seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinem Sohn.