Host Tracker: Site drop notification alleen voor bedrijven

Natuurlijk is een van de topprioriteiten voor elke sitebeheerder ervoor te zorgen dat de bron probleemloos draait. Echter, periodieke «downs » site crashes zijn onvermijdelijk, en het belangrijkste hier — het probleem tijdig opsporen en oplossen.
Uiteraard is niemand in staat om de prestaties van de site de klok rond te volgen. Bovendien kan de bron niet beschikbaar zijn in een andere regio, en deze manager zal het op geen enkele manier traceren.
En het is om deze problemen op te lossen is ontworpen dienst HostTracker, die de beschikbaarheid van de site controleert. Het registreert de «downfall» site, analyseert het probleem en stuurt een alarm naar de beheerder of het middelenbeheer.
Het is duidelijk dat niemand een vals alarm nodig heeft, en het principe «better safeguard than sorry;— is in dit geval niet de beste strategie. Dat's waarom in het werk van de dienst het noodzakelijk is om uiterst nauwkeurig en adequaat te zijn in het beoordelen van problemen.

HostTrekker heeft daarom een aantal kritische taken: het tijdig opsporen en waarschuwen van de klant, en het voorkomen van vals alarm, en het berekenen van uptime op basis van best-case en worst-case scenario's.

Hoe log je een directe «drop» bron?

Wat is het beste en slechtste scenario?
Zodra een klant een website toevoegt, stuurt het systeem een verzoek uit met een vast interval tussen een minuut en een uur. Daarbij wordt de controle uitgevoerd vanaf onafhankelijke servers die over de hele wereld verspreid zijn, zodat de controle geografisch gedistribueerd is. Momenteel zijn er meer dan vijftig van dergelijke servers. Een specifieke agent wordt willekeurig geselecteerd.

 Als er een validatiefout wordt geretourneerd, wordt een nieuwe test uitgevoerd voor nog eens vijf tot zeven onafhankelijke agenten. Als in de meeste gevallen het probleem wordt bevestigd, wordt de bron als «fallen» beschouwd. Als de andere agenten geen problemen ontdekten, wordt aangenomen dat het lokale probleem zich voordeed op een bepaalde agent.
Als moet worden bepaald of een site up is, wordt hetzelfde algoritme toegepast. Dit elimineert vrijwel de mogelijkheid van valse alarmen, en beschermt zo de gemoedsrust van de service klanten. De onbereikbaarheid van de bron wordt pas vastgesteld na meerdere controles met een bepaald interval.

Natuurlijk is het onmogelijk om voor honderd procent te garanderen in welke staat de site zich tussen de controles bevond. Echter, met de hoogste waarschijnlijkheid in het interval tussen controles die een foutmelding site & ‖ ligt. Als echter na een fout het herstel begint, kan de bron tussen de controles nog steeds werken. Eigenlijk is dit scenario de basis voor optimistische uptime berekening. De variant van «lying» site tussen de controles door wordt een uitgangspunt voor de berekening van een pessimistisch scenario.
Het optimistische scenario wordt in aanmerking genomen tijdens de statistische analyse, maar in geval van kennisgeving aan de klanten worden de gegevens gespecificeerd voor het pessimistische scenario.
Op deze manier, dankzij de berekening van alle varianten en zorgvuldige uitgebreide monitoring, krijgt de klant alleen bij echte problemen tijdig bericht en kan hij een volledig en betrouwbaar beeld krijgen van wat er gebeurt.