ディスクがいっぱいになるまでの日数の計算

グラファイトを使用して、ディスク使用率の履歴を経時的に追跡します。アラートシステムは、グラファイトのデータを調べて、空き容量が特定のブロック数を下回ったときにアラートを出します。

よりスマートなアラートを取得したい-私が本当に気にかけているのは、「空き領域について何かをしなければならない前にどれくらいの時間が必要か」ということです。たとえば、トレンドが7日間でディスクがなくなるスペースは警告を発生させ、2日未満の場合はエラーを発生させます。

グラファイトの標準ダッシュボードインターフェイスは、デリバティブとHolt Winters Confidenceバンドでかなりスマートにできますが、これまでのところ、これを実用的なメトリックに変換する方法を見つけていません。他の方法で数値をクランチすることにも問題はありません（グラファイトから生の数値を抽出し、それを実行するスクリプトを実行するだけです）。

複雑な点の1つは、グラフが滑らかではないことです。ファイルは追加および削除されますが、時間の経過に伴う一般的な傾向として、ディスク領域の使用量が増加するため、おそらくローカルミニマム（「ディスク空き」メトリックを参照する場合）を調べる必要があります。 ）そして、谷間のトレ​​ンドを描きます。

誰かこれをやったことがありますか？

正直なところ、「満杯になるまでの日数」はとにかく本当にひどい指標です。ファイルシステムは、100％の使用率に近づくと、本当に愚かになります。
従来の85％、90％、95％のしきい値を使用することをお勧めします（それぞれ警告、アラーム、重大な修正が必要です）-これにより、最新のディスクで多くの警告時間が表示されます。 （1TBドライブとしましょう：テラバイトの85％はまだ多くのスペースを残していますが、潜在的な問題を認識しています。90％はディスク拡張または他の緩和策を計画している必要があり、テラバイトの95％です。 50GBが残っているので、修正が必要です。

これにより、ファイルシステムが多かれ少なかれ最適に機能することも保証されます。大きなファイルの作成/変更/移動を処理するための十分な空き領域があります。

最新のディスクでない場合（または使用パターンにディスクに大量のデータが投入される場合）、しきい値を簡単に調整できます。

それでも「完全な日数」メトリックを使用するように設定されている場合は、グラファイトからデータを抽出して、いくつかの計算を行うことができます。 IBMの監視ツールは、完全なメトリックまで数日間実装します。これにより、実装方法のアイデアが得られますが、基本的には、履歴の2つのポイント間の変化率をとっています。

あなたの正気のために、グラファイトの派生物を使用することができます（これにより、時間の経過に伴う変化率が得られます）が、実際に「よりスマートな」アラートが必要な場合は、毎日および毎週の変化率（計算された）を使用することをお勧めします日/週のピーク使用量に基づく）。

使用する特定の予測（最小の変化率、最大の変化率、平均の変化率、加重平均など）は、環境によって異なります。IBMのツールは、1つのサイズですべてに対応するパターンを特定することが非常に難しいため、非常に多くの異なるビューを提供します。

結局のところ、希望する種類の計算を行うのに優れたアルゴリズムはありません。ディスクの使用率はユーザーによって決定され、ユーザーはRational Actorモデルの正反対です。1人のクレイジーな人が今日すべてがシステムメモリダンプを実行する日であると決定すると、すべての予測が枠を超えてしまう可能性があります。ホームディレクトリ。ただ。

最近、線形回帰を使用して、このためのカスタムソリューションを公開しました。

私たちのシステムでは、ディスクが使い尽くされる主な原因は、ローテーションされていないログファイルです。

これらは非常に予想どおりに成長するため、我々は、ディスク使用率（例えば、上の線形回帰を実行することができますz = numpy.polyfit(times, utilization, 1)）その後、線形モデル（例えば、与えられた100％のマークを計算(100 - z[1]) / z[0]）

デプロイされた実装は、rubyとGSLを使用するとこのようになりますが、numpyも非常にうまく機能します。

これに1週間分の平均使用率データを90分間隔（112ポイント）で供給することで、これまであまりノイズを発生させることなく、ディスク枯渇の可能性の高い候補を見つけることができました。

要点のクラスは、スカウトからデータをプルし、スラックを警告し、ランタイムテレメトリをstatsdに送信するクラスにラップされています。それは私たちのインフラストラクチャに固有のものであるため、ここでは省略します。