Host Tracker: Notificación de caída del sitio sólo para empresas
Publicado: Alex Shashenko 2014-03-09 all articles | Glossary | FAQ
Por supuesto, una de las principales prioridades de cualquier administrador de sitios es garantizar que el recurso funcione sin problemas. Sin embargo, periódica «downs » caídas del sitio son inevitables, y lo principal aquí — para rastrear y resolver el problema a tiempo.
Obviamente, nadie es capaz de controlar el rendimiento del sitio durante todo el día. Por otra parte, el recurso puede no estar disponible en otra región, y este gestor no rastrear de ninguna manera.
Y es para resolver estos problemas está diseñado servicio HostTracker, que supervisa la disponibilidad del sitio. Se registros de la «caída» sitio, analiza el problema y envía una alarma al administrador o la gestión de recursos.
Es obvio que nadie necesita una falsa alarma, y el principio «más vale prevenir que curar;— no es la mejor estrategia en este caso. Es por eso que en el trabajo del servicio es necesario ser extremadamente preciso y adecuado en la evaluación de los problemas.
Preguntas frecuentes.
HostTrekker tiene, por tanto, una serie de tareas críticas: rastrear y notificar al cliente a tiempo, y evitar falsas alarmas, y calcular tiempo de actividad en base a los mejores y peores escenarios.
¿Cómo se registra un recurso directo de «drop»?
Cuál es el mejor y el peor escenario posible?
Tan pronto como un cliente añade un sitio web, el sistema envía una solicitud a un intervalo fijo entre un minuto y una hora. En ese momento, dicha comprobación se realiza desde servidores independientes repartidos por todo el mundo para llevar a cabo una supervisión distribuida geográficamente. En la actualidad, hay más de cincuenta servidores de este tipo. Un agente concreto se selecciona aleatoriamente.
Si se devuelve un error de validación, se ejecuta una nueva prueba para entre cinco y siete agentes independientes más. Si, en la mayoría de los casos, se confirma el problema, el recurso se considera «caído». Si los demás agentes no detectaron ningún problema, se asume que el problema local se produjo en un agente concreto.
Si es necesario determinar si un sitio está levantado, se aplica el mismo algoritmo. Prácticamente elimina la posibilidad de falsas alarmas, protegiendo así la tranquilidad de los clientes del servicio. La inaccesibilidad del recurso se establece sólo después de múltiples comprobaciones con un intervalo determinado.
Por supuesto, es imposible garantizar al cien por cien exactamente en qué estado se encontraba el sitio entre comprobaciones. Sin embargo, con la mayor probabilidad en el intervalo entre los controles que dio a conocer un error sitio & -se acuesta‖. Sin embargo, si después de un error comienza la recuperación, entre comprobaciones el recurso puede seguir funcionando. En realidad este escenario es la base para el cálculo optimista del tiempo de actividad. La variante de «mentir» sitio entre comprobaciones se convierte en un punto de partida para calcular un escenario pesimista.
El escenario optimista se tiene en cuenta durante el análisis estadístico, pero en caso de notificar a los clientes los datos se especifican para el escenario pesimista.
De este modo, gracias al cálculo de todas las variantes y a un minucioso seguimiento exhaustivo, el cliente recibe notificaciones puntuales sólo en caso de problemas reales y puede obtener una imagen completa y fiable de lo que está ocurriendo.
Sobre el autor
