Neues Check-Plugin für TinkerForge Hardware

Sensoren wären ohne anständige Auswertungsmöglichkeit eigentlich nichts wert. TinkerForge bietet mit Ihrem BrickViewer bereits von Haus aus eine gute Lösung an. Da viele jedoch nicht ständig zwischen verschiedenen Tools hin und her wechseln wollen, gibt es für die TinkerForge Hardware und die dazugehörigen Sensoren auch ein Check-Plugin aus dem Hause Icinga. Herunterladen kann man dies auf exchange.icinga.com:

check_tinkerforge

 

Mit diesem Plugin können folgende Sensoren/Bricks mithilfe von Icinga 2 ausgelesen werden:

  • Ambient Light Bricklet 3.0
  • Humidity Bricklet 2.0 (misst auch gleichzeitig die Temperatur)
  • PTC Bricklet 2.0
  • Temperature Bricklet 2.0

 

 

Auch bei diesem Plugin können natürlich Schwellwerte gesetzt werden, um die Zustände OK, WARNING und CRITICAL zu definieren und zurückgemeldet zu bekommen. Im folgenden eine kurze Erklärung zu den wichtigsten Parametern des Plugins:

-H  Host Adresse im IP-Format
-P  Port Number
-S  Übergabe eines Authentication Secrets, falls dies gewünscht ist
-T  Sensortype, z. B. Temperatur
-u  Angabe der UID eines Bricks, insbesondere wenn mehere baugleiche Bricks genutzt werden
-W  Schwellwert oder Wertebereich für WARNING-Zustände
-C  Schwellwert oder Wertebereich für CRITICAL-Zustände

Natürlich möchten wir auch noch kurz ein paar Beispiele zeigen, wie das Plugin aufgerufen werden kann und was es uns dann zurückliefert:

PTC

check_tinkerforge.py -H <IP Address> -T ptc
OK - Tinkerforge: Temperature is 11.63 degrees celcius|'temperature'=11.63

 

Temperature

check_tinkerforge.py -H <IP Address> -T temperature -w 26:55
WARNING - Tinkerforge: Temperature is 24.75 degrees celcius|'temperature'=24.75

 

Humidity

check_tinkerforge.py -H <IP Address> -T humidity
OK - Tinkerforge: Humidity is 35.4 %HR (Temperature is 26.06 degrees celcius)|'temperature'=26.06 'humidity'=35.4

 

Ambient Light

check_tinkerforge.py -H <IP Address> -T ambient_light -w 900
WARNING - Tinkerforge: Illuminance is 959.41 lx|'illuminance'=959.41

 

Damit das TinkerForge Plugin fehlerfrei ausgeführt werden kann, werden folgende Komponenten auf dem System benötigt:

  • Python 2.7+
  • tinkerforge Python library from Pypi

 

Wer sich für die Produkte von TinkerForge interessiert, kann sich bei uns im Shop gerne einen Überblick verschaffen oder uns direkt ansprechen. Bei Fragen rund um unsere angebotene Hardware könnt Ihr uns per Mail erreichen – wir helfen wie immer gerne weiter!

Meine erste Reise bei NETWAYS!

Letzte Woche war es soweit ich durfte meine erste Dienstreise antreten. Zwar handelte es sich hierbei nur um eine Schulung, aber immerhin. Es ging nach München für die Icinga 2 Fundamentals Schulung.

Mit Lennart als Trainer, ging es Montag Nachmittag los. Zwei Stunden später waren wir angekommen. Natürlich mussten wir noch den Schulungsraum auf Vordermann bringen. Tische zurecht rücken, mit Notebooks bestücken, Unterlagen verteilen, Stromanschluss bereitstellen und so weiter. Der Aufbau nahm schon etwas Zeit in Anspruch, aber zu zweit ging das ganze doch schneller als erwartet. Ab aufs Zimmer um für den nächsten Tag fit zu sein, denn um neun Uhr geht es los. Themen der Icinga 2 Fundamentals Schulung? Wie der Name schon erwarten lässt, Grundkentnisse und Grundlagen zu Icinga2. Doch wer Lennart kennt, weiß dass er in den gegebenen Tagen meist mehr schafft als geplant.

