cálculo de dias até o disco ficar cheio

Usamos grafite para rastrear o histórico de utilização do disco ao longo do tempo. Nosso sistema de alerta examina os dados da grafite para nos alertar quando o espaço livre cai abaixo de um determinado número de blocos.

Gostaria de receber alertas mais inteligentes - o que realmente me interessa é "quanto tempo tenho antes de fazer algo sobre o espaço livre?", Por exemplo, se a tendência mostrar que em 7 dias ficarei sem disco espaço, em seguida, levante um aviso; se for menos de 2 dias, levante um erro.

A interface de painel padrão do Graphite pode ser bastante inteligente com derivativos e faixas 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 maneiras (basta extrair os números brutos da grafite e executar um script para fazer isso).

Uma complicação é que o gráfico não é tranquilo - os arquivos são adicionados e removidos, mas a tendência geral ao longo do tempo é que o uso do espaço em disco aumente; portanto, talvez seja necessário examinar as mínimas locais (se observar a métrica "sem disco") ) e desenhe uma tendência entre as cavidades.

Alguém já fez isso?

Honestamente, "Dias até o preenchimento" é realmente uma péssima métrica - os sistemas de arquivos ficam MUITO ESTÚPIDOS à medida que se aproximam de 100% da utilização.
Eu realmente recomendo usar os limites tradicionais de 85%, 90%, 95% (aviso, alarme e crítico, você realmente precisa corrigir esse NOW, respectivamente) - isso deve fornecer muito tempo de aviso em discos modernos (digamos, uma unidade de 1 TB: 85% de um terabyte ainda deixa muito espaço, mas você está ciente de um problema em potencial; em 90% você deve planejar uma expansão de disco ou alguma outra mitigação e a 95% de um terabyte você tem 50 GB restantes e deve muito bem ter uma correção em movimento).

Isso também garante que seu sistema de arquivos funcione de maneira mais ou menos otimizada: possui bastante espaço livre para lidar com a criação / modificação / movimentação de arquivos grandes.

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

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

Por uma questão de sanidade, você pode usar o derivado do Graphite (que fornecerá a taxa de alteração ao longo do tempo) e projetá-lo, mas se você REALMENTE quiser alertas "mais inteligentes", sugiro usar a taxa de alteração diária e semanal (calculada com base no pico de uso do dia / semana).

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

Por fim, nenhum algoritmo será muito bom para fazer o tipo de cálculo que você deseja. A utilização do 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 executarão um despejo de memória do sistema completo para seus diretório inicial. Só porque.

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

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

Como esses crescimentos são muito previsíveis, podemos realizar uma regressão linear na utilização do disco (por exemplo, z = numpy.polyfit(times, utilization, 1)) e depois calcular a marca de 100%, dado o modelo linear (por exemplo, (100 - z[1]) / z[0])

A implementação implantada se parece com isso usando ruby ​​e GSL, embora o numpy funcione muito bem também.

A alimentação desses dados médios de utilização de uma semana em intervalos de 90 minutos (112 pontos) conseguiu identificar possíveis candidatos à exaustão do disco sem muito barulho até agora.

A classe na essência é agrupada em uma classe que extrai dados do explorador, alerta para folga e envia alguma telemetria de tempo de execução para o statsd. Vou deixar isso de fora, pois é específico da nossa infraestrutura.