Seite wählen

NETWAYS Blog

Tornado – Extend Icinga 2 for Active and passive Monitoring of complex heterogeneous IT Environments by Francesco Cina & Patrick Zambelli | OSMC 2019

This entry is part 3 of 4 in the series OSMC 2019 | Recap

 

At the Open Source Monitoring Conference (OSMC) 2019 in Nuremberg, Francesco Cina and Patrick Zambelli whirled up a „Tornado – Extend Icinga 2 for active and passive Monitoring of complex heterogeneous IT Environments”. If you missed their presentation: See the video of their introduction to Tornado and its use cases, and read a summary (below).

The OSMC is the annual meeting of international monitoring experts, where future trends and objectives are set. Since 2006 the event takes place every autumn in Nuremberg, Germany. Leading specialists present the full scope of Open Source monitoring and be ready to answer your hardest questions. Learn new techniques, exchange knowledge and discuss with top developers.

In-depth workshops the day prior to the conference and a Hackathon provide further possibilities to extend your skills and deepen your knowledge in IT monitoring and management.

The next OSMC takes place in 2021 in Nuremberg.
More information at osmc.de.


 

Tornado – Extend Icinga 2 for Active and passive Monitoring of complex heterogeneous IT Environments

Monitoring Challenges: Pool vs. Event.

First of all we have to explain the difference between Pool and Event approach. Icinga and nagios use the polling approach, which is scheduling monitoring or checks in a static time interval to get a specific state. You can derive from this state if the status from monitored device or service is critical or ok. That means, we know not only the results of monitoring but also the monitored systems. By Polling we have centralized configuration and control. This will be performed either agentless e.g. SHH, SNMP or through an agent for example Icinga, NSClient++.

Contrarily to this historical approach is the event based approach. On the one side we accept the matrix all the time from the remote system and we don’t know exactly what will come, but on another side we have to understand the incoming protocol and derive if there is a problem or not.

 

Advantages and disadvantages of polling and event:

Polling Pros

  • Control when a check should be executed
  • Get only the data which you are interested in
  • Knowing the context from the system you are interacting with (context = host, service, performance data)

Polling Cons

  • Static configuration for monitored architecture (not good for a changeable one e.g. micro services)
  • Continuously usage of resources day and night
  • Not all data is retrievable via polling

 

Event Pros

  • No delay to react when event happens
  • No need to know what to receive but understand it
  • Dynamic on fast changing architecture
  • Listen to channel => new added hosts are integrated

Event Cons 

  • Need to face large amount of data (peaks)
  • Lack for filtering at source. We can lose information specially when the protocol is not reliable e.g. UDP or SNMP
  • Risk to lose information
  • Not the right approach for host alive and service availability  

Combination of both Polling (Icinga 2) and event (Tornado) will definitive a winning:

With Icinga 2 we have the advantage to start a project very quickly and easily. We have a wide range of checks in the community. Through Templates we can create a reusable monitoring. We can adapt to changes in the architecture by interacting with CMDB or domain controller for example.

With Tornado we listen on the monitored host to the output of a service on a specific channel then we convert this output via collector to Json, which is the only recognized language by Tornado. After that we compare the flow with by regular expression created rules. In the end we forward an action to Icinga 2 – “Critical” for example. 

That means, when our infrastructure grows with new hosts we can monitor the availability from these hosts and their services with Icinga 2. We can control the output from services with Tornado.

 

How to handle the increased load?

01. Scale the monitoring system horizontally

When our servers and services grow, we can increase the number of monitoring instances. This is not good because it doesn’t work out of the box and too many problems will appear. Moreover the throughput does not go linearly. At a number of scaled nodes the overhead of communication and sycronization between them will take more time than analyzing the traffic itself.

02.  Use a big data system

We put a big data system between events and the monitoring system, for example kafka, spark, cassandra. The idea is, we reprocess the messages or the events and send only the important ones to the monitoring system. In this way we will reduce the flow against our monitoring system. This will definitely lead to reduce the load as well. It is a real solution but terribly expensive and needs a lot of knowledge with the used data system.

03. Tornado

