Doprowadziłem PUMa do takiej postaci, że daje się używać i generuje w miarę strawny i używalny HTML. Przykładowy wynik działania. Oczywiście wszystko jest na GitHubie, który mnie drażni ostatnio, bo pisze (w związku z zupełnie innym projektem, notka leży w szkicach, których coraz więcej, upał taki, że nawet pisać się nie chce), że Can’t automatically merge. Don’t worry, you can still create the pull request. No niby mogę, ale autor upstreamu umiarkowanie nalega na wyprostowanie (się nie dziwię), a ja szczerze mówiąc nie widzę, co mu przeszkadza w automatycznym merge. Pewnie jakbym wiedział, to łatwiej byłoby mi pomóc gitowi ogarnąć się… W każdym razie będę doszkalał się z gita.
Wynikami nie ma się co sugerować zbytnio – sporo hostów zostało dodanych bardzo niedawno, stąd 100%. Jest też rozbieżność pomiędzy wynikami dla All time i jednego roku. Nie bug w skrypcie, tylko tak zwraca dane polecany niedawno Uptime Robot. Zgłosiłem buga i (szybka!) odpowiedź trochę martwi:
The Free Plan can return uptime ratios back to 1 month due to the limit of the logs kept. The Pro Plan supports back to 1 year.
And, the alltimeuptimeratio variable in the API currently returns 1-month uptime (and it’ll be removed from the APIv2).
Mój nos mówi mi, że idzie monetyzacja i z fajnej, darmowej usługi może być wkrótce coś niezbyt fajnego/używalnego. Ale może to tylko moje czarnowidztwo.
Poza tym, po niedawnej awarii (jak ktoś nie zna serwisu downdetector.pl do określania, czy jest awaria u dostawcy, to dość entuzjastycznie polecam) u mojego ISP wylądowałem za NAT (jak wielu innych abonentów). Po telefonie przywrócony publiczny IP, ale od tego czasu dla hosta w domu Uptime Robot pokazuje dziwne rzeczy – host znika, pojawia się, znowu znika… Podejrzewałem jakiś autosuspend w momencie, gdy żadne urządzenie nie jest aktywne, ale raczej nie o to chodzi. IP się nie zmienia, więc nawet w przypadku problemów z odświeżaniem dyndns nie powinno rzutować (ale nie wykluczę…). Problemy z routingiem? Może się zbiorę, ustalę IP z którego Uptime Robot monitoruje i zdiagnozuję… Póki co po prostu pauza, aby się śmieci nie generowały.
UPDATE Odnośnie problemów z git – stupid me, czyli niewiedza w temacie gita i podchodzenie do problemu od zadniej strony. Swoją drogą, namierzenie/szukanie rozwiązaniach po objawach mogłoby trwać długo… Przyczyna to złe forkowanie. Na szczęście GitHub ma świetną pomoc. Robienie forka repo git, następnie synchronizacja forka i wszystko działa.
Link do przykładowego wyniku zieje jadem (niezaufany certyfikat), po HTTP jest dobrze.
Poza tym u mnie publiczne IP działało raczej sprawnie, tą czkawkę o której piszesz miałem jak byłem za NATem.
Lista IPków z których UptimeRobot się dobija znajduje się w ichnim FAQ.
A tak na deser: nie sugerowałbym się stanem stron głównych firm hostingowych, bo zazwyczaj albo są hostowane z innych maszyn niż te przeznaczone dla Klientów, lub po prostu stoją za CloudFlare.
Tak, cert jest i niezaufany (bo dla innej domeny), i self signed. Zaszłości, oszczędności. IIRC to u Ciebie po prostu net gorzej działał za NAT. Tu nie ma to miejsca – działa poprawnie, tylko na monitoringu cuda. I to są dziury np. po parę godzin non-stop…
Dzięki, ale coś kojarzę (nie Ty o tym pisałeś?), że sprawdzają tylko z jednego. W ogóle z 13 IP w tej chwili odpowiada na pingi raptem 8. Ale nie to jest problemem – z drugiej lokalizacji, która monitoruje się poprawnie, jest dokładnie tak samo.
Czy strona/serwer jest za CloudFlare – widać (wystarczy whois na IP). Zwykle nie jest. Widać też, na czyjej adresacji stoi, czyli czy np. nie jest w firmie trzeciej. I tak, oczywiście, może stać na innym serwerze, niż strony klienckie. Ba, może stać na kilku serwerach. Ale z założenia nie chcę mierzyć dostępności stron klientów, a grubsze prace/niedostępności (typu problemy z siecią, load balancerem itp.) będą widoczne.
Tak czy inaczej to bardziej punkt odniesienia jest i nie przywiązywałbym się do wartości bezwzględnych – sam Uptime Robot ma swoją zawodność i nie zdziwiłbym się, gdyby była ona w tym przypadku (pomiary stron głównych firm hostingowych) kluczowa.
Ale jak była widoczna czkawka w UR to tak samo działał u mnie net a co za tym idzie hostowany z domu blog. To miałem na myśli. Poza tym UR raczej działa dobrze, chyba tylko raz miałem przypadek że nie generował się u nich wykres, ale logi pokazywały „up”, było „up”, nie było alertów bo monitorowany obiekt działał. Pisałem o tym u siebie, że może admin ekspres do kawy se podłączył zamiast jednego z serwerów ;o)
Na tą listę IPków z których UR może badać obiekty wpadłem jak niby skanował mnie z jednego (stąd mylny wniosek, iż zawsze tak już będzie) po czym ze dwa razy się owo IP zmieniło. Dodałem wszystkie do białej listy i już nie mam przekłamań spowodowanych blokadą nieznanego IP ;-P
Co do sprawy witryn hostingów – CL było tylko dla przykładu. IMHO sprawdzanie wiarygodności danej serwerowni poprzez monitowanie strony głównej firmy to kiepski pomysł, spotykałem się z przypadkami że strona leżała a witryna firmy jakby nigdy nic, i odwrotnie.
Pozostałe „cuda” mogą wynikać z tej prostej przyczyny, że UR jakby daleko jest i może mieć jakieś problemy „po drodze”. Np. dla mojego VPS pokazuje Ping rzędu 150 ms podczas gdy ja z domu mam 15-18 ms.
Mały update: Ten downdetector jest jakiś lewy. Teksty wyglądają jak tłumaczone translatorem, a poza tym dla Inea wisi komunikat „Najnowsze raporty pochodzą głównie z: Poznan, Warszawa, i Polska” – wchodzisz na mapę i a tam żółte plamy na Warszawie, Szczecinie, itp. Czyli albo błąd, albo ktoś dla zabawy zgłosił raporty spoza zasięgu tej sieci, co czyni komunikaty serwisu niewiarygodnymi.
O co chodzi z tymi forkami, bo chyba mniej czaję niż Ty? Myślałem, że forkuje się tylko czyjeś projekty, a nie własne.
@Monter Czyli czkawkę z UR miałeś? Włączyłem i teraz pokazuje poprawnie (100%), więc może faktycznie… Teraz działa, więc zostawiam włączone. Trzeba debugować, jak leży i tyle – sprawa z IP wyjaśniona, więc będzie łatwiej. 😉
Co do „monitoringu” hostingów – jeszcze raz, to jest bardziej punkt odniesienia. I raczej trzeba patrzeć w drugą stronę: skoro strona główna, czyli wizytówka firmy leży, to pewnie klienci też mają problem. Też nie jest to prawdą, ale bardziej o tok myślenia mi chodzi.
Downdetector – to jest polska wersja międzynarodowego serwisu, więc użycie translatora by mnie nie dziwiło (ale na pierwszy rzut oka nic mnie nie raziło). Co do miejsc zgłoszeń – jak komuś leży net w domu, to z niego nie zgłosi. A miejscowość zapewne jest na podstawie geoIP brana, czyli i błędy samego geoIP i to, że łącze z którego następuje zgłoszenie ma spore prawdopodobieństwo na przypisaną Warszawę. Zwł. mobilki, ale nie tylko – ogólnopolscy operatorzy też mają często siedzibę firmy podaną…
@Monter Jeszcze o Downdetector – IMO działa bardzo dobrze. Jak wiedziałem o większych awariach (albo podejrzewałem u mnie), to zawsze było sporo odnotowanych zgłoszeń (nie tylko Inea). Oczywiście to raczej statystyka, niż apteka, ale IMO warto.
Co do gita i forków – zgadza się, upstream nie jest mój i generalnie nie ma sensu forkowanie swoich projektów (nie mylić z branchowaniem i klonowaniem, bo git jest rozproszony).