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

この Microsoft FAQ では、Azure Monitor についてよくあるご質問を紹介します。This Microsoft FAQ is a list of commonly asked questions about Azure Monitor. 他に何かご質問がある場合は、ディスカッション フォーラムにアクセスして質問を投稿してください。If you have any additional questions, go to the discussion forum and post your questions. よく寄せられる質問については、すばやく簡単に見つけることができるように、この記事に追加していきます。When a question is frequently asked, we add it to this article so that it can be found quickly and easily.

全般General

Azure Monitor とはWhat is Azure Monitor?

Azure Monitor は Azure のサービスであり、Azure、他のクラウド環境、またはオンプレミスのアプリケーションとサービスのパフォーマンスと可用性を監視する機能が提供されます。Azure Monitor is a service in Azure that provides performance and availability monitoring for applications and services in Azure, other cloud environments, or on-premises. Azure Monitor を使うと、複数のソースから共通のデータ プラットフォームにデータが収集され、傾向や異常を分析できるようになります。Azure Monitor collects data from multiple sources into a common data platform where it can be analyzed for trends and anomalies. Azure Monitor の豊富な機能を利用すると、アプリケーションに影響する可能性がある重大な状況を迅速に特定して対応することができます。Rich features in Azure Monitor assist you in quickly identifying and responding to critical situations that may affect your application.

Azure Monitor、Log Analytics、Application Insights の違いは何ですか?What's the difference between Azure Monitor, Log Analytics, and Application Insights?

2018 年 9 月に、Azure Monitor、Log Analytics、Application Insights が 1 つのサービスに結合され、アプリケーションとそれらが依存するコンポーネントをエンドツーエンドで監視できるようになりました。In September 2018, Microsoft combined Azure Monitor, Log Analytics, and Application Insights into a single service to provide powerful end-to-end monitoring of your applications and the components they rely on. Log Analytics と Application Insights の機能は変更されていませんが、一部の機能は、新しい対象範囲がより適切に反映されるように、Azure Monitor にブランド変更されています。Features in Log Analytics and Application Insights have not changed, although some features have been rebranded to Azure Monitor in order to better reflect their new scope. Log Analytics のログデータ エンジンとクエリ言語は、Azure Monitor ログと呼ばれるようになっています。The log data engine and query language of Log Analytics is now referred to as Azure Monitor Logs. Azure Monitor の用語の更新に関するページをご覧ください。See Azure Monitor terminology updates.

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

メトリックやアクティビティ ログの収集など、自動的に有効になる Azure Monitor の機能は、無料で提供されます。Features of Azure Monitor that are automatically enabled such as collection of metrics and activity logs are provided at no cost. ログ クエリやアラートなどの他の機能については、関連コストが発生します。There is a cost associated with other features such as log queries and alerting. 詳細な価格については、Azure Monitor の価格に関するページをご覧ください。See the Azure Monitor pricing page for detailed pricing information.

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

Azure Monitor は新しい Azure サブスクリプションを作成した時点で有効になり、アクティビティ ログとプラットフォーム メトリックが自動的に収集されます。Azure Monitor is enabled the moment that you create a new Azure subscription, and Activity log and platform metrics are automatically collected. Azure リソースの動作に関するさらに詳細な情報を収集するには診断設定を作成し、特定のサービスについて収集されたデータについて追加の分析を提供するには監視ソリューション分析情報を追加します。Create diagnostic settings to collect more detailed information about the operation of your Azure resources, and add monitoring solutions and insights to provide additional analysis on collected data for particular services.

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

Azure Monitor のすべての機能とデータには、Azure portal の [モニター] メニューからアクセスします。Access all Azure Monitor features and data from the Monitor menu in the Azure portal. さまざまな Azure サービスのメニューの [監視] セクションでは、特定のリソースに対してフィルター処理されたデータを使用して、同じツールにアクセスできます。The Monitoring section of the menu for different Azure services provides access to the same tools with data filtered to a particular resource. Azure Monitor データには、CLI、PowerShell、REST API を使用したさまざまなシナリオでもアクセスできます。Azure Monitor data is also accessible for a variety of scenarios using CLI, PowerShell, and a REST API.

オンプレミス バージョンの Azure Monitor はありますか?Is there an on-premises version of Azure Monitor?

いいえ。No. Azure Monitor は大量のデータを処理して格納するスケーラブルなクラウド サービスですが、Azure Monitor ではオンプレミスまたは他のクラウドのリソースを監視することができます。Azure Monitor is a scalable cloud service that processes and stores large amounts of data, although Azure Monitor can monitor resources that are on-premises and in other clouds.

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

はい。Azure リソースから監視データを収集するだけでなく、Azure Monitor では、他のクラウドやオンプレミスの仮想マシンやアプリケーションからデータを収集することができます。Yes, in addition to collecting monitoring data from Azure resources, Azure Monitor can collect data from virtual machines and applications in other clouds and on-premises. Azure Monitor で使用する監視データのソース」をご覧ください。See Sources of monitoring data for Azure Monitor.

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

System Center Operations Manager の既存の管理グループを Azure Monitor に接続して、エージェントからのデータを Azure Monitor ログに収集することができます。You can connect your existing System Center Operations Manager management group to Azure Monitor to collect data from agents into Azure Monitor Logs. これにより、ログ クエリとソリューションを使用して、エージェントから収集されたデータを分析することができます。This allows you to use log queries and solution to analyze data collected from agents. また、Azure Monitor にデータを直接送信するように、既存の System Center Operations Manager エージェントを構成することもできます。You can also configure existing System Center Operations Manager agents to send data directly to Azure Monitor. Operations Manager を Azure Monitor に接続する」を参照してください。See Connect Operations Manager to Azure Monitor.

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

エージェントと他の外部リソースが Azure Monitor にアクセスするために必要な IP アドレスとポートの一覧については、「Application Insights および Log Analytics によって使用される IP アドレス」をご覧ください。See IP addresses used by Application Insights and Log Analytics for a listing of the IP addresses and ports required for agents and other external resources to access Azure Monitor.

データの監視Monitoring data

Azure Monitor はどこでデータを取得しますか?Where does Azure Monitor get its data?

Azure Monitor では、Azure Platform とリソース、カスタム アプリケーション、仮想マシン上で実行されているエージェントからのログやメトリックなど、さまざまなソースのデータが収集されます。Azure Monitor collects data from a variety of sources including logs and metrics from Azure platform and resources, custom applications, and agents running on virtual machines. Azure Security Center や Network Watcher などの他のサービスでは、データが Log Analytics ワークスペースに収集されるので、Azure Monitor のデータで分析できます。Other services such as Azure Security Center and Network Watcher collect data into a Log Analytics workspace so it can be analyzed with Azure Monitor data. また、ログまたはメトリックの REST API を使用して、Azure Monitor にカスタム データを送信することもできます。You can also send custom data to Azure Monitor using the REST API for logs or metrics. Azure Monitor で使用する監視データのソース」をご覧ください。See Sources of monitoring data for Azure Monitor.

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

Azure Monitor では、さまざまなソースからのデータがログまたはメトリックに収集されます。Azure Monitor collects data from a variety of sources into logs or metrics. 各データの種類には、独自の相対的利点があり、それぞれによって Azure Monitor の特定の機能セットがサポートされます。Each type of data has its own relative advantages, and each supports a particular set of features in Azure Monitor. Azure サブスクリプションごとに 1 つのメトリック データベースがありますが、複数の Log Analytics ワークスペースを作成し、要件に応じてログを収集することができます。There is a single metrics database for each Azure subscription, while you can create multiple Log Analytics workspaces to collect logs depending on your requirements. Azure Monitor データ プラットフォーム」をご覧ください。See Azure Monitor data platform.

Azure Monitor で収集できるデータに最大量はありますか?Is there a maximum amount of data that I can collect in Azure Monitor?

収集できるメトリック データの量に制限はありませんが、このデータは最大 93 日間保持されます。There is no limit to the amount of metric data you can collect, but this data is stored for a maximum of 93 days. メトリックの保有期間」をご覧ください。See Retention of Metrics. 収集できるログ データの量に制限はありませんが、Log Analytics ワークスペースに対して選択した価格レベルによって影響を受ける可能性があります。There is no limit on the amount of log data that you can collect, but it may be affected by the pricing tier you choose for the Log Analytics workspace. 価格の詳細を参照してください。See pricing details.

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

分析情報とソリューションにより、Azure Monitor に格納されているデータを操作するためのカスタム エクスペリエンスが提供されます。Insights and solutions provide a custom experience for working with data stored in Azure Monitor. Kusto クエリ言語 (KQL) で記述たログ クエリを使用して、ログ データを直接操作できます。You can work directly with log data using a log query written in Kusto Query Language (KQL). Azure portal では、Log Analytics を使用してクエリを記述して実行し、対話形式でデータを分析できます。In the Azure portal, you can write and run queries and interactively analyze data using Log Analytics. Azure portal では、メトリックス エクスプローラーを使用してメトリックを分析します。Analyze metrics in the Azure portal with the Metrics Explorer. Azure Monitor でログ データを分析する方法に関するページ、および「Azure メトリックス エクスプローラーの概要」のページをご覧ください。See Analyze log data in Azure Monitor and Getting started with Azure Metrics Explorer.

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

Azure Monitor での分析情報とはどのようなものですか?What is an insight in Azure Monitor?

分析情報では、特定の Azure サービスに対するカスタマイズされた監視エクスペリエンスが提供されます。Insights provide a customized monitoring experience for particular Azure services. Azure Monitor の他の機能と同じメトリックとログが使用されますが、追加データを収集し、Azure portal で独自のエクスペリエンスを提供することができます。They use the same metrics and logs as other features in Azure Monitor but may collect additional data and provide a unique experience in the Azure portal. Azure Monitor での分析情報に関する記事をご覧ください。See Insights in Azure Monitor.

Azure portal で分析情報を表示するには、 [モニター] メニューの [分析情報] セクション、またはサービスのメニューの [監視] セクションを使用します。To view insights in the Azure portal, see the Insights section of the Monitor menu or the Monitoring section of the service's menu.

Azure Monitor でのソリューションとは何ですか?What is a solution in Azure Monitor?

監視ソリューションは、Azure Monitor の機能に基づいて特定のアプリケーションまたはサービスを監視するためのロジックのパッケージ化されたセットです。Monitoring solutions are packaged sets of logic for monitoring a particular application or service based on Azure Monitor features. Azure Monitor のログ データが収集され、Azure portal の一般的なエクスペリエンスを使用して、分析のためのログ クエリとビューが提供されます。They collect log data in Azure Monitor and provide log queries and views for their analysis using a common experience in the Azure portal. Azure Monitor での監視ソリューション」をご覧ください。See Monitoring solutions in Azure Monitor.

Azure portal でソリューションを表示するには、 [モニター] メニューの [分析情報] セクションで [詳細] をクリックします。To view solutions in the Azure portal, click More in the Insights section of the Monitor menu. [追加] をクリックして、ワークスペースに新しいソリューションを追加します。Click Add to add additional solutions to the workspace.

