Das neue User Interface von Icinga DB

Während mit Icinga DB sehr viel unter der Haube passiert ist, kommt mit dem Release auch ein rundum neu geschriebenes Monitoring Modul für Icinga Web 2. In diesem Zuge erhielt auch das User Interface ein ausführliches Redesign. In diesem Blogpost werden die wichtigsten Änderungen erklärt.

Listen

Wie im bewährten Monitoring Modul gibt es im Monitoring Modul für Icinga DB viele Listenansichten. Daher wurden diese komplett überarbeitet. Allen Listenelementen liegt eine grundlegende einheitliche Anatomie zugrunde.

ListItem Anatomy.jpg

Anatomie eines Listenelements

Visual

Für jedes Listenelement wird ein so genanntes Visual verwendet. Dieses dient dazu, in langen Listen bestimmte Elemente hervorzuheben bzw. einen intuitiven Überblick geben, welchen Zustand das zugrunde liegende Objekt hat. Bei Host- bzw. Servicelisten wird dadurch beispielsweise der State dargestellt. So wird in der Übersicht unmittelbar ersichtlich, bei welchen Objekten Probleme vorliegen.

Title

Der Titel beschreibt ergänzend kurz zusammengefasst den Zustand des Listenelements. So enthält er beispielsweise die Info, dass ein Host gerade Down ist. Während das Visual einen intuitiven Eindruck gibt, erklärt der Titel, was genau passiert ist.

Meta

Der Metabereich ist für zusätzliche Informationen vorgesehen. In der Regel werden hier Zeitangaben des Listenelements angezeigt. In Host und Servicelisten steht hier, wie lange sich das Objekt bereits im entsprechenden Zustand befindet.

Caption

Der Caption-Bereich enthält detaillierte Informationen zum Listenelement. Dies kann im Falle von Hosts und Services der Plugin Output sein. Bei Kommentaren und Downtimes werden hier die Kommentartexte des Users angezeigt. Um die Listendarstellung kompakt und einheitlich zu halten, werden lange Texte auf eine oder mehrere Zeilen gekürzt.

Klickbare Elemente

Viele der Listenelemente enthalten neben dem Hauptelement zwei oder mehrere klickbare Elemente. Alle Teile des Listenelements, die auf weitere Detailinformationen verweisen sind eindeutig hervorgehoben. Dadurch ist sofort erkennbar, hinter welchen Textteilen sich Zusatzinformationen befinden.

Overdue Checks in Host- und Service Listen

In Host und Servicelisten werden Overdue Checks nun besonders auffällig hervorgehoben. Dadurch ist auf den ersten Blick sofort ersichtlich, welche Objekte möglicherweise nicht mehr aktuell sind.

Artboard Copy.jpg

Das neue Icinga DB Design: Hostliste und Detailbereich

Detailgrad der Listenansichten wählen

Der Detailgrad der Host- und Servicelisten ist nun wählbar. Die Standardansicht zeigt den Titel und einen zweizeiligen Plugin Output. In der detaillierten Ansicht wird der gesamt Plugin Output angezeigt. Will man einen größeren Überblick bekommen gibt es außerdem die Minimalansicht. Hier wird in einer Zeile der Plugin Output angeschnitten, wenn genügend Platz vorhanden ist. Dafür sieht man auf einem Bildschirm wesentlich mehr Listenelemente als in den anderen Darstellungen.

State Change Visual in History- und Notification Elementen

In History und Notification Listen sind unter anderem Statewechsel-Elemente zu finden. Hier wird im Visual der Wechsel nun auf den ersten Blick deutlich gemacht. Neben dem aktuellen State wird gleichzeitig auch der vorherige State ersichtlich.

State Changes sind in den Notificationlisten nun besser ersichtlich.

Detailansichten

Optimierte Headerbereiche

Die Headerbereiche der einzelnen Objekttypen erhalten ein neues Design. Während die herkömmlichen Headerbereiche sehr viel Platz brauchten, sind die Informationen kompakter.

Graphen

Die Detailansichten der Elemente waren bisher sehr textlastig. Nach dem Redesign sind die Detailbereiche deutlich visueller angelegt. Nun werden anstatt der bloßen Auflistung Informationen kombiniert und Zusammenhänge dargestellt.

Modaldialoge für schnelle Aktionen

