Hej,

Detta kanske är lite OT i just webbhotell forumet men det är nog här det passar bäst in.

Jag håller på att sätta ihop dom sista detaljerna kring en funktion som mäter tillgänglighet på webbhotell. Men jag har inte riktigt bestämt på vilket sätt som är bäst o mäta.

Formeln är iaf (antalet misslyckade försök / (antalet lyckade försök + antalet misslyckade försök))
Nu sker sampling var 10:onde minut (Om du äger ett webbhotell kanske du sett min spindel i loggarna redan..)

Nu till det intressanta. Hur ska man visa datat? Jag var lite inne på att enbart visa siffror för en månad, som då tar hänsyn till samtliga mätpunkter (Det kommer ju ta en stund o köra med tanke på att allt data samplas 6x i timmen), alternativet är att ta fram timdata, dvs. 24 mätpunkter per dygn, eller en per dygn. Eftersom alla (?) webbhotell mäter tillgänglighet per månad borde det ju ändå vara detta som man borde komma fram till?

Men kan det finnas anledning att ta fram annat data? Exempelvis tillgänglighet på dygnet? Har man Amerikanska besökare så kanske man vill ha bra tillgänglighet på natten? (Då många svenska webbhotell har servicefönster)

Vad tycker ni? (Dels webbhotellen och ni som är kunder :-) )

Bör mätas på:

* Nät
* Per Server

Sedan bör den räkna totalt tid i avbrott per varje server, antal avbrott och tid på dygnet avbrott är.

Så om du får avbrott varje tidig morgon för du kör backup eller laddar om config så bör den känna av det.

Allt handlar inte om nertid i tid alltid utan antal avbrott med, 1h nertid med 1 avbrott eller 100 små avbrott kan vara stor skildnad på.

Tänk på att även du kan ha problem i din uppkoppling. Ska det bli rättvisa data behöver du ha flera utspridda mätklienter och även ta hänsyn till att en mätpunkt kan misslyckas medan alla andra fortfarande lyckas.

Gör som Pingdoms GIGRIB-tjänst:
http://uptime.pingdom.com/general/methodology
Det är en rättvisande metod tycker jag.

Ju fler mätpunkter per dag du har desto säkrare blir din statistik. Det är fullt möjligt för delar av ett webbhotell att ligga nere bara några minuter. Nedtid över en halvtimme skulle jag vilja påstå är oerhört ovanligt. Eftersom vi har en upptidsgaranti på 99,9% för våra största kunder (och 99% på alla tjänster oavsett nivå) så måste vi ha mer exakta mätningar än en gång i timmen, kanske till och med mer exakt än var tionde minut. Vårt eget system mäter en gång i minuten från flera olika mätpunkter (har för mig att vi har fem utspridda mätklienter i dagsläget men vi har planer på att dra igång fler).

Vad är det förresten du mäter? Webbhotellens egna hemsidor eller kundhemsidor? Jag misstänker att vi inte är det enda webbhotellet som har sin egen sajt på andra servrar än kundernas sajter. Jag kan avslöja att Levonline.com ligger på en egen ensam maskin, på ett annat nät i hallen. Webbklustren hos Levonline är i en miljö med teknik anpassad särskilt för hög tillgänglighet för webbsidor (bland annat genom lastbalanserade kluster där minst två webbservrar i varje kluster kan krascha samtidigt utan att det påverkar upptiden för sajten), samt även bakom ytterligare en router. Är det då rättvist att mäta vår egen sajt när kunderna ligger i en annan miljö?

Självklart är det så. Tanken är att likna GIGRIB där vi vill ha flera klienter, helst hos webbhotellen (då vi får bra redundans på nätsidan per automatisk) Som det ser ut idag kommer vi mäta från två nät innan vi går live och har "partners".


Ja, det är samma problematik jag brottats med. 10 minuters sampling är det "långsammaste" som jag har kunnat motivera mig själv med, men även 1min och 5min har varit med på tapeten.

Just nu innan lanseringen är det dom "riktiga" sajterna, som i ert fall är www.levonline.se (som har en bra svarstid) vi mäter.
Men tanken är att mäta kundsidor när vi går "live" - Men det förutsätter att vi får konton på alla webbhotell, eller ett hostname som ligger i den "riktiga" kundmiljön. Vissa webbhotell har ju inte ens sin primära sida på samma internetförbindelse (för dom webbhotellen som inte själva kör BGP exempelvis) - just för att vara tillgänliga även vid driftstörningar.

Vi skulle också vilja mäta tillgänlighet av databaser och mailköer. Men vi måste ta en sak i taget (om ingen ger oss en stor påse pengar dvs.)

Pingdom "Publika" GIGRIB suger extremt mycket. Den visar extremt mycket mer nertid än deras betaltjänst.

Men har mycket med att det är så många som har sunkig internetuppkopplingar som mäter och skapar stats.

Mätningen blir lite mer komplicerad hos oss riktiga leverantörer som har nät i flera städer och möjligen även flera fysiska lastbalanserare.

Så belastning och redundans beror mycket på vilken del av sverige trafiken kommer in eller ut.

