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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Azure Monitor によって収集されたすべてのログ データは、Log Analytics ワークスペースに保存されます。 ワークスペースは、基本的に、さまざまなソースからログ データが収集されるコンテナーです。 すべての監視データに対して 1 つの Log Analytics ワークスペースを使用する場合もあれば、複数のワークスペースの要件が発生する場合もあります。 Log Analytics ワークスペース構成の設計に関するページを参照してください。

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

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

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

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

AzureDiagnostics は、Log Analytics がデータ インジェストから作成する一意のテーブルです。 そのスキーマは構成できません。 このテーブルが生成された後、保持ポリシーを適用できます。

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

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

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

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

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

Azure Monitor のメトリック エクスプローラーでは、現在、Prometheus メトリック データの視覚化はサポートされていません。 Azure Managed Grafana を使用して Prometheus メトリックを視覚化することを検討してください。

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

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

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

Azure portal を使用して Prometheus メトリック収集を有効にし、クラスターの [分析情報] ページから AKS アドオンまたは Azure Arc 対応 Kubernetes クラスターの拡張機能をインストールする場合、Log Analytics へのログの収集と Prometheus 用マネージド サービスへの Prometheus メトリックの収集が有効になります。

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

Azure portal を使用して Prometheus メトリック収集を有効にし、AKS クラスターの [分析情報] ページから AKS アドオンをインストールする場合、Log Analytics ワークスペースへのログ収集が有効になります。 および Azure Monitor ワークスペースへの Prometheus メトリック コレクション。

マネージド エージェントから Prometheus メトリックを取り込むためのトラブルシューティング ガイドは、こちらで参照できます。

