Windows Azure をSCOMで管理しよう、の第4回です。（ その1・その2・その3）

さて前回から間が空いてしまいました。
というのも Windows Azure 用管理パックが一時公開停止になってたからなんですが。。。
で、理由はわかりませんが、やっと今日再公開（但しRCとして）されたので、続きをやってみようと思います。

管理パックに関する詳細はこちら。管理パックそのものはこちらからダウンロードできます。（一応RTWは2011年上半期の予定のようですね…）
ちなみにダウンロードして以前のと比較したところ、ドキュメントと管理パックのファイルはまったく同じでした。
EULAが今回公開された分はしっかりと記載されていたので、そのあたりが理由じゃないかなと勘繰ったり…

…余談が長くなりました。では気を取り直して続きをば。

前回までで一応SCOMで監視できるようになってるはずですので、今回はログを吐いたりする Windows Azure アプリケーションをデプロイして、実際にパフォーマンスの監視をしてみたいと思います。

Windows Azure 側の準備

Windows Azure のアプリケーションログやパフォーマンスログは、そのままだと出力しても各ロールのローカル上にしか保存されません。
ですのでいったん Windows Azure Storage 上に転送してあげる必要があります。（SCOMで監視する際もこの設定が必要です）

ということで、まずは Windows Azure Storage を作成します。

赤枠で囲んだアカウント名とキーは後で必要になるのでメモっておきましょう。

Windows Azure アプリケーションの準備

サンプルとして今回は ASP.NET MVC な Web Role を作成します。

ただ単にデフォルトのページを表示させてもあまり面白くありませんので、適度に負荷がかかるようにしたいと思います。

今回は0から50万までの素数を出力させるようにしてみました。
結果はこんな感じ。

まぁサンプルだからこんな感じでいいですね。だいたい結果が返ってくるまで40秒ほどCPUを適度に使ってくれます。

次はログを出力するようにロールを構成する必要があります。

ASP.NET MVCプロジェクトの WebRole.cs 内に OnStart メソッドがありますので、そちらにログ出力の有効化とストレージへの転送を設定するコードを追記します。

public override bool OnStart()
{

    var config = DiagnosticMonitor.GetDefaultInitialConfiguration();

    //イベントログの設定と転送
    config.WindowsEventLog.DataSources.Add("Application!*");
    config.WindowsEventLog.DataSources.Add("System!*");
    config.WindowsEventLog.ScheduledTransferLogLevelFilter = LogLevel.Verbose;
    config.WindowsEventLog.ScheduledTransferPeriod = TimeSpan.FromMinutes(1);
   
    //パフォーマンスカウンタの設定と転送
    config.PerformanceCounters.DataSources.Add(
        new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Processor(_Total)\% Processor Time",
            SampleRate = TimeSpan.FromSeconds(1)
        });
    config.PerformanceCounters.DataSources.Add(
        new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\ASP.NET Applications(*)\Requests/Sec",
            SampleRate = TimeSpan.FromSeconds(1)
        });
    config.PerformanceCounters.DataSources.Add(
        new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Memory\Available MBytes",
            SampleRate = TimeSpan.FromSeconds(1)
        });
    config.PerformanceCounters.DataSources.Add(
        new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Network Interface(*)\Bytes Sent/sec",
            SampleRate = TimeSpan.FromSeconds(1)
        });
    config.PerformanceCounters.ScheduledTransferPeriod = TimeSpan.FromMinutes(1);

    //診断ログの設定と転送
    config.DiagnosticInfrastructureLogs.ScheduledTransferLogLevelFilter = LogLevel.Verbose;
    config.DiagnosticInfrastructureLogs.ScheduledTransferPeriod = TimeSpan.FromMinutes(1);

    //IISログの転送
    config.Directories.ScheduledTransferPeriod = TimeSpan.FromMinutes(1);

    //Windows Azureログの設定と転送
    config.Logs.ScheduledTransferLogLevelFilter = LogLevel.Verbose;
    config.Logs.ScheduledTransferPeriod = TimeSpan.FromMinutes(1);

    //診断モニタの有効化
    DiagnosticMonitor.Start("DiagnosticsConnectionString", config);

    RoleEnvironment.Changing += RoleEnvironmentChanging;

    return base.OnStart();
}

最後に、 ServiceConfiguration.cscfg ファイル内に出力先の接続文字列がありますので、既定の開発ストレージから先ほど作成した Windows Azure Storage の情報に変更します。

<Setting name="DiagnosticsConnectionString" value="DefaultEndpointsProtocol=https;AccountName=アカウント名;AccountKey=キー" />

以上で修正は完了です。
ビルド後、 Windows Azure へデプロイしましょう。

パフォーマンスのモニタリング

正常にデプロイされたら、アプリケーションを適当に実行させます。
SCOMではリアルタイムではありませんが（ Windows Azure Storage へすぐに転送されないので）パフォーマンスカウンタを見ることができます。

パフォーマンスカウンタは、おそらく Windows Server 上で参照できるものはだいたい指定できそうです。（どのカウンタを表示させるか、もSCOM上で設定することができます）

ここまで出来れば、SCOMを活用して閾値を超えたらインスタンスを増やすとかアラートを上げるといったことも可能になるんじゃないかなと思います。

ITProでSCOMerな方は是非活用して頂ければと思います。

ということで、このシリーズはいったん完了。なんとか終わってヨカッタヨカッタ。

おまけ。

やっとまともに監視されるようになりました。（自分ところのネットワークの問題だったので）