Select Page

Results for "119"

OSMC 2015: Der Countdown läuft – nur noch 119 Tage

Gerhard Laußer mit “Monitoring von Netzwerkkomponenten mit check nwc health”

OSMC? Was soll das denn sein und wer sind die netten Menschen in diesen Videos? Die Open Source Monitoring Conference (kurz: OSMC) ist die internationale Plattform für alle an Open Source Monitoring Lösungen Interessierten, speziell Nagios und Icinga. Jedes Jahr gibt es hier die Möglichkeit sein Wissen über freie Monitoringsysteme zu erweitern und sich mit anderen Anwendern auszutauschen. Die Konferenz richtet sich besonders an IT-Verantwortliche aus den Bereichen System- und Netzwerkadministration, Entwicklung und IT-Management. Und die netten Menschen, die Ihr in unseren Videos zur OSMC seht, gehören dazu. 2015 wird die OSMC zum 10. Mal in Nürnberg stattfinden.

This was stackconf 2024 | Recap & Pictures

stackconf 2024 has come and gone, leaving a lasting impression on its community. This year’s conference, held in Berlin, was absolutely amazing. From inspiring talks on cloud native & IT infrastructure solutions to lively networking sessions and a fantastic evening event, stackconf 2024 was a hub of innovation and collaboration. Here’s a quick recap of the event and a behind-the-scenes look, along with some memorable images.

The Conference Program

The program at stackconf 2024 featured many expert speakers who gave inspiring talks on cloud-native and IT infrastructure solutions. They covered topics like cloud infrastructure and disaster recovery, AI and security, DevOps and automation, and software development and deployment. The sessions were informative and engaging, offering valuable insights for both seasoned professionals and newcomers. Thanks to our outstanding speakers! It was an absolute pleasure to have you here!

Our Sponsors

Big thank you to our sponsors of stackconf 2024! Eliatra and NETWAYS Web Services were supporting the conference as silver sponsors, and Xyntion and STACKIT contributed as bronze sponsors. We also value the support of our media partners GermanTechJobs, Linux Magazin and Kube Events. We’re really happy about your contribution and love to hear your amazing feedback about this sponsorship opportunity. Your support helped make stackconf 2024 a success, enabling us to bring together industry experts and enthusiasts for an enriching experience. Thank you for being a vital part of our event!

The stackconf Team

A heartfelt thank you to our incredible team for their hard work and dedication in making stackconf 2024 a success. From capturing great pictures, managing social media, coordinating the camerawork, and moderating sessions, to organizing the entire event and creating engaging blog posts, your efforts were invaluable. Your commitment ensured everything ran smoothly and made the conference an unforgettable experience for all attendees.

The Evening Event

The evening event at stackconf 2024 was also unforgettable, mainly because most attendees arrived drenched from a sudden heavy rain. Despite the weather, it was a great atmosphere. There was a roulette table, and Andreas Hering won a Lego DeLorean set as the clear winner. The food was delicious, and overall, it was a fantastic opportunity for networking and enjoying good company.

 

Stay Tuned!

The date for stackconf 2025 will be announced shortly. Be sure to follow us on LinkedIn to get the latest news, submission, and ticket deadlines.
In addition, the archives including recordings and speaker slides will be online soon!

 

Katja Kotschenreuther
Katja Kotschenreuther
Manager Marketing

Katja ist seit Oktober 2020 Teil des Marketing Teams. Als Manager Marketing kümmert sie sich um das Marketing für die Konferenzen stackconf und OSMC, die DevOpsDays Berlin, Open Source Camps, sowie unsere Trainings. In ihrer Freizeit reist sie gerne, bastelt, backt und im Sommer kümmert sie sich außerdem um ihren viel zu großen Gemüseanbau.

Monitoring-Plugin check_system_basics: Erstes Release!

Für das Basis-Monitoring von Linux-Maschinen existieren viele Plugins im Monitoring-Universum. Grundlegende Änderungen an den zugrunde liegenden Schnittstellen sind eher selten, da viele Programme sehr langfristig darauf aufbauen. Deshalb erfüllen aktuelle Lösungen teilweise seit Jahrzehnten noch ihre Aufgabe.
Nichtsdestotrotz gibt es gelegentlich neue Schnittstellen, etwa die Pressure Stall Information”-Schnittstelle des Linux Kernels, die entweder als Ersatz für bisherige Ansätze dienen (“load”) oder als Ergänzung, um eine andere Perspektive hinzufügen.

Einführung in check_system_basics

Unabhängig von den zugrunde liegenden Schnittstellen zum System, ist die Schnittstelle zum Monitoringsystem selbst (in unserem Fall typischerweise Icinga) an sich deutlich flexibler. Hier haben sich Gewohnheiten etabliert, die aber nicht unbedingt immer den optimalen Ansatz abbilden oder der Kontext hat sich mit der Zeit gewandelt und dementsprechend ist der damalige Ansatz heute nicht mehr ganz zeitgemäß.

Aus dem Wunsch heraus, die oben genannten Probleme anzugehen und eine Lösung zur Linux Systemüberwachung anzubieten ist das Monitoring Plugin “check_system_basics” hier bei NETWAYS entstanden. Die Idee ist dahinter ist, grundlegende Systemeigenschaften mit einer möglichst konsistenten und eingängigen Parametrisierung und einer ästhetisch ansprechenden Ausgabe testen zu können. Zusätzlich wurden eine einfachere Wartung sowie die Möglichkeit der modularen Entwicklung als Ziele formuliert. Um das zu erreichen wurde Golang als Programmiersprache gewählt. Dabei dient die hauseigene Bibliothek go-check als Basis für die Funktionalität.

Kernfunktionen von check_system_basics