大文字と小文字を除いて同じラベル名が 2 つあるメトリックは、ラベル名が重複しているものとして扱われます。 2 つのラベルは同じものとして見なされるため、これらの時系列は取り込み時に削除されます。 たとえば、時系列 my_metric{ExampleLabel="label_value_0", examplelabel="label_value_1} は、ExampleLabel と examplelabel が同じラベル名として認識されるため、ラベルが重複しているため削除されます。

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

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

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

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

Azure のアラートの概要に関するページを参照してください。

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

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

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

Azure Monitor エージェントは、他のすべてのレガシ監視エージェントの機能を統合した、新しい強化されたエージェントです。 一元化されたデータ収集、フィルター処理、マルチホームなどの追加の利点も提供されます。 「Azure Monitor エージェントの概要」を参照してください。

レガシ エージェントには次のものが含まれます。

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

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

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

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 

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

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

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

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

「ネットワーク ファイアウォールの要件」を参照してください。

Log Analytics エージェントは、Azure Monitor エージェントに置き換えられます。 これは、Microsoft Monitoring Agent とも呼ばれます。 これにより、Azure Diagnostics 拡張機能と Telegraf エージェントが置き換えられます。 Azure Monitor エージェントでは、少ないフットプリントで高い EPS レートが提供されます。 データ収集ルールと Azure ポリシーを使用して、強化されたフィルター機能、スケーラブルなデプロイ管理、構成が提供されます。

Azure Monitor エージェントは、現時点では Microsoft Monitoring Agent と完全には同等ではありませんが、引き続き機能とサポートを追加していきます。 Microsoft Monitoring Agent は、2024 年 8 月 31 日に廃止される予定です。

「Azure Monitor エージェントの概要」を参照してください。

Log Analytics エージェントからの移行に関するページを参照してください。

Azure Monitor エージェントが System Center Operations Manager の 2 つの監視シナリオにどのように影響するかを次に示します。

• シナリオ 1: System Center Operations Manager の Windows オペレーティング システムを監視する。 アップグレード パスは、他のマシンの場合と同じです。 必要なパリティ機能が Azure Monitor エージェントで使用できるようになったら、ただちに Microsoft Monitoring Agent (バージョン 2016 および 2019) から Azure Monitor エージェントに移行できます。
• シナリオ 2: System Center Operations Manager を Log Analytics ワークスペースにオンボードまたは接続する。 Log Analytics/Azure Monitor には System Center Operations Manager コネクタを使用します。 Operations Manager 管理サーバーに Microsoft Monitoring Agent も Azure Monitor エージェントもインストールする必要ありません。 このため、Azure Monitor エージェントの観点からは、このユース ケースに影響はありません。

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

次の図は、新しい拡張機能アーキテクチャを表しています。

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

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

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

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

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

重複イベントは、一方のエージェントから他方のエージェントに移行する期間だけに制限してください。 データ収集ルールを完全にテストし、そのデータ収集を確認した後、ワークスペースに対する収集を無効にし、Microsoft Monitoring Agent データ コネクタを切断してください。

Log Analytics エージェントと比較した場合の、Azure Monitor エージェントの現在の制限事項を確認してください。

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

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

はい。ただし、Defender for Cloud (以前の Azure Security Center) にオンボードする必要があります。 これは、AUOMS を介して Linux auditd ログを収集する、Azure Monitor エージェントの拡張機能として使用できます。

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

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

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

これは、仮想マシン、仮想マシン スケール セット、Azure Arc 対応サーバーに直接インストールできます。 また、Azure Monitor エージェント用の Windows MSI インストーラーを使用して、Windows 10 または 11 を実行しているワークステーションやデスクトップなどのデバイスにインストールすることもできます。 これは、現在プレビューで利用可能です。

はい。 Windows イベント ログをフィルター処理するために XPath クエリを使用できます。 詳細については、こちらを参照してください。 パフォーマンス カウンターでは、収集するカウンターを指定でき、不要なカウンターを除外できます。 Linux の Syslog では、ファシリティと、収集する各ファシリティのログ レベルを選択できます。

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

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

「データ収集ルールと関連付けを作成するために必要なアクセス許可」を参照してください。

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

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

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

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

• .NET アプリ。
• Azure Diagnostics。
• Java Web アプリ。

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

• ファイアウォール例外の設定。
• ASP.NET サーバーのセットアップ。
• Java サーバーのセットアップ。

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

「デプロイする必要がある Application Insights リソースの数」を参照してください。

• Azure Virtual Machines または Azure Virtual Machine Scale Sets の IIS サーバー上の Web アプリ
• オンプレミスまたは VM 内の IIS サーバー上の Web アプリ
• Java Web アプリ
• Node.js アプリ
• Azure で動作する Web アプリ
• Azure の Cloud Services
• 単一ページの Web アプリ
• SharePoint
• Windows デスクトップ アプリ
• その他のプラットフォーム

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

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

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

「料金プラン」を参照してください。

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

詳細は、プロジェクトの種類によって異なります。 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 については、「 リリース ノート 」をご覧ください。

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

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

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

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

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

• HTTP 要求。
• 依存関係。 SQL データベースに対する呼び出し、外部サービス、Azure Cosmos DB、Azure Table Storage、Azure Blob Storage、Azure Queue Storage に対する HTTP 呼び出し。
• 例外とスタック トレース。
• パフォーマンス カウンター: Azure Monitor Application Insights Agent、VM または仮想マシン スケール セット用 Azure Monitoring、または Application Insights collectd ライターを使用している場合。
• コード化するカスタム イベントとカスタム メトリック。
• トレース ログ (適切なコレクターを構成する場合)。

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

• ページ ビュー数
• AJAX 呼び出し: 実行中のスクリプトから行われる要求
• ページ ビューの読み込みデータ
• 構成可能なページのアクセス時間
• ユーザー数とセッション数
• 認証されたユーザー ID

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

• Azure Diagnostics
• Log Analytics へのインポート
• Log Analytics
• Logstash

はい。 サーバーで以下を記述できます。

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

ASP.NET、ASP.NET Core、JavaScript (Web)、Python または Java の詳細を確認してください。

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

• ブラウザー テレメトリ:送信者の IP アドレスを収集します。
• サーバー テレメトリ:Application Insights モジュールでクライアントの IP アドレスが収集されます。 X-Forwarded-For が設定されている場合は収集されません。
• Application Insights で IP アドレスと位置情報データが収集される方法について詳しくは、「位置情報と IP アドレスの処理」を参照してください。

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

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

データ保持とプライバシーに関するページを参照してください。

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

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

位置情報属性が検索された後、クライアント Web アドレスの "すべて" のオクテットが常に 0 に設定されます。

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

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

次の操作を行います。

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

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

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

• 「デプロイする必要がある Application Insights リソースの数」を参照してください。
• 例: worker ロールと web ロールを使用したクラウド サービス

• 「デプロイする必要がある Application Insights リソースの数」を参照してください。
• 例: worker ロールと web ロールを使用したクラウド サービス

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

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

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

PageView テレメトリには URL が含まれており、Kusto の正規表現関数を使用して UTM パラメーターを解析できます。

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

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

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

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

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

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

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

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

Application Insights の構成

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

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

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

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

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

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

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

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

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

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

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

サービスと IP アドレスの全一覧については、「Azure Monitor で使用される 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>

プロキシのパススルー

プロキシのパススルーを実現するには、マシン レベルのプロキシまたはアプリケーション レベルのプロキシを構成します。 「DefaultProxy」を参照してください。

Web.config の例:

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

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

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

Application Insights のほとんどのデータは、待ち時間が 5 分未満となっています。 一部のデータ (通常は、大きなログ ファイル) では、これよりも時間がかかることがあります。 Application Insights のサービス レベル アグリーメントに関するページを参照してください。

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

サーバー側の監視が有効になっているサーバーから 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 での HTTP エラー "502 無効なゲートウェイ" と "503 サービス利用不可" のトラブルシューティング」を参照してください。

監視のための新しいオープンソース標準です。 詳細については、「OpenTelemetry」を参照してください。

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

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

時間の経過とともに、Microsoft は、OpenTelemetry によって、Azure Monitor のお客様がサポートされている言語以外の言語で記述されたアプリケーションを監視できるようになると考えるようになりました。 また、豊富なインストルメンテーション ライブラリのセットを通じて収集できるデータの種類も拡張します。 さらに、OpenTelemetry SDK は、以前の Application Insights SDK よりもパフォーマンスが大規模に向上する傾向があります。

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

「OpenTelemetry Spec コンプライアンス マトリックス」を参照してください。

これは、Azure でのファースト クラスのエクスペリエンスのためにすべての OpenTelemetry コンポーネントをバンドルするシン ラッパーと考えることができます。

コミュニティのネイティブ OpenTelemetry よりも Azure Monitor OpenTelemetry Distro を使用することには、いくつかの利点があります。

• 有効化作業を減らす
• 次のような Azure 固有の機能が導入されます。
  • Azure Active Directory (Azure AD) 認証
  • オフライン ストレージと自動再試行
  • Application Insights SDK を使用してサービス コンポーネントのトレースを保存する
  • ライブ メトリック (将来)

OpenTelemetry の精神に基づいて、ディストリビューションはオープンで拡張できるように設計されています。 たとえば、次のようなものを追加できます。

• OTLP エクスポーターと 2 番目の宛先に同時に送信する
• パッケージにバンドルされているもの以外のコミュニティ インストルメンテーション ライブラリ

.NET、Java、JavaScript (Node.js)、Python に関する Microsoft 提供のドキュメントを確認してください。

一概には言えません。 Azure Monitor OpenTelemetry Distro はまだ "プレビュー" であり、Application Insights SDK と同等の機能ではないことを考慮してください。

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

キー

• ✅ この機能は、正式なサポートを受けるすべてのお客様が利用できます。
• ⚠️ この機能は、パブリック プレビューとして利用できます。 「Microsoft Azure プレビューの追加利用規約」を参照してください。
• ❌ この機能は利用できないか、適用されません。

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

OpenTelemetry Web SDK が利用可能になるタイムラインはまだ決定されていません。 Application Insights JavaScript SDK の有効な代替手段となるブラウザー SDK が登場するのは、おそらく数年先です。

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

いいえ。 このような実行をテストまたはサポートする予定はありませんが、Distro では、Azure Monitor と共に同時に OTLP エンドポイントにエクスポートできます。

それは推奨されません。 「Microsoft Azure プレビューの追加利用規約」を参照してください。

はい。一部のお客様は、"段階的なアプローチ" を使用してインストルメント化したいと考えていることは理解しています。 ただし、ディストリビューションには、Azure で最適なエクスペリエンスを開始するための最も簡単な方法が用意されています。

「OpenTelemetry の概要」を参照してください。

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

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

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

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

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

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

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

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

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

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

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

方法 1

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

ContainerID プロパティに基づき結合することで、ContainerInventory テーブルの Image プロパティと ImageTag プロパティがクエリに含まれるように変更します。 ContainerID プロパティに基づき結合することで、KubepodInventory テーブルの ContainerName フィールドの Name プロパティ (以前は ContainerLog テーブルに表示されていました) を含めることができます。 このオプションをお勧めします。

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

//Let's say we're querying an hour's 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 or if they're 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 rewritten
//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 設定を有効にします。

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

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

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

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

"Missing Subscription registration for Microsoft.OperationsManagement"(Microsoft.OperationsManagement のサブスクリプション登録がありません) というエラーが表示される場合、ワークスペースが定義されているサブスクリプションでリソース プロバイダー Microsoft.OperationsManagement を登録することで解決できます。 手順については、「リソース プロバイダーの登録エラーの解決」を参照してください。

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

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

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

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

Container Insights では、複数行のログ記録 (プレビュー) がサポートされるようになりました。有効にする方法の詳細については、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 ページを参照してください。

"要求で指定されている応答 URL が、アプリケーションに関して構成されている応答 URL と一致しない: '<アプリケーション ID>'。" というエラーが表示されることがあります。解決策については、Container insights でのコンテナー データのリアルタイム表示に関するページを参照してください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

点線が表示される理由はいくつかあります。 データ収集にギャップがある場合、点線が表示されます。

データ サンプリング頻度の既定の設定では、60 秒ごとにデータが収集されます。 有効化されているパフォーマンス カウンターの頻度を変更したとき、グラフの時間範囲を狭め、サンプリング頻度がグラフで使用されているバケット サイズよりも少ない場合には、グラフで点線が使用されます。

たとえば、サンプリング頻度が 10 分ごとで、グラフの各バケットが 5 分などの場合です。 この場合、表示する時間範囲を広げると、グラフの線が点線ではなく実線で表示されます。

はい。 Dependency エージェントをインストールすると、VM から情報が収集され、サブスクリプション、リソース グループ、仮想マシン スケール セット、クラウド サービスに基づいてグループが表示されます。

これらのグループは、Service Map を使用して、マシン グループを作成した場合も表示されます。 表示中のワークスペースでコンピューター グループを作成した場合は、それらもグループ フィルターで表示されます。

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

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

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

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

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

応答時間は概算です。 アプリケーションのコードがインストルメント化されていないため、要求がいつ開始されたか、応答をいつ受信したのかは不明です。 その代わり、接続で送信されるデータと、その接続で返されるデータが監視されます。

エージェントは、送信と受信を追跡し、それらをペアリングしようとします。 一連の送信とそれに続く一連の受信が、要求/応答のペアとして解釈されます。 その操作の間隔が応答時間となります。 これには、ネットワーク待機時間とサーバーの処理時間が含まれます。

要求/応答ベースのプロトコルでは、これに類似するものが適切に機能します。 接続で 1 つの要求が送信され、1 つの応答が受信されます。 この動作は、HTTP(S) (パイプライン処理なし) で利用できますが、他のプロトコルでは利用できません。

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

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

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

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

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

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

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

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

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

次のステップ

こちらでご質問の回答が見つからない場合は、次のフォーラムでその他の質問と回答を参照してください。

• Log Analytics
• Application Insights

Azure Monitor に関する一般的なフィードバックについては、「フィードバック フォーラム」を参照してください。