Seite wählen

Ergebnisse für " docker "

Docker

Die Devops-Tool-Chain hat seit einiger Zeit ein sehr interessantes neues Tool mit dem Namen „Docker“. Docker erfährt einen regelrechten Hype um sich, wobei die Meinungen um das Tool durchaus gemischt sind. Einen Blick ist es auf jeden Fall Wert. Aber was ist Docker eigentlich?
Docker ist ein Open-Source-Framework, das leichtgewichtige, portable, LXC-Container bereitstellt und steuert, die praktisch überall laufen können. Eine Anwendung kann also problemlos auf einem Laptop des Entwicklers, oder in großen Produktionsumgebungen auf Bare-Metal oder in der Cloud laufen. Das mit dem überall beschränkt sich dann aber doch auf einen Linux-Kernel mit LXC, aber das wiederum kann praktisch überall laufen. Die Use-Cases sind die Automatisierung von Deployments, das Bereitstellen von PaaS/SaaS Services, automatisierte Continuous-Integration-Tests und die Skalierung von Anwendungen. Spätestens jetzt ruft der erste „Bingo“ beim Buzzword-Bingo.
In anderen Worten ist Docker ein Tool, vergleichbar mit Vagrant, mit dem sich Anwendungen einfach über Umgebungen hinweg portieren lassen.
docker run ubuntu /bin/echo hello world
Tatsächlich ist das aufgezeigte Beispiel vielleicht etwas ernüchternd: es gibt bei Erfolg lediglich „hello world“ auf einer neuen Zeile zurück. Tatsächlich passiert aber viel mehr. Das Image ‚ubuntu‘ wird heruntergeladen – wenn es nicht bereits lokal vorhanden ist – und in einem LXC-Container gestartet. In diesem wiederum wird /bin/echo ausgeführt und anschließend beendet sich der Container wieder.
Ein Container wird immer aus einem Image erzeugt und läuft so lange die Anwendung läuft – wird diese beendet, beendet sich auch der Container. Images sind über Repositories, bei Bedarf auch eigenen Repositories, verfügbar. Ähnlich wie mit Git lassen sich diese Images steuern. docker commit, docker pull, docker push erstellen neue Images und laden diese hoch bzw. runter.
docker run -i -t ubuntu /bin/bash
docker commit $ID my_fancy_app
docker run -p 80:3000 my_fancy_app rails server

In dem Beispiel wird ein LXC-Container mit Ubuntu gestartet mit einer interaktiven Shell. In der Sitzung installiert man seine Anwendung. Eleganter ist ein Dockerfile, dass das automatisch vornimmt. In dem Beispiel wird eine Ruby-on-Rails-Anwendung installiert und mit dem commit Befehl anschließend ein neues Image erzeugt. Nebenbei bemerkt: docker diff zeigt den Unterschied zum initialen Container. Abschließend wird das neue Image in einem neuem Container mit einer Portweiterleitung von 80 auf 3000 und der Anwendung (Webrick) gestartet. Die Anwendung ist dann unter der $IP:80 auf dem System, dass den Container hosted, verfügbar. Die Anwendung bzw. der Container kann jetzt beliebig oft sekundenschnell gestartet werden, solange der Netzwerkport natürlich nicht doppelt belegt wird. Der Container ist jetzt in der Lage auf jedem System gestartet zu werden, dabei ist es egal ob es eine Amazon AWS VM, KVM/XEN VM, Bare-Metal oder Virtualbox(Vagrant) ist.
Seine Container kann man auch mit Puppet steuern, verteilen und starten.
docker::run { 'my_app':
image => 'my_fancy_app',
command => 'rails start',
ports => ['80', '443'],
}

Zusammenfassend ist Docker ein geniales Framework für einige bestimmte Anwendungsfälle. Ich bin begeistert.
Mehr Information findet man auf docker.io

Sebastian Saemann
Sebastian Saemann
CEO Managed Services

Sebastian kam von einem großen deutschen Hostingprovider zu NETWAYS, weil ihm dort zu langweilig war. Bei uns kann er sich nun besser verwirklichen, denn er leitet das Managed Services Team. Wenn er nicht gerade Cloud-Komponenten patched, versucht er mit seinem Motorrad einen neuen Rundenrekord aufzustellen.