Why is Tornado the solution?

  • Can handle millions of events per second per CPU
  • Stateless: the nodes don’t need to communicate to each other
  • Cloud-ready
  • Has collectors which translate events from format X to Tornado format (Json)
  • Take decision based on the event content
  • Cheap because it doesn’t need too much resources 

Tornado decides to pass the events to Icinga when they match the pipelines and the rules we defined in Tornado. Not suitable events will be dropped.

 

You liked this blog post and want to read more about different monitoring solutions? Then browse through our blog series, visit our YouTube channel or just contact us.

 

Afeef Ghannam
Afeef Ghannam
Support Engineer

Afeef hat seine Ausbildung Als Fachinformatiker in Richtung Systemintegration im Juli 2020 bei NETWAYS absolviert, seitdem unterstützt er die Kollegen im Support und bei der Betriebsunterstützung. Nach der Arbeit macht er gerne Sport, trifft Freunde oder mag es Filme zu schauen.

Cluster unter Proxmox virtual environment

Man kann aus verschiedenen Nodes ein Cluster aufbauen, so dass die Hochverfügbarkeit der Gäste und Lastverteilung gesichert ist (mindestens 3 Nodes werden empfohlen). Pve-cluster ist der wichtigste Service im Proxmox VE. Er ermöglicht den Zugriff auf Hauptkonfigurationsdateien bei jedem Node unter /etc/pve, deshalb muss dieser Service auch bei Single-Node-Installationen eingeschaltet sein, ansonsten funktioniert Proxmox VE nicht mehr. Die anderen zwei Services, pve-ha-lrm und pve-ha-crm, unterstützen pve-cluster. LRM steht für local resource manager, der die gewünschten Status aller lokalen Services unter /etc/pve/nodes/<nodename>/lrm_status liest und die entsprechenden Befehle an alle betroffenen Services schickt. CRM steht für „cluster resource manager“, der Entscheidungen über Cluster trifft. Er sendet Befehle zu allen LRMs, verarbreitet die Ergebnisse und schiebt VMs und Container zu einem anderen Node, falls etwas schief geht z.B ein Node ausfällt.

Anforderungen

  • Freigabe von UDP-Ports 5404 und 5405 für Corosync-Kommunikation auf allen Nodes

  •  Zeitsynchronisation

  • SSH tunnel auf port 22 für alle Hosts

  • Mit Hochverfügbarkeit sollte der Cluster aus mindestens drei Hosts aufgebaut werden

  • Eigenes Netzwerk für Cluster-Verkehr besonders mit der Nutzung von geteiltem Speicherplatz

  • Root-Passwort vom Cluster-Node um Nodes hinzufügen

Cluster erstellen

Nachdem ein eigenes Netzwerk für Cluster unter Node => Netzwerk eingerichtet wurde, kann man eine Cluster erstellen unter Datacenter => Cluster => Create Cluster. Link0 ist das Cluster-Netzwerk. Link1 ist für Netzwerk-Redundanz falls Link0 ausfällt oder umgekehrt. Gesetzte Priorität bestimmt welches Interface im normalen Fall aktiv ist.

Node zum Cluster einschließen

Vorsicht: Ein neuer Gast muss keine VMs haben, da alle Konfigurationen unter /etc/pvc überschrieben werden. Dies macht Proxmox VE als Schutzmaßnahme gegen Konflikt der Vms-IDs. Als Umweg muss ein Backup für VMs des neuen Nodes gemacht werden.

Vom Cluster-Node durch Datacenter => Cluster => Join Information, holt man Cluster-Information, die bei neuen Nodes gebraucht werden.
Wenn man bei einem neuen Node auf Datacenter=> Cluster => Join Cluster, geht und dann kopierte Informationen einfügt, werden Peer Address und Fingerprint automatisch befüllt. Root-Passwort des Cluster-Nodes und Link0 bzw. Link0 und Link1 müssen noch eingegeben werden.

Afeef Ghannam
Afeef Ghannam
Support Engineer

Afeef hat seine Ausbildung Als Fachinformatiker in Richtung Systemintegration im Juli 2020 bei NETWAYS absolviert, seitdem unterstützt er die Kollegen im Support und bei der Betriebsunterstützung. Nach der Arbeit macht er gerne Sport, trifft Freunde oder mag es Filme zu schauen.

