Go to Qiita Advent Calendar Top
LoginSignup
37
32

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

@shingo_kawahara(Shingo Kawahara)in株式会社セゾンテクノロジー

AzureサービスだけでIaaSをどこまで監視できるか試してみた

Posted at

JP1/System Walker/Datadog/Mackerelといった監視エージェント。とても便利ですよね。

でもAzureにも監視サービスがいくつもあります。

そこで、AzureのサービスだけでIaaS(Virtual Machines)をどこまで監視できるかを試して、監視エージェントが必要なケースを纏めてみました。

監視したいものは何か？

はじめに対象を定義しておきます。

  • 対象OS
    Windows/Linux問わないこととしますが、この記事ではWindows Serverをベースに解説しています。値は違いますが、基本的にはLinuxにも適応可能だと思って下さい。
  • 監視したいもの
    • CPU使用率やメモリ使用率等の各種パフォーマンス情報
    • イベントログ(syslog)
    • サービス(プロセス)

最終的な構成図

image.png

Azureオンリーで監視しようとした場合の私的最適構成案がこれです。
なぜこういう構成なのかと、実現するための手順を解説していきたいと思います。

細かく解説

まずはここのラインから

image.png

メトリック

IaaSであれPaaSであれ、Azureではパフォーマンスと正常性を視覚的に確認できるメトリックが標準で準備されています。CPU使用率とかネットワークI/Oとかの数値データですね。
メトリックは1分間隔で取得されます。

ホストVMメトリック

  • [メトリック]→[メトリック値]の順に選択します
  • ここでは[ホスト]Percentage CPUを選択してみます
    image.png

  • 以下のような感じでCPU使用率が表示されました
    image.png

  • 過去24時間のCPU使用率が表示されていますが、最大で30日間のメトリックを確認することが可能です。

ゲストVMメトリック

  • デフォルトだと以下の項目に対するメトリックを確認することができます
    image.png

  • なんだか少ない気がします。例えばメモリ使用率とかディスク空き容量とかを確認したい場合はどうすればよいのでしょうか

  • [ホスト]と表示されていることがポイントで、仮想マシンをデフォルトで作成した直後だと、ゲストOS側からパフォーマンス情報を取得しておらず、Azureホストからのみ取得している状態です

  • ゲストレベルの診断を有効にすることで、OSのパフォーマンスモニター情報を取得することができます

  • ゲストOSのパフォーマンス情報まで取得するためには、[診断設定]を選択します
    image.png


  • [ゲストレベルの監視を有効にする]を選択します
    image.png

  • しばらく待つと以下のようにパフォーマンスモニターの情報を確認することができます
    image.png

  • ちなみにゲストレベルの監視は、仮想マシン作成時に設定することも可能です
  • 作成時に[ゲストOSの診断]項目を、[有効]にすることでゲストOS診断を有効にした状態で仮想マシンを作成できます
    image.png

ゲストVMメトリック確認

  • 項目を見ると分かるようにWindowsのパフォーマンスモニター値がそのまま表示されています
    image.png

  • ディスク空き容量を見てみます。以下は過去1時間のディスク空き容量のメトリックです
    image.png

  • ちなみに実態はVirtual Machines拡張機能「IaaSDiagnostics」が追加されたことで、ゲストOSのパフォーマンスモニタ情報を取得できるようになりました
    image.png

アラート

ここまでで細かいリソースのパフォーマンスを可視化することができました。
次は閾値を超えた場合のアラート通知についてです。

メトリックアラート

  • アラート画面から[メトリックアラートの追加]を選択します
    image.png

  • 監視対象メトリックと閾値、期間を設定します
  • この例では、5分以上、CPU使用率が90%より大きくなった状態が続いた場合にアラートとして検知します
    image.png

  • 次にアラートを検知した場合の通知手段を選んでいきます
    image.png

  • 通知手段は以下から選択できます

    • メール
    • Webhook
    • Automation Runbook
    • Logic Apps

  • Webhook/Runbook/Logic Appsが選択出来るため、通知方法はいろんあパターンがあるかなと思います

    • 例えば、Twilio APIを呼び出して架電したり、PagerDuty APIを呼び出して架電したり、Slackに通知したり
    • メトリックアラートからだとWebhookカスタムペイロード指定ができないので、Webhook単体だとSlack通知できません。Logic Appsを間にかますか、RunbookのPowershellでSlack通知を書くかのどちらかになるかと思います

メトリックアラート設定確認

  • [アラートルール]から設定した内容を確認することができます
    image.png

  • 設定したアラートを一時的に無効化することも可能です
    image.png

次にここのライン

image.png

Log Analyticsへイベントログ収集

