Azure Monitor についてよくあるご質問

この Microsoft FAQ では、Azure Monitor についてよくあるご質問を紹介します。 その他の質問がある場合は、ディスカッション フォーラムにアクセスして質問を投稿してください。 よく寄せられる質問については、すばやく簡単に見つけることができるように、この記事に追加していきます。

全般

Azure Monitor とは

Azure Monitor は Azure のサービスであり、Azure、他のクラウド環境、またはオンプレミスのアプリケーションとサービスのパフォーマンスと可用性を監視する機能が提供されます。 Azure Monitor を使うと、複数のソースから共通のデータ プラットフォームにデータが収集され、傾向や異常を分析できるようになります。 Azure Monitor の豊富な機能を利用すると、アプリケーションに影響する可能性がある重大な状況を迅速に特定して対応することができます。

Azure Monitor、Log Analytics、Application Insights の違いは何ですか?

2018 年 9 月に、Azure Monitor、Log Analytics、Application Insights が 1 つのサービスに結合され、アプリケーションとそれらが依存するコンポーネントをエンドツーエンドで監視できるようになりました。 Log Analytics と Application Insights の機能は変更されていませんが、一部の機能は、新しい対象範囲がより適切に反映されるように、Azure Monitor にブランド変更されています。 Log Analytics のログデータ エンジンとクエリ言語は、Azure Monitor ログと呼ばれるようになっています。 Azure Monitor の用語の更新に関するページをご覧ください。

Azure Monitor のコストはどれくらいですか?

メトリックやアクティビティ ログの収集など、自動的に有効になる Azure Monitor の機能は、無料で提供されます。 ログ クエリやアラートなどの他の機能については、関連コストが発生します。 詳細な価格については、Azure Monitor の価格に関するページをご覧ください。

Azure Monitor を有効にするにはどうすればよいですか?

Azure Monitor は新しい Azure サブスクリプションを作成した時点で有効になり、アクティビティ ログとプラットフォーム メトリックが自動的に収集されます。 Azure リソースの動作に関するさらに詳細な情報を収集するには診断設定を作成し、特定のサービスについて収集されたデータについて追加の分析を提供するには監視ソリューション分析情報を追加します。

Azure Monitor にアクセスするにはどうすればよいですか?

Azure Monitor のすべての機能とデータには、Azure portal の [モニター] メニューからアクセスします。 さまざまな Azure サービスのメニューの [監視] セクションでは、特定のリソースに対してフィルター処理されたデータを使用して、同じツールにアクセスできます。 Azure Monitor データには、CLI、PowerShell、REST API を使用したさまざまなシナリオでもアクセスできます。

オンプレミス バージョンの Azure Monitor はありますか?

いいえ。 Azure Monitor は大量のデータを処理して格納するスケーラブルなクラウド サービスですが、Azure Monitor ではオンプレミスまたは他のクラウドのリソースを監視することができます。

Azure Monitor でオンプレミスのリソースを監視することはできますか?

はい。Azure リソースから監視データを収集するだけでなく、Azure Monitor では、他のクラウドやオンプレミスの仮想マシンやアプリケーションからデータを収集することができます。 「Azure Monitor で使用する監視データのソース」をご覧ください。

Azure Monitor と System Center Operations Manager を統合することはできますか?

System Center Operations Manager の既存の管理グループを Azure Monitor に接続して、エージェントからのデータを Azure Monitor ログに収集することができます。 この機能により、ログ クエリとソリューションを使用して、エージェントから収集されたデータを分析することができます。 また、Azure Monitor にデータを直接送信するように、既存の System Center Operations Manager エージェントを構成することもできます。 「Operations Manager を Azure Monitor に接続する」を参照してください。

Azure Monitor ではどのような IP アドレスが使用されますか?

エージェントと他の外部リソースが Azure Monitor にアクセスするために必要な IP アドレスとポートの一覧については、「Application Insights および Log Analytics によって使用される IP アドレス」をご覧ください。

データの監視

Azure Monitor はどこでデータを取得しますか?

Azure Monitor では、Azure プラットフォームとリソース、カスタム アプリケーション、仮想マシン上で実行されているエージェントからのログやメトリックなど、さまざまなソースのデータが収集されます。 Microsoft Defender for Cloud や Network Watcher などの他のサービスでは、データが Log Analytics ワークスペースに収集されるので、Azure Monitor のデータで分析できます。 また、ログまたはメトリックの REST API を使用して、Azure Monitor にカスタム データを送信することもできます。 「Azure Monitor で使用する監視データのソース」をご覧ください。

Azure Monitor ではどのようなデータが収集されますか?

Azure Monitor では、さまざまなソースからのデータがログまたはメトリックに収集されます。 各データの種類には、独自の相対的利点があり、それぞれによって Azure Monitor の特定の機能セットがサポートされます。 Azure サブスクリプションごとに 1 つのメトリック データベースがありますが、複数の Log Analytics ワークスペースを作成し、要件に応じてログを収集できます。 「Azure Monitor データ プラットフォーム」をご覧ください。

Azure Monitor で収集できるデータに最大量はありますか?

収集できるメトリック データの量に制限はありませんが、このデータが保存される期間は最大 93 日間になります。 「メトリックの保有期間」をご覧ください。 収集できるログ データの量に制限はありませんが、Log Analytics ワークスペースに対して選択した価格レベルの影響を受ける可能性があります。 価格の詳細を参照してください。

Azure Monitor によって収集されたデータにアクセスするにはどうすればよいですか?

分析情報とソリューションにより、Azure Monitor に格納されているデータを操作するためのカスタム エクスペリエンスが提供されます。 Kusto クエリ言語 (KQL) で記述たログ クエリを使用して、ログ データを直接操作できます。 Azure portal では、Log Analytics を使用してクエリを記述して実行し、対話形式でデータを分析できます。 Azure portal では、メトリックス エクスプローラーを使用してメトリックを分析します。 Azure Monitor でログ データを分析する方法に関するページ、および「Azure メトリックス エクスプローラーの概要」のページをご覧ください。

Azure Monitor ログに重複するレコードが表示されるのはなぜですか?

場合によっては、Azure Monitor ログに重複するレコードが表示されることがあります。 通常、この重複は次の 2 つの条件のいずれかが原因となっています。

  • パイプライン内のコンポーネントは、配信先に確実に配信されるように再試行を行います。 場合によっては、この機能が原因で、わずかながらテレメトリ項目が重複する可能性があります。
  • 重複するレコードが仮想マシンから配信される場合、Log Analytics エージェントと Azure Monitor エージェントの両方がインストールされている可能性があります。 今後も Log Analytics エージェントをインストールしておく必要がある場合は、Azure Monitor エージェントが使用しているデータ収集ルールによっても収集されているデータが今後は収集されないように、Log Analytics ワークスペースを構成します。

ソリューションと分析情報

Azure Monitor での分析情報とはどのようなものですか?

分析情報では、特定の Azure サービスに対するカスタマイズされた監視エクスペリエンスが提供されます。 Azure Monitor の他の機能と同じメトリックとログが使用されますが、追加データを収集し、Azure portal で独自のエクスペリエンスを提供することができます。 Azure Monitor での分析情報に関する記事をご覧ください。

Azure portal で分析情報を表示するには、 [モニター] メニューの [分析情報] セクション、またはサービスのメニューの [監視] セクションを使用します。

Azure Monitor でのソリューションとは何ですか?

監視ソリューションは、Azure Monitor の機能に基づいて特定のアプリケーションまたはサービスを監視するためのロジックのパッケージ化されたセットです。 Azure Monitor のログ データが収集され、Azure portal の一般的なエクスペリエンスを使用して、分析のためのログ クエリとビューが提供されます。 「Azure Monitor での監視ソリューション」をご覧ください。

Azure portal でソリューションを表示するには、 [モニター] メニューの [分析情報] セクションで [詳細] をクリックします。 [追加] をクリックして、ワークスペースに新しいソリューションを追加します。

ログ

Azure Monitor ログと Azure Data Explorer の違いは何ですか?

Azure Data Explorer は、ログと利用統計情報データのための高速で拡張性に優れたデータ探索サービスです。 Azure Monitor ログは、Azure Data Explorer を基にして構築されており、若干の違いはありますが同じ Kusto クエリ言語 (KQL) を使用します。 「Azure Monitor ログ クエリ言語の違い」をご覧ください。

ログ データはどのようにして取得しますか?

すべてのデータは、Kusto クエリ言語 (KQL) で記述したログ クエリを使用して、Log Analytics ワークスペースから取得します。 独自のクエリを記述したり、特定のアプリケーションまたはサービス用のログ クエリが含まれるソリューションや分析情報を使用したりできます。 「Azure Monitor のログ クエリの概要」をご覧ください。

Log Analytics ワークスペースのデータは削除できますか?

データは、ワークスペースの保有期間に従って削除されます。 プライバシーやコンプライアンス上の理由から、特定のデータを削除することが可能です。 詳細については、「プライベート データをエクスポートして削除する方法」を参照してください。

Log Analytics ストレージは不変ですか?

データベース ストレージのデータは、取り込んだ後に変更することはできませんが、プライベート データを削除するための purge API パスで削除することはできます。 データを変更することはできませんが、一部の認証では、データを不変の状態に保ち、ストレージ内で変更や削除ができないようにする必要があります。 データの不変性は、不変ストレージとして構成されているストレージ アカウントへのデータ エクスポートを使用して実現することができます。

Log Analytics ワークスペースとはどのようなものですか?

Azure Monitor によって収集されたすべてのログ データは、Log Analytics ワークスペースに保存されます。 ワークスペースは、基本的に、さまざまなソースからログ データが収集されるコンテナーです。 すべての監視データに対して 1 つの Log Analytics ワークスペースを使用する場合や、複数のワークスペースが必要な場合があります。 Log Analytics ワークスペース構成の設計 (logs/workspace-design.md) を参照してください。

既存の Log Analytics ワークスペースを別の Azure サブスクリプションに移動できますか?

リソース グループ間またはサブスクリプション間でワークスペースを移動することはできますが、別のリージョンに移動することはできません。 「Log Analytics ワークスペースを別のサブスクリプションまたはリソース グループに移動する」をご覧ください。

Log Analytics でクエリ エクスプローラーと [保存] ボタンが表示されないのはなぜですか?

