Hitzefrei

Das Blech vibriert, die Lüfter föhnen:
Hört doch, wie die Server stöhnen!
Würds’ hier ein Thermometer geben
Könnte man jetzt live erleben
Wie Zehnt um Zehnt die Säule steigt
Während’s längst schon rot anzeigt.

Ventilatoren quietschen, schleifen, scheuern,
Man müsst’ vielleicht ein paar erneuern.
Gepiepse, nervzerreißend sticht hervor,
Übertönt den jämmerlichen Lüfterchor.
Expertenmeinung: “Gar nicht gut,
Ich glaube irgendwo ist was kaputt”.

Die Experten sind nur grad nicht hier,
Ihr Freitag-Feierabend war um vier.
Ansonsten sieht man sie im Office schwitzen
Und nicht hier unten im Gedröhne sitzen.
Schreien Server noch bevor die Platte bricht,
Nützt’s nicht viel, man hört sie nicht.

So kommt es wie es kommen muss,
Groß das G’schrei und der Verdruss
Zwar läuft die Klima immer weiter
Auch die Chiller drehen heiter.
Dumm nur dass das Wasser steht,
Weil wer am falschen Hahn gedreht.

So kommt es wie es kommen muss,
Vom Head-Crash einen schönen Gruß.
And’re Server fahr’n sich runter,
Jetzt werden erste Admins munter
Denn das Smartphone meckert an,
Dass es keine Mails hol’n kann.

Schwer ist es jetzt zu ertragen
Wenn dann die Besserwisser sagen:
Mit Icinga wär das nicht passiert,
Du wärst beizeiten informiert.
Wüsstest welcher Server piept,
Wer wann warum den Geist aufgibt.

Auch würdest dich jetzt besser fühlen
Müsstest nicht nach Backups wühlen
Weil Bareos-Jobs nicht Handarbeit
Sondern Puppet-driven stets bereit
Auf jedem deiner Server laufen:
Du müsstest nie Lizenzen kaufen.

Das hast du alles? Wissen wir,
Schließlich bist ja Kunde hier.
Mit freier Software stets entspannt,
Wird Unheil frühzeitig erkannt.
Auch hast im Rechenzentrum Ohren,
Aus dem Netways-Shop sind die Sensoren.

In diesem Sinne, fröhlich heiter
Genieße ruhig die Sonne weiter.
Das Wochenend steht vor der Tür,
Ein kühles Bierchen gönne dir.
Leg dich hin und werd bedient,
Schließlich hast es dir verdient!

Thomas Gelf

Autor: Thomas Gelf

Der gebürtige Südtiroler Tom arbeitet als 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.

JSON-Streams über HTTP

Viele Anwendungen sind darauf angewiesen, in Echtzeit Benachrichtigungen zu bestimmten Ereignissen zu erhalten:

  • Der Benutzer soll sofort über neue E-Mails benachrichtigt werden.
  • Notifications von einem Monitoring-System sollen durch eine Anwendung in der Taskleiste angezeigt werden.
  • Nachrichten, die per Instant Messaging versendet werden, sollten zeitnah beim Empfänger ankommen.

Zur Umsetzung solcher Anwendungen bieten sich durch die Verwendung von bekannten Standardprotokollen wie HTTP signifikante Vorteile:

Vorhandene Tools und Infrastruktur

Für HTTP gibt es in nahezu jeder Programmiersprache nativ integrierte Libraries. Hierdurch sinkt für Entwickler, die einen neuen Client für das Protokoll schreiben wollen der initiale Aufwand. Zwar unterscheiden sich die Anwendungen trotzdem noch an einigen Stellen (Wie sehen einzelne Messages aus? Welche URLs werden verwendet?), dafür werden andere Themen wie Authentifizierung bereits durch den Standard abgehandelt.

Um im Fehlerfall bzw. während der Entwicklung Probleme zu analysieren gibt es bereits etliche Tools. Diese reichen von einfachen konsolen-basierten HTTP-Clients wie curl und wget über Protokoll-Analyse-Tools wie Wireshark hin zu speziell für HTTP entwickelten Debug-Hilfsmitteln wie Fiddler.