Wollte man bisher aus dem Detailbereich einen Kommentar anlegen oder eine Downtime setzen wurde der Dialog in einer weiteren Spalte angezeigt, so dass die Inhalte der linken Spalte verloren gingen. Im neuen Monitoring Modul gibt es nun ein Modal-Element für kurze Interaktionsdialoge. Für Aktionen im Detailbereich erscheint nun ein Modaldialog. Dadurch bleibt die linke Listenspalte und somit der Kontext besser erhalten.

 

Florian Strohmaier
Florian Strohmaier
UX Designer

Mit seinen Spezialgebieten UI-Konzeption, Prototyping und Frontendentwicklung unterstützt Florian das Dev-Team bei NETWAYS. Trotz seines Design-Backgrounds fühlt er sich auch in der Technik zuhause. Gerade die Kombination aus beidem hat für ihn einen besonderen Reiz.

OpenStack made easy… Mit Icinga 2-Master Maschinen überwachen

This entry is part 2 of 4 in the series OpenStack made easy

Mit unserer OpenStack Cloud ist es kinderleicht seine eigene Umgebung nach eigenen Vorstellungen aufzubauen. Schnell und einfach mittels Terraform einige Maschinen starten, per angehängter Floating IP und zugehöriger Security Group den Dienst für die Außenwelt verfügbar machen und schon läuft das Projekt.

Aber keine Umgebung läuft fehlerfrei und Monitoring ist ein großes Thema – man merkt gerne vor seinen eigenen Benutzern, oder Kunden, wenn einmal etwas nicht ganz so funktioniert wie es soll. Ich denke jedem Leser dieses Blogs ist zum einen die Wichtigkeit eines Monitorings bewusst aber auch die Auswertung von Performancedaten wichtig. Wie überwache ich nun unkompliziert meine OpenStack Umgebung, vor allem wenn meine Server von der Außenwelt gar nicht erreichbar sind? Wir haben da mal etwas vorbereitet!

Neben unserem IaaS Angebot stellen wir – wie sicherlich bekannt – auch diverse SaaS Lösungen bereit. Darunter auch die App Icinga 2 Master, mit welcher man binnen weniger Minuten einen vollständigen Icinga 2 Master, mitsamt Graphite und Grafana erhält.

Ist dieser erstmal gestartet, findet man nach dem Login unter dem Reiter “Agenten hinzufügen” – oder je nach Browsersprache auch “Add Agent” – diverse Integrationsskripte für unterschiedliche Betriebssysteme.

Diese lädt man einfach nach Anleitung auf den Server, führt es aus und schon ist der Server an den Icinga2 Master angebunden.

server01:~# chmod +x createHost.sh; ./createHost.sh

Alles wichtige wird hier automatisiert. Per default werden einige Checks direkt mit angelegt und mithilfe des Directors ist es auch einfach weitere Checks für seine Hosts zu verteilen. Auch die API des Directors kann direkt angesprochen werden, es sind einem fast keine Grenzen gesetzt. Zusätzlich findet man noch einige Graphen zu den Performancedaten des angebundenen Agents direkt beim jeweiligen Check. Damit können nicht nur Probleme erkannt werden, sondern auch Trends werden direkt visualisiert. Diese Daten werden wohlgemerkt bei unseren Paketen ein Jahr vorgehalten um auch eine Langzeitübersicht zu gewährleisten.

Der erste Monat des Icinga 2 Masters ist außerdem kostenlos – ein Test lohnt sich. Unser MyEngineer hilft auch gerne bei der Einrichtung!

Fabian Rothlauf
Fabian Rothlauf
Senior Systems Engineer

Fabian kehrte nach seinem fünfjährigen Ausflug nach Weimar zurück in seine Geburtsstadt Nürnberg und hat im September 2016 bei NETWAYS als Systems Engineer im Hosting Support angefangen. Der Mopsliebhaber, der schon seit seinem 16. Lebensjahr ein Faible für Adminaufgaben hat, liebt außerdem Grillen, Metal und Computerspiele. An seinem Beruf reizt ihn vor allem die Abwechslung, gute Weiterentwicklungsmöglichketen und dass es selten mal einen Stillstand gibt. Nachdem er die Berufsschulzeit bereits mit Eric und Georg genießen...

OSMC 2019 – Day 2