Also eine erholsame Nacht im Hotel später wurden die Schulungsteilnehmer in Empfang genommen. Um acht Uhr trafen die ersten bereits ein um ihre Plätze einzunehmen. Nach einer kleinen Vorstellungsrunde bei der sich Lennart mit dem derzeitigen Wissenstand der Teilnehmer auseinandersetzte sind wir auch schon gleich mit Icinga2 eingestiegen. Egal ob Icinga selbst, einfache Plugins oder der Icinga Director es wurde alles abgedeckt.

Selbstverständlich gab es reichlich Pausen, sowie Getränke und Essen zu genüge. Auf leeren Magen lässt es sich schlecht lernen und die Worte NETWAYS und leerer Magen sind nicht miteinander vereinbar. Am zweiten Schulungstag wurde es gegen Abend mal Zeit für einen Tapetenwechsel und wir machten uns auf dem Weg zum Augustiner Klosterwirt. In geselliger Atmosphäre in diesem rauen Etablissement wurde der Abend ausgeklungen und nach einem deftigen Abendessen auch das ein oder andere Bier getrunken.

Die vier Tage gingen schnell vorüber. Für mich als zukünftigen Consultant war es praktisch zu sehen, wie Lennart den Schulungsteilnehmern individuell zur Seite stehen konnte und noch während der Schulung Auskunft gegeben konnte über die Anwendung in den entsprechenden Umgebungen der Kunden. Es waren vier sehr intensive Tage vollgestopft mit sehr viel Informationen. Seit Freitag bin ich wieder in Nürnberg und jetzt heißt es erst einmal sacken lassen. Wird bestimmt nicht lange dauern bis ich mein erstes Icinga-Projekt bekomme.

Um ehrlich zu sein, war ich schon ein bisschen nervös. Vor der ersten richtigen Dienstreise, aber jetzt kann ich die nächste kaum erwarten.

Tobias Bauriedel
Tobias Bauriedel
Junior Consultant

Tobias ist ein offener und gelassener Mensch, dem vor allem der Spaß an der Arbeit wichtig ist. Bei uns macht er zurzeit seine Ausbildung zum Fachinformatiker. In seiner Freizeit ist er viel unterwegs und unternimmt gern etwas mit Freunden.

Einstieg in Icinga mit dem NETWAYS Icinga Starterpaket

Icinga überwacht alles, ist offen, sehr gut dokumentiert und für jede Umgebung anpassbar. Und damit der Start in das eigene Monitoringsystem oder der Umstieg von Nagios oder Icinga 1.x reibungslos funktioniert, haben wir das Icinga Starterpaket geschnürt. In 4 Tagen Workshop vor Ort beim Kunden stellen wir zusammen mit euch die Basis für eine Open Source Überwachungsumgebung für eure Server, Netzwerkhardware, Anwendungen, Datenbanken und Betriebssysteme auf die Beine und führen euch in Icinga ein.

Was können wir in 4 Tagen Workshop leisten?

  • Installation von Icinga 2 mit Icinga Web 2 und Datenbankanbindung
  • Installation einer Graphing Lösung zur Darstellung von Performancedaten
  • Installation des Business Process Addons
  • Beispielhafte Überwachung von Linux Servern
  • Beispielhafte Überwachung von Windows Servern
  • Beispielhafte Überwachung einer Datenbank (MSSQL, Oracle, DB2, MaxDB, MySQL, ..)
  • Beispielhafte Überwachung von Netzwerkkomponenten per SNMP (MIBs müssen vorhanden sein)
  • Beispielhafte Überwachung deiner Anwendungen
  • Einrichtung von E-Mail Benachrichtigungen

Wir empfehlen vor der Buchung des Icinga Starterpakets Standard den Besuch unserer Icinga Fundamentals Schulung. Diese Schulung könnt ihr auch als Modul zu diesem Starterpaket hinzubuchen.

