Icinga for Windows 1.0 – Eine neue Ära

Seit heute ist der erste offizielle, stabile Release des Icinga für Windows Pakets in Version 1.0 verfügbar. Das Paket besteht aus drei individuellen Komponenten – dem Icinga PowerShell Framework, dem Icinga PowerShell Service und den Icinga PowerShell Plugins. In Kombination bilden sie den Grundbaustein für die künftige Überwachung von Windows Systemen – inklusive Software, Hardware und alles was dazugehört.

Neben der klassischen Überwachung der Windows Systeme geht das Framework aber noch einen Schritt weiter: Mit über 200 Cmdlets wird nicht nur das Monitoring an sich sichergestellt, sondern auch das Deployment der einzelnen Komponenten inklusive Icinga 2 Agent. Darüber hinaus wird die Verwaltung des Agents, die Konfiguration, aber auch das Troubleshooting auf Windows System deutlich vereinfacht: Für die gängigsten Befehle wurden Wrapper-Cmdlets entwickelt, mit denen neben dem Logfile-Tracing auch Features aktiviert und deaktiviert werden können, Icinga 2 Objects auslesbar und durchsuchbar gemacht wurden oder die Funktionsfähigkeit der Icinga 2 Installation auf dem lokalen System überprüft werden kann.

Vereinfachte Installation

Folgt man der Installationsanleitung, dann stellt man fest, dass die meisten Schritte vereinfacht über einen Installations-Wizard durchgeführt werden können. Der große Vorteil dabei ist, dass die Grundinstallation nur auf einem System vollständig manuell durchgeführt werden muss. Ist der Wizard erst einmal durchgeklickt, erhält man einen Konfigurations-String, der auf einem anderen System einfach ausgeführt werden kann, nachdem dort das Framework über den Kickstart installiert worden ist. Somit ist der künftige Rollout der Systeme einfacher denn je.

Standardisiertes Monitoring

Plugins bieten die Möglichkeit, schnell und effizient einzelne Komponenten zu überwachen. Die Schwierigkeit liegt darin, den Output der Plugins richtig zusammen zu bauen und Performance-Metriken sauber zu kapseln. Zum Schluss bleibt dann nur noch das Einpassen in das standardisierte Threshold-Verhalten der Icinga Plugins sowie die Ausführung der bekannten Prüfung, ob ein Wert nun Ok, Warning, Critical oder vielleicht doch Unknown ist.

All das wird mit dem Icinga PowerShell Framework deutlich vereinfacht, denn es werden einige Funktionen bereitgestellt, die sich genau um diese Tasks kümmern. Am Ende des Tages holt man sich einfache seine Daten über PowerShell Cmdlets und packt diese in ein Icinga Check-Objekt. Mit den Informationen, die das Objekt erhält, kann anschließend geprüft werden, welchen Status das Objekt hat und mittels einem Check-Result Objekt in ein gültiges Icinga 2 Format gebracht werden. Der Output ist anschließend für alle Plugins standardisiert.

Zeitintervall-Metriken

In der Vergangenheit lag der große Vorteil von Lösungen wie NSClient++ darin, dass diese als Dienst gestartet werden konnten und dabei Metriken gesammelt haben. Hierdurch konnte man auch auf Windows beispielsweise die CPU-Load in Intervallen von 1, 3, 5 und 15 Minuten in den Performance-Daten abbilden. Installiert man das PowerShell Framework als Dienst, ist dieser Zustand für jedes Plugin ebenfalls abbildbar. Hierfür ist lediglich der Background-Daemon für den Service Check mittels

Register-IcingaBackgroundDaemon -Command ‘Start-IcingaServiceCheckDaemon’

zu registrieren. Anschließend können einzelne Service-Checks für die regelmäßige Ausführung konfiguriert werden. Möchte man für die CPU-Load alle 30 Sekunden Metriken für die Intervalle 1, 3, 5 und 15 Minuten sammeln, registriert man den Service-Check entsprechend

Register-IcingaServiceCheck -CheckCommand ‘Invoke-IcingaCheckCPU’ -Interval 30 -TimeIndexes 1, 3, 5, 15;

Anschließend startet man den PowerShell Dienst neu und erhält alle Metriken in den gewünschten Intervallen:

Administrationsunterstützung

Wer den Icinga 2 Agent auf Windows administriert, muss auch hier öfter einmal die Konsole zur Hand nehmen und das Icinga 2 Binary mit diversen Befehlen starten. Das PowerShell Framework bietet auch hierfür einige Lösungen, da – wie bereits erwähnt – gängige Befehle in einem Wrapper-Cmdlet hinterlegt sind. Ein einfaches Parsen und stetiges Lesen der Logfiles erfolgt damit über einen einzigen Befehl – ohne am Ende in das Icinga Verzeichnis navigieren oder die Logdatei suchen zu müssen:

PS> Use-Icinga; Read-IcingaAgentLogFile
[2020-02-19 14:40:31 +0100] information/RemoteCheckQueue: items: 0, rate: 0/s (6/min 30/5min 90/15min);
[2020-02-19 14:40:41 +0100] information/RemoteCheckQueue: items: 0, rate: 0/s (12/min 60/5min 180/15min);

Sucht man mittels icinga2 object list nach bestimmten Check-Commands oder generellen Einträgen, gibt es auch hierfür eine elegante Lösung:

PS> Use-Icinga; Find-IcingaAgentObjects -Find ‘*CheckMemory*’
Line #4948 => “Object ‘Invoke-IcingaCheckMemory’ of type ‘CheckCommand’:”
Line #4950 => ” * __name = “Invoke-IcingaCheckMemory””
Line #4955 => ” * value = “Use-Icinga; exit Invoke-IcingaCheckMemory””
Line #4958 => ” * value = “$IcingaCheckMemory_String_CriticalBytes$””
Line #4961 => ” * value = “$IcingaCheckMemory_Object_CriticalPercent$””
Line #4964 => ” * set_if = “$IcingaCheckMemory_Switchparameter_NoPerfData$””
Line #4967 => ” * value = “$IcingaCheckMemory_Int32_Verbosity$””
Line #4970 => ” * value = “$IcingaCheckMemory_String_WarningBytes$””
Line #4973 => ” * value = “$IcingaCheckMemory_Object_WarningPercent$””
Line #4986 => ” * name = “Invoke-IcingaCheckMemory””
Line #4994 => ” * templates = [ “Invoke-IcingaCheckMemory”, “plugin-check-command”, “PowerShell Base”, “plugin-check-command”, “plugin-check-command” ]”

Damit wird die generelle Administration nicht nur einfacher, sondern mittels PowerShell Remote-Execution können auch mehrere Systeme gleichzeitg abgefragt und Statusinformationen eingesammelt werden.

Um sicherzustellen, dass der Agent korrekt ausgeführt wird, der Dienst gestartet werden kann und alle notwendigen Komponenten vefügbar sind, gibt es einen simplen Test, der alle Funktionalitäten überprüft:

Einfache Erweiterbarkeit

Alles in allem ist das Framework so gebaut, dass es eine solide Basis für weitere Entwicklungen bietet – sei es direkt von Seiten Icinga, NETWAYS oder aus der Community. Der Developer Guide bietet schon jetzt grundlegende Erklärungen und Erläuterungen und wird in den nächsten Wochen noch erweitert. Wer sein eigenes PowerShell Modul entwickeln möchte, um Plugins für die Überwachung oder eigene Background-Daemons bereitzustellen, der findet mit diesem Framework das nötige Werkzeug.

Live Webinar

Wer sich einen eigenen Eindruck über das Icinga PowerShell Framework und dessen zahlreiche Möglichkeiten machen möchte, der sei herzlich zu unserem Icinga for Windows – Einstieg” Webinar am 11. März 2020 um 10:30 Uhr eingeladen. Wir freuen uns wie immer auf eine rege Teilnahme.

Wer Unterstützung bei der Installation und Konfiguration oder bei der Entwicklung eigener Plugins benötigt, kann natürlich gerne Kontakt mit uns aufnehmen. Ansonsten freuen wir uns natürlich über Feedback und breite Unterstützung aus der Community!

Christian Stein
Christian Stein
Lead Senior Account Manager

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Senior Sales Engineer und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".

Get your Early Bird Tickets for IcingaConf

We are very proud to be Platinum Sponsor for the very first IcingaConf taking place in Amsterdam this June! The three-day event, hosted by our partner Icinga, includes two days of presentations focusing on Icinga and the surrounding Open Source monitoring ecosystem, as well as a workshop day.

Enjoy the spirit of sharing stories and keeping each other up to date about observability, automation and monitoring culture. Get to know the newest innovations and best practices from the experts. And polish your Icinga skills in one of the workshops.

Conference plus Workshop

Early Bird Tickets for IcingaConf are still available. Don’t wait too long: Get your tickets now!

Prior to two days full of inspiring lectures on June 24 – 25, a workshop day will take place on June 23. Experienced instructors will take you by the hand and guide you through the world of monitoring.