クエリ エクスプローラー[保存] および [新しいアラート ルール] ボタンは、クエリ スコープが特定のリソースに設定されている場合は使用できません。 アラートを作成し、クエリを保存または読み込むには、Log Analytics のスコープをワークスペースに指定する必要があります。 ワークスペース コンテキストで Log Analytics を開くには、 [Azure Monitor] メニューの [ログ] を選択します。 最後に使用されたワークスペースが選択されますが、その他のワークスペースを選択することはできます。 「Azure Monitor Log Analytics のログ クエリのスコープと時間範囲」を参照してください

VM から Log Analytics を開くときに、"このサブスクリプションのリソース プロバイダー `Microsoft.Insights` を登録してこのクエリを有効にしてください" というエラーが表示されるのはなぜですか?

多くのリソース プロバイダーは自動的に登録されますが、一部のリソース プロバイダーは手動で登録することが必要な場合があります。 登録の範囲は常にサブスクリプションです。 詳細については、「リソース プロバイダーと種類」を参照してください。

VM から Log Analytics を開くときに、アクセス権なしというエラー メッセージが表示されるのはなぜですか?

VM ログを表示するには、VM ログを格納するワークスペースに対する読み取りアクセス許可が付与される必要があります。 このような場合、管理者が Azure でのアクセス許可を付与する必要があります。

テンプレートを使用して AzureDiagnostics テーブルを作成したり、API を使用してスキーマを変更したりできないのはなぜですか?

AzureDiagnostics は、データ インジェストを使用して Log Analytics サービスによって作成される一意のテーブルであり、そのスキーマを構成することはできません。 アイテム保持ポリシーは、テーブルの生成後に適用できます。

メトリック

Azure 仮想マシンのゲスト OS のメトリックがメトリックス エクスプローラーに表示されないのはなぜですか?

プラットフォーム メトリックは、Azure リソースについて自動的に収集されます。 ただし、仮想マシンのゲスト OS からメトリックを収集するには、いくつかの構成を実行する必要があります。 Windows VM の場合は、「Windows Azure Diagnostics 拡張機能 (WAD) のインストールと構成」の説明に従って、診断拡張機能をインストールし、Azure Monitor シンクを構成します。 Linux の場合は、「Linux VM のカスタム メトリックを InfluxData Telegraf エージェントを使用して収集する」の説明に従って、Telegraf エージェントをインストールします。

Prometheus

Azure Monitor ワークスペースとは?

Prometheus 用の Azure Monitor マネージド サービスによって収集された Prometheus メトリック データは、Azure Monitor ワークスペースに格納されます。 これは基本的に、Prometheus メトリック データがさまざまなソース用に格納されるコンテナーです。 すべての Prometheus メトリック データに対して 1 つの Azure Monitor ワークスペースを使用する場合や、複数のワークスペースが必要な場合があります。 追加情報については、「Azure Monitor ワークスペースの概要」を参照してください。

Azure Monitor ワークスペースと Log Analytics ワークスペースの違いは何ですか?

Azure Monitor ワークスペースは、Azure Monitor によって収集されたデータに固有の環境です。 各ワークスペースには、独自のデータ リポジトリ、構成、アクセス許可があります。 Azure Monitor ワークスペースには、ネイティブのメトリックを含め、最終的に Azure Monitor が収集したすべてのメトリック データが含められます。 現時点では、Azure Monitor ワークスペースによってホストされるデータは Prometheus メトリックのみです。 追加情報については、「Azure Monitor ワークスペースの概要」を参照してください。

どうすれば Prometheus メトリック データを取得できますか?

すべてのデータは、Prometheus クエリ言語 (PromQL) で記述されたクエリを使用して、Azure Monitor ワークスペースから取得されます。 独自のクエリを記述することも、オープンソース クエリと、PromQL クエリを含む Grafana ダッシュボード使用することもできます。 詳細については、「Prometheus プロジェクト」を参照してください。

Azure Monitor ワークスペースから Prometheus メトリック データを削除できますか?

データは、データ保持期間 (18 か月) に従って Azure Monitor ワークスペースから削除されます。

Azure Monitor メトリック エクスプローラーで Prometheus メトリックを表示できますか?

Azure Monitor のメトリック エクスプローラーでは、現在、Prometheus メトリック データの視覚化はサポートされていません。 Azure Managed Grafana を使用して、Prometheus 用の Azure Monitor マネージド サービスでメトリックを視覚化する方法を確認してください。

Azure Monitor ワークスペースや Managed Prometheus とは異なるリージョンで Azure Managed Grafana を使用できますか?

はい。Prometheus 用の Azure Monitor マネージド サービスを使用する場合は、サポートされている任意のリージョンに Azure Monitor ワークスペースを作成できます。 Azure Kubernetes Service クラスターは、任意のリージョンに存在することができ、別のリージョンの Managed Prometheus にデータを送信することもできます。 Azure Managed Grafana を、Azure Monitor ワークスペースを作成したリージョンとは異なるリージョンに配置することもできます。

Managed Prometheus を使用する場合、Azure Monitor ワークスペースに複数のクラスターのデータを格納できますか?

はい。Prometheus 用 Azure Monitor マネージド サービスは、複数の Azure Kubernetes Service クラスターのデータを 1 つの Azure Monitor ワークスペースに格納できるシナリオを可能にすることを目的としています。 追加情報については、「Azure Monitor ワークスペースの概要」を参照してください。

どんな種類のリソースによって、Prometheus メトリックを Managed Prometheus に送信できますか?

コレクターを、Azure Kubernetes Service クラスターで使用できます。 これはマネージド アドオンとしてインストールされ、必要なデータを収集し、レプリカ セットとして、またはレプリカ セットおよびクラスター内の各ノードで実行するように構成できます。 また、リモート書き込みを有効にする手順に従って、Azure、別のクラウド、またはオンプレミスで実行されている Kubernetes クラスターでリモート書き込みを構成することもできます。

AKS クラスターで Managed Prometheus を有効にすると、Container Insights も有効になりますか?

Prometheus メトリックを収集する方法には、いくつかのオプションがあります。 Azure portal を使用して Prometheus メトリック収集を有効にし、Azure Monitor ワークスペース UX から AKS アドオンをインストールする場合、Container Insights とログ データの収集は有効になりません。 AKS クラスターの [分析情報] ページに移動すると、ログ データを収集する Container Insights を有効にするように求められます。
Azure portal を使用して Prometheus メトリック収集を有効にし、AKS クラスターの [分析情報] ページから AKS アドオンをインストールする場合には、Logs コレクションと Managed Prometheus への Prometheus メトリック コレクションの両方が有効になります。

変更の分析

Change Analysis の使用にはコストはかかりますか?

Change Analysis は、追加コストなしで使用できます。 Microsoft.ChangeAnalysis リソース プロバイダーを有効にすると、変更分析でサポートされているものはすべて使用できるようになります。

Web アプリケーション用に有効にする方法を教えてください。

問題の診断と解決ツールを使用して、Web アプリケーションのゲスト内の変更用に Change Analysis を有効にします。

警告

Azure Monitor でのアラートとはどのようなものですか?

アラートは、監視データで重要な状態が見つかると事前に通知します。 管理者は、その通知を見て、システムのユーザーが問題に気付く前に問題を識別して対処できます。 アラートには、次のように複数の種類があります。

  • メトリック - メトリックの値が、しきい値を超えました。
  • ログ クエリ - ログ クエリの結果が、定義された条件と一致しました。
  • アクティビティ ログ - アクティビティ ログのイベントが、定義された条件と一致しました。
  • Web テスト - 可用性テストの結果が、定義された条件と一致しました。

Microsoft Azure のアラートの概要」をご覧ください。

アクション グループとはどのようなものですか?

アクション グループとは、アラートによってトリガーできる通知とアクションのコレクションです。 複数のアラートで 1 つのアクション グループを使用して、通知とアクションの共通セットを利用できます。 「Azure portal でのアクション グループの作成および管理」をご覧ください。

アクション ルールとはどのようなものですか?

アクション ルールを使用すると、特定の条件に一致する一連のアラートの動作を変更できます。 このルールにより、メンテナンス期間中にアラート アクションを無効にするなどの要件を実行できます。 また、アラート ルールにアラートを直接適用するのではなく、一連のアラートにアクション グループを適用することもできます。 アクション ルールに関するページをご覧ください。

エージェント

Azure Monitor ではエージェントは必要ですか?

エージェントは、仮想マシン内のオペレーティング システムおよびワークロードからデータを収集するためにのみ必要です。 仮想マシンは、Azure、別のクラウド環境、またはオンプレミスのどこに存在していてもかまいません。 「Azure Monitor エージェントの概要」をご覧ください。

Azure Monitor エージェントの間にはどのような違いがありますか?

Azure Monitor エージェントは、他のレガシ監視エージェントすべての機能を統合し、改善された新しいエージェントで、一元化されたデータ収集、フィルター処理、マルチホームなどの追加の利点も備わっています。 「Azure Monitor エージェントの概要」をご覧ください。
レガシ エージェントには次のものが含まれます。

  • Azure 診断拡張機能は Azure Virtual Machines 用であり、データは Azure Monitor メトリック、Azure Storage、Azure Event Hubs に収集されます。
  • Log Analytics エージェントは、Azure、別のクラウド環境、またはオンプレミスの仮想マシン用であり、データは Azure Monitor ログに収集されます。 これらのエージェントは、2024 年 8 月に非推奨となる予定です。

エージェントのトラフィックでは、ExpressRoute の接続が使用されますか?

Azure Monitor へのトラフィックでは、Microsoft ピアリングの ExpressRoute 回線が使用されます。 さまざまな種類の ExpressRoute トラフィックについては、ExpressRoute のドキュメントをご覧ください。

Log Analytics エージェントが Azure Monitor と通信できることを確認するにはどうすればよいですか?

エージェント コンピューターのコントロール パネルで、[セキュリティ & 設定][Microsoft Monitoring Agent] の順に選択します。 [Azure Log Analytics (OMS)] タブで、緑色のチェック マーク アイコンは、エージェントが Azure Monitor と通信できることを示します。 黄色の警告アイコンは、エージェントに問題があることを示します。 一般的な原因の 1 つは、Microsoft Monitoring Agent サービスが停止したことです。 サービス コントロール マネージャーを使用してサービスを再開します。

Log Analytics エージェントと Azure Monitor の通信を停止するにはどうすればよいですか?

