¿Qué cliente de StatsD debo usar para un proyecto java/grails?

(3)

Después de dormir sobre esto durante una semana, creo que voy a seguir adelante y usar el plugin existente StatsD de Grails. La razón para esto es que, aunque podría lograr un efecto similar utilizando un Executor para manejar la concurrencia, sin usar un conjunto de objetos, esto todavía estaría vinculado a una única instancia cliente / socket, en teoría un cuello de botella bastante obvio en la aplicación. Por lo tanto, si necesito un grupo de todos modos, también puedo usar uno donde alguien más haya hecho todo el trabajo duro :)

Estoy pensando en agregar la recopilación de datos StatsD a mi aplicación Grails y mirar alrededor de las bibliotecas y el código existentes me ha dejado un poco confundido en cuanto a lo que sería una buena solución escalable. Para poner la pregunta en contexto un poco, estoy trabajando en un proyecto de tipo de juego en línea en el que naturalmente estaré monitoreando las interacciones del usuario con el motor del juego, que naturalmente se agruparán en momentos específicos en los que los usuarios de X realizarán interacciones dentro de la ventana de uno o dos segundos, luego se repite después de una pausa de 10-20 segundos.

Aquí está mi análisis de las opciones que están disponibles hoy.

Ejemplo de cliente Etsy StatsD

https://github.com/etsy/statsd/blob/master/examples/StatsdClient.java

La solución "lo más simple que posiblemente podría funcionar", podría incluir esta clase en mi proyecto e instanciar una instancia de singleton como un bean spring y usarla directamente. Sin embargo, después de notar que el complemento grails-statsd crea un conjunto de instancias de clientes, comencé a preguntarme sobre la escalabilidad de este enfoque.

Parece que el método doSend podría convertirse en un cuello de botella si muchos subprocesos intentan enviar eventos al mismo tiempo, sin embargo, como lo entiendo, debido a la naturaleza de disparar y olvidar el envío de paquetes UDP, esto debería suceder rápidamente, evitando la enorme sobrecarga. que usualmente asociamos con conexiones de red.

plugin grails-statsd

https://github.com/charliek/grails-statsd/

Alguien ya ha creado un complemento StatsD para Grails que incluye algunas características withTimer , como las anotaciones y el método withTimer . Sin embargo, veo que a la implementación le faltan algunas correcciones de errores de la implementación de ejemplo, como especificar la configuración regional en las llamadas a String.format . Tampoco soy un gran fanático de jalar en el apache commons-pool solo por esto, cuando un Ejecutor estándar podría lograr un efecto similar.

java-statsd-client

https://github.com/tim-group/java-statsd-client/

Esta es una biblioteca java pura alternativa que funciona de forma asíncrona manteniendo su propio ExecutorService. Admite la API completa de StatsD, incluidos los conjuntos y el muestreo, pero no proporciona ningún enlace para configurar el grupo de subprocesos y el tamaño de la cola. En el caso de problemas, para cosas no críticas como el monitoreo, creo que preferiría una cola finita y eventos perdidos que tener una cola infinita que llena mi montón.

Reproducir el plugin statsd

https://github.com/vznet/play-statsd/

Ahora no puedo usar este código directamente en mi proyecto de Grails, pero pensé que valía la pena ver cómo se implementaban las cosas. En general, me encanta la forma en que está construido el código en StatsdClient.scala , muy limpio y legible. También parece tener el error de configuración regional, pero de lo contrario, la característica completa con el ejemplo de etsy. Curiosamente, a menos que haya algo de magia Scala que no haya entendido, esto parece crear un nuevo socket para cada punto de datos que se envía a StatsD. Si bien este enfoque evita perfectamente la necesidad de un grupo de objetos o un subproceso ejecutor, no puedo imaginar que sea muy eficiente, y que pueda realizar búsquedas de DNS dentro del subproceso de solicitud que debería regresar al usuario lo antes posible.

Las preguntas

A juzgar por el hecho de que todas las otras implementaciones parecen haber implementado otra estrategia para manejar la concurrencia, ¿puedo asumir que el ejemplo de Etsy es un poco demasiado ingenuo para el uso en producción?
¿Mi análisis aquí parece ser correcto?
¿Qué están usando otras personas para statsd en java / groovy?

Hasta ahora, parece que la mejor solución existente es el plugin de Grails siempre que pueda aceptar la dependencia de commons-pool, pero ahora mismo estoy considerando seriamente pasar el domingo escribiendo mi propia versión que combina las mejores partes de cada implementación.

Hablando como el principal java-statsd-client , así como alguien que usa esta biblioteca en producción, me gustaría intentar disipar tus miedos con respecto a "tener una cola infinita que llena mi montón".

Creo que lo logró con su análisis del ejemplo del cliente Etsy StatsD cuando dijo "debido a la naturaleza de despedir y olvidar el envío de paquetes UDP, esto debería suceder rápidamente, evitando la gran sobrecarga que usualmente asociamos con las conexiones de red".

Tengo entendido que, la forma en que actualmente se implementa el java-statsd-client, la restricción para la acumulación de una gran cola de mensajes salientes es la velocidad del envío de paquetes UDP para disparar y olvidar. No soy un experto en esta área, pero no conozco ninguna forma en que esto pueda bloquearse de tal manera que se pueda crear una cola infinita.

Cuando originalmente realizó su evaluación, hubo una serie de problemas pendientes con el java-statsd-client (por ejemplo, ambigüedades de codificación de caracteres / locale y falta de soporte de muestreo), pero recientemente se han abordado. Lo que queda es la cuestión de si existe un riesgo real de llenar el montón. Me gustaría escuchar las opiniones de la comunidad sobre este tema y, si el consenso es que hay un problema, me encantaría explorar la introducción de una cola de acceso limitado en la biblioteca.

Me encontré con StatsD sobre SLF4J durante una búsqueda similar para un cliente puro de Java StatsD y lo comparé con el cliente de Java StatsD , que mencionaste tenía varios problemas. Basándome en la lectura de la fuente, se me ocurrió este desglose relacionado con los problemas.

EDITAR: la tabla siguiente se ha actualizado para la versión 3.0.1 de java-statsd-client en la que se han solucionado muchos de los problemas originales.

| java-statsd-client | statsd-over-slf4j ——————————————————————————+————————————————————————+———————————————————— messages support sampling | yes | yes ——————————————————————————+————————————————————————+———————————————————— actual sampling performed | no, left to caller | yes, using java.util.Random ——————————————————————————+————————————————————————+———————————————————— nonblocking impl worker | single daemon thread | single daemon thread ——————————————————————————+————————————————————————+———————————————————— nonblocking impl queue | unbounded | caller-specified bound ——————————————————————————+————————————————————————+———————————————————— String.format locale | none* | Locale.US ——————————————————————————+————————————————————————+———————————————————— charset for message bytes | UTF-8** | default, can be overridden * no localisation is applied ** this is the charset that StatsD reads with