この記事では、Azure 最適化エンジン (AOE) 用に Log Analytics ワークスペースを構成する方法について説明します。
パフォーマンス カウンターを構成する
仮想マシン (VM) の適切なサイズの拡張推奨事項を完全に使用する場合は、VM が Log Analytics ワークスペースにログを送信する必要があります。 通常、Tt は AOE インストール時に選択したものにする必要がありますが、異なる場合があり、特定のパフォーマンス カウンターを送信するために必要です。 必要なカウンターの一覧は、 perfcounters.json ファイルで定義されます ( AOE ルート フォルダーで使用可能)。 AOE には、構成された Log Analytics パフォーマンス カウンターの検証と修正に役立つツールがいくつか用意されています。 これらは、マシンからログを収集するために使用しているエージェントの種類によって異なります。
Azure Monitor エージェント (推奨されるアプローチ)
Setup-DataCollectionRules.ps1 スクリプトの助けを借りて、パフォーマンス カウンターを任意の Log Analytics ワークスペースにストリーミングするように構成する、2 つのデータ収集規則 (DCR) (OS の種類ごとに 1 つ) を作成できます。 次のスクリプトを使用して DCR を作成した後は、VM をそれぞれの DCR に関連付ける (Azure Policy など) 手動または自動で行う必要があります。
要件
Install-Module -Name Az.Accounts
Install-Module -Name Az.Resources
Install-Module -Name Az.OperationalInsights
使用方法
./Setup-DataCollectionRules.ps1 -DestinationWorkspaceResourceId <Log Analytics workspace ARM resource ID> [-AzureEnvironment <AzureChinaCloud|AzureUSGovernment|AzureCloud>] [-IntervalSeconds <performance counter collection frequency - default 60>] [-ResourceTags <hashtable with the tag name/value pairs to apply to the DCR>]
# Example 1 - create Linux and Windows DCRs with the default options
./Setup-DataCollectionRules.ps1 -DestinationWorkspaceResourceId "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/myResourceGroup/providers/Microsoft.OperationalInsights/workspaces/myWorkspace"
# Example 2 - create DCRs using a custom counter collection frequency and assigning specific tags
./Setup-DataCollectionRules.ps1 -DestinationWorkspaceResourceId "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/myResourceGroup/providers/Microsoft.OperationalInsights/workspaces/myWorkspace" -IntervalSeconds 30 -ResourceTags @{"tagName"="tagValue";"otherTagName"="otherTagValue"}
Log Analytics エージェント (従来の Microsoft Monitoring Agent、2024 年 8 月 31 日に非推奨)
従来の Log Analytics エージェントをまだ使用している場合は、 Azure Monitor エージェントに移行します。
パフォーマンス ログのコスト見積もり
Perf テーブルの各パフォーマンス カウンター エントリのサイズは、OS の種類ごとに 7 つの必要なカウンターによって異なります。 次の表は、パフォーマンス カウンター エントリごとのサイズ (バイト単位) を列挙したものです。
| OS の種類 | オブジェクト | カウンタ | サイズ | 間隔/VM あたりのコレクション数 |
|---|---|---|---|---|
| Windows | プロセッサ | プロセッサ時間の使用率 (%) | 200 | 1 + vCPUの数 |
| Windows | [メモリ] | 使用可能な MB | 220 | 1 |
| Windows | LogicalDisk | ディスク読み取りバイト/秒 | 250 | 3 + データディスク数 |
| Windows | LogicalDisk | ディスク書き込みバイト/秒 | 250 | 3 + データディスク数 |
| Windows | LogicalDisk | ディスク読み取り/秒 | 250 | 3 + データディスク数 |
| Windows | LogicalDisk | ディスク書き込み/秒 | 250 | 3 + データディスク数 |
| Windows | ネットワーク アダプター | バイト合計/秒 | 290 | ネットワーク アダプターの数 |
| Linux | プロセッサ | プロセッサ時間の使用率 (%) | 200 | |
| Linux | [メモリ] | 使用メモリの % | 200 | |
| Linux | 論理ディスク | ディスク読み取りバイト/秒 | 250 | 3 + データディスクの数 |
| Linux | 論理ディスク | ディスク書き込みバイト/秒 | 250 | 3 + データディスクの数 |
| Linux | 論理ディスク | ディスク読み取り/秒 | 250 | 3 + データディスク数 |
| Linux | 論理ディスク | ディスク書き込み/秒 | 250 | 3 + データディスク数 |
| Linux | ネットワーク | 合計バイト数 | 200 | ネットワーク アダプターの数 |
要約すると、Windows VM ではパフォーマンス カウンター エントリあたり平均で 245 バイトが生成されますが、Linux ではエントリあたり 230 バイトの消費が少なくなります。 ただし、CPU コア、データ ディスク、またはネットワーク アダプターの数によっては、VM によって多かれ少なかれ Log Analytics エントリが生成されます。 たとえば、4 つの vCPU、1 つのデータ ディスク、5 つのネットワーク アダプターを備えた Windows VM では、コレクション間隔ごとに 5 * 200 + 220 + 4 * 250 + 4 * 250 + 4 * 250 + 5 * 290 = 6670 バイト (6.5 KB) が生成されます。 パフォーマンス カウンター間隔を 60 秒に設定すると、1 か月あたり 60 * 24 * 30 * 6.5 = 280800 KB (274 MB) のインジェスト データが得られます。 これは、インジェスト用の Log Analytics の小売価格（従量課金制）で、コストが月に0.70 EUR未満であることを意味します。
パフォーマンス ログに複数のワークスペースを使用する
VM の適切なサイズの推奨事項レポートに複数の Log Analytics ワークスペースの VM を含めるには、AOE Azure Automation アカウントに AzureOptimization_RightSizeAdditionalPerfWorkspaces という名前の新しい変数を追加します。 変数の値は、ワークスペース ID のコンマ区切りのリストである必要があります。 AOE マネージド ID にそのワークスペースに対する閲覧者アクセス許可がある場合は、任意のワークスペースを AOE のスコープに追加できます。 ワークスペースは、同じサブスクリプション内、または同じテナント内の他の任意のサブスクリプション、または (Lighthouse の助けを借りて) 別のテナント内にあってもかまいません。
関連するコンテンツ
関連製品:
関連するソリューション: