Seite wählen

NETWAYS Blog

Is there a Company Backing PostgreSQL?

That’s a question I got asked when I was helping out at the PostgreSQL booth at this year’s FOSDEM.

I replied “yes”. And a second later, “there are even several!”.

But although the nerd density at FOSDEM is ridiculously high, I’m not sure he got that boolean joke “Are you going for lunch now or later?” “Yes.” … so, in the faint hope that, that guy will stumble upon this blogpost and hopefully as a nice read too many others, let me elaborate on that a bit.

PostgreSQL was Initially a Research Project

Back in the 1970’s, even in the US, universities could do research on things that would not directly lead to a patent for the corporate sponsor and a spinoff (owned predominantly by the corporate sponsor). They even received public money for such kind of research (whoo!), often from the DARPA.

Michael Stonebraker and Eugene Wong, who started PostgreSQL’s predecessor Ingres, were funded by a couple of military agencies, more detail here.

Stonebraker in fact did the spinoff “stunt” with Ingres which exists until today. However he returned to Berkeley to continue research on a “Post-Ingres” system, “Postgres”. Yada yada yada, long story short, Postgres was basically handed over to a group of enthusiast who kept working on it and turned it into PostgreSQL over time (we’re discussing the mid-90’s here). Some of those initial enthusiasts are still actively working on the project btw., one, Bruce Momjian, even attending FOSDEM on a regular basis!

It Today is a Community Project

The database system today is “owned”, which is in fact impossible due to the ridiculously open license, be the PostgreSQL Global Development Group, a non-profit that mainly runs the different postgresql.org sites. Alongside, there are several national & international non-profits, e.g. PgUS, PgEU and countless local usergroups, see the community page to get an idea.

… that allows a lot of Companies to generate Profit of it

So, people started doing serious stuff with Postgres, ran into problems and had them resolved, wanted advice on certain issues, get trained, or just someone to look after their databases on a regular base. Companies were founded, that specialised on PostgreSQL support and consulting. Some of these vanished, some still exist.

Some of these companies offer proprietary products that base on PostgreSQL. Also, there were “spinoffs”, companies that took the PostgreSQL code and ran with it, making something new of it. Just as well, some of these still exist and make good business.

… which some Feed Back partly into the Project

Many, if not most, of these companies contribute to PostgreSQL one way or the other. As a matter of fact, the vast majority of the core team members and major contributors work for a handful of companies.

Still, these people are probably working for those companies, because they are major contributers. E.g. Tom Lane these days works for Crunchy Data, but has been working for e.g. Red Hat and Salesforce before (rumours are that Salesforce hiring Tom was a huge factor in the Salesforce-Oracle “war” and led to their 2013 partnership – most probably due to a massive discount that Salesforce were willing to agree to…).

Corporate contributions are mostly code by hiring people, who hack on PostgreSQL and money by sponsoring infrastructure or events.

The community is rather small, so is the circle of corporate players. At the end of the days, everyone knows everyone and is engaged in a coopetition.

Most corporate code contributions stem from their customers’ requirements. Some improvements go to the proprietary variants first, very few go there only. However, the ultimate goal usually is to get a feature into the core product, so mainline, community PostgreSQL.

So how does this Model differ from Other Popular Projects?

Linux

These days, when we mention the kernel, we usually mean Linux, that has the Linux Foundation, essentially backed by all major players in IT, which realised that Linux is useful to them and decided to fund the development (essentially ending the UNIX wars).

There are only few, if at all, companies that “span off” the kernel, but the vast majority of code contribution these days is coming from corporations or their employees.

Some of these in turn “sell” Linux as distributions, essentially subscriptions today. Their share of Kernel contributions is a huge selling point.

Others, take NIC or SCSI controller manufacturers for example, were initially (like, 25 or 20 years ago) just hoping to sell a few more of their products by offering some nerd enthusiasts specs and technical documentation. Today, they know they just can’t sell anything that isn’t properly supported by Linux, and thus are willing to hire full-time developers to ensure so.

All of those contributions still go over the “benevolent dictator“‘s desk or one of his aides’ and thus have to fulfil certain requirements. And the distributors agreed years ago to only include mainline features in their products, to avoid fragmentation.

A major difference to PostgreSQL: all those companies (distributors aside) use Linux for their resp. products, not as their product.

