最近SystemAnswerG2（以下SAG2)ネタばかりですね、スイマセン。丁度色々アレコレとやっていまして[E:coldsweats01]
もうそろそろ一旦ネタが尽きるとは思うのですが、中々普通では分からないマニアックなお話をしきれていないな…と思いまして。
さて、SAG2ですが、監視系ソフトでは、オープンソースではZABBIXやらCactiやらMuninなどあり、商用系では・・・SAG2もそうですが、まぁ色々とあると思います。
そんな監視の世界での今回のネタは「サイレント障害検知・予兆検知」に機能をフォーカスしてみます。
私が知らないだけかもしれませんが、私の知る限りでは、「ベースライン」という考えはSAG2にしかなかったようなと思いますので、ちょっとどんなものかを。
どんな監視ソフトでもグラフは描いてくれるし、「しきい値」なんかも設定出来てアラートを出すことが出来るかと思います。
で、この「しきい値」機能ですが、監視ツールによって設定方法はマチマチだと思いますが、基本的には「上限設定と下限設定」、「注意・警戒・警告」かと思います。
しきい値で良く利用するのは、ディスクの容量とかCPUやメモリですかね・・・。他にもあるとは思いますが、大抵この手の考えで浮かぶのはパーセントでの計算かリソース容量MAXからの率計算ですかね・・・。CPUが60%超えたら注意とか、80%こえたら警告とか？そんな感じで。
では、ここでは例えですが、4時間毎に安定して１５刻みで増えていくものがあったとき・・・
例は、AWSの課金です。。。[E:coldsweats01] 幾らまでなら許可しようかな？という「しきい値」は設定出来ると思います。このグラフで・・・そうですねぇ・・・500ドルまで許可という「しきい値」は書けそうです。
そして、想定通り５００ドル到達するとずっと注意アラートが出っぱなしになっちゃいますね・・・どうしましょう。EC2を色々と止めて下げますかね。これはこれでOKですね。
でも、『その500ドルまでの日時の道のりはいつもの通りだったでしょうか。』
何時もだったらだいたい一カ月迎えるぐらいに500ドル行くはずなのが、15日ぐらいで500ドルを迎えてしまった場合・・・確かに検知出来ますが、どうして半月で「しきい値」にぶつかってしまったのか・・・その状態は正なのか誤なのか・・・すぐに分かるでしょうか？計画的に動いた結果早まった・・・だけなら良いのですが。
何が言いたいかと言うと、しきい値はあくまで、その時点で教えてくれるものなので、予兆検知としては少し後手になります。
そこで、予兆検知の精度を上げたり柔軟性を上げるのに使えるのが「ベースライン」です。
ベースラインでは、カレントとなる数値といつもの周期（パターン）での数値の学習値から何％前後の注意・警戒・警告の範囲としてアラートが出せる仕組みになっています。
グラフの例でいうと、最後のカレントが281.98を指していますが、この値から１０％前後の薄いボヤーンとした範囲ペイントされているかと思います。10%足すと、だいたい310ぐらいです。
つまり、いつもの値から１０％以上数値変動があったら警告するという仕組みになります。アベレージベースで学習されていくので、３１０ドルで検知して、状況変化の確認が行えます。500ドルまで待つ必要はありません。そして、計画通り500ドルに達したら、それはしきい値で警告してあげましょう。使いすぎだと言うのにはしきい値でお知らせする必要がありますが、予測外出費を未然に防ぐのにベースライン機能は使えそうですね。あくまで例ですが。
なので、急激なスパイクの発生は、確かにしきい値でも検知出来ますが、500ドル以下で、50ドルから急に300ドルなんていう変化のスパイクがあっても、しきい値では検知出来ません。これが「サイレント障害」という考えに繋がります。でもベースラインであればその変化を読み取って追従出来るわけですね。もっと言ってしまうと、先週との比較も学習させられるので、先週と違い過ぎるっていう検知にも使えます。
ただ、しきい値よりはチューニングは多少・・・頭を使って利用する事になります。
上図はデフォルトのベースラインの設定で、グラフに範囲表示されるのは「注意」の値の範囲となります。２５となっていますが、２５％です。なのでデフォルトのままだと・・・
上限がこのグラフだと360ドルあたりですかね。かなり見えずらいですが、計算された値は、BaseLineと書かれているこのグラフだと黄色の線があり、そこから基準で２５％となります。実際の数値から２５％ではない事に注意して下さい。
最初に使ったグラフは１０％にしていました。こんな感じで設定します。
極端な例で、１％設定です。１％設定だと、価格上昇時にはみ出てますね。この場合はアラートが上昇時に飛びます。そして、アラートは飛ぶのですが、1時間後にはその値が正常という範囲に入っています。これは学習不足の影響も出ていますが、ベースライン的には計算値に収まったから正常という判定になっているんですね。それが想定されているものかどうかで想定外であればチューニングによるベースラインのしきい値の設定を少し変えないと駄目ですね。
で、ここでベースラインの値の範囲に戻っていると思うのですが、ここから「乖離とリセット」の話になるので、それはまた今度。とりあえず、今回は簡単に考えましょう。
別のグラフも参考までに。
ZABBIXゲットで拾っているスレッド数ですが、起伏が激しいように見えます。
このグラフからだと、しきい値を６００ぐらいに入れておきたいっすね。
しきい値をいれるのはこんな感じで。
でもそれをベースラインでやると・・・
６００を狙うパーセントで入れていきます。
ベースラインの注意範囲が緩やかな波になっていますね。カレントの値ではなくて、計算されたベースラインの値からのパーセントの範囲になっているからです。なので６００ぐらい・・・ていう感じになります。
青丸の部分ではみ出ているので、これで検知します。これはスレッドのグラフですが、急にプロセス大量死亡とかの検知もベースラインだったら上手く使えそうですね。
このスレッド値もこのサーバーだからのスレッド値なので、別のサーバーだったらこの値ではないと思います。でもベースラインの場合はパーセント評価をしますので、しきい値で実数値を入れる場合と違って管理しやすい面も出てきます。無論、しきい値も取得している値によってはパーセントで出てくる値もあります。
しきい値だけじゃかゆい所に手が届かないって思っていた方は「ベースライン」を試してみてください。
ベースラインの苦手としている部分は、平日休日で負荷変動が大きな値の場合ですね。1週間で祝日が無ければハマるのですが、祝日は平日と被ってしまうので、平日と祝日差があるデータをベースライン評価をする場合はちょっと向いていません（ベースラインのしきい値の設定にもっと工夫が必要になります）。
そういえば、SystemAnsweG2が今年もINTEROPの「#show_net」に使われるようです。統計グラフ監視マニアとしては、色々な機械のデータを取って見られるのはチョーうらやましいです[E:happy02]
