PHP_AdminTool_Projekt/CHANGELOG.md
Tom c03a99d07a Updated Snmp and Interface
Ich habe das UI Testweise nochmal erweitert und die Art wie wir die SNMP Daten abrufen und anzeigen nochmal überarbeitet. Es gibt jetzt eine kleine API die über Javascript in Intervallen die Daten aktualisiert. In der Datei Changelog sind nochmal die genauen Änderungen erklärt.
2025-12-03 17:06:10 +01:00

298 lines
8.9 KiB
Markdown
Raw Permalink Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# CHANGELOG
## 2025-12-03 — SNMP Live-Dashboard (Architektur: Service + API)
### Übersicht
Implementierung eines **dualen SNMP-Status-Systems**:
1. **Server-seitig (Initial Load):** `DashboardController``SnmpServerStatusService`
2. **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):**
1. Heuristik: Suche nach "Physical Memory" (exakt)
2. Fallback 1: Suche nach "physical" ODER "memory" ODER "ram" (Case-insensitive)
3. Fallback 2: Nimm den **kleinsten Storage-Eintrag** (wahrscheinlich RAM)
4. Falls alles fehlschlägt: Exception → abgefangen im Controller → 0% angezeigt
**Disk-Erkennung (in dieser Reihenfolge):**
1. Heuristik: Suche nach "C:\\" (Windows, exakt)
2. Fallback 1: Suche nach "C:" ODER "root" ODER "/" (Case-insensitive)
3. Fallback 2: Nimm den **größten Storage-Eintrag > 1 GB** (wahrscheinlich Hauptlaufwerk)
4. 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**:
```php
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
```bash
# Browser öffnen, als Admin einloggen
# Dashboard öffnen
# → Sollten Werte sichtbar sein (entweder echte oder 0%)
```
### 2. Service-Fehler simulieren
```php
// In DashboardController.php: Service-Aufruf kommentieren
// $serverStatus = [... Fallback-Werte ...];
// → Dashboard sollte trotzdem laden (mit 0%)
```
### 3. API testen
```bash
# 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
```bash
# 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
```bash
# Temp-Datei prüfen
# Windows: %TEMP%\snmp_status_cache.json
# Linux: /tmp/snmp_status_cache.json
# → Sollte JSON enthalten
```
---
## Known Issues & Limitations
1. **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
2. **Cache-Speicher:** Erfordert Schreibzugriff auf `sys_get_temp_dir()`
- **Lösung:** Falls nicht verfügbar → Cache-Code entfernen oder APCu/Redis nutzen
3. **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:**
1. Initial Load via Service (sofortige Daten)
2. 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)