OSMC Logo
The social event yesterday evening was a blast and the late lounge afterwards also a must. So while some were still recovering, the room for the first talk was already quite full. This showed the interest in Jochen Kressin‘s talk about “Zero Trusted Networks – why Perimeter Security is dead”. He explained the (old) assumption of perimeter security “I am behind a firewall, so my traffic is secure” and asked the question if this is still true. Showing examples proving it is not true anymore because if it would be, none of these data breaches would have been happen. He explained what has changed in the last years leading to “Zero Trusted Networks” where every system has to be treated as untrusted and how to adopt for it. As one of the developers he used Search Guard as example which adds security to Elasticsearch, one of the great tools that had no security by itself for a long time, being not ready for the zero trusted approach.
Zero Trusted NetworksFluentD
Toshaan Bravani was talking about “Monitoring your Logs with Fluent”. FluentD and the client component FluentBit is an alternative to Logstash I see more and more at customer environments, so I was happy to get a deeper look into it. In addition he showed the complete tool stack to get most out of your data and the automation used to get it up and running.

Open Source landscape for APM
Third one for today was “Improved Observability Using Automated, OpenCensus-based Application Monitoring Solutions” by Tobias Angerstein. He started with a nice overview of the Open Source landscape for Application Performance Management before focusing on inspectIT. Its latest incarnation inspectIT Ocelot focuses on Open Standards like Open Metrics, Open Tracing and Open Census which are forming a new one called Open Telemetry which allows integration with all the well-known tools like Telegraf, Prometheus, Grafana. It also provides End User Monitoring using Boomerang, a javascript agent, and an EUM Server which transforms data to the Open Standards. In his demo he showed the capability of it and my only thought was how helpful something like this would have been to me in my early IT days being a Java developer.

Afterwards we could enjoy another great lunch break and perhaps also an massage, before starting into the afternoon sessions.
Lunch breakLunch BreakLunch Break

Database observability
Charles Judith gave a talk about “How to improve database Observability”. In his job he is responsible for reliability of the company’s databases and told the crowd the problems he started with like having no backup and monitoring at all. So it was his personal goal to have no hidden issues anymore and get transparency into their environment. His way from zero to hero was quite interesting and he compared it with a roller coaster. In the end having metrics to tell users that they are right or wrong with their feeling of the database is slow and having logs and monitoring telling were the real problem lies instead of guessing has improved his daily work already. But he still has some more steps to do like publishing SLA. The WIP version of his toolkit can be found on Github.

Why BOFH is toxic
Second last one I attended was Jan Doberstein with a non technical talk about behaviour and how it influences your daily life and work, titled “Idiot! – or: Why BOFH is toxic”. He touched the same topic like the open discussion yesterday and I think it is great to get people think about and reflect their behaviour. While most of his examples were matched to the crowd and perhaps people working in IT do communicate much more in electronic fashion than others, it is a topic that everyone should care about.

High available setup
Last but not least Marcel Weinberg showed the high available setup he built for Digital Ocean. He included some very helpful small tips and tricks to increase performance and avoid pitfalls while diving deep into the configuration. Indeed it were too much for me to list them all here.

Pictures are taken again from the OSMC stream at Twitter, thanks to everyone for sharing their impressions. I hope everyone enjoyed the conference like I did. Thanks to everyone who made OSMC such a great experience again this year, starting with my colleagues organizing the event, the sponsors and speakers but this includes every attendee forming this nice community. Save travels for everyone leaving today or see you tomorrow if you join the Hackathon or Open Source Camp on Foreman. I hope I will see everyone next year at the same place on November 16th to 19th for OSMC 2020 or in Amsterdam for IcingaConf on May 12th to 14th.

Dirk Götz
Dirk Götz
Principal Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.

OSMC 2019 – Day 1

OSMC Logo
As always OSMC started with the workshop day. This time the topics were Prometheus given by Julian Pivotto, Gitlab by Michael, Terraform by Lennart and Foreman by me. After the workshops with coming together for dinner and some drink social networking started, one of things I enjoy most at conferences nowadays.

Day one started also like every time with a warm welcome from Bernd. Quite unexpected for me was the high number of first time attendees who raised hands when Bernd asked. It is always great to see new faces!

