この記事では、パフォーマンスカウンターの収集設定と保持設定を調整することで、Azure Virtual Desktop (AVD) 監視のためのAzure Log Analyticsの取り込みコストを確認および削減するための実用的なワークフローを提供します。
目的は、運用、通知、レポート、トラブルシューティング、およびNerdio ManagerやAzure Monitorに依存する機能のために十分なデータを保持しながら、回避可能な取り込みを削減することです。
このワークフローは、AVDのパフォーマンスカウンター、診断、およびモニタリングデータを収集するLog Analytics ワークスペースに適用されます。個々のワークスペースのタスクについては、「Log Analyticsの管理」を参照してください。
Nerdio Managerを使用すると、Log Analyticsワークスペースとパフォーマンスカウンターを管理できます。Azure Monitorは、カウンターがインストールされているエージェント上で、構成されたサンプルレートで指定されたカウンターを収集します。サンプルの頻度が高いほど、収集されるデータ量が増加します。
高頻度の収集は、アクティブなトラブルシューティング中に役立ちます。定常状態の監視では、レポートや通知の依存関係を検証した後であれば、多くの環境で選択したカウンターに対してより緩やかなサンプル間隔を使用できます。
Log Analyticsのコストは、以下の要因によって決まります。
-
データを送信するセッションホストの数
-
収集されるカウンターの数
-
カウンターのサンプル頻度
-
カウンターごとのインスタンス数
-
有効になっている診断ログの量
-
保持期間
-
ワークスペースを使用しているホストプールの数
-
インシデント後に有効のままになっているトラブルシューティング設定
-
複製または重なり合う収集ルール
-
同じワークスペースを共有しているAVD以外のリソース
パフォーマンスカウンターのカーディナリティは重要となります。数分ごとに収集される単一のマシンレベルのカウンターは、通常、低ボリュームです。多くのホスト全体で30秒ごとに収集されるディスクごと、プロセスごと、またはマルチインスタンスのカウンターは、より多くのデータを作成する可能性があります。
設定を変更する前に、以下の質問に回答してください:
-
このワークスペースはAVDの監視専用に使用されていますか?
-
このワークスペースは他のAzureワークロードと共有されていますか?
-
どのホストプールがこのワークスペースにデータを送信していますか?
-
どのダッシュボード、通知、ワークブック、またはレポートがこのデータに依存していますか?
-
組織に保持要件はありますか?
-
現在、トラブルシューティングのために使用しているカウンターはありますか?
-
Nerdio Manager Insights、Azure Monitor ワークブック、カスタムKQL、または外部レポートを使用していますか?
注意
カウンターを削除したり、保持期間を無闇に短縮したりしないでください。コスト削減を行う際は、測定と記録を行い、いつでも元に戻せるようにしてください。
データの使用方法に合わせて収集レベルを調整してください:
|
監視レベル |
ユースケース |
推奨されるアプローチ |
|---|---|---|
|
ベースライン監視 |
通常の運用 |
コアCPU、メモリ、ディスク、およびセッションホストの正常性シグナルを保持してください。適切な場合は、中程度以下のサンプル頻度を使用してください。 |
|
アクティブなトラブルシューティング |
短期的なインシデントまたはパフォーマンスの調査 |
影響を受ける範囲に対して、一時的にサンプル頻度を増やしてください。理由を記録し、解決後に元に戻してください。 |
|
監査または履歴レポート |
コンプライアンス、傾向分析、エグゼクティブレポート |
要件に合わせて保持期間を調整してください。カウンターの選択とサンプル頻度の最適化に重点を置いてください。 |
まず、Azure MonitorまたはLog Analyticsの使用状況分析を使用して、データ量の発生源を把握してください。詳細については、Microsoft Learnをご覧ください。Log Analytics ワークスペースでの使用状況の分析。
次のKQLクエリ例は、データ型別の高レベルな使用状況を示しています。
Usage | where TimeGenerated > ago(30d) | where IsBillable == true | summarize TotalVolumeGB = sum(Quantity) / 1000 by DataType | order by TotalVolumeGB desc
次の例では、サポートされている場合に課金対象サイズを使用します。
search * | where TimeGenerated > ago(7d) | where _IsBillable == true | summarize BillableGB = sum(_BilledSize) / 1024 / 1024 / 1024 by $table | order by BillableGB desc
ワークスペースのスキーマやテーブルの使用状況は異なる可能性があるため、環境内のクエリを検証してください。
ワークスペースの設定を確認するには:
-
クラウドデスクトップ > Storage > Log Analytics に移動します。
-
ワークスペースを特定します。
-
ワークスペースの構成とデータ保持を確認します。
-
操作メニューから Manage counters を選択し、収集されたカウンターとそのサンプルレートを確認します。
変更を行う前に、以下を記録してください。
-
ワークスペースとホストプール
-
保持期間
-
カウンター名とサンプルレート
-
カスタムカウンター
-
最近の変更
-
見積もりインジェスト量と月次コストの傾向
以下を確認します。
-
30秒ごとに収集されるカウンター
-
ディスクごとのカウンター
-
プロセスごとのカウンター
-
インスタンス数が多いカウンター
-
ダッシュボードや通知で使用していないカウンター
-
以前のトラブルシューティングイベント中に有効化されたカウンター
-
1つのホストプールのみが必要としている場合に、すべてのホストから収集されたカウンター
注意
ボリュームが大きいという理由だけでカウンターを減らさないでください。まず、それが監視、通知、適正サイズ化、トラブルシューティング、または顧客レポートに使用されているかどうかを確認してください。
定常状態の監視では、多くの環境で、すべてのパフォーマンスカウンターを非常に高い頻度でサンプリングする必要はありません。間隔を30秒から180秒に増やすと、収集されるサンプル数が減るため、そのカウンターの取り込み量を大幅に削減できます。以下の間隔をガイドとして使用してください:
|
サンプル間隔 |
一般的な用途 |
|---|---|
|
秒 |
アクティブトラブルシューティングまたは短期的な調査 |
|
秒 |
高解像度の運用監視 |
|
秒 |
多くのカウンターの通常のベースライン監視 |
|
300秒以上 |
リアルタイムの粒度が不要な長期的な傾向監視 |
カウンターのサンプルレートを変更するには:
-
クラウドデスクトップ > ストレージ > Log Analytics に移動します。
-
ワークスペースを特定し、アクションメニューからカウンターの管理を選択してください。
-
Windowsパフォーマンスカウンターの下で、調整したい各カウンターのサンプルレートを変更します。
-
適用 を選択します。
保持期間はビジネス要件に合わせる必要があります。多くの運用監視シナリオでは、30日間で十分な場合があります。監査、コンプライアンス、傾向分析、またはエグゼクティブレポートの場合は、より長い保持期間が必要になることがあります。保持を変更する前に、確認してください。
-
コンプライアンス要件
-
レポート要件
-
過去のトラブルシューティングが必要かどうか
-
別のシステムが長期データを格納しているかどうか
承認された保持設定を記録します。
保持期間を変更するには:
-
クラウドデスクトップ > ストレージ > Log Analytics に移動します。
-
ワークスペースを特定し、保持の編集を選択してください。
-
30日から730日の間で、保持日数を入力してください。
-
[OK] を選択します。
以下が期待どおりに動作することを確認してください。
-
ダッシュボード
-
インサイトInsights overviewを参照してください。
-
Azure Monitor ワークブック
-
アラート
-
KQL クエリ
-
適正サイズ化レポート。 ルール: ルール: AVDプール型デスクトップを適正サイズにする および ルール: ルール: AVD個人用デスクトップを適正サイズにする。
-
ホストプール利用状況ビュー
-
トラブルシューティングワークフローをサポートする
-
エクスポートまたは外部レポート
調整後は、取り込みパターンが正常化するまで十分な時間を確保してください。多くの環境では、24〜72時間あれば方向性のある影響を確認できます。より長い期間にわたる月間コストへの影響を見直してください。比較
-
調整前後の日次取り込み量
-
調整前後の課金対象トップテーブル
-
調整前後の月間見積もりコスト
-
アラートまたはダッシュボードへの影響
-
トラブルシューティングへの影響
-
ユーザーエクスペリエンスへの影響
Log Analyticsのコスト調整は、一度限りのタスクではありません。以下のような変更を行った後は、設定を見直す。
-
ホストプールを追加した、またはセッションホストの件数を増やした。
-
監視構成を変更した。
-
新しいワークブックまたは診断を有効にする。
-
主要な Nerdio Manager をアップグレードする。リリースノートを参照してください。
-
トラブルシューティングイベントが終了します。
-
セキュリティ要件または監査要件が変更されます。
-
アクティブなアラートやダッシュボードで必要なカウンターを削除しないでください。
-
コンプライアンス要件を下回るまで保持期間を短縮しないでください。
-
AVD関連のすべてのテーブルを低コストのテーブルプランに移行できると想定しないでください。まず、Microsoftのサポートと機能への影響を検証してください。
-
トラブルシューティングレベルの収集を無期限に有効にしたままにしないでください。
-
他のワークロードが使用しているかを確認せずに、共有ワークスペースを調整しないでください。
-
現在の設定とロールバック計画を文書化せずに、本番環境の監視を変更しないでください。
-
監視設計の適正サイズ化の代わりとして、取り込み削減を使用しないでください。
-
課金対象の上位テーブルとデータ型を特定してください。
-
どのホストプールがワークスペースにデータを送信しているかを確認してください。
-
Nerdio Managerの現在のパフォーマンスカウンターを確認してください。
-
30秒間隔で収集されるカウンターを特定してください。
-
ダッシュボード、アラート、またはレポートで使用されているカウンターを確認してください。
-
重要度の低いベースラインカウンターは、より長いサンプル間隔に変更してください。
-
トラブルシューティング用のカウンターは、範囲を限定して一時的に利用できるようにしてください。
-
保持期間を見直し、ビジネス上の要件が許す場合にのみ削減してください。
-
ダッシュボード、アラート、レポートを検証してください。
-
24 ~ 72 時間後の取り込み状況を比較してください。
-
月次の節約見積もりを記録してください。
|
シナリオ |
Standard |
|---|---|
|
通常の運用 |
ベースラインのカウンター収集を使用し、傾向のみを把握するカウンターには低いサンプル頻度を使用してください。また、取り込み状況を月次または四半期ごとに確認してください。 |
|
トラブルシューティング |
一時的にサンプル頻度を上げ、変更スコープを絞り込み、理由を記録し、インシデント後に元に戻し、前後での取り込み状況を比較してください。 |
-
Log Analytics 管理
-
ホストプールのAzure Monitor構成
-
リリースノート
-
| Microsoft LearnLog Analytics ワークスペースでの使用状況を分析してください
-
| Microsoft LearnAzure Monitor でのログデータ取り込み時間
-
| Microsoft LearnAzure Monitor メトリックの概要
サポートチケットを提出してくださいこの項目について。
コメント (0件のコメント)