CW Monitoring

Version 0.1.0-alpha17.5

## Fix: 100 % abgeschlossen, aber Ansicht bleibt stehen

• Nach einem erfolgreichen Remote-Update konnte die Nachprüfung bereits erfolgreich beendet sein, während die Oberfläche trotzdem bei **100 %** und „Ansicht wird neu geladen …“ stehen blieb.
• ### Änderung
• Nach erfolgreicher Nachprüfung wird jetzt ein **echter neuer Dokumentabruf** erzwungen.
• Dafür erhält die Reload-URL einmalig einen internen Cache-Buster (`_cwmon_refresh`), damit eine Navigation auf exakt dieselbe URL nicht als No-op behandelt werden kann.
• Der Cache-Buster wird nach dem Laden sofort per `history.replaceState()` wieder aus der sichtbaren URL entfernt.
• Zusätzlich existiert ein nativer `window.location.reload()`-Fallback.
• Falls eine globale Admin-/Browser-Navigation trotzdem blockiert wird, erscheint nach wenigen Sekunden ein klarer Button **„Ansicht jetzt neu laden“** statt einer scheinbar festhängenden 100-%-Anzeige.
• Die Update-Sperre wird unmittelbar vor dem Reload sauber aufgehoben, sodass der eigene `beforeunload`-Schutz die Navigation nicht verhindern kann.
• Das eigentliche Remote-Update und die Monitoring-Nachprüfung bleiben weiterhin getrennte Phasen.

Version 0.1.0-alpha17.4

## Fix: alter Browser-Dialog nach Update

• In alpha17.3 waren die nativen `window.confirm()`-Dialoge bereits durch das professionelle CW-Modal ersetzt. Der Browser konnte jedoch weiterhin die gecachte `assets/admin.js` aus alpha17.2 laden. Dadurch erschien auf bereits geöffneten Installationsseiten weiterhin der alte Browserdialog – sowohl bei Modulupdates als auch bei CW-Coreupdates.
• ### Änderung
• `assets/admin.js` und `assets/admin.css` werden mit einer Cache-Kennung aus dem SHA-256-Inhalt der jeweiligen Datei ausgeliefert.
• Ändert sich das Asset, ändert sich automatisch auch seine URL.
• Das gilt unabhängig davon, ob der Browser oder ein vorgeschalteter Cache die alte Datei noch gespeichert hat.
• Die Bestätigungen für Modul- und CW-Coreupdates laufen weiterhin ausschließlich über das CW-Modal aus alpha17.3.
• Ein manuelles Leeren des Browser-Caches ist nach Installation dieses Releases nicht erforderlich.

Version 0.1.0-alpha17.3

## Bestätigungen im CW-Stil

• Die nativen Browser-Dialoge (`window.confirm`) wurden vollständig aus der Monitoring-Oberfläche entfernt. Stattdessen gibt es ein zentrales, responsives CW-Bestätigungsmodal mit klarer Überschrift, Kontext, Sicherheitsdetail und eindeutigen Aktionen.
• ### Remote-Updates
• CW-Coreupdate: Installation und Versionsweg werden vor dem Start angezeigt.
• Alle CW-Coreupdates: Anzahl der sicheren Versionsschritte sowie Start-/Zielversion werden erklärt.
• Einzelne Modulupdates: Modul, Installation und Versionswechsel werden angezeigt.
• Alle Modulupdates: Anzahl der aktuell sicher updatefähigen Module wird genannt.
• Die in alpha17.2 eingeführte Einmal-Sperre bleibt bestehen; eine Bestätigung kann nicht versehentlich einen zweiten Job starten.
• ### Weitere Sicherheitsabfragen
• Auch Schlüssel neu erzeugen/überschreiben, vorbereiteten Schlüsselbund verwerfen, Remote-Schlüssel erzeugen, Installation entfernen, Reporting-Empfänger löschen und Cron-Schlüssel erneuern verwenden dasselbe Modal. Destruktive Aktionen sind optisch als kritisch gekennzeichnet.
• ### Bedienung / Barrierearmut
• `Abbrechen` erhält beim Öffnen den Fokus.
• Escape oder Klick auf den Hintergrund bricht ab.
• Tab bleibt im Dialog gefangen.
• Nach Schließen springt der Fokus auf das zuvor verwendete Element zurück.

Version 0.1.0-alpha17.1

## Remote-Update Abschlussanzeige

• Ein Remote-Update wird bei 100 % jetzt sofort als **erfolgreich abgeschlossen** gekennzeichnet.
• Die anschließende Monitoring-Nachprüfung ist ein eigener sichtbarer Schritt und verändert den bereits erreichten Update-Erfolg nicht mehr.
• Nach CW-Coreupdates wird die CW-Core-Karte sofort auf **„CW-Update installiert“** mit der tatsächlich vom Remote-Job gemeldeten Zielversion umgestellt.
• Modulupdates erhalten ebenfalls unmittelbar eine abgeschlossene Zwischenanzeige, bis der frische Monitoring-Status geladen ist.
• Die Status-Nachprüfung läuft mit Timeout. Bei einer langsamen oder kurzzeitig nicht erreichbaren Installation wird nach dem erfolgreichen Update trotzdem zuverlässig neu geladen.
• Der Browser-Verlassensschutz wird nur während eines tatsächlich laufenden Updates aktiviert und kann den automatischen Reload nach Erfolg nicht mehr blockieren.
• ## Kompatibilität
• Keine Änderung am Remote-Agent-Protokoll und keine neue Agent-API erforderlich.
• Keine Storage-Migration.
• Kein CW-Core-Update erforderlich.

Version 0.1.0-alpha17

## Neu

• Installationsdetails sind jetzt in **Übersicht, Statistik, Updates & Remote, Technik und Verlauf** getrennt.
• Die Statistikansicht nutzt die etablierte CW-Analytics-Darstellung mit ECharts, Range-Zoom, Datenreihen-Schaltern, Linien-/Balkenansicht und PNG-Export.
• Zeiträume: Heute, Gestern, letzte 2/7/30/60 Tage, diese/letzte Woche, dieser/letzter Monat sowie frei definierbar mit Datum und Uhrzeit.
• Intervallwahl: 5/15/30 Minuten, 1/3/6/12 Stunden oder 1 Tag; bei zu großen Ranges wird automatisch auf ein sicheres Intervall begrenzt.
• Länder und Städte werden passend zum gewählten Zeitraum neu aggregiert.
• ## Agent / Datenschutz
• Neue signierte Read-only-Route `/cw-monitoring/api/v1/traffic` und Capability `traffic-query-60d`; Range und Intervall sind Bestandteil der HMAC-signierten Request-Zeile.
• Agent-API: **1.6**.
• Detailabfragen sind auf die letzten 60 Tage begrenzt und werden lokal auf der Kundeninstallation aggregiert. Der zentrale Detailcache gilt fünf Minuten; ältere Query-Caches werden automatisch begrenzt/aufgeräumt.
• Es werden weiterhin keine IP-Adressen, Session-IDs, Visitor-IDs, User-Agents oder einzelnen Tracking-Ereignisse an die Zentrale übertragen.
• Die exakte Berechnung von eindeutigen/neuen/wiederkehrenden Besuchern erfolgt deshalb auf dem Agent und wird nicht durch fehlerhaftes Addieren von Tageswerten angenähert.
• ## Kompatibilität
• Normale Monitoring-Reports enthalten weiterhin den kompakten 30-/60-Tage-Cache aus alpha16.
• Ohne `traffic-query-60d` kann die Zentrale für 30/60 Tage auf diesen Cache zurückfallen.
• Kein CW-Core-Update erforderlich.

Version 0.1.0-alpha16

## Besucherstatistik in der Installations-Detailansicht

• Neue 30-/60-Tage-Statistik direkt auf der Detailseite jeder überwachten Installation.
• Kennzahlen: Zugriffe/Seitenaufrufe, Besuche, eindeutige Besucher, neue Besucher und wiederkehrende Besucher.
• Responsive Tagesgrafik für alle fünf Kennzahlen.
• Top-Länder und Top-Städte aus den vorhandenen lokalen CW-GeoIP-Daten.
• Die Daten werden zusammen mit dem normalen signierten Agent-Report geliefert; kein zusätzlicher Login und kein zusätzlicher externer Analytics-Dienst.
• Datenschutz: Der Agent überträgt ausschließlich aggregierte Werte. Keine IP-Adressen, Session-IDs, Visitor-IDs, User-Agents oder einzelnen Tracking-Ereignisse verlassen die Kundeninstallation.
• Neuer Agent-Schalter **Besucherstatistik übertragen**.
• Der zentrale Statistik-Cache liegt unter `project/storage/cw-monitoring/traffic/` und wird bei neuen Abrufen überschrieben statt in jedem historischen Snapshot dupliziert.
• Agent-API auf 1.5 erweitert; ältere Agenten bleiben für das übrige Monitoring kompatibel und zeigen lediglich noch keine Besucherstatistik.

Version 0.1.0-alpha15

## Alert & Reporting

• Neuer Backend-Menüpunkt **Alert & Reporting** in der Zentrale.
• Reporting-Empfänger sind einfache Name-/E-Mail-Profile und keine CW-Benutzer.
• Empfänger können für Urlaub oder andere Pausen deaktiviert werden, ohne Einstellungen zu verlieren.
• Neue Empfänger können auf Basis eines vorhandenen Profils angelegt werden. Kopiert werden Alert-Arten und Versandintervalle; Name, E-Mail und Aktivstatus bleiben eigenständig.
• Alert-Kriterien: kritisch, Warnungen, CW-/Modulupdates, Agent nicht erreichbar, Fehlerzähler, Mailfehler und Security-Hinweise.
• Alert-Frequenz: stündlich, täglich, wöchentlich oder monatlich.
• Statusreport: täglich, alle 3 Tage, wöchentlich oder monatlich.
• Responsive HTML-Mails mit eingebettetem CW-Mail-Logo und Text-Fallback.
• Versand über die vorhandene CW-Mailverwaltung / Outbox.
• Test-Alert und Test-Report je Empfänger.
• Integration in den bestehenden Monitoring-Cron; kein zusätzlicher Cronjob.
• Exklusiver Reporting-Lock verhindert doppelte Zustellungen bei überlappenden Cronläufen.
• Mailfehler werden technisch protokolliert und verfälschen nicht den Status des erfolgreich ausgeführten Monitoring-Crons.
• Persistenter Storage: `reporting.json` und `reporting-state.json`; beide werden vom Modulupdate gesichert.

Version 0.1.0-alpha14.4

## CSS-Hotfix für den neuen Schlüsselbund

• Auf der Seite **Installationen** wurde der neue Schlüsselbund durch die ältere `.cwmon-pairing`-Grid-Regel in drei schmale Außenspalten gezwungen. Dadurch standen Überschrift, Copy-Button, Schlüsselfelder und Website gegeneinander und wurden teilweise abgeschnitten.
• Alpha14.4 entkoppelt nur den neuen `.cwmon-bundle-highlight`-Block von diesem alten Layout. Der Schlüsselbund besitzt jetzt einen einspaltigen Außenaufbau; innerhalb davon bleiben Installations-ID, Agent-Schlüssel und Remote-Wartungsschlüssel auf ausreichend breiten Bildschirmen als saubere Dreiergruppe sichtbar und brechen responsiv um.
• *Keine Datenmigration und keine Änderung an vorhandenen Schlüsseln oder Kopplungen.**

Version 0.1.0-alpha14.3

## Schnelle Schlüsselbunde

• Die Zentrale kann neue Kundenkopplungen jetzt vorbereiten, bevor ein Host vollständig eingerichtet ist. Ein Klick erzeugt drei zusammengehörige Werte:
• 1. Installations-ID
• 2. Agent-Schlüssel für das read-only Monitoring
• 3. separater Remote-Wartungsschlüssel
• Alle drei Werte können einzeln oder als kompletter Schlüsselbund in die Zwischenablage kopiert werden. Vorbereitete Bunde bleiben in der Zentrale persistent und können später über ihre Installations-ID einem Client zugeordnet werden, ohne die Schlüssel neu zu erzeugen.
• Beim normalen Anlegen einer Installation wird der Remote-Wartungsschlüssel ebenfalls direkt mit erzeugt. Das ist nur eine Vorbereitung: Remote-Wartung, Modulupdates und CW-Coreupdates bleiben auf dem Child weiterhin standardmäßig deaktiviert und müssen dort ausdrücklich freigeschaltet werden.
• Nicht zugeordnete Bunde können in der Zentrale bewusst verworfen werden. Bereits zugeordnete Hosts werden durch diese Funktion niemals gelöscht oder entkoppelt.

Version 0.1.0-alpha14.2

## Neu

• Backend-Menüpunkt **Schlüssel** als zentrale Kopplungs- und Schlüsselverwaltung.
• Installations-ID, Agent-Schlüssel und Remote-Wartungsschlüssel sind für berechtigte Administratoren jederzeit kopierbar.
• Agent/Child zeigt die eigene Kopplung ebenfalls unter **Schlüssel**, damit eine Zentrale nach Neuaufbau rekonstruiert werden kann.
• Installationsdialog unterstützt **Vorhandene Kopplung übernehmen**.
• ## Wiederverwendung statt unnötiger Rotation
• Wird beim Anlegen eine bereits bekannte Installations-ID verwendet, übernimmt CW einen lokal noch gespeicherten Agent-Schlüssel automatisch. Nur ausdrücklich eingetragene manuelle Werte überschreiben vorhandene Schlüssel.
• ## Sicherheit
• Ein vollständig verlorenes Secret wird nicht über eine öffentliche Route ausgegeben. Eine frisch installierte Zentrale kann daher nur lokal noch vorhandene bzw. in lokalen CW-Modulbackups vorhandene Secrets automatisch wiederverwenden. Wenn die Zentrale keine Kopie mehr besitzt, kann der Schlüssel im angemeldeten Agent/Child unter **Schlüssel** kopiert und einmalig übernommen werden.
• ## Unverändert
• Monitoring und Remote-Wartung verwenden getrennte Schlüssel.
• Remote-Wartung bleibt standardmäßig deaktiviert.
• Bestehende Storage-Dateien und Kopplungen werden nicht gelöscht oder rotiert.

Version 0.1.0-alpha14.1

## Help-Routing Hotfix