Kubernetes 101: Die nächsten Schritte

This entry is part 7 of 7 in the series Alles rund um Kubernetes

Im Laufe des letzten Jahres haben wir uns in dieser Blogserie ausführlich mit Kubernetes beschäftigt. Von leicht verständlichen Erklärungen zu Design und Funktionsweise über den Aufbau eines ersten (lokalen) Clusters bis hin zur Inbetriebnahme und Absicherung haben wir viele Aspekte behandelt.
Im besten Fall konntest du erste Erfahrungen zu sammeln und vielleicht schon die eine oder andere Anwendung eigenständig bereitstellen. Die naheliegende Frage ist nun, „wohin“ geht die Reise von hier aus?

In diesem letzten Artikel unserer Serie werde ich daher einige Ausblicke geben. Was ist im täglichen Betrieb zu beachten? Wie wird das System heute noch genutzt? Und welche neuen Einsatzmöglichkeiten zeichnen sich gerade ab? Vielleicht ist ja der eine oder andere Anwendungsfall auch für dich interessant!

Kubernetes im Alltagsbetrieb

Nachdem du dein(e) Cluster eingerichtet hast, beginnt der Alltagsbetrieb in der schicken, neuen Cloud-nativen Umgebung. Und hier kann es (ungewollt) spannend werden! Die verteilte Architektur und das generelles Design erfordern eine andere Herangehensweise als in traditionellen IT-Umgebungen. Insbesondere beim Monitoring bzw. Observability oder beim Backup-Management.

Werden Anwendungen auf Kubernetes betrieben, reicht es nicht aus, nur die laufenden Anwendungen zu sichern und in das Monitoring einzubinden. Man muss sich auch um die zugrundeliegende Infrastruktur kümmern! Die Gründe hierfür sollten klar sein: Verliert man die Zustandsinformationen der Kubernetes-API in etcd, ist ein Betrieb nicht mehr möglich. Ist der Cluster selbst kompromittiert, sind auch die darauf laufenden Applikationen in Gefahr. Es gilt also, aufzupassen und vorzusorgen.

Zum Thema Sicherheit auf gibt es in dieser Blogserie bereits einen eigenen Beitrag, die wichtigsten Punkte möchte ich aber noch einmal zusammenfassen:
Anwendungen auf Kubernetes werden in der Regel als containerisierte Microservices betrieben, die über das clusterinterne Netzwerk miteinander kommunizieren. Eine entsprechende Absicherung der verwendeten Netzwerke, sowohl an den Clustergrenzen als innerhalb des Clusters, ist daher zwingend erforderlich. Hierzu gibt es die Möglichkeit der nativen Fähigkeiten von Kubernetes selbst (Stichwort NetworkPolicies) oder man greift auf externe Tools zurück, die in ihrem Funktionsumfang weniger eingeschränkt sind (z.B. CNIs wie Cilium oder Calico).

Darüber hinaus sollten auch die betriebenen Container selbst unter die Lupe genommen werden: Nutzen sie vulnerable Abhängigkeitenbenötigen sie alle zugewiesenen Privilegien, und wie sieht es mit der Aktualität der Images selbst aus? Für all diese Fragen gibt es Tools, die die Umsetzung erleichtern – von Imagescannern wie Trivyoder Docker Scoutbis zur Echtzeiterkennung von Sicherheitsproblemen mit NeuVector von unserem Partner SUSE.

Das Ökosystem bietet auch Lösungen für das Backup-Management: Angefangen bei Kasten, einer Enterprise-Backuplösung von Veeam, über Velero, einer FOSS-Lösung für Backups von Clusterzustand und PersistentVolumes, bis hin zu Kanister (ebenfalls von Veeam), das Backup-Management auf Anwendungsebene ermöglichen soll.
Je nach Anwendungsfall und Clusterspezifikationen (Anzahl an Nodes, onPrem vs. Cloud, etc.) wirst du dich wahrscheinlich für eine bestimmte Backup-Lösung und einen speziellen Ansatz für das Backup-Management wählen.
Mit den genannten Lösungen kannst du aber definitiv deine ersten Schritte gehen.

