Jakiś czas temu zacząłem korzystać z Uptime Monitor. Przyznaję, że jestem zadowolony, do pełni szczęścia brakowało mi czegoś, co wystawi moje uptime’y na WWW. Tzn. jest sporo fajnych narzędzi, rysujących ładnie i live, tzn. z autoodświeżaniem, ale… nie byłem przekonany do pomysłu publikacji kluczy API. Tym bardziej, że w niektórych przypadkach udostępnienie klucza wiąże się z z podaniem danych hosta, loginu i hasła do htpasswd itp.
Wolałbym mieć możliwość ukrycia nazwy/IP i ogólnie nie podawania zbyt wielu informacji, zwł. klucza API. Zauważyłem też, że nie ma (a przynajmniej nie znalazłem) nic do obsługi Uptime Monitora w Perlu. Stwierdziłem, że generowanie statycznego HTML (docelowo) z crona jest zupełnie wystarczające, a ew. autoodświeżanie prosto można załatwić JSem czy IIRC nawet polem META w HTML (koła nie odkrywam, „konkurencja” też tak robi.
I w ten sposób powstał PUM czyli Perl Uptime Monitor. 😉 Jest możliwość nadpisania nazwy, jest możliwość generowania uptime dla danego okresu (ilość dni wstecz). Brakuje opakowania wyniku w HTML (wyniki na STDOUT póki co…), ale to wkrótce… W sumie nie ma problemu z pobraniem danych do wykresu czasu odpowiedz, ale nie planuję póki co. Zachęcam do forkowania i zgłaszania pull requestów, ew. pomysłów w komentarzach.
Jak już chciałeś dać nazwę z jajem to ja bym dał PLUM – Perl Live Uptime Monitor ;-P
To, czego ja używam nie korzysta z klucza Master, dla porządku powinieneś wspomnieć iż UM daje dostęp przez API poprzez dwa rodzaje kluczy, z czego Master zawiera listę wszystkich monitorowanych obiektów oraz daje dostęp do edycji i zapisu ustawień UM, a klucze typu Read-Only dotyczą pojedynczych monitorowanych obiektów i poznanie takiego klucza nic atakującemu nie daje.
@Monter Ale właśnie nie jest live. Opiera się o wywołanie (np. z crona).
Tak, korzystam z Monitor-Specific API Keys, czyli dotyczących pojedynczych obiektów, ale dane takie jak nazwa hosta, URL, httpusername czy httppassword są widoczne właśnie dla nich.
Hmmm, mi się wydawało że Uptime Robot jest dla stron publicznych. Jest co prawda w opcjach możliwość ustawienia loginu i hasła do monitorowanego obiektu, ale jest to tylko opcja. Poza tym osobiście nie widzę sensu publikowania na stronie dostępnej dla wszystkich monitora obiektów, stron lub aplikacji, które publicznie dostępne nie są ;o) Po to masz osobne klucze API żeby wybrać co chcesz pokazywać, a czego nie. Coś pominąłem?
Co to znaczy „strona publiczna”? Nie widzę powodu, by ktoś miał znać login, hasło czy choćby nazwę hosta/IP pewnych rzeczy. Oczywiście mógłbym się bawić w różne zestawy hostów (i część statystyk ukryć hasłem), ale po co, skoro mogę mieć wszystko w jednym miejscu?
Prosty scenariusz: jesteś firmą obsługującą „informatycznie” N sklepów. Jak wystawisz takie dane publicznie, to ryzykujesz, że ktoś, komu zajdziesz za skórę zrobi psikusa i DDoSa na te hosty. A to rozwiązanie pozwala z jednej strony mieć wszystko w jednym miejscu, z drugiej ukrywa dane. Hosty mogą się nazywać choćby Sklep 1 w Poznaniu. 😉
Strona publiczna to taka, do której dajesz link i zapraszasz do jej odwiedzin, np. linkujesz do swoich statystyk prosto z bloga, więc musisz liczyć się z tym, że zajrzą tam i ludzie, i boty.
Może zacznijmy od tego dla kogo prowadzisz statystyki i monitoring? Bo jak dla siebie, to niepotrzebnie wynajdujesz koło na nowo ;o)
Zdecydowanie są tam w takim razie także hosty niepubliczne.
Monitoring dla mnie, statystyki ogólnie. Choćby po to, żeby móc kiedyś pokazać, jaki uptime ma (mój) sprzęt w danych warunkach (np. brak redundantnych zasilaczy i łącz), a jaki rozwiązania profesjonalne.
Potrzebujesz zatem narzędzia które ukrywa konfig i prawie wszystko poza wykresem.
Poza tym skoro monitoring dla Ciebie a tylko wyniki raz kiedyś do wklejenia np. na bloga to równie dobrze wystarczy te raz kiedyś zrobić zrzut ekranu a linka do monitora nie dawać, i problem z głowy ;o)
BTW. UptimeRobot chyba właśnie ma jakąś awarię, od 3 rano są puste wykresy na ichnim Dashboardzie.