Seite wählen

NETWAYS Blog

NETWAYS Azubi-Projektwoche 2022

Wie jedes Jahr gibt es bei NETWAYS auch 2022 wieder eine Azubi-Projektwoche. Hier kommen alle Azubis aus den verschiedenen Abteilungen (Professional Services, Managed Services, Icinga, Finance & Administration, Sales, Event, IT Service Management und Marketing) zusammen und setzen innerhalb einer Woche ein selbst ausgewähltes Projekt um. Letztes Jahr war es aufgrund von Corona leider nicht möglich, die Projektwoche gemeinsam vor Ort durchzuführen, aber zum Glück konnten wir uns dieses Jahr wieder in unserem gemütlichen Kesselhaus treffen.

Am ersten Tag haben wir uns zusammen gesetzt und administrative Aufgaben besprochen. Zum Beispiel wurde Marc Rupprecht als Projektleiter ausgewählt und Ideen für mögliche Projekte gesammelt. Anschließend haben alle zusammen darüber abgestimmt, welches Projekt von unserer Ideenliste wir umsetzen wollen. Ein paar Eckpunkte musste das Projekt erfüllen: Es muss allen Beteiligten Spaß machen und den Nachhaltigkeitsaspekt verfolgen, also so lange wie möglich einen Mehrwert für NETWAYS bieten und zu großen Teilen aus nachhaltigen Materialien bestehen.

Sehr schnell wurde die Idee, Pflanzenkästen mit Smart-Plant-Pi und das NETWAYS-Logo aus Moos zu basteln, in dem Raum gestellt und alle Beteiligten hatten direkt Lust, diese Ideen umzusetzen. So ging es sehr schnell daran, die Gruppen einzuteilen und einen Plan für die Teilprojekte zu erstellen. Um für diesen Blogbeitrag einen Eindruck aus allen Gruppen zu bekommen, wurden den Projektteams verschiedene Fragen gestellt: Wie seid ihr an das Projekt herangegangen, wie habt ihr die Ideen umgesetzt und auf welche Probleme seid ihr gestoßen? Hier sind ihre Antworten:

Team Ab-ins-Beet

Teammitglieder: André Paskowski, Andrew Constant, Leonie Pehle , Nathaniel Donahue, Luxshana Sannathurai, Jonada Hoxha

Im Team Ab-ins-Beet haben wir uns darum gekümmert, die Palettenbeete zu planen, bauen und dann auch zu bepflanzen. Dabei hatten wir jedoch die ein oder andere Hürde zu meistern. Angefangen hat alles mit den Paletten, welche wir gekauft hatten und mit dem Auto transportieren wollten. Blöderweise waren wir zu viert im Auto gesessen, jedoch war es nicht möglich, mit allen Kolleg:innen zurückzufahren, da wir die Rückbank umklappen mussten.
Als Nächstes waren dann die Holzplatten für den Rest des Beetes dran. Diese könnten wir teilweise zuschneiden lassen, mussten aber dennoch oft noch mal nachschneiden, was zum Schluss doch recht zeitaufw
endig war.

Danach ging es ans Streichen und Zusammensetzen der einzelnen Komponenten und zum Schluss konnten wir dann irgendwann die Erde hinzufügen und die ersten Samen vergraben. Alles in allem sind wir trotz anfänglicher Schwierigkeiten zeitlich sehr gut durchbekommen.

 

Jeder hatte seinen Teil, an dem er/sie gearbeitet hat und so haben wir zum Schluss nun zwei fertige Palettenbeete, welche sehr schick aussehen und hoffentlich eine lange Zeit für eine farbenfrohe Terrasse und gut gewürztes Essen sorgen.

Team Islandmoos

Teammitglieder: Yonas Habteab, Nik Schmolzi, Saeid Hassan-Abadi

