strona główna

Archive for the 'monitoring www' Category

Po przeprowadzce

Saturday, October 27th, 2007

Tym razem krótko. Od wczoraj El Monito znajduje się na nowym serwerze. Wygląda na to, że wszystko jest w porządku, ale jeśli natkniecie się na jakiś problem to, jak zwykle, proszę o kontakt. Adres bez zmian, marcin@elksoft.pl.

Tym samym mogę wrócić do normalnego trybu rozwoju serwisu. Niedługo pierwsze zmiany i nowe funkcje :)

Errare humanum est

Sunday, September 23rd, 2007

...ale do popełniania tysięcy błędów na minutę potrzeba już komputera.

Dzisiaj o 10:03 mój błąd w kodzie El Monito spowodował wysłanie do większości użytkowników całkowicie niepotrzebnych powiadomień typu "Zmiana statusu: Online -> Online", na dodatek – do niektórych nawet w kilkudziesięciu kopiach. Dokładniej: 3211 powiadomień do 81 użytkowników, najbardziej pechowy dostał 161 (cześć, Grzegorz!). Niedobrze.

Przepraszam za kłopoty wszystkich, którzy otrzymali powiadomienia. Przyczynę już znam, jeszcze dzisiaj wprowadzę zmiany zabezpieczające przed powtórzeniem się takiej sytuacji.

Efekt Bytowiska

Wednesday, August 22nd, 2007

Na początku lipca El Monito (wtedy jeszcze Elksoft Monitor: o tu) trafił na wykop.pl. Skutkiem był dość efektowny, ale krótki pik o którym już pisałem.

Google Analytics

W sobotę, 18 sierpnia, Byte umieścił notkę o El Monito na swojej stronie, bytowisko.pl, co spowodowało dużą liczbę odwiedzin, niewiele mniejszą niż po Wykopie. I dziewięciokrotnie większą liczbę nowych kont w ciągu trzech dni.

Efekt Wykopu? Phi. Efekt Bytowiska to jest to :)

El(ksoft) Monito(r)

Tuesday, July 24th, 2007

Tym razem krótko: wczoraj Elksoft Monitor zmienił nazwę (na El Monito), adres (http://el-monito.com/) i wygląd. Nie zmieniła się cena (0zł miesięcznie) i przydatność (bardzo wysoka).

Podoba Ci się nowy wygląd? A może odrzuca? Jakich funkcji najbardziej Ci brakuje? Napisz lub dodaj komentarz :)

Zmiana 2007/07/31: dodałem zrzut głównej strony poprzedniej wersji. Dla porównania :)

elksoft_monitor_stary.png

Monitor międzynarodowy. Trochę.

Thursday, July 5th, 2007

Od dzisiaj, godziny 15:30, Monitor ma znowu trzy stałe źródła danych:

monitor_3_zrodla.gif

Nowe źródło znajduje się w Hanowerze, więc niniejszym sieć stała się międzynarodowa :)

I po wykopie

Tuesday, July 3rd, 2007

sparkline_wykop_20070703.png
Tak wygląda wykres w dwa dni po wykopaniu kilkoma głosami; liczba odwiedzin wróciła prawie do poprzedniego poziomu, co było do przewidzenia w przypadku tego typu serwisu – narzędzia bez fajerwerków i nowych wiadomości.

Miłym rezultatem jest to, że wykopowa strona Monitora pojawiła się dość wysoko w google pod hasłem "monitoring www". Co ciekawe, strona ta i tak przegrywa z wpisem na moim blogu :)
W ciągu ostatnich trzech dni hasło "monitoring www" wyprzedziło dotychczasowy numer jeden na liście haseł dzięki którym ludzie tu trafiają, czyli "prototype.js".

A dzisiaj, w ramach kolejnego eksperymentu, dodałem na stronie Monitora przycisk digga. Zobaczymy :)

Wykop w akcji

Sunday, July 1st, 2007

sparkline_wykop_20070701.png
Do tej pory nie używałem wykopu, więc nie wiedziałem czego się po nim spodziewać, ale dzisiaj mam w końcu okazję sprawdzić to w statystykach.

Adres Monitora został wykopany wczoraj rano, a dzisiejszy wykres odwiedzin wygląda jak na załączonym obrazku. Pierwszy pik, mniej więcej w połowie, to oficjalny start Monitora – ten wątek na grupie net_talk dwa tygodnie temu. Drugi, dwukrotnie wyższy, to właśnie wykop w akcji.

Aktualizacja: adres Monitora wykopał Gołąb, będący także autorem najprawdopodobniej pierwszej blogowej notki na temat tego serwisu. Dzięki :)

Kody odpowiedzi HTTP

Saturday, June 30th, 2007

Ten wpis jest wynikiem rozmów na temat możliwej rozbieżności między tym, co widać w przeglądarce, a stanem raportowanym przez Monitor.