Natürlich passen wir unser Workshopangebot auch komplett an eure Anforderungen an. Wir freuen uns auf eure Anfrage.

Martin Krodel
Martin Krodel
Head of Sales

Der studierte Volljurist leitet bei NETWAYS die Sales Abteilung und berät unsere Kunden bei ihren Monitoring- und Hosting-Projekten. Privat reist er gerne durch die Weltgeschichte und widmet sich seinem ständig wachsenden Fuhrpark an Apple Hardware.

Irgendwer muss es halt machen

Ostern ist gerade erst vorbei,
Dann Tag der Arbeit, erster Mai.
Davor, danach brauchst Brückentage:
Zur Erholung, keine Frage.

Die Völlerei der letzten Wochen
Zehrte ziemlich an den Knochen.
Die Magenwand hat überstrapaziert
Wer gefastet hat und nicht trainiert.

Geniert euch nicht, euch sei's gegönnt:
Schaltet ab, sooft ihr's könnt.
Bald ist Pfingsten, Christi Himmelfahrt,
Das Leben das ist ganz schön hart.

Nur einer, der muss ständig laufen,
Darf nicht rasten, niemals saufen.
Wird gern beschimpft, sieht selten Lohn
Schuftet mühsam, schwer und monoton.

Muss ständig in die Runde fragen
Bis wirklich alle Hallo sagen,
Meldet alsdann jeden als gestört
Der sein Rufen nicht erhört.

Wer opfert sich für solche Sachen?
Irgendwer muss es halt machen.
Einsam tut damit hervor
Sich von Icinga 2 der Core.

Die Moral von der Geschichte?
Lasst ihn schuften, zu die Kiste.
Eure Woche ist erst mal zu Ende,
Tschüss Icinga, es ist Wochenende!

Thomas Gelf
Thomas Gelf
Principal Consultant

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.

Neu im Shop: RackMonitoring Kits von TinkerForge

Ab heute können sich unsere Kunden über einen neuen Hersteller bei uns im Shop freuen: Zur Überwachung von Serverräumen bieten wir nun zwei RackMonitoring Kits aus dem Hause TinkerForge an.

TinkerForge ist ein mittelständisches Unternehmen aus Ostwestfalen-Lippe, das Mikrocontrollerbausteine herstellt, die sogenannten Bricks. Die Idee zu diesen Bricks hatten die beiden Gründer Bastian Nordmeyer und Olaf Lüke, nachdem sie – auf der Suche nach Mikrocontrollermodulen für autonome Fußballroboter – keine offenen, mit verschiedenen Programmiersprachen ansteuerbaren Bauteile gefunden haben. Was 2011 noch mit einer kleinen Produktlinie begann, ist nun ein extensiver Katalog an Controllern und Modulen, die sich in zahlreichen Programmiersprachen ansteuern lassen, und sich durch ihre modulare Bauweise schier endlos verknüpfen lassen.

 

 

In enger Zusammenarbeit wurden nun zwei RackMonitoring Kits erstellt, die vor allem Kunden mit individuellen Ansprüchen gerecht werden. Aufgrund der hohen Modularität der einzelnen Komponenten lassen sich TinkerForge Produkte immer wieder neu zusammensetzen. Des Weiteren zeichnet sich TinkerForge durch offene Schnittstellen für Programmierer aus und fällt damit klar in die Kategorie Open Source. Zu den Kits gibt es natürlich auch ein entsprechendes Monitoring Plugin auf exchange.icinga.com.

