sidetechスマートフォン用の表示で見るsidetechインフラエンジニアの寄り道メモ。RTX昨日のRTX1200のNATの数をSystemAnswerG2の統計グラフに取り込んで表示する方法をやりましたが、早速おいしいグラフ描画になりました。判りやすくするためにCPUとNATマスカレードカウントとそのインターフェースのトラフィックLAN2を並べてみました。Aのポイントですが、トラフィックとCPUの動きと、NATカウントに注目です。いった波形は大きなファイルをダウンロードまたはアップロードした時に現れます。この傾向はRTX1200まででRTX1210ではここまでハッキリとは判らないかと思います。CPU性能の兼ね合いと、どうやらYAMAHAルーターは「特定の挙動に対して弱い(負荷があがる)」ようなんですね。RTX系と纏めちゃってはいますが仕様がボチボチ違ったりするので、RTX1000からRTX1210まで、全て同じ条件での負荷を掛けても結果は違ってくると思います。全般的に今回のグラフの結果は特有の癖が出ている感じです。Bの区域も同様にパッと見はCPUとNATカウントのグラフが似た感じで推移していますが、実際にはちょっち違いますね。トラフィックとの波形とも噛み合いません。CPUの盛り上がりの原因はとりあえずNATセッション数に近い形で推移しているのが判りました。このグラフから言いたいのは、CPUとトラフィックだけしか見えない場合に、トラフィックの状況からしてCPUの波形は理解に苦しむと思います。巷ではRTXはショー○パケッ○に弱いとか言われていたりしますが・・・ま、それは置いておいて、CPUが仮に60%を超えてきた場合に、トラフィックが上図のような波形では説明が出来ないと思うんですよね。何が原因でCPU負荷が上がっているのかをCPUとトラフィックだけでは表現が出来ないのです。データの形態によってCPUが瞬間上昇している訳ですから、このデータ特性が大量に飛び込んで来たらCPUは悲鳴を上げるでしょう。そのデータ特性をどうやって見抜くかはやはりNATセッション情報があると初期判断材料としては少しだけ読みやすくなりますね。これはまた別の角度のデータが必要なのですが、DNSクエリーの増加がまずあります。とあるクラウド製品を使うと1台あたりのセッション数が3倍から5倍になるというぐらいですからね~。昔なら間違いなくウィルスが発病した時の傾向グラフでしたね[E:coldsweats02]。あとですね、インターネット回線側によってのセッション数ってのもはあったりしますんで・・・そこの話はいずれ。グラフを見てもふんづまりが判らないなぁ・・・となってくると・・・RTXで見なくちゃならないのが、以下のコマンドです。length(割愛)あらーら・・・パケロスしてますね。いつパケロスしたんだろ(激汗)。量的には大した数ではないと言いたいけど、気になるよねぇ~。ここの値もSNMPで見られないのかなぁ・・・。いうことで今回はちょっとコッテリした内容かもしれませんがご参考になれば。Tumblr関連記事2015-06-28SNMPから~の~Merakiで仕留める先日、いやーなものをSNMPで発見してしまいましたね。はてなブログPro仕事時々趣味ぐらいのブログです。exporterでレスポンス監視はIntervalで表現する(ぽい?)WindowsでPrometheus&Grafanaのまとめ。)月別アーカイブリンクプライバシーポリシースターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。