Możliwe są, oczywiście, dwa przypadki: serwis zachowuje się poprawnie w przeglądarce, a Monitor pokazuje jego stan jako "Offline", lub na odwrót. Jeśli taka rozbieżność się utrzymuje, to należy ją potraktować jako bardzo cenną informację o trudnym do zauważenia błędzie: najprawdopodobniej serwis przesyła treści z niewłaściwym kodem HTTP.

Kody HTTP

Krótki opis, z pominięciem wielu nieistotnych teraz szczegółów: wymiana danych według protokołu HTTP odbywa się zawsze według wzoru "zapytanie-odpowiedź". Przeglądarka wysyła do serwera zapytanie zawierające adres zasobu (strony) i żądanie, co należy z nim zrobić (zwykle "pobrać" lub "zmienić"), a serwer odsyła odpowiedź z informacją o stanie wykonania polecenia oraz tekstem do wyświetlenia. Ta informacja o stanie jest przekazywana w postaci liczby – kodu odpowiedzi HTTP. Najczęściej spotykane wartości to:

  • 200: OK – "wszystko w porządku, polecenie się powiodło, przesyłam tekst strony",
  • 301: Trwale przeniesiony – "tej strony już tu nie ma, ale przesyłam adres pod którym powinna teraz być, spróbuj tam",
  • 404: Nie znaleziono – "nie mam niczego z takim adresem, przesyłam wyjaśnienie",
  • 500: Wewnętrzny błąd serwera – "wiem o co chodzi, próbowałem wykonać polecenie, ale nie wyszło; przesyłam wyjaśnienie".

Specyfikacja HTTP wymienia więcej kodów, dla wygody pogrupowanych według pierwszej cyfry: kody 2xx to różne warianty odpowiedzi "OK, jest dobrze", 3xx to "przekierowanie, spróbuj inny adres", 4xx to "błąd po stronie klienta, np niewłaściwy adres lub źle sformułowane zapytanie", 5xx to "błąd po stronie serwera, np. problem ze skryptem, bazą danych, lub sprzętem."

Co z tego wynika w przypadku opisanych wcześniej rozbieżności? Po kolei:

"Mój serwis działa, a według Monitora jest w stanie Offline"

Najprawdopodobniej Twój serwis odsyła poprawną zawartość stron, ale z niewłaściwym kodem odpowiedzi, na przykład 404 lub 500 zamiast 200. Łatwo to sprawdzić w Monitorze na stronie "historia" takiego serwisu poprzez wskazanie kursorem jednego z prostokątów z informacją o wynikach obserwacji:

monitor: status 404

To jest fragment zapisu obserwacji adresu http://elksoft.pl/nie-ma-takiej-strony. Każda stacja obserwacyjna przesyła, oprócz samego stanu (Online/Offline), także wyjaśnienie błędu, w tym przypadku – 404.

Przeglądarki zwykle nie pokazują kodów odpowiedzi, więc z punktu widzenia użytkownika wszystko może wyglądać dobrze – takie strony działają dokładnie tak samo jak z poprawnym kodem, działają odsyłacze, obrazki itp. Pomimo tego z punktu widzenia oprogramowania taki serwis nie działa. A to jest poważny problem z co najmniej dwóch powodów.

Po pierwsze, jeśli Google przeglądając zawartość serwisu trafi na takie strony, to je pominie, wychodząc z założenia że skoro serwis nie działa to cały ten tekst, który dostaje w odpowiedzi, zawiera tylko opis błędu, więc nie warto go indeksować.

Po drugie, przeglądarki i serwery proxy nie zapisują tekstów i obrazków otrzymanych z kodami oznaczającymi sytuacje błędne. Oznacza to wielokrotne ściąganie tych samych elementów stron, więc znacznie większe obciążenie serwera i połączenia z internetem.

"Mój serwis nie działa, a według Monitora jest Online"

Najprawdopodobniej mamy sytuację dokładnie odwrotną do poprzedniej. Na przykład: skrypt obsługujący serwis nie jest w stanie nawiązać połączenia z bazą danych i wyświetla opis błędu na stronie, ale przesyła odpowiedź z kodem 200, więc "jest OK".

Przeciwnie niż w poprzednim przypadku, Google i inne wyszukiwarki, polegając na kodzie odpowiedzi, potraktują ten opis błędu jak zamierzoną zawartość strony. W efekcie Twój serwis może zostać przez nie zapamiętany z niewłaściwą zawartością, aż do następnego pełnego przejrzenia zawartości.

Przeglądarki i serwery proxy, także na podstawie kodu, zapamiętają tekst z opisem błędu zamiast zawartości strony lub obrazka, co oznacza że poprawna treść może być dla części użytkowników niedostępna przez pewien czas po naprawieniu błędu.

Co z tym zrobić?

Przede wszystkim – sprawdzić. Najprościej przy pomocy programu wget (dostępne są wersje na wszystkie popularne systemy operacyjne):


