2014/01お楽しみはこれからだ!2014年1月31日金曜日サーバーの監視を楽しむ結構前から、サーバー監視は自分で作ったものでやってたんです。好きなように表示したいし、欲しい項目も業務に依存したものもあるし。既存のツールを調べて使いこなす(そういうの得意じゃないっていうのもありますが)のも、どうかなー、と思って。今は黒背景にしてるけど、気分で白にしたり、クリスマスバージョンにしたり。これをオフィスに大きなテレビに出してるんですよね。もとになるデータをどうやって取得するのか、っていうのがいろいろなんですよ。DBから業務データを集計したものだったり、単純にサーバーのCPUとかメモリとかだったり、サイトごとのリクエスト数、コネクション数とか。データセンターのスイッチのトラフィックとかもね。エージェントベースのものでいけるのもあるし、それだと面倒だからWMIでとったり、SQLだったりさー。Agentでのアプリケーションプロファイルは極悪なほどパフォーマンスが悪くなるので、テストの時だけね。あれ、常時運用で仕掛けてるひといるのかな。お金がたんまりあってはサーバーたくさんでハニーポット的に一部のサーバーだけロードバランさの割り当て率下げて、とかならやれなくはないかもだけどー。マルチテナントきりきりだとちょっとなー、と思うんす。ないの?で、いろんなところから取得したデータをMongoDBに入れて、画面に出すときには、MongoDBからとってきて表示。MVCアプリでjqPlotでレンダリング。取得と保持と表示を分けてるのは、まぁ、ね。とりたいし、いろいろ出したいのと、取得したものをそのままの精度で保持しときたいから。MongoDBはしょぼいサーバーで動かしてるけど、がんばってくれるんす。ちなみにこれとは別のMongoDBクラスタでトレース情報はとってるけど、そっちはアプリケーションログなんで、また別のモニターに出たりしてて。そっちはそっちで重要だけど、なんか、あんまり楽しくない。して、監視っていうのが需要の少ないものなのかもしれないけど、どうなんでしょうね。WMIで対象データを抽出する場合は、WMIで取得したい項目もクラス名調べたりいろいろ面倒だけど、抽出自体はとても簡単で、コンソールからwmicっていうの取得するか、コードでSystem.Managementのクラス使ってちょこちょこ取得。これのいい点は対象サーバーのCPUをほとんど使わないところ。必要なものだけしかとらないしね。辛い点は外部からの監視だから対象サーバーに到達しないとか、忙しくて無視されるとちゃんととれないところ。そのときは前後の状態から人が目で見て判断できることがほとんどだから、そんなに気にしない。気になる人には向いてないですね。(Name="_Total")って、書くと取れますね(localhostならnodeは指定しなくてもいいです)。ほかの項目もこの容量でなんでもとれるけど、プロセス起動になるので、対象サーバーが多いとちょっと辛いかも。テキストでとれるので適当にパースしましょう。とりたいフィールド名は指定できるので、必要ない項目は無視で。System.Managementなら、↓こんな感じで。ダメなら無視Debug.WriteLine(ex.Message);}}雰囲気ね。一度PING飛ばしてちゃんとレスポンスがあるのかどうか確認してるのはManagementObjectSearchはTimeoutを検出しないからデス。これだと、Taskで複数一度に回せて意外とさらさらー、って取り出せます。続いて、ネットワーク機器の監視にみんな使ってるであろうMRTG。SNMP到達しない機器だろうと、MRTGは見れる、なんていう構成、ありますよね。