• Öffentliche Hilfe funktioniert jetzt auch auf weiterhin unterstützten CW 3.0.0-beta11.14-Installationen.
• Ab CW mit zentraler Modulhilfe bleibt die Standardroute `/modules/help/cw-monitoring` aktiv.
• Auf älteren CW-Beta11-Ständen wird automatisch die kompatible Fallback-Route `/cw-monitoring/help` verwendet.
• Alle Kapitel- und Rollenlinks (Überblick, Zentrale, Child, Abläufe, Updates, Logs, Technik, Sicherheit, Fehlerhilfe) verwenden automatisch die jeweils gültige Route.
• Subdirectory-Installationen wie `/p/salman` werden durch `cw_base_path()` korrekt berücksichtigt.
• Bootstrap-Asset der öffentlichen Hilfe berücksichtigt ebenfalls den CW-Basispfad.
• Keine Änderungen an Monitoring-, Remote-, Schlüssel- oder Kundendaten.

Version 0.1.0-alpha14

## Hilfe & Technik

• neue Backend-Seite **Hilfe & Technik**
• öffentliche Dokumentation `/modules/help/cw-monitoring` nach Rollen und Themen getrennt
• Kapitel: Einleitung, Allgemein, Zentrale/Host, Agent/Child, Ablaufpläne, Remote-Updates, Cron/Protokolle, Architektur/Technik, Sicherheit/Datenschutz und Fehlerbilder/Internet
• visuelle Ablaufpläne für Kopplung, normalen Agent-Check, Cron und Remote-Updatekette
• Volltextsuche über Kapitel und Abschnitte, mobile Seitennavigation
• Praxis-Hinweis zur Netzwerkrealität: ein gespeicherter Child-Status wird der Zentrale erst nach erfolgreicher Folgeabfrage bekannt; mehrere Checks können bei Timeouts nötig sein, lokale Freigaben müssen dennoch nach einmaligem erfolgreichen Speichern persistent bleiben
• ## Sicherheit
• Die öffentliche Hilfe liest keine Hostlisten, Schlüssel, Logs oder Kundeninhalte. Sie enthält ausschließlich statische Dokumentation und wird `noindex,nofollow` ausgeliefert.

Version 0.1.0-alpha13

## Oberfläche

• Große Update-Statuskarten für CW-Core und Module.
• Klare Zustände: Up to date, Update verfügbar, Unbekannt.
• Modulzeilen mit Updatebedarf werden hervorgehoben.
• Release-Server-Diagnose bleibt vorhanden, ist standardmäßig eingeklappt.
• ## Härtung
• Exklusiver Remote-Update-Lock verhindert parallele schreibende Wartungsjobs.
• Stale-Job-/Lock-Erkennung.
• Größenlimit für Remote-JSON-Antworten.
• Schreibende Remote-Wartung verlangt HTTPS.
• Präzisere Fehlertexte und zugänglichere Fortschrittsanzeige.
• ## Sicherheitsgrenzen unverändert
• Keine beliebigen URLs, Dateipfade, PHP-/Shell-Kommandos, Fullsource- oder System-Reparaturpakete.

Version 0.1.0-alpha12.1

## Fix: zentraler Remote-Wartungsschlüssel bleibt bei Updates erhalten

• Eigener geschützter Zentralspeicher: `project/storage/cw-monitoring/central-remote-pairing.json`
• Legacy-Spiegel in `secrets.json` für Rollback-Kompatibilität
• Automatische Migration vorhandener `remote_sites`
• Automatische Recovery aus der letzten CW-Modul-Rollback-Sicherung, falls ein älterer Monitoring-Stand den zentralen Schlüssel verloren hat
• Beim Löschen einer Installation werden beide Remote-Key-Speicher bereinigt
• Die Agent-seitige Kopplung unter `remote-pairing.json` bleibt unverändert.

Version 0.1.0-alpha12

## Remote CW-Coreupdates

• separate Agent-Freigabe `Remote-CW-Coreupdates erlauben`
• neuer Remote-Preflight für Module und CW-Core
• `Nächstes CW-Update` installiert genau einen sicheren Core-Schritt
• `Alle CW-Updates ausführen` arbeitet die komplette vom lokalen CW-Release-Server angebotene Updatekette ab
• ausschließlich reguläre `update`-Pakete; kein Fullsource und keine System-Reparatur remote
• Download, SHA-256, Rollback-Sicherung, Wartungsmodus, Dateiinstallation und Rollback bleiben Aufgabe des vorhandenen CW-System-Updaters
• jeder weitere Core-Schritt startet in einem frischen HTTP-/PHP-Prozess, damit aktualisierter Updater-Code geladen ist
• Jobdateien bleiben unter `project/storage/cw-monitoring/remote-jobs` und überleben Core-/Modulupdates
• Fortschrittsanzeige toleriert den kurzzeitigen Wartungsmodus während eines Core-Updates
• Wartungskopplung bleibt updatefest in `project/storage/cw-monitoring/remote-pairing.json`
• ## Sicherheitsgrenze
• Die Zentrale darf weiterhin keine Download-URL, Paket-ID, Datei, PHP-Code oder Shell-Befehl vorgeben. Der Agent löst die Updatekette selbst über seine lokale CW-Konfiguration auf und akzeptiert nur den Kanal `stable`, `preview` oder `all`. Bei einem Fehler wird die Kette sofort gestoppt.

Version 0.1.0-alpha11.2

