Workers Analytics Engine es una nueva herramienta, anunciada este mismo año, que permite a los desarrolladores y equipos de productos crear análisis de series temporales para todo tipo de datos, con alta dimensionalidad, alta cardinalidad y un escalado fácil. Hemos desarrollado Analytics Engine para permitir a los equipos obtener información sobre el código que ejecutan en Workers, proporcionar análisis a los clientes finales o incluso crear una facturación basada en el uso.
En este blog, te explicamos cómo usamos Analytics Engine para desarrollar Analytics Engine. Hemos instrumentado nuestra propia API SQL de Analytics Engine con Analytics Engine, y usamos estos datos para encontrar errores y priorizar nuevas funciones del producto. Esperamos que esto sirva de inspiración a otros equipos que estén buscando formas de instrumentar sus propios productos y de recopilar comentarios.
¿Por qué necesitamos Analytics Engine?
Analytics Engine te permite generar eventos (o "puntos de datos") desde Workers con solo unas líneas de código. Con GraphQL o API SQL, puedes consultar estos eventos y crear información útil sobre el negocio o la tecnología. Para obtener más información sobre cómo comenzar a usar Analytics Engine, consulta nuestra documentación para desarrolladores.
Desde que lanzamos la versión beta abierta de Analytics Engine en septiembre, hemos estado agregando constantemente nuevas funciones, basándonos en los comentarios de los desarrolladores. Sin embargo, hemos observado dos importantes lagunas en nuestra visibilidad del producto.
En primer lugar, nuestro equipo de ingeniería debe responder las típicas preguntas relativas a la observabilidad, tales como: cuántas solicitudes recibimos, cuántas de esas solicitudes generan errores, cuál es la naturaleza de estos errores, etc. Nuestros ingenieros necesitan poder ver los datos agregados (como la tasa de error promedio o el tiempo de respuesta de p99) y detallar más en eventos individuales.
En segundo lugar, puesto que se trata de un producto lanzado recientemente, estamos buscando información sobre el producto. Al instrumentar la API SQL, podemos comprender las consultas que escriben nuestros clientes y los errores que ven, lo que nos ayuda a priorizar las funciones que hacen falta.
Nos dimos cuenta de que Analytics Engine sería una herramienta increíble, tanto para responder a nuestras preguntas relativas a la observabilidad técnica como para recopilar información sobre el producto. En efecto, podemos registrar un evento para cada consulta en nuestra API SQL y, a continuación, consultar los problemas de rendimiento agregados, así como los errores y las consultas individuales que ejecutan nuestros clientes.
En la siguiente sección, te explicaremos cómo usamos Analytics Engine para supervisar esa API.
Agregar instrumentación a nuestra API SQL
La API SQL de Analytics Engine te permite consultar los datos de eventos de la misma manera que consultarías una base de datos normal. Durante décadas, SQL ha sido el lenguaje más común para consultar datos. Queríamos proporcionar una interfaz que te permitiera empezar de inmediato a hacer preguntas sobre tus datos sin tener que aprender un nuevo lenguaje de consulta.
Nuestra API SQL analiza las consultas de SQL de los usuarios, las transforma y las valida, y luego las ejecuta en los servidores de base de datos back-end. A continuación, escribimos información sobre la consulta nuevamente en Analytics Engine para poder ejecutar nuestro propio análisis.
La escritura de datos en Analytics Engine desde Cloudflare Worker es muy simple y se explica en nuestra documentación. Instrumentamos nuestra API SQL de la misma manera que lo hacen nuestros usuarios y este extracto de código muestra los datos que escribimos en Analytics Engine:
Ahora que esos datos están almacenados en Analytics Engine, podemos obtener información sobre cada campo que estamos analizando.
Crear consultar para generar información
El hecho de mantener nuestros datos de análisis en una base de datos SQL te permite la libertad de escribir cualquier consulta que desees. En comparación con el uso de métricas que a menudo son predefinidas y tienen un propósito específico, puedes definir cualquier conjunto de datos personalizado que desees e interrogar a tus datos para formular fácilmente nuevas preguntas.
Necesitamos admitir conjuntos de datos que comprendan billones de puntos de datos. Para lograrlo, hemos implementado un método de muestreo llamado Adaptive Bit Rate (ABR). Con ABR, si tienes grandes cantidades de datos, tus consultas pueden devolver eventos de muestra para responder en un tiempo razonable. Si tienes cantidades de datos más típicas, Analytics Engine consultará todos tus datos. Esto te permite ejecutar cualquier consulta que desees y obtener respuestas rápidamente. Actualmente, debes tener en cuenta el muestreo a la hora de realizar tus consulta, pero estamos examinando distintos enfoques para automatizar el proceso.
Para visualizar tus análisis, puedes utilizar cualquier herramienta de visualización de datos. En Cloudflare, usamos mucho Grafana (¡y tú también puedes hacerlo!). Esta herramienta es especialmente útil para casos de uso de observabilidad.
Observar los tiempos de respuesta de las consultas
Una consulta a la que le prestamos especial atención nos brinda información sobre el rendimiento de nuestros clústeres de bases de datos back-end:
Como puedes observar, el percentil del 99 % (que corresponde al 1 % de las consultas más complejas a ejecutar) a veces alcanza picos de aproximadamente 300 ms. Pero, en promedio, nuestro back-end responde a las consultas con un retardo de 100 ms.
Esta visualización se genera a partir de una consulta SQL:
Información del cliente a partir de datos de alta cardinalidad
Otro uso de Analytics Engine es extraer información acerca del comportamiento del cliente. Nuestra API SQL es especialmente adecuada para esto, ya que puede aprovechar al máximo el poder de SQL. Gracias a nuestra tecnología ABR, incluso las consultas costosas se pueden llevar a cabo en grandes conjuntos de datos.
Usamos esta capacidad como ayuda para priorizar las mejoras en Analytics Engine. Nuestra API SQL admite un dialecto bastante estándar de SQL, pero aún no tiene todas las funciones. Si un usuario intenta hacer algo no compatible en una consulta SQL, recibe un mensaje de error estructurado. Esos mensajes de error se notifican en Analytics Engine. Podemos agregar los tipos de errores que encuentran nuestros clientes, lo que ayuda a determinar qué funciones se deben priorizar a continuación.
La API SQL muestra errores con el formato type of error: more details. La primera parte (antes de los dos puntos) indica por lo tanto el tipo de error. Reagrupamos los errores en función de esta información para obtener un recuento de cuántas veces se ha producido ese error y a cuántos usuarios ha afectado:
Para realizar la consulta anterior, utilizando un sistema de métricas ordinario, necesitaríamos representar cada tipo de error con una métrica diferente. La notificación de un número tan alto de métricas de cada microservicio presenta desafíos en términos de escalabilidad. Ese problema no se produce con Analytics Engine, porque está diseñado para manejar datos de alta cardinalidad.
Otra ventaja importante de un almacén con alta cardinalidad como Analytics Engine es que puedes profundizar en los detalles. Si se produce un pico de errores de SQL, es posible que deseemos encontrar qué clientes tienen un problema a fin de ayudarles o identificar qué función quieren usar. Esto es una tarea fácil, con otra consulta de SQL:
En Cloudflare, históricamente hemos confiado en consultar nuestros servidores de base de datos back-end para obtener este tipo de información. La API SQL de Analytics Engine ahora nos permite abrir nuestra tecnología a nuestros clientes, para que puedan recopilar fácilmente información sobre sus servicios a cualquier escala.
Conclusión y qué viene a continuación
La información que hemos recopilado sobre el uso de la API SQL es una aportación muy útil para nuestra toma de decisiones acerca de la priorización de productos. Ya hemos añadido soporte para las funciones substring y position, utilizadas en las visualizaciones anteriores.
Al observar los principales errores de SQL, podemos ver numerosos errores relacionados con la selección de columnas. Estos errores se deben principalmente a algunos problemas de uso relacionados con el complemento Grafana. Agregar soporte para la función DESCRIBE debería mitigar este problema, ya que, sin esta función, el complemento Grafana no entiende la estructura de la tabla. Esto, así como otras mejoras de nuestro complemento Grafana, se encuentra en nuestra hoja de ruta.
Además, podemos ver que los usuarios intentan consultar rangos de tiempo en busca de datos más antiguos que ya no existen. Esto sugiere que nuestros clientes desearían beneficiarse de una retención de datos más prolongada. Recientemente, hemos ampliado nuestra retención de datos de 31 a 92 días, y seguiremos atentos a esta demanda para determinar si deberíamos ampliar aún más este periodo.
Observamos muchos errores relacionados con errores comunes o interpretaciones incorrectas de la sintaxis SQL adecuada. Esto indica que podemos proporcionar mejores ejemplos o explicaciones de errores en nuestra documentación para ayudar a los usuarios a solucionar sus consultas.
¡Sigue atento a nuestra documentación para desarrolladores para mantenerte informado acerca de la evolución y la incorporación de nuevas funciones!
¡Ya puedes comenzar a usar Workers Analytics Engine! Analytics Engine ahora está en la versión beta abierta con retención de datos gratuita de 90 días. Empieza a usarlo hoy o únete a nuestra comunidad Discord para hablar con nuestro equipo.