Log Analytics に直接接続されているエージェントの場合は、[コントロール パネル] を開き、[Microsoft Monitoring Agent] を選択します。 [Azure Log Analytics (OMS)] タブで、一覧に表示されているすべてのワークスペースを削除します。 System Center Operations Manager では、Log Analytics マネージド コンピューターの一覧からコンピューターを削除します。 Operations Manager はエージェントの構成を更新して、Log Analytics に報告しなくなるようにします。

エージェントごとにどれくらいのデータが送信されますか?

エージェントごとに送信されるデータ量は、次のものによって異なります。

  • 有効にしているソリューション
  • 収集されているログとパフォーマンス カウンターの数
  • ログ内のデータ量

詳細については、Log Analytics ワークスペースでの使用状況の分析に関するページを参照してください。

WireData エージェントを実行できるコンピューターの場合、どれくらいのデータが送信されているかを確認するには次のクエリを使用します。

WireData
| where ProcessName == "C:\\Program Files\\Microsoft Monitoring Agent\\Agent\\MonitoringHost.exe"
| where Direction == "Outbound"
| summarize sum(TotalBytes) by Computer 

データを Azure Monitor に送信するときに、どれくらいのネットワーク帯域幅が Microsoft Management Agent (MMA) によって使用されますか?

帯域幅は、送信されるデータ量に関する機能です。 データは、ネットワーク経由で送信されるときに圧縮されます。

Log Analytics エージェントからのデータ収集が停止したときに通知を受け取るにはどうすればよいですか?

データ収集が停止したときに通知を受けるには、新しいログ アラートの作成に関する記事で説明されている手順を使用します。 アラート ルールの次の設定を使用します。

  • [アラートの条件を定義します] : リソース ターゲットとして Log Analytics ワークスペースを指定します。
  • [アラートの条件]
    • [シグナル名] : "カスタム ログ検索"
    • [検索クエリ] : Heartbeat | summarize LastCall = max(TimeGenerated) by Computer | where LastCall < ago(15m)
    • [アラート ロジック]: "結果の数"に基づく条件より大きいしきい値0
    • 評価基準: 期間 (分)30頻度 (分)10
  • [アラートの詳細を定義します]
    • Name:"データ収集が停止した"
    • [重大度] :警告

既存または新規のアクション グループを指定して、ログ アラートが条件に一致する場合に、ハートビートが 15 分以上なければ通知が送られるようにします。

Log Analytics エージェントにはファイアウォールに関するどのような要件がありますか?

ファイアウォールの要件について詳しくは、「ネットワーク ファイアウォールの要件」をご覧ください。

Azure Monitor エージェント

AMA を使用するか、Log Analytics エージェント (MMA) から AMA に移行するかしなければならないのはなぜですか?

AMA は、Log Analytics エージェントAzure Diagnostics 拡張機能、および Telegraf エージェントを置き換える機能です。 AMA は、フットプリントが低い EPS のレートが高く、高度なフィルター機能と、DCR ポリシーと Azure ポリシーを使用したスケーラブルなデプロイ管理および構成を提供します。

AMA はまだ MMA と完全に同等というわけではありませんが、Microsoft は機能とサポートの追加を継続しており、MMA は 2024 年 8 月 31 日に廃止される予定です。

詳細については、「Azure Monitor エージェントの概要」を参照してください。

Log Analytics エージェントから Azure Monitor エージェントへのアップグレード パスを教えてください。 移行するにはどうすればよいですか?

Log Analytics エージェントからの移行」を参照してください

System Center Operations Manager を監視するにあたり、Log Analytics エージェント (MMA) から Azure Monitor エージェント (AMA) へのアップグレード パスを教えてください。 System Center Operations Manager シナリオに AMA を使用できますか?

AMA が 2 つの System Center Operations Manager 関連の監視シナリオに与える影響をこちらに示します。

  • シナリオ 1: System Center Operations Manager の Windows オペレーティング システムを監視する。 アップグレード パスは、他のマシンと同じです。この場合は、必要な機能パリティが AMA で満たされた時点ですぐに、MMA (バージョン 2016、2019) から AMA に移行することができます。
  • シナリオ 2: System Center Operations Manager を Log Analytics ワークスペースにオンボードまたは接続する。 これは、Log Analytics または Azure Monitor の System Center Operations Manager コネクタによって実現されるため、Operations Manager 管理サーバーには MMA も AMA もインストールする必要はありません。 そのため、AMA の観点から見れば、このユース ケースへの影響はありません。

新しい Azure Monitor エージェントは、各種の Log Analytics ソリューションと Azure サービス (Microsoft Defender for Cloud、Microsoft Sentinel など) のデータ収集をサポートしますか?

プレビューで現在利用可能な AMA 拡張機能の一覧をご確認ください。 こちらは、新しい Azure Monitor エージェントを代わりに使用した場合に現在利用できるのと同じソリューションとサービスです。 ソリューションやサービスでの必要に応じて、追加のデータを収集したり、変換や処理を実行したりした後、AMA を使用して最終的なデータを Azure Monitor にルーティングするためのソリューションやサービス用に追加の拡張機能がインストールされる場合があります。

以下の図は、新しい拡張アーキテクチャを説明したものです。

拡張機能アーキテクチャ

新しい Azure Monitor エージェントでは、どの Log Analytics ソリューションがサポートされますか?

サポートされているサービスと機能」を参照してください。

新しい Azure Monitor エージェントを使用して Windows セキュリティ イベントを収集する方法はありますか?

セキュリティ イベントの Log Analytics ワークスペースへの送信時に、新しいエージェントを使用して収集するには、次の 2 つの方法があります。

  • AMA を使用すると、他の Windows イベントと同じように、セキュリティ イベントをネイティブに収集できます。 これらは Log Analytics ワークスペースの 'Event' テーブルに送信されます。
  • ワークスペースで Sentinel が有効になっている場合、セキュリティ イベントは、代わりに AMA 経由で 'SecurityEvent' テーブルに送信されます (Log Analytics エージェントを使用する場合と同様)。 この場合、最初にソリューションを有効にする必要があります。

Azure Monitor エージェントと Log Analytics エージェントをサイド バイ サイドで共存させることはできますか?

はい、できます。ただしいくつかの考慮事項があります。 エージェントとの共存について詳細をお読みください。

同じマシン上で Azure Monitor エージェントと Log Analytics エージェントを使用すると、イベントが複製されますか?

両方のエージェントで同じイベントを収集すると、重複が発生します。 この重複は、データ収集ルールによって収集される、ワークスペース構成データからのレガシ エージェントによって取集される重複したデータである可能性があります。 または、レガシ エージェントを使用してセキュリティ イベントを収集し、Microsoft Sentinel の AMA コネクタで Windows セキュリティ イベントを有効にする可能性があります。

重複イベントは、1 つのエージェントから別のエージェントに移行する間だけ制限する必要があります。 DCR を完全にテストし、そのデータ収集を確認したら、ワークスペースに対する収集を無効にして、MMA データ コネクタを切断する必要があります。

Azure Monitor エージェントは Log Analytics エージェントと同じですか?

Log Analytics エージェントと比較した、AMA の現在の制限事項を確認します。

Azure Monitor エージェントは Azure 以外の環境 (他のクラウド、オンプレミスなど) をサポートしますか?

現在のサーバーに Azure Arc エージェントがインストールされていれば、オンプレミス マシンと他のクラウドに接続されたマシンの両方がサポートされます。 AMA と DCR を実行するという目的において、Arc の要件に追加のコストやリソース消費は伴いません。Arc エージェントは、インストール メカニズムとしてのみ使用されるのであり、使用しないのであれば有料の管理機能を有効にする必要はありません。

Azure Monitor エージェントではプライベート リンクをサポートしていますか?

はい。作成されたデータ収集エンドポイントを使用して、Azure Monitor Private Link スコープ (AMPLS) に追加します。 セットアップ手順に従います

AMA では Linux または AUOMS の AuditD ログをサポートしていますか?

はい。ただし、AUOMS を介して Linux 監査ログを収集する AMA の拡張機能として利用できる Defender for Cloud (以前の Azure Security Center) サービスにオンボードする必要があります。

Azure Arc は AAD 参加マシンに必要ですか?

Windows 10 または 11 (クライアント OS) を実行している AAD 参加 (またはハイブリッド AAD 参加) マシンの場合、これらのマシンに Arc をインストールする必要はありません。 代わりに、AMA 用の Windows MSI インストーラーを使用できます (現在プレビューで利用可能)。

AMA を使用するために、Azure Arc Connected Machine エージェントをインストールする必要があるのはなぜですか?

AMA はマネージド ID を介してワークスペースに対して認証します。この ID は、Connected Machine エージェントのインストール時に作成されます。 マネージド ID は、Azure のより安全で管理可能な認証ソリューションです。 レガシ Log Analytics エージェントでは、代わりに、ワークスペース ID およびキーを使用して認証するため、Azure Arc を必要としません。

Azure Arc Connected Machine エージェントをインストールすると、Azure 以外のマシンにどのような影響がありますか?

Azure Arc がインストールされても、マシンへの影響はありません。 システム リソースやネットワーク リソースをほとんど使用せず、実行するホスト上のフットプリントが低くなるように設計されています。

新しい Azure Monitor エージェントでは、どのような種類のマシンがサポートされますか?

Virtual Machines、Virtual Machines Scale Sets、Arc 対応サーバーにそれらを直接インストールできます。 AMA 用の Windows MSI インストーラーを使用して、Windows 10 または 11 を実行しているデバイス (ワークステーション、デスクトップ) にインストールすることもできます (現在プレビューで利用可能)。

イベント ID を使用してイベントをフィルタリングすることはできますか? つまり、新しい Azure Monitor エージェントを使用することで、従来よりも粒度の細かいイベント フィルタリングが可能になりますか?

はい。 Windows イベント ログのフィルタリングに XPath クエリを使用できます。 詳細情報
パフォーマンスカウンターでは、収集する特定のカウンターを指定し、不要なカウンターを除外することができます。 Linux の syslog では、ファシリティとログ レベルを、収集する各ファシリティについて選択できます。

新しい Azure Monitor エージェントは、Event Hubs や Azure ストレージ アカウントへのデータの送信をサポートしますか?

いいえ、まだサポートしていません。ただし将来、AMA と診断拡張機能の集約が始まると、データ収集ルールに加え、新しいエージェントでも、Event Hubs と Azure Storage アカウントの両方へのデータの送信がサポートされる予定です。

新しい Azure Monitor エージェントでは Linux のサポートが強化されていますか?

Linux のサポートはまだ強化されていません。

