IT-Monitoring – Grundlagen

Was ist IT-Monitoring und warum brauchst du es?

Stell dir vor, dein Fileserver läuft seit drei Stunden mit 99 % CPU-Last – und du merkst es erst, wenn das erste Ticket reinkommt: “Alles lahm.” Genau das verhindert IT-Monitoring. Statt reaktiv auf Beschwerden zu warten, überwachst du deine Systeme proaktiv und wirst benachrichtigt, bevor die Lage eskaliert.

IT-Monitoring ist die kontinuierliche Überwachung von Servern, Netzwerkgeräten, Diensten und Anwendungen auf Verfügbarkeit, Performance und Sicherheitsereignisse. Es ist kein Nice-to-have – es ist die Grundlage eines stabilen IT-Betriebs, egal ob du 20 oder 200 Geräte betreust.

Was wird überwacht? Die sechs Dimensionen

Ein vollständiges Monitoring-Konzept deckt mehrere Schichten ab:

Besonders Backup-Monitoring wird im Alltag gern vergessen – bis man das Backup braucht und merkt, dass es seit Wochen fehlschlägt. Verknüpfe Monitoring direkt mit deiner Backup-Strategie.

Die wichtigsten Metriken und Schwellwerte

Diese Richtwerte sind ein bewährter Startpunkt. Du wirst sie nach einigen Wochen Monitoring an deine Umgebung anpassen – jeder Server verhält sich anders.

Monitoring-Tools im Überblick

PRTG Network Monitor (Paessler)

PRTG ist der Klassiker im Windows-KMU-Umfeld. Die Installation läuft auf Windows Server, die Konfiguration erfolgt über eine Web-Oberfläche. Das Lizenzmodell basiert auf “Sensoren” – jede überwachte Metrik (z. B. CPU eines Servers) zählt als ein Sensor. Bis 100 Sensoren ist PRTG dauerhaft kostenlos – damit kommt ein kleines KMU gut hin.

Stärken:

• Auto-Discovery findet Geräte im Netz automatisch
• Hunderte vordefinierter Sensor-Templates
• SNMP, WMI, REST API, Ping, Port – alles dabei
• Gute Dokumentation auf Deutsch

Schnellstart mit PRTG:

1. PRTG herunterladen und auf einem Windows Server installieren
2. Auto-Discovery starten: Netzwerk-Subnetz eingeben, PRTG scannt und erstellt Sensoren automatisch
3. Benachrichtigungen einrichten: Einstellungen > Benachrichtigungen > E-Mail-Konto hinterlegen
4. Standard-Schwellwerte überprüfen und an deine Umgebung anpassen

Zabbix

Zabbix ist Open Source, komplett kostenlos und extrem leistungsfähig – dafür auch deutlich komplexer. Es läuft auf Linux (Ubuntu/Debian empfohlen) und nutzt eine eigene Datenbank (MySQL/PostgreSQL). Die Lernkurve ist steiler, aber die Möglichkeiten sind nahezu unbegrenzt.

Wann Zabbix wählen:

• Grosse Umgebungen mit vielen Hosts
• Komplexe Trigger-Logik und Korrelation
• Kein Budget für kommerzielle Lizenzen
• Du hast Linux-Know-how

Typischer Zabbix-Stack:

Zabbix Server → Zabbix Agent (auf jedem Host) → Zabbix Frontend (Web-UI)
                                               → Grafana (optionale Visualisierung)

Grafana + Prometheus

Der moderne DevOps-Stack: Prometheus sammelt Metriken (Time-Series-Datenbank), Grafana visualisiert sie in flexiblen Dashboards. Besonders stark für Container/Kubernetes-Umgebungen.

Prometheus → scrapet Metriken von Exportern (node_exporter, windows_exporter)
Grafana    → fragt Prometheus ab → zeigt Dashboards
Alertmanager → sendet Alerts aus Prometheus-Regeln

Für reine Windows-Umgebungen im KMU ist der Setup-Aufwand oft zu hoch – PRTG oder Checkmk sind pragmatischer.

Checkmk