Im Team Islandmoos haben wir uns um das Mooslogo von NETWAYS gekümmert. Wir haben im Internet total beeindruckende Moosbilder bzw. Mooslogos gefunden. Daher dachten wir auch, dass das gar nicht so schwer sein dürfte. Das hat sich allerdings gerade in der Beschaffung und der Planung des Designs als falsch erwiesen. Wir haben als Team einen gesamten Tag damit verbracht, überhaupt an das richtige Moos zu kommen, da es ein besonderes konserviertes Moos sein muss, damit die Pflege des Logos im Nachhinein gleich null ist. Zudem waren noch weitere Dinge zu erledigen, etwa die Besorgung des richtigen Klebers, des richtigen Holzes und der Überlegung, wo und wie wir das Logo überhaupt in unserem Büro anbringen wollen. Nachdem das abgeschlossen war, haben wir angefangen, unser Holz zu bearbeiten. Wir mussten das Logo maßstabsgetreu vorzeichnen und dann mit einer bestimmten Holzfolie folieren.

Gerade der Mittwoch und Donnerstag bestand dann viel daraus, das Logo zu vollenden. Wir haben vor allem am Donnerstag die meiste Zeit dafür verwendet, das Moos möglichst genau mit Holzleim zu befestigen. Das Ergebnis dieser Ausbildungsprojektwoche von Yonas, Nik und Saeid seht ihr im Pausen- und Meetingraum Nirvana an der Wand.

 

Team flowerPi

Teammitglieder: Patrick Dolinic, Matthias Döhler, Björn Berg

Dem Wunsch nachgehend, das Team Ab-ins-Beet mit Sensoren und IoT (Internet of Things) zu unterstützen, haben sich Matthias, Björn und Patrick für das „flowerPi“ Projekt entschieden. Die drei haben sich verschiedene Möglichkeiten überlegt, wie man mittels Feuchtesensor Alarm schlagen kann, sobald das Beet zu trocken wird. Eine kleine LED könnte leicht übersehen werden, ein Lautsprecher mit nervtötenden Lauten würde die Kolleg:innen zur Weißglut treiben. Es musst eine bessere Lösung her: E-Mails.
Die größte Herausforderung war es, von hinten mit der Arbeit zu beginnen, während die bestellten Sensoren noch unterwegs waren. Da wir die Sensoren noch nicht testen konnten, wurden von Montag bis Mittwoch Installations- bzw. Konfigurationsskripte sowie das eigentliche Prüfskript geschrieben. Diese sollten die Raspberry Pis mit allen nötigen Dateien bestücken, um die Beete zu prüfen und E-Mails zu verschicken.

Nachdem die Sendung endlich angekommen war, haben wir uns auf die Anbindung der Sensoren gestürzt. Etwas zögerlich – keiner von uns hatte damit bisher große Berührungspunkte – haben sie identifiziert, welche Pins sie auf welche Weise ansprechen müssen. Durch etwas Ausprobieren und Planung kamen sie dann zu einem funktionsfähigen Endergebnis, das nur noch (…wetterfest) montiert werden musste.

 

Team Paparazzi

Teammitglieder: Moumen Amneh, Hasan Alherek, Joshua Hartmann

Im Team Paparazzi hatten wir die Aufgaben, Video und Fotomaterial aufzunehmen und diese weiterzuverarbeiten. Wir mussten schauen, dass wir immer bei den Projekten dabei sind, um neues Material aufzunehmen. Daraus wurden dann auch unser Projektvideo geschnitten. Hier gab es eine Schwierigkeit, denn zu einem guten Video gehört auch ein gutes Lied. Es wurde viel Zeit investiert, um ein passendes Lied zu finden, das mit den Aufnahmen harmoniert. Wir haben insgesamt über 500 Bilder und knapp 200 Kurzvideos aufgenommen.

Bei so viel Material mussten wir es natürlich auch noch sortieren und die schönsten Bilder bzw. Videos heraussuchen. Gleichzeitig haben wir auch einen Blogpost und ein Wochenbuch erstellt, das aus kurzen animierten Videos besteht. Als Team Paparazzi waren wir immer bei allen Projekten dabei und haben versucht, unsere Eindrücke so gut wie möglich einzufangen, damit wir diese auch anderen präsentieren können.

 

Ansprechpartner / Projektleiter

Teammitglied: Marc Rupprecht

