Host Tracker : notification d'abandon de site pour les entreprises uniquement

Bien sûr, l'une des principales priorités de tout gestionnaire de site est de s'assurer que la ressource fonctionne sans problème. Toutefois, les «downs »périodiques du site sont inévitables, et l'essentiel ici &mdash ; pour suivre et résoudre le problème à temps.
Évidemment, personne n'est en mesure de surveiller la performance du site autour de l'horloge. En outre, la ressource peut être indisponible dans une autre région, et ce gestionnaire ne le tracera en aucune façon.
Et c'est pour résoudre ces problèmes est conçu service HostTracker, qui surveille la disponibilité du site. Il enregistre les «downfall» ; site, analyse le problème et envoie une alarme à l'administrateur ou à la gestion des ressources.
Il est évident que personne n'a besoin d'une fausse alarme, et le principe «mieux vaut prévenir que guérir;&mdash ; n'est pas la meilleure stratégie dans ce cas. C’est pourquoi, dans le travail du service, il est nécessaire d’être extrêmement précis et adéquat dans l’évaluation des problèmes.

HostTrekker a donc un certain nombre de tâches critiques : suivre et avertir le client à temps, et éviter les fausses alertes, et calculer uptime sur la base des scénarios les plus favorables et les plus défavorables.

Comment enregistrer une ressource directe «drop» ?
Quel est le meilleur et le pire des scénarios ?
Dès qu'un client ajoute un site web, le système envoie une requête à un intervalle fixe entre une minute et une heure. À ce moment-là, cette vérification est effectuée à partir de serveurs indépendants dispersés dans le monde entier afin d'effectuer une surveillance géographiquement distribuée. À l'heure actuelle, il existe plus de cinquante serveurs de ce type. Un agent spécifique est sélectionné de manière aléatoire.

 Si une erreur de validation est renvoyée, un nouveau test est effectué pour cinq à sept autres agents indépendants. Si, dans la plupart des cas, le problème est confirmé, la ressource est considérée comme «tombée» ;. Si les autres agents n'ont détecté aucun problème, on suppose que le problème local s'est produit sur un agent particulier.
S'il est nécessaire de déterminer si un site est opérationnel, le même algorithme est appliqué. Il élimine pratiquement toute possibilité de fausses alarmes, protégeant ainsi la tranquillité d'esprit des clients du service. L'inaccessibilité de la ressource n'est établie qu'après de multiples vérifications avec un certain intervalle.

Bien entendu, il est impossible de garantir à cent pour cent l'état exact dans lequel se trouvait le site entre deux contrôles. Cependant, avec la plus grande probabilité dans l'intervalle entre les vérifications qui a donné une erreur site & ; ‖ se trouve vers le bas‖. Cependant, si après une erreur commence la récupération, entre les contrôles la ressource peut encore fonctionner. En fait, ce scénario est la base du calcul du temps de fonctionnement optimiste. La variante du site «couché» ; entre les vérifications devient un point de départ pour le calcul d'un scénario pessimiste.
Le scénario optimiste est pris en considération lors de l'analyse statistique, mais en cas de notification aux clients, les données sont spécifiées pour le scénario pessimiste.
De cette façon, grâce au calcul de toutes les variantes et à un suivi complet minutieux, le client reçoit des notifications opportunes uniquement en cas de problèmes réels et peut obtenir une image complète et fiable de ce qui se passe.