Checkmk ist eine starke Open-Source-Alternative zu PRTG, mit einer vergleichbar einfachen Bedienung. Die Raw Edition ist kostenlos, die Cloud/Enterprise Editions sind kostenpflichtig. Installation läuft auf Linux.

Uptime Kuma

Uptime Kuma ist das leichtgewichtigste Tool im Vergleich – ideal als Ergänzung oder als Einstieg. Es läuft als Docker-Container und überwacht Verfügbarkeit von HTTP-Endpunkten, Ports, DNS, Zertifikaten usw. Kein Agent, kein Server-Monitoring, aber ein tolles Status-Dashboard.

# Uptime Kuma mit Docker starten
docker run -d --restart=always -p 3001:3001 \
  -v uptime-kuma:/app/data \
  --name uptime-kuma \
  louislam/uptime-kuma:1

Danach erreichbar unter http://server-ip:3001.

Monitoring mit PowerShell – der schnelle Einstieg

Bevor du ein Tool installierst, kannst du mit PowerShell sofort loslegen. Gerade für einfache Checks oder als Ergänzung zu einem Monitoring-Tool sind diese Befehle praktisch:

# Erreichbarkeit eines Servers prüfen (Ping)
Test-Connection -ComputerName "fileserver01" -Count 3

# TCP-Port testen (z.B. RDP Port 3389)
Test-NetConnection -ComputerName "fileserver01" -Port 3389

# Mehrere Server auf Erreichbarkeit prüfen
$server = @("fileserver01", "dc01", "sql01", "printserver")
foreach ($s in $server) {
    $ping = Test-Connection -ComputerName $s -Count 1 -Quiet
    [PSCustomObject]@{ Server = $s; Erreichbar = $ping }
} | Format-Table -AutoSize

# Disk-Belegung aller Laufwerke auf einem Remote-Server prüfen
Get-WmiObject Win32_LogicalDisk -ComputerName "fileserver01" |
    Where-Object { $_.DriveType -eq 3 } |
    Select-Object DeviceID,
        @{N="GesamtGB"; E={[math]::Round($_.Size/1GB,1)}},
        @{N="FreiGB";    E={[math]::Round($_.FreeSpace/1GB,1)}},
        @{N="FreiProzent"; E={[math]::Round(($_.FreeSpace/$_.Size)*100,1)}} |
    Format-Table -AutoSize

# Windows-Dienst überwachen – ist er gestartet?
Get-Service -ComputerName "fileserver01" -Name "Spooler","W32Time","Netlogon" |
    Select-Object MachineName, Name, Status | Format-Table

# CPU-Last der letzten Minute (lokal)
Get-CimInstance Win32_Processor | Select-Object Name,
    @{N="CPU%"; E={$_.LoadPercentage}}

# RAM-Auslastung (lokal)
$os = Get-CimInstance Win32_OperatingSystem
$ramTotal = [math]::Round($os.TotalVisibleMemorySize/1MB, 1)
$ramFrei  = [math]::Round($os.FreePhysicalMemory/1MB, 1)
$ramGenutzt = [math]::Round((($os.TotalVisibleMemorySize - $os.FreePhysicalMemory) / $os.TotalVisibleMemorySize) * 100, 1)
"RAM: $ramGenutzt% genutzt ($ramFrei GB frei von $ramTotal GB)"

Einfaches Monitoring-Skript mit E-Mail-Alert

Dieses Beispiel prüft Ping und Disk und sendet bei einem Problem eine E-Mail:

# monitoring-check.ps1 – als geplante Aufgabe einrichten (täglich / stündlich)
$smtpServer = "smtp.firma.ch"
$absender   = "monitoring@firma.ch"
$empfaenger = "it@firma.ch"
$probleme   = @()

# Server-Liste
$server = @("dc01","fileserver01","sql01")

foreach ($s in $server) {
    if (-not (Test-Connection -ComputerName $s -Count 2 -Quiet)) {
        $probleme += "WARNUNG: $s nicht erreichbar!"
    }
}

