calculando dias até que o disco esteja cheio

Question

Usamos grafite para rastrear o histórico de utilização de disco ao longo do tempo. Nosso sistema de alertas analisa os dados do grafite para nos alertar quando o espaço livre fica abaixo de um certo número de blocos.

Gostaria de receber alertas mais inteligentes - o que realmente me importa é "quanto tempo tenho antes de fazer algo sobre o espaço livre?" Se a tendência mostra que em 7 dias eu vou ficar sem espaço em disco, em seguida, levante um aviso, se for menos de 2 dias, em seguida, levante um erro.

A interface de painel padrão do Graphite pode ser bastante inteligente com derivativos e bandas de Confiança de Holt Winters, mas até agora não encontrei uma maneira de converter isso em métricas acionáveis. Também estou bem em analisar os números de outras formas (apenas extraia os números brutos do grafite e execute um script para fazer isso).

Uma complicação é que o gráfico não é suave - os arquivos são adicionados e removidos, mas a tendência geral ao longo do tempo é de que o uso do espaço em disco aumente, então talvez seja necessário observar os mínimos locais (se observar o "disco") livre "métrica) e traçar uma tendência entre os vales.

Alguém já fez isso?

    

Answer 1

Honestamente, "Days Until Full" é realmente uma péssima métrica - os sistemas de arquivos ficam REALMENTE ESTÚPIDOS à medida que se aproximam de 100% de utilização.
Eu realmente recomendo usar os 85%, 90% e 95% de limites tradicionais (aviso, alarme e crítico que você realmente precisa corrigir-este-AGORA, respectivamente) - isso deve lhe dar muito tempo de aviso em discos modernos (digamos que uma unidade de 1 TB: 85% de um terabyte ainda te deixa muito espaço, mas você está ciente de um possível problema, em 90% você deve estar planejando uma expansão de disco ou alguma outra atenuação, e em 95% de um terabyte você tem 50 GB sobrando e deve ter uma correção em movimento).

Isso também garante que o sistema de arquivos funcione mais ou menos de forma ideal: ele tem muito espaço livre para lidar com a criação / modificação / movimentação de arquivos grandes.

Se os seus discos não forem modernos (ou o seu padrão de uso envolver maiores quantidades de dados sendo lançados no disco), você poderá ajustar facilmente os limites.

Se você ainda usa uma métrica de "dias até o total", pode extrair os dados do grafite e fazer algumas contas nele. As ferramentas de monitoramento da IBM implementam vários Métricas de dias até o final , que podem lhe dar uma idéia de como implementá-lo, mas basicamente você está considerando a taxa de mudança entre dois pontos no histórico.

Para o bem da sua sanidade você poderia usar a derivada do Graphite (que lhe dará a taxa de mudança ao longo do tempo) e projetar usando isso, mas se você realmente quiser alertas "mais inteligentes" eu sugiro usar taxa diária e semanal de mudança (calculada com base no uso de pico para o dia / semana).

A projeção específica que você usa (menor taxa de mudança, maior taxa de variação, taxa média de mudança, média ponderada, etc ....) depende do seu ambiente. As ferramentas da IBM oferecem muitas visões diferentes porque é realmente difícil encontrar um padrão único para todos.

Em última análise, nenhum algoritmo vai ser muito bom em fazer o tipo de cálculo que você deseja. A utilização de disco é conduzida pelos usuários, e os usuários são a antítese do modelo do Rational Actor: todas as suas previsões podem sair pela janela com uma pessoa maluca decidindo que hoje é o dia em que realizarão um despejo de memória do sistema completo diretório inicial. Só porque.

    

Answer 2

Recentemente, lançamos uma solução personalizada para isso usando a regressão linear.

Em nosso sistema, a principal fonte de esgotamento de disco são arquivos de log dispersos que não estão sendo rotacionados.

Como estes crescem muito previsivelmente, podemos realizar uma regressão linear na utilização do disco (por exemplo, z = numpy.polyfit(times, utilization, 1) ) e, em seguida, calcular a marca de 100% dado o modelo linear (por exemplo, (100 - z[1]) / z[0] )

A implementação implementada parece esta usando ruby e GSL, embora a numpy funcione muito bem também.

Alimentar isso uma semana de dados de utilização média em intervalos de 90 minutos (112 pontos) foi capaz de escolher candidatos prováveis para exaustão de disco sem muito barulho até agora.

A classe no gist é empacotada em uma classe que extrai dados do scout, alerta para o slack e envia alguma telemetria de tempo de execução para o statsd. Vou deixar isso fora, já que é específico da nossa infraestrutura.