aiMOOC

IT-Systeme Hardware und Betriebssysteme – Prozesse Dienste und Ressourcen beobachten

QR-Code

IT-Systeme Hardware und Betriebssysteme – Prozesse Dienste und Ressourcen beobachten

Einleitung

In diesem aiMOOC lernst Du, den Systemzustand eines lokalen IT-Systems zu beurteilen. Im Mittelpunkt stehen Prozesse, Dienste, CPU, Arbeitsspeicher, Datenträger und Systemlast.

Zielgruppe: Ausbildung im IT-Bereich, besonders Fachinformatik und vergleichbare Bildungsgänge.

Kurzbeschreibung: Auslastung und Systemzustand beobachten, Messwerte einordnen und eine begründete Erstdiagnose erstellen.

Sicherheitsrahmen: Du arbeitest ausschließlich auf Deinem eigenen Lernrechner, einer ausdrücklich freigegebenen Schulungs-VM oder mit den fiktiven Daten dieses Kurses. Keine fremden Netze, Produktivsysteme, Zugangsdaten oder Kundendaten werden untersucht, verändert oder übertragen.

Das Betriebssystem vermittelt zwischen Hardware, Anwendungen und Benutzer. Die Abbildung auf Wikimedia Commons ist frei lizenziert.

Ausbildungsfall: Der langsame Schulungsserver

Du betreust die fiktive VM LAB-SRV-07. Auszubildende melden: „Die Anwendung reagiert langsam.“

Gegeben sind nur lokale, fiktive Messwerte:

Messwert	08:00	08:15	08:30
CPU	24 %	91 %	88 %
RAM belegt	58 %	67 %	69 %
Datenträger aktiv	12 %	39 %	33 %
Load Average 1 min	0,8	5,7	5,2
Dienst app-demo	aktiv	aktiv	aktiv

Erste Beobachtung: Der Dienst läuft, trotzdem steigt die CPU-Auslastung stark. Ein Dienst kann also formal aktiv sein und dennoch schlechte Leistung verursachen.

08:00  CPU  [█████---------------] 24 %
08:15  CPU  [██████████████████--] 91 %
08:30  CPU  [██████████████████--] 88 %

08:00  RAM  [████████████--------] 58 %
08:15  RAM  [█████████████-------] 67 %
08:30  RAM  [██████████████------] 69 %

Lerneinheit 1: Prozesse verstehen

Ein Prozess ist eine laufende Instanz eines Programms. Betriebssysteme verwalten Prozesse unter anderem über eine PID, Zustände, Prioritäten und zugewiesene Ressourcen.

Typische Zustände sind vereinfacht:

laufend: Der Prozess wird gerade ausgeführt.
bereit: Der Prozess könnte ausgeführt werden und wartet auf CPU-Zeit.
wartend: Der Prozess wartet zum Beispiel auf Ein-/Ausgabe.
beendet: Die Ausführung ist abgeschlossen.

Merksatz: Hohe Prozesszahl allein ist noch kein Fehler. Entscheidend sind Ressourcenverbrauch, Zustand, Dauer und Kontext.

Linux: Prozesse lokal beobachten

ps -eo pid,ppid,stat,%cpu,%mem,comm --sort=-%cpu | head

Der Befehl liest lokale Prozessinformationen und verändert nichts.

top

`top` zeigt eine fortlaufend aktualisierte Sicht auf Systemzustand und Prozesse.

Beobachtungsauftrag: Suche auf einer freigegebenen lokalen Linux-VM den Prozess mit der höchsten CPU-Nutzung. Notiere PID, Prozessname, CPU- und RAM-Anteil. Beende keinen Prozess.

Windows: Prozesse lokal beobachten

Der Task-Manager zeigt Apps, Hintergrundprozesse und deren Ressourcennutzung.

Lesend in PowerShell:

Get-Process |
  Sort-Object CPU -Descending |
  Select-Object -First 10 Name, Id, CPU, WorkingSet64