ゲストレベルの診断を有効化するとパフォーマンスモニターだけでなく、イベントログもAzure Storage(Table)に収集することが可能です。
ただ、それを監視するためにはStorageから更にLog Analyticsに転送する必要があります。
長期間保管する用途でもない限りは、仮想マシンから直接Log Analyticsへ転送したほうが効率がよいです。

  • ポータルからLog Analytics（OMSワークスペース）を作成します
    image.png

  • OMSワークスペースのメニューより、[仮想マシン]を選択します
    image.png

  • イベントログ収集対象の仮想マシンを選択して、[接続]ボタンを押します
    image.png

  • ワークスペースへの追加が完了すると、仮想マシンの拡張機能「MicrosoftMonitoringAgent」が追加されます
    image.png

  • これだけだとまだLog Analyticsが仮想マシンを認識しただけなので、ログを収集する設定をしていきます
  • OMSワークスペースのメニューより、[詳細設定]→[Data]→[Windowsイベントログ]の順に選択します
    image.png

  • SystemとApplicationイベントログを追加します
    Securityイベントログは収集できません。これはSecurity & Complianceソリューションを使ってねっていうメッセージだろうか。そのうち検証してみます。
    image.png

  • OMSワークスペースのメニューより、[ログ検索]を選択します
  • クエリを発行することで収集したログを確認できます
  • 以下はComputer名が「win-monitor」且つタイプが「Event」のものを抽出しています
    image.png

  • 以下のように結果が表示されます
    image.png

Log Analyticsアラート設定

特定の条件のメッセージが出力されたときにアラート通知する設定を行います。

  • アラートルールの元となるクエリを発行し、[New Alert Rule]を選択します
  • ここではコンピュータ名が「win-monitor」且つタイプが「イベント」且つイベントレベルが「Error」のものを抽出しています
    image.png

  • 条件を細かく決めていきます。条件欄を選択します
    image.png

  • 閾値を設定します。このクエリを実行したときにヒットした数が閾値を超えた場合にアラート通知するという条件になります
  • 1件でもErrorイベントを検知したらアラート通知したいので、ここでは「0より大きい場合」という条件にします
    image.png

  • 次に評価基準を設定します。「期間」はどれくらいの範囲を対象とするか、「頻度」はクエリ発行間隔を表しています
    image.png

  • 今回は10分間隔でクエリを発行し、クエリ発行から10分前までのデータを対象としています
    image.png

  • ここで注意事項
    頻度と期間を短くすればほぼリアルタイムで検知可能では？と思いますが、これには注意が必要です。
    ソース（今回はイベントログ）からLog Analyticsへの送信頻度や間隔は指定できないので、いつデータが収集されるかが分かりません
    あまり短くしすぎるとアラート検知漏れが発生する懸念があります
    image.png

  • 次にアラート名と重要度を設定します
    image.png

  • 最後にアラートを検知したときにどういうアクションを起こすかを定義します

  • 以下のアクションを選択できます

    • メール/SMS
    • Webhook
    • ITSM
    • Automation Runbook

  • メトリックアラートと違って、Log Analyticsのアラートでは、カスタムJSONペイロードを含めることが出来るため、間にLogic Appsを挟まなくてもSlack通知が可能ですね
    image.png

  • 設定したアラートはLog Analyticsメニューの[アラート]から確認可能です
    image.png

Log Analyticsにメトリック値も収集する

本記事ではメトリック値はAzure Alertを使って検知していますが、分析目的でパフォーマンスモニター等のメトリック値をLog Analyticsに収集するのももちろんありだと思います。

  • Log Analyticsの詳細設定より、[Data]→[Windowsパフォーマンスカウンター]→[選択したパフォーマンスカウンターを追加する]の順に選択します
    image.png

監視エージェントが必要なケースは？

OS上のサービスやプロセスの監視

Azureの機能では監視することができません。代替案としては以下のような手法が考えられます。

  • プロセスがダウンした場合、イベントログやsyslogに出力されるであろうことを前提にイベントログ(syslog)監視のみでいく
  • タスクスケジューラー等で定期的に状態を確認し、異常だとイベントログに出力するように作り込む

アラート通知に即時性を持たせたい

Log Analyticsでは検知するのに時間が掛かる可能性があるため、ログアラートを即時検知させたいようなケースでは必要になります

クラウド毎に運用を変えたくない

マルチクラウドで運用しているケースが挙げられます。クラウドに応じて監視手法を変えることがないメリットは大きいですね

まとめ

今回可能な限りAzureサービスのみでIaaSの監視を考えてみました。
エージェント製品が必要なケースももちろんあるので、システムの特性に合わせて選定できるようになれればと思います。

37
32
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
37
32

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?