Todo el mundo sabe que siempre es una buena señal cuando su DevOps está un poco relajado, tranquilo y confiado. Significa que el proyecto está bajo control y que todo funciona como debería. Y cuando se preocupan, es un motivo para que cualquiera se preocupe. Especialmente, si el registro de errores del proyecto es problemático.
Hoy quiero compartir la historia del problema que supone la enorme diferencia entre los datos de los análisis de Cloudflare y NEL que hemos descubierto en uno de nuestros proyectos más importantes (una infraestructura de cadena de bloques que gestiona más de 800 millones de solicitudes al día). No te preocupes, tiene un final feliz.
Esto es lo que pasó.
En mi rutina diaria como líder sénior de DevOps y tecnología, no hay nada especial. Mi trabajo debería ser aburrido, pero a veces me tropiezo con interrupciones e imperfecciones que me estimulan a buscar el problema y resolverlo. Sí, a veces, antes de resolver un problema, tienes que encontrarlo.
Al examinar los informes sobre el estado de los proyectos en Cloudflare, vi una cantidad increíble de 408 errores en el sitio web, alrededor de 20 millones en las últimas 24 horas. Sentí curiosidad por eso.
Esto era demasiado, especialmente si nuestra infraestructura se estaba agotando con otros tipos de averías si se producía al menos una de cada 10 000 partes de esos 408 errores. Como obtenemos los datos no directamente del sitio web, sino a través de Cloudflare, pensé que debería analizar este caso más de cerca. El punto que tenía que resolver: ¿debería preocuparme por los números de Cloudflare si todo iba bien desde el punto de vista de la infraestructura? ¿Cómo puedo obtener estadísticas verdaderamente fiables sobre nuestro registro de errores? ¿Hay alguna herramienta mejor para rastrear eso?
Revelación: por supuesto, había un instrumento mejor para el seguimiento de errores, ya que los «errores» de Cloudflare no son lo que deberían ser. Y ahora te lo demostraré.
Como ya sabrá, Cloudflare Analytics es una plataforma de análisis web que proporciona información en tiempo real sobre el tráfico, las páginas vistas y el comportamiento de los visitantes. Recopila datos mediante una variedad de métodos, incluidas las etiquetas de JavaScript, las balizas web y los registros del servidor. Cloudflare Analytics proporciona una gran cantidad de información sobre el rendimiento del sitio web, incluidos los tiempos de carga de las páginas, las tasas de rebote y las tasas de conversión. También permite a los usuarios profundizar en métricas específicas para obtener una visión más detallada del rendimiento del sitio web. Por lo general, eso es suficiente para que el propietario del sitio web tenga una idea general de lo que está sucediendo.
Cloudflare utiliza una variedad de métodos, que incluyen el monitoreo de usuarios reales (RUM), el monitoreo sintético y el monitoreo del lado del servidor. El RUM implica el seguimiento de las interacciones de los usuarios con un sitio web en tiempo real, mediante etiquetas de JavaScript o complementos de navegador. El monitoreo sintético implica simular las interacciones de los usuarios con un sitio web desde diferentes ubicaciones y dispositivos. La supervisión del lado del servidor implica el seguimiento de los errores del lado del servidor y las métricas de rendimiento, como los tiempos de respuesta y el tiempo de actividad del servidor. Estos métodos suponen tanto el procesamiento de datos como el trabajo con eventos sin procesar.
Los errores 408 suelen deberse a tiempos de espera de la red, que se producen cuando un servidor tarda demasiado en responder a una solicitud de un cliente. Estos errores pueden deberse a diversos factores, como la lentitud de las conexiones de red, la sobrecarga del servidor o un código mal optimizado. En nuestro caso, optimizamos la infraestructura de este proyecto anteriormente, por lo que todos los factores principales se excluyeron de las causas de aparición.
Una posible explicación de por qué Cloudflare informa de más 408 errores es que es más sensible a los tiempos de espera de la red que otros sistemas de registro. Utiliza una red global de servidores y centros de datos para recopilar datos de una amplia gama de ubicaciones y dispositivos, y es más probable que este sistema detecte los tiempos de espera de red que se producen en ubicaciones remotas o mal conectadas. Es posible que otros sistemas de registro no sean tan sensibles a este tipo de errores o que estén configurados para ignorarlos.
Otra posible explicación es que Cloudflare informa de los 408 errores, mientras que otros sistemas de registro pueden estar filtrando algunos de estos errores. Por ejemplo, algunos sistemas de registro pueden configurarse para excluir 408 errores que se producen durante períodos de mucho tráfico o sobrecarga del servidor, ya que estos errores pueden considerarse «esperados» o «normales» en estas circunstancias. Cloudflare, por otro lado, puede informar de los 408 errores, independientemente del contexto en el que se produzcan.
También vale la pena señalar que la cantidad de errores 408 notificados puede verse afectada por factores como el tráfico del sitio web, la carga del servidor y las condiciones de la red. Por ejemplo, un sitio web con altos niveles de tráfico puede tener más probabilidades de sufrir 408 errores, ya que es posible que el servidor esté sobrecargado o no pueda atender las solicitudes entrantes. Del mismo modo, un sitio web alojado en un servidor lento o mal conectado puede tener más probabilidades de sufrir tiempos de espera de red y errores 408.
Cualquiera de estas razones podría alejarnos de la verdad. Así que decidimos buscar otra solución para el seguimiento de errores y encontramos la más fiable de todas a la hora de tomar decisiones.
Registro de errores de red (NEL) es un nuevo encabezado HTTP diseñado para proporcionar una forma de registrar y analizar los errores de red que se producen en los sitios web. El NEL se puede usar para supervisar los errores de la red, como las solicitudes fallidas, los errores de resolución de DNS y los tiempos de espera de las conexiones, y para diagnosticar y solucionar rápidamente los problemas que pueden provocar una mala experiencia de usuario y una pérdida de ingresos. Es una herramienta fiable, de código abierto y fácil de fabricar; cada característica responde a mis gustos en DevOps.
La especificación NEL es un estándar del W3C que define cómo los navegadores web deben manejar el encabezado NEL. El encabezado NEL configura un cliente (navegador) para enviar informes de red [de errores] al punto final del encabezado Report-To proporcionado por. Es como un enlace a un formulario de comentarios, donde cualquier usuario puede dejar sus comentarios sobre el sitio. Sin embargo, está pensado para generar informes automáticos.
Los proyectos pueden beneficiarse de la NEL de varias maneras. Al supervisar los errores de la red, los desarrolladores pueden identificar y solucionar rápidamente los problemas que pueden provocar una mala experiencia de usuario o una pérdida de ingresos. También pueden usar los datos de NEL para identificar las tendencias en la aparición de errores y optimizar sus sitios web o aplicaciones para reducir la frecuencia de los errores.
Una de las principales ventajas de NEL es que permite a los desarrolladores web recopilar datos más completos sobre los errores de red. Tradicionalmente, los desarrolladores dependían del registro de errores del lado del cliente o del servidor para diagnosticar los errores de red, pero estos métodos a menudo no capturaban todos los errores. Con NEL, los desarrolladores pueden ver los errores que se producen en el lado del cliente y en el lado del servidor, y pueden usar esta información para identificar los patrones y las tendencias en los casos de errores.
Otra ventaja de NEL es que proporciona un formato estándar para registrar los errores de red, lo que facilita a los desarrolladores el análisis y la comparación de datos de diferentes fuentes. Esto puede resultar particularmente útil para proyectos grandes con muchos desarrolladores o para empresas con varios sitios web o aplicaciones.
Para usar NEL, los desarrolladores web deben incluir el encabezado NEL en sus respuestas HTTP. El encabezado contiene un URI que apunta a un punto final del informe, donde el navegador envía el objeto JSON que describe el error de red. Luego, los desarrolladores pueden usar esta información para analizar y diagnosticar errores de red.
Uno de los desafíos de usar NEL es que requiere un sistema de respaldo para procesar y almacenar los informes de errores. Los desarrolladores deben configurar un punto final de informes que pueda gestionar y almacenar los informes de errores, y deben disponer de un sistema para analizar los datos y actuar en función de ellos.
Al usar NEL, puede diagnosticar y corregir rápidamente los problemas que pueden provocar una mala experiencia de usuario y una pérdida de ingresos, y optimizar sus proyectos para reducir la frecuencia de errores a lo largo del tiempo. Y en nuestro caso, necesitábamos que NEL contrastara el panorama de 408 errores ofrecido por Cloudflare y encontrara una verdad única en la que confiar.
Después de implementar NEL, seguro que obtenemos una imagen mucho más realista de lo que estaba sucediendo. Además, presentamos esta solución al cliente y recibimos otro aplauso.
La NEL Grafana informó que todo estaba tranquilo y ordenado, con alrededor de 400 errores que no cambiaron nada para una infraestructura de 800 millones de solicitudes por día.
Los dos últimos días nos mostraron la cantidad correcta de errores que pueden ser confiables porque los obtenemos directamente del sitio web, no a través del proveedor externo.
Esta pequeña historia nos muestra la importancia de entender los propósitos de nuestros instrumentos en lugar de usarlos a ciegas y sin pensar. Otra lección que podemos aprender de esto es que la solución, incluso para los problemas más peligrosos, puede ser una herramienta simple y fácil de usar, no una especie de Santo Grial.
Agradecemos a NEL por su arranque inicial, su facilidad de explicación y su fiabilidad; estas son características que nos gustan en todas nuestras soluciones. Este es el verdadero camino hacia un seguimiento y un análisis eficientes: evite las soluciones encubiertas de terceros y apéguese a instrumentos transparentes y abiertos.
Y estarás tan tranquilo como un DevOps profesional.
.jpg)
.jpg)
