metrics - run - ¿Por qué usar statsd cuando el agregador de carbón de grafito puede hacer el mismo trabajo?

prometheus soft

Question

He estado explorando la herramienta de gráficos Graphite para mostrar las métricas de varios servidores, y parece que la forma ''recomendada'' es enviar primero todos los datos de métricas a StatsD. StatsD agrega los datos y los envía a grafito (o más bien, carbono).

En mi caso, quiero hacer agregaciones simples como suma y promedio en métricas en todos los servidores y trazar eso en grafito. El grafito viene con un agregador de carbono que puede hacer esto.

StatsD ni siquiera proporciona agregación del tipo del que estoy hablando.

Mi pregunta es: ¿Debería usar statsd para mi caso de uso? ¿Algo que me falta aquí?

Answer 1

1. StatsD opera sobre UDP, lo que elimina el riesgo de que la respuesta de carbono -aggregator.py sea lenta e introduzca latencia en su aplicación. En otras palabras, acoplamiento flojo.

2. StatsD admite el muestreo de las métricas de entrada, lo que es útil cuando no desea que su agregador tome el 100% de todos los puntos de datos para calcular las estadísticas descriptivas. Para secciones de código de alto volumen, es común usar tasas de muestreo de 0.5% -1% para no sobrecargar StatsD.

3. StatsD tiene una amplia compatibilidad con el cliente .

Answer 2

Debido a que el grafito tiene una resolución mínima, por lo que no puede guardar dos valores diferentes para la misma métrica durante el intervalo definido. StatsD resuelve este problema agregándolos previamente y, en lugar de decir "1 usuario registrado ahora" y "1 usuario registrado ahora", dice "2 usuarios registrados".

La otra razón es el rendimiento porque:

1. Envía datos a StatsD a través de UDP, que es un protocolo de disparo y olvido, sin estado, mucho más rápido
2. La implementación de StatsD etsy está en NodeJS, que también aumenta mucho el rendimiento.

Answer 3

Parece que el agregador de carbono y el conjunto de funciones de statsd disjoint:

• statsd admite el cálculo de la tasa y la suma, pero no admite valores promediados
• el agregador de carbono admite promedios, pero no es compatible con el cálculo de tasas.

Answer 4

Si el agregador de Carbono ofrece todo lo que necesita, no hay razón para no usarlo. Tiene dos funciones básicas de agregación (suma y promedio), y de hecho éstas no están cubiertas por StatsD. (No estoy seguro de la historia, pero tal vez el agregador de carbono ya existía y los autores de StatsD no querían duplicar las características). Carbon también admite la recepción de datos a través de UDP, por lo que lo único que extrañaría sería el muestreo , lo cual no importa si agrega por promedio.

StatsD admite diferentes tipos de métricas agregando valores agregados adicionales (por ejemplo, para temporizadores: media, inferior, superior y superior X percentil, ...). Me gustan, pero si no los necesita, el agregador de carbono es una buena forma de hacerlo también.

He estado buscando el código fuente del agregador de carbono y StatsD (y Bucky , una implementación de StatsD en Python), y todos son tan simples, que no me preocuparía el uso de recursos ni el rendimiento para ninguna de las opciones.

Answer 5

tldr: probablemente querrás statsd (o carbon-c-relay ) si alguna vez quieres ver las sumas o promedios específicos del servidor.

El agregador de carbono está diseñado para agregar valores de métricas múltiples en una sola métrica de salida, generalmente para aumentar el rendimiento de representación gráfica. statsd está diseñado para agregar múltiples puntos de datos en una sola métrica, porque de lo contrario el grafito solo almacena el último valor informado en la resolución de almacenamiento mínima.

Ejemplo de statsd: suponga que su archivo graphite storage-schemas.conf tiene una retención mínima de 10 segundos (el valor predeterminado) y su aplicación está enviando aproximadamente 100 puntos de datos cada 10 segundos a services.login.server1.count con un valor de 1. sin statsd, el grafito solo almacenaría el último recuento recibido en cada intervalo de 10 segundos. después de que se reciba el 100º mensaje, los otros 99 puntos de datos se habrían descartado. sin embargo, si coloca statsd entre su aplicación y grafito, entonces sumará los 100 puntos de datos juntos antes de enviar el total a grafito. por lo tanto, sin statsd su gráfico solo indica si se produjo un inicio de sesión durante el intervalo de 10 segundos. con statsd, indica cuántos inicios de sesión se produjeron durante ese intervalo. ( por ejemplo )

