tutorial rrd node.js graph visualization graphite statsd

node.js - rrd - Seguimiento de métricas usando StatsD(a través de etsy) y grafito, el grafito gráfico no parece estar graficando todos los datos



statsd counter (2)

Tenemos una métrica que aumentamos cada vez que un usuario realiza una determinada acción en nuestro sitio web, pero los gráficos no parecen ser precisos.

Así que, desistiendo de esta corazonada, invertimos el update.log de carbono y descubrimos que la acción había sucedido más de 4 mil veces hoy (usando grep y wc), pero de acuerdo con el resultado integral del gráfico, devolvió solo 220 milisegundos.

¿Cuál podría ser la causa de esto? Los datos están siendo reportados a statsd usando la librería statsd php, y llamando a statsd::increment(''metric''); y como se indicó anteriormente, el registro confirma que más de 4.000 actualizaciones de esta clave sucedieron hoy.

Estamos usando:

grafito 0.9.6 con statsD (etsy)

Después de investigar un poco a través de la documentación y algunas conversaciones con otros, encontré el problema y la solución.

La forma en que está diseñado el formato de archivo de susurro, espera que usted (o su aplicación) publique actualizaciones que no storage-schemas.conf el intervalo mínimo en su archivo storage-schemas.conf . Este archivo se usa para configurar cuánta retención de datos tiene en diferentes resoluciones de intervalos de tiempo.

Mi archivo storage-schemas.conf se configuró con un tiempo de retención mínimo de 1 minuto. El daemon StatsD predeterminado (de etsy) está diseñado para actualizar a carbono (el daemon de grafito) cada 10 segundos. La razón por la cual esto es un problema es: en un período de 60 segundos, los informes de StatsD 6 veces, cada escritura sobrescribe la última (en ese intervalo de 60 segundos, porque se actualiza más rápido que una vez por minuto). Esto produce resultados realmente extraños en su gráfico porque los últimos 10 segundos en un minuto podrían estar completamente muertos e informar un 0 para la actividad durante ese período, lo que da como resultado el anonimato completo de todos los datos que había escrito para ese minuto.

Para solucionar esto, tuve que volver a configurar mi archivo storage-schemas.conf para almacenar datos a una resolución máxima de 10 segundos, por lo que cada actualización de StatsD se guardará en la base de datos de susurros sin sobrescribir.

Etsy publicó la configuración storage-schemas.conf que estaban usando para su instalación de carbono, que se ve así:

[stats] priority = 110 pattern = ^stats/..* retentions = 10:2160,60:10080,600:262974

Esto tiene un tiempo de retención mínimo de 10 segundos y almacena 6 horas de ellos. Sin embargo, debido a mi próximo problema, amplié significativamente los períodos de retención.

A medida que dejé recolectar estos datos durante unos días, noté que todavía parecía estar apagado (y no estaba informando). Esto fue debido a 2 problemas.

  1. StatsD (versiones anteriores) solo informaron una cantidad promedio de eventos por segundo para cada período de informe de 10 segundos. Esto significa que si incrementaste una tecla 100 veces en 1 segundo y 0 veces durante los siguientes 9 segundos, al final del décimo segundo, statsD reportaría 10 en grafito, en lugar de 100. (100/10 = 10). Esto no informó el número total de eventos durante un período de 10 segundos (obviamente).

    Las versiones más nuevas de statsD corrigen este problema, ya que introdujeron el depósito stats_counts , que registra el número total de eventos por métrica para cada período de 10 segundos (por lo que en lugar de informar 10 en el ejemplo anterior, informa 100).

    Después de actualizar StatsD, noté que las últimas 6 horas de datos se veían geniales, pero cuando miré más allá de las últimas 6 horas, las cosas se veían extrañas, y la siguiente razón es por qué:

  2. A medida que el grafito almacena datos, mueve los datos de la retención de alta precisión a la retención de precisión más baja. Esto significa que, utilizando el ejemplo de etsy storage-schemas.conf , después de 6 horas de precisión de 10 segundos, los datos se movieron a una precisión de 60 segundos (1 minuto). Para mover 6 puntos de datos de 10s a 60s de precisión, el grafito hace un promedio de los 6 puntos de datos. Por lo tanto, tomaría el valor total de los 6 puntos de datos más antiguos y lo dividiría entre 6. Esto da un promedio de # eventos por 10 segundos para ese período de 60 segundos (y no el número total de eventos, que es lo que nos importa sobre específicamente).

    Así es como se diseña el grafito y, en algunos casos, puede ser útil, pero en nuestro caso, no es lo que queríamos. Para "solucionar" este problema, aumenté nuestro tiempo de retención de precisión de 10 segundos a 60 días. Más allá de 60 días, almaceno las precisiones minuciosamente y de 10 minutos, pero están esencialmente ahí sin ninguna razón, ya que esos datos no nos son útiles.

Espero que esto ayude a alguien, sé que me molestó por unos días, y sé que no hay una gran comunidad de personas que esté utilizando esta pila de software para este fin, por lo que fue necesario investigar un poco para descubrir realmente qué estaba pasando y cómo obtener un resultado que yo quería.