MySQL / MariaDB

MySQL initially was written by the founders of MySQL AB, which was acquired by SUN in 2008, which in turn was acquired by Oracle in 2010.

While being an Open Source product and even being GPL-licensed as Free Software, MySQL was never renowned for being very open to contributions, however MySQL AB and SUN were striving to improve the product, based on what the “community” was wishing.

Oracle, being the major player in the RDBMS market, obviously has no interest in improving a “free” piece of software to a degree that it could effectively cannibalise their core product … so, the MySQL founders founded MariaDB and took a significant part of the MySQL developers with them.

Both products still evolve, but development is steered and driven by Oracle and MariaDB respectively (no idea what I should think of the MariaDB Foundation, to be totally honest), so probably to a good degree by the marketing departments and in Oracle’s case, fenced by the limitations from “above”.

Sure, you can get support from independent companies (many of those also offering PostgreSQL services, btw.). However, any large customer like financial institutions, the public sector, etc. prefer to go “straight to the source”, so chances are that offering support will stay a niche market. Percona maybe being the exception.

MongoDB et. al.

The “NoSQL” market is (IMHO) to a certain degree a reply to the pricing policy of RDBMS vendors and the “better safe than sorry” mentality of many IT managers. But that’s a different story …

However, a certain pattern has evolved over the last years:
Some Open Source projects become popular, companies are founded, the development is centralized there, conferences and trainings are offered etc.
And at some point, someone decides that actually earning money would be a nice idea …

So, an “enterprise” product is introduced, or a dual-license model, or a cloud service with limitation of competitors’ ability to offer such, etc. pp.

In essence, these are often Open Source products, but not Free Software. They sometimes get crippled beyond recognition.
The communities could sometimes be called that way because the mawning people in the forums are “managed” by “community members”.

Is this healthy? Couldn’t a Company buy PostgreSQL, like Oracle did with MySQL?

Short: No.
Longer: Sure, e.g. Oracle could probably buy one or most of those companies, but the product PostgreSQL is not “theirs”. I mean, even MySQL was forked after the acquisition of SUN …

We’ve seen PostgreSQL companies get bought, sometimes they even disappear from their “natural” markets.
But that had no significant impact on the project’s structure, pace or harmony.

PostgreSQL

  • is “smaller” than MySQL, Linux or many other important FOSS projects
  • we don’t have the Kernel.org power
  • nor Oracle’s cash and licensing department
  • is not controlled by any single entity, thus
  • “more free” than many other “open source” projects/products
  • can not be bought, shut down or in any way be tampered with
  • will never change its license
  • will never disappear
  • yet feeds a lot of mouths directly and many, many more indirectly, like your humble author here
  • many contribute back one way or the other

PostgreSQL is much closer to the Linux model, coopetition of many companies, plus a fair share of “private” contributors, than to any other Open Source DBMS, relational or not.

This worked very good for the last 25 years, and I doubt it will ever change.

As someone (was it Bernd Erk?) coined:
> “PostgreSQL doesn’t have a community, it is one!”

I second that!

Über den Author:

Gunnar “Nick” Bluth hat seine Liebe zu relationalen Datenbanken Ende des letzten Jahrtausends entdeckt. Über MS Access und MySQL 3.x landete er sehr schnell bei PostgreSQL und hat nie zurückgeschaut, zumindest nie ohne Schmerzen. Er verdient seine Brötchen seit beinahe 20 Jahren mit FOSS (Administration, Schulungen, Linux, PostgreSQL). Gelegentlich taucht er auch tiefer in die Programmierung ein, so als SQL-Programmierer bei der Commerzbank oder in App-Nebenprojekten.
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...

Namen sind Schall und Rauch? Lieber nicht.

Das Problem

Bei vielen Projekten zu Logmanagement stellt sich recht schnell die Frage nach der Benamsung der Felder, in die Events zerlegt werden sollen. Da man sie weitestgehend frei wählen kann, startet so schnell ein gewisser Wildwuchs und das unabhängig davon, ob der Elastic Stack oder Graylog verwendet wird, um die Nachrichten zu “zergrokken”, wie es mal ein Kunde so schön formuliert hat.