サーバーからイベントを収集する DCR を作成するために必要なロールは何ですか?

同じイベント ID を含む DCR を作成し、それを同じ VM に関連付けると、イベントは重複しますか?

はい。 重複を回避するために、データ収集ルールで行うイベントの選択に重複イベントが含まれていないことを確認してください。

AMA で XPATH クエリを検証するにはどうしたらいいですか?

Get-WinEvent PowerShell コマンドレット -FilterXPath パラメーターを使用して、XPath クエリの妥当性をテストします。 詳細については、「Windows エージェントベースの接続」の手順に記載されているヒントを参照してください。 Get-WinEvent PowerShell コマンドレットは、最大 23 個の式をサポートしますが、Azure Monitor DCR は最大 20 個の式をサポートします。 また、> 文字と < 文字は、DCR で &gt;&lt; としてエンコードする必要があります。

視覚化

ビュー デザイナーを表示できないのはなぜですか?

ビュー デザイナーは、 Log Analytics ワークスペース内で共同作成者以上のアクセス許可が割り当てられているユーザーのみが使用できます。

Application Insights

構成の問題

次のセットアップで問題が発生しています。

サーバーからデータを取得できません。

"デプロイする必要がある Application Insights リソースの数。 "

Application Insights と共に使用できるもの

これは無料ですか。

はい、試験段階用です。 Basic 価格プランでは、アプリケーションは毎月無料で一定のデータ許容量を送信できます。 無料許容量は、開発や、少数のユーザー向けにアプリを発行するのに十分な大きさです。 指定した以上のデータ量が処理されることを防ぐために上限を設定できます。

上限を超える量のテレメトリは GB 単位で課金されます。 課金額を制限する方法について、こちらでいくつかのヒントを紹介しています。

Enterprise プランでは、テレメトリを送信した Web サーバー ノードごとに、1 日単位で料金が請求されます。 これは、連続エクスポートを大規模に使用する場合に適しています。

価格プランを参照してください

料金はどのくらいですか。

  • Application Insights リソースで [使用量と推定コスト] ページを開きます。 最近の利用状況のグラフが表示されます。 必要に応じて、データ量の上限を設定できます。
  • すべてのリソースの請求書を表示するには:
    1. Azure portal を開きます。
    2. 「コスト管理」を検索し、[コスト分析] ペインを使用して予測コストを表示します。
    3. 「コスト管理と課金」を検索し、[課金スコープ] ペインを開いて、サブスクリプション全体の現在の料金を確認します。

Application Insights によってどのような変更がプロジェクトに加えられますか?

詳細は、プロジェクトの種類によって異なります。 Web アプリケーションの場合:

  • 次のファイルがプロジェクトに追加されます。
    • ApplicationInsights.config
    • ai.js
  • これらの NuGet パッケージをインストールします。
    • Application Insights API - コア API
    • Application Insights API for Web Applications - サーバーからテレメトリを送信するために使用されます
    • Application Insights API for JavaScript Applications - クライアントからテレメトリを送信するために使用されます
  • パッケージには、これらのアセンブリが含まれます。
    • Microsoft.ApplicationInsights
    • Microsoft.ApplicationInsights.Platform
  • 次の項目を挿入します。
    • web.config
    • packages.config
  • (新しいプロジェクトの場合、Application Insights を既存のプロジェクトに手動で追加します)。 これらを Application Insights リソース ID で初期化するためのスニペットを、クライアントとサーバーのコードに挿入します。 たとえば、MVC アプリでは、Views/Shared/_Layout.cshtml マスター ページにコードが挿入されます。

以前のバージョンの SDK からアップグレードする方法。

お使いのアプリケーションに適切な SDK については、「 リリース ノート 」をご覧ください。

自分のプロジェクトがデータを送信する Azure のリソースを変更するにはどうすればいいですか?

ソリューション エクスプローラーで、 ApplicationInsights.config を右クリックし、 [Application Insights の更新] を選択します。 Azure の既存または新規のリソースにデータを送信できます。 更新ウィザードでは、サーバー SDK のデータの送信先を決定する、ApplicationInsights.config のインストルメンテーション キーを変更します。 [すべて更新] を選択解除している場合を除き、Web ページ内のキーが表示される場所でもキーが変更されます。

新しい Azure リージョンでは、接続文字列を使用する必要がありますか。

新しい Azure リージョンでは、インストルメンテーション キーの代わりに接続文字列を使用する必要があります。 接続文字列により、利用統計情報と関連付けるリソースが識別されます。 また、リソースでテレメトリの宛先として使用するエンドポイントを変更することもできます。 接続文字列をコピーし、アプリケーションのコードまたは環境変数に追加する必要があります。

接続文字列またはインストルメンテーション キーを使用する必要はありますか?

インストルメンテーション キーよりも、接続文字列を使用することをお勧めします。

Azure Resource Manager のデプロイで `providers('Microsoft.Insights', 'components').apiVersions[0]` を使用できますか?

API バージョンの設定に、この方法を使用することは推奨されません。 最新バージョンは、破壊的変更を含んでいる可能性があるプレビュー リリースを表す場合があります。 新しいプレビュー以外のリリースでも、API バージョンが必ずしも既存のテンプレートと下位互換性を持っているとは限りません。場合によっては、API バージョンがすべてのサブスクリプションで使用できない可能性もあります。

Application Insights では、どのようなテレメトリが収集されますか?

サーバーの Web アプリから:

クライアントの Web ページから:

その他のソースから (構成する場合):

一部のテレメトリを除外または変更することはできますか?

はい。サーバーで以下のようなものを記述できます。

  • 選択されたテレメトリ項目に対して、それがアプリから送信される前にフィルター処理やプロパティの追加を行うテレメトリ プロセッサ。
  • テレメトリの全項目にプロパティを追加するテレメトリ初期化子。

ASP.NET の場合はこちら、Java の場合はこちらで詳細を確認してください。

市区町村や国や地域などの geo ロケーション データはどのように計算されますか?

Web クライアントの IP アドレス (IPv4 または IPv6) を検索します。

  • ブラウザー テレメトリ:送信者の IP アドレスを収集します。
  • サーバー テレメトリ:Application Insights モジュールでクライアントの IP アドレスが収集されます。 X-Forwarded-For が設定されている場合は収集されません。
  • Application Insights で IP アドレスと geo ロケーション データが収集される方法の詳細については、こちらの記事を参照してください。

別のヘッダーから IP アドレスを取得するように ClientIpHeaderTelemetryInitializer を構成できます。 たとえば一部のシステムでは、プロキシ、ロード バランサー、または CDN によって X-Originating-IP に移動されます。 詳細については、こちらを参照してください

ワークスペースベースのリソースに移行した場合は、Power BI を使用してマップに要求テレメトリを表示できます。

ポータルでのデータ保持期間はどのくらいですか? セキュリティで保護されていますか?

データの保持とプライバシーに関するページをご覧ください。

サーバーまたはデバイスが Azure との接続を失った場合、Application insights のテレメトリはどうなりますか?

Web SDK を含むすべての SDK には、"信頼できるトランスポート" または "堅牢なトランスポート" が含まれています。 サーバーまたはデバイスが Azure との接続を失った場合、テレメトリはローカルにファイル システム (サーバー SDK) に、または HTML5 セッション ストレージ (Web SDK) に格納されます。 SDK は、インジェスト サービスが "古い" と見なすまで (ログの場合は 48 時間、メトリックの場合は 30 分)、このテレメトリの送信を定期的に再試行します。 古いテレメトリは削除されます。 ローカル ストレージがいっぱいになった場合など、場合によっては再試行は行われません。

テレメトリで個人データが送信されることはありますか?

コードでそのようなデータが送信される場合は、個人データを送信できます。 また、スタック トレース内の変数に個人データが含まれている場合にも、送信される可能性があります。 その個人データの処理が適切に行われるように、開発チームでリスク評価を実施する必要があります。 こちらから、データ リテンション期間とプライバシーについての詳細を確認してください。

geo ロケーション属性の検索後、クライアント Web アドレスのすべてのオクテットは常に 0 に設定されます。

Application Insights JavaScript SDK には、既定では、オートコンプリートに個人データは含まれていません。 ただし、アプリケーションで使用されている個人データの一部が SDK によって取得される場合があります (たとえば、window.title の完全名や、XHR URL クエリ パラメーターのアカウント ID など)。 カスタム個人データ マスキングの場合は、テレメトリ初期化子を追加します。

Web ページのソースに自分のインストルメンテーション キーが表示されます。

  • この表示は、監視ソリューションにおいてはよくあることです。
  • iKey を使用してデータを盗むことはできません。
  • データ スキューやアラートのトリガーに使用される可能性はあります。
  • これまでに、お客様がそのような問題に遭遇したという事例は報告されていません。

以下のような方法で対処できます。

  • クライアント データとサーバー データに 2 つの独立したインストルメンテーション キー (別々の Application Insights リソース) を使用します。 または
  • サーバーで実行するためのプロキシを記述し、Web クライアントからそのプロキシを介してデータを送信します。

診断検索で POST データを表示する方法を教えてください。

POST データは自動ではログに記録されませんが、TrackTrace 呼び出しを使用してメッセージ パラメーターにデータを格納できます。 メッセージ パラメーターのサイズ制限は、文字列プロパティの制限よりも長いものの、フィルター処理には使用できません。

Application Insights リソースは、単一リソースと複数リソースのどちらを使用すべきですか?

1 つのビジネス システム内のすべてのコンポーネントまたはロールに対しては、単一リソースを使用します。 開発、テスト、およびリリースのバージョン、および独立したアプリケーションに対しては、複数のリソースを使用します。

インストルメンテーション キーを動的に変更するには、どうすればよいですか?

ユーザー数とセッション数とは何ですか?

  • JavaScript SDK では、Web クライアントにユーザー Cookie を設定することで戻ってきたユーザーを識別し、セッション Cookie を設定することでグループ アクティビティを識別します。
  • クライアント側のスクリプトがない場合は、サーバーで Cookie を設定できます。
  • 1 人の実在するユーザーが、複数の異なるブラウザーや、プライベート/シークレット ブラウズ、または複数のコンピューターでサイトを利用した場合、それらは複数のユーザーとしてカウントされます。
  • 複数のコンピューターやブラウザー間でログイン済みのユーザーを識別するには、setAuthenticatedUserContext() の呼び出しを追加します。

Application Insights では、デバイス情報 (ブラウザー、OS、言語、モデル) はどのように生成されるのですか?