Hinweis: `CPU` in `Get-Process` ist die bisher verbrauchte Prozessorzeit, nicht direkt der momentane Prozentwert. Für eine Momentaufnahme eignet sich der Task-Manager besser.

Basisaufgabe 1

Ordne zu: PID, Prozessname, CPU-Nutzung, RAM-Nutzung.

Feedback: Eine belastbare Diagnose braucht Identität und Ressourcennutzung zusammen. Nur „CPU hoch“ reicht nicht.

Lerneinheit 2: Dienste beobachten

Ein Dienst arbeitet meist im Hintergrund und stellt eine Funktion bereit. Unter Linux verwaltet häufig systemd Dienste; unter Windows übernimmt dies der Service Control Manager.

Das eingebettete Video von Learn Linux TV erklärt systemd und Dienstverwaltung. Nutze im Kurs nur die beobachtenden Teile; Änderungen führst Du ausschließlich in einer freigegebenen Lernumgebung aus.

Linux: Dienststatus lesen

systemctl --failed
systemctl status app-demo.service --no-pager

Für den Ausbildungsfall ist `app-demo.service` nur ein fiktiver Name. Auf Deinem Lernsystem verwendest Du ausschließlich einen vorhandenen und freigegebenen Übungsdienst.

Wichtig: `active` bedeutet, dass die Unit aktiv ist. Es beweist nicht, dass die Anwendung schnell oder fachlich korrekt arbeitet.

Windows: Dienste lesen

Get-Service |
  Sort-Object Status, Name |
  Select-Object Status, Name, DisplayName

Nur laufende Dienste:

Get-Service |
  Where-Object Status -eq 'Running' |
  Select-Object Name, DisplayName

Anwendungsaufgabe 1

Im Ausbildungsfall ist `app-demo` aktiv, die CPU liegt aber bei 91 %. Formuliere zwei Hypothesen.

Mögliche begründete Antwort:

Ein Prozess des Dienstes verarbeitet ungewöhnlich viele Aufgaben und verursacht hohe CPU-Last.
Ein anderer Prozess belastet die CPU; der Dienst ist nur indirekt betroffen.

Feedback: Der Status eines Dienstes und die Ressourcensituation sind zwei verschiedene Beobachtungsebenen.

Lerneinheit 3: CPU und Systemlast

CPU-Auslastung beschreibt, wie stark Rechenzeit genutzt wird. Unter Linux ergänzt die Load Average die Betrachtung. Sie zählt über Zeit gemittelt ausführbare Tasks sowie Tasks, die auf nicht unterbrechbare I/O warten.

uptime
cat /proc/loadavg

Beispiel mit fiktiven Daten:

5.70 4.10 2.80 6/312 8421

Die ersten drei Werte stehen für 1, 5 und 15 Minuten.

Achtung: Load Average ist nicht dasselbe wie CPU-Prozent. Die Interpretation hängt unter anderem von der Zahl der CPU-Kerne und der Art der Wartezustände ab.

Mini-Visualisierung

Fiktive VM mit 4 logischen CPUs:

Zeit   Load 1m   Einordnung
08:00   0.8      geringe Last
08:15   5.7      auffällig
08:30   5.2      weiter erhöht

Begründung: Eine Load von deutlich über 4 auf einer 4-CPU-Lern-VM ist ein Anlass zur genaueren Analyse, aber noch keine vollständige Fehlerdiagnose.

Lerneinheit 4: Arbeitsspeicher beobachten

Bei Linux ist `MemAvailable` meist aussagekräftiger als nur `MemFree`, weil Dateicache bei Bedarf freigegeben werden kann.

free -h
grep -E 'MemTotal|MemAvailable|SwapTotal|SwapFree' /proc/meminfo

Fiktives Beispiel:

RAM gesamt       8.0 GiB
RAM verfügbar    2.5 GiB
Swap gesamt      2.0 GiB
Swap frei        2.0 GiB

Einordnung: Viel genutzter RAM ist nicht automatisch schlecht. Kritischer wird die Lage, wenn wenig Speicher verfügbar ist und gleichzeitig starker Swap- oder Paging-Druck auftritt.

