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 データには、CLI、PowerShell、REST API を使用したさまざまなシナリオでもアクセスできます。

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

はい。Azure リソースから監視データを収集するだけでなく、Azure Monitor では、他のクラウドやオンプレミスの仮想マシンやアプリケーションからデータを収集することができます。 「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 ワークスペース構成の設計 (logs/workspace-design.md) を参照してください。

リソース グループ間またはサブスクリプション間でワークスペースを移動することはできますが、別のリージョンに移動することはできません。 「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 用の Azure Monitor マネージド サービスによって収集された 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 用の Azure Monitor マネージド サービスでメトリックを視覚化する方法を確認してください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

エージェント コンピューターのコントロール パネルで、[セキュリティ & 設定]、[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
• [アラートの詳細を定義します]
  • Name:"データ収集が停止した"
  • [重大度] :警告

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

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

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

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

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

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

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 の観点から見れば、このユース ケースへの影響はありません。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Application Insights のデプロイを設計する方法:1 つまたは多数の Application Insights リソース

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

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

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

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 Database の呼び出し、外部サービスの HTTP 呼び出し、Azure Cosmos DB、テーブル、Blob Storage、およびキューの呼び出し。
• 例外とスタック トレース。
• パフォーマンス カウンター - Azure Monitor Application Insights Agent、VM または仮想マシン スケール セット用 Azure Monitoring、あるいは Application Insights collectd ライターを使用している場合。
• コード化するカスタム イベントとカスタム メトリック。
• トレース ログ (適切なコレクターを構成する場合)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• こちらの説明を参照してください
• 例 - worker ロールと web ロールを使用したクラウド サービス

• こちらで説明しています
• 例 - worker ロールと web ロールを使用したクラウド サービス

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

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

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

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

送信される各項目には、その項目が表す元のイベントの数を示す itemCount プロパティが含まれています。 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 ロールベースのアクセス制御 (Azure RBAC) 設定を再作成します。
• インジェスト サンプリング、データ保有、日次上限、およびカスタム メトリックの有効化を含む設定をレプリケートします。 これらの設定は、 [使用量と推定コスト] ペインで制御します。
• リリース注釈、ライブ メトリックと安全なコントロール チャネルなど、API キーに依存するすべての統合。新しい API キーを生成し、関連する統合を更新する必要があります。
• クラシック リソースの連続エクスポートを再構成する必要があります。
• ワークスペースベースのリソースの診断設定を再構成する必要があります。

Application Insights の構成

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

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

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

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

REST API を使用して 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 アドレスのすべての一覧を確認できます。

ファイアウォールの例外

ご利用の 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 に関する dotnet の記事を参照してください。

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 の SLA」を参照してください。

"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 サービスを利用できません" のトラブルシューティングに関する記事を参照してください。

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

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

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

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

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

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

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

次のグラフは、各言語に対する 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 または 1DS Collector にテレメトリを送信することはまだできません。 さらに、この SDK では現在、一般的なクライアント イベントが定義されていません。

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

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

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

• C# (ASP.NET
• ASP.NET Core
• JavaScript (Node.js)
• OpenCensus Python

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

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

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

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

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 言語は、手動インストルメンテーションにのみ重点を置いています。

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

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

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

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

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

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

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

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

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

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

エージェント バージョン 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 設定を有効にすると、これらのフィールドの収集を再び有効にすることができます。

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

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

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

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

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

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

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

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

エージェントは、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 リンクをご覧ください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 分の場合)、グラフに点線が表示されます。 この場合、表示する時間範囲を広げると、グラフの線が点線ではなく実線で表示されます。

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

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

サブネット間および VNet 間で 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 トラフィックが表示されます。

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

要求/応答ベースのプロトコル、つまり接続上で単一の要求を送信して単一の応答を受信するプロトコルでは、この概算がうまく機能します。 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 VM (SQL 仮想マシン プロバイダーに登録されていない仮想マシンで実行されている SQL Server)

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

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

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

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

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

次のステップ

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

• Log Analytics
• Application Insights

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