Das Kuddelmuddel rund um die Feldnamen hat einige Nachteile, die früher oder später zuschlagen:

  • Ein Feld innerhalb eines Index darf nur einen Typ haben. Wenn also zufällig zwei Regeln ein Feld namens errorlevel anlegen und eine schreibt debug rein, die andere 4 wird das früher oder später dazu führen, dass Events von Elasticsearch abgelehnt werden
  • Gemeinsame Dashboards gestalten sich schwierig, wenn die IP des sich verbindenden Hosts mal in client , mal in client_ip und mal in anfragenderhost drin steht
  • Andere Tools und mitgelieferte Regeln / Dashboards haben keine Möglichkeit, vorherzusagen wie Felder heissen werden, deren Informationen sie brauchen

Schon immer galt die Empfehlung, sich ein Namensschema zu überlegen und sich strikt dran zu halten. Das klappt leider meist schon nicht, wenn nur eine Person dran arbeitet und wird nahezu unmöglich, wenn mehrere Teams eine gemeinsame Konfiguration pflegen. Das muss gar nicht einer gewissen Nachlässigkeit geschuldet sein, sondern kann alleine schon daraus resultieren, dass die gleichen Dinge manchmal in verschiedenen Teams einfach unterschiedlich genannt werden. Man muss nur an die Diskussion rund um “Satellite” oder “Slave” bei Icinga 2 oder die verschiedenen Logstash Instanzen (“Shipper”, “Indexer”, “Forwarder”, “häh?”) denken, um ein naheliegendes Beispiel zu haben.

ECS to the rescue

Elastic hat nun eine schöne, wenn auch noch nicht umfassende Lösung dafür geschaffen: Das “Elastic Common Schema”, kurz ECS.

Beschrieben in einem eigenen Abschnitt der Dokumentation. Darin sind Regeln festgelegt, wie Felder heissen müssen, die bestimmte Daten beinhalten. So gibt es z.B. nicht mehr logsource oder beat.hostname sondern host.hostname (der Host, auf dem das Event passiert ist, das den Logeintrag ausgelöst hat) und agent.name (Name des Agenten, der die Nachricht verschickt hat – kann der Hostname sein, aber auch ein Custom Name, falls z.b. mehrere Filebeat auf einem Host laufen)

Definiert im ECS sind eine ganze Menge von Überkategorien unter denen dann verschiedene Unterfelder definiert sind, die dann wiederum einen “Level” haben. Der Level gibt an, ob die Felder nach Möglichkeit befüllt werden sollen (“core”) oder eher optional sind (“extended”). Die core-Felder werden auch von diversen Tools des Elastic Stack genutzt, um automatische Auswertungen zu erlauben, was gleich einen riesigen Vorteil des ECS offenbart: Man kann damit viel einfacher fertige Lösungen verschicken, weil man nicht mehr rätseln muss, wie denn die Felder heissen könnten, in denen die wertvollen Informationen stecken.

So wird den meisten langjährigen Usern von Kibana aufgefallen sein, dass es inzwischen eine grosse Menge weiterer Tools in Kibana gibt als die klassischen “Discover”, “Visualize” und “Dashboard”. Die neuen Tools wie SIEM oder Infrastructure verlassen sich darauf, dass die benötigten Informationen in den richtigen Feldern abgelegt sind. Wenn man also ECS umsetzt, dann funktioniert z.B. der SIEM Teil von Kibana mehr oder weniger ohne weiteres zutun.

Im ECS ist auch definiert, welchen Typ welches Feld haben sollte. Sprechen Beats direkt mit Elasticsearch, kümmern sie sich darum, dass das richtig gesetzt wird. Baut man seine eigene Zerlegung in Logstash oder Graylog, dann sollte man darauf achten, dass die Felder auch entsprechend typisiert sind. In den meisten Fällen ergibt sich das aus der Art von Information, die im Feld gespeichert wird automatisch – man sollte dennoch immer wieder mal kontrollieren, ob nicht das eine oder andere durchgeschlüpft ist. Es sollte aber auch nichts dagegen sprechen, die Multifields von Elastic Search zu nutzen. Wird also ein Feld vom Typ keyword gefordert, kann man es auch als string in Elasticsearch schreiben, da der immer sowohl als text und als keyword abgelegt wird.

Der Umstieg