Lerneinheit 5: Datenträger und I/O

Langsame Systeme können durch Datenträgerzugriffe gebremst werden. Beobachte zunächst Auslastung und freien Platz.

Linux:

df -h

Windows PowerShell:

Get-PSDrive -PSProvider FileSystem |
  Select-Object Name, Used, Free

Diagnoseregel: Ein fast voller Datenträger ist ein Zustand; hohe I/O-Aktivität ist ein anderer. Beide können zusammen auftreten, müssen es aber nicht.

Lerneinheit 6: Systemzustand zusammenführen

Eine Diagnose entsteht nicht aus einem Einzelwert.

Beobachtung	Aussage	Typische nächste Frage
CPU hoch	viel Rechenzeit belegt	Welcher Prozess?
RAM knapp	wenig verfügbarer Speicher	Wächst ein Prozess dauerhaft?
Dienst gestoppt	Funktion möglicherweise nicht verfügbar	Warum ist der Dienst gestoppt?
Load hoch	viele runnable oder I/O-wartende Tasks	CPU oder I/O?
Datenträger fast voll	Kapazitätsrisiko	Welches Verzeichnis wächst?

btop visualisiert CPU, Speicher, Datenträger, Netzwerk und Prozesse in einer gemeinsamen Ansicht.

Lokale Testumgebung A: Fiktiver Systemmonitor

Speichere den folgenden Code lokal als `monitor_lab.py`. Er nutzt nur die Python-Standardbibliothek, erzeugt keine echte Last und liest keine Kundendaten.

import random
import time

def bar(value, width=20):
    filled = round(value / 100 * width)
    return "[" + "#" * filled + "-" * (width - filled) + "]"

profiles = {
    "normal":   {"cpu": (15, 35), "ram": (45, 65), "disk": (5, 25)},
    "cpu":      {"cpu": (82, 98), "ram": (55, 72), "disk": (10, 35)},
    "memory":   {"cpu": (20, 45), "ram": (88, 97), "disk": (15, 40)},
    "io":       {"cpu": (25, 55), "ram": (55, 75), "disk": (80, 99)},
}

print("Lokales Monitoring-Lab mit rein fiktiven Daten")
print("Profile:", ", ".join(profiles))
choice = input("Profil wählen: ").strip().lower()
profile = profiles.get(choice, profiles["normal"])

for second in range(1, 6):
    cpu = random.randint(*profile["cpu"])
    ram = random.randint(*profile["ram"])
    disk = random.randint(*profile["disk"])
    print(f"\nMessung {second}")
    print(f"CPU  {bar(cpu)} {cpu:3d}%")
    print(f"RAM  {bar(ram)} {ram:3d}%")
    print(f"DISK {bar(disk)} {disk:3d}%")
    time.sleep(1)

Arbeitsauftrag: Starte nacheinander die Profile `normal`, `cpu`, `memory` und `io`. Erstelle je Profil eine Ein-Satz-Diagnose.

Begründetes Feedback:

Bei `cpu` ist zuerst die Prozess-CPU-Nutzung zu untersuchen.
Bei `memory` ist die Entwicklung des verfügbaren Speichers entscheidend.
Bei `io` sollte Datenträgeraktivität mit betroffenen Prozessen und Antwortzeiten verglichen werden.
`normal` zeigt, dass einzelne Prozentwerte nur im Kontext beurteilt werden dürfen.

Lokale Testumgebung B: Fiktive Prozessliste auswerten

Speichere als `process_lab.py`:

processes = [
    {"pid": 101, "name": "system-demo", "cpu": 2.1, "ram": 1.8},
    {"pid": 248, "name": "app-demo",    "cpu": 76.4, "ram": 12.3},
    {"pid": 377, "name": "backup-demo", "cpu": 8.5, "ram": 5.4},
    {"pid": 512, "name": "log-demo",    "cpu": 4.2, "ram": 2.0},
]

print("PID   Prozess        CPU%   RAM%")
for p in sorted(processes, key=lambda x: x["cpu"], reverse=True):
    print(f'{p["pid"]:>3}   {p["name"]:<12}  {p["cpu"]:>5.1f}  {p["ram"]:>5.1f}')