ログLogs

Azure Monitor ログと Azure Data Explorer の違いは何ですか?What's the difference between Azure Monitor Logs and Azure Data Explorer?

Azure Data Explorer は、ログと利用統計情報データのための高速で拡張性に優れたデータ探索サービスです。Azure Data Explorer is a fast and highly scalable data exploration service for log and telemetry data. Azure Monitor ログは、Azure Data Explorer を基にして構築されており、若干の違いはありますが同じ Kusto クエリ言語 (KQL) を使用します。Azure Monitor Logs is built on top of Azure Data Explorer and uses the same Kusto Query Language (KQL) with some minor differences. Azure Monitor ログ クエリ言語の違い」をご覧ください。See Azure Monitor log query language differences.

ログ データはどのようにして取得しますか?How do I retrieve log data?

すべてのデータは、Kusto クエリ言語 (KQL) で記述したログ クエリを使用して、Log Analytics ワークスペースから取得します。All data is retrieved from a Log Analytics workspace using a log query written using Kusto Query Language (KQL). 独自のクエリを記述したり、特定のアプリケーションまたはサービス用のログ クエリが含まれるソリューションや分析情報を使用したりできます。You can write your own queries or use solutions and insights that include log queries for a particular application or service. Azure Monitor のログ クエリの概要」をご覧ください。See Overview of log queries in Azure Monitor.

Log Analytics ワークスペースのデータは削除できますか?Can I delete data from a Log Analytics workspace?

データは、ワークスペースの保有期間に従って削除されます。Data is removed from a workspace according to its retention period. プライバシーやコンプライアンス上の理由から、特定のデータを削除することが可能です。You can delete specific data for privacy or compliance reasons. 詳細については、「プライベート データをエクスポートして削除する方法」を参照してください。See How to export and delete private data for more information.

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

Azure Monitor によって収集されたすべてのログ データは、Log Analytics ワークスペースに保存されます。All log data collected by Azure Monitor is stored in a Log Analytics workspace. ワークスペースは、基本的に、さまざまなソースからログ データが収集されるコンテナーです。A workspace is essentially a container where log data is collected from a variety of sources. すべての監視データに対して 1 つの Log Analytics ワークスペースを使用する場合や、複数のワークスペースが必要な場合があります。You may have a single Log Analytics workspace for all your monitoring data or may have requirements for multiple workspaces. Azure Monitor ログのデプロイの設計」をご覧ください。See Designing your Azure Monitor Logs deployment.

既存の Log Analytics ワークスペースを別の Azure サブスクリプションに移動できますか?Can you move an existing Log Analytics workspace to another Azure subscription?

リソース グループ間またはサブスクリプション間でワークスペースを移動することはできますが、別のリージョンに移動することはできません。You can move a workspace between resource groups or subscriptions but not to a different region. Log Analytics ワークスペースを別のサブスクリプションまたはリソース グループに移動する」をご覧ください。See Move a Log Analytics workspace to different subscription or resource group.

Log Analytics でクエリ エクスプローラーと [保存] ボタンが表示されないのはなぜですか?Why can't I see Query Explorer and Save buttons in Log Analytics?

クエリ エクスプローラー[保存] および [新しいアラート ルール] ボタンは、クエリ スコープが特定のリソースに設定されている場合は使用できません。Query Explorer, Save and New alert rule buttons are not available when the query scope is set to a specific resource. アラートを作成し、クエリを保存または読み込むには、Log Analytics のスコープをワークスペースに指定する必要があります。To create alerts, save or load a query, Log Analytics must be scoped to a workspace. ワークスペース コンテキストで Log Analytics を開くには、 [Azure Monitor] メニューの [ログ] を選択します。To open Log Analytics in workspace context, select Logs from the Azure Monitor menu. 最後に使用されたワークスペースが選択されますが、その他のワークスペースを選択することはできます。The last used workspace is selected, but you can select any other workspace. Azure Monitor Log Analytics のログ クエリのスコープと時間範囲」を参照してくださいSee Log query scope and time range in Azure Monitor Log Analytics

エラーが発生する理由:VM から Log Analytics を開くときに、"このサブスクリプションのリソース プロバイダー 'Microsoft.Insights' を登録してこのクエリを有効にしてください" というエラーが表示されるのはなぜですか?Why am I getting the error: "Register resource provider 'Microsoft.Insights' for this subscription to enable this query" when opening Log Analytics from a VM?

多くのリソース プロバイダーは自動的に登録されますが、一部のリソース プロバイダーは手動で登録することが必要な場合があります。Many resource providers are automatically registered, but you may need to manually register some resource providers. 登録の範囲は常にサブスクリプションです。The scope for registration is always the subscription. 詳細については、「リソース プロバイダーと種類」を参照してください。See Resource providers and types for more information.

VM から Log Analytics を開くときに、アクセス権なしというエラー メッセージが表示されるのはなぜですか?Why am I getting no access error message when opening Log Analytics from a VM?

VM ログを表示するには、VM ログを格納するワークスペースに対する読み取りアクセス許可が付与される必要があります。To view VM Logs, you need to be granted with read permission to the workspaces that stores the VM logs. このような場合、管理者が Azure でのアクセス許可を付与する必要があります。In these cases, your administrator must grant you with to permissions in Azure.

メトリックMetrics

Azure 仮想マシンのゲスト OS のメトリックがメトリックス エクスプローラーに表示されないのはなぜですか?Why are metrics from the guest OS of my Azure virtual machine not showing up in Metrics explorer?

プラットフォーム メトリックは、Azure リソースについて自動的に収集されます。Platform metrics are collected automatically for Azure resources. ただし、仮想マシンのゲスト OS からメトリックを収集するには、いくつかの構成を実行する必要があります。You must perform some configuration though to collect metrics from the guest OS of a virtual machine. Windows VM の場合は、「Install and configure Windows Azure Diagnostics 拡張機能 (WAD) のインストールと構成」の説明に従って、診断拡張機能をインストールし、Azure Monitor シンクを構成します。For a Windows VM, install the diagnostic extension and configure the Azure Monitor sink as described in Install and configure Windows Azure diagnostics extension (WAD). Linux の場合は、「Linux VM のカスタム メトリックを InfluxData Telegraf エージェントを使用して収集する」の説明に従って、Telegraf エージェントをインストールします。For Linux, install the Telegraf agent as described in Collect custom metrics for a Linux VM with the InfluxData Telegraf agent.

警告Alerts

Azure Monitor でのアラートとはどのようなものですか?What is an alert in Azure Monitor?

アラートは、監視データで重要な状態が見つかると事前に通知します。Alerts proactively notify you when important conditions are found in your monitoring data. 管理者は、その通知を見て、システムのユーザーが問題に気付く前に問題を識別して対処できます。They allow you to identify and address issues before the users of your system notice them. アラートには、次のように複数の種類があります。There are multiple kinds of alerts:

  • メトリック - メトリックの値が、しきい値を超えました。Metric - Metric value exceeds a threshold.
  • ログ クエリ - ログ クエリの結果が、定義された条件と一致しました。Log query - Results of a log query match defined criteria.
  • アクティビティ ログ - アクティビティ ログのイベントが、定義された条件と一致しました。Activity log - Activity log event matches defined criteria.
  • Web テスト - 可用性テストの結果が、定義された条件と一致しました。Web test - Results of availability test match defined criteria.

Microsoft Azure のアラートの概要」をご覧ください。See Overview of alerts in Microsoft Azure.

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

アクション グループとは、アラートによってトリガーできる通知とアクションのコレクションです。An action group is a collection of notifications and actions that can be triggered by an alert. 複数のアラートで 1 つのアクション グループを使用して、通知とアクションの共通セットを利用できます。Multiple alerts can use a single action group allowing you to leverage common sets of notifications and actions. Azure portal でのアクション グループの作成および管理」をご覧ください。See Create and manage action groups in the Azure portal.

アクション ルールとはどのようなものですか?What is an action rule?

アクション ルールを使用すると、特定の条件に一致する一連のアラートの動作を変更できます。An action rule allows you to modify the behavior of a set of alerts that match a certain criteria. これにより、メンテナンス期間中にアラート アクションを無効にするなどの要件を実行できます。This allows you to perform such requirements as disable alert actions during a maintenance window. また、アラート ルールにアラートを直接適用するのではなく、一連のアラートにアクション グループを適用することもできます。You can also apply an action group to a set of alerts rather than applying them directly to the alert rules. アクション ルールに関するページをご覧ください。See Action rules.

エージェントAgents

Azure Monitor ではエージェントは必要ですか?Does Azure Monitor require an agent?

エージェントは、仮想マシン内のオペレーティング システムおよびワークロードからデータを収集するためにのみ必要です。An agent is only required to collect data from the operating system and workloads in virtual machines. 仮想マシンは、Azure、別のクラウド環境、またはオンプレミスのどこに存在していてもかまいません。The virtual machines can be located in Azure, another cloud environment, or on-premises. Azure Monitor エージェントの概要」をご覧ください。See Overview of the Azure Monitor agents.

Azure Monitor エージェントの間にはどのような違いがありますか?What's the difference between the Azure Monitor agents?

Azure 診断拡張機能は Azure Virtual Machines 用であり、データは Azure Monitor メトリック、Azure Storage、Azure Event Hubs に収集されます。Azure Diagnostic extension is for Azure virtual machines and collects data to Azure Monitor Metrics, Azure Storage, and Azure Event Hubs. Log Analytics エージェントは、Azure、別のクラウド環境、またはオンプレミスの仮想マシン用であり、データは Azure Monitor ログに収集されます。The Log Analytics agent is for virtual machines in Azure, another cloud environment, or on-premises and collects data to Azure Monitor Logs. Dependency Agent には、Log Analytics エージェントと、収集されるプロセスの詳細と依存関係が必要です。The Dependency agent requires the Log Analytics agent and collected process details and dependencies. Azure Monitor エージェントの概要」をご覧ください。See Overview of the Azure Monitor agents.

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

Azure Monitor へのトラフィックでは、Microsoft ピアリングの ExpressRoute 回線が使用されます。Traffic to Azure Monitor uses the Microsoft peering ExpressRoute circuit. さまざまな種類の ExpressRoute トラフィックについては、ExpressRoute のドキュメントをご覧ください。See ExpressRoute documentation for a description of the different types of ExpressRoute traffic.

Log Analytics エージェントが Azure Monitor と通信できることを確認するにはどうすればよいですか?How can I confirm that the Log Analytics agent is able to communicate with Azure Monitor?

