[ CoyoteKG @ 06.06.2016. 10:08 ] @
Koristite li vi neki tool ili klikate kao ja?

Da napomenem, da nismo hosting kompanija i sajtovi su uglavnom na nekim shared hostinzima, tako da ne mogu da instaliram nikakve programcice direktno na serverima...

Ono sto sam uradio jeste da sam spakovao u jedan tab tih pedesetak sajtova, i otvorim sve sto je u tom tabu, i zatvaram jedan po jedan za koji se uverim da je online...

E to je bilo Ok do momenta dok proslog vikenda jednom bitnom klijentu nije hakovan sajt....
Ja sam otvarao hompage i sajt je bio online i odmah sam ga i zatvorio. Fora je bila sto samo taj homepage je i radio, tamo neke login stranice koje su im u stvari i najbitnije nisu radile neko vreme, a ja nemam pojma koliko dugo... I ispao je veliki propust sto to nisam video na vreme...

Kako vi resavate ove stvari? Čekirate stranicu po stranicu i gledate sadrzaj?
[ djordjeno @ 07.06.2016. 09:36 ] @
Ja sam pisao custom app koja napravi request i proveri u response da li ima to sto treba da ima.
[ Panajotov @ 07.06.2016. 09:49 ] @
Da li si cuo za Google Webmasters? Detaljno mozes da pratis i neke sitnice na optimizr.net
[ CoyoteKG @ 07.06.2016. 10:16 ] @
za google webmaster moram da budem owner sajta da bih proveravao.
optimizr cu sad da vidim sta je.

Mislio sam kao neki tool koji ce sam da se pokrece recimo svako jutro ili noc, i da mi posalje izvestaj da taj neki sajt ne radi, ili na njemu ne rade svi glavni linkovi, ilistatijaznam... Da ne moram opet rucno da to radim.
[ dejanet @ 07.06.2016. 10:30 ] @
Ako znas power shell ili bash shell mozes da napravis skriptu koju 'bacis' u scheduler(win) ili cron(linux). Skrpita ce da pravi, kao sto je @djordjeno napomenuo request prema site-u, a response mozes da validiras, a zatim da ti posalje mail sa reportom.
[ Panajotov @ 07.06.2016. 10:41 ] @
@CoyoteKG, ti si webmaster? Odrzavas im sajtove? Imas pristup serveru? Ako je odgovor na ovo da, onda se samo registruj na Google Webmaster.

[ plus_minus @ 07.06.2016. 10:44 ] @
Kada hoću da se igram.
whois elitesecurity.org


A i najobičniji ping može da posluži.
[ dejanet @ 07.06.2016. 11:18 ] @
^ ako server generise error page npr. "500 internal server error", sta onda... ?

Jasno je da mora da parsira response against error codes...

[ banesss @ 07.06.2016. 12:38 ] @
@dejanet

error 500 uvek ima iskljucivo veze sa serverom, a ne sa klijentom. Error 500 najcesce nastaje kada klijent nesto posalje u pogresnom formatu, ne posalje uopste itd, a server to ne handluje na pravi nacin i umesto da klijentu vrati odgovarajucu poruku sa instrukcijama sta da ispravi jednostavno baci 500 error sto je pokazatelj lose napisanog code-a.

Sto se tice drugog pitanja vezano za proveru da li je online jednostavan ping iz konzole je ok, mada ozbiljni servisi imaju i health endpoint koji sluzi bas za te svrhe.
Health check obicno podrazumeva dosta vise od samog ping-a i da li server vraca response te je najpouzdanije koristiti health endpoint u te svrhe.
[ Aleksandar Đokić @ 07.06.2016. 15:08 ] @
Ne, nije ping dovoljan, zato sto server moze biti online, a sajt ne mora da radi.

Kad vec pisemo...

ovo je veoma bitna tema za npr. fail-over pricu u "tierd" i distribuiranim sistemima. Frontend (proxy) mora da zna kad postoji problem na backend serveru i da taj server ne koristi.

Npr Airbnb infrastruktura svaki server ima "/health" uri koji daje status servera (cak i https://www.airbnb.com/health). Tako frontend stack (oni valjda koriste nerve/synapse za health monitoring) zna koji backend server je ziv tj. stack sam menja podesavanja proxyja. Mislim da je osnova tog sistema svakako Haproxy, koji je inace "industry standard" za to.

Kad smo kod "system design-a" DNS moze imati vise A rekorda koji su u stvari proxy/load-balanceri. Za svaki od tih rekorda tj. ip adresa obicno budu 2 servera sa "keepalived-om" koji drzi taj IP kao "float" izmedju 2 servera i radi failover u slucaju da jedan server padne (VRRP). Dalje proxy/load-balancer serveri (ili neki drugi stack) rade "health monitoring" backend servera, i prosledjuju zahteve shodno statusu (pazeci na npr. session persistance), ili kes serverima izmedju. Backend serveri mogu da pricaju sa bazom takodje preko proxy servera (npr MySql proxy), i npr dele read/write request-e prema odredjenim serverima. Npr read se mogu opsluzivati iskljucivo sa "slave" (read-only) servera, dok se write prosledjuju masterima. Klaster baze moze ispred imati neki dinamicki kes npr. memcached.

Btw, alatka za proveru sajta moze biti Nagios sa skriptom koja ce da svuce sadrzaj, isparsira i prosledi Nagiosu status. To moze biti i na vise nivoa, provera pingom, provera porta, provera servisa pa tek onda svlacenje sadrzaja i parsiranje.

[Ovu poruku je menjao Aleksandar Đokić dana 07.06.2016. u 16:20 GMT+1]
[ tuxserbia @ 07.06.2016. 20:53 ] @
Pa curl ili čak wget ne može? Malo se parsira, malo provuče kroz grep, ili nedajBože awk, pa se u slučaju greške prosledi mail, a sve to zvek u cron.hourly daily yearly?
[ Aleksandar Đokić @ 08.06.2016. 00:27 ] @
Upravo to, ali u skripti za Nagios :). Cron moze ali mora da se vodi racuna onda da je ta masina ziva, jer to obicno bude neki workstation, dok za nagios mora zaseban server.
[ anon115774 @ 08.06.2016. 09:10 ] @
www.monitis.com

Ako sam dobro razumeo sta ti treba ovaj servis moze sve to.