Det märker man att det kan hända att en leverantör får problem i en viss del av sverige och inte kan nå någon minut tills den konvergerat till annat håll i ringen.


Hur ska du mäta svarstid? ICMP kan man nästan glömma om man vill ha vettigt resultat.

Alla fall när man shapar ut sådant, normalt så får man random DDoS rätt ofta upp till Gbit.

Bästa är mäta från Stockholm, Malmö, Göteborg från olika leverantörer då får man ett bra resultat.

Mätning är inte lätt och det kräver lite kunskaper i statistik för man inte ska mäta ihjäl sig.
När du gör enstaka mätningar på ett värde (uppe/nere) så vill du inte mäta kontinuerligt, det skulle ta för mycket bandbredd.
Först måste du veta vad du ska mäta och på vilken tidsenhet. Är det ett helt dygn, en hel timme, en hel minut eller ännu kortare intervaller?

Sen måste man betänka hur många prov som ska tas . Gäller det heltimmar så är det ~ 10 000 heltimmar/ år.
om du väljer att mäta 100 gånger under året, slumpmässigt uttaget, får du ett prov på 100 ur en population på 10000.
Låt oss säga att 10 av de 100 i provet gav utslag( indikerade att servern var nere). Det betyder att 10% av mätvärdena gav utslag.
Kan man då hävda att servern är nere 10% av tiden?
Nej!
Det man kan säga är att i ett sannolikhetsintervall om (t ex) 95% är serverna nere 10% av tiden med en felmarginal på xx % upp eller ner.
Ju högre sannolihetsintervall, desto större blir felmarginalen. Vanligast är att använda 95% i vetenskaplig litteratur, men det finns skrupelfria gynnare som använder neråt 70%.
Hur stor felmarginalen är beror på 1) förhållandet mellan totala populationen , i detta fall antal timmar/ år, och provets storlek, 100 mätpunkter i detta fall. 2) det valda sannoliketsintervallet. se ovan och 3) Hur stor andel av provet som visar utslag, ju mindre andel desto mindre felmarginal.

Antiklimax: Nu kan jag inte formeln för detta i detalj, men det är en av statistikens grundläggande sammanhang. kan man använda den skickligt så får man mycket information även med få mätpunkter.

En praktisk tillämpning av detta är i alla dessa väljarundersökningar som görs. Det räcker alltså med att fråga 1000 personer av ett antal miljoner för att med 95% sannolikhet få ett värde med en felmarginal på 1,5-2,5% beroende på storlek på partiet.
Man förstår lätt att slumpen skördar så att även om ingen ändrar åsikt så kommer man att få lite olika resultat varje gång man gör undersökningen. Det är inom felmarginalen, och folk som spekulerar i förändringar inom felmarginalen tillhör samma förtappade skara som spelar bort förmögenheter på jack vegas-apparater.

I ditt fall handlar det om att mäta små avvikelser nära noll, och det kräver ännu mer eftertanke. Vad betyder det när du tar ut en provserie på 1000 prov och ett visar att servern är nere? Vad betyder det om inget visar att servern är nere?

lite off såhär men:

Kan du inte mäta tillgänglighet på supporten/driftansvariga med? :-)

Då skulle inte många webbhotell ens komma upp i 60%. ;)

Fast de flesta behöver bara får tag supporten/driftansvariga när det inte fungerar.

Jag föredrar att ligga på ett webbhotell som alltid funkar till 100% där man inte så ofta får tag på support, än att ligga på ett hotell som knappt inte fungerar, men där man får tag på support snabbt 24/7

Supportpersonal kostar och kan man lägga den kostnaden på hårdvara och uppetid är det att föredra.

Tack för ditt svar Magnus :)

I det här fallet så handlar det om webbhotell och frekvensen är var 10:onde minut, dvs. vi gör 144 mätningar per dygn, eller 52 560 per år. Det ger ett par miljoner mätningar om man tittar på samtliga aktörer och om vi ska ha flera mätpunkter.

Det är dock inte ett tekniskt problem, då vi har gott om bandbredd (Ibland kan det ju vara fördel att äga ett webbhotell själv) och själva mätningarna laddar iofs. ner en html sida, ink. headers, men sidan kan vi strunta i, då det är headern som är viktigast. (Vi tar sidan också just nu som "Debug-info" då vi lätt kan gå tillbaka o se om exempelvis en lastbalanserare genererade nån output.

Eftersom det INTE handlar om urval så behöver vi inte tillämpa delar av statistiken mantra här. Däremot är vi lite osäkra på hur vi över tiden ska behålla data, och vad vi ska grunda det på. Exempelvis ska en års-uptime vara baserat på faktiskt alla 52 560 mätpunkter (Ok databasen kommer svälla upp o bli gigantisk stor och det kommer ta en stund o rassla igenom allt) eller kommer det vara baserat på medelvärdet av exempelvis en hel månads data. Det är sådana saker jag funderar på.

Just nu mäter vi en månads tillgänglighet genom alla drygt 4000 mätpunkter, men man kan ju tänka sig att även där titta på medelvärdet av varje dygns mätningar.

Eftersom vi pratar (hoppas jag oftast iaf) om tillgängligheter på 99.9x % så är det ju otroligt viktigt att vi får en hög sampling och använder medelvärden så lite som möjligt.

Beror ju på, om du är en "bra" kund behöver du bara supporten vid problem.

Men kunder kan vara rätt okunniga och kan behöva hjälp med stava till FTP.


Sedan beror det på vad för olika kunder med, ena server man har där det endast ligger i stort sätt företag som har mail som är rätt kritiskt. Där tar det 5min max att den skulle vara nere tills det skulle börja ringa en hel del.

Medans andra servrar skulle kunnat vara nere flera timmar och max fått enstaka mail om det.

Det är väl du som kund som ska göra det? ;-) Det är just därför du har möjlighet att sätta betyg på min sida ;-)