エージェント コンピューターのコントロール パネルで、 [セキュリティ設定] 、**[Microsoft Monitoring Agent] の順に選択します。From Control Panel on the agent computer, select Security & Settings, **Microsoft Monitoring Agent. [Azure Log Analytics (OMS)] タブで、緑色のチェック マーク アイコンは、エージェントが Azure Monitor と通信できることを示します。Under the Azure Log Analytics (OMS) tab, a green check mark icon confirms that the agent is able to communicate with Azure Monitor. 黄色の警告アイコンは、エージェントに問題があることを示します。A yellow warning icon means the agent is having issues. 一般的な原因の 1 つは、Microsoft Monitoring Agent サービスが停止したことです。One common reason is the Microsoft Monitoring Agent service has stopped. サービス コントロール マネージャーを使用してサービスを再開します。Use service control manager to restart the service.

Log Analytics エージェントと Azure Monitor の通信を停止するにはどうすればよいですか?How do I stop the Log Analytics agent from communicating with Azure Monitor?

Log Analytics に直接接続されているエージェントの場合は、[コントロール パネル] を開き、 [システムとセキュリティ][Microsoft Monitoring Agent] の順に選択します。For agents connected to Log Analytics directly, open the Control Panel and select Security & Settings, Microsoft Monitoring Agent. [Azure Log Analytics (OMS)] タブで、一覧に表示されているすべてのワークスペースを削除します。Under the Azure Log Analytics (OMS) tab, remove all workspaces listed. System Center Operations Manager では、Log Analytics マネージド コンピューターの一覧からコンピューターを削除します。In System Center Operations Manager, remove the computer from the Log Analytics managed computers list. Operations Manager はエージェントの構成を更新して、Log Analytics に報告しなくなるようにします。Operations Manager updates the configuration of the agent to no longer report to Log Analytics.

エージェントごとにどれくらいのデータが送信されますか?How much data is sent per agent?

エージェントごとに送信されるデータ量は、次のものによって異なります。The amount of data sent per agent depends on:

  • 有効にしているソリューションThe solutions you have enabled
  • 収集されているログとパフォーマンス カウンターの数The number of logs and performance counters being collected
  • ログ内のデータ量The volume of data in the logs

Azure Monitor ログで使用量とコストを管理する」をご覧ください。See Manage usage and costs with Azure Monitor Logs for details.

WireData エージェントを実行できるコンピューターの場合、どれくらいのデータが送信されているかを確認するには次のクエリを使用します。For computers that are able to run the WireData agent, use the following query to see how much data is being sent:

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) によって使用されますか?How much network bandwidth is used by the Microsoft Management Agent (MMA) when sending data to Azure Monitor?

帯域幅は、送信されるデータ量に関する機能です。Bandwidth is a function on the amount of data sent. データは、ネットワーク経由で送信されるときに圧縮されます。Data is compressed as it is sent over the network.

Log Analytics エージェントからのデータ収集が停止したときに通知を受け取るにはどうすればよいですか?How can I be notified when data collection from the Log Analytics agent stops?

データ収集が停止したときに通知を受けるには、新しいログ アラートの作成に関する記事で説明されている手順を使用します。Use the steps described in create a new log alert to be notified when data collection stops. アラート ルールの次の設定を使用します。Use the following settings for the alert rule:

  • [アラートの条件を定義します] : リソース ターゲットとして Log Analytics ワークスペースを指定します。Define alert condition: Specify your Log Analytics workspace as the resource target.
  • [アラートの条件]Alert criteria
    • [シグナル名] : "カスタム ログ検索"Signal Name: Custom log search
    • [検索クエリ] : Heartbeat | summarize LastCall = max(TimeGenerated) by Computer | where LastCall < ago(15m)Search query: Heartbeat | summarize LastCall = max(TimeGenerated) by Computer | where LastCall < ago(15m)
    • [アラート ロジック] : [基準] : "結果の数"、 [条件] : "より大きい"、 [しきい値] : 0Alert logic: Based on number of results, Condition Greater than, Threshold value 0
    • [評価基準] : [期間 (分単位)] : 30[頻度 (分単位)] : 10Evaluated based on: Period (in minutes) 30, Frequency (in minutes) 10
  • [アラートの詳細を定義します]Define alert details
    • Name:"データ収集が停止した"Name: Data collection stopped
    • [重大度] :警告Severity: Warning

既存または新規のアクション グループを指定して、ログ アラートが条件に一致する場合に、ハートビートが 15 分以上なければ通知が送られるようにします。Specify an existing or new Action Group so that when the log alert matches criteria, you are notified if you have a heartbeat missing for more than 15 minutes.

Azure Monitor エージェントにはファイアウォールに関するどのような要件がありますか?What are the firewall requirements for Azure Monitor agents?

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

視覚化Visualizations

ビュー デザイナーを表示できないのはなぜですか?Why can't I see View Designer?

ビュー デザイナーは、 Log Analytics ワークスペース内で共同作成者以上のアクセス許可が割り当てられているユーザーのみが使用できます。View Designer is only available for users assigned with Contributor permissions or higher in the Log Analytics workspace.

Application InsightsApplication Insights

構成の問題Configuration problems

次のセットアップで問題が発生しています。I'm having trouble setting up my:

サーバーからデータを取得できません。I get no data from my server:

"デプロイする必要がある Application Insights リソースの数。 "How many Application Insights resources should I deploy:

Application Insights と共に使用できるものCan I use Application Insights with ...?

これは無料ですか。Is it free?

はい、試験段階用です。Yes, for experimental use. Basic 価格プランでは、アプリケーションは毎月無料で一定のデータ許容量を送信できます。In the basic pricing plan, your application can send a certain allowance of data each month free of charge. 無料許容量は、開発や、少数のユーザー向けにアプリを発行するのに十分な大きさです。The free allowance is large enough to cover development, and publishing an app for a small number of users. 指定した以上のデータ量が処理されることを防ぐために上限を設定できます。You can set a cap to prevent more than a specified amount of data from being processed.

上限を超える量のテレメトリは GB 単位で課金されます。Larger volumes of telemetry are charged by the Gb. 課金額を制限する方法について、こちらでいくつかのヒントを紹介しています。We provide some tips on how to limit your charges.

Enterprise プランでは、テレメトリを送信した Web サーバー ノードごとに、1 日単位で料金が請求されます。The Enterprise plan incurs a charge for each day that each web server node sends telemetry. このプランは、連続エクスポートを大規模に使用する場合に適しています。It is suitable if you want to use Continuous Export on a large scale.

価格プランを参照してくださいRead the pricing plan.

コストはどれくらいですか。How much does it cost?

  • Application Insights リソースで [使用量と推定コスト] ページを開きます。Open the Usage and estimated costs page in an Application Insights resource. 最近の利用状況のグラフが表示されます。There's a chart of recent usage. 必要に応じて、データ量の上限を設定できます。You can set a data volume cap, if you want.
  • Azure の [課金] ブレードを開き、リソース全体での請求額を確認します。Open the Azure Billing blade to see your bills across all resources.

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

詳細は、プロジェクトの種類によって異なります。The details depend on the type of project. Web アプリケーションの場合:For a web application:

  • 次のファイルがプロジェクトに追加されます。Adds these files to your project:
    • ApplicationInsights.configApplicationInsights.config
    • ai.jsai.js
  • これらの NuGet パッケージをインストールします。Installs these NuGet packages:
    • Application Insights API - コア APIApplication Insights API - the core API
    • Application Insights API for Web Applications - サーバーからテレメトリを送信するために使用されますApplication Insights API for Web Applications - used to send telemetry from the server
    • Application Insights API for JavaScript Applications - クライアントからテレメトリを送信するために使用されますApplication Insights API for JavaScript Applications - used to send telemetry from the client
  • パッケージには、これらのアセンブリが含まれます。The packages include these assemblies:
    • Microsoft.ApplicationInsightsMicrosoft.ApplicationInsights
    • Microsoft.ApplicationInsights.PlatformMicrosoft.ApplicationInsights.Platform
  • 次の項目を挿入します。Inserts items into:
    • web.configWeb.config
    • packages.configpackages.config
  • (新しいプロジェクトのみ。Application Insights を既存のプロジェクトに追加している場合は、手動でこの操作を行う必要があります)。これらを Application Insights リソース ID で初期化するためのスニペットを、クライアントとサーバーのコードに挿入します。(New projects only - if you add Application Insights to an existing project, you have to do this manually.) Inserts snippets into the client and server code to initialize them with the Application Insights resource ID. たとえば、MVC アプリでは、Views/Shared/_Layout.cshtml マスター ページにコードが挿入されます。For example, in an MVC app, code is inserted into the master page Views/Shared/_Layout.cshtml

以前のバージョンの SDK からアップグレードする方法。How do I upgrade from older SDK versions?

お使いのアプリケーションに適切な SDK については、「 リリース ノート 」をご覧ください。See the release notes for the SDK appropriate to your type of application.

自分のプロジェクトがデータを送信する Azure のリソースを変更するにはどうすればいいですか?How can I change which Azure resource my project sends data to?

ソリューション エクスプローラーで、 ApplicationInsights.config を右クリックし、 [Application Insights の更新] を選択します。In Solution Explorer, right-click ApplicationInsights.config and choose Update Application Insights. Azure の既存または新規のリソースにデータを送信できます。You can send the data to an existing or new resource in Azure. 更新ウィザードでは、サーバー SDK のデータの送信先を決定する、ApplicationInsights.config のインストルメンテーション キーを変更します。The update wizard changes the instrumentation key in ApplicationInsights.config, which determines where the server SDK sends your data. [すべて更新] を選択解除している場合を除き、Web ページ内のキーが表示される場所でもキーが変更されます。Unless you deselect "Update all," it will also change the key where it appears in your web pages.

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

API バージョンの設定に、この方法を使用することは推奨されません。We do not recommend using this method of populating the API version. 最新バージョンは、破壊的変更を含んでいる可能性があるプレビュー リリースを表す場合があります。The newest version can represent preview releases which may contain breaking changes. 新しいプレビュー以外のリリースでも、API バージョンが必ずしも既存のテンプレートと下位互換性を持っているとは限りません。場合によっては、API バージョンがすべてのサブスクリプションで使用できない可能性もあります。Even with newer non-preview releases, the API versions are not always backwards compatible with existing templates, or in some cases the API version may not be available to all subscriptions.

Status Monitor とは何ですか?What is Status Monitor?

IIS Web サーバーで Web アプリ内の Application Insights を構成するために使用できるデスクトップ アプリです。A desktop app that you can use in your IIS web server to help configure Application Insights in web apps. テレメトリは収集されないので、アプリの構成中以外は停止しておくことができます。It doesn't collect telemetry: you can stop it when you are not configuring an app.

詳細については、こちらを参照してくださいLearn more.

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

サーバーの Web アプリから:From server web apps:

クライアントの Web ページから:From client web pages:

その他のソースから (構成する場合):From other sources, if you configure them:

一部のテレメトリを除外または変更することはできますか?Can I filter out or modify some telemetry?

はい。サーバーで以下のようなものを記述できます。Yes, in the server you can write:

  • 選択されたテレメトリ項目に対して、それがアプリから送信される前にフィルター処理やプロパティの追加を行うテレメトリ プロセッサ。Telemetry Processor to filter or add properties to selected telemetry items before they are sent from your app.
  • テレメトリの全項目にプロパティを追加するテレメトリ初期化子。Telemetry Initializer to add properties to all items of telemetry.

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