Folgende Features erwarten Sie bei unseren RackMonitoring Kits PTC4 und PTC8:

  • Modulare Low-Cost Serverraum-Überwachung
  • Lieferumfang:
    • vormontiertes 1HE-Gehäuse passend für 19″ Racks
    • jeweils ein integrierter Sensor für Temperatur, Luftfeuchtigkeit und Umgebungslicht
    • ein pt100 Temperaturfühler mit 1 m Länge
    • Anschlüsse für 7 weitere pt100 Temperaturfühler (nicht enthalten)
    • Anschlüsse und Adapter für Monitor und Keyboard
    • USB-Netzteil
  • Variante PTC4 erlaubt den Anschluss von bis zu 4 pt100 Temperaturfühlern, Variante PTC8 bis zu 8 pt100 Temperaturfühler
  • Erweiterbar: Weitere Sensoren und Ein-/Ausgabe Module können einfach hinzugesteckt werden
  • Stromversorgung per Ethernet (PoE) oder USB
  • Open Source Soft- und Hardware mit Icinga und Nagios Unterstützung
  • APIs für diverse Programmiersprachen verfügbar:
    • C/C++, C#, Delphi/Lazarus, Go, Java, JavaScript, LabVIEW, Mathematica, MATLAB/Octave, MQTT, Perl, PHP, Python, Ruby, Rust, Shell, Visual Basic .NET

Wie in der Feature-Liste breits erwähnt wurde, können die RackMonitoring Kits individuell erweitert werden. Für unsere Kunden heißt das, dass hier bzgl. Bricks, Bricklets und anderen Modulen aus dem Vollen geschöpft werden kann – egal, ob es sich um Sensoren, Netzwerk, Funk, Schalter oder Displays handelt. Gerade im Bereich Sensoren sind TinkerForge hier vorbildlich aufgestellt – von Luftqualität (Staub, CO2), räumliche Wahrnehmung (Distanz, Bewegung), Akustik (Schalldruck), Licht (Helligkeit, UV-Einstrahlung) und mehr.

Bei Fragen zum Produkt oder bzgl. Erweiterungs- oder Umbaumöglichkeiten können Sie sich wie gewohnt per Mail an uns wenden – wir helfen gerne weiter! Und wer gerne noch ein bisschen weiterlesen möchte zum Thema TinkerForge, dem sei unser erster Blogpost dazu empfohlen, in dem es um die Inbetriebnahme einer Wetterstation geht:

TinkerForge-Basteln Teil 1: Auspacken und Einrichten!

Modern C++ programming: Coroutines with Boost

(c) https://xkcd.com/303/

We’re rewriting our network stack in Icinga 2.11 in order to to eliminate bugs with timeouts, connection problems, improve the overall performance. Last but not least, we want to use modern library code instead of many thousands of lines of custom written code. More details can be found in this GitHub issue.

From a developer’s point of view, we’ve evaluated different libraries and frameworks before deciding on a possible solution. Alex created several PoCs and already did a deep-dive into several Boost libraries and modern application programming. This really is a challenge for me, keeping up with the new standards and possibilities. Always learning, always improving, so I had a read on the weekend in “Boost C++ Application Development Cookbook – Second Edition“.

One of things which are quite resource consuming in Icinga 2 Core is multi threading with locks, waits and context switching. The more threads you spawn and manage, the more work needs to be done in the Kernel, especially on (embedded) hardware with a single CPU core. Jean already shared insights how Go solves this with Goroutines, now I am looking into Coroutines in C++.

 

Coroutine – what’s that?

Typically, a function in a thread runs, waits for locks, and later returns, freeing the locked resource. What if such a function could be suspended at certain points, and continue once there’s resources available again? The benefit would also be that wait times for locks are reduced.

Boost Coroutine as library provides this functionality. Whenever a function is suspended, its frame is put onto the stack. At a later point, it is then resumed. In the background, the Kernel is not needed for context switching as only stack pointers are stored. This is done with Boost’s Context library which uses hardware registers, and is not portable. Some architectures don’t support it yet (like Sparc).

Boost.Context is a foundational library that provides a sort of cooperative multitasking on a single thread. By providing an abstraction of the current execution state in the current thread, including the stack (with local variables) and stack pointer, all registers and CPU flags, and the instruction pointer, a execution context represents a specific point in the application’s execution path. This is useful for building higher-level abstractions, like coroutinescooperative threads (userland threads) or an equivalent to C# keyword yield in C++.

callcc()/continuation provides the means to suspend the current execution path and to transfer execution control, thereby permitting another context to run on the current thread. This state full transfer mechanism enables a context to suspend execution from within nested functions and, later, to resume from where it was suspended. While the execution path represented by a continuation only runs on a single thread, it can be migrated to another thread at any given time.

