Pese a que han pasado menos de 3 años desde su lanzamiento, StatsD se ha situado como uno de los componentes más populares, y más útiles, de la cadena de herramientas de DevOps. Le explicamos porque:
¿Qué es StatsD?
StatsD era, en su origen, un sencillo demonio desarrollado y presentado por Etsy para agregar y resumir métricas de aplicación. Con StatsD, los desarrolladores pueden instrumentar aplicaciones utilizando bibliotecas de cliente de un lenguaje específico. Dichas bibliotecas se comunican luego con el demonio de StatsD, utilizando un protocolo muy simple, y el demonio genera métricas agregadas y las retransmite a, prácticamente, cualquier servidor backend de supervisión o creación de gráficos.
Como se suele decir, el resto es historia. La popularidad de StatsD creció rápidamente, hasta llegar a convertirse en un protocolo uniforme de recopilación de métricas de aplicación para el cual el demonio de Etsy ya era solo una implementación de referencia.
¿Cómo funciona StatsD?
Todo empieza con el propio código de aplicación del desarrollador, que lo instrumenta con una de las muchas bibliotecas de StatsD correspondientes al lenguaje de su aplicación. StatsD le permite capturar distintos tipos de métricas en función de sus necesidades. Actualmente, dichos tipos son: Medidores, Contadores, Estadísticas de resumen de intervalos y Conjuntos. Puede ser tan simple como añadir un decorador a los métodos que quiera cronometrar o un script de una línea para realizar el seguimiento del valor de un medidor.
A continuación, la biblioteca de cliente de StatsD envía cada llamada individual al servidor de StatsD a través de un datagrama de UDP. Dado que UDP es un protocolo desconectado en el que el destinatario del datagrama no envía acuse de recibo al remitente, la biblioteca no necesita ejecutar ningún tipo de bloqueo al enviar datos, como lo haría con protocolos basados en TCP o HTTP. La biblioteca tampoco coloca en almacenamiento intermedio los datos entre llamadas, lo que hace que el proceso siga siendo muy sencillo. Si lo desea, puede tomar muestras de los eventos que se van a enviar al servidor, en caso de que instrumente operaciones de alto rendimiento.
El demonio de StatsD escucha, a continuación, el tráfico del protocolo UDP desde todas las bibliotecas de aplicación, agrega los datos a lo largo del tiempo y los “descarga”, en el intervalo deseado, en el servidor backend elegido. Por ejemplo, se pueden agregar intervalos individuales de llamada a función cada 10 segundos en un conjunto de métricas de resumen que describa su valor mínimo, máximo y medio, además de los percentiles 90 y 95, en el intervalo de 10 segundos. El protocolo utilizado entre el demonio de StatsD y el servidor backend variará en función del servidor backend utilizado (la mayoría están basados en HTTP). El servidor backend de supervisión convertirá las corrientes de datos que componen las métricas en gráficos útiles y le enviará notificaciones cuando sea necesario. Entre los ejemplos de servidores backend se incluyen herramientas como Graphite o yours truly.
¿Qué diferencia a StatsD de los demás?
Siempre ha habido, y todavía hay, muchos métodos alternativos para capturar métricas, y uno de los más conocidos actualmente para aplicaciones Java es la excelente biblioteca Metrics de Coda Hale.
Estos son los elementos diferenciadores de StatsD a día de hoy:
Simplicidad: no es solo que resulte muy sencillo instrumentar la aplicación, sino que, además, el protocolo de StatsD está basado en texto, de manera que la escritura y la lectura son directas y sencillas. El código original del servidor Etsy tenía solamente 127 líneas de largo.
Desvinculación de la aplicación y su instrumentación: dado que el demonio se ejecuta fuera de la aplicación y el protocolo UDP es un protocolo de tipo enviar y olvidar (sin confirmación), no existe ninguna dependencia previa entre la recopilación de métricas y la propia aplicación. StatsD no puede bloquear la aplicación y no es necesario que esté en el mismo lenguaje ni que se ejecute en la misma máquina.
Tamaño muy reducido: los clientes de StatsD son muy ligeros, no presentan estado, no necesitan subprocesos y la sobrecarga que implican es insignificante. Además, StatsD permite tomar muestras arbitrarias de las llamadas para reducir el uso de la red. Ubicuidad y ecosistema: hay clientes de StatsD para Ruby, Python, Java, Erlang, Node, Scala, Go, Haskell y, prácticamente, cualquier otro lenguaje. Muchos desarrolladores han escrito servidores alternativos que se adecúan a necesidades especiales o ayudan a maximizar el rendimiento. También existen muchos servidores backend compatibles, tanto de código abierto como de pago. Esto se traduce en la falta de dependencia con respecto a los proveedores.
¿Qué problemas soluciona StatsD?
Más allá del problema técnico que resuelve (llevar datos de un punto A a un punto B de manera eficaz) las mayores contribuciones de StatsD son de naturaleza organizativa. Fomenta una cultura en la que los desarrolladores no tienen que pedir permiso a nadie para instrumentar sus aplicaciones, en la que se capturan métricas antes de que las aplicaciones entren en fase de producción y en la que métricas abstractas de rendimiento o uso de recursos se pueden vincular directamente con las métricas de aplicaciones o productos más relevantes para la empresa. Con frecuencia, nos preguntan cómo se debería “implementar DevOps”. La respuesta suele ser larga, pero, en gran medida, todo se reduce a que los equipos de Desarrollo y Operaciones compartan la propiedad del rendimiento y la disponibilidad de su aplicación. Justo esto es lo que permite StatsD.
StatsD y Datadog
A estas alturas, ya habrá adivinado que somos grandes defensores de StatsD y que le damos un gran uso a nivel interno. También queríamos que a nuestros clientes les resultase muy sencillo enviar métricas de StatsD a Datadog, por cuestiones de creación de gráficos, alertas, correlaciones de eventos y colaboración entre equipos:
- Hemos integrado nuestro propio demonio de StatsD en el agente de Datadog, con el objetivo de que la configuración resulte lo más sencilla posible, sin que deje de ser un sustituto temporal de StatsD (ver código fuente).
- Hemos ampliado el protocolo de StatsD para que admita el etiquetado, una de las mejores prestaciones de Datadog. Así, podrá añadir dimensiones adicionales a sus métricas, como la versión de la aplicación o el tipo de cliente al que hace referencia una llamada específica. Volveremos sobre esto en otra publicación, más adelante.
- Hemos simplificado la detección de las métricas de StatsD en la interfaz de usuario de Datadog. Cada host difundirá automáticamente sus métricas, a fin de que los usuarios no tengan que buscarlas.
¿Quiere ver cómo funciona? Puede experimentar con la versión de prueba gratuita de Datadog y seguir nuestra guía para StatsD.
Este articulo ha sido traducido. La version original se encuentra aquí, en ingles.