市区町村や国や地域などの geo ロケーション データはどのように計算されますか?How are city, country/region, and other geo location data calculated?

Web クライアントの IP アドレス (IPv4 または IPv6) の検索に GeoLite2 を使用しています。We look up the IP address (IPv4 or IPv6) of the web client using GeoLite2.

  • ブラウザー テレメトリ:送信者の IP アドレスを収集します。Browser telemetry: We collect the sender's IP address.
  • サーバー テレメトリ:Application Insights モジュールでクライアントの IP アドレスが収集されます。Server telemetry: The Application Insights module collects the client IP address. X-Forwarded-For が設定されている場合は収集されません。It is not collected if X-Forwarded-For is set.
  • Application Insights で IP アドレスと geo ロケーション データが収集される方法の詳細については、こちらの記事を参照してください。To learn more about how IP address and geolocation data are collected in Application Insights refer to this article.

別のヘッダーから IP アドレスを取得するように ClientIpHeaderTelemetryInitializer を構成できます。You can configure the ClientIpHeaderTelemetryInitializer to take the IP address from a different header. たとえば一部のシステムでは、プロキシ、ロード バランサー、または CDN によって IP アドレスが X-Originating-IP に移動されます。In some systems, for example, it is moved by a proxy, load balancer, or CDN to X-Originating-IP. 詳細については、こちらを参照してくださいLearn more.

Power BI を使用すると、要求テレメトリを地図上に表示できます。You can use Power BI to display your request telemetry on a map.

ポータルでのデータ保持期間はどのくらいですか?How long is data retained in the portal? セキュリティで保護されていますか?Is it secure?

データの保持とプライバシーに関するページをご覧ください。Take a look at Data Retention and Privacy.

サーバーまたはデバイスが Azure との接続を失った場合、Application insights のテレメトリはどうなりますか?What happens to Application Insight's telemetry when a server or device loses connection with Azure?

Web SDK を含むすべての SDK には、"信頼できるトランスポート" または "堅牢なトランスポート" が含まれています。All of our SDKs, including the web SDK, includes "reliable transport" or "robust transport". サーバーまたはデバイスが Azure との接続を失った場合、テレメトリはローカルにファイル システム (サーバー SDK) に、または HTML5 セッション ストレージ (Web SDK) に格納されます。When the server or device loses connection with Azure, telemetry is stored locally on the file system (Server SDKs) or in HTML5 Session Storage (Web SDK). SDK は、インジェスト サービスが "古い" と見なすまで (ログの場合は 48 時間、メトリックの場合は 30 分)、このテレメトリの送信を定期的に再試行します。The SDK will periodically retry to send this telemetry until our ingestion service considers it "stale" (48-hours for logs, 30 minutes for metrics). 古いテレメトリは削除されます。Stale telemetry will be dropped. ローカル ストレージがいっぱいになった場合など、場合によっては再試行は行われません。In some cases, such as when local storage is full, retry will not occur.

テレメトリで個人データが送信されることはありますか?Could personal data be sent in the telemetry?

コードでそのようなデータを送信する場合は可能性があります。This is possible if your code sends such data. また、スタック トレース内の変数に個人データが含まれている場合にも、送信される可能性があります。It can also happen if variables in stack traces include personal data. その個人データの処理が適切に行われるように、開発チームでリスク評価を実施する必要があります。Your development team should conduct risk assessments to ensure that personal data is properly handled. こちらから、データ リテンション期間とプライバシーについての詳細を確認してください。Learn more about data retention and privacy.

geo ロケーション属性の検索後、クライアント Web アドレスのすべてのオクテットは常に 0 に設定されます。All octets of the client web address are always set to 0 after the geo location attributes are looked up.

Web ページのソースに自分のインストルメンテーション キーが表示されます。My Instrumentation Key is visible in my web page source.

  • 監視ソリューションにおいてはよくあることです。This is common practice in monitoring solutions.
  • iKey を使用してデータを盗むことはできません。It can't be used to steal your data.
  • データ スキューやアラートのトリガーに使用される可能性はあります。It could be used to skew your data or trigger alerts.
  • これまでに、お客様がそのような問題に遭遇したという事例は報告されていません。We have not heard that any customer has had such problems.

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

  • クライアント データとサーバー データに 2 つの独立したインストルメンテーション キー (別々の Application Insights リソース) を使用します。Use two separate Instrumentation Keys (separate Application Insights resources), for client and server data. またはOr
  • サーバーで実行するためのプロキシを記述し、Web クライアントからそのプロキシを介してデータを送信します。Write a proxy that runs in your server, and have the web client send data through that proxy.

診断検索で POST データを表示する方法を教えてください。How do I see POST data in Diagnostic search?

POST データは自動ではログに記録されませんが、TrackTrace 呼び出しを使用してメッセージ パラメーターにデータを格納できます。We don't log POST data automatically, but you can use a TrackTrace call: put the data in the message parameter. 文字列プロパティの制限よりもサイズ制限は大きいですが、フィルター処理には使用できません。This has a longer size limit than the limits on string properties, though you can't filter on it.

Application Insights リソースは、単一リソースと複数リソースのどちらを使用すべきですか?Should I use single or multiple Application Insights resources?

1 つのビジネス システム内のすべてのコンポーネントまたはロールに対しては、単一リソースを使用します。Use a single resource for all the components or roles in a single business system. 開発、テスト、およびリリースのバージョン、および独立したアプリケーションに対しては、複数のリソースを使用します。Use separate resources for development, test, and release versions, and for independent applications.

インストルメンテーション キーを動的に変更するには、どうすればよいですか?How do I dynamically change the instrumentation key?

ユーザー数とセッション数とは何ですか?What are the User and Session counts?

  • JavaScript SDK では、Web クライアントにユーザー Cookie を設定することで戻ってきたユーザーを識別し、セッション Cookie を設定することでグループ アクティビティを識別します。The JavaScript SDK sets a user cookie on the web client, to identify returning users, and a session cookie to group activities.
  • クライアント側のスクリプトがない場合は、サーバーで Cookie を設定できます。If there is no client-side script, you can set cookies at the server.
  • 1 人の実在するユーザーが、複数の異なるブラウザーや、プライベート/シークレット ブラウズ、または複数のコンピューターでサイトを利用した場合、それらは複数のユーザーとしてカウントされます。If one real user uses your site in different browsers, or using in-private/incognito browsing, or different machines, then they will be counted more than once.
  • 複数のコンピューターやブラウザー間でログイン済みのユーザーを識別するには、setAuthenticatedUserContext() の呼び出しを追加します。To identify a logged-in user across machines and browsers, add a call to setAuthenticatedUserContext().

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

表示内容What you should see 表示方法How to get it 用途Why you want it
可用性グラフAvailability charts Web テストWeb tests Web アプリが稼働しているか確認するKnow your web app is up
サーバー アプリ パフォーマンス: 応答時間、...Server app perf: response times, ... Application Insights をプロジェクトに追加するか、AI Status Monitor をサーバーにインストールする (または独自のコードを記述して依存関係を追跡する)Add Application Insights to your project or Install AI Status Monitor on server (or write your own code to track dependencies) パフォーマンスの問題を検出するDetect perf issues
依存関係テレメトリDependency telemetry AI Status Monitor をサーバーにインストールするInstall AI Status Monitor on server データベースや、その他の外部コンポーネントの問題を診断するDiagnose issues with databases or other external components
例外からスタック トレースを取得するGet stack traces from exceptions コード内に TrackException 呼び出しを挿入する (自動で報告されるものもある)Insert TrackException calls in your code (but some are reported automatically) 例外を検出して診断するDetect and diagnose exceptions
ログ トレースの検索Search log traces ログ アダプターを追加するAdd a logging adapter 例外、パフォーマンスの問題を診断するDiagnose exceptions, perf issues
クライアントの利用状況の基本情報: ページ ビュー、セッション、...Client usage basics: page views, sessions, ... Web ページの JavaScript の初期化子JavaScript initializer in web pages Usage analyticsUsage analytics
クライアントのカスタム メトリックClient custom metrics Web ページでの呼び出しの追跡Tracking calls in web pages ユーザー エクスペリエンスを向上させるEnhance user experience
サーバーのカスタム メトリックServer custom metrics サーバーでの呼び出しの追跡Tracking calls in server Business intelligenceBusiness intelligence

検索グラフとメトリック グラフで数が等しくないのはなぜですか?Why are the counts in Search and Metrics charts unequal?

サンプリングにより、アプリからポータルに実際に送信されたテレメトリ項目 (要求、カスタム イベントなど) の数が減少します。Sampling reduces the number of telemetry items (requests, custom events, and so on) that are actually sent from your app to the portal. 検索グラフには、実際に受信した項目の数が表示されます。In Search, you see the number of items actually received. イベント数を表示するメトリック グラフには、発生した元のイベントの数が表示されます。In metric charts that display a count of events, you see the number of original events that occurred.

送信される各項目には、その項目が表す元のイベントの数を示す itemCount プロパティが含まれています。Each item that is transmitted carries an itemCount property that shows how many original events that item represents. Analytics で次のクエリを実行すると、サンプリング操作を確認できます。To observe sampling in operation, you can run this query in Analytics:

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

Application Insights リソースを新しいリージョンに移動するにはどうすればよいですか?How do I move an Application Insights resource to a new region?

既存の Application Insights リソースをあるリージョンから別のリージョンに移動することは、現在サポートされていませんMoving existing Application Insights resources from one region to another is currently not supported. 収集した履歴データを新しいリージョンに移行することはできませんHistorical data that you have collected cannot be migrated to a new region. 唯一の部分的な回避策は次のとおりです。The only partial workaround is to:

  1. 新しいリージョンに新しい Application Insights リソース (クラシックまたはワークスペースベース) を作成します。Create a brand new Application Insights resource (classic or workspace-based) in the new region.
  2. 元のリソースに固有のすべての独自のカスタマイズを新しいリソースに再作成します。Recreate all unique customizations specific to the original resource in the new resource.
  3. 新しいリージョン リソースのインストルメンテーション キーまたは接続文字列を使用するようにアプリケーションを変更します。Modify your application to use the new region resource's instrumentation key or connection string.
  4. 新しい Application Insights リソースで引き続きすべてが期待どおりに動作していることをテストして確認します。Test to confirm that everything is continuing to work as expected with your new Application Insights resource.
  5. この時点で、元のリソースを削除することができます。これにより、すべての履歴データが失われ ますAt this point you can either delete the original resource which will result in all historical data being lost. または、そのデータ保有設定の期間中、履歴レポートの目的で元のリソースを保持します。Or retain the original resource for historical reporting purposes for the duration of its data retention settings.