check_system_basics bietet in seiner aktuellen Version (also während des Verfassens dieses Blogposts) sechs verschiedene Modi, die auf spezifische Aspekte der Systemgesundheit und Leistungsfähigkeit ausgerichtet sind. Die Modi reichen von der Speicher- und Swapspeichernutzung bis zum Zustand des Netwerk-Interfaces.

Memory

Dieser Modus befasst sich mit dem Erfassen und Bewerten der Arbeitsspeicher- und Swapspeicher-Nutzung.
Im einfachsten Fall sieht die Benutzung schlicht so aus:

# ./check_system_basics memory 
[OK] - states: ok=2 
\_ [OK] RAM 
  \_ [OK] Available Memory (27 GiB/31 GiB, 85.49%) 
  \_ [OK] Free Memory (24 GiB/31 GiB, 76.17%) 
  \_ [OK] Used Memory (4.0 GiB/31 GiB, 12.74%) 
\_ [OK] Swap Usage 0.00% (0 B / 32 GiB) 
|available_memory=28686442496B;;;0;33554198528 free_memory=25557921792B;;;0;33554198528 used_memory=4274946048B;;;0;33554198528 swap_used=0B;;;0;3423390515

Arbeitsspeicher- und Swap-Nutzung werden hier zusammengefasst, da sie zusammenhängen und semantisch in einen gemeinsamen Bereich fallen. Die Absicht hinter der Formatierung der Ausgabe ist es, die Teilbereiche getrennt darzustellen, aber gleichzeitig eine schnelle Erfassung aller wichtigen Werte zu ermöglichen. Auch eigentlich redundante Werte (wie die Prozentangabe) sind hier enthalten, um möglichst alle offenen Fragen auf einmal beantworten zu können.
Die Parametrisierung der Checks kann fein-granular gegen spezifische Messwerte vorgenommen werden und in absoluten oder relativen Werten erfolgen.

Eine Übersicht über die verfügbaren Parameter kann mit

# ./check_system_basics memory --help

generiert werden.

Filesystem

Dieser Modus befasst sich mit den im System eingehängten Dateisystemen. Klassischerweise wird hier check_disk verwendet, das aber ein paar (subjektive) Nachteile aufweist.

Der erste davon ist bereits die Namensgebung, wobei dies vermutlich schon sehr von der persönlichen Perspektive abhängt. Tatsächlich ist der Betrachtungsgegenstand keine “Disk”, also ein magnetischer Festspeicher mit rotierenden Scheiben, sondern die darauf abgelegten Dateisysteme. Zudem ist die einzeilige Darstellung schon bei einer relativ geringen Anzahl von Dateisystemen unübersichtlich. Diese Ausgabe ist der historischen Limitierung auf eine einzige Ausgabezeile geschuldet, eine Beschränkung, die oft nicht mehr existiert. Auch hier wird zur besseren Übersichtlichkeit eine Darstellung als “Baum” gewählt:

[OK] - states: ok=5 
\_ [OK] / (42.11% used space, 83.54% free inodes) 
    \_ [OK] Space usage 
        \_ [OK] Percentage of free space: 57.89% 
    \_ [OK] Inodes 
        \_ [OK] Percentage of used inodes: 16.46% 
\_ [OK] /snap (42.11% used space, 83.54% free inodes) 
    \_ [OK] Space usage 
        \_ [OK] Percentage of free space: 57.89% 
    \_ [OK] Inodes 
        \_ [OK] Percentage of used inodes: 16.46% 
\_ [OK] /boot (43.19% used space, 99.72% free inodes) 
    \_ [OK] Space usage 
        \_ [OK] Percentage of free space: 56.81% 
    \_ [OK] Inodes 
        \_ [OK] Percentage of used inodes: 0.28% 
\_ [OK] /var (75.22% used space, 92.84% free inodes) 
    \_ [OK] Space usage 
        \_ [OK] Percentage of free space: 24.78% 
    \_ [OK] Inodes 
        \_ [OK] Percentage of used inodes: 7.16% 
\_ [OK] /home (49.32% used space, 94.45% free inodes) 
    \_ [OK] Space usage 
        \_ [OK] Percentage of free space: 50.68% 
    \_ [OK] Inodes 
        \_ [OK] Percentage of used inodes: 5.55% 
|/_space_free=34419593216B;;;0;62669000704 /_space_used=25032798208B;;;0;62669000704 /_space_used_percentage=42.106% /_space_free_percentage=57.894%;5:100;2:100 /_inodes_free=3264260;;;0;3907584 /_inodes_used=643324;;;0;3907584 /_inodes_free_percentage=83.537% /_inodes_used_percentage=16.463%;99;98 /snap_space_free=34419593216B;;;0;62669000704 /snap_space_used=25032798208B;;;0;62669000704 /snap_space_used_percentage=42.106% /snap_space_free_percentage=57.894%;5:100;2:100 /snap_inodes_free=3264260;;;0;3907584 /snap_inodes_used=643324;;;0;3907584 /snap_inodes_free_percentage=83.537% /snap_inodes_used_percentage=16.463%;99;98 /boot_space_free=265634816B;;;0;493201408 /boot_space_used=201981952B;;;0;493201408 /boot_space_used_percentage=43.194% /boot_space_free_percentage=56.806%;5:100;2:100 /boot_inodes_free=124580;;;0;124928 /boot_inodes_used=348;;;0;124928 /boot_inodes_free_percentage=99.721% /boot_inodes_used_percentage=0.279%;99;98 /var_space_free=58994331648B;;;0;250843787264 /var_space_used=179032711168B;;;0;250843787264 /var_space_used_percentage=75.215% /var_space_free_percentage=24.785%;5:100;2:100 /var_inodes_free=14510565;;;0;15630336 /var_inodes_used=1119771;;;0;15630336 /var_inodes_free_percentage=92.836% /var_inodes_used_percentage=7.164%;99;98 /home_space_free=241836023808B;;;0;502813065216 /home_space_used=235360329728B;;;0;502813065216 /home_space_used_percentage=49.321% /home_space_free_percentage=50.679%;5:100;2:100 /home_inodes_free=29518844;;;0;31252480 /home_inodes_used=1733636;;;0;31252480 /home_inodes_free_percentage=94.453% /home_inodes_used_percentage=5.547%;99;98