context switch between threads requires system calls (involving the OS kernel), which can cost more than thousand CPU cycles on x86 CPUs. By contrast, transferring control vias callcc()/continuation requires only few CPU cycles because it does not involve system calls as it is done within a single thread.

TL;DR – in the way we write our code, we can suspend function calls and free resources for other functions requiring it, without typical thread context switches enforced by the Kernel. A more deep-dive into Coroutines, await and concurrency can be found in this presentation and this blog post.

 

A simple Example

$ vim coroutine.cpp

#include <boost/coroutine/all.hpp>
#include <iostream>

using namespace boost::coroutines;

void coro(coroutine::push_type &yield)
{
        std::cout << "[coro]: Helloooooooooo" << std::endl;
        /* Suspend here, wait for resume. */
        yield();
        std::cout << "[coro]: Just awesome, this coroutine " << std::endl;
}

int main()
{
        coroutine::pull_type resume{coro};
        /* coro is called once, and returns here. */

        std::cout << "[main]: ....... " << std::endl; //flush here

        /* Now resume the coro. */
        resume();

        std::cout << "[main]: here at NETWAYS! :)" << std::endl;
}

 

Build it

On macOS, you can install Boost like this, Linux and Windows require some more effort listed in the Icinga development docs). You’ll also need CMake and g++/clang as build tool.

brew install ccache boost cmake 

Add the following CMakeLists.txt file into the same directory:

$ vim CMakeLists.txt

cmake_minimum_required(VERSION 2.8.8)
set(BOOST_MIN_VERSION "1.66.0")

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++0x")

find_package(Boost ${BOOST_MIN_VERSION} COMPONENTS context coroutine date_time thread system program_options regex REQUIRED)

# Boost.Coroutine2 (the successor of Boost.Coroutine)
# (1) doesn't even exist in old Boost versions and
# (2) isn't supported by ASIO, yet.
add_definitions(-DBOOST_COROUTINES_NO_DEPRECATION_WARNING)

link_directories(${Boost_LIBRARY_DIRS})
include_directories(${Boost_INCLUDE_DIRS})

set(base_DEPS ${CMAKE_DL_LIBS} ${Boost_LIBRARIES})

set(base_SOURCES
  coroutine.cpp
)

add_executable(coroutine
        ${base_SOURCES}
)

target_link_libraries(coroutine ${base_DEPS})

set_target_properties(
        coroutine PROPERTIES
        FOLDER Bin
        OUTPUT_NAME boost-coroutine
)

Next, run CMake to check for the requirements and invoke make to build the project afters.

cmake .
make

 

Run and understand the program

$ ./boost-coroutine
[coro]: Helloooooooooo
[main]: .......
[coro]: Just awesome, this coroutine
[main]: here at NETWAYS! :)

Now, what exactly happened here? The Boost coroutine library allows us to specify the “push_type” where this functions should be suspended, after reaching this point, a subsequent call to “yield()” is required to resume this function.

void coro(coroutine::push_type &yield)

Up until “yield()”, the function logs the first line to stdout.

The first call happens inside the “main()” function, by specifying the pull_type and directly calling the function as coroutine. The pull_type called “resume()” (free form naming!) must then be explicitly invoked in order to resume the coroutine.

coroutine::pull_type resume{coro};

After the first line is logged from the coroutine, it stops before “yield()”. The main function logs the second line.

[coro]: Helloooooooooo
[main]: .......

Now comes the fun part – let’s resume the coroutine. It doesn’t start again, but the function’s progress is stored as stack pointer, targeting “yield()”. Exactly this resume function is called with “resume()”.

        /* Now resume the coro. */
        resume();

That being said, there’s more to log inside the coroutine.

[coro]: Just awesome, this coroutine

After that, it reaches the end and returns to the main function. That one logs the last line and terminates.

[main]: here at NETWAYS! :)

Without a coroutine, such synchronisation between functions and threads would need waits, condition variables and lock guards.

 

Icinga and Coroutines

