Azure Monitor で仮想マシンを監視する: データの収集
この記事は、「Azure Monitor で仮想マシンとそのワークロードを監視する」のガイドの一部です。 Azure とハイブリッド仮想マシンに Azure Monitor エージェントをデプロイした後に、Azure Monitor でデータの収集を構成する方法について説明します。
この記事では、仮想マシンから最も一般的な種類のテレメトリを収集するためのガイダンスを提供します。 選択する正確な構成は、マシンで実行するワークロードによって異なります。 各セクションには、そのデータで使用できるログ クエリ アラートのサンプルが含まれています。
- 仮想マシンから収集したテレメトリの分析の詳細については「Azure Monitor を使用して仮想マシンを監視する: 監視データの分析」を参照してください。
- Azure Monitor で、仮想マシンから収集したテレメトリを使用してアラートを作成する方法の詳細については「Azure Monitor を使用して仮想マシンを監視する: アラート」を参照してください。
注意
このシナリオでは、Azure とハイブリッド仮想マシン環境の完全な監視を実装する方法について説明します。 最初の Azure 仮想マシンの監視を開始するには、Azure 仮想マシンの監視に関する記事を参照してください。
データ収集ルール
Azure Monitor エージェントからのデータ収集は、Azure サブスクリプションに格納されている 1 つ以上のデータ収集ルール (DCR) によって定義され、仮想マシンに関連付けられます。
仮想マシンの場合、DCR は収集するイベントやパフォーマンス カウンターなどのデータを定義し、そのデータの送信先の Log Analytics ワークスペースを指定します。 また、DCR は変換を使って、不要なデータをフィルター処理したり、計算列を追加したりできます。 1 台のマシンを複数の DCR に関連付けることができ、1 つの DCR を複数のマシンに関連付けることができます。 DCR は、関連付けられているすべてのマシンに配信され、そこで、Azure Monitor エージェントがこれらを処理します。
データ収集ルールを表示する
Azure サブスクリプションの DCR は、Azure portal の [監視] メニューの [データ収集ルール] から確認できます。 DCR は、Azure Monitor の他のデータ収集シナリオをサポートしているため、すべての DCR が仮想マシン用であるとは限りません。
データ収集ルールを作成する
DCR を作成する方法は、データ収集シナリオに応じて複数あります。 一部のケースでは、Azure portal が構成のガイドを示します。 その他のシナリオでは、DCR を直接編集する必要があります。 VM の分析情報を構成すると、事前に構成済みの DCR が自動的に作成されます。 以降のセクションでは、収集する一般的なデータとデータ収集の構成方法について説明します。
場合によっては、既存の DCR を編集して機能を追加することが必要です。 たとえば、Azure portal を使用して、Windows または Syslog イベントを収集する DCR を作成できます。 次に、その DCR に変換を追加し、収集しないイベントの列をフィルター処理するとします。
環境が成熟し、複雑になるにつれて、DCR を整理して管理を支援するための戦略を実装する必要があります。 さまざまな戦略に関するガイダンスについては、「Azure Monitor でのデータ収集ルールの作成と管理のベスト プラクティス」を参照してください。
コストの管理
Azure Monitor のコストは、収集するデータの量によって変わるため、監視要件を満たすために必要とする以上のデータを収集しないようにしてください。 構成は、予算と、仮想マシンの運用について必要とする分析情報の量のバランスをとって設定します。
ヒント
Azure Monitor のコストを削減するための戦略については、「コストの最適化と Azure Monitor」を参照してください。
一般的な仮想マシンは、毎月 1 GB から 3 GB のデータを生成します。 このデータ サイズは、マシンの構成、マシンで実行されるワークロード、および DCR の構成によって異なります。 仮想マシン環境全体のデータ収集を構成する前に、一部の代表的なマシンで収集を開始して、環境全体にデプロイしたときに予想されるコストをより適切に予測します。 コンピューター別のデータ ボリュームのログ クエリを使って、各マシンに対する課金対象のデータ収集量を決定し、それに応じて調整します。
不要なデータをフィルター処理する方法は、収集するデータ ソースごとに異なる場合があります。 変換を使用して、より詳細なフィルター処理を実装し、価値の低い列のデータをフィルター処理で除外できます。 たとえば、アラートには有用な Windows イベントに、冗長なデータまたは過剰なデータを含む列が含まれているとします。 この場合に、過剰なデータを削除した上で、イベントの収集を許可する変換を作成することができます。
既定のデータ収集
Azure Monitor は、その他の構成を必要とせずに、次のデータ収集を自動的に実行します。
プラットフォームのメトリック
Azure 仮想マシンのプラットフォーム メトリックには、CPU、ネットワーク、ディスク使用率などの重要なホスト メトリックが含まれます。 連絡先として指定できるもの:
- 概要ページで表示。
- Azure portal 内のマシンのメトリック ス エクスプローラーで分析。
- メトリック アラートで使用。
アクティビティ ログ
アクティビティ ログは自動的に収集されます。 構成の変更や停止と開始のタイミングなどの、マシンの最近のアクティビティが含まれます。 Azure portal で、各仮想マシンのホストについて収集されたプラットフォームのメトリックとアクティビティ ログを表示できます。
個々のマシンまたはサブスクリプション内の全リソースについてアクティビティ ログを表示できます。 このデータを Azure Monitor エージェントが使用する同じ Log Analytics ワークスペースに送信し、仮想マシンに対して収集された他の監視データと合わせて分析するには、診断設定を作成します。 アクティビティ ログ データの取り込みや保持にはコストはかかりません。
Azure Resource Graph の VM の可用性に関する情報
Azure Resource Graph を使用すると、ログ クエリで使用されるのと同じ Kusto 照会言語を使用して、Azure リソースに対して大規模なクエリを、複雑なフィルター処理、グループ化、リソース プロパティによる並べ替えを使用して実行できます。 VM 正常性に関する注釈を Resource Graph に使用して、詳細な障害の原因とダウンタイムの分析を行うことができます。
収集されるデータとその表示方法の詳細については、「Azure Monitor を使用して仮想マシンを監視する: 監視データの分析」を参照してください。
VM の分析情報
VM の分析情報を有効にすると、次の情報を収集する、MSVMI- というプレフィックスを持つ DCR が作成されます。 VM ごとに新しい DCR を作成するのではなく、この同じ DCR を他のマシンでも使用できます。
クライアント オペレーティング システムの共通パフォーマンス カウンターは、Log Analytics ワークスペースの InsightsMetrics テーブルに送信されます。 カウンター名は、オペレーティング システムの種類に関係なく、同じ共通名を使用するように正規化されます。 収集されるパフォーマンス カウンターの一覧については、「VM insights からログをクエリする方法」を参照してください。
収集するプロセスと依存関係を指定した場合、次のテーブルにデータが設定されます。
- VMBoundPort: マシン上の開いているサーバー ポートのトラフィック
- VMComputer: マシンのインベントリ データ
- VMConnection: マシンとの間の受信と送信の接続のトラフィック
- VMProcess: マシン上で実行されているプロセス
既定では、VM の分析情報は、データ インジェスト コストを節約するために、プロセスと依存関係の収集を有効にしません。 このデータはマップ機能に必要であり、依存関係エージェントのマシンへのデプロイも行います。 この機能を使う場合は、この収集を有効にします。
Windows と Syslog イベントの収集
仮想マシンのオペレーティング システムとアプリケーションは、多くの場合、Windows イベント ログまたは Syslog に書き込みます。 1 つのイベントが見つかったらすぐにアラートを作成することも、特定の時間枠内で一致する一連のイベントを待機することもできます。 時間の経過に伴う特定の傾向の特定や、問題発生後のトラブルシューティングの実行などの、その後の分析のためにイベントを収集することもできます。
Windows と Syslog イベントを収集するための DCR の作成に関するガイダンスについては、「Azure Monitor エージェントを使用して仮想マシンからイベントとパフォーマンス カウンターを収集する」を参照してください。 最も一般的な Windows イベント ログと Syslog をイベント レベルでフィルター処理するファシリティを使用して、DCR をすばやく作成できます。
イベント ID などの条件でより詳細にフィルター処理するために、XPath クエリを使用してカスタム フィルターを作成できます。 DCR を編集して変換を追加することで、収集したデータをさらにフィルター処理できます。
イベント収集の推奨される開始点として、次のガイダンスを使います。 DCR の設定を変更して、不要なイベントをフィルター処理で除外し、要件に応じてその他のイベントを追加します。
| source | 戦略 |
|---|---|
| Windows イベント | システムおよびアプリケーション ログについて、少なくとも重大、エラー、警告イベントを収集して、アラートをサポートするようにします。 情報イベントを追加して傾向を分析し、トラブルシューティングをサポートします。 詳細イベントはほとんど役に立つことはありません。通常は収集しないでください。 |
| Syslog イベント | 少なくとも LOG_WARNING イベントを各ファシリティについて収集し、アラートをサポートします。 情報イベントを追加して傾向を分析し、トラブルシューティングをサポートします。 LOG_DEBUG イベントはほとんど役に立つことはありません。通常は収集しないでください。 |
ログ クエリのサンプル: Windows イベント
| クエリ | 説明 |
|---|---|
Event |
すべての Windows イベント |
Event | where EventLevelName == "Error" |
重大度が「エラー」のすべての Windows イベント |
Event | summarize count() by Source |
ソース別の Windows イベントの数 |
Event | where EventLevelName == "Error" | summarize count() by Source |
ソース別の Windows エラー イベントの数 |
ログ クエリのサンプル: Syslog イベント
| クエリ | 説明 |
|---|---|
Syslog |
すべての Syslog |
Syslog | where SeverityLevel == "error" |
重大度がエラーであるすべての Syslog レコード |
Syslog | summarize AggregatedValue = count() by Computer |
コンピューターごとの Syslog レコードの数 |
Syslog | summarize AggregatedValue = count() by Facility |
ファシリティごとの Syslog レコードの数 |
パフォーマンス カウンターを収集します。
クライアントからのパフォーマンス データは、Azure Monitor メトリックと Azure Monitor ログのいずれかに送信でき、通常は両方の宛先に送信します。 VM の分析情報を有効にした場合、パフォーマンス グラフをサポートするために、一般的なパフォーマンス カウンターのセットがログに収集されます。 このカウンターのセットを変更することはできませんが、その他の DCR を作成してさらにカウンターを収集し、異なる宛先に送信することはできます。
ゲストのパフォーマンスを収集するために DCR を作成する理由は複数あります。
- VM の分析情報を使っていないため、クライアントのパフォーマンス データがまだ収集されていない。
- VM の分析情報が収集していないその他のパフォーマンス カウンターを収集します。
- クライアント上で実行されている他のワークロードからパフォーマンス カウンターを収集する。
- パフォーマンス データを Azure Monitor メトリックに送信し、メトリックス エクスプローラーとメトリック アラートで使用できるようにする。
パフォーマンス カウンターを収集するための DCR の作成に関するガイダンスについては、「Azure Monitor エージェントを使用して仮想マシンからイベントとパフォーマンス カウンターを収集する」を参照してください。 最も一般的なカウンターを使用して、DCR をすばやく作成できます。 イベント ID などの条件でより詳細にフィルター処理するために、XPath クエリを使用してカスタム フィルターを作成できます。
注意
パフォーマンスとイベントの収集を同じ DCR に結合することもできます。
| 宛先 | 説明 |
|---|---|
| メトリック | ホスト メトリックは、Azure Monitor メトリックに自動的に送信されます。 メトリックス エクスプローラーでの組み合わせ分析や、メトリック アラートでの使用ができるように、DCR を使用してクライアント メトリックを収集できます。 このデータは 93 日間保存されます。 |
| ログ | Azure Monitor ログに格納されているパフォーマンス データは、長期間保存できます。 Log Analytics のログ クエリや、ログ クエリ アラートを使用して、イベント データと組み合わせてデータを分析できます。 複数のマシン、リージョン、サブスクリプションにまたがる複雑なロジックを使用してデータを相互に関連付けることもできます。 パフォーマンス データは、次のテーブルに送信されます。 - VM の分析情報: InsightsMetrics - その他のパフォーマンス データ - Perf |
サンプル ログ クエリ
次のサンプルでは、カスタム パフォーマンス データで Perf テーブルを使っています。 VM の分析情報によって収集されたパフォーマンス データについては、「VM insights からログをクエリする方法」を参照してください。
| クエリ | 説明 |
|---|---|
Perf |
すべてのパフォーマンス データ |
Perf | where Computer == "MyComputer" |
特定のコンピューターからのすべてのパフォーマンス データ |
Perf | where CounterName == "Current Disk Queue Length" |
特定のカウンターに関するすべてのパフォーマンス データ |
Perf | where ObjectName == "Processor" and CounterName == "% Processor Time" and InstanceName == "_Total" | summarize AVGCPU = avg(CounterValue) by Computer |
コンピューター全体の平均 CPU 使用率 |
Perf | where CounterName == "% Processor Time" | summarize AggregatedValue = max(CounterValue) by Computer |
コンピューター全体の最大 CPU 使用率 |
Perf | where ObjectName == "LogicalDisk" and CounterName == "Current Disk Queue Length" and Computer == "MyComputerName" | summarize AggregatedValue = avg(CounterValue) by InstanceName |
特定のコンピューターのインスタンス全体における現在のディスク キューの長さの平均 |
Perf | where CounterName == "Disk Transfers/sec" | summarize AggregatedValue = percentile(CounterValue, 95) by Computer |
コンピューター全体のディスク転送数/秒の 95 パーセンタイル |
Perf | where CounterName == "% Processor Time" and InstanceName == "_Total" | summarize AggregatedValue = avg(CounterValue) by bin(TimeGenerated, 1h), Computer |
全コンピューターの CPU 使用率の平均値 (1 時間ごと) |
Perf | where Computer == "MyComputer" and CounterName startswith_cs "%" and InstanceName == "_Total" | summarize AggregatedValue = percentile(CounterValue, 70) by bin(TimeGenerated, 1h), CounterName |
特定のコンピューターの各パーセント (%) カウンターの 70 パーセンタイル (1 時間ごと) |
Perf | where CounterName == "% Processor Time" and InstanceName == "_Total" and Computer == "MyComputer" | summarize ["min(CounterValue)"] = min(CounterValue), ["avg(CounterValue)"] = avg(CounterValue), ["percentile75(CounterValue)"] = percentile(CounterValue, 75), ["max(CounterValue)"] = max(CounterValue) by bin(TimeGenerated, 1h), Computer |
特定のコンピューターの CPU 使用率の平均、最小、最大、75 パーセンタイル (1 時間ごと) |
Perf | where ObjectName == "MSSQL$INST2:Databases" and InstanceName == "master" |
名前付き SQL インスタンス INST2 のマスター データベースのデータベース パフォーマンス オブジェクトのすべてのパフォーマンス データ。 |
テキスト ログを収集する
一部のアプリケーションでは、仮想マシンに格納されているテキスト ログに書き込まれるイベントが書き込まれます。 このデータを収集するためにカスタム テーブルと DCR を作成します。 テキスト ログの場所、その詳細構成、カスタム テーブルのスキーマを定義します。 ワークスペースでのこのデータの取り込みと保有にはコストがかかります。
サンプル ログ クエリ
ここで使用する列名は、例として示しているだけです。 ほとんどの場合、ご使用のログの列名は異なります。
| クエリ | 説明 |
|---|---|
MyApp_CL | summarize count() by code |
コード別にイベントの数をカウントします。 |
MyApp_CL | where status == "Error" | summarize AggregatedValue = count() by Computer, bin(TimeGenerated, 15m) |
エラー イベントに対するアラート ルールを作成します。 |
IIS ログを収集する
Windows マシンで実行される IIS では、ログがテキスト ファイルに書き込まれます。 「Azure Monitor エージェントを使用した IIS ログの収集」を使用して IIS ログの収集を構成します。 ワークスペースでのこのデータの取り込みと保有にはコストがかかります。
IIS ログのレコードは、Log Analytics ワークスペースの W3CIISLog テーブルに格納されます。 ワークスペースでのこのデータの取り込みと保有にはコストがかかります。
サンプル ログ クエリ
| クエリ | 説明 |
|---|---|
W3CIISLog | where csHost=="www.contoso.com" | summarize count() by csUriStem |
www.contoso.com というホストの URL 別の IIS ログ エントリの数。 |
W3CIISLog | summarize sum(csBytes) by Computer |
各 IIS マシンによって受信された合計バイト数を確認します。 |
サービスやデーモンを監視する
Windows サービスまたは Linux デーモンの状態を監視するには、Azure Automation で変更履歴とインベントリ ソリューションを有効にします。
Azure Monitor には、サービスまたはデーモンの状態を単独で監視する機能はありません。 Windows イベント ログでイベントを検索するなど、使用できる方法はいくつかありますが、この方法は信頼性がありません。 VM の分析情報によって入力された VMProcess テーブルから、マシンで実行されているサービスに関連付けられているプロセスを検索することもできます。 このテーブルは 1 時間ごとにしか更新されないので、このデータをアラートに使いたい場合、一般的には十分ではありません。
注意
変更履歴と分析ソリューションは、VM 分析情報の変更分析機能とは異なります。 この機能はパブリック プレビューの段階であり、このシナリオにはまだ含まれていません。
仮想マシンで Change Tracking ソリューションを有効にするためのさまざまなオプションについては、「Change Tracking と Inventory の有効化」を参照してください。 このソリューションには、仮想マシンを大規模に構成する方法が含まれています。 このソリューションをサポートする Azure Automation アカウントを作成する必要があります。
変更履歴とインベントリを有効にすると、Log Analytics ワークスペースに 2 つの新しいテーブルが作成されます。 ログ クエリおよびログ クエリの警告ルールには、次のテーブルを使います。
| テーブル | 説明 |
|---|---|
| ConfigurationChange | ゲスト内の構成データへの変更 |
| ConfigurationData | ゲスト内の構成データについて最後に報告された状態 |
サンプル ログ クエリ
最近開始されたすべてのサービスとデーモンを一覧表示します。
ConfigurationChange | where ConfigChangeType == "Daemons" or ConfigChangeType == "WindowsServices" | where SvcState == "Running" | sort by Computer, SvcName特定のサービスが停止したときにアラートを生成します。 ログ警告ルールでこのクエリを使います。
ConfigurationData | where SvcName == "W3SVC" | where SvcState == "Stopped" | where ConfigDataType == "WindowsServices" | where SvcStartupType == "Auto" | summarize AggregatedValue = count() by Computer, SvcName, SvcDisplayName, SvcState, bin(TimeGenerated, 15m)一連のサービスのうちの 1 つが停止したときにアラートを生成します。 ログ警告ルールでこのクエリを使います。
let services = dynamic(["omskd","cshost","schedule","wuauserv","heathservice","efs","wsusservice","SrmSvc","CertSvc","wmsvc","vpxd","winmgmt","netman","smsexec","w3svc","sms_site_vss_writer","ccmexe","spooler","eventsystem","netlogon","kdc","ntds","lsmserv","gpsvc","dns","dfsr","dfs","dhcp","DNSCache","dmserver","messenger","w32time","plugplay","rpcss","lanmanserver","lmhosts","eventlog","lanmanworkstation","wnirm","mpssvc","dhcpserver","VSS","ClusSvc","MSExchangeTransport","MSExchangeIS"]); ConfigurationData | where ConfigDataType == "WindowsServices" | where SvcStartupType == "Auto" | where SvcName in (services) | where SvcState == "Stopped" | project TimeGenerated, Computer, SvcName, SvcDisplayName, SvcState | summarize AggregatedValue = count() by Computer, SvcName, SvcDisplayName, SvcState, bin(TimeGenerated, 15m)
ポートの監視
ポートの監視では、マシンで特定のポートがリッスンされていることを確認します。 ここでは、ポート監視のために考えられる 2 つの戦略について説明します。
Dependency Agent テーブル
プロセスと依存関係の収集を有効にして VM の分析情報を使用する場合は、VMConnection と VMBoundPort を使用して接続とマシン上のポートを分析できます。 VMBoundPort テーブルは、コンピューター上で実行されている各プロセスとリッスンしているポートで 1 分ごとに更新されます。 ハートビートなしアラートに似たログ クエリ アラートを作成して、停止したプロセスを見つけたり、マシンが特定のポートでリッスンしていないときにアラートを生成したりすることができます。
構成とセキュリティの脆弱性がある VM を評価するために、VM で開いているポートの数を確認します。
VMBoundPort | where Ip != "127.0.0.1" | summarize by Computer, Machine, Port, Protocol | summarize OpenPorts=count() by Computer, Machine | order by OpenPorts desc構成とセキュリティの脆弱性がある VM を評価するために、VM 上のバインドされたポートを一覧表示します。
VMBoundPort | distinct Computer, Port, ProcessNameアプリケーションまたはサービスがどのように構成されているかを判断するために、ポート別にネットワーク アクティビティを分析します。
VMBoundPort | where Ip != "127.0.0.1" | summarize BytesSent=sum(BytesSent), BytesReceived=sum(BytesReceived), LinksEstablished=sum(LinksEstablished), LinksTerminated=sum(LinksTerminated), arg_max(TimeGenerated, LinksLive) by Machine, Computer, ProcessName, Ip, Port, IsWildcardBind | project-away TimeGenerated | order by Machine, Computer, Port, Ip, ProcessNameVM で送受信されたバイト数の傾向を確認します。
VMConnection | summarize sum(BytesSent), sum(BytesReceived) by bin(TimeGenerated,1hr), Computer | order by Computer desc | render timechart時間の経過に伴う接続エラーを使用して、障害率が安定している (または変化している) かどうかを判断します。
VMConnection | where Computer == <replace this with a computer name, e.g. 'acme-demo'> | extend bythehour = datetime_part("hour", TimeGenerated) | project bythehour, LinksFailed | summarize failCount = count() by bythehour | sort by bythehour asc | render timechartリンクの状態の傾向を調べて、マシンの動作と接続状態を分析します。
VMConnection | where Computer == <replace this with a computer name, e.g. 'acme-demo'> | summarize dcount(LinksEstablished), dcount(LinksLive), dcount(LinksFailed), dcount(LinksTerminated) by bin(TimeGenerated, 1h) | render timechart
接続マネージャー
Network Watcher の接続モニター機能は、仮想マシン上のポートへの接続をテストするために使用されます。 テストでは、マシンでポートがリッスンされていて、ネットワーク上でアクセスできることを確認します。
接続マネージャーを使用するには、テストを開始するクライアント マシンに Network Watcher 拡張機能が必要となります。 テスト対象のマシンにインストールする必要はありません。 詳細については、チュートリアル - Azure portal を使用してネットワーク通信を監視するに関するページを参照してください。
接続マネージャーには追加料金が発生します。 詳細については、「Network Watcher の価格」を参照してください。
ローカル コンピューターでプロセスを実行する
一部のワークロードを監視するには、ローカル プロセスが必要です。 たとえば、ローカル コンピューター上で実行され、アプリケーションに接続してデータを収集または処理する PowerShell スクリプトがあります。 Azure Automation の一部である Hybrid Runbook Worker を使用して、ローカルの PowerShell スクリプトを実行できます。 Hybrid Runbook Worker に対しては直接課金されませんが、それが使用する Runbook ごとにコストが発生します。
Runbook では、ローカル コンピューター上の任意のリソースにアクセスして、必要なデータを収集できます。 Azure Monitor にデータを直接送信したり、アラートを作成したりすることはできません。 アラートを作成するには、Runbook がカスタム ログにエントリを書き込むようにします。 次に、Azure Monitor によって収集されるようにそのログを構成します。 そのログ エントリに対して実行されるログ クエリのアラート ルールを作成します。