Die erste Ebene in diesem “Baum” sind die einzelnen Dateisysteme, die zweite Ebene sind Tests auf bestimmte Eigenschaften des Dateisystems. In diesem einfachen Beispiel sind die Eigenschaften die Nutzung des Speicherplatzes und der Inodes. Mit diesem Schema sollte sehr schnell erkennbar sein, welches Dateisystem welchen Problemzustand aufweist.

Die Parametrisierung erlaubt hier das Eins- und Ausschließen von Dateisystemen basierend auf dem Dateisystemtyp, dem Pfad des zugrundeliegenden Gerätes, dem Einhängepfad und der verwendeten Einhängeoptionen, sowie natürlich das Setzen von Grenzwerten für die Auslastung.

Die möglichen Parameter können wiederum mittels --help ausgegeben werden:

# ./check_system_basics filesystem --help

Als Anmerkung sei hier noch zu erwähnen, dass bewusst auf die Möglichkeit, unterschiedliche Grenzwerte für verschiedene Dateisysteme festzulegen, verzichtet wurde. Die Verwendung alternativer  Plugins, etwa check_disk wird dadurch unnötig kompliziert und es ist einfacher diese Logik im Monitoringsystem selbst abzubilden.

PSI

Wie bereits weiter oben erwähnt ist die “PSI” (“Pressure Stall Information”)-Schnittstelle relativ neu im Linux Kernel ( ~2018 ) und hat vergleichsweise selten Einzug in Monitoringsysteme gefunden. Ein
tragischer Umstand, da sie gute Metriken zur Erkennung einer Ressourcenknappheit bietet.

An dieser Stelle soll keine tiefere Diskussion zu einzelnen Werte stattfinden, dafür kann auf die entsprechende Dokumentation verwiesen werden. Kurz zusammengefasst erhält man durch die PSI-Schnittstelle Prozentangaben wie stark die Ressourcen “CPU”, “IO” (Daten lesen oder schreiben) und “Memory” überlastet sind.
Damit ist es ein besserer Ersatz für die noch weit verbreitete Betrachtung und Interpretation von load-Werte.

Die simple Ausführung sieht dann wie folgt aus:

[OK] - states: ok=3
\_ [OK] CPU Full Pressure - Avg10: 0.00, Avg60: 0.00, Avg300: 0.00
\_ [OK] IO Pressure - Avg10: 0.05, Avg60: 0.04, Avg300: 0.00
\_ [OK] Memory Pressure - Avg10: 0.00, Avg60: 0.00, Avg300: 0.00
|cpu-some-avg10=0%;@30:100;@95:100;0;100 cpu-some-avg60=0%;@30:100;@95:100;0;100 cpu-some-avg300=0%;@30:100;@95:100;0;100 cpu-some-total=10431234c;@30:100;@95:100;0 cpu-full-avg10=0%;@30:100;@95:100;0;100 cpu-full-avg60=0%;@30:100;@95:100;0;100 cpu-full-avg300=0%;;;0;100 cpu-full-total=0c;;;0 io-some-avg10=0.05%;@30:100;@95:100;0;100 io-some-avg60=0.04%;@30:100;@95:100;0;100 io-some-avg300=0%;@30:100;@95:100;0;100 io-some-total=35037331c;@30:100;@95:100;0 io-full-avg10=0.05%;@30:100;@95:100;0;100 io-full-avg60=0.04%;@30:100;@95:100;0;100 io-full-avg300=0%;;;0;100 io-full-total=34421878c;;;0 memory-some-avg10=0%;@30:100;@95:100;0;100 memory-some-avg60=0%;@30:100;@95:100;0;100 memory-some-avg300=0%;@30:100;@95:100;0;100 memory-some-total=57c;@30:100;@95:100;0 memory-full-avg10=0%;@30:100;@95:100;0;100 memory-full-avg60=0%;@30:100;@95:100;0;100 memory-full-avg300=0%;;;0;100 memory-full-total=57c;;;0

Die Unterteilung erfolgt hier in die drei oben genannten Bestandteile und dort jeweils in die Werte für 10, 60 und 300 Sekunden. Diese sind so dem Kernel entnommen und wurden nicht über diese Zeiten gemessen, check_system_basics legt hier keinen Zustand im Dateisystem ab.

Die meisten Werte der Schnittstelle sind Prozentangaben, 0% bedeutet keine Überlastung, 100% eine vollständige.

Auch hier zeigt die Hilfe --help die möglichen Parameter an:

# ./check_system_basics psi --help

Zu beachten ist, dass die “PSI”-Schnittstelle nicht zwangsläufig aktiviert sein muss, manche Distributionen deaktivieren die Option normalerweise um etwas Leistung einzusparen. Wie dies geändert werden kann, ist jeweils in der Dokumentation der Distribution nachzulesen.

Load

Aus Gewohnheits- und Vollständigkeitsgründen ist ebenfalls eine Abfrage und Bewertung der “load”-Metrik enthalten:

[OK] - states: ok=3
\_ [OK] 1 minute average: 0.04
\_ [OK] 5 minute average: 0.06
\_ [OK] 15 minute average: 0.08
|load1=0.04;;;0 load5=0.06;;;0 load15=0.08;;;0

Parameter können mit der --help Flag ausgelesen werden:

# ./check_system_basics load --help

Sensors