Zusätzlich unterstützt HTTP mittels HTTP-Proxies “Routing”, da es in jeder Anfrage alle notwendigen Adressinformationen bereithält.

Streaming über HTTP

Nun ist HTTP zunächst ein Protokoll, das darauf basiert, dass für eine Anfrage jeweils genau eine Antwort übermittelt wird. Wie können wir nun also dem HTTP-Client unaufgefordert Events schicken?

Die einfache Grundlage hierfür ist eine Technologie, die als “Long Polling” bekannt ist: Der HTTP-Client sendet hierbei zunächst einen Request und bekommt vom Server auch eine Antwort. Diese Antwort hat allerdings kein Ende: Der Server sendet über die noch bestehende Verbindung JSON-kodierte Ereignisse sobald sie vorliegen.

Der Client muss dazu die Möglichkeit haben, zwischen den einzelnen JSON-kodierten Ereignissen unterscheiden zu können. Am Beispiel von zwei JSON-Ereignissen möchte ich hier auf die unterschiedlichen Ansätze eingehen.

Beispiel:

  • { “id”: 1, “message”: “Hallo Welt” }
  • { “id”: 2, “message”: “Dies ist ein Test.” }

Inkrementeller JSON-Parser

Ein JSON-Parser, der den Datenstrom inkrementell parsen kann, hat die Möglichkeit, zu erkennen, an welcher Stelle eine JSON-Message aufhört und die nächste beginnt. Die Messages werden hierbei also einfach aneinander gehängt. Der Body der HTTP-Antwort würde dabei etwa so aussehen:

{ "id": 1, "message": "Hallo Welt" }{ "id": 2, "message": "Dies ist ein Test." }

Vorteil hierbei ist, dass die Implementation des Servers sehr einfach ist. Allerdings können nur wenige JSON-Parser inkrementell parsen, was die Entwicklung des Clients erschwert.

Eine JSON-Message pro Zeile

Hierbei werden einzelne JSON-Messages per Newline (“\n”) getrennt. Beim Encoden der Messages muss darauf geachtet werden, dass diese selbst keine Newlines beinhalten.

{ "id": 1, "message": "Hallo Welt" }
{ "id": 2, "message": "Dies ist ein Test." }

Auf Clientseite ist dies im Regelfall recht einfach umzusetzen. Die Entwicklung des Servers wird minimal dadurch erschwert, dass mit Newlines innerhalb der JSON-Messages richtig umgegangen werden muss.

Längenangabe vor jeder JSON-Message

Bei dieser Möglichkeit sendet der Server vor jeder eigentlichen Message die Länge der JSON-Daten gefolgt von einem Newline:

37
{ "id": 1, "message": "Hallo Welt" }
45
{ "id": 2, "message": "Dies ist ein Test." }

(Wer nachzählt kommt möglicherweise darauf, dass die Längenangaben um ein Byte zu groß sind. Hierbei ist zu beachten, dass ich für dieses Beispiel aus Gründen der Lesbarkeit nach den JSON-Messages ein Newline eingefügt habe, das dann auch Bestandteil der Message ist und mitgezählt werden muss.)

Im Regelfall sollte es sowohl für Client als auch Server recht einfach sein, dies umzusetzen.

Gunnar Beutner

Autor: Gunnar Beutner

Vor seinem Eintritt bei NETWAYS arbeitete Gunnar bei einem großen deutschen Hostingprovider, wo er bereits viel Erfahrung in der Softwareentwicklung für das Servermanagement sammeln konnte. Bei uns kümmert er sich vor allem um verschiedene Kundenprojekte, aber auch eigene Tools wie inGraph oder Icinga2.

Kleine Briefe erhalten die Freundschaft: Little Letter

little_letterSeit vielen Jahren hosten wir mit Clever Elements eine phantastische Newsletter-Plattform, die wir selbst seit einem Jahr für unsere Newsletter verwenden. Das Unternehmen mit dem Sitz in Berlin ruht sich aber nicht auf dem Erreichten aus, sondern bringt mit Little Letter eine neue Idee an den Start.