Wie bereits in der Einleitung dieses Blogposts erwähnt, wurde ich von meinen Azubikolleg:innen zu Beginn der Projektwoche zum Projektleiter gewählt. An dieser Stelle bedanke ich mich bei allen für das Vertrauen und muss sagen: Es hat mir viel Spaß gemacht mit euch zusammen an diesen coolen Projekten zu arbeiten. Doch welche Aufgaben kamen in dieser Position auf mich zu und mit welchen Schwierigkeiten hatte ich zu kämpfen? Hier ein kurzer Überblick:

Die wohl wichtigste Aufgabe, welche mich über die gesamte Woche hinweg beschäftigt hat, war die Verwaltung unseres Projektbudgets. Welcher Betrag sollte zurückgehalten werden, um eventuelle Probleme aufzufangen? Welche Beträge kann ich freigeben und wo muss eine gute Lösung aus dem besten Produkt und dem niedrigsten Preis gefunden werden? Diese Fragen mussten jeden Tag neu bewertet und beantwortet werden.
Neben der Verwaltung des Budgets war ich als Ansprechpartner für Fragen jeder Art gefragt. Woher bekommen wir das Werkzeug, um anständig zu arbeiten, wer fährt mit dem Firmenwagen das Material einkaufen, wo lagern wir unsere (noch nicht) fertigen Teilprojekte, damit sie niemand vor der Abschlusspräsentation zu Gesicht bekommt, sind nur einige der Themen, mit denen ich mich beschäftigen durfte. Neben viel organisatorischem habe ich trotzdem die Zeit gefunden, an einigen Projekten selbst Hand anzulegen, was zu einem guten Ausgleich geführt hat.

Die gerade angesprochene Abschlusspräsentation war zudem etwas, an dem ich seit Tag 1 gearbeitet habe. Wir haben uns dafür entschieden, die Präsentation als Livestream durchzuführen, damit auch die Kolleg:innen im Homeoffice die Möglichkeit haben daran teilzunehmen. Hier stand ich auch vor den ersten wirklichen Schwierigkeiten der Woche, die technische Umsetzung des Livestreams.
Als kompletter Neuling in Sachen Liveübertragung habe ich die Vorbereitungszeit für diese Art der Präsentation ein wenig unterschätzt. Deshalb kam es am Abschlusstag auch zu einigen hektischen Momenten, da der Livestream zunächst nicht wie gewollt gestartet hat und anschließend die Tonspur doppelt bei den Zuschauer:innen angekommen ist. Dank der Hilfe erfahrener NETWAYS Kolleg:innen wurden diese jedoch zeitnah behoben und die Abschlusspräsentation konnte wie geplant stattfinden. Wieder etwas gelernt und für die nächste Azubi-Projektwoche wird mehr Zeit für die Vorbereitung eines Streams eingeplant.

OSMC 2021 | Observability will not fix your broken Monitoring , or Culture

This entry is part 5 of 23 in the series OSMC 2021

OSMC 2021 has been over for almost three months now. It was a pretty interesting conference, and also my first one as a trainee at NETWAYS. The two-day conference including a workshop and hackathon was all about open source monitoring software like Icinga2, CheckMK or Prometheus.
Today I give you some insights about one of the talks:

About the Speaker

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. He is frequently speaking at or organizing different international conferences and has written about the same subjects in different Books, Papers and Articles. He spends most of his time working on bridging the gap between developers and operations with a strong focus on High Availability, Scalability, Virtualisation and Large Infrastructure Management projects hence trying to build infrastructures that can survive the 10th floor test, better known today as the cloud while actively promoting the devops idea!

The difference between Monitoring and Observability

Plenty of companies are jumping on a new hype train, Observability. The hope that is associated with the new technology: a replacement of the „legacy“ monitoring stack.
In his talk Kris Buytaert took a look at this development and pointed out why it is a wrong approach for a lot of people. To understand the problems that could come up with the implementation of Observability, he first introduced the differences between Monitoring and Obervability.

What is Monitoring?

So what exactly is monitoring? Summarizied in one question: what is going on in my system?
With this question in mind, experts look at a system to figure out the following points (and some more):

– High level overview of the state of a service or component
– Availability of this services
– Technical components of your setup
– What is the performance of my setup

