blaerf e82c2c041a snmp_update2 (#14 )

Co-authored-by: Tom <165781231+GraegelTh@users.noreply.github.com>
Reviewed-on: https://git.eckertplayground.de/taarly/PHP_AdminTool_Projekt/pulls/14

2025-12-04 03:30:46 +00:00

8.9 KiB

Raw Blame History

CHANGELOG

2025-12-03 — SNMP Live-Dashboard (Architektur: Service + API)

Übersicht

Implementierung eines dualen SNMP-Status-Systems:

Server-seitig (Initial Load): DashboardController → SnmpServerStatusService
Client-seitig (Live-Updates): Browser-JavaScript → API-Endpunkt (snmp_status.php)

Ergebnis: Beste User Experience (sofortige Daten beim Laden) + Redundanz (Live-Polling läuft weiter, auch wenn Service fehlt).

Komponente 1: Service (`app/Services/Snmp/SnmpServerStatusService.php`) — modernisiert

Was wurde geändert?

Die alte Version ist zu streng gewesen (wirft Exception wenn "Physical Memory" nicht exakt gefunden wird). Neue Version hat intelligente Fallback-Logik:

RAM-Erkennung (in dieser Reihenfolge):

Heuristik: Suche nach "Physical Memory" (exakt)
Fallback 1: Suche nach "physical" ODER "memory" ODER "ram" (Case-insensitive)
Fallback 2: Nimm den kleinsten Storage-Eintrag (wahrscheinlich RAM)
Falls alles fehlschlägt: Exception → abgefangen im Controller → 0% angezeigt

Disk-Erkennung (in dieser Reihenfolge):

Heuristik: Suche nach "C:\" (Windows, exakt)
Fallback 1: Suche nach "C:" ODER "root" ODER "/" (Case-insensitive)
Fallback 2: Nimm den größten Storage-Eintrag > 1 GB (wahrscheinlich Hauptlaufwerk)
Falls alles fehlschlägt: Exception → abgefangen im Controller → 0% angezeigt

Featureset

✅ Robuste Fehlerbehandlung (aussagekräftige RuntimeException für Debugging)
✅ Intelligente Fallbacks bei unerwarteten OID-Beschreibungen
✅ Unterstützung Windows + Linux
✅ Prüfung auf SNMP-Erweiterung und Konfiguration
✅ Uptime in lesbares Format konvertieren (z. B. "1 Tage, 10:17:36")
✅ CPU-Durchschnitt über alle Kerne

Komponente 2: Controller (`app/Controllers/DashboardController.php`) — neu strukturiert

Was wurde geändert?

Der Controller hatte nur eine Zeile geändert; jetzt fehlertolerante Abfrage:

try {
    $serverStatus = $this->snmpService->getServerStatus();
} catch (\RuntimeException $e) {
    error_log('SNMP-Fehler beim initialen Laden - ' . $e->getMessage());
    // Fallback-Werte werden verwendet (siehe oben)
}

Effekt:

Wenn Service fehlschlägt: Dashboard wird trotzdem geladen (mit 0% oder 'n/a')
Fehler wird geloggt (PHP Error-Log)
Live-Polling (API) läuft trotzdem weiter und kann Daten liefern
Bessere User Experience statt "Error 500"

Komponente 3: API (`public/api/snmp_status.php`)

Siehe vorherige CHANGELOG-Einträge. Wichtig:

Identische Fallback-Logik wie der Service
Session-Validierung (nur Admins)
Caching (10 Sekunden)
Detailliertes Logging in public/logs/snmp_api.log

Komponente 4: View & JavaScript (`public/views/dashboard.php`)

Siehe vorherige CHANGELOG-Einträge.

Architektur: Dual-Layer System

Layer 1: Initial Load (Server-seitig)

Nutzer öffnet Dashboard
         ↓
DashboardController::show()
         ↓
SnmpServerStatusService::getServerStatus()
         ↓
SNMP-Abfrage (mit Fallbacks)
         ↓
Daten sofort in View angezeigt
         ↓
(Bei Fehler: Fallback-Werte wie 0%, 'n/a')
         ↓
Logging in PHP Error-Log

Vorteile:

✅ Daten sind sofort sichtbar (gute UX)
✅ Fallbacks verhindern "Error 500"
✅ Service wird nur 1x pro Seitenladung aufgerufen (sparsam)

Layer 2: Live-Updates (Client-seitig)

Browser lädt Dashboard
         ↓
JavaScript addEventListener('DOMContentLoaded')
         ↓
Sofort erste Abfrage: fetch('api/snmp_status.php')
         ↓
Antwort: JSON mit aktuellen Daten
         ↓
updateUI() aktualisiert die Karten
         ↓
Alle 5 Sekunden wiederholt (setInterval)
         ↓
Logging in public/logs/snmp_api.log (Server-seitig)

Vorteile:

✅ Live-Updates ohne Seite zu reload-en
✅ Session-Schutz (nur Admins können Endpunkt aufrufen)
✅ Caching reduziert SNMP-Last (10s TTL)
✅ Fallback-Logik im API unabhängig vom Service
✅ Redundanz: Wenn Service fehlt, läuft API trotzdem

Logging

PHP Error-Log (Service-Fehler)

Ort: Abhängig von PHP-Konfiguration (meist /var/log/php-errors.log oder Windows Event-Log)
Format: Standard PHP Error-Log
Inhalt: SNMP-Fehler beim initialen Laden (z. B. "SNMP-Konfiguration ist unvollständig")
Trigger: Nur wenn Service-Abfrage fehlschlägt

Beispiel:

[03-Dec-2025 12:05:00 UTC] DashboardController: SNMP-Fehler beim initialen Laden - SNMP-Konfiguration ist unvollständig (host fehlt).

SNMP API Log (`public/logs/snmp_api.log`)

Ort: public/logs/snmp_api.log (wird automatisch angelegt)
Format: [YYYY-MM-DD HH:MM:SS] Nachricht
Inhalt:
- Cache-Hits/Misses
- SNMP-Konfiguration
- Alle Storage-Einträge
- Erkannte Disk/RAM mit Prozentsätzen
- Fallback-Aktionen
- Finale Werte
- Fehler

Beispiel:

[2025-12-03 12:05:00] --- SNMP-Abfrage gestartet ---
[2025-12-03 12:05:00] SNMP-Host: 127.0.0.1, Community: public_ro, Timeout: 2s
[2025-12-03 12:05:00] Uptime OID: 1.3.6.1.2.1.1.3.0, Raw: "Timeticks: (1234567) 14 days, 6:14:27.67"
[2025-12-03 12:05:00] Storage[1]: Desc='Physical Memory', Size=16777216, Used=8388608, Units=1024
[2025-12-03 12:05:00] Speicher erkannt (Index 1): Physical Memory → 50.00%
[2025-12-03 12:05:00] Storage[2]: Desc='C:\\ ', Size=536870912, Used=268435456, Units=512
[2025-12-03 12:05:00] Datenträger erkannt (Index 2): C:\\ → 50.00%
[2025-12-03 12:05:00] RESULT: CPU=25, Mem=50.00, Disk=50.00
[2025-12-03 12:05:00] Cache geschrieben, TTL: 10s

Fehlerszenarien & Behavior

Szenario 1: SNMP läuft, alles OK

Service: ✅ Daten sofort angezeigt
API:     ✅ Live-Updates alle 5s
Logs:    ✅ Beide Logs ganz normal

Szenario 2: SNMP-Erweiterung fehlt

Service: ❌ Exception → abgefangen → 0%, 'n/a' angezeigt
API:     ❌ Exception → abgefangen → {"error": "snmp_extension_missing"}
Logs:    ⚠️  Beide Logs zeigen Fehler
User-View: "Metriken werden angezeigt (0%), aber nicht aktualisiert"
Aktion:    Admin sieht Fehler im Log und installiert SNMP

Szenario 3: SNMP antwortet, aber Beschreibungen sind unbekannt

Service: ✅ Fallback-Logik findet RAM/Disk trotzdem
API:     ✅ Fallback-Logik findet RAM/Disk trotzdem
Logs:    ℹ️  `Fallback RAM gefunden` / `Fallback Disk gefunden`
User-View: ✅ Daten werden angezeigt

Szenario 4: Service fehlt, API läuft

Service: ❌ Exception beim Laden
API:     ✅ Live-Updates funktionieren normal
User-View: "Beim Laden: 0%, nach 5s: aktuelle Werte"
Gut genug!

Testing-Anleitung

1. Initialer Load testen

# Browser öffnen, als Admin einloggen
# Dashboard öffnen
# → Sollten Werte sichtbar sein (entweder echte oder 0%)

2. Service-Fehler simulieren

// In DashboardController.php: Service-Aufruf kommentieren
// $serverStatus = [... Fallback-Werte ...];
// → Dashboard sollte trotzdem laden (mit 0%)

3. API testen

# Browser DevTools → Network → api/snmp_status.php
# → Sollte JSON zurückgeben
# Bei 401 → Session fehlt (erwartet wenn nicht angemeldet)
# Sollte aber funktionieren wenn angemeldet

4. Logs prüfen

# PHP Error-Log
error_log() Output ansehen

# SNMP API Log
cat public/logs/snmp_api.log
# Sollte Einträge zeigen (mit Timestamps)

5. Cache prüfen

# Temp-Datei prüfen
# Windows: %TEMP%\snmp_status_cache.json
# Linux: /tmp/snmp_status_cache.json
# → Sollte JSON enthalten

Known Issues & Limitations

Disk/RAM-Heuristik: Bei sehr ungewöhnlichen Storage-Labels können Fallbacks greifen, die nicht ideal sind
- Lösung: Log prüfen (Storage[X]: Einträge) und ggf. Heuristiken anpassen
Cache-Speicher: Erfordert Schreibzugriff auf sys_get_temp_dir()
- Lösung: Falls nicht verfügbar → Cache-Code entfernen oder APCu/Redis nutzen
OS-Feld: Hardcoded auf "Windows Server" (TODO: Dynamisch per OID 1.3.6.1.2.1.1.1.0)

Performance

Service-Abfrage: 1x pro Seitenladung (~100-500ms je nach SNMP-Timeout)
API-Abfrage: Alle 5s, aber gecacht für 10s → effektiv alle 10s eine echte SNMP-Abfrage
JavaScript Polling: 5s Intervall (Browser-seitig, keine Last auf Server)
Gesamt: Sehr effizient, auch bei vielen gleichzeitigen Nutzern

Summary für Kollegen

✅ Live-Dashboard mit zwei Ebenen:

Initial Load via Service (sofortige Daten)
Live-Polling via API (kontinuierliche Updates)

✅ Robuste Fallback-Logik für RAM und Disk (findet die Werte auch bei unbekannten Labels)

✅ Dual Logging:

PHP Error-Log für Service-Fehler
public/logs/snmp_api.log für API-Aktivitäten

✅ Session-Geschützt: Nur Admins können Status abrufen

✅ Gecacht: 10 Sekunden TTL reduziert SNMP-Load

✅ Error-tolerant: Dashboard funktioniert auch wenn SNMP fehlt (zeigt 0%, wartet auf Live-Updates)

8.9 KiB Raw Blame History Unescape Escape

CHANGELOG

2025-12-03 — SNMP Live-Dashboard (Architektur: Service + API)

Übersicht

Komponente 1: Service (app/Services/Snmp/SnmpServerStatusService.php) — modernisiert

Was wurde geändert?

Featureset

Komponente 2: Controller (app/Controllers/DashboardController.php) — neu strukturiert

Was wurde geändert?

Komponente 3: API (public/api/snmp_status.php)

Komponente 4: View & JavaScript (public/views/dashboard.php)

Architektur: Dual-Layer System

Layer 1: Initial Load (Server-seitig)

Layer 2: Live-Updates (Client-seitig)

Logging

PHP Error-Log (Service-Fehler)

SNMP API Log (public/logs/snmp_api.log)

Fehlerszenarien & Behavior

Szenario 1: SNMP läuft, alles OK

Szenario 2: SNMP-Erweiterung fehlt

Szenario 3: SNMP antwortet, aber Beschreibungen sind unbekannt

Szenario 4: Service fehlt, API läuft

Testing-Anleitung

1. Initialer Load testen

2. Service-Fehler simulieren

3. API testen

4. Logs prüfen

5. Cache prüfen

Known Issues & Limitations

Performance

Summary für Kollegen

8.9 KiB

Raw Blame History

Komponente 1: Service (`app/Services/Snmp/SnmpServerStatusService.php`) — modernisiert

Komponente 2: Controller (`app/Controllers/DashboardController.php`) — neu strukturiert

Komponente 3: API (`public/api/snmp_status.php`)

Komponente 4: View & JavaScript (`public/views/dashboard.php`)

SNMP API Log (`public/logs/snmp_api.log`)