次の方法で共有

Azure Monitor での仮想マシンのメトリック エクスペリエンス

Azure Monitor で Azure 仮想マシンまたは Arc 対応サーバーの拡張監視を有効にする場合は、ゲスト オペレーティング システムからパフォーマンス データを収集および視覚化するための 2 つのエクスペリエンス (メトリックベースの監視 (プレビュー) とログベースの監視 (クラシック) のどちらかを選択します。 この記事では、これらのエクスペリエンスの違いについて説明し、選択するガイダンスを提供します。

エクスペリエンスを比較する

次の表は、Azure Monitor での Azure 仮想マシンの OpenTelemetry ベースの監視エクスペリエンスとログベースの監視エクスペリエンスを比較したものです。

特徴 メトリックベース (プレビュー) ログベース (クラシック)
データ ストレージ Azure Monitor ワークスペース Log Analytics ワークスペース
適用対象 Azure 仮想マシン
Arc 対応サーバー		 Azure 仮想マシン
Arc 対応サーバー
VM Scale Sets
データ モデル 一貫性のあるクロスプラットフォームの名前付けによる OpenTelemetry システム メトリック プラットフォーム固有のパフォーマンス カウンター
クエリ言語 PromQL (Prometheus クエリ言語) KQL (Kusto クエリ言語)
Latency レイテンシが低い準リアルタイム 通常は 1 ~ 3 分
コスト 既定のメトリックは無料 標準のログ分析のインジェストと保持コスト
マルチ VM ビュー 現在制限あり 完全な VM インサイトのマルチ-VM ダッシュボードとワークブック
ログとの相関関係 個別のクエリが必要 メトリックとログ用の 1 つのワークスペースにより、1 つのクエリでの相関関係が可能

ログ ベースのエクスペリエンスを有効にするタイミング

既定のメトリックの収集は無料であるため、すべてのケースでメトリックベースのエクスペリエンスを有効にする必要があります。 次の場合は、ログベースのメトリックも有効にすることを選択します。

  • VM スケール セットを監視する必要があります。
  • 組み込みのマルチ VM ダッシュボードとトレンド ビューが必要です。
  • メトリックとログを 1 つのクエリに関連付ける必要があります。
  • InsightsMetrics テーブルに基づいて、クエリ、ダッシュボード、またはアラートを既に使用しています。

OpenTelemetry の利点

OS 間の可観測性
システム メトリックの OpenTelemetry セマンティック規則は、Windows と Linux のパフォーマンス カウンターを一貫した名前付け規則とメトリック データ モデルに集約することで、OS 間のエンド ユーザー エクスペリエンスを合理化します。 これにより、Windows または Linux オペレーティング システムで使用される 1 つのクエリ セットを使用して、すべての仮想マシンを簡単に管理できます。 OpenTelemetry システム メトリックを採用するホスティング リソースには、同じ コードとしての構成 デプロイ方法と同じ PromQL クエリを使用できます。

その他のパフォーマンス カウンター
OpenTelemetry Collector Host Metrics Receiver は、Azure Monitor がログベースの収集に現在使用できるよりも多くのパフォーマンス カウンターを収集します。 たとえば、プロセスごとの CPU 使用率、ディスク I/O、メモリ使用量を監視できます。

よりシンプルなメトリック モデル

多くのシナリオでは、複数のパフォーマンス カウンターが、メトリック ディメンション ( リソース属性とも呼ばれます) を持つ 1 つの OpenTelemetry (OTel) システム メトリックにマップされます。 これにより、コレクションとクエリの両方が簡略化されます。

たとえば、OTel には system.cpu.time メトリックが含まれています。 State、システム、アイドルなどの値をディメンションでフィルター処理できます。 ログベースの収集では、次のパフォーマンス カウンターを収集してクエリを実行する必要があります。

  • Windows: \Processor Information(_Total)\% Processor Time、 \Processor Information(_Total)\% Privileged Time、 \Processor Information(_Total)\% User Time
  • Linux: Cpu/usage_user、 Cpu/usage_system、 Cpu/usage_idle、 Cpu/usage_active、 Cpu/usage_nice、 Cpu/usage_iowait、 Cpu/usage_irq

Azure Monitor ワークスペースの利点

Azure Monitor ワークスペースは時系列取得用に最適化されているため、Azure Monitor ワークスペースに格納されているメトリックは、Log Analytics ワークスペースに格納されているのと同じデータよりも低コストで高速にクエリを実行できます。 Azure Monitor ワークスペースで OTel メトリックを使用すると、ログベースの収集で使用される複数のスキーマも回避されます。 既定のログ ベースのメトリックは InsightsMetrics テーブルに格納され、追加の有効なメトリックは別のスキーマを使用する Perf テーブルに格納されます。

OpenTelemetry による強化された監視では、使用可能なシステム メトリックのサブセットが使用されます。これにより、チーム間でダッシュボード、アラート、PromQL クエリを標準化できます。

メトリックベースの収集の制限事項

  • メトリックベースのコレクションは、現在、個々の VM と Arc 対応サーバーでのみ使用できます。 ログベースのコレクションは、VM スケール セットにも使用できます。
  • Log Analytics ワークスペースと Azure Monitor ワークスペース内のデータに対して 1 つのクエリを実行することはできません。 ログベースの収集では、VM のログとメトリックが一緒に格納されるため、1 つの KQL クエリでそれらの間を関連付けることができます。 メトリックベースの収集では、メトリックは Azure Monitor ワークスペースに格納され、ログは Log Analytics ワークスペースに格納され、それぞれに個別のクエリが必要になります。
  • OpenTelemetry メトリックを使用してマルチ VM グラフを表示する独自のブックとダッシュボードを作成できますが、ログベースの収集に使用できるような組み込みのエクスペリエンスは Azure portal にありません。

ヒント

Azure Monitor GitHub コミュニティ に投稿するか、 ポータルのフィードバックを使用して、表示する新しいパフォーマンス カウンターまたは機能に関するフィードバックを共有します。

関連するコンテンツ

  • Last updated on