sidetech

(元)インフラエンジニアの寄り道メモ。

Backbox exporterでレスポンス監視はIntervalで表現する(ぽい?)

以前の記事で、ICMP安定せーへんねん!って嘆いていたヤツ・・・

blog.sidetech.jp

これなんすけど。

回避方法というか、正攻法?こうしちゃえば?みたいなやり方やっとわかりました。

個人的にはモヤモヤ感はぬぐえていませんが。

とりあえず、正解?から。

f:id:hunter1014:20190930211121p:plain

グラフも少し賑やかになって、トラフィックの情報もでていますが、こちらはsnmp_exporterで取ったもの。本記事の主役は紫のグラフと緑・橙・赤タイルのやつです。

どうやらですね、”interval"というのを仕掛けると、その名の通り、インターバルで見て表示してくれるようでして。この時間軸はいま6時間のグラフを表示するようにしていますが、blackbox_exporterで取得した値(Duration second)を15秒のインターバールで表示してねという形にしています。

 

これを、表示時間軸を変更せずに、インターバルを変更すると・・・・

f:id:hunter1014:20190930211515p:plain

グラフの雰囲気がガラッと変わったと思います。10分のインターバルで計算してねとやってみた結果です。

もとより6時間という範囲でグラフの粒度が荒くなっているところで、分解能力のベースを15秒から10分に変更すると平均値が変わっていくのでこーなる訳っすね。

期待するグラフの形ではないですけど。

ただ、どちらのグラフには非はなく、それぞれに良い見え方はあります。

スパイクしている値が大きすぎると表示アベレージが変動しグラフのレンジも大きくなって、細かい部分が見えなくなるデメリットがありますが、インターバルを調整することで、界隈の平均値のブレを見つけやすくはなります。本来のブレ幅の平均値が見えてきやすいというか。

統計監視の難しい所は時間軸でグラフの雰囲気が変わってくるので、単純に見えているグラフを信用するわけにもいかず、ある程度ゴリゴリっとグラフのタイムレンジをいじらないと、直近で何が起きたのか客観的に判断するのが難しかったりしますよね。

 

で、設定ですが、

f:id:hunter1014:20190930212248p:plain

Min stepに$intervalのテンプレート変数を投入し、

f:id:hunter1014:20190930212416p:plain

テンプレート変数にインターバルとして使う時間の単位を投入します。

 

前回は、probe_duration_secondsに*1000をして単位をms表示できるようにアレンジしていましたが、

f:id:hunter1014:20190930212606p:plain

今回は、表示単位を"seconds(s)"を使って単位を調整しました。

 

今回の変更によって、変な0msのグラフを沢山書くことは無くなりました。インターバルでやっつけていますからね。なので逆に0msを表示させるのが困難になりそうですね。

するてっと、別の監視で死活をしたほうが良さそうです。そこで、ずっと静かに「OK」と表示されている子がいますね。

こちらは「probe_success」から値をとっています。なので0と1しか値がありません。

なので、死活はこれでやればいいでしょう。ちょっと味気ないけどね。。。メールにグラフが表示されているのがカッコイイのに・・・。

f:id:hunter1014:20190930213324p:plain

て、なってくると、やっぱり死活用ダッシュボードと分析用ダッシュボードは分けたほうがいいっていう話になりますね。

 

さて、1週間程度経って、Scrapeをほとんどが15秒でやってSNMPだけ30秒か1分かでやっていますが・・・約7GB食いました。

次の課題はここだな・・・。