Wer schon ein funktionierendes Logmanagement hat, kann übrigens ziemlich sanft auf ECS umsteigen. ECS erlaubt nämlich ausdrücklich auch, eigene Felder zu definieren. Anders ausgedrückt sollten die relevanten Informationen in den angegebenen Feldern vorhanden sein. Ausser der dabei entstehenden Ressourcenverschwendung spricht aber nichts dagegen, die Daten auch in den zuvor genutzten Feldern vorzuhalten, solange man migriert. Man kann also die Information durchaus duplizieren, falls das nötig ist.

Wer noch ältere Clients im Einsatz hat, muss ohnedies vorsichtig sein, da Elastic die Standardfelder, die automatisch hinzugefügt werden, im Laufe der Zeit in einer nicht abwärtskompatiblen Art verändert hat. So kommen insbesondere Logs, die über Syslog verschickt wurden mit einem host Feld, in dem schlicht der Hostname drin steht. Laut ECS (und damit auch in Events von Beats) ist host aber ein “Nested Field”, das selbst wieder Unterfelder beinhaltet. Schickt man also in den selben Index Events, die man über Syslog-Protokoll erhalten hat und solche, die via Beats eingeliefert wurden, dann hat man leicht einen type mismatch. Dabei ist das nur eines von mehreren möglichen Beispielen. Die Logs von Elasticsearch und Logstash bzw. Graylog zeigen, wenn Events abgelehnt werden und üblicherweise auch wieso.

Eine gewisse Herausforderung ist dabei wieder, sich in die verschiedenen Positionen hineinzuversetzen. Aus Sicht des Logadmins ist der Client vielleicht der Agent, der die Nachricht verschickt, aber aus der Sicht dessen, der die Nachricht zur Überwachung seiner Applikation benötigt, ist der Client der, der mit seiner Applikation gesprochen hat. Dafür gibt es eben eigene Felder wie agent oder event, die Metadaten beinhalten können, die sich nur auf das Logmanagement beziehen, nicht auf den Inhalt der Nachricht. Das Problem ist aber nicht ECS spezifisch, sondern allgemein etwas, das Logadmins plagt.

Abschliessendes

Wer neue Regeln zum Zerlegen von Events anlegt, sollte aber von vornherein darauf achten, dass das ECS eingehalten wird. Dazu sollte man noch ein Feld mitgeben, das die ECS Version anzeigt, um in Kibana für Klarheit zu sorgen und ggf. noch ein paar Regeln kurz vor den Outputs einzuführen, die alte Nachrichten nachbessern. Das haben wir z.B. auch in der Logstash Pipeline für Icinga Logs getan.

Wer sich dazu noch etwas ausführlicher erzählen lassen möchte, kann ja mal in einer unserer Elastic Stack Schulungen vorbei schauen.

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

Logstash automatisiert ausrollen? Freilich!

Der Lennart sagt mir ja immer, ich soll nicht über ungelegte Eier sprechen, aber momentan fasziniert mit das Thema einfach zu viel, als dass ich nicht drüber was schreiben könnte. Dass ich gern mit dem Elastic Stack arbeite, sollten auch weniger aufmerksamere Leser schon mitbekommen haben, aber mit Ansible hab’ ich mich bisher recht zurückgehalten. Da ich aber eigentlich beides ganz gern mag, dachte ich mir, ich verbinde es mal.

 

Mit Ansible ist es wie bei den meisten Configmanagementsystemen: Man fängt mal an, was zu bauen, findet’s gut, lernt was dazu, findet’s nicht mehr gut, baut’s neu, findet’s richtig gut, lernt dazu, findet’s eher mies, baut’s neu, ein Loch ist Eimer, lieber Reinhard, lieber Reinhard.

Deshalb dachte ich, ich bemüh’ mich jetzt mal, eine Rolle für Logstash zu bauen, die man auch wirklich guten Gewissens so rausgeben kann. Falls was nicht so schön ist, gibt’s dann wenigstens die ganzen lieben Leute da draußen, die Pull Requests machen *wink*. Hier also der aktuelle Stand unserer Ansible Rolle für Logstash.