With Boost ASIO, the spawn() method wraps coroutines on a higher level and hides the strand required. This is used in the current code and binds a function into its scope. We’re using lambda functions available with C++11 in most locations.

The following example implements the server side of our API waiting for new connections. An endless loop listens for incoming connections with “server->async_accept()”.

Then comes the tricky part:

  • 2.9 and before spawned a thread for each connection. Lots of threads, context switches and memory leaks with stalled connections.
  • 2.10 implemented a thread pool, managing the resources. Handling the client including asynchronous TLS handshakes are slower, and still many context switches ahead between multiple connections until everything stalls.
  • 2.11 spawns a coroutine which handles the client connection. The yield_context is required to suspend/resume the function inside.

 

void ApiListener::ListenerCoroutineProc(boost::asio::yield_context yc, const std::shared_ptr& server, const std::shared_ptr& sslContext)
{
	namespace asio = boost::asio;

	auto& io (server->get_io_service());

	for (;;) {
		try {
			auto sslConn (std::make_shared(io, *sslContext));

			server->async_accept(sslConn->lowest_layer(), yc);

			asio::spawn(io, [this, sslConn](asio::yield_context yc) { NewClientHandler(yc, sslConn, String(), RoleServer); });
		} catch (const std::exception& ex) {
			Log(LogCritical, "ApiListener")
				<< "Cannot accept new connection: " << DiagnosticInformation(ex, false);
		}
	}
}

The client handling is done in “NewClientHandlerInternal()” which follows this flow:

  • Asynchronous TLS handshake using the yield context (Boost does context switches for us), Boost ASIO internally suspends functions.
    • TLS Shutdown if needed (again, yield_context handled by Boost ASIO)
  • JSON-RPC client
    • Send hello message (and use the context for coroutines)

And again, this is the IOBoundWork done here. For the more CPU hungry tasks, we’re using a different CpuBoundWork pool which again spawns another coroutine. For JSON-RPC clients this mainly affects syncing runtime objects, config files and the replay logs.

Generally speaking, we’ve replaced our custom thread pool and message queues for IO handling with the power of Boost ASIO, Coroutines and Context thus far.

 

What’s next?

After finalizing the implementation, testing and benchmarks are on the schedule – snapshot packages are already available for you at packages.icinga.com. Coroutines will certainly help embedded devices with low CPU power to run even faster with many network connections.

Boost ASIO is not yet compatible with Coroutine2. Once it is, the next shift in modernizing our code is planned. Up until then, there are more Boost features available with the move from 1.53 to 1.66. Our developers are hard at work with implementing bug fixes, features and learning all the good things.

There’s many cool things under the hood with Icinga 2 Core. If you want to learn more and become a future maintainer, join our adventure! 🙂

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

NETWAYS Webinare: Geballte Power

Am 20. Februar 2019 gibt es eine Doppelfolge unserer beliebten NETWAYS Webinar-Reihe: Vormittags behandeln wir OpenStack und nachmittags Graylog. Was erwartet unsere Teilnehmer inhaltlich?

OpenStack ist seit vielen Jahren in der IT-Branche ein Begriff und wird auf nahezu allen Konferenzen, die sich mit Automatisierung, Hosting, Rechenzentren usw. beschäftigen, beworben und vorgestellt. Unsere eigene IaaS-Plattform baut ebenso auf OpenStack auf – aber was ist OpenStack eigentlich? Wo kommt es her, welche Vorteile bietet die Lösung und was kann ich damit am Ende tun? Diese Fragen wollen wir in unserem Webinar beantworten und einige Möglichkeiten anhand unserer OpenStack-Plattform demonstrieren.

Graylog ist eine vielseitige und umfangreiche Lösung, wenn es um die zentrale Speicherung, Analyse und Auswertung von Logdaten – egal ob Syslog, Windows Event Log, Log-Dateien oder viele andere – geht. Neben einer übersichtlichen Oberfläche bietet Graylog vor allem die Möglichkeit, nativ Berechtigungen auf Inhalten und Dashboards festzulegen und individuelle Streams, Inputs und Filter zu definieren. In der neuen Version 3.0 stehen viele neue Features wie Views, Reports und die neue Sidecar zur Verfügung. In diesem Webinar wollen wir grundlegend auf die Möglichkeiten von Graylog, vor allem jedoch auf die Neuheiten, eingehen und diese vorstellen.