Kubernetes als Infrastruktur-Plattform

Ein stetig wachsender Anwendungsfall ist der Einsatz als zentrale Infrastruktur-Management-Plattform. Dank zahlreicher (Open-Source-) Projekte im Cloud-nativen Ökosystem ist Crossplane heute in der Lage, Ressourcen wie S3-Buckets, Cloud-VMs oder gemanagte Datenbanken in verschiedenen Public Clouds zu provisionieren und zu verwalten.

Du kannst das System auch als Hypervisor für deine VM-Flotte verwenden Möglich macht dies das Projekt kubeVirt, das KVM-VIrtualisierung auf Kubernetes bringt – alles unter einem Dach, quasi! kubeVirt selbst ist ein Projekt innerhalb der CNCF, das unter Anderem von namhaften Firmen wie SUSE, RedHat oder ARM unterstützt wird.

Kubernetes als Management-Plattform

Doch nicht nur für Infrastruktur kann Kubernetes als Plattform herhalten. Es bietet auch die Möglichkeit, dass andere Benutzer in der Organisation die zentrale Schnittstelle für Ihre tägliche Interaktion mit eurer IT-Landschaft werden. Das Schlagwort für diese Art der Nutzung lautet Internal Development Platform (IDP) und ist eines der Themen, die derzeit stark im Kommen sind:
Vorgelebt von Spotify und seiner modularen Plattform Backstage gibt es mittlerweile eine ganze Reihe von kommerziellen und nicht-kommerziellen Lösungen, die Entwicklern in Zeiten von SaaS-Lösungen und immer komplexeren Entwicklungsumgebungen helfen können, den Überblick zu behalten.

Ziel von IDPs ist es, verschiedene Informationen rund um den Entwicklungszyklus zusammenzuführen, Prozesse zu vereinheitlichen und „Golden Paths“ zu etablieren. Mit seiner mächtigen API und seinen Orchestrierungsmöglichkeiten bietet sich Kubernetes für so ein Vorhaben an. Schließlich sollen verschiedenste Drittanwendungen mit der Plattform interagieren, Informationen bereitstellen und im Gegenzug Anweisungen von der Plattform erhalten. Nicht umsonst ist das Thema „Kubernetes als IDP“ also eines der derzeit „heißesten“ Themen auf Konferenzen wie z.B. der KubeCon.

Fazit

Kubernetes wird nicht langweilig und bietet viele Möglichkeiten zur Erweiterung und zum Ausbau. Das ist ein bisschen Fluch und Segen zugleich. Denn mit den Vorteilen entstehen auch neue Risiken. Es kann sinnvoll sein klein anzufangen, sein(e) Cluster nach und nach zu erweitern und an neue Anwendungsfälle anzupassen.
Eine der wichtigsten Regeln ist, von der ersten Minute an Sicherheit und Observability zu bedenken. Das Risiko einer unentdeckten Schwachstelle ist ansonsten aufgrund der verteilten Architektur und den darauf laufenden Anwendungen schwer zu überblicken.

Wenn du nach der Lektüre dieser Serie Lust bekommen hast loszulegen, du dich aber noch nicht zu 100% bereit fühlst direkt loszulegen, ist vielleicht unser Kubernetes Training etwas für dich!
Ansonsten kannst du jederzeit unser Sales Team kontaktieren, und mit einem unsere Kubernetes-Spezialisten über deine Fragen sprechen.

Daniel Bodky
Daniel Bodky
Platform Advocate

Daniel kam nach Abschluss seines Studiums im Oktober 2021 zu NETWAYS und beriet zwei Jahre lang Kunden zu den Themen Icinga2 und Kubernetes, bevor es ihn weiter zu Managed Services zog. Seitdem redet und schreibt er viel über cloud-native Technologien und ihre spannenden Anwendungsfälle und gibt sein Bestes, um Neues und Interessantes rund um Kubernetes zu vermitteln. Nebenher schreibt er in seiner Freizeit kleinere Tools für verschiedenste Einsatzgebiete, nimmt öfters mal ein Buch in die Hand oder widmet sich seinem viel zu großen Berg Lego. In der wärmeren Jahreszeit findet man ihn außerdem oft auf dem Fahrrad oder beim Wandern.