Jag ska inte tala för andra kollegor alls, men när man själv driver ett webbhotell blir jag lite skeptisk till en sådan "konsumentupplysnings"-site som du här skriver om, som drivs av ett annat webbhotell, dvs i realiteten en konkurrent?

Hur har du arbetat med kravet på objektivitet och kritik mot den egna verksamheten? Hur kan jag vara säker på att informationen är helt objektiv och att informationen om företaget presenteras på ett likvärdigt sätt som informationen om din egen verksamhet?

Bara några funderingar... annars är idén bra. Den kräver dock ganska mycket resurser, och du måste kunna mäta både från olika nät och helst också olika länder.

Mvh Jonas

Enkelt - Vårt webbhotell är inte ens med i jämförelsen, och kommer aldrig bli det då det är ett hobbyprojekt där våra kunder kommer från vår bekantskapskrets.

Olika nät håller jag med om, men det är naturligtvis inget krav att vi sätter upp mätpunkter i USA. Inte ens sitescanner, som gör detta på "heltid" har det.

Nej, självklart är det inget krav. Täcker du in ett par av de större näten i Sverige brukar det fånga upp eventuella avbrott även om det är routingproblem mellan ett par leverantörer. Det skadar dock inte att ha en testpunkt någonstans även utomlands som kan köra ett test om någon av de svenska mätpunkterna indikerar avbrott... men det är bara ett tips. :)

Varför skulle backuper ge nertid? Varför ger "laddar om config" nertid?

Absolut, men det är en ekomomisk fråga. Jag kommer inte tjäna en spänn på att sätta upp det här, det handlar mer om jag tycker det är dags att seriöst ta tag i frågan om bra webbhotell (som jag skrev om tidigare här på WN)

Routingproblem kan iofs inträffa rätt ofta, men oftast är dom inte dubbelriktade, iaf. inte om vi pratar BGP-4 (jag har varit med så pass länge att man ibland undrar hur klantskallar hanterar bgp - bara o titta på den ISP'n som helt plötsligt routade ut Youtubes alla nät som sina, nice).

Du kanske vill stänga ner en webbplats medans du gör backup för att förhindra att något skrivs samtidigt till en fil eller logg medans du gör det.


Senaste igår såg vi ett sådant problem, vill inte prata vilket nät det handlade om här.

Ännu värre i detta fallat pga det fastnade i vissa routrar fast det det slutade annonserades. Så vissa ISP får det forfarane även efter hård reset av sessioner.

Fick tyvärr lösas på fult sätt att annonsera 2 x /25 or för att komma runt där, men det kom bara till vissa delar av världen.

Man ser ofta rätt mycket roligheter i nätet.

Det är väl ingen som så dåliga backuprutiner? Har man så mycket diskskrivningar så tar man en snapshot.

Jag har faktiskt ett litet problem, postade det här http://www.webmasternetwork.se/f4t34781.html

Men tänkte att det säkert finns duktiga personer som kan hjälpa mig, jag har kört fast. Har tittat på:

* PTR iaf. det skulle strula (har inga på båda dom näten)
* Fel brandväggsregler (Har testat på 3 servrar nu, har svårt o tänka mig att det kan vara något sånt)

Det enda jag kan tänka mig är IP-only bråkar med mig på något sätt, men kan inte svara på vad, har skickat ett mail till deras support, men inte fått svar.

Det sitter en Cisco 3620 på IP-only nätet, funderar på om den kan bråka, men den har ingen skum config. Den tar hand om ett nät via ett länknät bara.

Svarade på mina resultat i andra tråden.

* PTR - Inte troligt, inte många som ställer in att sin http server ska göra dns lookup på varje besökare då det segar ner allt förmycket.

* En brandvägg har ju bara permit eller deny i grunden, så skickar du samma wget request från varje host så påverkar ju inte en brandvägg det. Antingen släpps det igenom eller inte igenom. Visst så kan belastningen på brandvägg och så påverka men lär gissat att du gjort testat flera gånger och fått samma resultat.


Ett bra sätt är att du skapar en html fil som är mindre än 1500 byte (Glöm inte räkna med övriga ethernet/ip ramar tar plats med) på så sätt slippa massa fragmenterade paket och se om du får samma reslutat då.