Planificación de capacidad de disco para Whisper / Graphite

14

¿Alguien tiene alguna fórmula, o tal vez algunos datos de muestra de su entorno que puedan ayudarme a estimar cuánto espacio en disco utilizará el grafito por punto de datos?

monitoring graphite

— Kyle Brandt
fuente

2

Asegúrese de que también está planificando su E / S de disco correctamente, y no solo la capacidad de su disco. rrdtool, a lo largo de los años, ha acumulado muchas micro optimizaciones que lo hacen mucho más rápido (¿2 veces más rápido?) en escrituras que el formato de base de datos Whisper de Graphite. Si planea mantener todos sus datos en un SSD decente, eso lo llevará a la mayor parte del camino, pero no planearía mantener una tonelada completa de Whisper DB en el disco giratorio. A escala, simplemente no es rentable que los niveles de E / S de disco que arroja Graphite.

— jgoldschrafe

7

whisper-info.py le brinda una gran cantidad de información sobre qué y cómo se agrega cada archivo, incluido el tamaño del archivo.

Sin embargo, solo es útil para los archivos de susurro existentes.

Cuando desee ver el tamaño predictivo de un esquema antes de ponerlo en práctica, pruebe una Calculadora de susurros, como la disponible en https://gist.github.com/jjmaestro/5774063

EDITAR:

Cuando se le pide un ejemplo ...

almacenamiento_esquema:

{
    :catchall => {
      :priority   => "100",
      :pattern    => "^\.*",
      :retentions => "1m:31d,15m:1y,1h:5y"
    }
}

Mirando mi archivo applied-in-last-hour.wsp, ls -lproduce

-rwxr-xr-x 1 root root 4415092 Sep 16 08:26 applied-in-last-hour.wsp

y whisper-info.py ./applied-in-last-hour.wsprendimientos

maxRetention: 157680000
xFilesFactor: 0.300000011921
aggregationMethod: average
fileSize: 4415092

Archive 0
retention: 604800
secondsPerPoint: 10
points: 60480
size: 725760
offset: 52

Archive 1
retention: 2678400
secondsPerPoint: 60
points: 44640
size: 535680
offset: 725812

Archive 2
retention: 157680000
secondsPerPoint: 600
points: 262800
size: 3153600
offset: 1261492

Entonces, básicamente, combina sus hosts por coincidencia de retención por segmento de período de retención por estadística, multiplica por un factor de los sistemas que tiene la intención de aplicar también, factoriza el número de estadísticas nuevas que va a rastrear. Luego, toma la cantidad de almacenamiento que sea y al menos la duplica (porque estamos comprando almacenamiento y sabemos que lo usaremos ...)

— gWaldo
fuente

Cualquier posibilidad de que tenga algunos números de muestra de eso (junto con la configuración de retención). En este momento estoy pensando en diferentes almacenes de datos de series temporales en términos de uso del disco, por lo que obtener grafito en vivo para eso es un poco difícil.

— Kyle Brandt

@KyleBrandt Respuesta actualizada.

— gWaldo

Gracias por esto. Entonces, con el tamaño del archivo, ¿será eso lo que será después de una hora de recopilación de datos, o es que el tamaño del archivo será casi siempre? Entonces, ¿es 4415092 representativo de 5 años de datos esta retención, o es representativo de una hora de datos de 1 minuto? Además, ¿son bytes o bits?

— Kyle Brandt

