Der kleine Ping erkundet die Welt

Als der kleine Ping vor bald 34 Jahren geboren wurde, war die Welt noch übersichtlich und in Ordnung. Jeder kannte jeden und man lernte schnell neue Freunde kennen. Diese Freunde bleiben einem dann häufig auch lange treu. Ein offenherziger Kerl wie der kleine Ping lernte damals sehr schnell sehr viele Freunde kennen.

Gut erzogen und treu wie er war, besuchte er die meisten davon immer wieder und wieder. War jemand krank, dann war Ping schon mal länger unterwegs oder kam gar nicht mehr zurück. Aber langsam von vorn.

Seinen Namen bekam der kleine Ping vermutlich, weil sein Vater Mike zu viele Kriegsfilme im Fernsehen schaute. Oder weil seine Arbeit bei der US Army ihn so faszinierte. Ping, so hört sich nämlich der Sonar ein einem U-Boot an. Wie ein Klopfen. Irgendwie fanden seine Eltern das wohl sehr spannend. Also die Tatsache dass da Schallsignale gesendet und wieder zurück reflektiert wurden.

Das wäre doch auch ein schöner Job für unseren Ping, dachten sie. Also wurde der kleine Ping schon sehr früh losgeschickt, um unsere Welt zu erkunden. Da war er noch ganz klein, gerade mal 1000 Zeilen hoch. Dennoch fühlte er sich wie ein ganz Großer. Ständig auf Reisen kannte er sehr bald jede Straße, jede Autobahn und jeden Weg wie seine Westentasche. Das fand er unglaublich spannend.

Sein Vater war aber sehr streng. Jedesmal wenn Ping das Haus verließ notierte er auf die Millisekunde genau, wie spät es war. Und als der Ping dann wieder zurückkam, wurde auch das notiert. Aus Start- und Endzeit errechnete sein Vater dann, wie lange der kleine Ping unterwegs war.

Als der kleine Ping älter wurde, machte er sein Hobby zum Beruf. Wenn jemand wissen wollte, wie lang man auf einer Strecke unterwegs war, dann ging er zum kleinen Ping. Wollte ein LKW-Fahrer wissen, ob sein fetter Brummi unter einer Brücke Platz hätte – unser Ping konnte das klären.

Manchmal war es freilich ein wenig langweilig. Als Berufspendler war er hauptsächlich auf immer denselben Strecken unterwegs. Zu den Stoßzeiten im Stau zu sein war auch kein Vergnügen. Ping nahm sich dann ab und an andere Texte zum Lesen mit, das sorgte für gute Unterhaltung. Sein Vater prüfte übrigens immer, ob er auch wirklich mit denselben Texten wieder nach Hause kam. Fehlten Buchstaben oder waren falsche dabei, dann ließ er ihn unter Umständen gar nicht mehr ins Haus. Ping musste dann auf der Straße übernachten.

Ab und an erlaubte Ping sich einen Spaß. Da packte er ein Vielfaches an Ladung drauf um zu sehen, ob auch wirklich alle Tunnel-Decken und Brücken hoch genug waren. Er war halt so ein richtig nerviger Besserwisser. Und ab und an krachte es dabei natürlich ganz heftig. Ping bekam dann aber nicht etwa Stress. Das lief dann einfach als “Prüfung des Maximalen Tunnel Umfangs”, kurz MTU-Test. Ping hatte seinen Spaß – und die Polizei war froh, dass sie von jemandem auf Verletzungen der Bauvorschriften hingewiesen wurden.

Die richtig wichtigen Jobs bekamen andere. Einige seiner Brüder arbeiteten bei der Polizei, das hätte dem kleinen Ping gefallen. Bei welcher Einheit wäre ihm egal gewesen, zur Not auch bei den lahmen Kerlen von der “Ruhigen Inneren Polizei”, dem RIP. Das sind die Verkehrspolizisten in den kleinen Käffern auf dem Land.

Im Grunde machten die nicht viel mehr als die Leute nach links und rechts zu dirigieren. Aber dennoch. Betrachtete man das Geschehen vom Kirchturm aus, dann sah das schon beeindruckend aus. Alles floss schön links und rechts an den Polizisten vorbei – genau wie die sich das gerade so vorstellten. Ganz großes Kino!

Die richtig coolen Jungs hingegen arbeiteten bei der “Beindruckend Großen Polizei”, dem BGP. Das ist die Autobahnpolizei, irre was bei denen abging. Schon bei der Aufnahmeprüfung musste jeder von denen ein paar hunderttausend Routen im Kopf haben. Das klang irre anspruchsvoll und stressig. So weit wollte der kleine Ping dann doch nicht hinaus. Aber ab und an davon zu träumen, das war schon schön.

