Buscando una recomendación para medir una aplicación de alta disponibilidad que está utilizando una CDN

Trabajo para una compañía de Fortune 500 que tiene problemas para medir con precisión el rendimiento y la disponibilidad de aplicaciones de alta disponibilidad (es decir, aplicaciones que aumentan el 99.5% con 5 segundos de navegación de página a página). Consideramos tanto el tiempo de inactividad programado como el no programado para determinar este número de disponibilidad. Sin embargo, recientemente agregamos un CDN a la mezcla, lo que complica un poco nuestras métricas. El CDN ahora maneja aproximadamente el 75% de nuestro tráfico, mientras envía el resto a nuestros propios servidores.

Intentamos medir lo que llamamos una "verdadera experiencia de usuario" (es decir, nuestros scripts de prueba emulan a un usuario típico que hace clic en la aplicación). Estos scripts de monitoreo se encuentran fuera de nuestra red, lo que significa que estamos llegando al CDN aproximadamente el 75% de el tiempo.

La gerencia ha decidido que tomemos el peor de los casos para medir la disponibilidad. Por lo tanto, si nuestros servidores de origen están teniendo problemas, pero la CDN está sirviendo bien el contenido, todavía tenemos un impacto en la disponibilidad. Lo mismo es cierto al revés. Mi opinión es que mientras la "experiencia del usuario" sea exitosa, no debemos castigarnos innecesariamente. Después de todo, ¡hay un CDN para mejorar el rendimiento y la disponibilidad!

Me pregunto si alguien tiene conocimiento de cómo otras compañías de Fortune 500 calculan sus números de disponibilidad. Miro a apple.com, por ejemplo, de una tienda que usa un CDN que nunca parece estar fuera de servicio (a menos que haya un anuncio importante del producto). Sería genial tener algunos datos concretos, ya que no No creo que necesitemos dañarnos innecesariamente con estas métricas. Nos estamos tomando decisiones de negocio basadas en estos números.

Sin embargo, puedo decir que, dado que estas métricas son visibles para la administración, los problemas se abordan y se resuelven bastante rápido (léase: eliminamos la burocracia bastante rápido). Desafortunadamente, como desarrollador, no quiero que la administración piense que la aplicación está arriba o abajo porque algún factor externo (es decir, CDN) está influyendo en los números.

Pensamientos?

(Por error publiqué esta pregunta en StackOverflow, lo siento de antemano por la publicación cruzada)

En resumen, yo diría que deberías definir claramente lo que constituye "disponible" versus "no disponible" y compararte con él. Por ejemplo, podría tener un SLA de rendimiento del lado del cliente para el sitio de 1 segundo hasta el "pliegue" y 3 segundos para una página completamente renderizada. Cuando no cumpla con el SLA de rendimiento, debe contarlo como una falla de disponibilidad para ese período de tiempo. No debería importar si está llegando al CDN o no: la experiencia del usuario es lo que importa.

Sin embargo, dado que solo está realizando mediciones cada 5 minutos, parece razonable medir las visitas al CDN frente al sitio maestro por separado, y calcular que el 75% de la disponibilidad proviene del CDN y el 25% del maestro. La dificultad aquí es que el 75% es solo un promedio. Para asignar la culpa con precisión durante un período de tiempo determinado, debe saber cuándo uno u otro sitio no está realmente orientado al cliente, por ejemplo, durante un cambio planificado o después de una acción manual cuando se detecta un problema. También debe tener en cuenta lo que sucede cuando uno de los sitios maestros o la CDN están inactivos. ¿El cliente obtiene un HTTP 500, o simplemente falla de manera transparente al sitio de trabajo? Mucho depende de su solución de equilibrio de carga. La métrica del "peor de los casos" que describió parece demasiado simplista. Pregúntese, "

En cuanto a si se debe "culpar" cuando el CDN está inactivo: absolutamente. Si el 75% de sus visitas van a la CDN, el 75% de la experiencia de su cliente depende de ellas. Usted es responsable de proporcionar una buena experiencia a sus clientes, por lo que si la CDN tiene problemas, debe usar sus recursos de ingeniería para probarlo y hacer un seguimiento con el proveedor.

Otra cosa a tener en cuenta es lo que sucede cuando el sitio maestro no está disponible durante un período prolongado de tiempo. Como lo ha descrito, parece que el CDN es una copia estática del contenido en el sitio maestro. Si el sitio maestro está inactivo durante mucho tiempo, el CDN podría comenzar a ponerse obsoleto. Entonces, tal vez parte de su SLA debería ser frescura: 1 segundo para el "doblez" y 3 segundos para una página completamente renderizada, con contenido de no más de 15 minutos de antigüedad.

Estoy de acuerdo con user44700, es mejor separar las pruebas de disponibilidad para sus servidores en comparación con el CDN y rastrear los dos de forma independiente. Su verdadera disponibilidad será Server Avail * CDN Avail, ya que si cualquiera de las dos cae, está considerando que su página / sitio está caído. Esto también le costará menos con cualquiera de los proveedores de monitoreo.