Für alle Freunde unserer Icinga 2 Webinare haben wir leider schlechte Nachrichten, da wir im März das Thema vorerst abschließen wollen:

Aber niemand muss traurig sein – seht Euch unseren Webinar-Kalender einfach an. Wir sind sicher, dass Euch auch die neue Webinar-Reihe zum Thema OpenStack begeistern wird.

Wir freuen uns, Euch in unseren Webinaren begrüßen zu dürfen!

Weniger ist mehr: Gestaltung unter dem Aspekt der Aufmerksamkeitsökonomie

Weniger ist mehr: Gestaltung unter dem Aspekt der Aufmerksamkeitsökonomie

Das Konzept der Aufmerksamkeitsökonomie versteht die menschliche Aufmerksamkeit als eine begrenzte Ressource. Je mehr Informationen auf den Wahrnehmenden »einprasseln«, desto mehr dieses knappen Gutes benötigt ein Mensch um diese zunächst zu sortieren und zu priorisieren, bevor sie verarbeitet werden können.

(mehr …)

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.

Windows blocking Icinga 2 with ephemeral port range

Recently a customer opened a support ticket reporting “frozen” Icinga 2 agents on Windows. The agent was still running and writing logs but didn’t respond to connection attempts from an Icinga 2 master or satellite nor did it connect the other way.

The Icinga 2 log showed messages which stemmed directly from Windows and could not be found in the Icinga 2 code.

critical/TcpSocket: Invalid socket: 10055, "An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full."

What we found after some research is strange enough to make me write this article about. It seems that, depending on version, patch level and installed applications Windows is changing its range of ephemeral ports. So your windows might or might not be blocking ports which Icinga 2 uses for its communication.

What solved the problem was an entry into the Windows hosts registry.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters 

Value Name: MaxUserPort Value 
Type: DWORD 
Value data: 65534

You can find more information at Microsoft or in this blog.

Photo by Paweł Czerwiński on Unsplash

Thomas Widhalm
Thomas Widhalm
Lead Support Engineer

Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 möchte er aber lieber die große weite Welt sehen und hat sich deshalb dem Netways Consulting Team angeschlossen. Er möchte ausserdem möglichst weit verbreiten, wie und wie einfach man persönliche Kommunikation sicher verschlüsseln kann, damit nicht dauernd über fehlenden Datenschutz gejammert, sondern endlich was dagegen unternommen wird. Mittlerweile wird er zum logstash - Guy bei Netways und hält...

Bewirb dich und fliege zu einem Icinga Camp deiner Wahl!

Für den heutigen Freitag haben wir uns etwas ganz spezielles überlegt. Wir suchen nach wie vor (und eigentlich auch immer) Verstärkung für unser Professional Services Team.

Solltest du dich für den

bewerben und wirst eingestellt, darfst du dir ein Icinga Camp deiner Wahl aussuchen und dort hinreisen.

Zur Auswahl stehen Icinga Camps in:

Also schnell ab mit euch an die Tastatur und schickt eure Bewerbung an jobs@netways.de. Die ersten Camps sind bereits im März (Berlin) und Mai (Atlanta + Seattle).

Tobias Redel
Tobias Redel
Head of Professional Services

Tobias hat nach seiner Ausbildung als Fachinformatiker bei der Deutschen Telekom bei T-Systems gearbeitet. Seit August 2008 ist er bei NETWAYS, wo er in der Consulting-Truppe unsere Kunden in Sachen Open Source, Monitoring und Systems Management unterstützt. Insgeheim führt er jedoch ein Doppelleben als Travel-Hacker, arbeitet an seiner dritten Millionen Euro (aus den ersten beiden ist nix geworden) und versucht die Weltherrschaft an sich zu reißen.