Der kleine Ping war zufrieden mit seinem Job. Er war es, der dieses Berufsbild erfunden und geformt hatte. Tausende hatten es ihm im Laufe der Jahre nachgemacht. Und heute ist er nicht zuletzt wichtiger Bestandteil einer jeden Monitoring-Umgebung. Auch wir haben kaum irgendwo eine Icinga-Umgebung am Laufen, in welchem er nicht zuverlässig seinen Dienst verrichten würden. Darum sei ihm an dieser Stelle mal ein Lob ausgesprochen: er macht seinen Job ausgezeichnet, ist zuverlässig und unauffällig.

Weiter so, lieber kleiner Ping!

Thomas Gelf

Autor: Thomas Gelf

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.

+++ Final note | Only a few OSMC tickets available +++


Nächste Woche ist es schon soweit und die 12. OSMC öffnet ihre Tore! Erfreulicher Weise sind nur noch ein paar letzte Tickets buchbar! Darum heißt es schnell handeln, um noch dabei sein zu können! Neben einem tollen Programm und einer mit Sicherheit grandiosen Abendveranstaltung  bietet die OSMC alles was für eine gelungene Konferenz notwendig ist. Bis nächste Woche!

 

Markus Neder

Autor: Markus Neder

Nach langen Jahren im Hotelgewerbe, hat sich Markus auf die andere Seite geschlagen und leitet nun bei NETWAYS die Event-Abteilung. Seine langjährige Erfahrung als Hotelmeister hilft uns jedes Jahr die beste Konferenz von allen die noch kommen werden zu veranstalten. Wenn er privat nicht mit seinen Kindern unterwegs ist, entspannt er am liebsten bei der Gartenarbeit oder beim Gitarrespielen.

Ungewöhnliche Überwachungen

Kuh auf WieseBei meinen Einsätzen als Consultant bei Netways bin ich oft bei Kunden vor Ort und darf mich immer wieder von der Unterschiedlichkeit der Monitoring Installationen überzeugen. Dabei fallen mir immer wieder kreative und ungewöhnliche Methoden auf neue Dinge zu überwachen. Über den Sinn und Unsinn dieser Checks darf zwar gerne gestritten werden, dennoch wollte ich euch ein paar Ideen nicht vorenthalten.

Check boss / Schwiegermutter

Dieser Check ist perfekt wenn du nicht von einem plötzlichen Besuch deines Chefs im Büro oder der Schwiegermutter zu Hause überrascht werden willst. Da heutzutage ja alle ein Smartphone mit sich herumtragen kann man einfach checken, ob bzw. auf welchem Accesspoint jemand eingeloggt ist um Frühzeitig über sein erscheinen informiert zu sein. Wie ich aus zuverlässiger Quelle gehört habe geht das zu Hause bequem mit einem Raspberry und einem Check, der den arp table überwacht. Im Unternehmen hat man häufig bessere Accesspoints, die per snmp auf angemeldete devices geprüft werden können. Hier kann man die Daten auch noch mit Geo Koordinaten versehen und anzeigen wo der Boss sich auf dem Betriebsgelände versteckt 😉

Check bitcoin/pool

In einem Unternehmen mit bitcoin affiner IT-Abteilung haben mehrere Admin’s zu Hause ein paar mining Server stehen. Hier hat es sich angeboten, die mining Rate mit check_btcpool zu überwachen und bei einem Abfall zu informieren.
Da hier sowieso schon gebastelt wurde haben die Herren gleich noch eine flotte Überwachung der bitcoin Kurse auf Basis der bitcoin.de API hinzugefügt. Bei Ausbruch aus einem bestimmten Korridor wird auch hier informiert.

Check bot

Überraschenderweise kann man sogar Pflanzen monitoren. Ein Botanik-Check überwacht EC, PH und Feuchtigkeit im Boden und setzt im Eventfall 5 Sekunden lang eine Pumpe in Gang die das Beet bewässert. Auf Grund der Langzeitdaten über EC und PH Wert kann man das Gießwasser mit Dünger und anderen Stoffen vorbehandeln und hat so eine perfekte Nährlösung. Allerdings ist die Ausrüstung hierfür wohl nicht ganz günstig. Das Ganze bietet sich also wohl nur für den professionellen Gemüsebauer an.

Check meat

In der Landwirtschaft geht es weiter. Der moderne Bauer hat schon einiges an IT bei sich herumstehen. Das Rind ist überwacht, der Biogastank blubbert. Doch wer überwacht die Überwacher dieser Prozesse? Natürlich Icinga. Neben der Überwachung der eigentlichen IT sowie der Melk und Futtersysteme bin ich hier auf die Idee gestoßen die Rinder mit Hilfe des maps moduls für icinga2 zu lokalisieren. Hierfür war es natürlich nützlich, dass alle Rinder ein RFID Halsband tragen und sich an den Trinkstellen selbst “anmelden”. Einer interessanter Einsatz des Netways Monitors war hier die Temperaturüberwachung der Ställe. Dabei ging es vor allem um ein Überschreiten der Temperatur im Sommer.