Dieser Modus ist eher spartanisch, da er keine Parameter zur Konfiguration der Grenzwerte besitzt. Grundsätzlich liest und gibt check_system_basics hier die Werte der vom Kernel erkannten Hardwaresensoren aus. Damit kann z.B. der Temperaturverlauf in der CPU erfasst werden.

Auch ohne Grenzwerte kann dieser Modus einen Alarm auslösen, da der Kernel selbst Grenzwerte für bestimmte Sensoren hat und diese auch zur Verfügung stellt. Wenn nun ein Sensor nicht im “grünen” Wertebereich liegt, wird dies ebenfalls vom Monitoring-Plugin erfasst und dementsprechend ein Nicht-OK-Zustand ausgegeben, mit der Angabe, um welchen Sensor es sich handelt.

[OK] - states: ok=6
\_ [OK] acpitz
    \_ [OK] acpitz_temp1: Ok - 41C
\_ [OK] BAT1
    \_ [OK] BAT1_in0: Ok - 17.413V
    \_ [OK] BAT1_curr1: Ok - 0A
\_ [OK] nvme
    \_ [OK] Composite: Ok - 37C
\_ [OK] ACAD
\_ [OK] coretemp
    \_ [OK] Package id 0: Ok - 43C
    \_ [OK] Core 0: Ok - 39C
    \_ [OK] Core 1: Ok - 40C
    \_ [OK] Core 2: Ok - 39C
    \_ [OK] Core 3: Ok - 38C
\_ [OK] iwlwifi_1
    \_ [OK] iwlwifi_1_temp1: Ok - 47C
|acpitz_temp1=41C;;~:210 BAT1_in0=17.413V BAT1_curr1=0A Composite=37C;~:83;-5:87  'Package id 0'=43C;~:100;~:100 'Core 0'=39C;~:100;~:100 'Core 1'=40C;~:100;~:100 'Core 2'=39C;~:100;~:100 'Core 3'=38C;~:100;~:100 iwlwifi_1_temp1=47C

Netdev

Das letzte Element in dieser Liste bildet der netdev-Modus. Zu diesem Zeitpunkt noch sehr eingeschränkt, wird lediglich eine Warnung ausgegeben, wenn Netzwerk-“interfaces” nicht “up” sind und die Werte einiger Zähler der jeweiligen “interfaces” ausgegeben.

[WARNING] - states: warning=3 ok=2
\_ [OK] wlp170s0 is Up
\_ [WARNING] docker0 is Down
\_ [WARNING] tun0 is Unknown
\_ [WARNING] virbr0 is Down
\_ [OK] enx00e04c6801bd is Up
|wlp170s0_rx_bytes=3597690 wlp170s0_rx_errors=0 wlp170s0_rx_dropped=12914 wlp170s0_rx_packets=28422 wlp170s0_tx_bytes=338558 wlp170s0_tx_errors=0 wlp170s0_tx_dropped=0 wlp170s0_tx_packets=1441 docker0_rx_bytes=0 docker0_rx_errors=0 docker0_rx_dropped=0 docker0_rx_packets=0 docker0_tx_bytes=0 docker0_tx_errors=0 docker0_tx_dropped=0 docker0_tx_packets=0 tun0_rx_bytes=50674521 tun0_rx_errors=0 tun0_rx_dropped=0 tun0_rx_packets=53663 tun0_tx_bytes=5252457 tun0_tx_errors=0 tun0_tx_dropped=0 tun0_tx_packets=36064 virbr0_rx_bytes=0 virbr0_rx_errors=0 virbr0_rx_dropped=0 virbr0_rx_packets=0 virbr0_tx_bytes=0 virbr0_tx_errors=0 virbr0_tx_dropped=0virbr0_tx_packets=0 enx00e04c6801bd_rx_bytes=69051761 enx00e04c6801bd_rx_errors=0 enx00e04c6801bd_rx_dropped=13077 enx00e04c6801bd_rx_packets=225219 enx00e04c6801bd_tx_bytes=19850102 enx00e04c6801bd_tx_errors=0 enx00e04c6801bd_tx_dropped=0 enx00e04c6801bd_tx_packets=149016

check_system_basic: Installation

Das Plugin kann einfach von Github heruntergeladen werden, entweder als fertig kompiliertes Programm in den Releases oder natürlich im Quellcode zum selbst kompilieren.
Alternativ ist das Plugin auch für einige gängige Distributionen verfügbar.

Für Icinga-Benutzer ist die Integration zusätzlich vereinfacht, die Option --dump-icinga2-config generiert die notwendige Konfiguration als CheckCommand, beispielhaft etwa:

./check_system_basics --dump-icinga2-config > /etc/icinga2/zones.d/global-templates/commands.d/check_system_basics.conf

Feedback, Wünsche und Probleme

Da es sich hier noch um eine recht neue Entwicklung handelt, ist der Umfang der Optionen und Möglichkeiten noch recht gering. Der Fokus liegt aktuell zunächst darauf, eine Basisfunktionalität zu schaffen, die minimal und “sauber” ist. Über Wünsche und Ideen freuen wir uns als Entwickler:innen sehr, natürlich auch über die Meldung von Problemen und Bugs. Und selbstverständlich auch einfach nur über eine Meldung, wenn etwas gut funktioniert 🙂

Lorenz Kästle
Lorenz Kästle
Systems Engineer

Lorenz hat seinen Bachelor der Informatik an der FAU gemacht und sich zuletzt mit Betriebssystemen dort beschäftigt. In seiner Freizeit beschäftigt er sich ein wenig mit XMPP und der Programmiersprache Erlang.

NETWAYS Chefs | Azubis grillen – Teil 1/2

This entry is part 16 of 19 in the series NETWAYS Chefs