Die neue Onlineplattform eröffnet neue Möglichkeiten fürs Marketing mit bis zu 297 Zeichen und schickt sich an, Social Media-Angebote wie Twitter und Facebook zu ergänzen: Little Letter ist wie eine digitale Postkarte und verbindet die Vorteile von E-Mail mit denen von Twitter. Der Absender kann über die Website littleletter.com Botschaften versenden, die aus einem Titel, maximal 297 Zeichen sowie optional einem Bild bestehen. Auf dieser Website können die Nachrichten auch abonniert (oder abbestellt) werden. Aber anders als Tweets werden diese Nachrichten wie eine E-Mail zugestellt.

Viele Menschen können mit Social Media-Angeboten wie Facebook oder Twitter nichts anfangen, nutzen aber selbstverständlich E-Mail

sagt Manuel Kistner, Geschäftsführer von Clever Elements aus Berlin, auch diese Menschen möchten gerne mit den von ihnen favorisierten Brands im Kontakt bleiben. Diese Lücke schliesst Little Letter. So können Unternehmen ihre Botschaften gezielt an ihre Fans und Kunden senden. Es gibt nahezu keinen Streuverlust, da der Nutzer gezielt abonniert.

Unternehmen können eigene Little Letter-Kanäle für die gesamte Marke oder für einzelne Produkte einrichten. Denkbar sind auch Kampagnen-Aktionen mithilfe der neuen Plattform. Little Letter eignet sich aber auch für Menschen, egal ob Promis oder Privatleute.

Kistner benutzt den neuen Kanal zurzeit selbst intensiv. Er befindet sich seit Oktober 2014 mit seiner Freundin auf einer dreijährigen Weltreise. Von unterwegs betreut er sein Unternehmen Clever Elements gemeinsam mit seinem Kompagnon, der in Berlin wohnt. Natürlich nutzt er alle Möglichkeiten des digitalen Lebens von Skype bis E-Mail, um sich mit dem zweiten Geschäftsführer abzustimmen. Aber um mit Freunden und Familie in Kontakt zu bleiben, versendet er täglich einen Little Letter, der wie eine Postkarte ein Schlaglicht wirft auf seine Reise und was er dabei erlebt.

Natürlich könnte ich auch twittern, aber die digitale Postkarte, die bei allen von alleine landet, die mich abonniert haben, ist ungleich komfortabler€œ

so der Unternehmer, der derzeit durch Lateinamerika reist.

Wir bei NETWAYS freuen uns auf jeden Fall über jeden ein- und ausgehenden Traffic (DDOS-Attacken ausgeschlossen) und werden Little Letter gleich mal bei unserem nächsten USA-Trip im Oktober testen. Und wer will das nicht lesen?!

Bernd Erk

Autor: Bernd Erk

Bernd ist einer der Geschäftsführer der NETWAYS Gruppe und verantwortet das Tagesgeschäft. Da er in einem früheren Leben mit Java und Oracle Datenbanken gearbeitet hat, kümmert er sich immer noch gerne um das Thema Reporting - sowohl bei NETWAYS, als auch im Icinga Team. In seiner knappen Freizeit streitet er sich mit seinem Sohn, wer das iPad gerade benutzen darf und widmet sich der Weiterverbreitung der gehobenen fränkischen Schaschlik-Kultur.

Monthly Snap June: NetApp FAS 3140; News about OSMC and OSBConf; Katello; Open-Stack-Tage

June started with Georg looking for a new home for a used NetApp FAS 3140 we received from a client. The beautiful device is in good condition and can be fetched at our office, if you make a camerasmall donation.

My humble self, told you all you need to know about the Hackathon at OSMC and started the OSMC countdown with the presentation “OSMC 2014: From monitoringsucks to monitoringlove, and back” by Kris Buytaert. I also introduced the complete speaker lineup of Open Source Backup Conference to you.

Dirk introduced you all to Katello, the Foreman Plugin for Softwaremanagement and reported on why you should have a look at it, if you don’t have a provisioning and Configuration Management yet.

