Faire DNS Monitoring Right: The AT & T DNS Panne
La panne du serveur de noms de domaine AT&T (DNS) du 15 août 2012 illustre pourquoi une méthode de surveillance des sites Web « non basée sur le cache » est importante pour les sites Web critiques pour la mission. Tout d’abord, un peu d’un examen. La forme la plus courante et de base de surveillance du site Web est effectuée à l’aide d’un navigateur synthétique (et non d’un navigateur réel), qui se connecte au serveur cible via un processus de demande HTTP. Un certain nombre de processus axés sur le serveur, tels que la disponibilité du serveur cible, le temps qu’il faut pour charger le fichier HTML pour le site Web à partir du serveur, et la capacité de détecter les mots clés dans le fichier HTML sont vérifiés via l’utilisation d’un navigateur synthétique à l’aide d’un processus de demande HTTP.
Pour mettre en cache ou ne pas mettre en cache – c’est la question
Toutefois, ce qui n’est généralement pas bien connu au sujet de la méthodologie synthétique de base de surveillance http est les entreprises de surveillance de site Web ont le choix – d’utiliser un «cache» ou «non-cache» méthodologie. Le choix de la méthodologie par un service de suivi affecte directement sa capacité à détecter les problèmes sur les serveurs DNS secondaires, tels que la panne ATT DNS qui s’est produite le 15 août 2012. D’une part, une méthode basée sur le cache est beaucoup plus simple pour l’entreprise de surveillance à implémenter et coûte moins cher à configurer et à administrer. En fait, la plupart des services de surveillance de disponibilité « de base » à faible coût utilisent une « méthode de cache ».
Je vais prendre le non-cache, merci
Cependant, le petit secret sale est la méthode de cache de surveillance n’est pas aussi précis, (ni à long terme aussi rentable) qu’une solution non-cache. Pourquoi? La raison simple est que les méthodes basées sur le cache ne détectent même pas le problème DNS secondaire.
La raison un peu plus complexe est plus longue, mais obtient vraiment à la viande de ce qu’est une bonne surveillance est tout au sujet – en évitant les temps d’arrêt.
Plus précisément, la raison pour laquelle le non-cache est plus rentable est que lorsqu’un problème comme la panne ATT DNS se produit invariablement – comme lorsque toute condition d’erreur de site Web se produit – c’est le temps total de réparation (TTR) qui détermine la perte due aux temps d’arrêt. En d’autres termes, le temps total (1) qu’il faut pour détecter, diagnostiquer et réparer une erreur, plus l’impact de l’erreur est grave. Inversement, plus une solution de surveillance accélère le TTR rapidement, plus la perte est réduite (ou complètement évitée).
Comment surveiller efficacement la prochaine situation de panne d’ATT DNS
Dans le cas de la panne ATT DNS, plusieurs facteurs clés déterminent le délai de réparation :
– Méthode de détection des erreurs : Utilisez une solution de surveillance qui utilise une méthode non-cache pour propager les requêtes DNS jusqu’aux serveurs de noms racine à chaque instance de surveillance. Un service de méthode cache cache DNS et ne détecte donc pas du tout un problème DNS secondaire, ou il peut prendre des jours ou des semaines pour détecter le problème.
-Fréquence de surveillance : Utilisez une fréquence plus rapide de surveillance non cache, comme toutes les 1 minute contre une fois par heure. Plus la solution de surveillance non cache détecte et alerte rapidement un administrateur touché d’un site Web à l’aide d’un service DNS défaillant, plus vite un commutateur peut être effectué vers un fournisseur de défaillance DNS.
– Fréquence du réglage time-to-live (TTL) : plus la valeur du paramètre de fréquence time-to-live (TTL) utilisée par les administrateurs DNS pour définir la mise en cache DNS vers un serveur DNS secondaire du nom de domaine à partir du serveur de nom faisant autorité principal. Généralement réglé à 86.400 secondes (1 jour) ou plus, dans la planification de récupération après sinistre le TTL peut être réglé aussi bas qu’une fois toutes les 300 secondes, mais plus le réglage plus la charge sur le serveur de nom de domaine faisant autorité.
-Les diagnostics – tels qu’un traceur automatique au moment du problème DNS détecté – sont fournis par la solution de surveillance (la plupart des services de surveillance de base ne fournissent aucune information diagnostique)
-Réparation : Continuez à surveiller la solution pendant l’état d’erreur pour identifier davantage le problème. Envoyez les résultats surveillés à votre fournisseur DNS. Vous pouvez également exécuter des traceurs DNS manuels gratuits ici (sélectionnez Trace Style «DNS») pour vérifier le problème au besoin.
-Prévenir : Utilisez une solution de surveillance qui vous permet de visualiser les détails d’une surveillance réelle du navigateur) afin de voir des «erreurs douces» telles que les tendances de ralentissement et les problèmes intermittents, de sorte que vous pouvez prendre des mesures avant que l’erreur douce devient une «erreur difficile» comme un client confronté à des temps d’arrêt.
(1) Selon les organismes qui ont participé à une étude du TRAC, en septembre 2011, les organisations ont identifié le temps passé à dépanner les problèmes de rendement comme leur principal défi avec « en moyenne, sur une semaine de travail complète d’heures-hommes (46,2 heures) passées dans des situations de salle de guerre chaque mois ».
