Hacer el monitoreo de DNS correctamente: la interrupción de DNS de AT&T
La interrupción del servidor de nombres de dominio (DNS) de AT&T del 15 de agosto de 2012 ejemplifica por qué un método “no basado en caché” para el monitoreo de sitios web es importante para los sitios web de misión crítica. En primer lugar, un poco de una revisión. La forma más común y básica de monitoreo de sitios web se realiza utilizando un navegador sintético (no un navegador real), que se conecta al servidor de destino a través de un proceso de solicitud HTTP. Una serie de procesos centrados en el servidor, como la disponibilidad del servidor de destino, el tiempo que se tarda en cargar el archivo HTML para el sitio web desde el servidor y la capacidad de detectar palabras clave dentro del archivo HTML se verifican mediante el uso de un navegador sintético utilizando un proceso de solicitud HTTP.
Almacenar en caché o no almacenar en caché: esa es la cuestión
Sin embargo, lo que generalmente no se conoce bien sobre la metodología básica de monitoreo HTTP sintético es que las empresas de monitoreo de sitios web tienen una opción: usar una metodología de “caché” o “no caché”. La elección de la metodología por un servicio de seguimiento afecta directamente su capacidad para detectar problemas en servidores DNS secundarios, como la interrupción de DNS de AT&T que ocurrió el 15 de agosto de 2012. Por un lado, un método basado en caché es mucho más simple de implementar para el negocio de monitoreo y cuesta menos configurarlo y administrarlo. De hecho, la mayoría de los servicios de monitoreo de tiempo de actividad “básicos” de bajo costo utilizan un “método de caché”.
Voy a tomar el no-cache, gracias
Sin embargo, el pequeño secreto sucio es que el método de monitoreo de caché no es tan preciso (ni a largo plazo tan rentable) como una solución sin caché. ¿Por qué? La razón simple es que los métodos basados en caché ni siquiera detectarán el problema de DNS secundario.
La razón un poco más compleja es más larga, pero realmente llega a la carne de lo que se trata un buen monitoreo: evitar el tiempo de inactividad.
Específicamente, la razón por la que la falta de caché es más rentable es que cuando ocurre invariablemente un problema como la interrupción de DNS de AT&T, como cuando ocurre cualquier condición de error del sitio web, es el tiempo total de reparación (TTR) lo que determina la pérdida debido al tiempo de inactividad. En otras palabras, cuanto TIEMPO total (1) se tarda en detectar, diagnosticar y reparar un error, peor es el impacto del error. Por el contrario, cuanto más rápido una solución de monitoreo acelera el TTR, más se reduce (o se evita por completo) la pérdida.
Cómo monitorear de manera efectiva la próxima situación de interrupción de DNS de AT&T
En el caso del problema de interrupción de DNS de AT&T, hay varios factores clave que determinan el tiempo de reparación:
– Método de detección de errores: utilice una solución de supervisión que utilice un método que no sea de caché para propagar consultas DNS hasta los servidores de nombres raíz con cada instancia de supervisión. Un servicio de método de caché almacena en caché DNS y, por lo tanto, no detectará un problema de DNS secundario en absoluto, o puede tardar días o semanas en detectar el problema.
-Frecuencia de monitoreo: use una frecuencia más rápida de monitoreo sin caché, como cada 1 minuto en lugar de una vez por hora. Cuanto más rápido detecte y alerte la solución de supervisión sin caché a un administrador afectado de un sitio web que utilice un servicio DNS defectuoso, más rápido se podrá realizar un cambio a un proveedor de conmutación por error de DNS.
– Configuración de frecuencia de tiempo de vida (TTL): cuanto menor sea el valor de la configuración de frecuencia de tiempo de vida (TTL) utilizada por los administradores de DNS para establecer el almacenamiento en caché de DNS en un servidor DNS secundario del nombre de dominio del servidor de nombres autoritativo principal. Normalmente establecido en 86.400 segundos (1 día) o más, en la planificación de recuperación ante desastres, el TTL se puede establecer tan bajo como una vez cada 300 segundos, sin embargo, cuanto menor sea la configuración, mayor será la carga en el servidor de nombres de dominio autoritativo.
-El diagnóstico, como un traceroute automático en el momento del problema de DNS detectado, es proporcionado por la solución de monitoreo (la mayoría de los servicios de monitoreo básicos no proporcionan ninguna información de diagnóstico)
-Reparar: continúe monitoreando la solución durante la condición de error para identificar aún más el problema. Envíe los resultados supervisados a su proveedor de DNS. También puede ejecutar traceroutes DNS manual gratuito aquí (seleccione Trace Style “DNS”) para verificar el problema según sea necesario.
-Prevenir: Utilice una solución de supervisión que le permita ver los detalles de una búsqueda de DNS (como un Monitoreo real del navegador) para ver “errores suaves”, como tendencias de desaceleración y problemas intermitentes, para que pueda tomar medidas antes de que el “error suave” se convierta en un “error grave”, como un cliente que enfrenta tiempo de inactividad.
(1) Según las organizaciones que participaron en un estudio de TRAC Research, septiembre de 2011, las organizaciones identificaron la cantidad de tiempo dedicado a solucionar problemas de rendimiento como su principal desafío con “en promedio, durante una semana laboral completa de horas-hombre (46.2 horas) pasadas en situaciones de sala de guerra cada mes”.