新しいリージョンのリソースに対して、通常、手動で再作成または更新する必要がある独自のカスタマイズには、以下のものがありますが、これらに限定されるものではありません。Unique customizations that commonly need to be manually recreated or updated for the resource in the new region include but are not limited to:

  • カスタム ダッシュボードとブックを再作成します。Recreate custom dashboards and workbooks.
  • カスタム ログまたはメトリック アラートのスコープを再作成または更新します。Recreate or update the scope of any custom log/metric alerts.
  • 可用性アラートを再作成します。Recreate availability alerts.
  • ユーザーが新しいリソースにアクセスするために必要なカスタムのロールベースのアクセス制御 (RBAC) 設定を再作成します。Recreate any custom Role-Based Access Control (RBAC) settings that are required for your users to access the new resource.
  • インジェスト サンプリング、データ保有、日次上限、およびカスタム メトリックの有効化を含む設定をレプリケートします。Replicate settings involving ingestion sampling, data retention, daily cap, and custom metrics enablement. これらの設定は、 [使用量と推定コスト] ペインで制御します。These settings are controlled via the Usage and estimated costs pane.
  • リリース注釈ライブ メトリックとコントロール チャネルの保護など、API キーに依存するすべての統合。新しい API キーを生成し、関連する統合を更新する必要があります。Any integration that relies on API keys such as release annotations, live metrics secure control channel etc. You will need to generate new API keys and update the associated integration.
  • クラシック リソースの連続エクスポートを再構成する必要があります。Continuous export in classic resources would need to be configured again.
  • ワークスペースベースのリソースの診断設定を再構成する必要があります。Diagnostic settings in workspace-based resources would need to be configured again.

注意

新しいリージョンで作成するリソースによってクラシック リソースが置き換えられる場合は、新しいワークスペースベースのリソースを作成することのメリットを検討するか、または既存のリソースをワークスペースベースに移行することをお勧めします。If the resource you are creating in a new region is replacing a classic resource we recommend exploring the benefits of creating a new workspace-based resource or alternatively migrating your existing resource to workspace-based.

オートメーションAutomation

Application Insights の構成Configuring Application Insights

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

  • Application Insights リソースの作成と更新。Create and update Application Insights resources.
  • 価格プランの設定。Set the pricing plan.
  • インストルメンテーション キーの取得。Get the instrumentation key.
  • メトリック アラートの追加。Add a metric alert.
  • 可用性テストの追加。Add an availability test.

メトリックス エクスプローラー レポートや連続エクスポートの設定はできません。You can't set up a Metric Explorer report or set up continuous export.

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

REST API を使用して Analytics クエリを実行します。Use the REST API to run Analytics queries.

イベントにアラートを設定するには、どうすればよいですか?How can I set an alert on an event?

Azure アラートはメトリックにのみ設定できます。Azure alerts are only on metrics. イベントが発生するたびにしきい値を超える、カスタム メトリックを作成してください。Create a custom metric that crosses a value threshold whenever your event occurs. その後、メトリックにアラートを設定します。Then set an alert on the metric. メトリックがしきい値を超えると、超えたときの方向がどちらであっても通知が届くことになります。初期値がしきい値より高くても低くても、最初にしきい値を超えるまで通知は届きません。常に数分の待ち時間が発生します。You'll get a notification whenever the metric crosses the threshold in either direction; you won't get a notification until the first crossing, no matter whether the initial value is high or low; there is always a latency of a few minutes.

Azure Web アプリと Application Insights の間でデータ転送料金は発生しますか?Are there data transfer charges between an Azure web app and Application Insights?

  • Application Insights の収集エンドポイントがあるデータ センターに Azure Web アプリがホストされている場合、料金はかかりません。If your Azure web app is hosted in a data center where there is an Application Insights collection endpoint, there is no charge.
  • ホスト データ センターに収集エンドポイントがない場合は、アプリのテレメトリに対して Azure の送信料金が発生します。If there is no collection endpoint in your host data center, then your app's telemetry will incur Azure outgoing charges.

これは、Application Insights リソースがホストされている場所ではなく、This doesn't depend on where your Application Insights resource is hosted. 単に Microsoft のエンドポイントの割り当てによって決まります。It just depends on the distribution of our endpoints.

テレメトリを Application Insights ポータルに送信できますか?Can I send telemetry to the Application Insights portal?

Microsoft の SDK と SDK API を使用することをお勧めします。We recommend you use our SDKs and use the SDK API. 各種プラットフォーム向けに異なる SDK が用意されています。There are variants of the SDK for various platforms. これらの SDK では、バッファリング、圧縮、調整、再試行などを処理します。These SDKs handle buffering, compression, throttling, retries, and so on. ただし、取り込みスキーマエンドポイント プロトコルはパブリックです。However, the ingestion schema and endpoint protocol are public.

イントラネット Web サーバーを監視できますか?Can I monitor an intranet web server?

はい。ただし、ファイアウォールの例外またはプロキシによるリダイレクトを使用して、Microsoft のサービスへのトラフィックを許可する必要があります。Yes, but you will need to allow traffic to our services by either firewall exceptions or proxy redirects.

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

ここでサービスと IP アドレスのすべての一覧を確認できます。Review our full list of services and IP addresses here.

ファイアウォールの例外Firewall exception

ご利用の Web サーバーから Microsoft のエンドポイントへの利用統計情報の送信を許可します。Allow your web server to send telemetry to our endpoints.

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

構成内のエンドポイントを上書きすることによって、ご利用のサーバーからのトラフィックをイントラネット上のゲートウェイにルーティングします。Route traffic from your server to a gateway on your intranet by overwriting Endpoints in your configuration. これらの "Endpoint" プロパティが config に存在しない場合、これらのクラスは、次の ApplicationInsights.config の例に示されているように、既定値を使用します。If these "Endpoint" properties are not present in your config, these classes will use the default values shown below in the example ApplicationInsights.config.

ご利用のゲートウェイは、Microsoft のエンドポイントのベース アドレスにトラフィックをルーティングする必要があります。Your gateway should route traffic to our endpoint's base address. 構成内の既定値を http://<your.gateway.address>/<relative path> に置き換えてください。In your configuration, replace the default values with http://<your.gateway.address>/<relative path>.

既定のエンドポイントを使用する ApplicationInsights.config の例:Example ApplicationInsights.config with default endpoints:
<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>

注意

ApplicationIdProvider は v2.6.0 以降で使用できます。ApplicationIdProvider is available starting in v2.6.0.

プロキシのパススルーProxy passthrough

プロキシのパススルーは、マシン レベルとアプリケーション レベルのどちらかのプロキシを構成することで実現できます。Proxy passthrough can be achieved by configuring either a machine level or application level proxy. 詳細については、DefaultProxy に関する dotnet の記事を参照してください。For more information see dotnet's article on DefaultProxy.

Web.config の例:Example Web.config:

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

イントラネット サーバーで可用性 Web テストを実行できますか?Can I run Availability web tests on an intranet server?

Microsoft の Web テストは、世界中に分布する Points of Presence で実行されます。Our web tests run on points of presence that are distributed around the globe. 以下に示す 2 つのソリューションがあります。There are two solutions:

  • ファイアウォール ドア - 頻繁に変更される多数の Web テスト エージェントからのサーバーへの要求を許可します。Firewall door - Allow requests to your server from the long and changeable list of web test agents.
  • イントラネット内部からサーバーに定期的な要求を送信する独自のコードを記述します。Write your own code to send periodic requests to your server from inside your intranet. Visual Studio Web テストを実行して、このコードをテストすることができます。You could run Visual Studio web tests for this purpose. テストの結果は TrackAvailability() API を使用して Application Insights に送信できます。The tester could send the results to Application Insights using the TrackAvailability() API.

テレメトリの収集にはどれくらいの時間がかかりますか?How long does it take for telemetry to be collected?

Application Insights のほとんどのデータは、待ち時間が 5 分未満となっています。Most Application Insights data has a latency of under 5 minutes. 一部のデータ (通常は、大きなログ ファイル) については、それよりも時間がかかることがあります。Some data can take longer; typically larger log files. 詳細については、「Application Insights の SLA」を参照してください。For more information, see the Application Insights SLA.

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

"502 無効なゲートウェイです" エラーと "503 サービスを利用できません" エラーは、Application Insights によって常にキャプチャされるわけではありません。"502 bad gateway" and "503 service unavailable" errors are not always captured by Application Insights. クライアント側の JavaScript が監視に使用されている場合にのみ、これは予期される動作となります。監視 JavaScript スニペットが表示されている HTML ヘッダーを含むページの前でエラー応答が返されるためです。If only client-side JavaScript is being used for monitoring this would be expected behavior since the error response is returned prior to the page containing the HTML header with the monitoring JavaScript snippet being rendered.

サーバー側の監視が有効になっているサーバーから 502 または 503 の応答が送信された場合は、Application Insights SDK によってエラーが収集されます。If the 502 or 503 response was sent from a server with server-side monitoring enabled the errors would be collected by the Application Insights SDK.

ただし、アプリケーションの Web サーバーでサーバー側の監視が有効になっていても、Application Insights によって 502 エラーまたは 503 エラーがキャプチャされない場合もあります。However, there are still cases where even when server-side monitoring is enabled on an application's web server that a 502 or 503 error will not be captured by Application Insights. 多くの最新の Web サーバーでは、クライアントが直接通信することはできませんが、代わりにリバース プロキシなどのソリューションを使用して、クライアントとフロントエンド Web サーバーの間で情報をやり取りすることはできます。Many modern web servers do not allow a client to communicate directly, but instead employ solutions like reverse proxies to pass information back and forth between the client and the front-end web servers.

このシナリオでは、リバース プロキシ レイヤーでの問題により、502 または 503 の応答がクライアントに返されますが、Application Insights によってすぐにキャプチャされることはありません。In this scenario, a 502 or 503 response could be returned to a client due to an issue at the reverse proxy layer and this would not be captured out-of-box by Application Insights. このレイヤーでの問題を検出するには、リバース プロキシから Log Analytics にログを転送し、502/503 の応答を確認するためのカスタム ルールを作成する必要があります。To help detect issues at this layer you may need to forward logs from your reverse proxy to Log Analytics and create a custom rule to check for 502/503 responses. 502 エラーと 503 エラーの一般的な原因の詳細については、Azure App Service の "502 無効なゲートウェイです" と "503 サービスを利用できません" のトラブルシューティングに関する記事を参照してください。To learn more about common causes of 502 and 503 errors consult the Azure App Service troubleshooting article for "502 bad gateway" and "503 service unavailable".

OpenTelemetryOpenTelemetry

OpenTelemetry とはWhat is OpenTelemetry

監視のための新しいオープンソース標準です。A new open-source standard for observability. 詳細については、https://opentelemetry.io/ をご覧ください。Learn more at https://opentelemetry.io/.

Microsoft/Azure Monitor が OpenTelemetry に投資しているのはなぜですか?Why is Microsoft / Azure Monitor investing in OpenTelemetry?

次の 3 つの理由から、お客様により良いサービスを提供できると確信しています。We believe it better serves our customers for three reasons:

  1. より多くの顧客シナリオのサポートを可能にする。Enable support for more customer scenarios.
  2. ベンダー ロックインの心配をせずにインストルメント化する。Instrument without fear of vendor lock-in.
  3. 顧客の透明性とエンゲージメントを向上させる。Increase customer transparency and engagement.