Get to know our super nice NETWAYS colleague, Icinga consultant Thilo Wening. His Icinga Essentials Workshop will guide you through your first steps with Icinga so you can use the tool as efficiently as possible. Thilo has many years of experience with Icinga. Consulting large enterprises and conducting training sessions is part of his daily business.

Thomas Gelf is the main developer of the Icinga Director at Icinga, and Icinga consultant for NETWAYS. Hello lovely colleague no. 2! At NETWAYS we call him “Mr. Director”. Thomas knows exactly how to tweak Director with diverse requirements. Join the Icinga Director Workshop, ask your most urgent questions and thrive!

Training class attendance requires the purchase of an IcingaConf + Workshop ticket. To promote a comprehensive training success, the number of participants is limited. Register now and save your seat!

IcingaConf Speaker Line-Up

The organizers recently announced the speaker line-up for IcingaConf 2020 of which I want to present you a small selection to give you a brief impression of what you can expect:

From the Server Room to the Dev Team

Marina Malaguti is the Director of Data Science & Engineering at Jellyvision, one of the fastest-growing and most successful companies in Chicago.  In the last 10 years of her career, she has identified three team patterns or topologies as being the most commonly used for DevOps teams and Devs. Find out which ones and learn more from the fierce technology leader with a keen eye for problem-solving at IcingaConf.

Find out more about Marina & her talk: To the Dev Team!

Behind the Curtain: The Anatomy of a Real Major Incident

Failures are inevitable. But when they occur, our goal should be to resolve them as quickly and efficiently as possible. The PagerDuty Community has developed an most effective, open-source DevOps approach to Incident Response. George Miranda, Community Advocate at PagerDuty, infrastructure engineer, book author, and former EMT & First Responder knows some gritty details about crisis situations and of course effective incident management.

Find out more about George & his talk: Peek behind the curtain!

No DevOps without Open Source Monitoring

Kris Buytaert is a long time Linux and Open Source Consultant. He’s one of the instigators of the devops movement, currently working for Inuits. 10 years ago they started the #devopsdays leading up to the global use of the term DevOps. Kris talk will illustrate the thriving force that Open Source Monitoring plays for the #devops movement. May contain Icinga, Graphite, Prometheus and friends.

Find out more about Kris & his talk: Thriving #DevOps!

Join us in Amsterdam!

IcingaConf takes place June 23 – 25, 2020 in Amsterdam. Meet us there! Find out more about IcingaConf at icingaconf.com.

Julia Hornung
Julia Hornung
Marketing Manager

Julia ist seit Juni 2018 Mitglied der NETWAYS Family. Vor ihrer Zeit in unserem Marketing Team hat sie als Journalistin und in der freien Theaterszene gearbeitet. Ihre Leidenschaft gilt gutem Storytelling, klarer Sprache und ausgefeilten Texten. Privat widmet sie sich dem Klettern und ihrer Ausbildung zur Yogalehrerin.

IcingaConf 2020 now in June

The Icinga team is dedicated to all that’s going on in the world of observability, automation and monitoring culture. So are you? Meet the Icinga members in Amsterdam!

New date

Please note, that the date of the conference changed. Icinga announces that due to various scheduling conflicts which could not be foreseen, they had to adjust details during the planing phase and move the IcingaConf 2020 to a new date. The new date for IcingaConf 2020 is: June 23 – 25, 2020

What you will get

IcingaConf is a platform where monitoring enthusiasts come together to exchange views about the latest and greatest monitoring trends. Talks focus on Icinga and the surrounding Open Source monitoring ecosystem, newest technologies and best practices. The event starts with two workshopsIcinga Essentials and Icinga Director – on June 23, followed by the main conference on June 24 and 25, 2020.

Get to know the community

Besides all technical deep-dives IcingaConf is your chance to get to know the monitoring community and chat about your ideas and work in a relaxed atmosphere. Be part and learn about different approaches, experiences and challenges. Enjoy the spirit of sharing stories and keeping each other up to date on the most advanced and promising innovations.

Tickets and Proposals

There are only a few Early Bird Tickets left. Don’t wait too long! Register now! Also note that the Call for Proposals is still open. This is your chance to share your insights into enterprise use of Icinga, best practices for large-scale monitoring or to present your preferred DevOps toolchain.

Early Bird Tickets, proposals and more at icingaconf.com

Julia Hornung
Julia Hornung
Marketing Manager

Julia ist seit Juni 2018 Mitglied der NETWAYS Family. Vor ihrer Zeit in unserem Marketing Team hat sie als Journalistin und in der freien Theaterszene gearbeitet. Ihre Leidenschaft gilt gutem Storytelling, klarer Sprache und ausgefeilten Texten. Privat widmet sie sich dem Klettern und ihrer Ausbildung zur Yogalehrerin.
From Monitoring to Observability: Distributed Tracing with Jaeger