top = max(processes, key=lambda x: x["cpu"])
print(f"\nAuffälligste CPU-Nutzung: {top['name']} mit {top['cpu']} %")

Transferfrage: Warum wäre es falsch, `app-demo` sofort zu beenden?

Feedback: Beobachtung kommt vor Eingriff. Ein Prozess kann absichtlich stark arbeiten. Vor einer Änderung brauchst Du Kontext, Freigabe, Auswirkungen und möglichst weitere Messwerte.

Gestufte Hilfen zum Ausbildungsfall

Hilfe 1: Hinweis

Vergleiche CPU, RAM, Datenträger, Load und Dienststatus. Suche nach dem stärksten zeitlichen Zusammenhang.

Hilfe 2: Vorgehen

Prüfe, ob die CPU-Spitze gleichzeitig mit der schlechten Reaktion auftritt.
Ermittle den CPU-stärksten Prozess.
Vergleiche RAM und Datenträger.
Prüfe nur lesend den Dienststatus.
Formuliere eine Hypothese statt sofort eine Änderung vorzunehmen.

Hilfe 3: Musterweg

Die stärkste Auffälligkeit ist CPU. RAM und Datenträger steigen weniger stark. Der Dienst bleibt aktiv. Deshalb lautet eine gute Arbeitshypothese: Ein Prozess im Umfeld der Anwendung verursacht hohe CPU-Last. Danach wird lokal die Prozessliste nach CPU sortiert und dokumentiert.

Transferaufgabe: Diagnoseprotokoll

Erstelle für LAB-SRV-07 ein kurzes Protokoll:

Punkt	Beispiel
Symptom	Anwendung reagiert langsam
Zeitpunkt	08:15 bis 08:30
Auffälliger Messwert	CPU 91 % beziehungsweise 88 %
Dienststatus	aktiv
Arbeitshypothese	CPU-intensive Verarbeitung
Nächste sichere Prüfung	Prozessliste lokal nach CPU sortieren

Feedback: Gute Diagnoseprotokolle trennen Messwert, Interpretation und nächste Handlung.

Interaktive Aufgaben

Quiz: Teste Dein Wissen

Was kennzeichnet einen Prozess am treffendsten? (Eine laufende Instanz eines Programms) (!Eine dauerhaft gespeicherte Datei) (!Eine Netzwerkadresse) (!Ein Benutzerkonto)

Welche Kennung identifiziert einen Prozess auf einem laufenden System? (PID) (!DNS) (!SSID) (!URL)

Was zeigt top unter Linux hauptsächlich? (Einen dynamischen Blick auf System und Prozesse) (!Nur installierte Programme) (!Nur Netzwerkgeräte) (!Nur Benutzerkonten)

Was bedeutet ein aktiver Dienststatus sicher? (Der Dienst ist aktuell aktiv) (!Die Anwendung ist garantiert schnell) (!Die CPU ist niedrig ausgelastet) (!Es existiert kein Fehler)

Welcher Linux-Wert berücksichtigt besser kurzfristig verfügbaren Speicher? (MemAvailable) (!MemTotal) (!SwapTotal) (!Uptime)

Was beschreiben die ersten drei Werte in proc loadavg? (Lastmittel über 1 5 und 15 Minuten) (!CPU Takt über drei Kerne) (!Drei Prozesskennungen) (!Drei Datenträgergrößen)

Welche Handlung gehört zuerst zu einer sicheren Diagnose? (Beobachten und dokumentieren) (!Prozess sofort beenden) (!Dienst ungeprüft deaktivieren) (!Produktivsystem neu starten)

Was ist bei hoher CPU Nutzung die sinnvollste nächste Frage? (Welcher Prozess verbraucht die CPU Zeit) (!Welche Bildschirmauflösung ist eingestellt) (!Wie heißt das WLAN) (!Welcher Drucker ist Standard)