また、オープン ソースを採用するという Microsoft の戦略とも一致しています。It also aligns with Microsoft’s strategy to embrace open source.

OpenTelemetry で提供される付加価値は何ですか?What additional value does OpenTelemetry give me?

上記の理由に加えて、OpenTelemetry は、より効率的かつ大規模であり、言語間で一貫した設計または構成が提供されます。In addition to the reasons above, OpenTelemetry is more efficient at-scale and provides consistent design/configurations across languages.

OpenTelemetry をテストするにはどうしたらよいですか?How can I test out OpenTelemetry?

https://aka.ms/AzMonOtel で Azure Monitor Application Insights 早期導入者コミュニティにサインアップして参加してください。Sign up to join our Azure Monitor Application Insights early adopter community at https://aka.ms/AzMonOtel.

OpenTelemetry のコンテキストで GA はどういう意味ですか?What does GA mean in the context of OpenTelemetry?

OpenTelemetry コミュニティは、ここで一般提供 (GA) を定義しています。The OpenTelemetry community defines Generally Available (GA) here. ただし、OpenTelemetry の "GA" は、既存の Application Insights SDK との機能パリティを意味するものではありません。However, OpenTelemetry “GA” does not mean feature parity with the existing Application Insights SDKs. Azure Monitor では、事前に集計されたメトリックライブ メトリックアダプティブ サンプリングプロファイラースナップショット デバッガーなどの機能を必要とするお客様に対しては、OpenTelemetry SDK の機能が成熟するまで、現在の Application Insights SDK が今後も推奨されます。Azure Monitor will continue to recommend our current Application Insights SDKs for customers requiring features such as pre-aggregated metrics, live metrics, adaptive sampling, profiler, and snapshot debugger until the OpenTelemetry SDKs reach feature maturity.

運用環境でプレビュー ビルドを使用できますか?Can I use Preview builds in production environments?

それはお勧めしません。It’s not recommended. 詳細については、「Microsoft Azure プレビューの追加使用条件」を参照してください。See Supplemental Terms of Use for Microsoft Azure Previews for more information.

OpenTelemetry SDK と自動インストルメンテーションの違いは何ですか?What’s the difference between OpenTelemetry SDK and auto-instrumentation?

OpenTelemetry の仕様で SDK は定義されています。The OpenTelemetry specification defines SDK. つまり、"SDK" は、アプリケーションのさまざまなコンポーネントにわたってテレメトリ データを収集し、エクスポーターを介して Azure Monitor にデータを送信する、言語固有のパッケージです。In short, “SDK” is a language-specific package that collects telemetry data across the various components of your application and sends the data to Azure Monitor via an exporter.

自動インストルメンテーション (バイトコード インジェクション、コード不要、またはエージェントベースと呼ばれることもあります) の概念は、コードを変更せずにアプリケーションをインストルメント化する機能を指します。The concept of auto-instrumentation (sometimes referred to as bytecode injection, codeless, or agent-based) refers to the capability to instrument your application without changing your code. 例については、OpenTelemetry Java 自動インストルメンテーションの Readme で詳細を確認してください。For example, check out the OpenTelemetry Java Auto-instrumentation Readme for more information.

OpenTelemetry コレクターとは何ですか?What’s the OpenTelemetry Collector?

OpenTelemetry コレクターについては、GitHub の readme で説明されています。The OpenTelemetry Collector is described in its GitHub readme. 現在、Microsoft は OpenTelemetry コレクターを利用しておらず、Azure Monitor の Application Insights に送信するダイレクト エクスポーターに依存しています。Currently Microsoft does not utilize the OpenTelemetry Collector and depends on direct exporters that send to Azure Monitor’s Application Insights.

OpenCensus と OpenTelemetry の違いは何ですか?What’s the difference between OpenCensus and OpenTelemetry?

OpenCensusOpenTelemetry の前段階です。OpenCensus is the precursor to OpenTelemetry. Microsoft は、OpenTracing と OpenCensus を統合して、世界の単一の監視標準である OpenTelemetry の作成を支援しました。Microsoft helped bring together OpenTracing and OpenCensus to create OpenTelemetry, a single observability standard for the world. Azure Monitor の現在の運用環境で推奨されている Python SDK は OpenCensus に基づいていますが、最終的には、すべての Azure Monitor の SDK が OpenTelemetry に基づくようになります。Azure Monitor’s current production-recommended Python SDK is based on OpenCensus, but eventually all Azure Monitor’s SDKs will be based on OpenTelemetry.

コンテナーに対する Azure MonitorAzure Monitor for containers

正常性機能 (プライベート プレビュー)Health feature is in private preview

機能を追加するための一連の変更を行い、お客様からのフィードバックに対処する予定です。We are planning to make a series of changes to add functionality and address your feedback. 正常性機能は、2020 年 6 月末にプライベート プレビューに移行します。詳細については、Azure 更新プログラムに関するお知らせを参照してください。The Health feature is going to transition to a private preview at the end of June 2020, and for additional information review the following Azure updates announcement.

ノード ビューで [その他のプロセス] は何を表していますか?What does Other Processes represent under the Node view?

[その他のプロセス] は、ノードのリソース使用率が高い根本原因を明確に理解するのに役立つことを目的としています。Other processes are intended to help you clearly understand the root cause of the high resource usage on your node. これによって、コンテナー化されたプロセスとコンテナー化されていないプロセスで使用率を区別できます。This enables you to distinguish usage between containerized processes vs non-containerized processes.

これらの [その他のプロセス] とは何ですか?What are these Other Processes?

これらは、ノードで実行されるコンテナー化されていないプロセスです。These are non-containerized processes that run on your node.

これはどのようにして計算しますか?How do we calculate this?

その他のプロセス = CAdvisor からの合計使用量 - コンテナー化されたプロセスからの使用量Other Processes = Total usage from CAdvisor - Usage from containerized process

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

  • 自己管理型またはマネージド Kubernetes のコンテナー化されていないプロセスSelf-managed or managed Kubernetes non-containerized processes

  • コンテナーの実行時プロセスContainer Run-time processes

  • kubeletKubelet

  • ノードで実行されているシステム プロセスSystem processes running on your node

  • ノード ハードウェアまたは VM 上で実行されている Kubernetes 以外の他のワークロードOther non-Kubernetes workloads running on node hardware or VM

ContainerLog テーブルのクエリを実行したとき、Image プロパティと Name プロパティの値が出力されません。I don't see Image and Name property values populated when I query the ContainerLog table.

エージェント バージョン ciprod12042019 以降では、ログ データの収集にかかるコストを最小限に抑えるため、既定では、これら 2 つのプロパティはすべてのログ行に出力されません。For agent version ciprod12042019 and later, by default these two properties are not populated for every log line to minimize cost incurred on log data collected. これらのプロパティとその値を含めるようにテーブルをクエリする 2 つの方法があります。There are two options to query the table that include these properties with their values:

方法 1Option 1

他のテーブルを結合して、これらのプロパティ値を結果に含めます。Join other tables to include these property values in the results.

ContainerID プロパティに結合することによって ContainerInventory テーブルの Image プロパティと ImageTag プロパティを含めるようにクエリを変更します。Modify your queries to include Image and ImageTag properties from the ContainerInventory table by joining on ContainerID property. ContainerID プロパティに結合することによって、KubepodInventory テーブルの ContaineName フィールドから (以前に ContainerLog テーブルにあったときのように) Name プロパティを含めることができます。You can include the Name property (as it previously appeared in the ContainerLog table) from KubepodInventory table's ContaineName field by joining on the ContainerID property. このオプションを選択することをお勧めします。This is the recommended option.

次の例は、結合を使用してこれらのフィールド値を取得する方法を説明するサンプルの詳細なクエリです。The following example is a sample detailed query that explains how to get these field values with joins.

//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 dont lose logs even if we cannot 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 

方法 2Option 2

すべてのコンテナー ログ行について、これらのプロパティの収集を再び有効にします。Re-enable collection for these properties for every container log line.

クエリの変更を伴うため最初の方法が難しい場合、log_collection_settings.enrich_container_logsデータ収集の構成設定に関するページの説明に従い、エージェントの ConfigMap で 設定を有効にすることによって、これらのフィールドの収集を再び有効にすることができます。If the first option is not convenient due to query changes involved, you can re-enable collecting these fields by enabling the setting log_collection_settings.enrich_container_logs in the agent config map as described in the data collection configuration settings.

注意

2 番目の方法は、50 を超えるノードを持つ大規模なクラスターでは推奨されません。このエンリッチメントを実行するために、クラスター内のすべてのノードから API サーバー呼び出しが生成されるからです。The second option is not recommended with large clusters that have more than 50 nodes because it generates API server calls from every node in the cluster to perform this enrichment. この方法を使用すると、収集されるすべてのログ行のデータ サイズも増加します。This option also increases data size for every log line collected.

Grafana で収集されたメトリックを表示できますか?Can I view metrics collected in Grafana?

Azure Monitor for Containers では、Grafana ダッシュボードの Log Analytics ワークスペースに格納されているメトリックの表示をサポートしています。Azure Monitor for containers supports viewing metrics stored in your Log Analytics workspace in Grafana dashboards. Grafana のダッシュボード リポジトリからダウンロードできるテンプレートが用意されています。これを使って作業を開始し、監視対象クラスターから追加データのクエリを実行して、カスタム Grafana ダッシュボードで視覚化する方法を学習できます。We have provided a template that you can download from Grafana's dashboard repository to get you started and reference to help you learn how to query additional data from your monitored clusters to visualize in custom Grafana dashboards.

Azure Monitor for containers で AKS エンジンのクラスターを監視できますか?Can I monitor my AKS-engine cluster with Azure Monitor for containers?

Azure Monitor for containers は、Azure をホストとする AKS エンジン (旧称 ACS エンジン) クラスターにデプロイされたコンテナー ワークロードの監視をサポートしています。Azure Monitor for containers supports monitoring container workloads deployed to AKS-engine (formerly known as ACS-engine) cluster(s) hosted on Azure. このシナリオでの監視を有効にするために必要な手順の概要および詳細については、AKS エンジンへの Azure Monitor for containers の使用に関するページを参照してください。For further details and an overview of steps required to enable monitoring for this scenario, see Using Azure Monitor for containers for AKS-engine.

Log Analytics ワークスペースにデータが表示されないのはなぜですかWhy don't I see data in my Log Analytics workspace?

Log Analytics ワークスペースで、毎日特定の時間にデータが表示されない場合は、既定の 500 MB の制限に達したか、または毎日収集するデータ量を制御するために指定された 1 日の上限に達している可能性があります。If you are unable to see any data in the Log Analytics workspace at a certain time everyday, you may have reached the default 500 MB limit or the daily cap specified to control the amount of data to collect daily. その日の上限に達すると、データ収集が停止し、次の日にしか再開されません。When the limit is met for the day, data collection stops and resumes only on the next day. データ利用状況を確認して、予期される利用パターンに基づいて別の価格レベルに更新するには、ログ データの使用量とコストに関する記事をご覧ください。To review your data usage and update to a different pricing tier based on your anticipated usage patterns, see Log data usage and cost.

