「EC2のCPU使用率といった一見Zabbixで監視できそうなリソースも、実は正確な値は取れていません。」という記述の真偽について
Xenのマネージャ階層ではとりあえずVM毎に割当CPU枠があって、Xenの仮想マシン側寄りの階層で、枠に対して一時的なバーストの許容やら連続バースト制限みたいなリミット操作があって…がCloudWatchの値
2015-04-22 16:43:08バーストの制限が加わったような場合にも「割当枠を減らす」みたいにクロックを下げるとかやると、VMへの影響が大きいから、ハイパーバイザのレベルで演算クロック分を横取りし(たように見せかけ)て制限する 中のOSにはそれがStealとして見えて…が、Zabbixエージェントで採れる値…
2015-04-22 16:48:08VM内ではStealで待たされているだけな時間で、Xenレベルでの物理演算リソースは消費してないんだけど、Xenマネージャとしては「割りつけた演算の消費」なわけで、CloudWatchの値は大きく見える傾向にある…
2015-04-22 16:54:53インストールに制限が無いのであれば、ぜひともZabbixエージェント入れて監視するべきだとは思う。やたらとStealが出るならEC2のインスタンスリミットに掛かってる可能性があるし、iowait高いならPIOPSなストレージ入れるべきかもだし…
2015-04-22 16:58:51クラスメソッドだから大丈夫とか、影響度あるとか、そういうのを鵜呑みにしちゃうくらいなら、いろんな文献を当たるしかないよね。サーバーワークスのブログでざびっくすおじさんが打ち消し報してもいいんだしさ。
2015-04-23 00:13:55Steal CPUとかI/O時間なんて、別にXenだろうがAWSだろうがVMwareだろうが、仮想化してたら一見不正確な値が返ってきちゃうのは原理的にそうだし、それはJP1/PFM使ってもITM使ってもZabbixでももとのOSが返す統計情報がずれてるから仕方ない。
2015-04-23 00:17:25CloudWatchだってVMwareだってHyper-Vだって、仮想化ハイパーバイザーのレイヤーで取ってる情報と、その中のゲストOSで見える情報には差があるし、どちらが正確という問題は論点がおかしい。ただ、AWSのEC2のサイジングという意味ではどっちも大事である。
2015-04-23 00:20:01ゲストOSの中のプロセスから見たらStealは使いたくても気づいたら居なくなってたCPU時間だし、その程度を把握して必要に応じてEC2インスタンスをStop→Startして具合のいいホストにするって運用も必要になるぜよ。見とかないと分からんけど。
2015-04-23 00:23:47@toshi__ya 同じ話が2chに書いてあっても信じなかったでしょうから、バイアスかかってるんだと思いますが、別にクロスレビューや推敲して外部公開してるわけじゃなさそうなので、用法用量を守ってお使いくださいなと。
2015-04-23 00:25:56