Wenn ihr noch ungewöhnliche Checks kennt oder eine irre Idee habt schreibt es gerne in die Kommentare.

Christoph Niemann

Autor: Christoph Niemann

Christoph hat bei uns im Bereich Managed Service begonnen und sich dort intensiv mit dem internen Monitoring auseinandergesetzt. Seit 2011 ist er nun im Consulting aktiv und unterstützt unsere Kunden vor Ort bei größeren Monitoring-Projekten und PERL-Developer-Hells.

How to: Icinga 2 – CA Proxy

Die in Kürze erscheinende Icinga-Version 2.8 erweckt den CA-Proxy zum Leben. Mit diesem Blogpost möchte ich nun zeigen, wie man dieses Feature verwendet und wozu es nützlich ist.

Was bringt der CA-Proxy?
Am besten ist dies anhand eines Beispiels zu erklären. Man nehme an, das Setup besteht aus einem Master, einem Satellite und mehreren Clients. Während der Einrichtung dieses Setups muss man bisher für jeden Client ein Ticket auf dem Master erstellen und eine direkte Verbindung zum Master haben, was nicht in allen Setups immer möglich oder einfach ist.

Der CA-Proxy ermöglicht es nun, Certificate-Signing-Requests nicht direkt an den Master, sondern an einen Satellite zu senden. Der Satellite leitet den Request dann an den Master weiter.

Mit Version 2.8 kommt zudem die Möglichkeit hinzu, ein Certificate-Signing-Request an den Master zu senden, ohne vorher ein Ticket zu erstellen. Diese Requests können danach am Master manuell beantwortet bzw. das Zertifikat signiert werden.

Durch die Kombination dieser beiden Features, muss weder der Master, noch ein Ticket im Node-Wizard angegeben werden. Firewalls, die den Master abschirmen, stellen hier auch kein Problem mehr da, solange der Client den Satellite erreichen kann.

Einrichtung eines Clients
Auf dem Client muss nun der Node-Wizard ausgeführt werden. Hier kann, wie vorher erwähnt, das Ticket einfach leer gelassen werden:

root@icinga-agent-1:~# icinga2 node wizard
Welcome to the Icinga 2 Setup Wizard!

We will guide you through all required configuration details.

Please specify if this is a satellite/client setup ('n' installs a master setup) [Y/n]: y

Starting the Client/Satellite setup routine...

Please specify the common name (CN) [icinga-agent-1]: [ENTER]

Please specify the parent endpoint(s) (master or satellite) where this node should connect to:
Master/Satellite Common Name (CN from your master/satellite node): icinga-satellite-1

Do you want to establish a connection to the parent node from this node? [Y/n]: y
Please specify the master/satellite connection information:
Master/Satellite endpoint host (IP address or FQDN): 10.211.55.23
Master/Satellite endpoint port [5665]: [ENTER]

Add more master/satellite endpoints? [y/N]: n
Parent certificate information:

Subject: CN = icinga-satellite-1
 Issuer: CN = icinga-satellite-1
 Valid From: Nov 8 11:37:56 2017 GMT
 Valid Until: Nov 4 11:37:56 2032 GMT
 Fingerprint: BA 1F 61 BE 26 8E CB 4E 8B 4D 20 3F 10 5B D5 0C C4 BF 91 00

Is this information correct? [y/N]: y