What is Observability?

Observability on the other hand is trying to answer the question: Why is this going on?
For example, your services behave in a way that they shouldn’t because you or your colleagues didn’t tell the system to do this. With the help of Observability software you could figure out why your tech is behaving the way it is.
In practice Observability consists of three pilars:
Metrics
Logs
Traces

Whats your goal in observability?

After the short introduction of the differences between monitoring and observability, Kris Buytaert showcased some examples of failed implementation of observability. What all of the situations have in common? There was no flawless instance of monitoring on which the observability was placed.

But why are an increasing number of companies who turn to observabilty and what’s the goal of of this development?

In his talk he listed some reasons he experienced himself when talking to companies and employees:

– Expectation of increasing performance problems
– Already existing performance problems
– The monitoring data is chaos, observability will fix it and give a better insight in what is running in the system
– More hipster credit (e.g. ‚Our company is so advanced. We take on every new trend to show how progressive we are.‘)

The first steps of implementing observability

To end his talk, the speaker gave a few helpful first steps for everyone who is thining about implementing obervability.

1. Fix your monitoring. It can be an automated single source of truth about what is going on in your system.
2. Keep it GREEN!
3. Fix your metrics. Check if logshipping is partially broken, if theres a regression on shipping your metrics or if you have a broken dashboard.

Apart form the technical standpoint the speaker encourages everyone to ask some important questions before the implementation of a new system:

– Who exactly wants Observability? Is it the devs and ops or is it the upper management who insists on trying out something new.
– What do they really want? Do they really want Observability or are there other reasons they want it in your system.
– Will a new system fit into my existing ecosystem? If a vendor claims it works out of the box for everyone but your developers say it doesn’t…Trust your devs!

As the last words in his talk Kris Buytaert had some advice: ‚You might not need Observability (yet) but you do need to fix your monitoring.‘

 

Full talk and more from and about OSMC 2021

Watch the whole talk by Kris Buytaert here:

YouTube player

 

Since OSMC 2021 is unfortunately over we still have something for you: Did you already check out this year’s conference archives? They provide you slides and videos of each talk and also some photographs of the conference itself.

OSMC 2022 will take place from November 14 – 16 and we’re already looking forward  to meeting you all again!

Stay tuned!

Mini-NAS mit Raspberry Pi & OpenMediaVault

Als Auszubildender zum Fachinformatiker für Systemintegration im ersten Lehrjahr bei NETWAYS darf ich regelmäßig neue Projekte bearbeiten. Das Ziel der Projekte: Wissensaufbau und Verständnis für die zugrunde liegende Technik und Software entwickeln.
Im Rahmen meines aktuellen Projektes setze ich mich mit der Einsatzmöglichkeit eines Raspberry Pi 4 als Network-attached storage (NAS) auseinander. Um sich als Einsteiger mit dem Konzept NAS und den Konfigurationsmöglichkeiten vertraut zu machen, ist die Open Source Software OpenMediaVault (OMV) eine sehr gute Einstiegsmöglichkeit. Mit ihrer Hilfe lässt sich unkompliziert und innerhalb kurzer Zeit ein voll funktionstüchtiges NAS installieren und konfigurieren.

In diesem Blogpost erkläre ich dir, wie du schnell und einfach OpenMediaVault auf einem Raspberry Pi installieren kannst.

Was ist OpenMediaVault?

OpenMediaVault ist eine moderne, auf Debian basierende NAS-Lösung. Die Software unterstützt mit FTP, TFTP, SMB/Samba, NFS, SNMP und SSH die gängigsten Protokolle für den Fernzugriff. Dadurch kann von (fast) jedem Gerät auf die gespeicherten Daten zugegriffen werden, egal ob PC, Laptop oder Smartphone.

Eine besonders wichtige Rolle spielt Samba. Das dazugehörige SMB-Protokoll wird von Linux, Microsoft Windows, macOS sowie Android unterstützt und ist somit das ideale Protokoll für den Cross-Platform-Zugriff.

