Catégorie: Surveillance des services réseau

Le passage à IPv6 passe à la vitesse de la lumière. Le 8 juin 2011, plusieurs grandes organisations, dont Google, Yahoo et Facebook, exécuteront un test complet pour passer à iPv6. Si tout va bien la plupart des entreprises vont commencer à faire le commutateur. Cependant, l’avènement de l’IPV6 n’est pas sans problèmes et les solutions de surveillance des performances qui ont fonctionné pour IPv4, ne fonctionnera pas avec IPv6.

L’utilisation d’un service externe actif de surveillance des performances sera essentielle avec l’avènement d’IPv6. Les gestionnaires de réseaux et de sites Web doivent avoir une vue fidèle sur la connectivité utilisateur final et la possibilité de recevoir une notification instantanée chaque fois qu’un problème se produit. Pour des outils de test gratuits instantanés pour les performances IPv6, consultez ServerView Monitoring™ https://www.dotcom-monitor.com/free-uptime-performance-tests.aspx™ https://www.dotcom-monitor.com/technical-tools-browser-test.aspx .

Level3 Communications et AT&T semblent avoir des problèmes continus au cours des deux derniers jours entraînant des pannes subies.

15 août 2012 – Dotcom-Monitor surveille un problème DNS impliquant att DNS nameservers et fournira des mises à jour au fur et à mesure que de nouveaux détails émergent.

15 août 2012 -La panne d’ATT DNS démontre l’importance du diagnostic des causes profondes en temps réel lors de la surveillance des services Internet. Des erreurs intermittentes d’ATT DNS ont été détectées pour la première fois à 5 h 23 H PST par Dotcom-Monitor une heure complète avant qu’ATT ne rapporte le problème. Le nœud Dotcom-Monitor minnesota a noté le problème et capturé une trace diagnostique DNS au moment de l’erreur. Les non-clients de Dotcom-Monitor peuvent utiliser un outil de traçabilité DNS gratuit ici pour tester si leur domaine est affecté par la sélection de Trace Style «DNS».

Cette information a été envoyée immédiatement aux clients dotcom-monitor dont les services ont été affectés par la panne d’ATT DNS. Ce diagnostic a donné aux clients dotcom-monitor des informations immédiates qui ont identifié la cause profonde du problème sans avoir besoin de dépannage supplémentaire. Les clients dotcom-monitor utilisant ATT DNS ont pris des décisions extrêmement rapides et éclairées, telles que le déplacement de leur DNS vers un autre fournisseur, ou la prise de mesures alternatives pour réafrouer le trafic.

Faire dns surveillance à droite: La panne AT T DNS: Le serveur de noms de domaine AT T (DNS) panne du 15 août 2012 illustre pourquoi une méthode «non-cache basée» pour la surveillance des sites Web est important 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 cache ou non-à-cache – c’est la question de surveillance DNS

Tout d’abord, il n’est généralement pas bien connu que la surveillance externe http site web de type demande, comme le café à votre joint java local, est disponible en différentes «grades» – basé sur le cache et non-cache basé. Dotcom-Monitor utilise une surveillance non mise en cache, qui se propage à travers le processus DNS complet à chaque instance de surveillance. La surveillance basée sur le cache (utilisée par de nombreux services de surveillance de base) ne se propage pas par le biais du processus DNS et manque les problèmes DNS.
Comment surveiller efficacement la prochaine situation de panne DNS

Dans le cas de la panne ATT DNS, plusieurs facteurs clés aident à accélérer le délai de réparation (TTR) ou à éviter les temps d’arrêt.

Le test de panne et de paternité GoDaddy DNS : Qui est votre GoDaddy ? C’est un autre épisode de la Maury Povich Paternity Test sur DNS Outage TV hier. Après avoir écrit au sujet d’une panne majeure AT T DNS le 15 août, nous voici de nouveau le 10 septembre 2012 témoin de la panne godaddy DNS. Des millions d’utilisateurs de sites Web et de courriels DNS processus de recherche se joue comme un épisode de Maury Povich TV de tests de paternité a mal tourné. Pour la première fois, les visiteurs d’un site Web GoDaddy tapent l’URL GoDaddy dans leur navigateur et la réponse du DNS revient « This aint your GoDaddy ». Ou quelque chose comme ça.

Malgré les efforts déployés pour éviter les pannes de sites Web bancaires, elles se sont produites à très grande échelle en 2012 et devraient continuer de se produire. Par conséquent, ce sont les banques qui répondent le plus efficacement aux problèmes d’intempérage des sites Web qui ont un avantage sur le marché en évitant la perte d’utilisateurs de sites Web bancaires.

Les événements d’indisponibilité comme le 27 septembre 2012, la panne du site Web de PNC Financials font les manchettes convaincantes, les maux de tête des banquiers et les ennuis des utilisateurs du site Web de la banque. Mais, est-ce que ce temps d’arrêt est plus que cela? Est-ce un autre lieu de contrôle (l’accès numérique à l’argent) à l’ère moderne qui tourne hors de contrôle dans un trou cyber-noir empiétant du chaos économique? Eh bien non, mais… les temps d’arrêt et les ralentissements ont un impact.