El grafito deja de recopilar datos al azar

8

Tenemos un servidor Graphite para recopilar datos a través de collectd, statsd, JMXTrans ... Desde hace unos días, con frecuencia tenemos agujeros en nuestros datos. Examinando los datos que aún tenemos, podemos ver un aumento en el tamaño de la caché de carbono (de 50K a 4M). No vemos un aumento en el número de métricas recopiladas (metricsReceived es estable en alrededor de 300K). Tenemos un aumento en el número de consultas de 1000 a 1500 en promedio.

Curiosamente, el uso de cpu disminuye ligeramente del 100% (tenemos 4 CPU) al 50% cuando aumenta el tamaño de la caché.

Curiosamente, vemos un aumento en el número de octetos leídos del disco, y una disminución en el número de octetos escritos.

Tenemos configuración de carbono principalmente con valores predeterminados:

MAX_CACHE_SIZE = inf
MAX_UPDATES_PER_SECOND = 5000
MAX_CREATES_PER_MINUTE = 2000

Obviamente, algo ha cambiado en nuestro sistema, pero no entendemos qué, ni cómo podemos encontrar esta causa ...

Alguna ayuda ?

graphite metrics

— Guillaume
fuente

Por lo general, empiezo desde el enfoque básico de los problemas de grafito; ¿hay espacio en el disco para escribir? ¿Han cambiado los permisos del directorio de datos? ¿Ha habido un cambio en el usuario del daemon que recopila estadísticas? Si no hay una causa clara, es muy posible que tenga daños por RRD, y puede que necesite encontrar una manera de exportar lo que tiene e iniciar la recopilación de indicadores desde cero.

— Stephan

Verificamos el espacio en disco y el permiso, nada extraño allí. Ningún cambio en el daemon que recopila datos, tal vez un aumento en el número de métricas, pero no tan grande. Estamos investigando la corrupción del WSP.

— Guillaume

2

Este no es un error de la pila de grafito, sino más bien un cuello de botella de E / S, probablemente porque su almacenamiento no tiene los IOPS lo suficientemente altos. Debido a esto, la cola se sigue acumulando y se desborda a 4M. En ese punto, pierde esa cantidad de datos en cola, que se refleja más adelante, como "brechas" aleatorias en su gráfico. Su sistema no puede mantenerse al día con la escala a la que recibe las métricas. Se sigue llenando y desbordando .

Curiosamente, el uso de cpu disminuye ligeramente del 100% (tenemos 4 CPU) al 50% cuando aumenta el tamaño de la caché.

Esto se debe a que su sistema comienza a intercambiarse y las CPU obtienen mucho "tiempo de inactividad", debido a la espera de E / S.

Para agregar contexto, tengo 500 IOPS aprovisionados en aws en un sistema en el que recibo unas 40K métricas. La cola es estable a 50K.

— erbdex
fuente

Estoy viendo exactamente el mismo problema descrito en la pregunta. Sin embargo, el uso del disco es mínimo (reportado como 0% -3% por encima) y solo estoy presionando ~ 80 métricas / s a través de StatsD. Por lo tanto, parece poco probable que tenga un cuello de botella IO. ¿Alguna idea de lo que podría estar causando el problema?

— Heyman

1

Otro respondedor mencionó el cuello de botella de E / S de disco. Hablaré sobre el cuello de botella de la red como otra causa de esto.

En mi entorno, ejecutamos un grupo de servidores de interfaz de usuario front-end (httpd, memcached); otro grupo de relés de capa media (relé de carbono-c que realiza reenvío y agregación); y una capa de fondo (httpd, memcached, carbon-c-relay y carbon-cache). Cada uno de estos clústeres consta de varias instancias en EC2 y en el proceso total 15 millones de métricas por minuto.

Tuvimos un problema en el que estábamos viendo brechas para las métricas generadas por la función agregada "suma", y también los valores agregados eran incorrectos (demasiado bajos). El problema se aliviaría reiniciando el relé de carbono-c en la capa intermedia, pero las brechas comenzarían a aparecer nuevamente después de varias horas.

Tuvimos una agregación que tuvo lugar tanto en la capa media como en la capa de fondo (la capa de fondo agregó las métricas agregadas que se le pasaron desde la capa media).

Los hosts de la capa media no estaban vinculados a la CPU, ni al disco, ni a la memoria. Esto, combinado con el hecho de que el problema solo aparecería unas horas después de reiniciar los procesos de retransmisión, significaba que había un cuello de botella en la red. Nuestra solución fue simplemente agregar más hosts a la capa intermedia. Hacer esto instantáneamente resultó en que las métricas agregadas funcionen correctamente y no experimenten brechas.

¿El lugar exacto en la pila de la red donde estaba el cuello de botella? No te lo pude decir. Podría haber estado en los hosts de Linux; podría haber estado en el lado de Amazon.

— Michael Martinez
fuente