From Monitoring to Observability: Distributed Tracing with Jaeger

Modern cloud environments and microservice architectures need a changed mindset when it comes to monitoring. Classic host/service object relations are not always applicable, containers run in Kubernetes are short lived, and application performance within distributed networks is hard to monitor. Especially with applications running millions of operations, where to start the root cause analysis for slow client responses in your web shop? Is it just slow connections to MySQL, or does the application’s debug log slow down the entire fleet?

This is where observability with tracing comes into play. In the cloud native space, OpenTracing evolved as vendor neutral standardized API including client instrumentation. Famous tools are Zipkin and Jaeger which was contributed from Uber to the CNCF.

Let’s have a look into Jaeger today.

 

Getting Started

The easiest way to try Jaeger is with using the Docker container explained in the documentation.

docker run -d --name jaeger \
  -e COLLECTOR_ZIPKIN_HTTP_PORT=9411 \
  -p 5775:5775/udp \
  -p 6831:6831/udp \
  -p 6832:6832/udp \
  -p 5778:5778 \
  -p 16686:16686 \
  -p 14268:14268 \
  -p 9411:9411 \
  jaegertracing/all-in-one:1.16

Navigate to http://localhost:16686 to get greeted by Jaeger.

 

Try it

A sample application is available as container. I’m using a modified port mapping with 8081-8084 here since port 8080 is already assigned.

docker run --rm -it \
  --link jaeger \
  -p8081-8084:8080-8083 \
  -e JAEGER_AGENT_HOST="jaeger" \
  jaegertracing/example-hotrod:1.16 \
  all

Navigate to http://localhost:8081 and click the buttons to order some cars.

Within Jaeger itself, start analyzing the traces and for example learn that Redis runs into timeouts quite often delaying the HTTP responses to the clients.

 

Traces for applications

Jaeger provides officially supported client libraries for Go, Java, Python, NodeJS, C/C++, C#/.NET, others are in the making. Let’s see if we can add it into Icinga 2 and do some tracing here.

First off, clone the repository, build and install the client libraries. You’ll need CMake, a C++ compiler, etc. – basically everything which is required for Icinga 2 too and documented here. In this example, I’m compiling on my Macbook. There are additional libraries and headers required. Hint: Boost 1.72 has a bug which needs a patch.

brew install yaml-cpp thrift 
git clone https://github.com/opentracing/opentracing-cpp && cd opentracing-cpp
# 1.6.0 doesn't work atm
git checkout v1.5.1
mkdir -p build && cd build
cmake ..
make && make install
cd ..

Then clone, cmake, make, install.

git clone https://github.com/jaegertracing/jaeger-client-cpp && cd jaeger-client-cpp
git checkout v0.5.0
# regenerate thrift headers for 0.11.0
find idl/thrift/ -type f -name \*.thrift -exec thrift -gen cpp -out src/jaegertracing/thrift-gen {} \;
mkdir -p build && cd build
cmake ..
make && make install
cd ..

In order to add Jaeger into Icinga 2, there are the following steps necessary:

  • Add CMake functions to lookup yaml-cpp, opentracing, jaeger headers and libraries
  • Optionally enable Jaeger tracing code, link the icinga2 binary against it
  • Add a new tracer into the Config Compiler CLI command to measure the timing points

The majority of development time today was to resolve compile and linking issues, adding spans and traces is really simple. You can follow my progress in this Icinga PR – developers, get started wtih the client libraries and help your colleagues with enhanced observability!

 

Conclusion

Tracing application performance, cluster messages, end2end tests and any sort of event span provides valuable insights for both, devs and ops. With the new cloud native landscape evolving fast, we have additional possibilities to analyze our environments. Next to the now standardized tools for parsing and ingesting logs with Elastic Stack or Graylog, tracing has found its place in the observability stack.

Jaeger Tracing also is part of the GitLab observability suite which will be moved to the free core edition in 2020. Metrics, logging, alerts and tracing are key elements in modern cloud environments. Prometheus monitors everything from classic load checks to Kubernetes containers, Jaeger provides application performance insights and on top of that, Grafana combines the view on problems and trends. You can learn more about GitLab’s vision here.

Exploring these cool new features in GitLab are our mission in future trainings and workshops, watch this space in 2020!

Michael Friedrich
Michael Friedrich
Senior Developer

Michael ist seit vielen Jahren Icinga-Entwickler 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 und der Linzer Torte. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht in der Community helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst...
Vom Messwert zur Alarmierung

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
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“.

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.