ほわいとぼーど

ぷろぐらまのメモ帳

Mackerelで予測する的な話を試したり発展させたりする

mackerel

『年末年始のディスク容量アラートを回帰分析で回避しよう』という最高の記事が公開されたので試してみました。また、追加で自分が試してみたいことを試してみた話。

経緯

MackerelでAlertが出たらSlackの特定チャンネルにメンションするという運用にしているのですが、
DiskやMemoryのAlertはショボい理由*1で発生することも多く
サーバ数が増えるに従って頻度も増えるし手が回らなくなってきたのでどうにかしたい、
予測みたいなことで対処できないかと思っていました。

そこでid:stanakaさんの記事を試してみたり、
応用例について考えてみたという内容になります。

用意

自分のような人間にはだいたい準備が大変です。
仕事の環境(AWS/Amazon Linux)を意識してCentOS6で環境を作ったので、
Ubuntuならあるいはもっと楽に出来るかも知れませんん。
欲張って慣れないpyenv-virtualenv環境でやったのもハマリポイントでした。

とりあえず雑にVagrantfile作りました。
Vagrantだとグラフは見れないけど予測プログラム試すだけならコレで出来るはず。*2

実行

id:stanakaさんのプログラムをコピーして実行してみます

$ export MACKEREL_APIKEY="(your own mackerel key)"
$ python mackerel_estimate_filesystem_lifetime.py
INFO:__main__:fetching ip-xxx-xxx-xxx-xxx (1/xxx)
INFO:__main__:fetching ip-xxx-xxx-xxx-xxx (2/xxx)
...
...
ip-xxx-xxx-xxx-xxx:xvda1, size: 277.73 GB/422.62 GB, full in 12d21h21m35.429102s
ip-xxx-xxx-xxx-xxx:xvda1, size: 4.46 GB/8.32 GB, full in 17d22h39m20.554903s
...
...

こんな感じでDiskFullまでの時間が短いものから表示されます。
あくまで予測ですが候補が提示されるのは非常に助かります。
何日か連続でチェックすれば変動に幅があるものもケアできるでしょう。
毎日1回とか仕込もうかなとか画策中です。

metricsを収集する範囲は1週間で利用してます。

(APIの叩く頻度は数秒に1回程度にご配慮ください)

とのことなので、API実行後に time.sleep(2.0) とかして実行してます。

Memoryでも試してみました。
他のmetricもいい感じに確認できるようになるといいですね。

とりあえずこれで長期的な予測はしやすくなりました。
デプロイ前後の挙動変更とか元々使用量が高い場合とかいくつか難しい課題はあるのですが、
こういった手段の枠組みが提供されたことは喜ばしいことです。
更に
『もう少しすると、今までの傾向を分析して予測に基づいた監視が出来るようになりそうなので、ぜひご期待ください！』
(Mackerelが大切にしているエンジニアを”ワクワク”させることについて)
とあるので期待せざるをえません！

応用例

もう1つ出来たらいいなと思っていたことがあって、
それは閾値を超えたら緊急度を判定して通知してくれないか、というもの。
WARNING Alertをトリガーに分析した結果を通知する方向で考えてみました。

方法

流れとしては、

  • Alert APIでAlertを定期的に取得する
  • 未処理のDisk WARNING Alertを判定
  • 短時間のmetrics値を元に前出の分析を実行
  • 結果(DiskFullに到達するまでの時間)が一定の値よりも短い場合はSlackメンションする

分析には前出のプログラムを流用します。
プログラムは適当にcronで監視させます。

f:id:a3no:20151227213921p:plain

こんな感じでDisk使用量が増加すると、

f:id:a3no:20151227213931p:plain

Alert出現時に分析も行って結果を表示して、寿命が短い場合はメンションも実施します。

逆に寿命に猶予がある場合にはメンションしないようにします。
MAXまで1日以上かかるような場合は平日であればメンションせずとも対応可能なのではないでしょうか。

試したコードはサンプルとして貼っておきます。
https://gist.github.com/ki38sato/7f2b1a81423a55a0bbef
分析期間やAlert判定閾値は適当です。

チューニングはまだまだこれから*3、場合によって分析方法も、、ですが、
こういった仕組みを用意することで分析の得意な人に改善してもらえる土壌ができます。(他人任せ)

以上、Mackerelで予測したりする話でした。

補足

filesystemを分析するスクリプトをVagrant VMに対して試す場合は注意が必要です。 /dev/mapper/VolGroup-lv_root がMackerelサーバでは mapper_VolGroup-lv_root に変換されています。

*1:ちょっとしたエラーを放置してログが溢れるとかリークを放置するとか

*2:ただし初回起動に1時間くらいかかる気がする　Docker欲しい案件

*3:ddでファイル作って試しましたが傾きを調整できずなかなか、、、