Kibana Sicherheits-Updates: CVSS:Critical

Und täglich grüßt das Murmeltier. Nein nicht ganz. Heute ist es  aus der Elastic Stack Werkzeugkiste Kibana, für das es ein wichtiges Sicherheits-Update gibt. Es besteht auf jeden Fall Handlungsbedarf! IMHO auch wenn ihr die „Reporting“ Funktion deaktiviert habt.

Der Link zur Veröffentlichung: Kibana 8.12.1, 7.17.18 Security Update (ESA-2024-04)

Schweregrad: Severity: CVSSv3: 9.9(Critical)

Beschreibung

Die Verwundbarkeit ist ist auf eine Schwachstelle von Google Chrome aus Dezember 2023 zurückzuführen. Da Kibana für die Reporting Funktion eine eingebettete „Chromium headless Verison“ mit sich bringt, ist Kibana von dieser „Heap buffer overflow in WebRTC“ ebenfalls betroffen. Diese Schwachstelle ermöglicht es einem entfernten Angreifer, über eine manipulierte HTML-Seite einen „Heap-Velrust“ auszunutzen.

Dieser Effekt betrifft „on-premises“ Kibana installation auf Betriebsystemen die „Chromium Sandbox“ abgeschaltet haben. Diese sind CentOS, Debian, RHEL.

Es betrifft auch Instanzen welche mit dem Kibana Docker betrieben werden, wenn „Chromium Sandbox“ wie explizit empfohlen abgeschaltet ist. Jedoch gilt hier, dass eine „Container Escape“ nicht möglich ist, da es durch „seccomp-bpf“ unterbunden wird. Das gilt auch für Kibana Instanzen auf „Elastic Cloud„, für „Elastic Cloud Enterprise (ECE)„, wobei hier das weitere Vordringen zusätzlich zum „seccomp-bf “ mit „AppArmor profiles“ verhindert wird.

Für Kibana Instanzen welche auf „Elastic Cloud on Kubernetes“ laufen, ist um das weitere Vordingen (Container Escape) durch „seccomp-bf“ zu verhindern, dieses entsprechend in Kubernetes zu konfigurieren (wird seit V1.19 unterstützt).

Betroffene Versionen

  • Kibana bis 7.17.17
  • Kibana bis 8.12.0

Handlungsablauf zur Abhilfe

  • Dringend Update auf Version 8.12.1 oder Version 7.17.18
    • Dabei ist aber auch an die Elasticsearch Version zu denken
  • Sollte Kein UPDATE möglich sein, dann sollte die „Reporting“ Funktion dringend abgeschalten werden
    vi /etc/kibana/kibana.yml
    ...
    xpack.reporting.enabled: false

     

Anmerkung der Redaktion

Hier ist ein handeln Empfohlen. Der Hersteller hat die Schwachstelle erkannt und öffentlich bekannt gegeben, begleitet von Handlungsempfehlungen zur Behebung. Wir haben dies festgestellt und möchten euch mit diesem Beitrag bei der Erkennung und der damit verbundenen Möglichkeit zum Handeln unterstützen. Wenn Ihr unsicher seit, wie ihr reagieren sollt und Unterstützung benötigt, wendet euch einfach an unser Sales-Team. Das Team von Professional Services unterstützt euch gerne.

Daniel Neuberger
Daniel Neuberger
Senior Consultant

Nach seiner Ausbildung zum Fachinformatiker für Systemintegration und Tätigkeit als Systemadministrator kam er 2012 zum Consulting. Nach nun mehr als 4 Jahren Linux und Open Source Backup Consulting zieht es ihn in die Welt des Monitorings und System Management. Seit April 2017 verstärkt er das NETWAYS Professional Services Team im Consulting rund um die Themen Elastic, Icinga und Bareos. Wenn er gerade mal nicht um anderen zu Helfen durch die Welt tingelt geht er seiner Leidenschaft für die Natur beim Biken und der Imkerei nach und kassiert dabei schon mal einen Stich.

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 stellt sich vor – Lucy Siemer