Als vor einer Weile unsere Catharina das neue Konzept für NETWAYS Chefs verkündet hat, hab ich sofort das Team “Zentrale Ausbildung” für August eingetragen. Da zu dem Zeitpunkt eh ein gemeinsames Projekt anstand, war die Zeit dafür vorhanden und für mich ist es eine super Teambuilding-Maßnahme. Die Auszubildenden waren aus unterschiedlichen Gründen begeistert. Für die einen war es eine Chance, sich in der Küche auszutoben, für die anderen eine gratis Mahlzeit! 😉

Die ersten Ideen wurden immer mal wieder besprochen und es zeichnete sich schnell passend zum Sommer “Grillen” als Thema ab. Die Pläne wurden dann am Ende der gemeinsamen Icinga-Schulung konkretisiert, sodass wir eine Umfrage für alle Kollegen erstellen konnten. Aus dieser durfte jeder ein oder zwei Hauptgerichte wählen. Wem nichts von unseren Vorschlägen gefallen hat, wählte die Option “You bring it, we grill it”. Beilagen in Form von Brot und Salaten versprachen wir einfach anhand der Anzahl von Kollegen beizusteuern. Und was wäre ein Essen ohne Nachtisch? Also sollten alle mit einem extra Magen für Süßes auch noch in dieser Spalte ein Kreuzchen machen. Nachdem sich bis zur Deadline fast 30 Kollegen eingetragen hatten, stand am Mittwoch der große Einkauf an. Hierfür legten wir gemeinsam fest, was gemacht werden sollte und wer dafür verantwortlich ist. Derjenige schrieb seine Zutaten zusammen und daraus machten unsere Einkäufer eine Liste. Als diese zurück waren, begannen schon die ersten Vorbereitungen, da manches über Nacht gehen, einziehen oder abkühlen sollte. Bevor wir aber nun mit den Rezepten starten, sollen nun erst mal unsere Einkäufer zu Wort kommen.

 

Der Einkauf von Johannes Rauh

Meine Aufgabe war es, die ganzen Einkäufe zu planen und durchzuführen. Diese Aufgabe habe ich mir mit Apostolos geteilt. Da wir schon den Nachmittag vor dem Grilltag angefangen hatten, die ersten Sachen vorzubereiten, mussten wir auch schon einen Tag davor einkaufen gehen. Dazu haben mir alle Leute ihre Rezepte mit genauen Mengenangaben geschickt und ich habe eine große Einkaufsliste zusammengeschrieben. Daraus hat sich ergeben, dass wir in 5 Läden mussten: Metzger, Baumarkt, einen griechischen Laden, ALDI und REWE.
Da wir ja Grillen wollten, war klar, dass wir eine gewisse Menge an Fleisch benötigen. Unsere Umfrage hat ergeben, dass wir 20 fränkische Bratwürste, 18 Putenspieße, 10 Rinder-Roastbeef à 200g, 10 Lachsfilets sowie 20 Grillkäse benötigen.

Alles bis auf die Lachsfilets wollten wir bei einem Metzger vorbestellen und am Tag des Grillens abholen. Hierfür sind wir zum Partyservice Wahler gefahren.

EinkaufAnschließend waren wir beim Baumarkt und haben die Gasflasche für unseren Gasgrill auffüllen lassen. So war sichergestellt, dass uns nicht plötzlich während des Grillens das Gas ausgeht und die Leute hungrig bleiben müssen.

Apostolos – ein Grieche durch und durch – hat darauf bestanden, den Joghurt für sein Tsatsiki in seinem griechischen Fachgeschäft des Vertrauens zu besorgen und so haben wir dort auch gleich ein Kilo Feta für die Salate geholt.

Der Plan für den Rest war, möglichst viel bei ALDI zu bekommen, um ein wenig Geld zu sparen. Alles, was wir dort nicht bekommen haben, haben wir vom REWE direkt nebenan geholt.

 

Fischmarinade von Dirk Götz

Irgendwann war mir danach, statt Fisch natur oder mit ein paar Kräutern gewürzt zu grillen, mich im Marinieren zu versuchen. Dabei bin ich über die “Fisch – Marinade à la Ralli” auf Chefkoch gestolpert, die meine aktuelle Standard-Marinade geworden ist, aber wie immer mit ein bisschen Abwandlung.

Du brauchst:
Marinierter Lachs
1 TL Pfeffer (am besten bunter, frisch gemahlen)
1 TL Salz
1 Peperoni
1 EL süßer Senf
3 EL dunkle Sojasauce
12 EL Olivenöl
3 EL Balsamico
4 große Zehen Knoblauch
1/2 Bund Dill