ブラウザーによって、要求の HTTP ヘッダーでユーザー エージェント文字列が渡されます。Application Insights インジェスト サービスでは、UA パーサーを使用して、データ テーブルとエクスペリエンスに表示されるフィールドが生成されます。 その結果、Application Insights ユーザーはこれらのフィールドを変更できなくなります。

ユーザーまたはエンタープライズがブラウザーの設定でユーザー エージェントの送信を無効にした場合、このデータが失われたり不正確になったりすることがあります。 UA パーサーの正規表現にすべてのデバイス情報が含まれていない場合や Application Insights に最新の更新プログラムが適用されていない場合があります。

Application Insights の機能をすべて有効にしているでしょうか?

表示内容 表示方法 用途
可用性グラフ Web テスト Web アプリが稼働しているか確認する
サーバー アプリ パフォーマンス: 応答時間、... Application Insights をプロジェクトに追加するか、Azure Monitor Application Insights Agent をサーバーにインストールする (または独自のコードを記述して依存関係を追跡する) パフォーマンスの問題を検出する
依存関係テレメトリ サーバーに Azure Monitor Application Insights Agent をインストールする データベースや、その他の外部コンポーネントの問題を診断する
例外からスタック トレースを取得する コード内に TrackException 呼び出しを挿入する (自動で報告されるものもある) 例外を検出して診断する
ログ トレースの検索 ログ アダプターを追加する 例外、パフォーマンスの問題を診断する
クライアントの利用状況の基本情報: ページ ビュー、セッション、... Web ページの JavaScript の初期化子 Usage analytics
クライアントのカスタム メトリック Web ページでの呼び出しの追跡 ユーザー エクスペリエンスを向上させる
サーバーのカスタム メトリック サーバーでの呼び出しの追跡 Business intelligence

検索グラフとメトリック グラフで数が等しくないのはなぜですか?

サンプリングにより、アプリからポータルに送信されたテレメトリ項目 (要求、カスタム イベントなど) の数が減少します。 [検索] には、受信した項目の数が表示されます。 イベント数を表示するメトリック グラフには、発生した元のイベントの数が表示されます。

送信される各項目には、その項目が表す元のイベントの数を示す itemCount プロパティが含まれています。 Analytics で次のクエリを実行すると、サンプリング操作を確認できます。

    requests | summarize original_events = sum(itemCount), transmitted_events = count()

Application Insights リソースを新しいリージョンに移動するにはどうすればよいですか?

既存の Application Insights リソースをあるリージョンから別のリージョンに移動することは、現在サポートされていません。 収集した履歴データは、新しいリージョンに移行できません。 唯一の部分的な回避策は次のとおりです。

  1. 新しいリージョンに新しい Application Insights リソース (クラシックまたはワークスペースベース) を作成します。
  2. 元のリソースに固有のすべての独自のカスタマイズを新しいリソースに再作成します。
  3. 新しいリージョン リソースのインストルメンテーション キーまたは接続文字列を使用するようにアプリケーションを変更します。
  4. 新しい Application Insights リソースで引き続きすべてが期待どおりに動作していることをテストして確認します。
  5. この時点で、元の Application Insights リソースを保持または削除できます。 従来の Application Insights リソースを削除すると、すべての履歴データが失われます。 元のリソースがワークスペースベースの場合、そのデータは Log Analytics に残ります。 元の Application Insights リソースを保持すると、データ保持設定が切れるまでその履歴データにアクセスできます。

新しいリージョンのリソースに対して、通常、手動で再作成または更新する必要がある独自のカスタマイズには、以下のものがありますが、これらに限定されるものではありません。

  • カスタム ダッシュボードとブックを再作成します。
  • カスタム ログまたはメトリック アラートのスコープを再作成または更新します。
  • 可用性アラートを再作成します。
  • ユーザーが新しいリソースにアクセスするために必要なカスタムの Azure ロールベースのアクセス制御 (Azure RBAC) 設定を再作成します。
  • インジェスト サンプリング、データ保有、日次上限、およびカスタム メトリックの有効化を含む設定をレプリケートします。 これらの設定は、 [使用量と推定コスト] ペインで制御します。
  • リリース注釈ライブ メトリックと安全なコントロール チャネルなど、API キーに依存するすべての統合。新しい API キーを生成し、関連する統合を更新する必要があります。
  • クラシック リソースの連続エクスポートを再構成する必要があります。
  • ワークスペースベースのリソースの診断設定を再構成する必要があります。

Note

新しいリージョンで作成するリソースによってクラシック リソースが置き換えられる場合は、新しいワークスペースベースのリソースを作成することのメリットを検討するか、または既存のリソースをワークスペースベースに移行することをお勧めします。

Automation

Application Insights の構成

Azure Resource Monitor を使用して PowerShell スクリプトを記述することにより、以下の操作を実行できます。

  • Application Insights リソースの作成と更新。
  • 価格プランの設定。
  • インストルメンテーション キーの取得。
  • メトリック アラートの追加。
  • 可用性テストの追加。

メトリックス エクスプローラー レポートや連続エクスポートの設定はできません。

テレメトリに対するクエリの実行

REST API を使用して Analytics クエリを実行します。

イベントにアラートを設定するには、どうすればよいですか?

Azure アラートはメトリックにのみ設定できます。 イベントが発生するたびにしきい値を超える、カスタム メトリックを作成してください。 その後、メトリックにアラートを設定します。 メトリックがどちらの方向であれしきい値を超えると必ず、通知を受け取ります。初期値が高くても低くても、最初に超えるまでは通知を受け取りません。常に数分の待ち時間が発生します。

Azure Web アプリと Application Insights の間でデータ転送料金は発生しますか?

  • Application Insights の収集エンドポイントがあるデータ センターで Azure Web アプリがホストされている場合、料金はかかりません。
  • ホスト データ センターに収集エンドポイントがない場合は、アプリのテレメトリに対して Azure の送信料金が発生します。

この回答は、Application Insights リソースがホストされている場所ではなく、エンドポイントの分散によって異なります。

テレメトリを Application Insights ポータルに送信できますか?

Microsoft の SDK と SDK API を使用することをお勧めします。 各種プラットフォーム向けに異なる SDK が用意されています。 これらの SDK では、バッファリング、圧縮、調整、再試行などを処理します。 ただし、取り込みスキーマエンドポイント プロトコルはパブリックです。

イントラネット Web サーバーを監視できますか?

はい。ただし、ファイアウォールの例外またはプロキシによるリダイレクトを使用して、Microsoft のサービスへのトラフィックを許可する必要があります。

  • QuickPulse https://rt.services.visualstudio.com:443
  • ApplicationIdProvider https://dc.services.visualstudio.com:443
  • TelemetryChannel https://dc.services.visualstudio.com:443

ここでサービスと IP アドレスのすべての一覧を確認できます。

ファイアウォールの例外

ご利用の Web サーバーから Microsoft のエンドポイントへの利用統計情報の送信を許可します。

ゲートウェイのリダイレクト

構成内のエンドポイントを上書きすることによって、ご利用のサーバーからのトラフィックをイントラネット上のゲートウェイにルーティングします。 これらの "Endpoint" プロパティが config に存在しない場合、これらのクラスでは、次の ApplicationInsights.config の例に示されているように、既定値が使用されます。

ご利用のゲートウェイは、Microsoft のエンドポイントのベース アドレスにトラフィックをルーティングする必要があります。 構成内の既定値を http://<your.gateway.address>/<relative path> に置き換えてください。

既定のエンドポイントを使用する ApplicationInsights.config の例:

<ApplicationInsights>
  ...
  <TelemetryModules>
    <Add Type="Microsoft.ApplicationInsights.Extensibility.PerfCounterCollector.QuickPulse.QuickPulseTelemetryModule, Microsoft.AI.PerfCounterCollector">
      <QuickPulseServiceEndpoint>https://rt.services.visualstudio.com/QuickPulseService.svc</QuickPulseServiceEndpoint>
    </Add>
  </TelemetryModules>
    ...
  <TelemetryChannel>
    <EndpointAddress>https://dc.services.visualstudio.com/v2/track</EndpointAddress>
  </TelemetryChannel>
  ...
  <ApplicationIdProvider Type="Microsoft.ApplicationInsights.Extensibility.Implementation.ApplicationId.ApplicationInsightsApplicationIdProvider, Microsoft.ApplicationInsights">
    <ProfileQueryEndpoint>https://dc.services.visualstudio.com/api/profiles/{0}/appId</ProfileQueryEndpoint>
  </ApplicationIdProvider>
  ...
</ApplicationInsights>

Note

ApplicationIdProvider は v2.6.0 以降で使用できます。

プロキシのパススルー

プロキシのパススルーは、マシン レベルとアプリケーション レベルのどちらかのプロキシを構成することで実現できます。 詳細については、DefaultProxy に関する dotnet の記事を参照してください。

Web.config の例:

<system.net>
    <defaultProxy>
      <proxy proxyaddress="http://xx.xx.xx.xx:yyyy" bypassonlocal="true"/>
    </defaultProxy>
</system.net>

イントラネット サーバーで可用性 Web テストを実行できますか?

Microsoft の Web テストは、世界中に分布する Points of Presence で実行されます。 以下に示す 2 つのソリューションがあります。

  • ファイアウォール ドア - 頻繁に変更される多数の Web テスト エージェントからのサーバーへの要求を許可します。
  • イントラネット内部からサーバーに定期的な要求を送信する独自のコードを記述します。 Visual Studio Web テストを実行して、このコードをテストすることができます。 テストの結果は TrackAvailability() API を使用して Application Insights に送信できます。

テレメトリの収集にはどれくらいの時間がかかりますか?

Application Insights のほとんどのデータは、待ち時間が 5 分未満となっています。 一部のデータ (通常は、大きなログ ファイル) については、それよりも時間がかかることがあります。 詳細については、「Application Insights の SLA」を参照してください。

HTTP 502 および 503 の応答は Application Insights によって常にキャプチャされるわけではありません

"502 無効なゲートウェイです" エラーと "503 サービスを利用できません" エラーは、Application Insights によって常にキャプチャされるわけではありません。 クライアント側の JavaScript が監視に使用されている場合にのみ、これは予期される動作となります。監視 JavaScript スニペットが表示されている HTML ヘッダーを含むページの前でエラー応答が返されるためです。

サーバー側の監視が有効になっているサーバーから 502 または 503 の応答が送信された場合は、Application Insights SDK によってエラーが収集されます。