Wofür wird Get Service unter Windows verwendet? (Zum Abrufen von Dienstinformationen) (!Zum Formatieren von Datenträgern) (!Zum Löschen von Benutzerkonten) (!Zum Ändern der Firmware)

Warum reicht ein einzelner Messwert selten für eine Diagnose? (Weil Systemzustände im Zusammenhang bewertet werden müssen) (!Weil Messwerte grundsätzlich falsch sind) (!Weil Betriebssysteme keine Ressourcen messen) (!Weil Prozesse keine Ressourcen verwenden)

Begründetes Quiz-Feedback

Prozess und Programm sind nicht dasselbe: Erst die Ausführung erzeugt einen Prozess.
Eine PID ordnet Beobachtungen einer konkreten laufenden Instanz zu.
`top` kombiniert Systemübersicht und Prozessliste.
Ein Dienst kann aktiv und trotzdem überlastet oder fachlich gestört sein.
`MemAvailable` berücksichtigt abschätzbar nutzbaren Speicher und ist daher oft hilfreicher als nur freier RAM.
Load Average ist eine Zeitreihe über 1, 5 und 15 Minuten und kein CPU-Prozentwert.
Sichere Administration beginnt mit Beobachtung und nachvollziehbarer Dokumentation.
Hohe CPU wird erst durch die Zuordnung zu Prozessen diagnostisch nützlich.
`Get-Service` liefert lokale Dienstobjekte.
Ursache und Wirkung entstehen aus mehreren Messwerten und ihrem zeitlichen Zusammenhang.

Memory

PID	Prozesskennung
CPU	Rechenressource
MemAvailable	Verfügbarer Arbeitsspeicher
Load Average	Gemittelte Systemlast
systemctl	systemd Werkzeug
Get-Service	Windows Dienstabfrage

Drag and Drop

Ordne die richtigen Begriffe zu.	Thema
Prozess	Laufende Programminstanz
Dienst	Hintergrundfunktion des Systems
CPU	Rechenzeit
Arbeitsspeicher	Kurzfristig benötigte Daten und Programme
Datenträger	Persistente Speicherung

Kreuzworträtsel

Prozess	Wie heißt eine laufende Instanz eines Programms?
Speicher	Welche Ressource wird mit RAM bezeichnet?
Dienst	Wie heißt eine im Hintergrund bereitgestellte Systemfunktion?
Systemd	Welcher Linux Dienstmanager wird im Kurs behandelt?
Taskmanager	Welches Windows Werkzeug visualisiert Prozesse und Auslastung?
Diagnose	Wie nennt man die systematische Untersuchung einer Störung?

LearningApps

Lückentext

Offene Aufgaben

Leicht

Prozessliste: Beobachte auf einer lokalen Lernmaschine fünf Prozesse und notiere PID, Name und eine Ressource.
Systemauslastung: Erstelle aus drei fiktiven CPU-Werten eine kleine Balkengrafik auf Papier oder digital.
Dienststatus: Vergleiche die Begriffe aktiv, inaktiv und fehlgeschlagen und formuliere je einen Beispielsatz.
Diagnoseprotokoll: Übertrage den Ausbildungsfall in eine Tabelle mit Symptom, Messwert, Hypothese und nächster Prüfung.

Standard

Ressourcenvergleich: Vergleiche lokal CPU, RAM und Datenträger über fünf Minuten und beschreibe zwei Zusammenhänge.
PowerShell: Sortiere auf einem lokalen Windows-Lernsystem Prozesse nach CPU-Zeit und erkläre die Grenzen dieses Messwerts.
Linux-Prozessanalyse: Nutze `ps` und `top` auf einer freigegebenen Linux-VM und vergleiche Momentaufnahme mit dynamischer Ansicht.
Fehlerhypothese: Entwickle drei mögliche Ursachen für „Dienst aktiv, Anwendung langsam“ und ordne passende Prüfungen zu.

Schwer