• Remote-Kopplung wird zusätzlich in `project/storage/cw-monitoring/remote-pairing.json` dauerhaft gespeichert.
• Bestehende Alpha11/11.1-Schlüssel und Freigaben werden automatisch migriert; ein normales Modulupdate darf Remote-Schlüssel/Freigaben nicht mehr zurücksetzen.
• Kritische Monitoring-Konfiguration wird beim Modulupdate gezielt gesichert statt den kompletten Runtime-Storage zu kopieren.
• Remote-Route verwendet den bekannten CW-WAF-Scope `analytics`, damit POST auch auf älteren Beta11-Installationen kompatibel behandelt wird.
• Agent meldet getrennt: Schlüssel vorhanden, Remote-Freigabe, Modulupdate-Freigabe, persistente Kopplung und API-Version.
• Host-Detailseite zeigt die exakte Ursache, wenn Remote-Wartung nicht bereit ist.
• Neuer Button „Remote-Verbindung testen“ führt einen signierten Preflight ohne Update aus.

Version 0.1.0-alpha11.1

## Remote-Update Hotfix + Fortschritt

• Wartungsroute verwendet jetzt einen eigenen WAF-Scope, der signierte POST-Anfragen erlaubt.
• Behebt HTTP 405 / „Das Formular wurde mit einer nicht zulässigen Anfrageart aufgerufen.“ beim Remote-Update.
• Remote-Modulupdates laufen als Job und blockieren die Host-Detailseite nicht mehr.
• Live-Fortschritt mit Prozentbalken, aktuellem Schritt und kurzem Job-Log.
• Der vorhandene CW-Modul-Updater liefert seine echten Fortschrittsstufen (Download, Prüfung, Backup, Austausch, Migration, Integrität) an das Monitoring weiter.
• „Alle Modulupdates“ aggregiert die einzelnen Modulfortschritte zu einem Gesamtlauf.
• Nach erfolgreichem Update liest die Zentrale den Host automatisch neu ein und aktualisiert die Detailseite.
• Remote-Job-Dateien liegen unter `project/storage/cw-monitoring/remote-jobs` und überleben auch ein Selbstupdate von CW Monitoring.
• Keine beliebigen URLs, Pfade, PHP- oder Shell-Befehle werden akzeptiert.
• Für die neue Job-API muss Alpha11.1 auf Zentrale **und** Agent/Child installiert sein.

Version 0.1.0-alpha11

## Remote-Update Foundation

• Separater HMAC-Schlüssel für Remote-Wartung; Monitoring-Schlüssel bleibt read-only.
• Remote-Wartung ist auf Agenten standardmäßig deaktiviert.
• Alpha11 erlaubt ausschließlich kontrollierte Modulupdates aus dem lokal konfigurierten CW-Modul-Releaser.
• Einzelnes Modul oder alle sicher direkt updatefähigen Module aktualisieren.
• Vor jedem Update: Katalogprüfung, Versions-/PHP-/CW-Prüfung, bestehende CW-Backup-/Rollback-Logik, SHA-256-Prüfung.
• Die Zentrale übermittelt weder Download-URLs noch PHP-Code oder Dateipfade.
• CW-Core-Remoteupdates sind in Alpha11 bewusst noch gesperrt. Nach erfolgreichem Dummy-Modul-Test folgt der Core in einem nächsten Release.

Version 0.1.0-alpha10.4

## Update-Kanal konfigurierbar

• Die Monitoring-Zentrale kann jetzt explizit zwischen `all`, `preview` und `stable` waehlen.
• Da CW aktuell noch Alpha/Beta ist, ist `all` der Default fuer neue Installationen. Alte Monitoring-Installationen mit dem bisherigen, nicht explizit markierten Default `stable` werden beim Laden auf `all` angehoben. Sobald der Benutzer einen Kanal in den Monitoring-Einstellungen speichert, bleibt diese Auswahl unveraendert.
• Die Auswahl steuert sowohl die CW-Core- als auch die Modul-Updatepruefung.

Version 0.1.0-alpha10.3

• Core-Release-Prüfung transparenter gemacht.
• Erzwungene Prüfungen fallen bei HTTP/API-Fehlern nicht mehr still auf einen alten Cache zurück.
• Host-Detailseite zeigt Release-Server-Diagnose mit HTTP-Status, Kanal, latest_version, available_count, Update-Anzahl und Antwortfeldern.
• Keine Änderungen an Agent-API oder Kopplung; Client-Update ist für diese Diagnose nicht erforderlich.

Version 0.1.0-alpha10.2

## Core-Update-Erkennung

• Die zentrale CW-Prüfung verwendet jetzt dieselbe Release-API-Semantik wie der originale CW-Core-Updater.
• Neuere publizierte CW-Versionen werden zuverlässig erkannt.
• `update_available` wird nicht mehr fälschlich als alleinige Aussage über den neuesten veröffentlichten Core-Stand interpretiert.
• Eine Installation kann damit als „CW-Update vorhanden“ markiert werden, auch wenn für ihren alten Stand aktuell kein direkter Update-Pfad veröffentlicht ist.
• Die Installierbarkeit bleibt separat sichtbar und kann später von der Remote-Wartung genutzt werden.
• Die PHP-Version der überwachten Installation wird bei der Release-Abfrage mitgesendet.
• Keine gespeicherten Hosts, Kopplungsschlüssel, Cron-Schlüssel oder Protokolle werden verändert.

