Uptime

W ramach side questa potrzebowałem monitoringu dostępności stron WWW, z API i dość dużą liczbą monitorowanych serwisów. Powiedzmy od 100 w górę. I najchętniej za darmo, bo potrzebuję tylko do PoCa. I fajnie, jakby umiał monitorować nieco częściej, niż raz na 5 minut.

Zdziwiłem się, bo okazało się, że… nie ma. A przynajmniej nie znalazłem. Oczywiście jest Uptime Robot, którego – jak się okazało – używam od ponad dekady. Z własnym narzędziem do wyświetlania dashboardu. No ale tam mam sporo slotów zużytych z 50, które może od biedy by wystarczyły.

Jestem zdziwiony, bo tego typu monitoring jest w miarę tani. Bo czymże jest request HTTP czy wysłanie pakietu ICMP raz na minutę i zapamiętanie stanu. A dla wysyłki poczty (SMTP relay) serwisów pozwalających nawet niewielkie newslettery jest całkiem spory wybór. I wygląda na nieco bardziej inwazyjne, potencjalnie (spam). No ale nie ma i co zrobisz, trzeba selfhostować. Za to będzie pełna dowolność w interwałach sprawdzania dostępności.

Szybko odpędziłem myśl o napisaniu własnego rozwiązania, bo tak, plik YAML z definicjami serwisów, prosty skrypt w Pythonie z wykorzystaniem biblioteki requsets, napędzany cronem spokojnie by wystarczył do tego, co chcę osiągnąć. Postanowiłem rozejrzeć się za gotowcami.

No i znalazłem coś, co mnie nawet zachwyciło. Nazywa się Uptime Kuma, daje API, daje ładny frontend, sensowną dokumentację w zakresie uruchomienia, obsługuje wiele kanałów powiadomień. Od początku ujęło mnie tym, że potrafi korzystać zarówno z bazy sqlite, jak i MySQL, więc przy małych zastosowaniach można sobie trzymać bazę w pliku, bez kolejnego serwera.

Oczywiście są wady. Po pierwsze nie przepadam za technologią, w której jest stworzone rozwiązanie. Po drugie, dedykowana biblioteka Pythona do obsługi API nie działa poprawnie. W sumie przez to straciłem więcej czasu, niż na uruchomienie monitorigu + reverse proxy w oparciu o nginx. Skończyło się tym, że nie korzystam z dedykowanej biblioteki, tylko robię requesty na żywca.

Gdyby ktoś chciał sobie porobić wykresy albo monitorować usługi – polecam sprawdzenie Uptime Kuma. 90k gwiazdek na GitHub nie jest przypadkiem.

FireHOL mirror is dead, long live FireHOL mirror!

Jakiś czas temu pisałem, że repozytorium projektu na GitHubie jest nieaktualizowane. Można było się przełączyć na pobieranie danych ze strony projektu FireHOL, ale przy niektórych zastosowaniach jest to mniej wygodne.

W komentarzach do zgłoszonego issue pojawił się link na nowy, lepszy mirror list FireHOL. Jest to stosunkowo świeże i robione przez niezależną od projektu osobę, ale LGTM i mam nadzieję, że będzie działać.

Czemu lepszy mirror? Ano dlatego, że jest parę ulepszeń, albo nawet i poprawek w stosunku do oryginału. Po pierwsze, usunięte są adresy prywatne. Usunięte są także stare blocklisty. I na koniec usunięte zostały niespójności pomiędzy plikami z sieciami i plikami z IP.

WordPress i kłopoty z cache – rozwiązanie

Od pewnego czasu na blogu występuje problem. Objawia się on tym, że niektóre wpisy nie wyświetlają się w całości, są jakby obcięte. Zauważyłem to parę dni temu, ale wtedy uznałem za jednorazowy wybryk i machnąłem ręką. Po części zwaliłem sprawę na cache, bo jego wyczyszczenie pomogło. Po głowie jako przyczyna chodziło mi też coś w stylu DDoS, który po publikacji artykułu na blogu uprawiają serwery Mastodon. I zupełnie nie miałem czasu na analizę.