Ansible module planned to be released
First talk I attended was “Directing the Director” by Martin Schurz who gave some insights in how the monitoring platform developed at T-Systems Multimedia Solutions GmbH over last years. So they scaled up from single system, solved migration from VMs to Docker of the monitored environment and built knowledge to provide consulting to the teams which run 94 different projects which have to be monitored. With so many different things to monitor the next step of course was automation where all the good from Icinga-Director-API and Ansible came together. But if it is easy for users to build monitoring objects, configuration will grow which comes with the next challenges to make it even more easy and error prove. And from what Martin showed they solved it in a good fashion, but future will tell and I hope he will give another talk providing an update in the future.

Crowded room at OSMC
Second one was Christian with “Windows: One Framework to Monitor them all” who introduced his precious to the crowed. If you could not make it into the crowded room or was not at OSMC at all, have a look at the documentation or the framework itself, the plugins, the kickstart script to get it up and running the background daemon. In a great live demo he showed all the components and explained them in depth. While it is still the first release candidate it looks very promising.

Marcelo Perazolo from IBM Systems was talking about “Monitoring Alerts and Metrics on Large Power Systems Clusters”. He started with an introduction to the Power architecture and the workloads it is specially useful to make everyone familiar with it. The example he used was a big one, the Summit supercomputer. The main topic were two projects CRASSD and Power-Ops which not bring the data from some systems not everyone is familiar with to commonly used tools but also include Ansible playbooks for automation and flexibility “instead of just providing a docker container”. The demo showed some Kibana dashboards which provided in-depth data summarizing the health and performance of Power Systems starting from firmware to service running on it.
Power architecture explainedDesert

Lunch was great as always (and not only the dessert) and to avoid food coma we had the first time ignite talks at OSMC. It started with one from the conference sponsor ilert. Afterwards Blerim talked about “How Observability is not killing Monitoring” where he concluded that Observability should be an addition to Monitoring and not a replacement. Toshaan Bharvani decided for an ignite when sitting in the talk about Power Systems and wanted to add about “Building your own Datacenter” based on OpenPower and software available for it. In his talk “Overengineering your personal website” Bram Vogelaar showed a good (and funny) example where adding things to your infrastructure can escalate.

New entry in the datalist
Marianne Spiller‘s talk “Lorem Icinga puppetdb director amet” was not only a must see because its creative title, but because I like the mix of humor and technical knowledge she always provides. With practical examples she showed the problems of manual work like lazy admins prefer introducing a “Not answered” to the datalist of operating systems instead of maintaining the information on hosts. So instead of a form manually filled by admins she ended using the import from PuppetDB to create monitoring objects based on facts of the system.

Grafana Loki demo
Directly from Grafana Labs represented by Ganesh Vernekar the audience got some news about Loki which is “Like Prometheus, but for Logs”. So Loki avoid huge indexes and allows for better scaling by not indexing log lines but grouping them to streams. Using a similar format to Prometheus it allows to get metrics and logs for a system without a context switch. Running Loki to get this seems quite simple and flexible with only one binary which can scale out easily and also allows for a microservice infrastructure.

First code improvement
“Fast Logs Ingestion” by Nicolas Fränkel showed common coding mistakes and how to avoid them to get better logging in your application. He also covered topics like metadata and searching logs which also should also influence decisions and code. Structured log data even not written to file are also a option to consider like config reload during runtime to enable the user to switch loglevel without downtime. In the end he hopes people take away from his talk that everyone from dev and ops to architects should keep in mind which trade-off between speed and reliability has to be done and why.

Like every year the “Current State of Icinga” by Bernd was held in front of full house. He started with a short introduction to Icinga including the workflow which results in “Icinga makes you happy”. Icinga Workflow Afterwards to start with technical things he looked into the big changes Icinga 2.11 brought with a new network stack, high availability for more features and a new process handling not only helping with containers. Icinga 2.7 brought more translations, markdown support, jQuery 3, modernized styling for forms and lists, color blind theme and improvements for module developers. The vSphere module provides now an Import Source for Director, no code depenency on the Director and some UI improvements. The latest version of Director has also more translation, support for scheduled downtimes and sync previews. The BP Modelling (formerly Business Process Modul) has now drag & drop, export and import and breadcrumbs to make the UI more usable. As the first new feature he introduced the Windows monitoring Christian gave a detailed talk earlier today. Icinga for AWS was an improvement to the one only providing a simple import source for Director which adds support for multiple sources, some property modifiers and sync previews. Icinga Module for Jira includes an Issue overview, Jira notification via Director integration and custom workflows you can create from Icinga Web 2. Icinga DB as replacement for IDO is decoupling status and historic data using Redis and in a demo the new monitoring module based on it was also shown including all the visual improvements. Pull requests are already merged and will be part of the next releases and new things are available separately. The next update you can get on IcingaConf in Amsterdam on May 12 – 14, 2020.