Version 0.1.0-alpha10.1

## Core-Release-Abgleich

• Manuelle Einzelpruefung fragt den CW-Core-Release sofort frisch ab.
• „Alle pruefen“ und Cronlaeufe verwerfen den alten Core-Cache vor dem Lauf.
• Der 15-Minuten-Cache bleibt nur fuer normale Seitenaufrufe bestehen.
• Robustere Ermittlung der neuesten CW-Version aus dem Release-API-Payload.
• Damit wird ein gerade auf den CW Release Server hochgeladenes Core-Release beim naechsten bewussten Check sofort erkannt.

Version 0.1.0-alpha10

## Cronanzeige verständlicher

• Technischer Cronstatus und Ergebnis der überwachten Hosts sind getrennt.
• Ein technisch sauber durchgelaufener Cron wird immer als **Erfolgreich** geführt.
• Host-Warnungen und kritische Zustände erscheinen separat als Monitoring-Ergebnis.
• Die Ursache wird im Cronlog konkret genannt; ein leerer Grund wird durch eine sichere Fallback-Diagnose ersetzt.
• Direkter Link vom Cronlauf auf alle Host-Checks mit derselben Lauf-ID.
• HTTP-Cron-Antwort nennt die Ursache ebenfalls.
• ## Weniger Fehlalarme
• Die Kompatibilität eines Agents wird über die Agent-API-Version bewertet, nicht über jede Alpha-Version des Moduls.
• Reine UI-/Zentralen-Updates führen dadurch nicht mehr automatisch zu einer Warnung für alle noch nicht aktualisierten Agents.

Version 0.1.0-alpha9

## Neu

• Cronprotokoll zeigt konkrete Ursachen für Warnungen/kritische Hosts.
• Prüfverlauf speichert einen kompakten Ursachentext je Check.
• Security-/WAF-Bewertung unterscheidet normale abgewehrte Ereignisse von echten technischen Problemen.
• Ein einzelner geblockter Request erzeugt nicht mehr automatisch eine Warnung.
• Schwellenwerte: Warnung ab 100 Security-Ereignissen/24h oder einem technischen Problem; kritisch ab 500 Ereignissen/24h oder 10 technischen Problemen.
• Agent-API 1.2 ergänzt `problems_24h` und die verwendeten Security-Schwellenwerte.
• ## Datenschutz
• Weiterhin werden keine Besucher-IP-Adressen, vollständigen WAF-/Security-Logs, Mailinhalte, Formulardaten oder Secrets an die Zentrale übertragen.
• ## Kompatibilität
• Bestehende Installationen, Kopplungen, Agent-Schlüssel, Cron-Schlüssel, Snapshots und Protokolle bleiben erhalten. Alte Cron-Einträge besitzen naturgemäß noch keine Ursachen-Spalte; neue Läufe füllen sie automatisch.

Version 0.1.0-alpha8

## Protokolle: Zeitraum, Filter und Seitennavigation

• Alpha 8 begrenzt die Logdarstellung standardmäßig auf die letzten 24 Stunden und ergänzt eine echte Seitennavigation. Dadurch bleibt das Backend auch nach vielen Cronläufen übersichtlich.
• ### Neu
• Standardzeitraum: letzte 24 Stunden
• Zeitraum frei von/bis filterbar
• Schnellwahl für 24 Stunden, 7 Tage und 30 Tage
• Pagination mit 25, 50 oder 100 Einträgen pro Seite
• Filter nach Installation, Status/Schweregrad und Auslöser
• HTTP-Statusfilter für Prüfverlauf und Technik/API
• Volltextsuche nach Name, URL, Lauf-ID, Code und Meldung
• Trefferzahl und Zeitraum werden sichtbar angezeigt
• ### Skalierung
• Die JSONL-Dateien werden für die Anzeige nicht mehr vollständig mit `file()` geladen. CW liest sie blockweise rückwärts. Bei einem Von-Zeitpunkt wird die Verarbeitung beendet, sobald ältere Einträge erreicht werden. Damit steigt der Speicherbedarf der Anzeige nicht proportional zur gesamten Logdateigröße.
• ### Bestandsschutz
• Keine Migration erforderlich. Bestehende Installationen, Agent-Schlüssel, Cron-Schlüssel, Snapshots und Logs bleiben erhalten.

Version 0.1.0-alpha7

## Hosting-Cron

