calcular días hasta que el disco esté lleno

Usamos grafito para rastrear el historial de utilización del disco a lo largo del tiempo. Nuestro sistema de alerta analiza los datos del grafito para alertarnos cuando el espacio libre cae por debajo de un cierto número de bloques.

Me gustaría recibir alertas más inteligentes: lo que realmente me importa es "¿cuánto tiempo tengo antes de tener que hacer algo sobre el espacio libre?", Por ejemplo, si la tendencia muestra que en 7 días me quedaré sin disco espacio, luego genera una Advertencia, si son menos de 2 días, genera un Error.

La interfaz de tablero estándar de Graphite puede ser bastante inteligente con derivados y bandas de confianza de Holt Winters, pero hasta ahora no he encontrado una manera de convertir esto en métricas accionables. También estoy de acuerdo con agrupar los números de otras maneras (solo extraiga los números sin procesar del grafito y ejecute un script para hacerlo).

Una complicación es que el gráfico no es uniforme: los archivos se agregan y eliminan, pero la tendencia general a lo largo del tiempo es que aumente el uso del espacio en disco, por lo que tal vez sea necesario observar los mínimos locales (si se observa la métrica "sin disco" ) y dibuja una tendencia entre los canales.

¿Alguien ha hecho esto?

Sinceramente, "Days Before Full" es realmente una métrica pésima de todos modos: los sistemas de archivos se vuelven REALMENTE ESTÚPIDOS a medida que se acercan al 100% de utilización.
Realmente recomiendo usar los umbrales tradicionales de 85%, 90%, 95% (advertencia, alarma y crítico que realmente necesita arreglar esto AHORA, respectivamente), esto debería darle mucho tiempo de advertencia en los discos modernos (supongamos que una unidad de 1 TB: el 85% de un terabyte todavía te deja mucho espacio, pero eres consciente de un problema potencial, en un 90% deberías estar planeando una expansión de disco u otra mitigación, y al 95% de un terabyte te quedan 50 GB y deberías tener una solución en movimiento).

Esto también garantiza que su sistema de archivos funcione de manera más o menos óptima: tiene mucho espacio libre para crear / modificar / mover archivos grandes.

Si sus discos no son modernos (o su patrón de uso implica que se arrojen grandes cantidades de datos al disco), puede ajustar fácilmente los umbrales.

Si todavía está configurado para usar una métrica de "días hasta que esté completa", puede extraer los datos del grafito y hacer algunos cálculos matemáticos. Las herramientas de monitoreo de IBM implementan métricas de varios días hasta que están completas, lo que puede darle una idea de cómo implementarlo, pero básicamente está tomando la tasa de cambio entre dos puntos en la historia.

En aras de su cordura, podría usar la derivada de Graphite (que le dará la tasa de cambio a lo largo del tiempo) y proyectar usando eso, pero si REALMENTE desea alertas "más inteligentes", sugiero usar una tasa de cambio diaria y semanal (calculada basado en el uso pico para el día / semana).

La proyección específica que utiliza (tasa de cambio más pequeña, tasa de cambio más grande, tasa de cambio promedio, promedio ponderado, etc.) depende de su entorno. Las herramientas de IBM ofrecen tantas vistas diferentes porque es realmente difícil definir un patrón único para todos.

En definitiva, ningún algoritmo será muy bueno para hacer el tipo de cálculo que desea. La utilización del disco está impulsada por los usuarios, y los usuarios son la antítesis del modelo de Rational Actor: todas sus predicciones pueden salir por la ventana con una persona loca que decide que hoy es el día en que realizarán un volcado de memoria del sistema completo en su directorio de inicio Simplemente porque.

Recientemente hemos implementado una solución personalizada para esto mediante regresión lineal.

En nuestro sistema, la fuente principal de agotamiento del disco son los archivos de registro extraviados que no se rotan.

Dado que estos crecen de manera muy predecible, podemos realizar una regresión lineal en la utilización del disco (por ejemplo, z = numpy.polyfit(times, utilization, 1)) y luego calcular la marca del 100% dado el modelo lineal (por ejemplo, (100 - z[1]) / z[0])

Las miradas de implementación desplegados como esta usando rubí y GSL, aunque las obras numpy bastante bien también.

Alimentar los datos de utilización promedio de esta semana en intervalos de 90 minutos (112 puntos) ha sido capaz de elegir posibles candidatos para el agotamiento del disco sin demasiado ruido hasta ahora.

La clase en la esencia está envuelta en una clase que extrae datos del explorador, alerta sobre la holgura y envía algo de telemetría de tiempo de ejecución a statsd. Dejaré ese bit afuera ya que es específico de nuestra infraestructura.