Czym jest render probe i dlaczego monitoring HTTP to za mało
Standardowy monitoring HTTP sprawdza, czy serwer odpowiada kodem 200 i czy w treści strony znajduje się oczekiwana fraza. To wystarcza do wykrycia całkowitej awarii serwera, ale nie powie Ci, że strona rozjechała się wizualnie po aktualizacji CSS, że zewnętrzny widget zepsuł layout, albo że Cloudflare/LiteSpeed wyświetla ścianę bota zamiast właściwej treści.
Render probe — znany też jako visual regression testing — idzie o krok dalej. Uruchamia prawdziwą przeglądarkę (Chromium przez Puppeteer/Browsershot), renderuje stronę i zapisuje snapshot stylów CSS (getComputedStyle) dla kluczowych elementów. Kolejne uruchomienia porównują nowy snapshot z zapisaną linią bazową — każde odchylenie oznacza potencjalny problem wizualny.
W Cyberapis v0.5.0 wprowadzamy właśnie tę warstwę weryfikacji. Dodatkowo system zyskuje mechanizm external confirmation — drugi, niezależny punkt obserwacyjny (GitHub Actions), który potwierdza awarię zanim wyślemy alert. Po co? Bo pojedynczy fałszywy alarm o 3 w nocy potrafi zniszczyć zaufanie do całego systemu monitoringu.
Nowe funkcjonalności
Render probe — wykrywanie regresji wizualnych
System uruchamia Chromium przez Browsershot, renderuje stronę i zapisuje snapshot getComputedStyle dla kluczowych elementów jako linię bazową. Każdy kolejny probe porównuje wynik z baseline — różnice wykraczające poza próg tolerancji generują alert. Snapshot obejmuje rozszerzone właściwości CSS: fontSize, lineHeight, marginTop, paddingTop, maxWidth oraz fallbacki selektorów dla popularnych układów CMS.
External confirmation przez GitHub Actions
Drugi punkt obserwacyjny, który potwierdza awarię zanim system wyśle powiadomienie. Aplikacja dispatchuje workflow GitHub Actions do sondowania URL z zewnętrznej infrastruktury. Alert e-mail wysyłany jest dopiero po potwierdzeniu awarii przez zewnętrzną sondę. Token autoryzacyjny przepływa przez GitHub Secrets, nie przez workflow_dispatch inputs.
Alert debouncing — ochrona przed fałszywymi alarmami
Konfigurowalny próg MONITORING_ALERT_CONSECUTIVE_FAILURES (domyślnie 2) — alert HTTP wysyłany jest dopiero po N kolejnych niepowodzeniach. Wartość 1 przywraca natychmiastowe alarmowanie.
Pause/Resume dla monitoringu
Każdy monitoring można wstrzymać (is_paused) — scheduler i ręczne wywołania pomijają go, a alerty nie są wysyłane. Panel Filament pokazuje ikony play/pause, a filtr trójstanowy pozwala wyświetlić tylko aktywne, tylko wstrzymane lub wszystkie.
Monitoring HTML sanity check
Po pomyślnym sprawdzeniu HTTP i dopasowaniu frazy system skanuje HTML strony w poszukiwaniu wzorców stron błędów (MonitoringHtmlSanityChecker). Wynik zapisywany w kolumnie monitoring_results.sanity_ok.
Naprawione błędy
Render probe cache bypass
Każdy probe używa świeżego katalogu profilu Chromium, parametru ?cyberapis_probe= jako cache bustera, nagłówka Cache-Control: no-cache i flagi --disable-http-cache. Eliminuje to ryzyko porównywania z cache'owaną wersją strony.
Browsershot na produkcji po config:cache
Wszystkie ustawienia BROWSERSHOT_* przeniesione do config/monitoring.php (klucz browsershot.*). Kod używa config() zamiast env(), więc ścieżka do Chrome nie ginie po deployu z config:cache.
Frontend monitoring list — wyciek danych
Zalogowani użytkownicy na stronie głównej i /monitorings widzieli wszystkie rekordy w bazie. Teraz widzą tylko własne monitorowanie (user_id), tak samo jak w panelu Filament.
Hasła użytkowników — podwójne hashowanie
Formularz Filament używał dehydrateStateUsing + Hash::make w page handlerze, co dawało podwójny hash. Hasło trafia teraz do casta hashed na modelu User bez dodatkowego hashowania.
External confirmation — bezpieczeństwo
Callback token nie przechodzi już przez workflow_dispatch inputs GitHub (widoczne w logach). Workflow czyta secrets.MONITORING_EXTERNAL_CONFIRM_CALLBACK_TOKEN — tę samą wartość co .env aplikacji.
Zmiany i ulepszenia
Monitoring failure email — więcej kontekstu
Z szablonu alertu usunięto długą uwagę o HTML sanity vs CSS/layout. Dodano zwięzły wiersz "style templates / render" pokazujący status ostatniego render probe (disabled / no data / OK / error + opcjonalne podsumowanie niezgodności).
Cron script z flock
cron-script.sh uruchamia monitor:check-websites pod flock -n, co zapobiega nakładaniu się równoległych wywołań schedulera.