Telemetría en aplicación ruby con telegraf
Prueba de concepto práctica sobre cómo monitorizar el comportamiento de un webservice externo (simulado) de una aplicación Ruby, mediante el protocolo de StatsD con almacenamiento en InfluxDB y visualización en Grafana.
Ya ha llovido bastante desde que, en 2011, Etsy nos sacudiera con su post “Measure Anything, Measure Everything” presentando su uso de StatsD. Desde entonces StatsD es un protocolo tan sencillo que hay numerosas implementaciones. Una de ellas, la que describe este post, se encuentra integrada en Telegraf, una de las piezas habituales del stack de monitorización que usamos en The Cocktail. Aún con ello, hay varias versiones para todos los gustos de StatsD, por lo que al margen de los ejemplos, el resto se puede aplicar al stack favorito de cada cual.
Recap: Qué es StatsD?
StatsD fue un servidor de almacenamiento de estadísticas, desarrollado en Node por Etsy, pensado para recibir telemetría interna de aplicación. A grandes trazos es un programa que queda en memoria y memoriza los datos que le vayan llegando por UDP. ¡Ni siquiera está encargado de persistirlos o mostrarlos! Como servidor puede almacenar Gauges, Counters, Sets y Timers. Los Timers son interesantes, porque irán almacenando los tiempos que les digamos, calculando medias, máximas, mínimas y el percentil que queramos calcular.
Configurar Telegraf para comportarse como StatsD
StatsD además es un protocolo tan simple que ya no se usa el servidor desarrollado por Etsy, porque quien más quien menos ha desarrollado el protocolo como complemento a otro sistema. Es el caso de Telegraf. Telegraf puede configurarse como servidor de StatsD y los resultados de los diferentes intervalos se irán almacenando en InfluxDB conforme lleguen sus ciclos de actualización. Podemos elegir si queremos que los contadores se vacíen o no, tras cada ronda de almacenado.
La aplicación Sinatra a monitorizar
Necesitamos una aplicación para monitorizar. Lo mas sencillo para el caso de prueba es tener una aplicación pequeña en Sinatra que simula mediante sleep una hipotética llamada a un servicio en red. Si el sleep se pasa de largo se genera un timeout, otras veces se simula un fallo de conexión y el resto de las ocasiones se realiza un sleep más o menos largo.
Para monitorizarla mediante StatsD necesitaremos la gema statsd-ruby y tendremos que incluir código para crear nuestra conexión (que no es tal al tratarse de UDP) en Sinatra en el bloque de configuración. Usamos variables de entorno por aquello de los 12 factores y porque el plan es que funcione dentro de un contenedor Docker.
Recuperando ese objeto cliente desde las settings podremos usarlo para incrementar un valor, alterar un gauge o, lo más interesante de todo, encerrar un bloque de código en una invocación del método time, que realizará un cálculo de tiempo y lo enviará a StatsD
La aplicación completa con código de monitorización se puede ver aquí.
Datos interesantes para mostrar en Grafana
Tras generar varias llamadas a StatsD en el almacén de datos de InfluxDB (en los ejemplos presentados) se habrán generado nuevos measurements en la base de datos telegraf. Dichos datos serán
error_connect: un campo value con la cuenta acumulada en intervalo de 10 segundos de los errores de conexiónerror_timeout: un campo value con la cuenta acumulada en intervalo de 10 segundos de los errores por timeoutfoobar_value: un campo value con la suma acumulada en intervalos de 10 segundos del valor de foobarexecution_time: Varios campos con: el número, la media de tiempo, el tiempo máximo y mínimo, el percentil 90 y la desviación estándar de todos los tiempos que hayamos enviado a statsD en el mismo intervalo de 10 segundos
Demo: Lanzar el stack
He dejado todo lo necesario para lanzar todos los componentes y sus relaciones a día de hoy la aplicación en un sistema dotado de docker y docker-compose en este repositorio:
Mediante la orden docker-compose up se lanzarán todos los contenedores de aplicación necesarios y se relacionan para que se puedan comunicar internamente. Son, el contenedor de Telegraf con su configuración para StatsD escuchando en el puerto 8125; el contenedor de InfluxDB escuchando en el puerto 8083 y 8086 y el contenedor de Grafana escuchando en el puerto 3000. También se construirá un contenedor derivado de Ruby que incluirá y arrancará la aplicación final con el código para StatsD y que escucha en el puerto 4567.
Demo: Generar trafico a nuestra app
La aplicación de Grafana quedará recibiendo tráfico pero es necesario realizar peticiones para generar tráfico sobre la misma. Puede servirnos cualquier aplicación para generar peticiones HTTP. curl, wget, a mano mediante el navegador o apache benchmark. A mi me gusta vegeta, una aplicación versátil y sencilla de manejar echa en Go y que funciona casi en cualquier lado con solo descargarla.
echo “GET http://0.0.0.0:4567" | ./vegeta attack -duration=30m rate=3 | ./vegeta reportCon rate y duration se puede controlar la cantidad de peticiones que se realizan
Demo: Terminar de configurar Grafana
El Grafana que viene en la demo no está terminado de configurar. Una vez arrancado se accede desde el navegador, en el servidor local en el puerto 3000 Tras esto hay que hacer login (admin/admin), crear un datasource con los siguientes datos
Nombre: influx
Tipo: InfluxDB
URL: http://influx:8086
Modo: proxy
Base de datos: telegrafTras esto podremos importar el dashboard presente en el repositorio, que ya viene preparado con las consultas adecuadas y que debería mostrar algo como esto, si la versión de Grafana no ha cambiado mucho
Y en el que se puede ver cuánto ha fallado la conexión por segundo, cuántos timeouts se están produciendo por segundo, la media y el percentil 90 del tiempo de respuesta del supuesto web service, y cuánto va acumulando el valor de “foo” todo ello en intervalos de 10 segundos (aunque esto puede resultar bastante estresante para la red de un site en producción).