As last topic a open discussion about Code of Conducts suggested and moderated by Stefan Lange took place.

Pictures are taken from several twitter users tagging them with OSMC. Thanks for providing them, expect some better ones from my colleagues from the events and marketing teams. I hope you enjoyed my report for day 1 while I am heading over to the social event at the Loftwerk and try to have at least a short talk to everyone. Day 2 will be covered tomorrow evening.

Dirk Götz
Dirk Götz
Principal Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.

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
Junior Consultant

Afeef macht seit September 2017 eine Ausbildung zum Fachinformatiker für Systemintegration bei NETWAYS. Nachdem der gebürtige Syrer erfolgreich Deutsch gelernt hat, stellt er sich jetzt der Herausforderung Programmiersprache. Neben der IT schätzt er vielfältiges Essen. Sein Motto lautet يد واحدة لا تصفق لوحدها , was so viel bedeutet wie „Eine Hand wird nie allein klatschen“.

Verstärkte Zusammenarbeit mit Icinga

Wir sind stolz darauf, Ihnen mitteilen zu können, dass icinga.com nun auch Hardware-Integrationen zur Überwachung von Umgebungssensoren und zur Alarmierung per SMS anbietet. Die Geräte der unter Icinga Integrations aufgeführten Hersteller können mit Hilfe von Plugins, die auf Icinga Exchange verfügbar sind, problemlos in Ihr Icinga-Monitoring integriert werden.

 

Alarme per Text Message

Grundsätzlich gibt es zwei Arten von Geräten, die sich am besten für die Integration mit Icinga eignen. Die erste Gruppe davon sind Gateways für den Versand von SMS als Alarmmeldungen. Diese Gateways arbeiten mit Standard-SIM-Karten und können auf Bändern in 4G-, 3G- und 2G-Netzen betrieben werden. Diese Geräte bieten auch mehr Funktionalität als nur das Senden von Nachrichten: Sie sind auch in der Lage, SMS in E-Mail zu konvertieren oder umgekehrt sowie Filter und Routing für das Senden von Nachrichten an nur eine bestimmte Person oder Personengruppe anzuwenden (Telefonbuchfunktion). Darüber hinaus verfügen die Gateways über einen eigenen Monitoring-Server, so dass sie z.B. bei einem Verbindungsabbruch zum Netzwerk automatisch Benachrichtigungen senden können.

Um diese Gateways reibungslos in die eigenen Produktionsprozesse einzubinden, gibt es z.B. Plugins für die direkte Verbindung zu Ihrem Microsoft Exchange zur vollumfänglichen Nutzung der E-Mail zu SMS Konvertierung. Integriert in Icinga 2 können Sie nicht nur das Gerät selbst überwachen, sondern es auch nutzen, um von Icinga generierte Benachrichtigungen weiterzuleiten. Die beiden Haupthersteller dieser Gateways sind Braintower mit Sitz in Deutschland und SMSEagle mit Sitz in Polen.

 

Monitoring Ihrer Umgebung

Die zweite Art von integrierbaren Geräten ist hauptsächlich für die Messung und Überwachung bestimmt. Diese bestehen meist aus einer Basiseinheit und mehreren Ports für den Anschluss von Sensoren. Die Basiseinheiten können entweder direkt über LAN oder bei entfernten Standorten über GSM kommunizieren. Für eine vollständige Umgebungsüberwachung gibt es eine Vielzahl von Sensortypen, die angeschlossen werden können:

  • Temperatur
  • Luftfeuchtigkeit
  • Kombination von Temperatur und Luftfeuchtigkeit
  • Luftdruck
  • Luftstrom
  • Spannung
  • Wasser und Leckagen
  • Rauch und Gas
  • Pegelstände von Flüssigkeiten
  • Bewegung, Vibration und Öffnen von Türen