Monitoring-Konzept: Entwirf für eine fiktive Schulungs-VM einen Beobachtungsplan aus Messwert, Intervall, Grenzsignal und Reaktion.
Zeitreihenanalyse: Erzeuge mit dem lokalen Python-Lab fünf Durchläufe und begründe, welcher Verlauf auf CPU-, Speicher- oder I/O-Probleme hindeutet.
Transferdiagnose: Erhalte fiktive Messwerte von zwei Systemen und entscheide, welches zuerst untersucht werden sollte. Begründe anhand von Auswirkungen und Evidenz.
Ausbildungsdokumentation: Erstelle ein einseitiges Handout „Beobachten vor Eingreifen“ mit sicheren lokalen Kommandos und klaren Grenzen.

Lernkontrolle

Zusammenhang CPU und Prozess: Ein System zeigt 95 % CPU, der Dienststatus ist aktiv. Beschreibe eine sichere Diagnosekette mit mindestens drei Beobachtungsschritten und begründe ihre Reihenfolge.
Zusammenhang RAM und Cache: Erkläre, warum wenig `MemFree` allein noch keinen Speichermangel beweist und welche Zusatzwerte Du prüfen würdest.
Vergleich Windows Linux: Entwickle eine gemeinsame Beobachtungsstrategie, obwohl Windows und Linux unterschiedliche Werkzeuge verwenden.
Transfer Load Average: Zwei Linux-VMs zeigen Load 4,0. Eine hat 2 logische CPUs, die andere 8. Erkläre, warum derselbe Wert unterschiedlich eingeordnet werden kann.
Ursache Wirkung: Entwirf ein Beispiel, bei dem ein Dienst aktiv ist, die Anwendung aber langsam reagiert. Trenne Symptom, Messwert, Hypothese und sichere Prüfung.
Entscheidung unter Unsicherheit: Du siehst erhöhte CPU und erhöhte Datenträgeraktivität. Erkläre, welche zusätzliche Beobachtung helfen würde, zwischen Rechen- und I/O-Engpass zu unterscheiden.

Lernnachweis

Für einen Lernnachweis solltest Du zeigen, dass Du:

Prozesse, Dienste und Ressourcen fachlich unterscheiden kannst.
CPU-, RAM-, Datenträger- und Lastwerte nicht isoliert, sondern im Zusammenhang bewertest.
unter Windows und Linux sichere, lokale Beobachtungswerkzeuge auswählen kannst.
Messwert, Interpretation und Hypothese sauber trennst.
eine Störung anhand fiktiver oder ausdrücklich freigegebener lokaler Daten nachvollziehbar dokumentierst.
vor Änderungen Auswirkungen, Freigabe und Sicherheitsrahmen prüfst.
keine fremden Netze, Produktivsysteme, Zugangsdaten oder Kundendaten für Übungszwecke verwendest.

Fachquellen und Medienrechte

Fachlich geprüft:

Microsoft Learn: Troubleshoot processes by using Task Manager – Task-Manager als integrierte Windows-Lösung zur Beobachtung von Prozessen und Ressourcen.
Microsoft Learn: Get-Service – lokale Windows-Dienste abfragen.
Microsoft Learn: Get-Process – Prozesse abrufen.
Linux manual page: top – dynamische Echtzeitsicht auf Prozesse und System.
Linux manual page: proc_loadavg – Bedeutung der Load-Average-Felder.
Linux manual page: proc_meminfo – Speicherstatistiken.
systemd: systemctl – Status und Eigenschaften von Units.
Linux Kernel Documentation: proc – Kernel-Schnittstelle für Prozess- und Systeminformationen.

Verwendete Commons-Medien und Rechte:

Operating system placement-de.svg – freie Lizenz laut Commons-Dateiseite.
Process states.en.svg – Free Art License beziehungsweise GFDL laut Commons-Dateiseite.
Top Linux screenshot – freier Software-Screenshot laut Commons.
Htop 3.0.1 screenshot – GPL-basierter freier Software-Screenshot.
Systemd-logo.svg – CC BY-SA 4.0.
Task-Manager-Screenshot – Rechteangaben auf Commons beachten.
Btop-system-monitor.png – freie Medienangaben auf Commons beachten.