Die Datensicherung kann unter anderem mit RSync durchgeführt werden. Dafür müssen lediglich ein Quell- sowie ein Zielordner angegeben werden.
Neben den von Haus aus vorhandenen Funktionen lässt sich OMV mit unterschiedlichen Plug-ins erweitern und an die eigenen Bedürfnisse anpassen.

Zusätzlich zu seiner umfassenden Funktionalität ist OpenMediaVault zudem äußerst Einsteiger- und Benutzerfreundlich. Das zeigt sich unter anderem an der grafischen Weboberfläche, die es allen Nutzer:innen, unabhängig vom IT-Wissen, erlaubt mit dem Browser auf OMV zuzugreifen und die Software zu konfigurieren.

Die Entwickler:innen selbst bezeichnen ihr Produkt als eine „Out-of-the-box-Lösung die es jeder Person, auch ohne technisches Vorwissen, möglich macht ein NAS zu installieren und zu verwalten.“

Technische Voraussetzungen

Damit ein NAS mithilfe von OpenMediaVault auf dem Rapsberry Pi installiert und konfiguriert werden kann, müssen einige technische Voraussetzungen erfüllt werden.
Du benötigst:

  • Raspberry Pi 4 mit Raspberry Pi OS Full oder Raspberry Pi OS lite (Versionen ab Raspberry Pi 2B sind ebenfalls möglich)
  • microSD-Karte (idealerweise 8GB Speicherkapazität)
  • Aktive Ethernet- oder WiFi-Verbindung des Raspberry Pi
  • Externes Speichermedium (z.B. Festplatte, USB-Stick) mit dem gewünschten Speicherplatz
  • Raspberry Pi HDMI-Kabel (falls der Pi mit einem Bildschirm verbunden werden muss)

Installation von OpenMediaVault

–HINWEIS–
Nach der Installation von OpenMediaVault kann der Raspberry Pi problemlos ohne Monitor betrieben werden. Da für den Zugriff auf die Weboberfläche jedoch die IP-Adresse des Pi benötigt wird, sollte für die Dauer des Installationsvorgangs ein Monitor angeschlossen sein.

Das Versprechen der Benutzerfreundlichkeit hält OpenMediaVault bereits bei der Installation ein. Sie umfasst lediglich fünf Schritte, wovon vier der Aktualisierung bzw. der Informationsfindung dienen.

  • Update und Aktualisierung der bereits auf dem Raspberry Pi installierten Softwarepakete
sudo apt update 
sudo apt upgrade
  • Installation des OpenMediaVault – Softwarepakets
wget -O - https://raw.githubusercontent.com/OpenMediaVault-Plugin-Developers/installScript/master/install | sudo bash
  • Nach Abschluss der Installation ist ein Neustart des Raspberry Pi empfehlenswert
sudo reboot
  • Abfragen der IP-Adresse des Pi
hostname -I

ODER

ip -a
  • Aufrufen der IP-Adresse im Browser der Wahl
    Wenn das folgende Eingabefenster erscheint, war die Installation erfolgreich:

Die standardmäßigen Anmeldedaten von OpenMediaVault lauten:

username: admin
password: openmediavault (aus Sicherheitsgründen sollte das Passwort direkt nach dem ersten Login in ein sicheres Passwort geändert werden.)

Damit ist die Installation von OpenMediaVault auf dem Raspberry Pi abgeschlossen. Welche Konfigurationsmöglichkeiten bestehen, auf welche Art und Weise auf das NAS zugegriffen wird und vieles mehr, bleibt dem Nutzer selbst überlassen.

Die folgenden Guides behandeln eine Erstkonfiguration der Software:

Wenn du einen Ausbildungsplatz als Fachinformatiker:in für Systemintegration suchst, Lust auf spannende und abwechslungsreiche Projekte hast (die stets auf deinen persönlichen Wissensstand abgestimmt sind) und Teil eines modernen IT-Unternehmens werden willst, bist du du bei NETWAYS an der richtigen Adresse.

OSMC 2021 | On the Bleeding Edge of OpenTelemetry

This entry is part 2 of 23 in the series OSMC 2021

OSMC 2021 has been over for about a month now. It was a pretty interesting conference, and also my first one as a trainee at NETWAYS. The two-day conference including a workshop and hackathon was all about open source monitoring software like Icinga2, CheckMK or Prometheus.
Today I give you some insights about one of the talks:

 