[marcink@raven ~]$ wget –server-response http://elksoft.pl/nie-ma-takiej-strony
–23:52:58– http://elksoft.pl/nie-ma-takiej-strony
Resolving elksoft.pl... 195.114.0.47
Connecting to elksoft.pl|195.114.0.47|:80... connected.
HTTP request sent, awaiting response...
HTTP/1.1 404 Not Found
Date: Fri, 29 Jun 2007 21:53:00 GMT
Server: Apache/2.0.59 (Unix) mod_perl/1.99_17-dev Perl/v5.8.6 mod_ssl/2.0.59 OpenSSL/0.9.7f PHP/4.4.5
Content-Length: 484
Keep-Alive: timeout=1, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1
23:53:00 ERROR 404: Not Found.

Parametr –server-response oznacza, że interesuje mnie nagłówek odpowiedzi. Zawartość nagłówka można tu rozpoznać po tym, że jest wcięta. Najbardziej interesująca jest pierwsza linia: "HTTP/1.1 404 Not Found" oznacza, że odpowiedź została przesłana według protokołu HTTP w wersji 1.1, kod odpowiedzi to 404, a krótki opis: "Not Found", czyli "nie znaleziono". Tak wygląda poprawna odpowiedź serwera na nierozpoznany adres.

Kolejny przykład:


[marcink@raven ~]$ wget –server-response http://www.elksoft.pl/
–02:03:19– http://www.elksoft.pl/
Resolving www.elksoft.pl... 195.114.0.47
Connecting to www.elksoft.pl|195.114.0.47|:80... connected.
HTTP request sent, awaiting response...
HTTP/1.1 301 Moved Permanently
Date: Sat, 30 Jun 2007 00:03:20 GMT
Server: Apache/2.0.59 (Unix) mod_perl/1.99_17-dev Perl/v5.8.6 mod_ssl/2.0.59 OpenSSL/0.9.7f PHP/4.4.5
Location: http://elksoft.pl/
Content-Length: 377
Keep-Alive: timeout=1, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1
Location: http://elksoft.pl/ [following]
–02:03:19– http://elksoft.pl/
Resolving elksoft.pl... 195.114.0.47
Reusing existing connection to www.elksoft.pl:80.
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Date: Sat, 30 Jun 2007 00:03:20 GMT
Server: Apache/2.0.59 (Unix) mod_perl/1.99_17-dev Perl/v5.8.6 mod_ssl/2.0.59 OpenSSL/0.9.7f PHP/4.4.5
Last-Modified: Tue, 26 Jun 2007 22:42:02 GMT
ETag: "2db857c-a1d-d6868280"
Accept-Ranges: bytes
Content-Length: 2589
Keep-Alive: timeout=1, max=99
Connection: Keep-Alive
Content-Type: text/html
Length: 2589 (2.5K) [text/html]

To wygląda ciekawiej, bo po wysłaniu zapytania o adres "http://www.elksoft.pl/" wget otrzymał odpowiedź z kodem 301 ("Moved Permanently" – "przeniesione na stałe") i adresem "http://elksoft.pl/". Prawidłową reakcją na 301 jest wysłanie kolejnego zapytania, ze wskazanym przez serwer adresem, i dokładnie to wget zrobił. Po drugim zapytaniu otrzymał odpowiedź ze statusem 200 ("OK").

Ogólnie, rezultat testów powinien być taki: kiedy w przeglądarce Twój serwis wygląda i zachowuje się poprawnie, to wywołania wget z tymi samymi adresami powinny kończyć się informacjami o statusie 2xx. Kiedy przeciwnie, serwis wyświetla informacje o błędach, wget powinien otrzymać właściwy kod z serii 4xx lub 5xx. Takie zachowanie w dużym stopniu wspierają wszelkie serwery WWW i serwery aplikacyjne – w razie wykrycia błędów, wyjątków lub innego zatrzymania skryptu w niewłaściwy sposób ustawiają kod odpowiedzi na 500. Zwykle wystarcza im nie przeszkadzać, a jeśli już skrypt przechwytuje wyjątki lub obsługuje po swojemu sytuacje błędne, to trzeba je obsłużyć do końca, włącznie z odesłaniem odpowiedniego kodu.

Monitoring WWW

Friday, June 15th, 2007

screens_small.JPGNie ma to jak zgranie w czasie.

Kiedy zaczynałem prace nad narzędziem do sprawdzania dostępności stron WWW, to nie udało mi się znaleźć żadnego polskiego a teraz, kiedy startuję, istnieją przynajmniej dwa inne. Po raz kolejny potwierdziło się, że nie należy odsuwać premiery metodą "jeszcze jedna zmiana" – kiedy w końcu wystartujesz może okazać się, że w międzyczasie zrobiło się tłoczno :)

Mój serwis, Monitor, wyróżnia się tym że przeznaczony jest głównie dla małych firm oraz hobbistów, korzystających z usług tanich firm hostingowych: jest prosty, wygodny i darmowy, a dodanie kolejnej strony zajmuje niewiele więcej czasu niż wpisanie jej adresu. Dostępność stron sprawdzana jest z kilku miejsc w Polsce, a niedługo też kolejnych za granicą. Funkcjonalność to w tej chwili niezbędne minimum, ale planów i pomysłów jest sporo :)

Serwis działa, zapraszam.