[Xamda]

Vi har löst det genom att använda olika mailservrar för att sända mail till våra mobilabonnemang som omvadlas till sms genom vår teleoperatör (mail till sms). Vi använder Telenor och har haft ett avbrott i den tjänsten på åtta år (avbrottet var i ett par timmar under vilka de ej kunde leverera sms).

[wooper]

Som jag tidigare nämnde är vår lösning baserad på http://www.nagios.org samt CentOS 5 i botten. Varje server kör sin egen mailserver vilket löser larmen via e-post. För att skicka SMS använder vi oss av 42IT, för att skicka SMS besöker man en spciell URL (t.ex. sms.42it.se/send.php?phone=7311111&msg=blablab) vilket är mycket simpelt och går riktigt fort.

[eliasson]

Pingdom används här, vilket är bland det smidigaste anser jag.

[jonny]

Om du inte vill få larm när "hela hallen går ner" kan du säkert ställa in det.

I Servers Alive kan du lägga till ett test som avbryter andra test om det är nere och larm ställs för varje test.

[jomper]

Jag kör med Pingdom och har satt upp övervakning även på servern med IP bredvid min. Om den också är nere så vet jag att det inte är mina server som bråkar.

Inte den snyggaste lösningen kanske men det funkar tillräckligt bra.

[wooper]

Känner till en man som körde BigBrother http://bb4.com/ under Windows för övervakning. Men efter att ha sätt Nagios hoppade han raskt över till det.

BB fungerar i alla fall på Windows.

[yoggi2k5]

Jag använder mig också av Nagios och Munin för att övervaka och larma. För att få larm till mobilen så använder jag push-mail, dyker upp i mobilen lika snabbt som ett sms men mycket flexiblare och billigare.

[Pingdom]

Originally posted by Xamda@Mar 14 2008, 01:10

Pingdom saknar jag förtroende för då den rapporterar nedtid på flera sajter när vi vet att dessa inte haft en sekunds nedtid (både hos oss och andra). Pingdom är bra på att ge en fingervisning, men är långt ifrån tillförlitlig.

Hej Xamda,

Låt mig först säga att det är smickrande att så många på WN valt att använda våra tjänster.

Det förekommer att kunder till oss ibland tycker att vi upptäcker korta nertider som dem inte tycker förekommer, men i samtliga fall så har vi lyckats förklara för kunden vad detta kan beror på.

Iom. att jag saknar bakgrund till din upplevelse så ska jag istället generalisera mitt svar.

• Låt mig först säga att vår rekommendation är att man väljer att mäta sitt mål med den högsta upplösningen vi erbjuder, nämligen 1ggr. min.
• Alla våra checkar har en timeout på 30 sekunder.
• Om checktyperna är http eller https så måste hela sidan ladda klart innan 30s har passerat och webbserven ska ha svarat med en positiv status kod. (Med undantag i de fall man söker efter ett nyckelord som ska eller inte ska finnas på sidan).
• Om checktypen är en annan så råder i vissa fall vissa andra kriterier.
• För att en check ska anses vara nere så måste en check misslyckas enligt ovanstående kriterier. Om den gör så, så görs ännu en check från ytterligare en server för att bekräfta nertiden, enbart om även denna check misslyckas så anser vi att checken är nere.

Jag utgår ifrån att det i detta fall handlar om ett http eller https check. Här är några vanliga anledningar till att en http check kan fallera.

• Sidan ligger på en server som tillfällig blir belastad vilket leder till att sidan tar mer än 30s att generera.
• Sidan använder sig av en extern databas (ex: MySQL) som blir lastad, sidan som är beroende av den kan då i vissa fall ta mer än 30s att generera. En annan vanligt anledning till att MySQL blir slö är att det görs en backup av MySQL. Samma sak gäller även andra databasservrar.
• En sida inkluderar från externa källor objekt (bilder/script m.m.) där det tillfälligt av någon anledning tar tid att ladda ner detta externa objekt och sidan tar i dessa fall mer än 30s att ladda.
• Det är nätverksproblem mellan check servern och målet (i dessa fall ligger felet med all sannolikhet nära målet). Som jag tidigare nämnde så bekräftar vi givetvis en netid från ytterligare en server, det ska alltså vara problem att nå målet från två av våra servrar.
• Serven svara med en felaktig statuskod.
• Sidan ligger på en server som påverkas av en backup körning.

Detta var några av många fall där en sida plötsligt under en kort period kan hamna i ett läge som gör den blir otillgänglig för våra testservrar (och vanliga internetanvändare) enligt kriterierna vi har.

För att slipa larm där en check ligger nere enbart en kort period (säg 30s och 1min) så rekommenderar vi våra kunder att ställa in larmutskicken så att dem skickas efter ex: 3 minuter av sammanhängande nertid. Om det är en sida som ligger på ett webbhotell där ni som kund inte kan göra mer än att underrätta webbhotellet så är det rekommenderat att ställa in larm på mellan 10-20 min +.

Jag hoppas att jag även om svaret var generellt lyckades förklara några av anledningarna bakom dessa kort nertider som ibland förekommer samt hur man kan konfigurera sina larm för att slippa situationer där man får larm strax innan eller efter att problemet som uppstått inte längre är ett problem.

Jag vill även tillägga att majoriteten av våra tusentals kunder inte drabbas av korta nertider, så även dessa bör iakttas om dem förekommer regelbundet. Kanske är det början till ett större problem.

Med vänlig hälsning
Sam Nurmi
Pingdom.com

Edit: Stavning