• Neuer geschützter HTTP(S)-Cron-Endpunkt für Hosting-Panels, die Cronjobs per URL ausführen.
• Automatisch erzeugter 256-Bit-Cron-Schlüssel, getrennt von Agent-Schlüsseln.
• Vollständige Cron-URL in den Einstellungen sichtbar.
• Separate Schlüsselrotation mit ausdrücklicher Bestätigung.
• HTTP 200 bei technisch erfolgreichem Monitoring-Lauf; Warnungen oder kritische Kundenhosts machen den Cron selbst nicht künstlich fehlerhaft.
• HTTP 500 nur bei technischem Fehler des Cronlaufs.
• CLI-Cron bleibt weiterhin verfügbar.
• ## ALL-INKL
• Empfohlen: HTTPS, komplette Cron-URL aus CW Monitoring eintragen, Beschreibung `CW Monitoring`, Ausführungsintervall alle 15 Minuten, HTTP-Benutzer/Passwort leer lassen.

Version 0.1.0-alpha6

## Änderungen

• Kopfbereich im Backend auf eine helle, kontraststabile Darstellung umgestellt. Titel, Modus, Version und Dokumentationsbutton bleiben damit auch bei abweichenden CW-Themes lesbar.
• Zentrale kann vorhandene Kopplungsdaten einer Installation erneut anzeigen, ohne den Agent-Schlüssel zu ändern.
• In der Installationsliste gibt es dafür die Aktion **Kopplung**.
• In der Detailansicht gibt es **Kopplungsdaten anzeigen** getrennt von **Schlüssel neu erzeugen**.
• Neu angelegte Hosts erhalten weiterhin automatisch eine eigene Installations-ID und einen eigenen 256-Bit-Agent-Schlüssel.
• Öffentliche Modulhilfe aktualisiert.
• ## Sicherheit
• Das erneute Anzeigen ist nur im authentifizierten CW-Backend mit `module.cw-monitoring.manage` möglich. Die öffentliche Hilfe und Agent-API geben keine Schlüssel aus.

Version 0.1.0-alpha5

## Fix

• Das Backend-Layout von CW Monitoring wurde nach 0.1.0-alpha4 nicht geladen. Ursache war kein Fehler der neuen Protokollansichten, sondern die URL des Modul-Stylesheets.
• `cw_module_asset_url()` liefert bereits eine CW-Asset-URL mit Query-Parametern. Alpha4 hängte zusätzlich `?v=<version>` an diese URL. Dadurch wurde der Modulpfad als `assets/admin.css?v=...` interpretiert und das Stylesheet nicht ausgeliefert.
• Alpha5 verwendet wieder die von CW vorgesehene Asset-URL unverändert. Dashboard, Installationen, Protokolle und Einstellungen erhalten dadurch wieder das vollständige CW-Monitoring-Layout.
• ## Daten / Kompatibilität
• keine Migration
• bestehende Hosts bleiben erhalten
• Agent-Schlüssel bleiben erhalten
• vorhandene Prüf-, Cron-, Ereignis- und Technikprotokolle bleiben erhalten
• öffentliche Hilfe `/modules/help/cw-monitoring` bleibt unverändert verfügbar

Version 0.1.0-alpha4

## Schwerpunkt

• Alpha 4 ergänzt das Monitoring um ein eigenständiges, datensparsames Protokollsystem. Damit ist nachvollziehbar, wann welcher Host geprüft wurde, ob der Cron tatsächlich lief und welche Zustandsänderungen zwischen zwei Prüfungen aufgetreten sind.
• ## Neu
• eigener Menüpunkt **Protokolle**
• vier getrennte Ansichten:
• Prüfverlauf
• Cronläufe
• Ereignisse
• Technik / API
• jeder einzelne Host-Check protokolliert:
• Zeitpunkt
• Installation
• Auslöser manuell / Cron
• Gesamtstatus
• Agent-Verbindungsstatus
• HTTP-Status
• Antwortzeit
• CW-Version
• Core-/Modulupdate-Status
• aggregierte Fehler-, Mail- und Security-Zähler
• Cronlauf erhält eigene Lauf-ID
• Cronlog speichert Start, Ende, Laufzeit, Anzahl geprüfter Hosts sowie OK-/Warn-/Kritisch-Zähler
• Ereignislog schreibt nur echte Zustandsänderungen und nicht jede unveränderte Prüfung
• Ereignisse für Agent-Ausfall/Wiederherstellung, Core-/Modulupdates sowie Health-Statusänderungen
• Technik/API-Log für Timeout, fehlende Agent-Route, Kopplungsfehler, Protokollfehler und ungültige Antworten
• Dashboard zeigt Anzahl der heutigen Prüfungen und den letzten Cronlauf
• Host-Detailseite verlinkt direkt auf alle Protokolle dieser Installation
• Protokolle nach Installation filterbar
• 50 / 100 / 250 / 500 Einträge auswählbar
• Aufbewahrung getrennt konfigurierbar:
• Prüfverlauf standardmäßig 90 Tage
• Cronläufe 180 Tage
• Ereignisse 180 Tage
• Technik/API 90 Tage
• automatische Log-Bereinigung mit Obergrenzen
• öffentliche Dokumentation `/modules/help/cw-monitoring` aktualisiert
• ## Datenschutz
• Die Protokolle enthalten ausschließlich technische Statusdaten der Monitoring-Zentrale. Es werden keine vollständigen Agent-Payloads, IP-Adressen, Mail-/Formularinhalte oder Secrets gespeichert. Technische Fehlermeldungen werden gekürzt und typische Token-/Secret-Muster redigiert.
• ## Weiterhin nicht enthalten
• E-Mail-Benachrichtigungen
• WhatsApp/Messenger-Provider
• Remote-Updates oder Fernsteuerung
• Selbstüberwachung der Zentrale
• Die Zentrale überwacht weiterhin ausschließlich externe CW-Hosts.