About the Speaker

Philipp Krenn is a development advocate and EMEA team lead at the american-dutch company Elastic NV, best known for the Elastic Stack. Most of his time he is traveling Europe and beyond to speak and discuss open source software, search, databases, infrastructure and security. At the Open Source Monitoring Conference 2021 in Nuremberg he’s shown his passion to demo interesting technology, when he introduced the audience to OpenTelemetry.

 

What is OpenTelemetry?

OpenTelemetry (OTel) is an open source project, which is backed by the CNCF (Cloud Native Computing Foundation). The CNCF is a project founded in 2015 by the Linux Foundation to help advance container technology and to align the big tech companies around its evolution.

OpenTelemetry combines traces, metrics and logs. With this approach the plan is to unify instrumentation and down the road replace OpenTracing and OpenCensus.
One key factor of the new tool is its vendor neutrality. The compatibility and interoperability approach has wide support throughout the telemetry industry, including global players like Google, Elastic or Splunk.

Including the forementioned companies, a lot of vendors are helping to build OpenTelemetry, while almost everyone who works in the observability space is more or less standardizing in OpenTelemetry right now.

What problem can OpenTelemetry solve?

The question you might be asking right now is: why should I start using OpenTelemetry?
If it’s about logging/events, you can use the Elastic Stack. And you are right. But especially in a distributed environment with multiple instances of an application, load balancing and databases, to recognize and analyze issues you also need metrics and traces.

Metrics can help you to identify bottlenecks in your infrastructure and outputs them in measurable numbers, while traces give you a much-needed overview to understand what happens when an application is running as well as the possibility to retrace e.g. the way of a customer or a session through the entire system.

With all of these parameters combined in one software as well as the targeted goal as industry standard, there are going to be multiple advantages like time saved by not having to develop the right agent or a new layer of communication.

 

Three Ways to integrate an application in OpenTelemetry

To use OpenTelemetry in your projects, it is necessary to integrate your application into OTel. There are three different options available for you to do this, while the vendor can implement one or more of these.

Your possibilities are:

  •  You have your application in whatever language you want together with the OpenTelemetry agent. Within every agent of every language you have something called vendor exporter who can talk to the backend of the vendor you are using. This way is not the ideal one because everything after the OpenTelemetry agent, e.g. wire protocoll, is from the vendor. Because of this, you have to write the vendor exporter for every single programming language and even constantly maintain it.
  • The second option is the OpenTelemetry collector. With this approach, the agent speaks the language of the OpenTelemetry protocol and sends his information to your centralized collector. A vendor exporter is located in the collector, from where your data is transferred to your vendor. A big benefit of this approach is that you only need one exporter for all applications, instead of one for every application.
  • The last way is to push back the vendor and his protocol even more. For this approach, your agent speaks the OpenTelemetry protocol, while the vendor just takes the protocol and implements it in his workflow. This option can be described as vendor neutral because you only need to implement the OTel protocol and not like in e.g. possibility one must have an agent in every language for every one of your applications.

 

What you can see in the OpenTelemetry demo

After explaining a lot of background information to the possibilities of OpenTelemetry, Philipp Krenn used one third of his speaking time to show a demo of what the program can do.
He demonstrated the combination of a java agent and elastic exporter as collector. With this setup, all the information is transferred to the Elastic Stack, so the storage takes place in Elastic Search while it is displayed in Kibana.

As a speciality he explains the preloading that is possible with java. He also talks about how this procedure works for other languages and shows how to implement your own information apart from the ones available as standard.
If you want to learn more about the possibilities OpenTelemetry has to offer, check out their Homepage for further and more in-depth information.

 

Full talk and more from and about OSMC 2021

Watch the whole talk by Philipp Krenn here:

YouTube player

 

Since OSMC 2021 is unfortunately over we still have something for you: Did you already check out this year’s conference archives? They provide you slides and videos of each talk and also some photographs of the conference itself.

OSMC 2022 will take place from November 14 – 16 and we’re already looking forward  to meeting you all again!

Stay tuned!