This entry is part 57 of 63 in the series NETWAYS stellt sich vor

Name: Lucy Siemer

Alter: 23

Studium/Ausbildung: Fachinformatikerin für Systemintegration

Position bei NETWAYS: Consultant

Bei NETWAYS seit: Mai 2023

 

 

Wie bist Du zu NETWAYS gekommen und was genau gehört zu Deinem Aufgabenbereich?

Nach der OSMC 2022 bin ich mit ein paar NETWAYS Kolleg:Innen in Kontakt geblieben. Diese haben mir viel von der NETWAYS-Kultur und -Arbeitsweise erzählt, die mir sofort gefallen hat. Da ich sowieso auf Jobsuche war, hab ich mich einfach mal beworben. Und siehe da, It’s a match!

Die Kollegen haben mich direkt am Anfang in eine Elasticstack-Schulung gesteckt, das Thema hat mir gut gefallen, deswegen unterstütze ich dort bereits einige Kunden. Auch bei den Themen Kubernetes, Docker und Infrastructure-as-Code Lösungen mit Ansible und Terraform stehe ich mit Rat und Tat zur Seite.

Des Weiteren halte ich auch die ein oder andere Schulung, was mir sehr viel Spaß macht.

 

Welche größeren, besonders interessanten Projekte stehen künftig an?

Gerade überarbeite ich zusammen mit den anderen Trainern die Elasticstack-Schulung, die ich demnächst auch halten werde. Auch auf der bevorstehenden stackconf werde ich tiefer involviert sein, da gilt es aber noch herauszufinden, was ich genau machen darf.

 

Wie gefällt es Dir bisher bei NETWAYS?

Wunderbar! Am besten gefallen mir bisher, ganz klar, die Leute. Meine Kolleg:Innen sind die nettesten Menschen, mit denen ich je gearbeitet habe. Die Aufgaben sind spannend und abwechslungsreich, und trotzdem wird mir genug Zeit eingeräumt, um mich weiter zu bilden.

 

Was machst Du, wenn Du mal nicht bei NETWAYS bist?

Reisen – eins meiner Lebensziele ist es, so viel von der Welt zu sehen, wie ich kann! Wenn ich mal Zuhause bin, nutze ich meine kreative Energie, um schöne Kleider zu schneidern. Vielleicht traue ich mich demnächst auch an kompliziertere Kleidungsstücke.

Ansonsten ist die IT natürlich nicht nur Beruf, sondern auch Hobby. Ich verwalte ein kleines Kubernetes-Cluster mit einigen Tools, die mal mehr, mal weniger Liebe benötigen. Als nächstes installiere ich einen AWX, um meine Playbooks kontinuierlich gegen das Cluster laufen zu lassen. Der nächste Schritt sind dann automatisierte Tests, um das Cluster und die Tools später automatisiert updaten zu können!

 

Wie geht es in Zukunft bei Dir weiter?

Ach, wer weiß das schon. Ich hoffe, mich mehr in Richtung Infrastructure as Code zu bilden, um Kunden auch bei architekturellen Fragen zur Seite stehen zu können, und um größere Umgebungen zu automatisieren.

Außerdem würde ich gern den ein oder anderen Talk halten, vielleicht ja auf der stackconf oder der OSMC 2024? Wir werden sehen.

Lucy Siemer
Lucy Siemer
Consultant

Lucy ist seit Mai 2023 bei NETWAYS als Consultant tätig, nachdem sie im Jahr 2022 ihre Ausbildung zur Fachinformatikerin für Systemintegration erfolgreich abgeschlossen hat. Ihre Schwerpunkte liegen auf den Bereichen Kubernetes, Infrastructure as Code und Monitoring. Neben ihrer Arbeit bei NETWAYS betreut Lucy auch privat ihre eigene Infrastruktur auf Kubernetes. Darüber hinaus ist sie leidenschaftlich daran interessiert, eigene Kleider zu nähen und individuelle Designs zu kreieren.