# Disk-Check (lokal, erweiterbar auf Remote)
$disks = Get-WmiObject Win32_LogicalDisk | Where-Object { $_.DriveType -eq 3 }
foreach ($d in $disks) {
    $freiProzent = [math]::Round(($d.FreeSpace / $d.Size) * 100, 1)
    if ($freiProzent -lt 15) {
        $probleme += "WARNUNG: Laufwerk $($d.DeviceID) nur noch $freiProzent% frei!"
    }
}

# Alert senden wenn Probleme vorhanden
if ($probleme.Count -gt 0) {
    $body = $probleme -join "`n"
    Send-MailMessage -SmtpServer $smtpServer -From $absender -To $empfaenger `
        -Subject "IT-Monitoring Alert – $(Get-Date -Format 'dd.MM.yyyy HH:mm')" `
        -Body $body
}

Dieses Skript planst du als geplante Aufgabe: Win+R → taskschd.msc → neue Aufgabe erstellen, Trigger “Täglich alle 1 Stunde”, Aktion “PowerShell -File C:\Scripts\monitoring-check.ps1”.

Alerting richtig konfigurieren

Ein Monitoring-System ohne Alerting ist wie ein Feuermelder ohne Sirene. Alerting ist das Herzstück – und gleichzeitig die grösste Fehlerquelle, wenn es schlecht konfiguriert ist.

Häufige Fehler beim Alerting:

• Zu viele Alerts: Jedes kleine Problem löst einen Alarm aus. Resultat: Alert Fatigue, Alerts werden ignoriert.
• Alert zu spät: Erst nach 30 Minuten wird gewarnt, obwohl das Problem seit 5 Minuten bekannt ist.
• Kein Eskalations-Routing: Alle Alerts gehen an alle. Wichtige Meldungen gehen unter.
• Kein Wiederholungs-Check: Einmaliger Packet Loss löst sofort Alarm aus.

Besser machen:

1. Mindestdauer definieren: CPU > 90 % muss für mindestens 5 Minuten anhalten, bevor ein Alert rausgeht
2. Prioritäten stufen: P1 (Server down) → SMS + Anruf. P3 (Disk 20 % frei) → E-Mail reicht
3. Benachrichtigungs-Kanäle: E-Mail für alles, Teams/Slack-Webhook für P1/P2, SMS für echte Notfälle
4. Maintenance Windows: Geplante Wartungen (Updates, Backups) von Alerts ausschliessen, damit keine Fake-Alarms entstehen
5. Dependency-Mapping: Wenn der Core-Switch down ist, sollen nicht 50 Alerts für alle dahinter liegenden Server kommen – nur einer für den Switch

Monitoring-Architektur im KMU – so sieht es aus

Ein typisches Setup für ein KMU mit 20–100 Geräten:

Netzwerk:
  Router / Firewall  → SNMP-Monitoring (Bandbreite, Paketverlust)
  Switches           → SNMP (Port-Status, Uptime)
  WLAN-Controller    → Verfügbarkeit, verbundene Clients

Server:
  Domain Controller  → Ping, WMI, Windows-Dienste (Netlogon, DNS, DHCP)
  Fileserver         → Disk, CPU, RAM, SMB-Dienst
  Backup-Server      → Backup-Job-Status, freier Speicher

Endpoints (optional):
  Kritische Workstations → Ping-Verfügbarkeit

Externe Dienste:
  Website / Webmail  → HTTP-Check, SSL-Zertifikat
  VPN-Gateway        → Port-Check von aussen

Das Monitoring-Tool selbst läuft idealerweise auf einem dedizierten Server oder einer VM. Wird dieser Server selbst zum Monitoring-Objekt seiner eigenen Tools, entsteht kein Mehrwert – deswegen sollte eine zweite, einfachere Lösung (z. B. Uptime Kuma auf einer anderen VM) den Monitoring-Server selbst überwachen.

Zertifikats-Monitoring – oft vergessen, immer schmerzhaft

Ein abgelaufenes SSL-Zertifikat macht deine Website oder dein VPN für alle Benutzer unerreichbar. Mit einem simplen PowerShell-Check kannst du das verhindern:

# SSL-Zertifikat Ablaufdatum prüfen
function Test-SslCertExpiry {
    param (
        [string]$Hostname,
        [int]$WarnDays = 30
    )
    $req = [System.Net.HttpWebRequest]::Create("https://$Hostname")
    $req.ServerCertificateValidationCallback = { $true }
    try {
        $resp = $req.GetResponse()
        $cert  = $req.ServicePoint.Certificate
        $ablauf = [datetime]::Parse($cert.GetExpirationDateString())
        $verbleibend = ($ablauf - (Get-Date)).Days
        [PSCustomObject]@{
            Host        = $Hostname
            Ablauf      = $ablauf.ToString("dd.MM.yyyy")
            Verbleibend = $verbleibend
            Status      = if ($verbleibend -lt 7) {"KRITISCH"} elseif ($verbleibend -lt $WarnDays) {"WARNUNG"} else {"OK"}
        }
    } catch {
        [PSCustomObject]@{ Host = $Hostname; Ablauf = "Fehler"; Verbleibend = -1; Status = "FEHLER" }
    }
}

# Mehrere Domains prüfen
@("firma.ch","webmail.firma.ch","vpn.firma.ch") | ForEach-Object {
    Test-SslCertExpiry -Hostname $_
} | Format-Table -AutoSize

Mehr zum Thema Zertifikate findest du auf der Seite SSL/TLS-Zertifikate.

Troubleshooting: Monitoring funktioniert nicht wie erwartet

Manchmal zeigt das Monitoring-Tool Fehler an, obwohl alles läuft – oder umgekehrt. Hier die häufigsten Ursachen:

Ping-Check schlägt fehl, Server läuft aber:

• Windows Firewall blockiert ICMP. Regel prüfen oder Port-Check statt Ping nutzen.

# ICMP eingehend erlauben (temporär für Test)
New-NetFirewallRule -DisplayName "Ping erlauben (Monitoring)" `
    -Direction Inbound -Protocol ICMPv4 -IcmpType 8 -Action Allow

WMI-Abfragen schlagen fehl (PRTG, PowerShell Remote):

• WMI-Dienst auf Zielhost läuft? Get-Service WinMgmt
• Firewall-Ausnahme für WMI gesetzt?
• Monitoring-Dienstkonto hat lokale Admin-Rechte auf Zielhost?

# WMI-Firewall-Ausnahme aktivieren
Enable-NetFirewallRule -Name "WMI-WINMGMT-In-TCP"
Enable-NetFirewallRule -Name "WMI-ASYNC-In-TCP"

SNMP funktioniert nicht (Router/Switch):

• Community String auf Gerät und im Monitoring-Tool identisch?
• Quelladresse des Monitoring-Servers in der SNMP-ACL des Geräts erlaubt?
• SNMPv2c oder SNMPv3? (SNMPv3 = mit Authentifizierung, sicherer)

Zu viele False Positives:

• Mindestdauer für Alerts erhöhen (5–10 Minuten statt sofort)
• Check-Interval verringern (alle 5 Min statt jede Minute)
• Maintenance Windows für bekannte Wartungszeiten konfigurieren

Microsoft Azure Monitor – Monitoring für Cloud-Umgebungen

Falls du Microsoft 365 und Azure nutzt, bietet Azure Monitor eine integrierte Lösung. Es sammelt Metriken und Logs von Azure-Ressourcen, M365-Diensten und kann mit Log Analytics (KQL-Abfragesprache) ausgewertet werden.

Für reine On-Premise-Umgebungen ist Azure Monitor kaum relevant, aber in Hybrid-Setups lohnt sich der Blick. Der Microsoft 365 Admin Center bietet zudem ein eigenes Service-Health-Dashboard, das dir sofort zeigt, ob Microsoft-Dienste beeinträchtigt sind – bevor deine Nutzer Tickets schreiben.

Mehr dazu in der Seite Microsoft 365 – Übersicht.

Weiterlernen

• PRTG Knowledge Base – Offizielle Dokumentation (Paessler)
• PRTG Network Monitoring Best Practices (Paessler Blog)
• Best Practices for Monitoring and Alerting (Paessler Blog)
• Zabbix Dokumentation (Zabbix.com)
• Grafana Dokumentation – Getting Started
• Azure Monitor Dokumentation (Microsoft Learn)

Videos

YouTube

YouTube