Vom Messwert zur Alarmierung

Unternehmen können heutzutage gar nicht von Überwachungsmaßnahmen ihrer Umgebung entkommen, da wir als Menschen den aktuellen Stand von hunderten von Geräten nicht im Griff haben können. Deshalb werden Tools und Equipment im Überwachungsbereich dauernd entwickelt. Aus dem vorherigen erwähnten Bedarf möchte ich ein paar Informationen über zwei Geräte teilen und zwar AKCP sensorProbe2+ und SMSEagle.

AKCP sensorProbe2+

Das AKCP sensorProbe2+ ist ein Messgerät, an das verschiedene Arten von Sensoren angeschlossen werden können. Beispielhaft sind Bewegungs-, Gas-, Schall-, Temperatur, Feuchtigkeit- und Spannungssensoren. Stecken Sie einen beliebigen Sensor in die sensorProbe2+ und eine Autosense-Funktion erkennt den Typ und konfiguriert ihn automatisch. Standardmäßig hat das SP2+ die IP-Adresse 192.168.0.100. Es ist über einen Webbrowser konfigurierbar – sogar die IP-Adresse lässt sich ändern unter Einstellungen  => IP-Einstellungen. Aber der angeschlossene PC muss im gleichen Netz wie der SP2+ sein, um die Verbindung herstellen zu können. Das Gerät kann in einem beliebigen Intervall sowohl seine Verfügbarkeit als auch sämtliche Messwerte durch SMS, Mail oder SNMP Trap mitteilen.

SMSEagle

SMSEagle ist ein SMS Gateway, das SMS und Mails schickt bzw. empfängt. Mails können in SMS umgewandelt werden und umgekehrt. Darüber hinaus gibt es eine eingebaute Überwachungsfunktion, die die Verfügbarkeit von Geräten und Ports überprüft (ICMP, SNMP, TCP, UDP) und beim Ausfall eine SMS oder Mail sendet. SMS können sogar weitergeleitet werden mit Nutzung von Filtern oder ohne. Zusätzlich können wir eine automatische Antwortregel konfigurieren. LDAP-Autentifizierung kommt auch als Feature mit.

Kombination von beiden Geräten:

Beide Geräte müssen nicht im gleichen Netzwerk sein, sondern es reicht, wenn beide einander anhand von einem SMTP-Server sehen. SMSEagle besitzt sogar einen integrierten SMTP-Server, der dafür benutzt werden kann. Dessen IP-Adresse habe ich beim SP2+ eingetragen. SMSEagle akzeptiert nur Mails, die an ihn gesendet sind und lehnt den Rest ab. In SMSEagle muss “Mail to sms” Plugin aktiviert werden, um eingehende Benachrichtigungsmails von SP2+ in SMS zu wandeln und an die gewünschte Nummer zu senden. Im SensorProbe2+ muss man eine Mail-Aktion unter Hauptmenü erstellen, in dem man Zieltelefonnumme@SMSEgale-FQDN als Zielmail einträgt. Zieltelefonnummer könnte man durch gespeicherte Kontaktnamen im Telefonbuch vom SMSEagle ersetzen, wenn es keine Leerzeichnen enthält. SP2+ akzeptiert nur FQDN als Zieladresse. Deswegen muss man folgende Konfigurationseinträge durchführen plus einen DNS-Eintrag für SMSEagle :

[ NXS Geräte unter]
/etc/postfix/main.cf

[NPE Geräte unter]
/mnt/nand-user/postfix/etc/postfix/main.cf

1. folgende Zeile finden “myhostname = localhost.localdomain” und ändern in “myhostname = yourdomain.com”

2. Konfiguration von  Postfix reloaden
postfix reload

Wir können eine Testmail von SP2+ schicken und im Eventslog nachschauen, ob sie versendet werden konnte , oder ob es eine Fehlermeldung gibt. Außerdem können wir unter “notification rules” einstellen, bei welchem erreichten Schwellenwert eine Mail geschickt werden soll. Hier haben wir fünf einstellbare Schwellenwerte Normal, High Warning, High Critical, Low Warning und Low Critical. Wir können auf der anderen Seite in den Maillog von SMSEagle unter /etc/var/log/mail.info, in Systemlog oder unter Einstellungen => sysinfo nachschauen, ob die gesendeten Mails vom SP2+ angekommen sind und als SMS weitergeschickt wurden.