Esta es una nueva implementación en esta empresa, y no tengo acceso a la anterior. Como el resultado fileSize de nivel superior coincide con el ls -lresultado, considero que son bytes. Cuando sumo los tamaños de los archivos dentro del archivo .wsp (según lo informado por whisper-info.py), se acercan al tamaño general del archivo .wsp (el resto supongo que son metadatos y demás. Este debería ser el tamaño del archivo para todos tiempo, como datos cae hacia abajo para bajar resoluciones de datos, y se descartan los puntos de datos antiguos.

— gWaldo

Bien, entonces con esta configuración de retención. Aproximadamente:ServerCount * MetricCount * 4.5MBytes

— Kyle Brandt

2

En la documentación de statsd dan un ejemplo para una política de retención de datos.

Las retenciones son 10s:6h,1min:7d,10min:5y2160 + 10080 + 262800 = 275040 puntos de datos y dan un tamaño de archivo de 3.2 MiB .

Suponiendo una relación lineal, esto sería aproximadamente 12.2 Bytes por punto de datos .

— AndreKR
fuente

ops-school.readthedocs.org/en/latest/monitoring_201.html (marca de tiempo, valor) los pares se almacenan como un valor largo y doble que consume 12 bytes por par. ¡La diferencia de 0.2 probablemente se deba a la sobrecarga de información de metadatos del archivo?

— user27465

1

No hay experiencia directa con Graphite, pero imagino la misma lógica que usamos para Cacti o cualquier otra cosa que se aplicaría RRD o impulsada por rollover de tiempo (Graphite ya no usa RRD internamente, pero la lógica de almacenamiento parece comparable).

La respuesta rápida es "Probablemente no tanto espacio como crees que necesitarás".

La respuesta larga implica algunas matemáticas específicas del sitio. Para nuestro sistema de monitoreo (InterMapper) calculo los períodos de retención, las resoluciones y el tamaño del punto de datos, hago algunas multiplicaciones y agrego sobrecarga.

Como ejemplo, usaré espacio en disco: almacenamos cifras con una precisión de 5 minutos durante 30 días, una precisión de 15 minutos por otros 60 días, y luego una precisión por hora durante otros 300 días, y estamos usando un 64 -bit (8 bytes) entero para almacenarlo:

21600 muestras en total, desglosadas como:
- 8640 muestras para la precisión de 30 días y 5 minutos
- 5760 muestras para la precisión de 60 días y 15 minutos
- 7200 muestras para la precisión de 300 días y 1 hora

Con 8 bytes por muestra, eso es aproximadamente 173 KB, más una sobrecarga saludable para la indexación de almacenamiento y similares lo lleva a aproximadamente 200 KB para los datos de uso del disco de una partición (cualquier error tiende a sobreestimar).

A partir de las métricas básicas, puedo calcular un tamaño promedio "por máquina" (10 particiones de disco, espacio de intercambio, RAM, promedio de carga, transferencia de red y algunas otras cosas): equivale a aproximadamente 5 MB por máquina.

También agrego un saludable 10% sobre el número final y redondeo, así que dimensiono las cosas a 6MB por máquina.

Luego miro los 1 TB de espacio que tengo para almacenar datos de métricas para gráficos y digo "Sí, ¡probablemente no me quede sin almacenamiento en mi vida a menos que crezcamos mucho!" :-)

— voretaq7
fuente

1

Para arrojar un número de la práctica real, con mis políticas de retención de producción (9 meses a 5 minutos; 1 año por hora; 5 años por día) y alrededor de 20 máquinas con ~ 20 métricas de 8 bytes cada una, más la advertencia / alarma / historial de eventos críticos / interrupciones durante 5 años Estoy usando 1.5G de espacio en disco. Eso es con InterMapper insertando todo en una base de datos Postgres. Así que de nuevo, la respuesta rápida es "Probablemente no tanto espacio como crees que necesitarás" :-)

— voretaq7

Sí, las matemáticas son sencillas, en realidad solo estoy mirando más sobre cómo Graphite almacena sus datos, puede hacer grandes diferencias a escala. Lo único que he encontrado es que, según los documentos, no es muy eficiente en cuanto al espacio (probablemente porque cuenta con rollups bastante agresivos).

— Kyle Brandt

Whisper (el back-end de almacenamiento que utiliza Graphite) tiene algunos elementos incorporados para masticar espacio; probablemente ya hayas visto esa página. La sección sobre "Períodos de tiempo de solapamiento de archivos" me llama la atención porque significa que los archivos son más grandes que mis ejemplos anteriores porque todos se remontan al principio del tiempo (el archivo de 60 días tiene en realidad 90 días; el archivo de 300 días es 390 días de duración). Whisper también mantiene una marca de tiempo (4 u 8 bytes) junto con cada punto de datos que también debe agregarse. No se ve, aunque complicado, simplemente hinchada :)

— voretaq7

0

Tengo 70 nodos que generan muchos datos. Usando Carbon / Whisper, un nodo creó 91k archivos solo (el nodo genera múltiples esquemas, cada uno con múltiples contadores y campos variables que deben ser seleccionables, por ejemplo: (nombre de nodo). (Esquema). (Contador). (Subcontador). (Etc. )....y así).

Esto proporcionó la granularidad que necesitaba para trazar cualquier gráfico que quisiera. Después de ejecutar el script para completar los 69 nodos restantes, tenía 1.3Tb de datos en el disco. Y eso es solo 6 horas de datos / nodo. Lo que me sorprende es que el archivo csv plano real para 6 horas de datos es de aproximadamente 230 Mb / nodo. 70 nodos son ~ 16 Gb de datos. Mi esquema de almacenamiento era 120s: 365d.

Soy relativamente nuevo en bases de datos, por lo que podría estar haciendo algo mal, pero supongo que es toda la sobrecarga para cada muestra.

Así que fue un experimento divertido, pero no creo que tenga sentido usar susurro para el tipo de datos que estoy almacenando. MongoDB parece una mejor solución, pero necesito descubrir cómo usarlo como un backend para Grafana.

— musca999
fuente