ただし、アプリケーションの Web サーバーでサーバー側の監視が有効になっていても、Application Insights によって 502 エラーまたは 503 エラーがキャプチャされない場合もあります。 多くの最新の Web サーバーでは、クライアントが直接通信することはできませんが、代わりにリバース プロキシなどのソリューションを使用して、クライアントとフロントエンド Web サーバーの間で情報をやり取りすることはできます。

このシナリオでは、リバース プロキシ レイヤーでの問題により、502 または 503 の応答がクライアントに返されますが、Application Insights によってすぐにキャプチャされることはありません。 このレイヤーでの問題を検出するには、リバース プロキシから Log Analytics にログを転送し、502/503 の応答を確認するためのカスタム ルールを作成する必要があります。 502 エラーと 503 エラーの一般的な原因の詳細については、Azure App Service の "502 無効なゲートウェイです" と "503 サービスを利用できません" のトラブルシューティングに関する記事を参照してください。

OpenTelemetry

OpenTelemetry とは何ですか?

監視のための新しいオープンソース標準です。 詳細については、https://opentelemetry.io/ をご覧ください。

Microsoft Azure Monitor Application Insights が OpenTelemetry に投資しているのはなぜですか?

Microsoft は、OpenTelemetry への最大のコントリビューターの 1 つです。

OpenTelemetry の重要な価値提案は、ベンダーに中立であることと、言語間で一貫した API/SDK を提供することです。

時間が経つにつれ、OpenTelemetry によって Azure Monitor のお客様は、Microsoft がサポートしている言語以外の言語で記述されたアプリケーションを監視できるようになり、お客様が使用できるインストルメンテーション ライブラリの数が増加すると確信してています。 特に、OpenTelemetry .NET SDK は、前身である Application Insights SDK よりも大幅にパフォーマンスが向上しています。

最後に、OpenTelemetry はオープン ソースを採用するという Microsoft の戦略に一致しています。

OpenTelemetry の状態はどうなっていますか?

完全な監視ソリューションには、監視の 3 つの柱すべてが含まれています。 OpenTelemetry コミュニティは、2021 年 2 月に安定版の分散トレースをリリースし、2022 年 3 月に安定版のメトリックをリリースしました。 Azure Monitor の OpenTelemetry ベースのオファリングには、これら 2 つの柱が含まれています。 OpenTelemetry コミュニティは、API/SDK 仕様のログ記録の安定化に積極的に取り組んでおり、Microsoft では後続のマイルストーンで OpenTelemetry ベースのオファリングにログ記録を追加する予定です。

OpenTelemetry をテストするにはどうしたらよいですか?

.NET、Java、JavaScript (Node.js)、Python の有効化に関するドキュメントを確認してください。また、https://aka.ms/AzMonOtel にサインアップし、Azure Monitor Application Insights 早期導入者コミュニティに参加すると、メジャー リリースの通知を受け取れます。

各 OpenTelemetry オファリング内の機能は、現在どんなリリース状態ですか?

次のグラフは、各言語に対する OpenTelemetry 機能のサポートを示しています。

機能 .NET Node.js Python Java
分散トレース ⚠️ ⚠️ ⚠️
カスタム メトリック ⚠️ ⚠️ ⚠️
標準メトリック (現状、精度はサンプリングの影響を受けます) ⚠️ ⚠️ ⚠️
固定レート サンプリング ⚠️ ⚠️ ⚠️
オフライン ストレージと自動再試行 ⚠️ ⚠️ ⚠️
例外のレポート ⚠️ ⚠️ ⚠️
ログ収集
Azure Active Directory (AAD) 認証
Azure でのクラウド ロール名/ロール インスタンスの自動設定
ライブ メトリック
ユーザー ID、認証されたユーザー ID、ユーザー IP の自動設定
操作名、ユーザー ID、または認証されたユーザー ID の手動オーバーライド/設定
アダプティブ サンプリング
Profiler ⚠️
スナップショット デバッガー

キー

  • ✅ : この機能は、正式なサポートを受けるすべてのお客様が利用できます。
  • ⚠️ : この機能は、パブリック プレビューとして利用できます。 Microsoft Azure プレビューの使用条件に関する補足
  • ❌ : この機能は利用できないか、適用外です。

OpenTelemetry は Web ブラウザーで使用できますか?

はい。ただし、Azure では推奨もサポートもされていません。 OpenTelemetry JavaScript は、Node.js 用に非常に最適化されています。 代わりに、Application Insights JavaScript SDK を使用することをお勧めします。

Web ブラウザーで OpenTelemetry SDK を使用できるようになるのはいつですか?

OpenTelemetry Web SDK の提供時期は未定ですが、Application Insights JavaScript SDK の代替となるブラウザー SDK が登場するのは数年先になる可能性があります。

現在、Web ブラウザーで OpenTelemetry をテストできますか?

OpenTelemetry Web Sandbox は、ブラウザーで OpenTelemetry を動作させるように設計されたフォークですが、Application Insights または 1DS Collector にテレメトリを送信することはまだできません。 さらに、この SDK では現在、一般的なクライアント イベントが定義されていません。

操作方法 OpenTelemetry が自分に適しているかどうかを判断するにはどうすればよいですか?

OpenTelemetry コミュニティでは、stable (安定版) または experimental (試験段階) を使用して、ソフトウェアの成熟度を示します。 これとは別に、Azure Monitor では "パブリック プレビュー" と "GA" を使用して安定性を示し、コミットメントをサポートします。

アプリケーションが Java で記述されている場合は、2020 年 11 月に一般提供された OpenTelemetry ベースのオファリングをすべてのユーザーにお勧めします。

アプリケーションが C#、JavaScript (Node.js)、または Python で記述される場合、現在の Application Insights SDK は最も機能豊富なエクスペリエンスを提供します。

すぐにでも OpenTelemetry への移行を検討する可能性のあるシナリオには、Azure Monitor と別のベンダーに同時にテレメトリを送信する、既存のインストルメンテーション プロトコルを収集して収束する、OpenTelemetry-Collector で利用可能な機能を活用するなどがあります。 たとえば、お客様は、バッチ プロセッサ末尾ベースのサンプラー属性プロセッサの使用を報告しています。 既存の Application Insights SDK にも同様の機能が存在しますが、この処理をエージェントのダウンストリームでホストすることを好むお客様もいます。

オープンソース リポジトリで、C#JavaScript、および Python の OpenTelemetry ベースの Azure Monitor エクスポーター向けの進捗状況を確認できます。

競合他社のエージェントと共に Application Insights を実行することはサポートされていますか? (たとえば、AppDynamics、DataDog、NewRelic など)

いいえ。 これに対するテストまたはサポートの予定はありませんが、OpenTelemetry ベースのオファリングでは、Azure Monitor と共に同時に OTLP エンドポイントにエクスポートできます。

運用環境でプレビュー ビルドを使用できますか?

それはお勧めしません。 詳細については、「Microsoft Azure プレビューの追加使用条件」を参照してください。

Azure Monitor には "OpenTelemetry ディストリビューション" がありますか?

OpenTelemetry では、ディストリビューションを "一部のカスタマイズを含むアップストリーム OpenTelemetry リポジトリのラッパー" として定義しています。 この意味では、Java、Python、JavaScript (Node.js) OpenTelemetry ベースのオファリングは、簡単に有効化できるように、いくつかのコンポーネントをパッケージ化しているため、"ディストリビューション" です。 これらのディストリビューションには、Azure Monitor Application Insights で最適なエクスペリエンスを実現するための Azure 固有のコンポーネント (オフライン ストレージを備えた Azure Monitor Exporter、カスタム サンプラーなど) が含まれます。 場合によっては、お客様はディストリビューションではなく、"段階的なアプローチ" を使用してインストルメント化することを望む場合があります。 このような場合、お客様はエクスポーターを直接使用でき、自己責任で実装に適したパッケージをすべて取り込むことになります。 現時点では、.NET では段階的なアプローチのために OpenTelemetry エクスポーターのみが提供されていますが、将来的には、一般的なテレメトリ シナリオに対応するディストリビューションも用意される予定です。

手動インストルメンテーションと自動インストルメンテーションの違いは何ですか?

手動インストルメンテーションは OpenTelemetry API に対するコーディングであり、通常はアプリケーションに言語固有の SDK をインストールすることで構成されます。 "手動" は、分散トレースのスパンを定義するための複雑なコードを記述する必要があることを示しているわけではありません (ただし、これはオプションとして残されています)。 OpenTelemetry のコントリビューターによって管理されている豊富で拡大しているインストルメンテーション ライブラリのセットにより、共通のフレームワークとライブラリ全体でテレメトリ信号を簡単にキャプチャできます。

自動インストルメンテーションは、アプリケーションのコードに触れることなく、構成を通じてテレメトリ収集を可能にします。 非常に便利ですが、構成が難しい傾向があり、すべての言語で利用できるわけではありません。

OpenTelemetry の自動インストルメンテーションの取り組みには、Microsoft が Java 3.X と呼ばれるディストリビューションを介してサポートする Java オファリングが含まれます。 Python.NET には、現在、Microsoft がサポートしていない試験段階の自動インストルメンテーションの取り組みがあります。 その他のすべての OpenTelemetry 言語は、手動インストルメンテーションにのみ重点を置いています。

OpenTelemetry-Collector を使用できますか?

Microsoft がアプリケーション監視のためのエージェントベースのアプローチをまだ正式にサポートしていないにもかかわらず、一部のお客様は、エージェントの代替として OpenTelemetry-Collector を使用し始めています。 その間、オープン ソース コミュニティは OpenTelemetry-Collector Azure Monitor エクスポーターを提供してきました。一部のお客様は、これを使用してデータを Azure Monitor Application Insights に送信しています。

詳細と予定はまだ公表されていませんが、Microsoft では将来的にエージェントベースのアプローチをサポートする予定です。 Microsoft の目的は、OpenTelemetry プロトコル (OTLP) を介して、OpenTelemetry でサポートされている任意の言語が Azure Monitor に送信するためのパスを提供することです。 これにより、お客様は、サポートされている言語以外の言語で記述されたアプリケーションを監視できるようになります。

OpenCensus と OpenTelemetry の違いは何ですか?

OpenCensusOpenTelemetry の前段階です。 Microsoft は、OpenTracing と OpenCensus を統合して、世界の単一の監視標準である OpenTelemetry の作成を支援しました。 Azure Monitor の現在の運用環境で推奨されている Python SDK は OpenCensus に基づいていますが、最終的には、すべての Azure Monitor の SDK が OpenTelemetry に基づくようになります。