Please specify the request ticket generated on your Icinga 2 master (optional).
 (Hint: # icinga2 pki ticket --cn 'icinga-agent-1'): [ENTER]

No ticket was specified. Please approve the certificate signing request manually
on the master (see 'icinga2 ca list' and 'icinga2 ca sign --help' for details).

Please specify the API bind host/port (optional):
Bind Host []: [ENTER]
Bind Port []: [ENTER]

Accept config from parent node? [y/N]: y
Accept commands from parent node? [y/N]: y

Reconfiguring Icinga...

Done.

Now restart your Icinga 2 daemon to finish the installation!
root@icinga-agent-1:~# systemctl restart icinga2

 

Danach können wir auf dem Master über “icinga2 ca list” alle Requests anzeigen lassen:

root@icinga-master-1:~# icinga2 ca list
Fingerprint        | Timestamp                | Signed | Subject
-------------------|--------------------------|--------|--------
92a2e5bbb9b374f... | Nov  8 11:43:06 2017 GMT |        | CN = icinga-agent-1

 

Und mit “icinga2 ca sign <fingerprint>” signieren:

root@icinga-master-1:~# icinga2 ca sign 92a2e5bbb9b374f...
information/cli: Signed certificate for 'CN = icinga-agent-1'.

Nach einigen Minuten sollten die signierten Zertifikate auf den Clients landen. Hierfür ist kein Neustart nötig.

Noah Hilverling

Autor: Noah Hilverling

Nachdem Noah bei einer vierjährigen Exkursion nach Belgien seine Liebe zum Programmieren entdeckte, holte der gebürtige Euskirchener innerhalb kürzester Zeit gleich zwei Schulabschlüsse nach. Danach verließ Noah sogar den schönen Chiemsee, um sich ab September 2016 im Rahmen der Ausbildung zum Fachinformatiker für Anwendungsentwicklung bei NETWAYS voll und ganz dem Programmieren hinzugeben und viele unterschiedliche Erfahrungen zu sammeln. Wenn er mal nicht am Programmieren und Zocken ist, brettert er mit seinem Snowboard die Pisten runter, oder schwingt sich auf sein Mountainbike.

Replace spaces with tabs in Visual Studio 2017

Visual Studio has several source code edit settings. This defaults to 4 spaces and no tabs by default and is slightly different to what we use in Icinga 2. There we put focus on tabs in our code style.

Editing the Icinga 2 source code on Windows with Visual Studio requires adjusting the editor settings. Navigate into Tools > Options > Text Editor > C# and C++ and adjust the settings to “Keep tabs”.

I accidentally forgot to specify these settings for C# too, and had the problem that half of the Icinga 2 setup wizard code had 4 spaces instead of tabs. Luckily I’ve found this blog post which sheds some lights in the comments.

Hit Ctrl+H to open the replace search window. Tick the icon to use regular expressions and search for “((\t)*)([ ]{4})”. Add “\t” as replacement text.

Happy coding for Icinga 2 v2.8 – ready for OSMC 🙂

Michael Friedrich

Autor: Michael Friedrich

Michael ist seit vielen Jahren Icinga Developer und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht im Monitoring-Portal helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst das schöne Nürnberg. Oder - at an Icinga Camp near you 😉

Flapping in Icinga 2.8.0

The author viewing the code for the first time

Flapping detection is a feature many monitoring suites offer. It is mainly used to detect unfortunately chosen thresholds, but can also help in detecting network issues or similar. In most cases two thresholds are used, high and low. If the flapping value, which is the percentage of state changes over a set time, gets higher than the high threshold, it is considered flapping. It will then stay flapping until the value drops below the low threshold.

Naturally Icinga 2 had such a feature, just that it implemented a different approach and didn’t work. For 2.8.0 we decided it was time to finally fix flapping, so I went to investigate. As I said the flapping was working differently from Icinga 1, Shinken, etc. Instead of two thresholds there was just one, instead of one flapping value there were two and they change based on the time since the last check. Broken down it looks like this:

positive; //value for state changes
negate; //value for stable changes
FLAPPING_INTERVAL; //Compile time constant to smoothen the values

OnCheckResult() {
  if (positive + negative > FLAPPING_INTERVAL) {
    pct = (positive + negative - FLAPPING_INTERVAL) / FLAPPING_INTERVAL;
    positive -= pct * positive;
    negative -= pct * negative;
  }

  weight = now - timeOfLastCheck;
  if (stateChange)
    positive += weight;
  else
    negative += weight;
}

IsFlapping() {
  return 100 * positive / (negative + positive);
}

The idea was to have the two flapping values (positive & negative) increase one or the other with every checkresult. Positive for state changes and negative for results which were not state changes, by the time since the last check result. The first problem which arises here, while in most cases the check interval is relatively stable, after a prolonged Icinga outage one of the values could be extremely inflated. Another problem is the degradation of the result, in my tests it took 17 consecutive stable results for a flapping value to calm down.

After some tweaking here and there, I decided it would be wisest to go with the old and proven style Icinga 1 was using. Save the last 20 checkresults, count the state changes and divide them by 20. I took inspiration in the way Shinken handles flapping and added weight to the sate changes, with the most recent one having a value of 1.2 and the 20th (oldest) one of 0.8. The issue of possibly wasting memory on saving the state changes could be resolved by using one integer as a bit array. This way we are actually using slightly less memory now \o/

The above example would then have a value of 39.1%, flapping in the case of default thresholds. More details on the usage and calculation of flapping in Icinga 2 can be found in the documentation once version 2.8.0 is released.

Jean-Marcel Flach

Autor: Jean-Marcel Flach

Geboren und aufgewachsen in Bamberg, kam Jean (das "-Marcel" ist still) nach einem Ausflug an die Uni, als Azubi zu NETWAYS. Dort sitzt er seit 2014 im Icinga 2 core Entwicklungsteam.