ejemplo del agregador de carbono: supongamos que tiene 200 servidores diferentes que informan 200 métricas separadas ( services.login.server1.response.time , services.login.server2.response.time , etcétera). en su tablero de operaciones muestra un gráfico de la media en todos los servidores que utilizan esta consulta de grafito: weightedAverage (services.login.server * .response.time, services.login.server * .response.count, 2). desafortunadamente, renderizar este gráfico toma 10 segundos. Para resolver este problema, puede agregar una regla de agregación de carbono para precalcular el promedio en todos sus servidores y almacenar el valor en una nueva métrica. ahora puede actualizar su panel para simplemente extraer una única métrica (por ejemplo, services.login.response.time ). la nueva métrica se renderiza casi al instante.

notas laterales:

1. las reglas de agregación en storage-aggregation.conf se aplican a todos los intervalos de almacenamiento en storage-schemas.conf, excepto el primer período de retención (el más pequeño) para cada cadena de retención. es posible usar un agregador de carbono para agregar puntos de datos dentro de una métrica para ese primer período de retención. desafortunadamente, aggregation-rules.conf usa patrones "blob" en lugar de patrones regex. por lo que debe agregar una entrada de archivo aggregation-rules.conf por separado para cada profundidad de ruta y tipo de agregación. la ventaja de statsd es que el cliente que envía la métrica puede especificar el tipo de agregación en lugar de codificarla en la ruta métrica. eso le da la flexibilidad de agregar una nueva métrica sobre la marcha, independientemente de la profundidad de la ruta métrica. si desea configurar el agregador de carbono para realizar la agregación tipo statsd automáticamente cuando agrega una nueva métrica, su archivo aggregation-rules.conf se vería de la siguiente manera:

   <n1>.avg (10)= avg <n1>.avg$
   <n1>.count (10)= sum <n1>.count$
   <n1>.<n2>.avg (10)= avg <n1>.<n2>.avg$
   <n1>.<n2>.count (10)= sum <n1>.<n2>.count$
   <n1>.<n2>.<n3>.avg (10)= avg <n1>.<n2>.<n3>.avg$
   <n1>.<n2>.<n3>.count (10)= sum <n1>.<n2>.<n3>.count$
   ...
   <n1>.<n2>.<n3> ... <n99>.count (10)= sum <n1>.<n2>.<n3> ... <n99>.count$

   notas: el "$" final no es necesario en graphite 0.10+ (actualmente prelanzamiento) aquí está el parche relevante en github y aquí está la documentación estándar sobre reglas de agregación

2. la función Promedio ponderado es nueva en grafito 0.10, pero en general la función Serie promedio dará un número muy similar siempre que su carga esté equilibrada. si tiene algunos servidores que son a la vez más lentos y atienden menos solicitudes o si usted es simplemente un experto en precisión, entonces aún puede calcular un promedio ponderado con grafito 0.9. solo necesitas construir una consulta más compleja como esta:

   divideSeries(sumSeries(multiplySeries(a.time,a.count), multiplySeries(b.time,b.count)),sumSeries(a.count, b.count))

3. si statsd se ejecuta en el cuadro del cliente, esto también reduce la carga de la red. aunque, en teoría, también podría ejecutar agregador de carbono en el lado del cliente. sin embargo, si usa una de las bibliotecas de clientes de statsd, también puede usar el muestreo para reducir la carga en la CPU de su máquina de aplicaciones (por ejemplo, crear paquetes udp de bucle invertido). además, statsd puede realizar automáticamente múltiples agregaciones diferentes en una sola métrica de entrada (suma, media, mínima, máxima, etc.)

4. si usa statsd en cada servidor de aplicaciones para agregar tiempos de respuesta, y luego volver a agregar esos valores en el servidor de grafito usando el agregador de carbono, termina con un tiempo de respuesta promedio ponderado por el servidor de aplicaciones en lugar de solicitarlo. obviamente, esto solo importa para agregar utilizando una regla de agregación media o top_90, y no min, max o sum. Además, solo importa si la carga está desequilibrada. como ejemplo: supongamos que tiene un clúster de 100 servidores y, de repente, 1 servidor recibe el 99% del tráfico. consecuentemente, los tiempos de respuesta se cuadruplican en ese servidor 1, pero permanecen constantes en los otros 99 servidores. si usa la agregación del lado del cliente, su métrica general solo aumentará aproximadamente un 3%. pero si hace toda su agregación en un único agregador de carbono del lado del servidor, entonces su métrica general aumentaría en aproximadamente un 300%.

5. carbon-c-relay es esencialmente un reemplazo directo para el agregador de carbono escrito en c. ha mejorado el rendimiento y las reglas de coincidencia basadas en expresiones regulares. El resultado es que puede hacer la agregación de puntos de datos al estilo de Stat y la agregación de métricas de estilo de retransmisión de carbono y otras cosas ordenadas como la agregación de varias capas, todo en el mismo archivo de configuración simple basado en expresiones regulares.

6. si usa el back-end de cyanite en lugar de la caché de carbono, entonces cianita hará el promedio intramétrico para usted en la memoria (a partir de la versión 0.5.1 ) o en el tiempo de lectura (en la versión <0.1.3 arquitectura).