Man kann SP2+ mit Icinga 2 verbinden, wofür man lediglich das entsprechende Plugin benötigt: check_sensorProbe2plus

Ansonsten helfen wir bei Fragen rund um die Hardware von AKCP und SMSEagle gerne weiter – wir sind erreichbar per Mail oder telefonisch unter der 0911 92885-44. Wer uns gerne bei der Arbeit ein bisschen über die Schulter schauen oder den Shop und die angebotenen Produkte verfolgen möchte, kann uns seit kurzem auch auf Twitter folgen – über @NetwaysShop twittert das NETWAYS Shop Team!

 

 

Afeef Ghannam
Afeef Ghannam
Support Engineer

Afeef hat seine Ausbildung Als Fachinformatiker in Richtung Systemintegration im Juli 2020 bei NETWAYS absolviert, seitdem unterstützt er die Kollegen im Support und bei der Betriebsunterstützung. Nach der Arbeit macht er gerne Sport, trifft Freunde oder mag es Filme zu schauen.

Zentraler Director mit verschiedenen Director-Datenbank als Backend

Man kann von einem Director auf andere verschiedene getrennte Icinga-Umgebungen zugreifen und dorthin deployen, die auch mit Director gepflegt werden. In diesem Szenario haben wir unterschiedliche getrennte Masters. Allerdings ist dies fehleranfällig, da das falsche Director-Backend ausgewählt werden könnte und damit nicht in die gewünschte Umgebung konfiguriert wird. Deshalb stellt sich die Frage ” ist es nicht vernünftiger sich bei dem gewünschten Master einzuloggen und den lokalen Director zu benutzen? “. Meiner Meinung nach ist das richtig, aber ich will die Aufmerksamkeit an dieser Stelle auf die Vorzüge des Directors lenken. Vielleicht wird es in der Zukunft nützlich sein.

Was braucht man, um dieses Szenario umsetzen zu können?

Zuerst müssen wir dem lokalen Director Zugriff auf die entfernte Director-Datenbank erlauben. Zusätzlich brauchen wir einen Api-User, der den entfernten Icinga-Core ansprechen kann und uns remote deployment ermöglicht.

Unter /etc/icingaweb2/resources.ini tragen wir die entfernte Director-Datenbank ein:


[director_customer1]
type = "db"
db = "mysql"
host = "ip"
dbname = "director"
username = "username"
password = "password"
charset = "utf8"
use_ssl = "0"

Unter /etc/icingaweb2/modules/director/config.ini machen wir die neue Resource dem Director bekannt:


[db]
resource = "director_db" // unsere lokale Director-Datenbenk
resources = director_customer1, director_customer2  // Remote Director-Datenbank

So bekommen wir ein drop down menu oben rechts im Director-Interface. Wir können z.B director_customer1 auswählen und unter Icinga Infrastruktur => Endpoints überprüfen, ob der Api-User eingetragen ist. Ab diesem Moment können wir Konfigurationen auf dem entfernten Master verwalten, die Director spezifisch sind.

Afeef Ghannam
Afeef Ghannam
Support Engineer

Afeef hat seine Ausbildung Als Fachinformatiker in Richtung Systemintegration im Juli 2020 bei NETWAYS absolviert, seitdem unterstützt er die Kollegen im Support und bei der Betriebsunterstützung. Nach der Arbeit macht er gerne Sport, trifft Freunde oder mag es Filme zu schauen.

Podman vs Docker

Als ich über Podman las, habe ich mir immer die Frage gestellt, wieso hat Redhat ihr eigenes Projekt gestartet, das im Grunde wie Docker ist, anstatt Pull Requests mit Verbesserungen an das Docker Projekt zu schicken? Die Antwort erhielt ich mit der Geschichte von Skopeo.

Skopeo :