And Bernd wrote about what happed at his visit of Open-Stack-Tage in Frakfurt.

Eva Häusler

Autor: Eva Häusler

Eva ist bei NETWAYS für das Marketing zuständig. Gerüchten zufolge wurde sie vor etwa einem Jahrzehnt in einer Kiste Braunschweiger Honigkuchen von Niedersachsen nach Franken geschmuggelt und wird seitdem hier in Geiselhaft gehalten. Nach einem Germanistikstudium mit begleitenden Ausflügen in die Nürnberger Literaturszene, hat sie bei NETWAYS in der Eventabteilung angefangen. Inzwischen kommt ihre geballte Wortgewalt im Marketing nutzbringend zum Einsatz.

Guest Post by Alan Robertson: How The Assimilation Project Got Started

Back in about 2010, I was working on a highly custom supercomputer research project with about 2.2 million cores called Cyclops64. It was a joint project between the University of Delaware, IBM and the NSA. It was interesting in a lot of respects, but what its most unusual feature was its networking. Each system was directly connected to 6 other systems by high-speed interconnects forming a cube, and only a few systems on one of the cube faces were connected to a “normal” ethernet network. The cube was 24x24x24 and each system had 160 cores (total: 2211840 cores).

As I thought about it, I realized that the way conventional monitoring systems like Nagios or Icinga work would be absolutely horrible in this environment. Imagine that the monitoring system was in one corner of the cube. Then each “Are You OK?” message would have to through 24 systems up, then 24 systems to the right, then 24 systems forward. The return message would have to follow the reverse return path – meaning that each round trip would touch 144 systems. Of course, the network in the vicinity of the central system would be totally destroyed by this traffic if it happened at any reasonable rate.

After thinking about it, I realized that it would be much better if each system monitored its six neighbors instead – delegating these “Are You OK?” queries to the machines being monitored. This totally changed the complexity of the task, and the network load – no network hot spots, and the central system had nothing to do most of the time – an amazing difference! I also realized that more conventional systems have these same problems of network congestion and ever growing centralized workload.

So, I adapted this idea to “normal” systems, and the Assimilation Project was born – providing greater scalability than any predecessors, while being incredibly simple. To keep the same topology-awareness that the original idea had, I realized that I needed to discover network connectivity. Once I’d done that, I realized that I could easily discover what services the system had which would eliminate manual configuration. Further, I could discover dependencies, which are essential to tracing problems to their root causes. Then I realized that this was all really a huge graph, so I adopted the Neo4j graph database. Lots of other valuable capabilities quickly became obvious results of having comprehensive and scalable discovery.

About this time, I realized that discovery was the real value and doing things like monitoring, and security compliance, network management and many other incredibly valuable applications naturally fell out from being able to easily know basically everything about everything and putting it into a graph-based configuration management database (CMDB).

So, it goes without saying that I’m excited to return to the OSMC in Nürnberg and talk about all the exciting new things we’re doing in the Assimilation Project. After all, the last time I was there, I had a great time and my talk got some pretty cool tweets.

magic+unicorns-1200

*The Cyclops64 has special monitoring hardware making this unnecessary.

_______________________________________________________________________________________________________________________

The Author Alan Robertson


Alan Robertson is an open source project leader and speaker on security, availability, discovery and monitoring. He founded Linux-HA (Pacemaker) and the Assimilation Project which maintains a scalable configuration management database driving monitoring and security.
_______________________________________________________________________________________________________________________

Eva Häusler

Autor: Eva Häusler

Eva ist bei NETWAYS für das Marketing zuständig. Gerüchten zufolge wurde sie vor etwa einem Jahrzehnt in einer Kiste Braunschweiger Honigkuchen von Niedersachsen nach Franken geschmuggelt und wird seitdem hier in Geiselhaft gehalten. Nach einem Germanistikstudium mit begleitenden Ausflügen in die Nürnberger Literaturszene, hat sie bei NETWAYS in der Eventabteilung angefangen. Inzwischen kommt ihre geballte Wortgewalt im Marketing nutzbringend zum Einsatz.