Die wichtigsten Hersteller für Messgeräte sind derzeit AKCP, GUDE, HW group und Tinkerforge. Für all diese finden Sie Monitoring Plugins auf Icinga Exchange. Insbesondere der Hersteller GUDE bietet auch Steckdosenleisten an, die nicht nur die Spannung überwachen, sondern auch Stecker und Geräte remote steuern können.

 

Integration von Tinkerforge mit Icinga

Um genauer anzuschauen, wie diese Geräte in Icinga 2 integriert werden können, ist Tinkerforge eines der besten Beispiele. Das gesamte Plugin-Projekt ist unter https://exchange.icinga.com/netways/check_tinkerforge zu finden und zeigt nicht nur die Integration, sondern bietet auch einen Einblick in die Funktionalitäten des Gerätes.

Für die Verwendung des check_tinkerforge Plugins ist es erforderlich, Python 2.7+ auszuführen und die tinkerforge Python-Bibliothek von Pypi installieren zu lassen. Danach erfolgt die Installation mit pip install tinkerforge und das Verschieben des Plugins in die Icinga PluginDir Position.

Lassen Sie uns nun einen Blick auf die Optionen des Plugins werfen:

$ ./check_tinkerforge.py --help
usage: check_tinkerforge.py [-h] [-V] [-v] -H HOST [-P PORT] [-S SECRET]
[-u UID] -T TYPE [-w WARNING] [-c CRITICAL]
[-t TIMEOUT]
optional arguments:
-h, --help show this help message and exit
-V, --version show program's version number and exit
-v, --verbose
-H HOST, --host HOST The host address of the Tinkerforge device
-P PORT, --port PORT Port (default=4223)
-S SECRET, --secret SECRET Authentication secret
-u UID, --uid UID UID from Bricklet
-T TYPE, --type TYPE Bricklet type. Supported: 'temperature', 'humidity', 'ambient_light', 'ptc'
-w WARNING, --warning WARNING Warning threshold. Single value or range, e.g. '20:50'.
-c CRITICAL, --critical CRITICAL Critical threshold. Single vluae or range, e.g. '25:45'.
-t TIMEOUT, --timeout TIMEOUT Timeout in seconds

 

Da das TinkerForge-Gerät Sensoren für Temperatur oder Luftfeuchtigkeit sowie andere Typen unterstützt, müssen wir mit dem Operator -T oder --type angeben, welcher Sensor überprüft werden soll:

check_tinkerforge.py -H 10.0.10.163 -T temperature -w 23 
WARNING - Tinkerforge: Temperature is 24.75 degrees celcius|'temperature'=24.75

Wenn Sie mehrere Sensoren eines Typs haben, müssen Sie die UID mit dem Operator -u oder --uid angeben, um den betreffenden Sensor korrekt zu identifizieren. Darüber hinaus können Schwellenwerte entweder als Einzelwerte oder Wertebereiche und mit den üblichen Operatoren für warning und critical angegeben werden.

Um die Sensoren in Ihre Icinga 2-Konfiguration zu integrieren, müssen Sie wie bei anderen Check-Plugins ein CheckCommand Objekt erstellen. Das Gerät selbst wird als Host Objekt angelegt und alle Sensoren sollten mit einem apply Service versehen werden. Zusätzlich finden Sie hier eine Beispielkonfiguration für TinkerForge. Dieses Beispiel kann direkt verwendet werden, es ist nur notwendig, die Parameter zu ändern und, falls Sie mehrere Sensoren eines Typs haben, die UIDs hinzuzufügen.

Alle in diesem Blogbeitrag genannten Hersteller finden Sie auf der Website der Icinga integrations mit Informationen über die Unternehmen, die Geräte und die Links zu den entsprechenden Monitoring-Plugins sowie in unserem Online Shop.

Nicole Frosch
Nicole Frosch
Sales Engineer

Ihr Interesse für die IT kam bei Nicole in ihrer Zeit als Übersetzerin mit dem Fachgebiet Technik. Seit 2010 sammelt sie bereits Erfahrungen im Support und der Administration von Storagesystemen beim ZDF in Mainz. Ab September 2016 startete Sie Ihre Ausbildung zur Fachinformatikerin für Systemintegration bei NETWAYS, wo sie vor allem das Arbeiten mit Linux und freier Software reizt. In ihrer Freizeit überschüttet Sie Ihren Hund mit Liebe, kocht viel Gesundes, werkelt im Garten, liest...