Jednak dotarły do mnie sygnały (dzięki!) o tym, że sprawa się powtarza, postanowiłem przyjrzeć się bliżej. Dziś wszedłem z telefonu na ten sam wpis i… problem wystąpił ponownie. Z racji pory dnia ruch powinien być niewielki, więc warunki do diagnostyki powinny sprzyjać.

Trzy słowa o setupie

Blog jest dumnie wspierany przez WordPress, wykorzystywany jest nginx oraz php-fpm 8.2. Do tego dość intensywnie korzystam z wtyczek do WordPress. W szczególności do różnych optymalizacji i cache, co raczej nie ułatwi diagnostyki. Dużo elementów ruchomych, ingerencja w treść serwowanej występuje w wielu miejscach.

Wspomniałem o pluginie do cache jako jednym z podejrzanych. Konfiguracja Cache Enabler wygląda następująco:

Konfiguracja Cache Enabler
Screenshot konfiguracii Cache Enabler

Objawy i logi

Obcięty wpis wygląda tak:

Ucięty wpis na blogu
Screenshot uciętego wpisu

Cache był wygenerowany o 07:48 i pokrywa się to z czasem wejścia z telefonu widocznym w access.log.

drwxr-xr-x 2 www-data www-data 4096 Sep 24 07:48 pentagram-cerberus-p6361-rzut-okiem-na-bezpieczenstwo

W logu php-fpm nic specjalnego. Chwilę wcześniej widać raczej nie mogące mieć wpływu

[24-Sep-2023 07:44:23] WARNING: [pool www] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 8 children, there are 1 idle, and 10 total children
[24-Sep-2023 07:44:27] WARNING: [pool www] child 20688 exited on signal 9 (SIGKILL) after 33847.200506 seconds from start
[24-Sep-2023 07:44:27] NOTICE: [pool www] child 25769 started

Diagnostyka

Problem występował na różnych przeglądarkach, także w trybie prywatnym. Zarówno na desktopie, jak i mobile. Sprawdzenie wersji zapisanej w cache pokazało, że jest ona błędna. Dobry znak, bo raczej można wykluczyć wpływ JSów. Były one podejrzane, bo wprawne oko dostrzeże, że polecenie curl przechodzi w pewnym momencie w kod źródłowy strony związany ze skryptem od statystyk Matomo.

Udało mi się ustalić, że wyczyszczenie cache pomaga, ale… tylko na pierwsze wyświetlenie. Kolejne wyświetlenia są już błędne. Sam problem występował niezależnie od obsługi JS. Czy to Firefox, czy links2, czy lynx – pierwsze wyświetlenie było poprawne, kolejne błędne.

Na pierwszy ogień poszły więc ustawienia wtyczki robiącej cache. W Minify HTML in cached pages including inline CSS and JavaScript wyłączyłem miniaturyzację CSS i JS. Nie pomogło.

Natomiast zupełne wyłączenie tej opcji jak najbardziej pomogło. Winnym okazała się zatem jedna z opcji wtyczki Cache Enabler w wersji 1.8.13. Takie tam ryzyka optymalizacji. Zgłosiłem problem na GitHub i zobaczymy co będzie dalej.

Rzuciłem jeszcze okiem na przyczynę. Prawdopodobnie chodzi o niepoprawne, zachłanne parsowanie komentarzy. Obcięcie następuje po pierwszym znaku *.
Gecko/20100101 Firefox/60.0' -H $'Accept: */*' -H $'Accept-Language: en-US,en;q=0.5'
natomiast linia bezpośrednio przed tym, co się zaczyna pojawiać, wygląda tak:
/* tracker methods like "setCustomDimension" should be called before "trackPageView" */