Skopeo ist die Inspiration und der Anfang von Podman. Skopeo bedeutet “Remote-Suchen” in der griechischen Sprache. Das Redhat-Team hat sich gefragt, wieso zuerst ein Image mit hunderten von MB von der Registery heruntergeladen werden muss, um nachschauen zu können, ob man das gewollte Image hat? Wenn ja, behält man es und wenn nein, schmeißt man es weg. Aufgrund dessen hat Redhat ein Pull Request an das Docker-Project geschickt. Das Docker-Team sich geweigert die Pull Request anzunehmen und hat gemeint, das schadet der API und dem CLI von Docker. Deshalb hat das Redhat-Team sein eigenes Tool entwickelt. So kamen Skopeo und die nachträglichen Gedanken vom Podman-Project zur Welt. Skopeo bot am Anfang die Möglichkeit die JSON Datei von einem Image herunterzuladen. Scopeo kann mittlerweile folgendes: Images pullen, pushen, kopieren zwischen Registeries ohne dazwischen lokal pullen zu müssen. Alles passiert ohne Root-Rechte.

$ mkdir fedora-24
$ skopeo copy docker://fedora:24 dir:fedora-24
$ tree fedora-24
fedora-24
├── 7c91a140e7a1025c3bc3aace4c80c0d9933ac4ee24b8630a6b0b5d8b9ce6b9d4.tar
├── f9873d530588316311ac1d3d15e95487b947f5d8b560e72bdd6eb73a7831b2c4.tar
└── manifest.json

Woher kommt der Name

Der Name Podman ist ein Kürzel für Pod Manager. Die Container-Orchestrierung Kubernetes hat den Begriff Pod geprägt. Er beschreibt eine Gruppe von Containern, die sich bestimmte Ressourcen teilen und nicht völlig isoliert voneinander laufen. Während Docker Pods nur indirekt über Kubernetes unterstützt wird, sind sie ein integraler Bestandteil von Podman. Eine Gruppe von – bedeutet “pod”, deshalb hat sich Redhat für drei Robben als Logo für Podman entschieden.

Ein Infra-Container verrichtet keine Arbeit, sorgt aber dafür, dass bestimmte Ressourcen des Pods wie Namespaces, CGroups und Netzwerk-Ports am Leben bleiben. Obwohl Podman dem Fork-Exec-Modell folgt und damit nicht als Server läuft, benötigen wir dennoch einen Prozess, der Container überwacht, um etwa Logs- und Exit-Codes zu sichern. Dies ist die Aufgabe von Conmon, ein kleines, in C geschriebenes Monitoring-Werkzeug, dass jedem Container angehängt wird. Neben dem Monitoring hält Conmon das Terminal des Containers offen, um per podman exec zu einem späteren Zeitpunkt das Terminal verwenden zu können.

Aus der Grafik ist ebenfalls die runc zu entnehmen. Runc ist für die Ausführung eines Container-Prozesses zuständig und implementiert die Runtime-Spezifikation der OCI (Open Containers Initiative). Redhat, IBM, Google, Microsoft, Docker und andere Unternehmen haben sich 2015 ausgetauscht und definiert ” was ein Image eines Containers bedeutet und wie dies ausschauen soll”. Den Konsens haben sie als Standards für den Image-Aufbau für die Industrie genommen und OCI (Open Containers Initiative) genannt.

mehr lesen…

Afeef Ghannam
Afeef Ghannam
Support Engineer

Afeef hat seine Ausbildung Als Fachinformatiker in Richtung Systemintegration im Juli 2020 bei NETWAYS absolviert, seitdem unterstützt er die Kollegen im Support und bei der Betriebsunterstützung. Nach der Arbeit macht er gerne Sport, trifft Freunde oder mag es Filme zu schauen.

Veranstaltungen

Di 27

GitLab Training | Online

Oktober 27 @ 09:00 - Oktober 28 @ 17:00
Di 27

Graylog Training | Online

Oktober 27 @ 09:00 - Oktober 28 @ 17:00
NETWAYS Headquarter | Nürnberg
Nov 04

Vorstellung der Monitoring Lösung Icinga 2

November 4 @ 10:30 - 11:30
NETWAYS Headquarter | Nürnberg
Nov 24

Elastic Stack Training | Online

November 24 @ 09:00 - November 26 @ 17:00
Dez 01

Foreman Training | Nürnberg

Dezember 1 @ 09:00 - Dezember 2 @ 17:00
NETWAYS Headquarter | Nürnberg