Ich geb’ ja zu, es ist noch eine recht frühe Version, aber sie ist immerhin so gebaut, dass sie umfassend konfigurierbar ist und auch der Linter von ansible-galaxy beschwert sich dabei nicht mehr. Anders ausgedrückt: Sie kann noch nicht extrem viel, aber das, was sie kann, kann sie ziemlich gut, meiner Meinung nach.

Ein schönes Feature, das mir besonders zusagt ist, dass sie einen dazu bringt, die Konfiguration der einzelnen Pipelines in einem Git Repository zu pflegen und zwar ein Repository pro Pipeline. Damit kann man die Rolle schön in Kombination mit unserer Logstash Pipeline für Icinga Logs nutzen. Ein paar Beispielpipelines, die aktuell nur Logs von A nach B schaufeln, habe ich in meinen persönlichen GitHub Account gelegt, von wo sie auch als Beispiele bei der Installation verwendet werden können. Ob das so bleibt, entscheidet sich noch, auf jeden Fall soll die Pipeline mit minimaler oder keiner Konfiguration zumindest mal Basisfunktionalität in Logstash herstellen. Ganz so, wie Elastic das geplant hat – ein einfacher Einstieg für Neulinge. Aber auch ausgefeiltere Setups sind damit möglich.

Besonders gut funktioniert die Rolle übrigens gemeinsam mit einer Rolle für Redis, aber das ist alles in der Readme beschrieben.

Weitere Rollen zum Rest vom Stack werden wohl noch kommen und die Logstash Rolle kann auch noch einiges an zusätzlichen Konfigoptionen brauchen. Lasst Euch also nicht aufhalten, Issues aufzumachen oder Pullrequests zu schicken.

 

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

Viel hilft viel? Nicht immer.

Wenn Systeme gesized werden, fällt üblicherweise bald die Frage: “Was brauchen wir denn besonders viel? CPU? Ram? I/O?” Elasticsearch ist ein schönes Beispiel, in dem man einfach antworten kann: “Alles!” Es braucht CPU, Ram, I/O, Platz, Netzwerkdurchsatz und alles möglichst viel. Tatsächlich braucht es eigentlich möglichst viele Maschinen, die dann jeweils von allem etwas mitbringen – daher auch die Empfehlung, immer auf Hardware zu setzen, weil sonst irgendwas zum Flaschenhals wird (z.B. das SAN).

Es gibt aber eine Ausnahme und schuld ist, wie so oft ( 😉 ): Java. Gibt man Java zu viel Ram, stellt es intern die Verwaltung seiner Pointer um und verliert dadurch so viel Performance, dass man noch ziemlich viel zusätzlichen Ram drauf schmeissen muss, um das wieder auszugleichen. Die genauen Zahlen variieren, liegen aber ungefähr so: Wenn man eine Schwelle überschreitet, die zwischen 30 und 32GB liegt, fällt die Performance so ab, dass man erst bei ca. 46GB wieder auf dem Stand von vor Überschreiten der Schwelle ist. Die ca. 16GB sind also verloren.

Da die Schwelle aber variabel ist, trägt man entweder zu niedrig an oder überschreitet sie unbemerkt. Elasticsearch bietet dabei aber eine einfache Möglichkeit, herauszufinden, ob die Schwelle schon überschritten wurde:

$ curl -s -XGET http://elastic02-hot.widhalm.or.at:9200/_nodes | jq '.nodes[].jvm.using_compressed_ordinary_object_pointers'
"true"
"true"
"true"
"true"
"true"

Dabei fragt man über die API eines Knoten den Zustand aller Knoten ab. Wenn so viele true als Antwort kommen, wie Knoten im Cluster sind, dann ist alles ok. Jedes false zeigt einen Knoten, der zu viel Ram zur Verfügung hat. Gesetzt in /etc/elasticsearch/jvm.options. Als Lösung: Einfach weniger Ram eintragen und die Knoten neu starten (immer nur dann, wenn der Cluster gerade im Status “green” ist)

Wer jq noch nicht installiert hat, sollte das nachholen, da damit wunderbar JSON geparsed werden kann. Ein paar Beispiele gibt’s hier.

Den Check würde ich übrigens regelmässig wiederholen. Ich habe noch keine genauen Daten, wie sich z.B. Updates darauf auswirken und ob sie nicht auch wirklich variabel sein kann.

(Photo by Liam Briese 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...

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

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