ContainerInventory テーブルではどのようなコンテナーの状態が指定されますかWhat are the container states specified in the ContainerInventory table?

ContainerInventory テーブルには、停止中と実行中両方のコンテナーに関する情報が含まれています。The ContainerInventory table contains information about both stopped and running containers. テーブルの値は、エージェント内のワークフローによって設定されます。このワークフローでは、Docker に対してすべてのコンテナー (実行中と停止) のクエリが実行され、そのデータが Log Analytics ワークスペースに転送されます。The table is populated by a workflow inside the agent that queries the docker for all the containers (running and stopped), and forwards that data the Log Analytics workspace.

"サブスクリプション登録がない" エラーを解決するにはどうすればよいですかHow do I resolve Missing Subscription registration error?

"Microsoft.OperationsManagement へのサブスクリプション登録がない" というエラーが表示される場合は、ワークスペースが定義されているサブスクリプションでリソース プロバイダー Microsoft.OperationsManagement を登録することで解決できます。If you receive the error Missing Subscription registration for Microsoft.OperationsManagement, you can resolve it by registering the resource provider Microsoft.OperationsManagement in the subscription where the workspace is defined. これを行う方法に関するドキュメントは、こちらにあります。The documentation for how to do this can be found here.

RBAC 対応の AKS クラスターはサポートされていますかIs there support for RBAC enabled AKS clusters?

コンテナー監視ソリューションでは RBAC がサポートされていませんが、Azure Monitor for Containers ではサポートされています。The Container Monitoring solution doesn't support RBAC, but it is supported with Azure Monitor for Containers. これらのクラスターのデータが示されるブレードでは、ソリューションの詳細ページに正しい情報が表示されない場合があります。The solution details page may not show the right information in the blades that show data for these clusters.

Helm を使用して kube システム名前空間内のコンテナーのログ収集を有効にするにはどうすればよいですかHow do I enable log collection for containers in the kube-system namespace through Helm?

Kube システム名前空間内のコンテナーからのログ収集は、既定では無効になっています。The log collection from containers in the kube-system namespace is disabled by default. omsagent で環境変数を設定することにより、ログ収集を有効にすることができます。Log collection can be enabled by setting an environment variable on the omsagent. 詳しくは、コンテナーの Azure Monitorに関する GitHub のページをご覧ください。For more information, see the Azure Monitor for containers GitHub page.

omsagent を最新リリースのバージョンに更新するにはどうすればよいですかHow do I update the omsagent to the latest released version?

エージェントをアップグレードする方法については、エージェントの管理に関する記事をご覧ください。To learn how to upgrade the agent, see Agent management.

複数行のログ記録を有効にするにはどうすればよいですかHow do I enable multi-line logging?

現在、コンテナーの Azure Monitor では複数行のログ記録はサポートされていませんが、利用可能な回避策があります。Currently Azure Monitor for containers doesn't support multi-line logging, but there are workarounds available. JSON 形式で書き込むようにすべてのサービスを構成することができ、Docker/Moby ではそれが単一行として書き込まれます。You can configure all the services to write in JSON format and then Docker/Moby will write them as a single line.

たとえば、サンプルの node.js アプリケーションに対する次の例で示すように、JSON オブジェクトとしてログをラップすることができます。For example, you can wrap your log as a JSON object as shown in the example below for a sample node.js application:

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

このデータは、クエリを実行すると、Azure Monitor のログに次の例のように表示されます。This data will look like the following example in Azure Monitor for logs when you query for it:

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

問題の詳細については、こちらの GitHub リンクをご覧ください。For a detailed look at the issue, review the following GitHub link.

ライブ ログを有効にしたときの Azure AD のエラーを解決するにはどうすればよいですかHow do I resolve Azure AD errors when I enable live logs?

次のエラーがに表示される場合があります。要求で指定されている応答 URL が、アプリケーションに関して構成されている応答 URL と一致しません ('<application ID>' )。You may see the following error: The reply url specified in the request does not match the reply urls configured for the application: '<application ID>'. それを解決するためのソリューションについては、Azure Monitor for containers を使用して、コンテナー データをリアルタイムで表示する方法に関する記事をご覧ください。The solution to solve it can be found in the article How to view container data in real time with Azure Monitor for containers.

オンボード後にクラスターをアップグレードできないのはなぜですかWhy can't I upgrade cluster after onboarding?

AKS クラスターに対して Azure Monitor for containers を有効にした後、クラスターがデータを送信していた Log Analytics ワークスペースを削除する場合、クラスターをアップグレードしようとすると失敗します。If after you enable Azure Monitor for containers for an AKS cluster, you delete the Log Analytics workspace the cluster was sending its data to, when attempting to upgrade the cluster it will fail. これを回避するには、監視を無効にしてから、サブスクリプション内の別の有効なワークスペースを参照して、監視を再度有効にする必要があります。To work around this, you will have to disable monitoring and then re-enable it referencing a different valid workspace in your subscription. クラスターのアップグレードをもう一度実行しようとすると、正常に処理され、完了するはずです。When you try to perform the cluster upgrade again, it should process and complete successfully.

エージェントに対して開いたり許可したりする必要があるポートとドメインはどれですか?Which ports and domains do I need to open/allow for the agent?

Azure、Azure US Government、および Azure China 21Vianet クラウドでコンテナー化されたエージェントに必要なプロキシとファイアウォールの構成情報については、「ネットワーク ファイアウォールの要件」をご覧ください。See the Network firewall requirements for the proxy and firewall configuration information required for the containerized agent with Azure, Azure US Government, and Azure China 21Vianet clouds.

VM に対する Azure MonitorAzure Monitor for VMs

既存のワークスペースにオンボードすることはできますか?Can I onboard to an existing workspace?

仮想マシンが Log Analytics ワークスペースに既に接続されている場合、ワークスペースがサポートされているリージョンのいずれかにあれば、Azure Monitor for VMs にオンボードするときにそのワークスペースを引き続き使用できます。If your virtual machines are already connected to a Log Analytics workspace, you may continue to use that workspace when onboarding to Azure Monitor for VMs, provided it is in one of the supported regions.

新しいワークスペースにオンボードすることはできますか?Can I onboard to a new workspace?

現在、VM が既存の Log Analytics ワークスペースに接続されていない場合は、データを保存するために新しいワークスペースを作成する必要があります。If your VMs are not currently connected to an existing Log Analytics workspace, you need to create a new workspace to store your data. Azure portal を使用して Azure Monitor for VMs で単一の Azure VM を構成すると、新しい既定のワークスペースが自動的に作成されます。Creating a new default workspace is done automatically if you configure a single Azure VM for Azure Monitor for VMs through the Azure portal.

スクリプト ベースのメソッドを使用する場合、これらの手順は、Azure PowerShell または Resource Manager テンプレートを使用した Azure Monitor for VMs の有効化に関する記事で説明されています。If you choose to use the script-based method, these steps are covered in the Enable Azure Monitor for VMs using Azure PowerShell or Resource Manager template article.

VM が既に既存のワークスペースに報告している場合はどうすればよいですか?What do I do if my VM is already reporting to an existing workspace?

仮想マシンから既にデータを収集している場合、既存の Log Analytics ワークスペースにデータを報告するように仮想マシンを構成済みである可能性があります。If you are already collecting data from your virtual machines, you may have already configured it to report data to an existing Log Analytics workspace. そのワークスペースがサポートされているリージョンのいずれかにあれば、その既存のワークスペースに対して Azure Monitor for VMs を有効にすることができます。As long as that workspace is in one of our supported regions, you can enable Azure Monitor for VMs to that pre-existing workspace. 既に使用しているワークスペースがサポートされているリージョンにない場合、現時点では Azure Monitor for VMs にオンボードすることはできません。If the workspace you are already using is not in one of our supported regions, you won't be able to onboard to Azure Monitor for VMs at this time. Microsoft では、その他のリージョンのサポートに積極的に取り組んでいます。We are actively working to support additional regions.

VM のオンボードに失敗したのはなぜですか?Why did my VM fail to onboard?

Azure portal から Azure VM をオンボードすると、次の手順が実行されます。When onboarding an Azure VM from the Azure portal, the following steps occur:

  • 既定の Log Analytics ワークスペースが作成されます (該当するオプションが選択されている場合)。A default Log Analytics workspace is created, if that option was selected.
  • Log Analytics エージェントが必要と判断されると、VM 拡張機能を使用して Azure VM にインストールされます。The Log Analytics agent is installed on Azure VMs using a VM extension, if determined it is required.
  • Azure Monitor for VMs Map Dependency エージェントが必要と判断されると、拡張機能を使用して Azure VM にインストールされます。The Azure Monitor for VMs Map Dependency agent is installed on Azure VMs using an extension, if determined it is required.

オンボード プロセス中、上記の各手順で状態がチェックされ、ポータルで通知の状態が返されます。During the onboard process, we check for status on each of the above to return a notification status to you in the portal. ワークスペースとエージェントのインストールの構成には、通常 5 から 10 分かかります。Configuration of the workspace and the agent installation typically takes 5 to 10 minutes. 監視データがポータルに表示されるまでに、さらに 5 から 10 分かかります。Viewing monitoring data in the portal take an additional 5 to 10 minutes.

オンボードを開始したときに、VM をオンボードする必要があることを示すメッセージが表示された場合は、VM がプロセスを完了するまでに最大 30 分かかります。If you have initiated onboarding and see messages indicating the VM needs to be onboarded, allow for up to 30 minutes for the VM to complete the process.

パフォーマンス グラフに VM のデータが表示されませんI don't see some or any data in the performance charts for my VM

パフォーマンス グラフは、InsightsMetrics テーブルに格納されているデータを使用するように更新されました。Our performance charts have been updated to use data stored in the InsightsMetrics table. これらのグラフのデータを表示するには、新しい VM Insights ソリューションを使用するようにアップグレードする必要があります。To see data in these charts you will need to upgrade to use the new VM Insights solution. 追加情報については、一般提供についての FAQ に関する記事を参照してください。Please refer to our GA FAQ for additional information.

ディスク テーブルまたは一部のパフォーマンス グラフにパフォーマンス データが表示されない場合、ワークスペースでパフォーマンス カウンターが構成されていない可能性があります。If you don't see performance data in the disk table or in some of the performance charts then your performance counters may not be configured in the workspace. これを解決するには、こちらの PowerShell スクリプトを実行してください。To resolve, run the following PowerShell script.

Azure Monitor for VMs のマップ機能は Service Map とどのように異なるのですか?How is Azure Monitor for VMs Map feature different from Service Map?