No seguiría la ruta de la creación de una prueba de navegador y vería qué elementos fallaron, aunque podría funcionar y algunas empresas como Catchpoint tienen el concepto de "disponibilidad de contenido"; puede que no sea exactamente lo que desea para este caso. Digamos, por ejemplo, que su página web tiene una llamada al CDN para un archivo que entrega 404, la mayoría de las soluciones de monitoreo le dirán que esto es un error, pero ¿fue realmente el CDN el que falló? ¿Era ese archivo incluso importante? tal vez alguien simplemente olvidó eliminar alguna referencia de reliquia que ningún usuario nota.

Puede leer esta publicación de blog para obtener más ideas: http://blog.catchpoint.com/2010/07/21/true-availability-of-a-webpage/

El informe de SLA debe reflejar con precisión la realidad. Si está midiendo la disponibilidad desde la perspectiva del usuario y solo el servidor que realiza la medición está experimentando problemas, informar ese problema dentro de su SLA no reflejaría la experiencia del usuario.

Puedo entender querer mantener la información de origen en un estándar alto, tal vez siempre informarla aunque sea inexacta, pero con una nota que identifique por qué.

Si no puede llegar a un acuerdo, quizás haya una solución técnica para hacer que el servidor de medición sea menos falible.

Si la información se informa como una interrupción y no lo fue, ¿qué valor proporciona el informe?

En mi entorno, informamos de múltiples fuentes. Una metodología de monitoreo externo para informar la disponibilidad desde una perspectiva externa, así como también para informar nuestro sistema interno de registro de interrupciones, que es ingresado por humanos y considera múltiples factores que reflejan con mayor precisión la situación.

Gomez y Keynote son soluciones aceptadas por la empresa para recopilar los tipos de métricas que mencionó. Gomez también tiene un servicio que monitorea su UX de usuario final al obtener un archivo javascript de google-analytics-esque.

Pingdom son buenos: http://www.pingdom.com/

Somos un Fortune 500 con un sitio habilitado para CDN, y utilizamos varias cosas. Usted ha determinado correctamente que necesita medir cosas diferentes si desea detectar cosas diferentes. No me queda claro qué es lo que desea específicamente: los números de disponibilidad para ayudarlo a determinar cuándo una aplicación está realmente inactiva, o los números que le quitan la administración. De todas formas...

1. Monitoreo sintético externo - Keynote / Gomez / Webmetrics. Solíamos usar Keynote, ahora usamos Gomez. Por supuesto, como observa, esto también incluye CDN y cualquier otro componente externo, lo cual es bueno para medir su SLA general, pero no tan bueno para determinar los SLA de sus aplicaciones.

Para obtener el "CDN", puede tomar otro monitor Keynote / Gomez y apuntarlo a sus aplicaciones, no a través del CDN, utilizando un nombre DNS alternativo o cualquier otra cosa. Pero como todavía tiene activos estáticos, es más útil para el rendimiento que la disponibilidad. Y mantiene interrupciones de Internet, interrupciones de agentes, etc. en el ciclo, lo cual es apropiado para algunos propósitos y no para otros.

2. Monitoreo real del usuario. Está basado en la red (Coradiant, Tealeaf) y basado en etiquetas (Jiffy, Gomez). Usamos Coradiant como un sniffer de red y determina el rendimiento real visto por el usuario de los activos alojados aquí en nuestro centro de datos, en otras palabras, las aplicaciones reales y no toda la basura estática en el CDN. Luego escribimos informes para determinar las tasas de error y el rendimiento de la aplicación y utilizamos el Apdex (apdex.org) como una métrica derivada. En algunos casos, no puede usar la red (demasiado tráfico, o sus activos no están alojados donde puede acceder a la red), y la etiqueta no es tan confiable. Tiene el inmenso beneficio de ver realmente el tiempo de respuesta y los errores del usuario final: es fácil configurar un monitor sintético que no produce errores en todos los casos en que lo hace un usuario real.

3. Monitoreo local sintético. Nagios / zabbix / sitescope / cien más. Apunte un monitor a su aplicación localmente (no pase por la CDN). Para el monitoreo de disponibilidad procesable (como en, enviar una página para despertar a alguien), este es el estándar de oro. No tiene en cuenta las cosas de la red.

4. Registro de monitoreo. En cierto sentido, este es el gueto de monitoreo de usuarios reales. Pero si realmente solo quieres ver qué error ocurrió, es bastante útil. Tiene el beneficio de "no, eso es realmente lo que sucedió" de la supervisión real del usuario. A menudo, solo disponibilidad, a menos que esté registrando un tiempo de espera en el nivel web, en cuyo caso le muestra cuánto tiempo tardó su servidor - no es útil para el usuario que enfrenta SLA, pero es muy útil para "en qué código debemos trabajar" ". Usa splunk.

No se trata de ninguno de los dos, utilizamos todos estos, porque usted quiere la "historia del usuario final", así como "en qué programador debemos apoyarnos".

BrowserMob es genial