So geht`s:

Die Peperoni einfach fein in Ringe schneiden, wobei ich persönlich Habanero oder ähnlich scharfe nehme, für die Kollegen sollte es aber eine einfache rote Peperoni tun. Den Dill fein hacken, alternativ geht auch getrockneter, aber frischer ist natürlich geschmacklich intensiver. Anschließend die Zutaten einfach vermengen.

Ich lasse den Fisch gerne über Nacht in der Marinade im Kühlschrank ziehen. Dafür einfach eine Schicht Fisch ins Gefäß legen, mit ein paar Löffeln Marinade übergießen, dann mit der nächsten Schicht wiederholen und zum Schluss den Rest einfach ins Gefäß gießen. Die Menge reicht für viel mehr als man denkt. Die 12 Lachsfilets waren also vollkommen ausreichend. Hat man weniger Zeit, kann man die Marinade auch während des Grillens immer wieder auftragen.

 

Mediterraner Kircherbsensalat von Dirk Götz

Bei diesem Salat handelt es um einen meiner Lieblingssalate zum Grillen. Dabei kann er aber auch ganz gut mit etwas Brot als vollwertige Mahlzeit dienen. Für die Kollegen hab ich die doppelte Portion gemacht, sodass auch genug für alle da war. Gefunden hab ich das Rezept auch wieder auf Chefkoch, da ich kein so großer Fan von Petersilie bin, lasse ich diese aber meist weg.

Du brauchst (für eine Schüssel):
Mediterraner Kichererbsensalat
1 Dose (800g) Kichererbsen
1 rote Zwiebel
1 Zucchini
1 (rote) Paprika
1 Peperoni
250g Feta (kann auch etwas mehr sein)
3 EL Balsamico-Essig
6 EL Olivenöl (und etwas zum Braten)
Zucker
Zitronensaft
Salz

So geht’s:

Die Kichererbsen abtropfen lassen. Währenddessen Essig, Öl, Zucker, Zitronensaft und Salz zu einem Dressing verrühren, wobei ich letztere nach Gefühl und durch Abschmecken dosiere. Die abgetropften Kichererbsen mit dem Dressing vermischen.
Die Zwiebel in schmale Halbkreise und die Peperoni in dünne Scheiben schneiden und hinzufügen. Auch hier darf es gerne eine schärfere Sorte sein, wenn man dies mag. Allerdings waren auch bei einer normalen Peperoni schon einige überrascht.

Zucchini in Scheiben und Paprika in feine Streifen oder größere Rechtecke schneiden und im Olivenöl anbraten. Das ganze darf schon etwas Farbe bekommen, die Zucchini gebräunt, die Paprika glasig.

Während des Anbratens den Schafskäse würfeln und unterheben. Nach dem Braten ebenso das Gemüse unterheben. Dabei lass ich auch gerne das Olivenöl vom Braten komplett mit reinlaufen. Gerne dann nochmal etwas abschmecken, je nach Geschmack braucht es noch etwas Zitronensaft oder Salz.

 

Mediterraner Nudelsalat mit getrockneten Tomaten und Pinienkernen von Leander Müller-Osten

Diesen Salat mach ich eigentlich bei jeder Grill-Feier. Zum einen ist er sehr schnell gemacht und auch sehr gut in großen Mengen zu machen. Vor allem heute, wo wir für ca. 25 Personen gekocht haben, genau der richtige Salat.

Du brauchst (für 10-12 Personen):
Nudelsalat (Work in Progress)
1kg Nudeln
1 Glas getrocknete Tomaten
400g Feta-Käse
2 Packungen Pinienkerne
4 EL Balsamicoessig
2 Becher Sauerrahm
3 Gläser rotes Pesto (grobes Pesto)

So geht’s:

  1. Bring einen Topf mit gesalzenem Wasser zum Kochen. Füge die Nudeln hinzu und koche sie gemäß den Anweisungen auf der Verpackung, bis sie al Dente sind.
  2. Rühre das Pesto nach Deinem Geschmack in die warmen Nudeln ein. Füge dann den Sauerrahm hinzu und vermische alles gut, bis die Nudeln gleichmäßig von der Pesto-Sauerrahm-Mischung umhüllt sind.
  3. Die getrockneten Tomaten abtropfen und in feine Streifen schneiden. Gib die geschnittenen Tomaten zu den Nudeln und rühre sie vorsichtig unter, damit sie sich gleichmäßig im Salat verteilen.
  4. Erhitze eine beschichtete Pfanne auf mittlerer Hitze. Gib die Pinienkerne in die Pfanne und röste sie leicht an, bis sie goldbraun und duftend sind. Achte darauf, sie regelmäßig zu wenden, damit sie sich gleichmäßig bräunen. Sobald die Pinienkerne fertig geröstet sind, nimm sie aus der Pfanne und gib sie zu den Nudeln.
  5. Zerbrösele den Fetakäse mit Deinen Händen über den Nudelsalat.
  6. Gib etwa 4 EL Balsamicoessig über den Salat. Nach Geschmack kannst Du auch etwas Olivenöl hinzufügen. Vermische alles gut und schmecke den Salat mit Salz und Pfeffer ab.
  7. Decke die Schüssel mit dem Nudelsalat ab und stelle sie für etwa 3-4 Stunden in den Kühlschrank.

 

Coleslaw von Leander Müller-Osten

Der Klassiker unter den Krautsalaten, der jedes Fleischgericht perfekt begleitet:

Du brauchst (für 10-12 Personen):
Coleslaw (Work in Progress)
1 Kopf Weißkohl
1/2 Kopf Rotkohl
3 Karotten
3 Äpfel
Mayonnaise
Honig
Apfelessig
Senf (mittel scharf oder Dijon)
Selleriesamen

So geht’s:

  1. Kohl vorbereiten: Weißkohl und Rotkohl vierteln und den Strunk entfernen. Schneide den Kohl dann in möglichst dünne Streifen und gib ihn in eine große Schüssel.
  2. Entwässern des Kohls (optional, aber empfohlen): Um sicherzustellen, dass der Coleslaw knackig bleibt und nicht zu viel Wasser abgibt, füge 1-2 Teelöffel Salz zum Kohl hinzu und vermische alles gründlich. Etwa 1 Teelöffel Salz pro Kohlkopf sollte ausreichen. Lasse den Kohl mindestens eine halbe Stunde stehen. Du kannst auch etwas Schweres auf den Kohl legen, um das Wasser herauszudrücken. Drücke den Kohl nach dem Ruhen kräftig aus, um so viel Wasser wie möglich zu entfernen.
  3. Apfel und Karotte raspeln: Raspel die Äpfel und Karotten, um feine Raspeln zu erhalten. Die Apfel- und Karottenraspeln fügen dem Coleslaw eine angenehme Süße und zusätzliche Textur hinzu.
  4. Dressing anrühren: Bereite das Dressing vor, indem Du Mayonnaise, Honig, Apfelessig, Senf und Selleriesamen in einer separaten Schüssel vermengst. Die genauen Mengen hängen von Deinem persönlichen Geschmack ab, aber als Richtlinie könntest Du etwa 1/2 Tasse Mayonnaise, 1-2 Esslöffel Honig, 2-3 Esslöffel Apfelessig, 1 Teelöffel Senf und eine Prise Selleriesamen verwenden. Rühre alles gut um, bis das Dressing gleichmäßig vermischt ist.
  5. Alles zusammen mischen: Gib die geraspelten Äpfel und Karotten zum entwässerten Kohl in die Schüssel. Gieße das vorbereitete Dressing über die Zutaten und vermische alles gründlich, bis der Kohl, die Äpfel und die Karotten gut mit dem Dressing bedeckt sind.
  6. Kühlen: Decke die Schüssel mit dem Coleslaw ab und stelle sie in den Kühlschrank. Lasse den Coleslaw für mindestens 1 Stunde oder länger kühl stehen, damit sich die Aromen verbinden und der Coleslaw gut durchziehen kann.

 

Kartoffelsalat von Jan Schuppik

Kartoffelsalat ist ein zeitloser Favorit, der zu den unterschiedlichsten Anlässen passt. Egal, ob bei Grillfesten, als leichtes Sommeressen oder auf Buffets – dieser Klassiker erfreut sich stets großer Beliebtheit. Dieses Rezept verleiht dem traditionellen Kartoffelsalat eine erfrischende Note und stammt von Chefkoch. Er begeistert durch ein einzigartiges Geschmackserlebnis und eine aufmerksam durchdachte Zubereitung.

Du brauchst (für 10 Portionen)::
Kartoffelsalat
2,5 kg vorwiegend festkochende Kartoffeln
2,5 Zwiebeln, fein geschnitten
2,5 Tassen heiße Gemüsebrühe (ca. 125 ml pro Tasse)
5 EL Essig
7,5 EL Rapskernöl
2,5 TL Salz
Prise Pfeffer
1,25 Salatgurken
Senf und/oder Salatkräuter

So geht’s:

Beginne damit, die frisch gekochten Kartoffeln zu schälen und in handwarme, hauchdünne Scheiben zu schneiden. Lege die Scheiben in eine großzügige Schüssel.

Erhitze die Gemüsebrühe und gib den Essig hinzu. Diese Mischung wird dem Kartoffelsalat die perfekte, harmonische Note verleihen. Nach Belieben kann auch etwas Senf hinzufügt werden, dieser wird dann in der Brühe-Essig-Mischung aufgelöst.

Jetzt kommt der interessante Teil: Beginne mit einer Prise Salz über den Kartoffelscheiben, gefolgt von den fein geschnittenen Zwiebeln. Je nach Geschmack kannst Du eine Prise gemahlenen Pfeffer oder feine Salatkräuter hinzufügen. Gieße dann die heiße Brühe-Essig-Mischung über die Zutaten.

Als Nächstes füge das Rapskernöl hinzu, dieses ermöglicht eine gleichmäßige Verteilung der Aromen. Verwende zwei Esslöffel, um die Zutaten vorsichtig zu vermengen, bis alles gut durchmischt ist. Lasse den Salat für mindestens eine Stunde in der Wärme ruhen, damit die Aromen sich entfalten können.

In der Zwischenzeit kannst Du die Salatgurken gründlich abwaschen und samt der Schale mithilfe eines Gemüsehobels in feine Scheiben schneiden. Diese knackige Ergänzung verleiht dem Salat eine erfrischende Textur und einen leichten Biss.

Sobald die Ruhezeit vorüber ist, füge die geschnittenen Gurkenscheiben hinzu und vermische alles behutsam miteinander.

Tipp:
Die heiße Gemüsebrühe in Kombination mit Essig mildert die Schärfe der Zwiebeln und lässt das Salz sowie den Pfeffer besser zur Geltung kommen. Das Öl wird immer zum Schluss hinzugefügt, um den Kartoffeln die Möglichkeit zu geben, Feuchtigkeit aufzunehmen und die Aromen gleichmäßig zu verteilen.

 

 

Nachtisch ist die beste OptonIn diesem ersten Teil ging es um das Grillgut und die Salate als Beilage. Im zweiten Teil kommen dann noch weitere Rezepte zu Broten, Dips und der Nachtisch dazu, denn wir wollten es uns natürlich richtig gut gehen lassen. Was auch schon das Abstimmungsergebnis gezeigt hat. 😉

Dirk Götz
Dirk Götz
Principal Consultant

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

Datensicherheit mit OpenSearch Machine Learning

This entry is part 5 of 5 in the series OpenSearch Security

OpenSearch bringt von Haus aus die Möglichkeit mit, Machine Learning zu nutzen und hierfür pre-trained aber auch untrained Modelle zu nutzen. Den Status deiner Modelle kannst du bequem in OpenSearch Dashboards sehen.

Wie du OpenSearch Machine Learning zum Laufen bringst, zeige ich dir in diesem Blogbeitrag. Wie bei vielen neuen und sich schnell weiterentwickelnden Projekten kann es jedoch sein, dass bis zum Release dieses Blogposts der ganze Prozess noch einmal einfacher geworden ist.

Der Prozess, um OpenSearch für Machine Learning vorzubereiten, besteht aus diesen Bausteinen:

  • Vorbereitung
  • Upload des Modells
  • Modell-Gruppe erstellen
  • Model auf die Gruppe registrieren
  • Deployment
  • Machine Learning nutzen.

Ursprünglich bin ich dieser Anleitung gefolgt. Du arbeitest am bequemsten direkt unter den Developer Tools (Management-> Dev Tools), kannst deine Befehle aber wie immer auch einfach via curl gegen die API senden:

Vorbereitung von Open Search auf Machine Learning

Zunächst habe ich für alle in meinem Beispiel genutzten Modelle URL-Registrierung zugelassen:

PUT _cluster/settings
{
    "persistent" : {
        "plugins.ml_commons.allow_registering_model_via_url" : true
    }
}

Außerdem habe ich das Zeitintervall der Synchronisation erhöht.
Denn “ML Commons will run a regular sync up job to sync up newly loaded or unloaded models on each node”:

PUT /_cluster/settings
{
    "persistent": {
        "plugins.ml_commons.sync_up_job_interval_in_seconds": 600
    }
}

Ab hier musst du einige Python-Libraries laden. Viele Modelle basieren auf der Pytorch-Library. So auch Sentence-Transformers, welches für einige der OpenSearch Modelle benötigt wird.

pip install -U sentence-transformers

Prinzipiell werden ML-Tasks nur auf den eigens dafür zugewiesenen OpenSearch Knoten ausgeführt und hierfür habe ich in meiner opensearch.yml folgende Einträge gesetzt:

node.roles: [ data, cluster_manager,  ml ]
plugins.security.restapi.roles_enabled: ["all_access","ml", "security_rest_api_access"]

Machine Learning Modell bereitstellen

Vorab: Über Task-IDs checkt man, ob die vorherigen Schritte durchgingen und besorgt sich notwendige Informationen zum weiter zuordnen.

Um Machine Learning Modelle in OpenSearch bereitzustellen, legt man einfach eine Gruppe an. Anschließend lädt man das Modell, fügt das Modell der Gruppe hinzu, deployt es über die Modell-ID an die gewünschten Knoten und hat anschließend die Möglichkeit, Machine Learning zu nutzen. Diese einzelnen Schritte zeige ich dir jetzt aber noch einmal detailliert.

Schritt 1: Modell Gruppe hinzufügen.

Bevor Modelle einer Gruppe hinzugefügt werden können, muss eine solche Gruppe angelegt werden. In meinem Beispiel habe ich sie “my-ml-group” genannt. Am einfachsten werden die Gruppen per API-Call hinzugefügt:

POST /_plugins/_ml/model_groups/_register
{
    "name": "my-ml-group",
    "description": "This is a public model group"
}

Es wird Success/Fail-Status sowie Gruppen-ID zurückgegeben, die benötigt wird: z.B. gprKIYoBmWoi9V5-T2Pb

Schritt 2: Das Modell wird von Huggingface geladen. (In meinem Beispiel verwende ich das Modell “all-MiniLM-L12-v2”)

POST /_plugins/_ml/models/_upload
{
  "name": "huggingface/sentence-transformers/all-MiniLM-L12-v2",
  "version": "1.0.1",
  "model_format": "TORCH_SCRIPT"
}

Schritt 3: Das all-MiniLM-L12-v2 Modell wird auf die vorherige Gruppen-ID meiner my-ml-group registriert:

POST /_plugins/_ml/models/_register
{
"name": "huggingface/sentence-transformers/all-MiniLM-L12-v2",
"version": "1.0.1",
"model_format": "TORCH_SCRIPT",
"model_group_id": "gprKIYoBmWoi9V5-T2Pb"
}

Hier bekommt man wieder den Success/Error-State, sowie eine Task ID zurück. In meinem Beispiel ist das die MprLIYoBmWoi9V5-o5Ix.

Schritt 4: Model-ID besorgen

Nutzt man die Task-ID vom registrierten Modell, sieht man Modell ID sowie Error-State:

GET /_plugins/_ml/tasks/MprLIYoBmWoi9V5-o5Ix
{
  "model_id": "RJrLIYoBmWoi9V5-o5LW",
  "task_type": "REGISTER_MODEL",
  "function_name": "TEXT_EMBEDDING",
  "state": "COMPLETED",
  "worker_node": [
    "KmfjhwWjS7eepv4PnUMKWw"
  ],
  "create_time": 1692784108336,
  "last_update_time": 1692784119285,
  "is_async": true
}

Die Modell-ID wird nun für das nachfolgende Deployment benötigt.

Schritt 5: Auf den Model-Nodes deployen

Zum eigentlichen Deployment braucht es Modell-ID und Knoten. Damit kann ich es auf all meinem Machine Learning-Knoten ausrollen:

POST /_plugins/_ml/models/RJrLIYoBmWoi9V5-o5LW/_load

Als Antwort bekommen ich den Task-Type: “Deploy“, sowie den State: “Completed

{
  "model_id": "RJrLIYoBmWoi9V5-o5LW",
  "task_type": "DEPLOY_MODEL",
  "function_name": "TEXT_EMBEDDING",
  "state": "COMPLETED",
  "worker_node": [
    "KmfjhwWjS7eepv4PnUMKWw"
  ],
  "create_time": 1692785563893,
  "last_update_time": 1692785582120,
  "is_async": true
}

Schritt 6: Prediction testen

Hierzu braucht es die Modell ID aus Schritt 5 des Deployments. Mit folgendem Call kannst du die Prediction testen:

POST /_plugins/_ml/_predict/text_embedding/RJrLIYoBmWoi9V5-o5LW
{
    "text_docs": [ "today is sunny" ],
    "return_number": true,
    "target_response": [ "sentence_embedding" ]
}

Ab hier wird es spannend, denn hat man mehrere OpenSearch Cluster läuft das Ganze direkt verteilt und auch alle Logs wie z.B. die von Icinga, Graylog uvm. sind im selben Backend. Dadurch wäre es möglich, mit allen vorhandenen Logs gleichzeitig zu trainieren!

Kannst du dir schon vorstellen, was du damit alles machen möchtest und vor allem da alles lokal bei dir stattfinden kann, was es bedeutet, dass du die volle Kontrolle über Datensicherheit hast?