Azure Monitor for VMs のマップ機能は Service Map に基づいていますが、次の点が異なります。The Azure Monitor for VMs Map feature is based on Service Map, but has the following differences:

  • マップ ビューには、VM のブレード、および [Azure Monitor] の [Azure Monitor for VMs](Azure Monitor for VMs) からアクセスできます。The Map view can be accessed from the VM blade and from Azure Monitor for VMs under Azure Monitor.
  • マップ内の接続がクリック可能になっており、選択した接続のサイド パネルに接続メトリック データのビューが表示されます。The connections in the Map are now clickable and display a view of the connection metric data in the side panel for the selected connection.
  • より複雑なマップのサポートを強化するために、マップの作成に使用される新しい API が用意されています。There is a new API that is used to create the maps to better support more complex maps.
  • 監視対象の VM がクライアント グループ ノードに含まれるようになりました。グループ内の監視対象の仮想マシンと監視対象外の仮想マシンの割合がドーナツ グラフに示されます。Monitored VMs are now included in the client group node, and the donut chart shows the proportion of monitored vs unmonitored virtual machines in the group. また、グループを展開したときに、これを使用してマシンの一覧をフィルター処理することもできます。It can also be used to filter the list of machines when the group is expanded.
  • 監視対象の仮想マシンがサーバー ポート グループ ノードに含まれるようになりました。グループ内の監視対象のマシンと監視対象外のマシンの割合がドーナツ グラフに示されます。Monitored virtual machines are now included in the server port group nodes, and the donut chart shows the proportion of monitored vs unmonitored machines in the group. また、グループを展開したときに、これを使用してマシンの一覧をフィルター処理することもできます。It can also be used to filter the list of machines when the group is expanded.
  • Application Insights のアプリ マップとの一貫性を向上させるために、マップのスタイルが更新されました。The map style has been updated to be more consistent with App Map from Application insights.
  • サイド パネルが更新されましたが、Service Map でサポートされていた Update Management、Change Tracking、Security、およびService Desk との統合は含まれていません。The side panels have been updated, and do not have the full set of integration's that were supported in Service Map - Update Management, Change Tracking, Security, and Service Desk.
  • マップするグループとマシンを選択するオプションが更新され、サブスクリプション、リソース グループ、Azure 仮想マシン スケール セット、クラウド サービスがサポートされるようになりました。The option for choosing groups and machines to map has been updated and now supports Subscriptions, Resource Groups, Azure virtual machine scale sets, and Cloud services.
  • Azure Monitor for VMs のマップ機能では、新しい Service Map コンピューター グループを作成することはできません。You cannot create new Service Map machine groups in the Azure Monitor for VMs Map feature.

パフォーマンス グラフに点線が表示されるのはなぜですか?Why do my performance charts show dotted lines?

これはいくつかの理由で発生する可能性があります。This can occur for a few reasons. 表示するデータ収集にギャップがある場合、点線が表示されます。In cases where there is a gap in data collection we depict the lines as dotted. 有効になっているパフォーマンス カウンターのデータ サンプリング頻度を変更したときに (既定の設定では、60 秒ごとにデータが収集されます)、グラフの時間範囲を狭め、サンプリング頻度がグラフで使用されるバケット サイズよりも少ない場合 (たとえば、サンプリング頻度が 10分 ごとで、グラフの各バケットが 5 分の場合)、グラフに点線が表示されます。If you have modified the data sampling frequency for the performance counters enabled (the default setting is to collect data every 60 seconds), you can see dotted lines in the chart if you choose a narrow time range for the chart and your sampling frequency is less than the bucket size used in the chart (for example, the sampling frequency is every 10 minutes and each bucket on the chart is 5 minutes). この場合、表示する時間範囲を広げると、グラフの線が点線ではなく実線で表示されます。Choosing a wider time range to view should cause the chart lines to appear as solid lines rather than dots in this case.

Azure Monitor for VMs でグループはサポートされていますか?Are groups supported with Azure Monitor for VMs?

はい、Dependency エージェントをインストールすると、VM から情報が収集され、サブスクリプション、リソース グループ、仮想マシン スケール セット、およびクラウド サービスに基づいてグループが表示されます。Yes, once you install the Dependency agent we collect information from the VMs to display groups based upon subscription, resource group, virtual machine scale sets, and cloud services. Service Map を使用し、マシン グループを作成している場合も、これらが表示されます。If you have been using Service Map and have created machine groups, these are displayed as well. 表示中のワークスペースでコンピューター グループを作成している場合は、それらもグループ フィルターに表示されます。Computer groups will also appear in the groups filter if you have created them for the workspace you are viewing.

集計パフォーマンス グラフで 95 百分位線を引き上げているものについて詳細を確認するにはどうすればよいですか?How do I see the details for what is driving the 95th percentile line in the aggregate performance charts?

既定では、選択されたメトリックで 95 パーセンタイルの最大値を持つ VM を示すためにリストが並べ替えられます。ただし、5 パーセンタイルの最小値を持つマシンが表示される、使用可能なメモリのグラフを除きます。By default, the list is sorted to show you the VMs that have the highest value for the 95th percentile for the selected metric, except for the Available memory chart, which shows the machines with the lowest value of the 5th percentile. グラフをクリックすると、適切なメトリックが選択された [Top N List](上位 N のリスト) ビューが開きます。Clicking on the chart will open the Top N List view with the appropriate metric selected.

マップ機能では、VNet 間およびサブネット間で重複する IP はどのように処理されますか?How does the Map feature handle duplicate IPs across different vnets and subnets?

サブネット間および VNet 間で VM または Azure 仮想マシン スケール セットの IP 範囲が重複している場合、Azure Monitor for VMs に間違った情報が表示されることがあります。If you are duplicating IP ranges either with VMs or Azure virtual machine scale sets across subnets and vnets, it can cause Azure Monitor for VMs Map to display incorrect information. これは既知の問題であり、このエクスペリエンスを改善するためのオプションを検討中です。This is a known issue and we are investigating options to improve this experience.

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

現在、マップ機能では IPv4 のみがサポートされています。IPv6 のサポートは検討中です。Map feature currently only supports IPv4 and we are investigating support for IPv6. IPv6 内でトンネリングされる IPv4 もサポートされています。We also support IPv4 that is tunneled inside IPv6.

リソース グループや他の大規模なグループのマップを読み込んだときに、マップを表示しづらくなりますWhen I load a map for a Resource Group or other large group the map is difficult to view

大規模で複雑な構成に対応できるようにマップを改善しましたが、マップに多数のノード、接続、クラスターとして機能するノードが含まれている場合があることがわかりました。While we have made improvements to Map to handle large and complex configurations, we realize a map can have a lot of nodes, connections, and node working as a cluster. Microsoft では、スケーラビリティを向上させるサポートの継続的な強化に取り組んでいます。We are committed to continuing to enhance support to increase scalability.

[パフォーマンス] タブのネットワーク グラフと Azure VM の概要ページのネットワーク グラフが異なるのはなぜですか?Why does the network chart on the Performance tab look different than the network chart on the Azure VM Overview page?

Azure VM の概要ページには、ゲスト VM でのアクティビティのホストの測定に基づいてグラフが表示されます。The overview page for an Azure VM displays charts based on the host's measurement of activity in the guest VM. Azure VM の概要のネットワーク グラフでは、課金対象となるネットワーク トラフィックのみが表示されます。For the network chart on the Azure VM Overview, it only displays network traffic that will be billed. これには、仮想ネットワーク間トラフィックは含まれません。This does not include inter-virtual network traffic. Azure Monitor for VMs に表示されるデータとグラフは、ゲスト VM のデータに基づいており、ネットワーク グラフには、仮想ネットワーク間も含め、その VM に対する受信および送信のすべての TCP/IP トラフィックが表示されます。The data and charts shown for Azure Monitor for VMs is based on data from the guest VM and the network chart displays all TCP/IP traffic that is inbound and outbound to that VM, including inter-virtual network.

VMConnection に格納されているデータの応答時間はどのように測定されて、接続パネルとブックに表示されるのですか?How is response time measured for data stored in VMConnection and displayed in the connection panel and workbooks?

応答時間は概算です。Response time is an approximation. アプリケーションのコードがインストルメント化されていないため、要求がいつ開始され、応答をいつ受信したのかは、実際にはわかりません。Since we do not instrument the code of the application, we do not really know when a request begins and when the response arrives. その代わり、接続上で送信されるデータと、その接続で返されるデータが監視されます。Instead we observe data being sent on a connection and then data coming back on that connection. それらの送信と受信は、エージェントによって追跡され、ペアリングが試みられます。つまり、一連の送信とそれに続く一連の受信が要求/応答のペアとして解釈されます。Our agent keeps track of these sends and receives and attempts to pair them: a sequence of sends, followed by a sequence of receives is interpreted as a request/response pair. その操作の間隔が応答時間となります。The timing between these operations is the response time. そこにはネットワーク待ち時間とサーバーの処理時間が含まれます。It will include the network latency and the server processing time.

要求/応答ベースのプロトコル、つまり接続上で単一の要求を送信して単一の応答を受信するプロトコルでは、この概算がうまく機能します。This approximation works well for protocols that are request/response based: a single request goes out on the connection, and a single response arrives. HTTP(S) (パイプライン処理を伴わないもの) はそれに該当しますが、他のプロトコルでは十分に機能しません。This is the case for HTTP(S) (without pipelining), but not satisfied for other protocols.

Log Analytics の無料プランを利用している場合、機能の制限はありますか?Are there limitations if I am on the Log Analytics Free pricing plan?

無料の価格レベルを使った Log Analytics ワークスペースで Azure Monitor を構成した場合、Azure Monitor for VMs Map 機能では、ワークスペースに接続できるマシンが 5 つに制限されます。If you have configured Azure Monitor with a Log Analytics workspace using the Free pricing tier, Azure Monitor for VMs Map feature will only support five connected machines connected to the workspace. 無料のワークスペースに VM が 5 つ接続されている場合、いずれかの VM を切断した後に新しい VM を接続すると、新しい VM は監視されず、マップ ページにも反映されません。If you have five VMs connected to a free workspace, you disconnect one of the VMs and then later connect a new VM, the new VM is not monitored and reflected on the Map page.

この条件下では、VM を開いて左側のウィンドウから [Insights](インサイト) を選択すると、機能が既に VM にインストール済みであっても、 [今すぐ試す] オプションが表示されます。Under this condition, you will be prompted with the Try Now option when you open the VM and select Insights from the left-hand pane, even after it has been installed already on the VM. ただし、その VM が Azure Monitor for VMs にオンボードされていない場合には、オプションは表示されません。However, you are not prompted with options as would normally occur if this VM were not onboarded to Azure Monitor for VMs.

次のステップNext steps

質問の回答がここで見つからない場合は、次のフォーラムで他の質問と回答を参照できます。If your question isn't answered here, you can refer to the following forums to additional questions and answers.

Azure Monitor に関する一般的なフィードバックについては、フィードバック フォーラムにアクセスしてください。For general feedback on Azure Monitor please visit the feedback forum.