Container insights

ノード ビューで [その他のプロセス] は何を表していますか?

[その他のプロセス] は、ノードのリソース使用率が高い根本原因を明確に理解するのに役立つことを目的としています。 これによって、コンテナー化されたプロセスとコンテナー化されていないプロセスで使用率を区別できます。

これらの [その他のプロセス] とは何ですか?

これらは、ノードで実行されるコンテナー化されていないプロセスです。

これはどのようにして計算しますか?

その他のプロセス = CAdvisor からの合計使用量 - コンテナー化されたプロセスからの使用量

[その他のプロセス] には、次のものが含まれます。

  • 自己管理型またはマネージド Kubernetes のコンテナー化されていないプロセス
  • コンテナーの実行時プロセス
  • kubelet
  • ノードで実行されているシステム プロセス
  • ノード ハードウェアまたは VM 上で実行されている Kubernetes 以外の他のワークロード

ContainerLog テーブルのクエリを実行したとき、Image プロパティと Name プロパティの値が出力されません。

エージェント バージョン ciprod12042019 以降では、ログ データの収集にかかるコストを最小限に抑えるため、既定では、これら 2 つのプロパティはすべてのログ行には出力されません。 これらのプロパティとその値を含めるようにテーブルをクエリする 2 つの方法があります。

方法 1

他のテーブルを結合して、これらのプロパティ値を結果に含めます。

ContainerID プロパティに結合することによって ContainerInventory テーブルの Image プロパティと ImageTag プロパティを含めるようにクエリを変更します。 ContainerID プロパティに結合することによって、KubepodInventory テーブルの ContaineName フィールドから (以前に ContainerLog テーブルにあったときのように) Name プロパティを含めることができます。 このオプションを選択することをお勧めします。

次の例は、結合を使用してこれらのフィールド値を取得する方法を説明するサンプルの詳細なクエリです。

//lets say we are querying an hour worth of logs
let startTime = ago(1h);
let endTime = now();
//below gets the latest Image & ImageTag for every containerID, during the time window
let ContainerInv = ContainerInventory | where TimeGenerated >= startTime and TimeGenerated < endTime | summarize arg_max(TimeGenerated, *)  by ContainerID, Image, ImageTag | project-away TimeGenerated | project ContainerID1=ContainerID, Image1=Image ,ImageTag1=ImageTag;
//below gets the latest Name for every containerID, during the time window
let KubePodInv  = KubePodInventory | where ContainerID != "" | where TimeGenerated >= startTime | where TimeGenerated < endTime | summarize arg_max(TimeGenerated, *)  by ContainerID2 = ContainerID, Name1=ContainerName | project ContainerID2 , Name1;
//now join the above 2 to get a 'jointed table' that has name, image & imagetag. Outer left is safer in-case there are no kubepod records are if they are latent
let ContainerData = ContainerInv | join kind=leftouter (KubePodInv) on $left.ContainerID1 == $right.ContainerID2;
//now join ContainerLog table with the 'jointed table' above and project-away redundant fields/columns and rename columns that were re-written
//Outer left is safer so you don't lose logs even if we can't find container metadata for loglines (due to latency, time skew between data types etc...)
ContainerLog
| where TimeGenerated >= startTime and TimeGenerated < endTime
| join kind= leftouter (
  ContainerData
) on $left.ContainerID == $right.ContainerID2 | project-away ContainerID1, ContainerID2, Name, Image, ImageTag | project-rename Name = Name1, Image=Image1, ImageTag=ImageTag1

方法 2

すべてのコンテナー ログ行について、これらのプロパティの収集を再び有効にします。

クエリの変更を伴うため最初の方法が難しい場合、データ収集の構成設定に関するページの説明に従い、エージェントの構成マップで log_collection_settings.enrich_container_logs 設定を有効にすると、これらのフィールドの収集を再び有効にすることができます。

注意

2 番目の方法は、50 を超えるノードを持つ大規模なクラスターでは推奨されません。このエンリッチメントを実行するために、クラスター内のすべてのノードから API サーバー呼び出しが生成されるからです。 この方法を使用すると、収集されるすべてのログ行のデータ サイズも増加します。

Grafana で収集されたメトリックを表示できますか?

Container insights では、Grafana ダッシュボードの Log Analytics ワークスペースに格納されているメトリックの表示がサポートされています。 Grafana のダッシュボード リポジトリからダウンロードできるテンプレートが用意されています。これを使って作業を開始し、監視対象クラスターからデータのクエリを実行して、カスタム Grafana ダッシュボードで視覚化する方法を学習できます。

Container insights を使用して AKS エンジン クラスターを監視することはできますか?

Container insights では、Azure をホストとする AKS エンジン (旧称 ACS エンジン) クラスターにデプロイされたコンテナー ワークロードの監視をサポートしています。 このシナリオでの監視を有効にするために必要な手順の概要および詳細については、AKS エンジンへの Container insights の使用に関するページをご覧ください。

Log Analytics ワークスペースにデータが表示されないのはなぜですか

Log Analytics ワークスペースで、毎日特定の時間にデータが表示されない場合は、既定の 500 MB の制限に達したか、または毎日収集するデータ量を制御するために指定された 1 日の上限に達している可能性があります。 その日の上限に達すると、データ収集が停止し、次の日にしか再開されません。 データ利用状況を確認して、予期される利用パターンに基づいて別の価格レベルに更新するには、Azure Monitor Logs の価格詳細に関する記事をご覧ください。

ContainerInventory テーブルではどのようなコンテナーの状態が指定されますか

ContainerInventory テーブルには、停止中と実行中両方のコンテナーに関する情報が含まれています。 テーブルの値は、エージェント内のワークフローによって設定されます。このワークフローでは、Docker に対してすべてのコンテナー (実行中と停止) のクエリが実行され、そのデータが Log Analytics ワークスペースに転送されます。

"サブスクリプション登録がない" エラーを解決するにはどうすればよいですか

"Microsoft.OperationsManagement へのサブスクリプション登録がない" というエラーが表示される場合は、ワークスペースが定義されているサブスクリプションでリソース プロバイダー Microsoft.OperationsManagement を登録することで解決できます。 これを行う方法に関するドキュメントは、こちらにあります。

Kubernetes RBAC 対応の AKS クラスターはサポートされていますか。

コンテナー監視ソリューションでは Kubernetes RBAC がサポートされていませんが、Container insights ではサポートされています。 これらのクラスターのデータが示されるペインでは、ソリューションの詳細ページに正しい情報が表示されない場合があります。

Helm を使用して kube システム名前空間内のコンテナーのログ収集を有効にするにはどうすればよいですか

Kube システム名前空間内のコンテナーからのログ収集は、既定では無効になっています。 ログ収集は、Azure Monitor エージェントに環境変数を設定することによって有効にできます。 詳細については、Container insights の GitHub ページをご覧ください。

Container Insights の Azure Monitor エージェントを最新のリリース バージョンに更新するにはどうすればいいですか?

エージェントをアップグレードする方法については、エージェントの管理に関する記事をご覧ください。

ログ行が 16 KB を超えると Log Analytics で複数のレコードに分割されるのはなぜですか?

エージェントは、Docker JSON ファイル ログ ドライバーを使用して、コンテナーの stdout と stderr を取り込みます。 このログ ドライバーでは、16 KB を超えるログ行を stdout または stderr からファイルにコピーするときに、複数の行に分割します。

複数行のログ記録を有効にするにはどうすればよいですか

現在、Container insights では複数行のログ記録はサポートされていませんが、回避策はあります。 JSON 形式で書き込むようにすべてのサービスを構成することができ、Docker/Moby ではそれが単一行として書き込まれます。

たとえば、サンプルの Node.js アプリケーションに対する次の例で示すように、JSON オブジェクトとしてログをラップすることができます。

console.log(json.stringify({ 
      "Hello": "This example has multiple lines:",
      "Docker/Moby": "will not break this into multiple lines",
      "and you'll receive":"all of them in log analytics",
      "as one": "log entry"
      }));

このデータは、クエリを実行すると、Azure Monitor のログに次の例のように表示されます。