Version 0.1.0-alpha3

## Schwerpunkt

• Alpha 3 macht aus dem Grundgerüst einen praktisch testbaren Monitoring-Datenfluss zwischen einer CW-Zentrale und externen CW-Agenten.
• ## Neu
• bestätigbarer Kopplungsstatus je Host statt nur „HTTP erreichbar“
• Unterscheidung zwischen offline, Agent-Route fehlt, Agent nicht gekoppelt, Signaturfehler, falsche Installations-ID und ungültiger Agent-Antwort
• Agent-Version und API-Version werden an die Zentrale gemeldet
• Warnung, wenn der Monitoring-Agent auf dem Kundenhost älter als die Zentrale ist
• „Letzter erfolgreicher Kontakt“ getrennt vom letzten Prüflauf
• problematische Hosts werden im Dashboard zuerst angezeigt
• neue Dashboard-KPIs für Updates, Warnungen und nicht erreichbare Agenten
• detailliertere Host-Detailansicht mit Agent-, System-, Health- und Updateinformationen
• Health-Reporting um Speicherstatus und PHP-Systemstatus erweitert
• PHP-Version, SAPI, Zeitzone, memory_limit und technische Extensions im Systembericht
• freier Speicherplatz und Schreibbarkeit von `project/storage`
• Mailstatus enthält zusätzlich aggregierte erfolgreiche Mailaktivität, ohne Empfänger/Betreff/Inhalt
• Modulübersicht zeigt Aktivstatus, installierte und verfügbare Version
• Verlauf zeigt Agent-Kopplungsstatus und Fehlerzähler
• Release-API-Auswertung robuster gegen verschachtelte JSON-Strukturen
• öffentliche Modulhilfe `/modules/help/cw-monitoring` auf Alpha 3 aktualisiert
• ## Datenschutz
• Weiterhin werden keine Formularinhalte, Mailinhalte, Mail-Empfänger, Besucher-IP-Adressen, Sessions, Passwörter oder vollständigen Logs übertragen. Die Zentrale erhält technische Versionen, Statuswerte, aggregierte Zähler und Zeitpunkte.
• ## Noch nicht enthalten
• E-Mail-Benachrichtigungen
• WhatsApp/Messenger-Provider
• Remote-Updates oder Fernsteuerung
• Selbstüberwachung der Zentrale
• Die Zentrale verwaltet bewusst ausschließlich externe CW-Hosts.

Version 0.1.0-alpha2

## Installationsfix

• Backend-Menü-Zuordnung korrigiert: `system / diagnostics`.
• Der vorherige Slot `system / monitoring` ist in der aktuellen CW Backend Menu Foundation nicht zulässig.
• Admin-Kategorie auf `analytics` normalisiert.
• Funktionsumfang aus Alpha 1 unverändert: Zentrale, Agent/Child, Dashboard, Installationsdetail, signierte Read-only-API, Cron und öffentliche Doku-Route `/modules/help/cw-monitoring`.
• Alpha 1 konnte durch die ungültige Menü-Slot-Deklaration bereits bei der Manifestprüfung abgewiesen werden. Alpha 2 ersetzt Alpha 1 vollständig.

Version 0.1.0-alpha1

Erster technischer Alpha-Release.

• ## Enthalten
• Betriebsart **Zentrale** oder **Agent / Child**
• Installationen mit eigener ID und eigenem 256-Bit-Schlüssel
• HMAC-SHA256-signierte Agent-Abfragen
• Timestamp-/Nonce-Replay-Schutz
• zentrales Dashboard mit:
• URL / Projekt
• Erreichbarkeit
• CW-Version
• Core-Update
• Modul-Updates
• Fehlerhinweise
• Mailstatus
• Security-Status
• PHP-Version
• Antwortzeit
• letzter Prüflauf
• klickbare Detailansicht je Installation
• Modulübersicht mit Updatevergleich
• begrenzte Prüfhistorie
• manueller Einzel- und Sammelabruf
• CLI-Cron für automatischen Sammelabruf
• öffentliche Dokumentationsroute `/modules/help/cw-monitoring`
• Datenschutzmodus ohne Übertragung von Mail-/Formularinhalten, IP-Adressen oder vollständigen Logs
• ## Noch nicht enthalten
• E-Mail-/Messenger-Benachrichtigungen
• Remote-Updates oder sonstige Fernsteuerung
• dauerhafte Incident-/Ticketverwaltung