LogEntry : ({"Hello": "This example has multiple lines:","Docker/Moby": "will not break this into multiple lines", "and you'll receive":"all of them in log analytics", "as one": "log entry"}

問題の詳細については、こちらの GitHub リンクをご覧ください。

ライブ ログを有効にしたときの Azure AD のエラーを解決するにはどうすればよいですか

次のエラーがに表示される場合があります。要求で指定されている応答 URL が、アプリケーション用に構成された応答 URL と一致しません ('<application ID>')。 それを解決するためのソリューションについては、Container insights を使用してコンテナー データをリアルタイムで表示する方法に関する記事をご覧ください。

オンボード後にクラスターをアップグレードできないのはなぜですか

AKS クラスターに対して Container insights を有効にした後に、そのクラスターのデータの送信先となっていた Log Analytics ワークスペースを削除した場合、クラスターをアップグレードしようとすると失敗します。 これを回避するには、監視を無効にしてから、サブスクリプション内の別の有効なワークスペースを参照して、監視を再度有効にする必要があります。 クラスターのアップグレードをもう一度実行しようとすると、正常に処理され、完了するはずです。

エージェントに対して開いたり許可したりする必要があるポートとドメインはどれですか?

Azure、Azure US Government、および Azure China 21Vianet クラウドでコンテナー化されたエージェントに必要なプロキシとファイアウォールの構成情報については、「ネットワーク ファイアウォールの要件」をご覧ください。

ARO クラスター用の Kubernetes 監査ログの収集はサポートされていますか?

いいえ、Container Insights では Kubernetes 監査ログの収集はサポートされていません。

KubeEvents テーブルに対してクエリを実行したときに通常のイベントの種類が表示されないのはなぜですか?

既定では、collect_all_kube_events configmap 設定が有効になっていない限り、通常のイベントの種類は収集されません。 通常のイベントの収集が必要な場合は、container-azm-ms-agentconfig configmap で collect_all_kube_events 設定を有効にします。 configmap の構成の詳細については、「Container insights のエージェント データ収集を構成する」を参照してください。

VM insights

既存のワークスペースにオンボードすることはできますか?

仮想マシンが Log Analytics ワークスペースに既に接続されている場合、ワークスペースがサポートされているリージョンのいずれかにあれば、VM insights にオンボードするときにそのワークスペースを引き続き使用できます。

新しいワークスペースにオンボードすることはできますか?

現在、VM が既存の Log Analytics ワークスペースに接続されていない場合は、データを保存するために新しいワークスペースを作成する必要があります。 Azure portal を使用して VM insights で単一の Azure VM を構成すると、新しい既定のワークスペースが自動的に作成されます。

スクリプト ベースのメソッドを使用する場合、これらの手順は、Azure PowerShell または Resource Manager テンプレートを使用した VM insights の有効化に関する記事で説明されています。

VM が既に既存のワークスペースに報告している場合はどうすればよいですか?

仮想マシンから既にデータを収集している場合、既存の Log Analytics ワークスペースにデータを報告するように仮想マシンを構成済みである可能性があります。 そのワークスペースがサポートされているリージョンのいずれかにあれば、その既存のワークスペースに対して VM insights を有効にすることができます。 既に使用しているワークスペースがサポートされているリージョンにない場合、現時点では VM insights にオンボードすることはできません。 Microsoft では、その他のリージョンのサポートに積極的に取り組んでいます。

VM のオンボードに失敗したのはなぜですか?

Azure portal から Azure VM をオンボードすると、次の手順が実行されます。

  • 既定の Log Analytics ワークスペースが作成されます (該当するオプションが選択されている場合)。
  • Log Analytics エージェントが必要と判断されると、VM 拡張機能を使用して Azure VM にインストールされます。
  • VM insights のマップ依存関係エージェントが必要と判断されると、拡張機能を使用して Azure VM にインストールされます。

オンボード プロセス中、上記の各手順で状態がチェックされ、ポータルで通知の状態が返されます。 ワークスペースとエージェントのインストールの構成には、通常 5 から 10 分かかります。 監視データがポータルに表示されるまでに、さらに 5 から 10 分かかります。

オンボードを開始したときに、VM をオンボードする必要があることを示すメッセージが表示された場合は、VM がプロセスを完了するまでに最大 30 分かかります。

パフォーマンス グラフに VM のデータが表示されません

ディスク テーブルまたは一部のパフォーマンス グラフにパフォーマンス データが表示されない場合、ワークスペースでパフォーマンス カウンターが構成されていない可能性があります。 これを解決するには、こちらの PowerShell スクリプトを実行してください。

VM insights のマップ機能は Service Map とどのように異なりますか?

VM insights のマップ機能は Service Map がベースですが、次の点が異なります。

  • マップ ビューには、VM のペイン、および [Azure Monitor] の [VM insights] からアクセスできます。
  • マップ内の接続がクリック可能になっており、選択した接続のサイド パネルに接続メトリック データのビューが表示されます。
  • より複雑なマップのサポートを強化するために、マップの作成に使用される新しい API が用意されています。
  • 監視対象の VM がクライアント グループ ノードに含まれるようになりました。グループ内の監視対象の仮想マシンと監視対象外の仮想マシンの割合がドーナツ グラフに示されます。 また、グループを展開したときに、これを使用してマシンの一覧をフィルター処理することもできます。
  • 監視対象の仮想マシンがサーバー ポート グループ ノードに含まれるようになりました。グループ内の監視対象のマシンと監視対象外のマシンの割合がドーナツ グラフに示されます。 また、グループを展開したときに、これを使用してマシンの一覧をフィルター処理することもできます。
  • Application Insights のアプリ マップとの一貫性を向上させるために、マップのスタイルが更新されました。
  • サイド パネルが更新されましたが、Service Map でサポートされていた Update Management、Change Tracking、Security、およびService Desk との統合は含まれていません。
  • マップするグループとマシンを選択するオプションが更新され、サブスクリプション、リソース グループ、Azure Virtual Machine Scale Sets、クラウド サービスがサポートされるようになりました。
  • VM insights のマップ機能では、新しい Service Map コンピューター グループを作成することはできません。

パフォーマンス グラフに点線が表示されるのはなぜですか?

これはいくつかの理由で発生する可能性があります。 表示するデータ収集にギャップがある場合、点線が表示されます。 有効になっているパフォーマンス カウンターのデータ サンプリング頻度を変更したときに (既定の設定では、60 秒ごとにデータが収集されます)、グラフの時間範囲を狭め、サンプリング頻度がグラフで使用されるバケット サイズよりも少ない場合 (たとえば、サンプリング頻度が 10 分ごとで、グラフの各バケットが 5 分の場合)、グラフに点線が表示されます。 この場合、表示する時間範囲を広げると、グラフの線が点線ではなく実線で表示されます。

VM insights でグループはサポートされていますか?

はい。Dependency エージェントをインストールすると、VM から情報が収集され、サブスクリプション、リソース グループ、Virtual Machine Scale Sets、およびクラウド サービスに基づいてグループが表示されます。 Service Map を使用し、マシン グループを作成している場合も、これらが表示されます。 表示中のワークスペースでコンピューター グループを作成している場合は、それらもグループ フィルターに表示されます。

集計パフォーマンス グラフで 95 百分位線を引き上げているものについて詳細を確認するにはどうすればよいですか?

既定では、選択されたメトリックで 95 パーセンタイルの最大値を持つ VM を示すためにリストが並べ替えられます。ただし、5 パーセンタイルの最小値を持つマシンが表示される、使用可能なメモリのグラフを除きます。 グラフをクリックすると、適切なメトリックが選択された [上位 N のリスト] ビューが開きます。

マップ機能では、VNet 間およびサブネット間で重複する IP はどのように処理されますか?

サブネット間および VNet 間で VM または Azure Virtual Machine Scale Sets の IP 範囲が重複している場合、VM insights のマップに間違った情報が表示されることがあります。 これは既知の問題であり、このエクスペリエンスを改善するためのオプションを検討中です。

マップ機能で IPv6 はサポートされていますか?

現在、マップ機能では IPv4 のみがサポートされています。IPv6 のサポートは検討中です。 IPv6 内でトンネリングされる IPv4 もサポートされています。

リソース グループや他の大規模なグループのマップを読み込んだときに、マップを表示しづらくなります

大規模で複雑な構成に対応できるようにマップを改善しましたが、マップに多数のノード、接続、クラスターとして機能するノードが含まれている場合があることがわかりました。 Microsoft では、スケーラビリティを向上させるサポートの継続的な強化に取り組んでいます。

[パフォーマンス] タブのネットワーク グラフと Azure VM の概要ページのネットワーク グラフが異なるのはなぜですか?

Azure VM の概要ページには、ゲスト VM でのアクティビティのホストの測定に基づいてグラフが表示されます。 Azure VM の概要のネットワーク グラフでは、課金対象となるネットワーク トラフィックのみが表示されます。 これには、仮想ネットワーク間トラフィックは含まれません。 VM insights に表示されるデータとグラフは、ゲスト VM のデータに基づいており、ネットワーク グラフには、仮想ネットワーク間も含め、その VM に対する受信および送信のすべての TCP/IP トラフィックが表示されます。

VMConnection に格納されているデータの応答時間はどのように測定されて、接続パネルとブックに表示されるのですか?

応答時間は概算です。 アプリケーションのコードがインストルメント化されていないため、要求がいつ開始され、応答をいつ受信したのかは、実際にはわかりません。 その代わり、接続上で送信されるデータと、その接続で返されるデータが監視されます。 それらの送信と受信は、エージェントによって追跡され、ペアリングが試みられます。つまり、一連の送信とそれに続く一連の受信が要求/応答のペアとして解釈されます。 その操作の間隔が応答時間となります。 そこにはネットワーク待ち時間とサーバーの処理時間が含まれます。

要求/応答ベースのプロトコル、つまり接続上で単一の要求を送信して単一の応答を受信するプロトコルでは、この概算がうまく機能します。 HTTP(S) (パイプライン処理を伴わないもの) はそれに該当しますが、他のプロトコルでは十分に機能しません。

Log Analytics の無料プランを利用している場合、機能の制限はありますか?

"無料" の価格レベルを使った Log Analytics ワークスペースで Azure Monitor を構成した場合、VM insights のマップ機能では、ワークスペースに接続できるマシンが 5 つに制限されます。 無料のワークスペースに VM が 5 つ接続されている場合、いずれかの VM を切断した後に新しい VM を接続すると、新しい VM は監視されず、[マップ] ページにも反映されません。

この条件下では、VM を開いて左側のペインから [Insights](インサイト) を選択すると、機能が既に VM にインストール済みであっても、[今すぐ試す] オプションが表示されます。 ただし、その VM が VM insights にオンボードされていない場合には、オプションは表示されません。

SQL Insights (プレビュー)

どのバージョンの SQL Server がサポートされていますか

SQL Server 2012 とそれ以降のすべてのバージョンがサポートされています。 詳細については、「サポートされているバージョン」を参照してください。

どのような SQL リソースの種類がサポートされていますか

  • Azure SQL データベース
  • Azure SQL Managed Instance
  • Azure Virtual Machines の SQL Server (SQL 仮想マシン プロバイダーに登録されている仮想マシンで実行されている SQL Server)
  • Azure VM (SQL 仮想マシン プロバイダーに登録されていない仮想マシンで実行されている SQL Server)

サポートされていない、またはサポートが限られているシナリオの詳細については、「サポートされているバージョン」を参照してください。

SQL Server を実行する仮想マシンのオペレーティング システムは何がサポートされていますか

WindowsLinux のドキュメントで指定されているすべてのオペレーティング システムは、Azure Virtual Machines の SQL Server に対応しています。

監視用の仮想マシンのオペレーティング システムは何がサポートされていますか

現時点では、監視用の仮想マシンでサポートされているオペレーティングシステムは Ubuntu 18.04 だけです。

監視データは Log Analytics のどこに格納されますか

すべての監視データは InsightsMetrics テーブルに格納されます。 Origin 列には、solutions.azm.ms/telegraf/SqlInsights という値があります。 名前空間列には、sqlserver_ で始まる値があります。

データはどのくらいの頻度で収集されますか

データ収集の頻度はカスタマイズできます。 既定の頻度の詳細については、「SQL Insights (プレビュー) によって収集されたデータ」を参照してください。頻度をカスタマイズする手順については、 「SQL 監視プロファイルの作成」を参照してください。

次のステップ

こちらでご質問の回答が見つからない場合は、次のフォーラムでさらに質問と回答を参照できます。

Azure Monitor に関する一般的なフィードバックについては、フィードバック フォーラムにアクセスしてください。