Azure Monitor Application Insights の公式 FAQ。 Azure Monitor での Application Insights の使用に関する質問への回答を見つけます。
概要
アプリケーションをインストルメント化するには
Application Insights を有効にするためのアプリケーションのインストルメント化の詳細については、 データ収集の基本を参照してください。
Application Insights の使用方法
アプリケーションをインストルメント化して Application Insights を有効にした後、最初にライブ メトリックとアプリケーション マップをチェックアウトすることをお勧めします。
Application Insights では、どのようなテレメトリが収集されますか?
サーバーの Web アプリから:
- HTTP 要求。
- 依存関係。 SQL データベースに対する呼び出し、外部サービス、Azure Cosmos DB、Azure Table Storage、Azure Blob Storage、Azure Queue Storage に対する HTTP 呼び出し。
- 例外 とスタック トレース。
- パフォーマンス カウンター: パフォーマンス カウンターは、次を使用するときに使用できます。
- コード化するカスタム イベントとメトリック。
- 適切なコレクターを構成した場合は、ログをトレースします。
アプリでのキャッチされない例外 (以下の情報が含まれる)
- スタック トレース
- 例外の詳細とエラーに付随するメッセージ
- エラーの行番号と列番号
- エラーが発生した URL
- アプリの XML Http 要求 (XHR) および Fetch (フェッチ コレクションは既定では無効) 要求によって実行されるネットワーク依存関係要求には、以下の情報が含まれます。
- 依存関係ソースの URL
- 依存関係の要求に使用されたコマンドとメソッド
- 要求の期間
- 要求の結果コードと成功状態
- 要求を行うユーザーの ID (存在する場合)
- 要求が行われた相関関係コンテキスト (存在する場合)
ユーザー情報 (場所、ネットワーク、IP など)
デバイス情報 (ブラウザー、OS、バージョン、言語、モデルなど)
セッション情報
注
シングルページ アプリケーション (SPA) などの一部のアプリケーションでは、期間が常に記録されるとは限りません。その場合、既定値は 0 です。
詳細については、「 Application Insights でのデータの収集、保持、およびストレージ」を参照してください。
その他のソースから (構成する場合):
デプロイする Application Insights リソースは何個必要ですか？
複数の環境でアプリケーションまたはコンポーネントをカバーするために必要な Application Insights リソースの数については、 Application Insights デプロイ計画ガイドを参照してください。
PowerShell を使用した Application Insights リソースを管理するにはどうすればよいですか?
Azure Resource Monitor を使用して PowerShell スクリプトを記述 すると、次のことができます。
- Application Insights リソースの作成と更新。
- 価格プランの設定。
- インストルメンテーション キーの取得。
- メトリック アラートの追加。
- 可用性テストの追加。
メトリックス エクスプローラー レポートや連続エクスポートは設定できません。
Application Insights テレメトリにクエリを実行するにはどうすればよいか
REST API を使用して Log Analytics クエリを実行します。
テレメトリを Application Insights ポータルに送信できますか?
Azure Monitor OpenTelemetry ディストリビューションをお勧めします。
インジェスト スキーマとエンドポイント プロトコルは公開されています。
テレメトリの収集にはどれくらいの時間がかかりますか?
Application Insights のほとんどのデータは、待ち時間が 5 分未満となっています。 一部のデータ (通常は、大きなログ ファイル) では、これよりも時間がかかることがあります。 Application Insights のサービス レベル アグリーメントを参照してください。
Application Insights では、どのようにデータの収集、保持、保管、プライバシーを処理しますか?
徴収
Application Insights では、Web サーバー テレメトリ、Web ページ テレメトリ、パフォーマンス カウンターなど、お使いのアプリに関するテレメトリを収集します。 このデータは、お使いのアプリのパフォーマンス、正常性、使用状況を監視する目的で使用できます。 新しい Application Insights リソースを作成するときに、場所を選択できます。
保持と保管
データは Application Insights Log Analytics ワークスペースに送信されます。 生データの保持期間は 30 日から 730 日まで選択できます。 集計データは 90 日間保持され、デバッグ スナップショットは 15 日間保持されます。
プライバシー
Application Insights では、機密データは既定では処理されません。 機密データをプレーンテキストとして URL に含めず、カスタム コードで個人やその他の機密情報が収集されないようにすることをお勧めします。 開発とテストの間、IDE とブラウザーのデバッグ出力ウィンドウで送信されたデータを確認します。
アーカイブされた情報については、「 Application Insights でのデータの収集、保持、およびストレージ」を参照してください。
Application Insights の価格モデルについて
Application Insights は、ログ データが取り込まれた Log Analytics ワークスペースを通じて課金されます。 既定の従量課金制 Log Analytics 価格レベルには、課金アカウントごとに、1 か月あたり 5 GB の無料データ許容量が含まれています。 Azure Monitor ログの価格オプションについて詳しく知る。
Azure Web アプリと Application Insights の間でデータ転送料金は発生しますか?
- Application Insights の収集エンドポイントがあるデータセンターで Azure Web アプリがホストされている場合、料金はかかりません。
- ホスト データセンターにコレクション エンドポイントがない場合、アプリのテレメトリには Azure の送信料金が発生します。
この回答は、Application Insights リソースがホストされている場所 ではなく 、エンドポイントの分散によって異なります。
Application Insights リソースが別のリージョンの Azure リソース (つまりテレメトリ プロデューサー) を監視している場合、ネットワーク コストは発生しますか?
はい。テレメトリの取得元と送信先のリージョンによって異なる、追加のネットワーク コストが発生する場合があります。 詳細については、 Azure 帯域幅の価格 に関するページを参照してください。
Application Insights で予期しない料金や高コストが表示される場合は、このガイドが役立ちます。 テレメトリの量が多い、データ インジェストの急増、サンプリングが正しく構成されていないなどの一般的な原因について説明します。 コストの急増、テレメトリボリューム、サンプリングが機能しない、データ上限、高インジェスト、または予期しない課金に関連する問題をトラブルシューティングする場合に特に便利です。 開始するには、「 Application Insights での高いデータ インジェストのトラブルシューティング」を参照してください。
どのような TLS バージョンがサポートされていますか?
Application Insights では、トランスポート層セキュリティ (TLS) 1.2 と 1.3 が使用されます。
Von Bedeutung
2025 年 3 月 1 日に、Azure では、すべてのサービスで従来のバージョンの TLS が廃止されます。 その時点で、Application Insights では TLS 1.0、TLS 1.1、および一覧に示されているレガシ TLS 1.2/1.3 暗号スイートと楕円曲線はサポートされなくなりました。
従来の TLS の問題に関する一般的な質問については、「TLS の問題の解決」および「Azure Resource Manager TLS サポート」を参照してください。
Application Insights に関する詳細情報はどこで入手できますか?
詳細については、「 Application Insights の概要」を参照してください。
カスタムのイベントとメトリックのための Application Insights API
テレメトリ データが見つからないのはなぜですか?
アプリケーションがシャットダウンする前にフラッシュされていない場合、両方のテレメトリ チャネルでバッファリングされたテレメトリが消失します。
データの損失を回避するには、アプリケーションのシャットダウン時に TelemetryClient をフラッシュします。
詳細については、「データのフラッシュ」を参照してください。
Track_() 呼び出しでスローされる例外は何ですか?
なし。 try catch 句で例外をラップする必要はありません。 SDK で問題が発生すると、デバッグ コンソール出力のメッセージが記録されます。メッセージがスルーされる場合は、診断検索にも記録されます。
ポータルからデータを取得する REST API はありますか。
はい、データ アクセス API があります。 データを抽出するその他の方法としては、ワークスペース ベースのリソースでの Power BI があります。
カスタム イベントとメトリック API の呼び出しが無視される理由は?
Application Insights SDK は、自動インストルメンテーションと互換性がありません。 自動インストルメンテーションが有効になっている場合、Track() やその他のカスタム イベントとメトリック API への呼び出しは無視されます。
Azure portal の App Service ページの [Application Insights] タブで自動インストルメンテーションをオフにするか、ApplicationInsightsAgent_EXTENSION_VERSION を disabled に設定します。
検索グラフとメトリック グラフで数が等しくないのはなぜですか?
サンプリングにより、アプリからポータルに送信されるテレメトリ項目 (要求、カスタム イベントなど) の数が減少します。 [検索] には、受信した項目の数が表示されます。 イベント数を表示するメトリック グラフには、発生した元のイベントの数が表示されます。
送信される各項目には、itemCount プロパティが含まれます。このプロパティは、項目が表す元のイベントの数を示します。 Log Analytics で次のクエリを実行すると、サンプリング操作を確認できます。
requests | summarize original_events = sum(itemCount), transmitted_events = count()
イベントにアラートを設定するには、どうすればよいですか?
Azure アラートはメトリックにのみ設定できます。 イベントが発生するたびにしきい値を超える、カスタム メトリックを作成してください。 その後、メトリックにアラートを設定します。 メトリックがどちらの方向であれしきい値を超えると、必ず通知を受け取ります。 初期値が高くても低くても、最初に超えるまでは通知を受け取りません。 常に数分の待ち時間が発生します。
カスタム イベントとメトリックの Application Insights API に関する詳細情報はどこで入手できますか?
詳細については、「カスタムのイベントとメトリックのための Application Insights API」をご覧ください。
オンプレミス サーバー用の Application Insights エージェントのデプロイ
Application Insights エージェントでプロキシのインストールはサポートされますか?
はい。 Application Insights エージェントをダウンロードするには、複数の方法があります。
- コンピューターがインターネットにアクセスできる場合は、
-Proxyパラメーターを使用して PowerShell ギャラリーにオンボードできます。 - このモジュールを手動でダウンロードし、コンピューターにインストールするか、直接使用することもできます。
これらの各オプションについては、詳細な手順で説明しています。
Application Insights エージェントで ASP.NET Core アプリケーションはサポートされますか?
はい。 Application Insights エージェント 2.0.0 以降では、IIS でホストされている ASP.NET Core アプリケーションがサポートされています。
有効化が成功したことを確認する方法を教えてください。
Get-ApplicationInsightsMonitoringStatus コマンドレットを使用して、有効化が成功したことを確認できます。
Live Metrics を使用して、アプリからテレメトリが送信されているかどうかをすばやく判断します。
Log Analytics を使用して、現在テレメトリを送信しているすべてのクラウド ロールを一覧表示することもできます。
union * | summarize count() by cloud_RoleName, cloud_RoleInstance
プロキシ パススルーを実現するにはどうすればよいですか?
プロキシのパススルーを実現するには、マシン レベルのプロキシまたはアプリケーション レベルのプロキシを構成します。 「DefaultProxy」を参照してください。
Web.config の例:
<system.net>
<defaultProxy>
<proxy proxyaddress="http://xx.xx.xx.xx:yyyy" bypassonlocal="true"/>
</defaultProxy>
</system.net>
オンプレミス サーバー用の Application Insights エージェントのデプロイに関する詳細情報はどこで入手できますか?
詳細については、「 オンプレミス サーバー用の Application Insights エージェントのデプロイ」を参照してください。
TLS サポート
TLS の提供終了が影響を受けるかどうかを判断する
Application Insights と Azure Monitor では、HTTPS 接続に使用される TLS バージョンは制御されません。 TLS のバージョンは、アプリケーションが実行されるオペレーティング システムとランタイム環境によって異なります。
使用中の TLS バージョンを確認するには:
- オペレーティング システムとランタイムまたはフレームワークのドキュメントを確認します。
- さらにサポートが必要な場合は、適切なサポート チームにお問い合わせください。 Application Insights でサポート 要求を開かないでください。
TLS 1.2 以降の言語とランタイムのサポート例
次のバージョンには、TLS 1.2 以降の統合サポートが含まれています。
- .NET / .NET Core: .NET Framework 4.6.2 以降、およびすべてのバージョンの .NET Core
- Java: Java 8 更新プログラム 161 (8u161) 以降
- Python: OpenSSL 1.0.1 以降で構築された Python ディストリビューション
- Node.js: バージョン 10 以降 Node.js
TLS 1.2 以降のオペレーティング システムサポートの例
次のオペレーティング システムには、TLS 1.2 以降の統合サポートが含まれています。
- Windows: Windows 8、Windows Server 2012 以降
- Linux: OpenSSL 1.0.1 以降を使用する最新の Linux ディストリビューションのほとんど
リソースが影響を受けないようにするにはどうすればよいですか?
サービスの中断を回避するために、リソースが対話する各リモート エンドポイント (依存する要求を含む) は、前述の同じプロトコル バージョン、暗号スイート、楕円曲線の少なくとも 1 つの組み合わせをサポートする必要があります。 リモート エンドポイントが必要な TLS 構成をサポートしていない場合は、非推奨後の TLS 構成の組み合わせをサポートして更新する必要があります。
2025 年 5 月 1 日以降、影響を受けるリソースの動作は何ですか?
影響を受ける Application Insights リソースはデータの取り込みを停止し、必要なアプリケーション コンポーネントにアクセスできません。 その結果、一部の機能は動作しなくなります。
非推奨が影響を受けるコンポーネントはどれですか?
このドキュメントで詳しく説明されているトランスポート層セキュリティ (TLS) の廃止は、2025 年 5 月 1 日以降の動作にのみ影響する必要があります。 CRUD 操作の詳細については、 Azure Resource Manager TLS のサポートに関するページを参照してください。 このリソースは、TLS のサポートと非推奨化のタイムラインの詳細について説明しています。
トランスポート層セキュリティ (TLS) のサポートはどこで入手できますか?
従来の TLS の問題に関する一般的な質問については、「TLS の問題の解決」を参照してください。
Application Insights の TLS サポートに関する詳細情報はどこで入手できますか?
詳細については、 TLS のサポートを参照してください。
ASP.NET
SDK をアンインストールするにはどうすればよいですか?
Application Insights を削除するには、アプリケーション内の API から NuGet パッケージと参照を削除する必要があります。 NuGet パッケージは、Visual Studio で NuGet パッケージ マネージャーを使ってアンインストールできます。
- トレース コレクションが有効になっている場合は、まず、NuGet パッケージ マネージャーを使って Microsoft.ApplicationInsights.TraceListener パッケージをアンインストールします。ただし、どの依存関係も削除しないでください。
- NuGet パッケージ マネージャーのオプション コントロール内で NuGet パッケージ マネージャーとそのアンインストール オプションを使って、Microsoft.ApplicationInsights.Web パッケージをアンインストールして、その依存関係を削除します。
- Application Insights を完全に削除するには、プロジェクトに追加した API 呼び出しと共に、追加したコードまたはファイルを確認し、それらを手動で削除します。 詳細については、「Application Insights SDK を追加するときに、何が自動的に作成されるのですか?」を参照してください。
Application Insights SDK を追加するときに、何が自動的に作成されるのですか?
Application Insights をプロジェクトに追加すると、自動的にファイルが作成されて、いくつかのファイルにコードが追加されます。 NuGet パッケージをアンインストールしても、そのファイルとコードが必ず破棄されるとは限りません。 Application Insights を完全に削除するには、プロジェクトに追加した API 呼び出しと共に、追加したコードまたはファイルを確認し、それらを手動で削除する必要があります。
Visual Studio ASP.NET プロジェクトに Application Insights Telemetry を追加すると、次のファイルが追加されます。
- ApplicationInsights.config
- AiHandleErrorAttribute.cs
次のコードが自動的に追加されます。
[自分のプロジェクトの名前].csproj
<ApplicationInsightsResourceId>/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/Default-ApplicationInsights-EastUS/providers/microsoft.insights/components/WebApplication4</ApplicationInsightsResourceId>Packages.config
<packages> ... <package id="Microsoft.ApplicationInsights" version="2.12.0" targetFramework="net472" /> <package id="Microsoft.ApplicationInsights.Agent.Intercept" version="2.4.0" targetFramework="net472" /> <package id="Microsoft.ApplicationInsights.DependencyCollector" version="2.12.0" targetFramework="net472" /> <package id="Microsoft.ApplicationInsights.PerfCounterCollector" version="2.12.0" targetFramework="net472" /> <package id="Microsoft.ApplicationInsights.Web" version="2.12.0" targetFramework="net472" /> <package id="Microsoft.ApplicationInsights.WindowsServer" version="2.12.0" targetFramework="net472" /> <package id="Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel" version="2.12.0" targetFramework="net472" /> <package id="Microsoft.AspNet.TelemetryCorrelation" version="1.0.7" targetFramework="net472" /> <package id="System.Buffers" version="4.4.0" targetFramework="net472" /> <package id="System.Diagnostics.DiagnosticSource" version="4.6.0" targetFramework="net472" /> <package id="System.Memory" version="4.5.3" targetFramework="net472" /> <package id="System.Numerics.Vectors" version="4.4.0" targetFramework="net472" /> <package id="System.Runtime.CompilerServices.Unsafe" version="4.5.2" targetFramework="net472" /> ... </packages>Layout.cshtml
プロジェクトに Layout.cshtml ファイルがある場合は、次のコードが追加されます。
<head> ... <script type = 'text/javascript' > var appInsights=window.appInsights||function(config) { function r(config){ t[config] = function(){ var i = arguments; t.queue.push(function(){ t[config].apply(t, i)})} } var t = { config:config},u=document,e=window,o='script',s=u.createElement(o),i,f;for(s.src=config.url||'//az416426.vo.msecnd.net/scripts/a/ai.0.js',u.getElementsByTagName(o)[0].parentNode.appendChild(s),t.cookie=u.cookie,t.queue=[],i=['Event','Exception','Metric','PageView','Trace','Ajax'];i.length;)r('track'+i.pop());return r('setAuthenticatedUserContext'),r('clearAuthenticatedUserContext'),config.disableExceptionTracking||(i='onerror',r('_'+i),f=e[i],e[i]=function(config, r, u, e, o) { var s = f && f(config, r, u, e, o); return s !== !0 && t['_' + i](config, r, u, e, o),s}),t }({ instrumentationKey:'00000000-0000-0000-0000-000000000000' }); window.appInsights=appInsights; appInsights.trackPageView(); </script> ... </head>ConnectedService.json
{ "ProviderId": "Microsoft.ApplicationInsights.ConnectedService.ConnectedServiceProvider", "Version": "16.0.0.0", "GettingStartedDocument": { "Uri": "https://go.microsoft.com/fwlink/?LinkID=613413" } }FilterConfig.cs
public static void RegisterGlobalFilters(GlobalFilterCollection filters) { filters.Add(new ErrorHandler.AiHandleErrorAttribute());// This line was added }
どうすればテレメトリの関連付けを無効にできますか?
ASP.NET での Application Insights の使用に関する詳細情報はどこで入手できますか?
ASP.NET Core アプリケーション
Application Insights で ASP.NET Core 3.1 はサポートされますか?
Microsoft は ASP.NET Core 3.1 のサポートを終了しました。
Application Insights SDK for ASP.NET Core バージョン 2.8.0 および Visual Studio 2019 以降は、ASP.NET Core 3.1 アプリケーションで使用できます。
自動的に収集されないテレメトリを追跡するにはどうすればよいですか?
コンストラクター インジェクションを使用して TelemetryClient のインスタンスを取得し、そのインスタンスで必須の TrackXXX() メソッドを呼び出します。 ASP.NET Core アプリケーションで新しい TelemetryClient または TelemetryConfiguration のインスタンスを作成することはお勧めしません。
TelemetryClient のシングルトン インスタンスが DependencyInjection コンテナーに既に登録されており、それによって TelemetryConfiguration がテレメトリの残りの部分と共有されます。 新しい TelemetryClient インスタンスは、残りのテレメトリとは別の構成が必要な場合にのみ作成します。
次の例では、コントローラーから追加のテレメトリを追跡する方法を確認できます。
using Microsoft.ApplicationInsights;
public class HomeController : Controller
{
private TelemetryClient telemetry;
// Use constructor injection to get a TelemetryClient instance.
public HomeController(TelemetryClient telemetry)
{
this.telemetry = telemetry;
}
public IActionResult Index()
{
// Call the required TrackXXX method.
this.telemetry.TrackEvent("HomePageRequested");
return View();
}
}
Application Insights でのカスタム データ レポートについては、Application Insights カスタム メトリック API リファレンスに関するページを参照してください。 同様の方法により、GetMetric API を使用して Application Insights にカスタム メトリックを送信することもできます。
テレメトリで要求と応答の本文をキャプチャするにはどうすればよいですか?
ASP.NET Core には、 を介した HTTP 要求/応答情報 (本文を含む) のログ記録のILoggerがあります。 これを活用することをお勧めします。 これにより、テレメトリ内の個人を特定できる情報 (PII) が公開される可能性があり、コスト (パフォーマンス コストと Application Insights の課金) が大幅に増加する可能性があるため、これを使用する前にリスクを慎重に評価してください。
ILogger logs コレクションをカスタマイズする方法
Application Insights の既定の設定では、警告以上の重大度のログのみがキャプチャされます。
Application Insights プロバイダーのログ構成を次のように変更して、情報や軽度のログをキャプチャします。
{
"Logging": {
"LogLevel": {
"Default": "Information"
},
"ApplicationInsights": {
"LogLevel": {
"Default": "Information"
}
}
},
"ApplicationInsights": {
"ConnectionString": "InstrumentationKey=00000000-0000-0000-0000-000000000000"
}
}
次の例では、Application Insights プロバイダーによって Information ログがキャプチャされないことに注意してください。 キャプチャされないのは、ApplicationInsights ログ以上の重大度のログのみをキャプチャするように Warning に指示する既定のログ フィルターが、SDK によって追加されるためです。 Application Insights には明示的なオーバーライドが必要です。
{
"Logging": {
"LogLevel": {
"Default": "Information"
}
}
}
詳細については、ILogger の構成に関する記事を参照してください。
一部の Visual Studio テンプレートでは、Application Insights を有効にする目的で UseApplicationInsights() 拡張メソッドが IWebHostBuilder で使用されていました。 この使用方法は今でも有効ですか?
拡張メソッド UseApplicationInsights() はまだサポートされていますが、Application Insights SDK バージョン 2.8.0 以降では古いものとしてマークされています。 次のメジャー バージョンの SDK で削除されます。 Application Insights のテレメトリを有効にするには、いくつかの構成を制御するためのオーバーロードが用意されているため、AddApplicationInsightsTelemetry() を使用します。 また、ASP.NET Core 3.X アプリでは、services.AddApplicationInsightsTelemetry() が Application Insights を有効にする唯一の方法です。
ASP.NET Core アプリケーションを Web Apps にデプロイしています。 Application Insights 拡張を Web アプリから有効にできますか?
この記事に示されているように、SDK がビルド時にインストールされる場合は、App Service ポータルから Application Insights の拡張機能を有効にする必要はありません。 拡張機能がインストールされている場合、既に SDK が追加されていることが検出されると、バックオフします。 拡張機能から Application Insights を有効にする場合、SDK をインストールして更新する必要はありません。 ただし、この記事の手順に従って Application Insights を有効にする場合は、次のような理由で柔軟性が増します。
- Application Insights テレメトリは以下で引き続き機能します。
- Windows、Linux、Mac を含む、すべてのオペレーティング システム。
- 自己完結型やフレームワーク依存型など、すべての発行モード。
- 完全 .NET Framework を含む、すべてのターゲット フレームワーク。
- Web Apps、VM、Linux、コンテナー、AKS、Azure 以外のホスティングなど、すべてのホスティング オプション。
- プレビュー バージョンを含むすべての .NET Core バージョン。
- Visual Studio からデバッグしているとき、テレメトリをローカル環境で見ることができます。
-
TrackXXX()API を使って、追加のカスタム テレメトリを追跡できます。 - 構成を完全に制御できます。
Azure Monitor Application Insights エージェント (旧名 Status Monitor v2) のようなツールを使用して、Application Insights 監視を有効にできますか?
はい。 Application Insights Agent 2.0.0-beta1 以降では、IIS でホストされている ASP.NET Core アプリケーションがサポートされています。
Linux でアプリケーションを実行する場合、すべての機能がサポートされますか?
はい。 SDK の機能サポートは、次の例外を除き、すべてのプラットフォームで同じです。
- パフォーマンス カウンターは Windows でのみサポートされているため、この SDK を使って Linux 上のイベント カウンターを収集します。 ほとんどのメトリックは同じです。
この SDK はワーカー サービスでサポートされていますか?
いいえ。 ワーカー サービスの場合は、ワーカー サービス アプリケーション (非 HTTP アプリケーション) 向け Application Insights を使用してください。
SDK をアンインストールするにはどうすればよいですか?
Application Insights を削除するには、アプリケーション内の API から NuGet パッケージと参照を削除する必要があります。 NuGet パッケージは、Visual Studio で NuGet パッケージ マネージャーを使ってアンインストールできます。
注
これらの手順は、ASP.NET Core SDK をアンインストールするためのものです。 ASP.NET SDK をアンインストールする必要がある場合は、ASP.NET SDK をアンインストールする方法に関する記事を参照してください。
- NuGet パッケージ マネージャーを使用して、Microsoft.ApplicationInsights.AspNetCore パッケージをアンインストールします。
- Application Insights を完全に削除するには、プロジェクトに追加した API 呼び出しと共に、追加したコードまたはファイルを確認し、それらを手動で削除します。 詳細については、「Application Insights SDK を追加すると作成される内容」を参照してください。
Application Insights SDK を追加すると作成される内容
ご利用のプロジェクトに Application Insights を追加すると、ファイルが作成され、ファイルの一部にコードが追加されます。 NuGet パッケージをアンインストールするだけでは、そのファイルとコードが必ず破棄されるとは限りません。 Application Insights を完全に削除するには、プロジェクトに追加した API 呼び出しと共に、追加したコードまたはファイルを確認し、それらを手動で削除する必要があります。
Visual Studio ASP.NET Core テンプレート プロジェクトに Application Insights Telemetry を追加すると、次のコードが追加されます。
[自分のプロジェクトの名前].csproj
<PropertyGroup> <TargetFramework>netcoreapp3.1</TargetFramework> <ApplicationInsightsResourceId>/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/Default-ApplicationInsights-EastUS/providers/microsoft.insights/components/WebApplication4core</ApplicationInsightsResourceId> </PropertyGroup> <ItemGroup> <PackageReference Include="Microsoft.ApplicationInsights.AspNetCore" Version="2.12.0" /> </ItemGroup> <ItemGroup> <WCFMetadata Include="Connected Services" /> </ItemGroup>Appsettings.json
"ApplicationInsights": { "ConnectionString": "InstrumentationKey=00000000-0000-0000-0000-000000000000" }ConnectedService.json
{ "ProviderId": "Microsoft.ApplicationInsights.ConnectedService.ConnectedServiceProvider", "Version": "16.0.0.0", "GettingStartedDocument": { "Uri": "https://go.microsoft.com/fwlink/?LinkID=798432" } }Startup.cs
public void ConfigureServices(IServiceCollection services) { services.AddRazorPages(); services.AddApplicationInsightsTelemetry(); // This is added }
どうすればテレメトリの関連付けを無効にできますか?
ASP.NET Core アプリケーションでの Application Insights の使用に関する詳細情報はどこで入手できますか?
詳細については、「Application Insights for ASP.NET Core」を参照してください。
ASP.NET パフォーマンス カウンター
例外レートと例外のメトリックの違いは何ですか
-
Exception rate: 例外レートはシステム パフォーマンス カウンターです。 CLR ではスローされた処理済みおよび未処理の例外をすべてカウントし、特定のサンプリング時間間隔での合計をその時間間隔の長さで除算します。 Application Insights SDK では、この結果を収集し、ポータルに送信します。 -
Exceptions: 例外メトリックは、グラフのサンプリング時間間隔中にポータルが受信したTrackExceptionレポートの数をカウントします。 これには、コード内でTrackException呼び出しを記述した処理済みの例外のみが含まれます。 すべての未処理の例外が含まれているわけではありません。
ASP.NET パフォーマンス カウンターに関する詳細情報はどこで入手できますか?
詳細については、「 Application Insights の .NET のカウンター」を参照してください。
ASP.NET イベント カウンター
Live Metrics で EventCounter を表示できますか。
ライブ メトリックで EventCounter は表示されません。 テレメトリを確認するには、メトリック エクスプローラーまたは Analytics を使用してください。
Azure Web アプリ ポータルから Application Insights を有効にした後、イベント カウンターが表示されないのはなぜですか?
この機能は、ASP.NET Core 向けの Application Insights 拡張機能 ではまだサポートされていません。
ASP.NET イベント カウンターに関する詳細情報はどこで入手できますか?
詳細については、「 Application Insights の .NET のカウンター」を参照してください。
Azure VM と仮想マシン スケール セット
ASP.NET Core アプリのクライアント側の監視を無効にする方法
ASP.NET Core アプリの既定では、クライアント側の監視が有効になっています。 無効にする場合は、次の情報を使用してサーバーに環境変数を定義します。
-
名前:
APPINSIGHTS_JAVASCRIPT_ENABLED -
値:
false
Azure VM と仮想マシン スケール セットに Application Insights を使用する方法の詳細については、どこで入手できますか?
詳細については、 Azure VM と仮想マシン スケール セットの Application Insights に関するページを参照してください。
依存関係の追跡
依存関係の自動コレクターが呼び出しの失敗を依存関係に報告する方法は?
依存関係の呼び出しに失敗すると、success フィールドが False に設定されます。 モジュール DependencyTrackingTelemetryModule は ExceptionTelemetry を報告しません。 依存関係の完全なデータ モデルについては、「Application Insights テレメトリ データ モデル」を参照してください。
"依存関係テレメトリのインジェスト待機時間を計算する方法は? "
次のコードを使用します。
dependencies
| extend E2EIngestionLatency = ingestion_time() - timestamp
| extend TimeIngested = ingestion_time()
"依存関係の呼び出しが開始された時刻を判断する方法は? "
Log Analytics のクエリ ビューでは、timestamp は依存関係呼び出しの応答を受信した直後に発生する TrackDependency() 呼び出しが開始された瞬間が表されています。 依存関係の呼び出しが開始された時刻を計算するには、timestamp を取得して、依存関係の呼び出しの記録済み duration を減算します。
Application Insights での依存関係の追跡には、応答本文のログ記録が含まれていますか?
ログ応答本文は、ほとんどのアプリケーションで生成されるテレメトリが多すぎるため、Application Insights での依存関係の追跡に含まれません。
Application Insights の依存関係の追跡に関する詳細情報はどこで入手できますか?
詳細については、「依存関係の 追跡」を参照してください。
可用性テスト
イントラネット サーバー上で可用性テストを実行することはできますか?
可用性テストは、世界中に分布するプレゼンスのポイントで実行されます。 以下に示す 2 つのソリューションがあります。
- ファイアウォール ドア: 頻繁に変更される多数の Web テスト エージェントからサーバーへの要求を許可します。
-
カスタム コード: イントラネット内部からサーバーに定期的な要求を送信する独自のコードを記述します。 Visual Studio Web テストを実行して、このコードをテストすることができます。 テストの結果は
TrackAvailability()API を使用して Application Insights に送信できます。
可用性テストのユーザー エージェント文字列は何ですか?
ユーザー エージェント文字列は、Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0; AppInsights) です
Application Insights 可用性テストに関する詳細情報はどこで入手できますか?
詳細については、「 可用性テスト」を参照してください。
可用性テストの TLS サポート
非推奨は Web テストの動作にどのように影響しますか?
可用性テストは、サポートされている Web テストの場所それぞれにおける分散クライアントとして機能します。 Web テストが実行されるたびに、可用性テスト サービスは、Web テスト構成内で定義されているリモート エンドポイントへのアクセスを試みます。 現在サポートされている TLS 構成すべてを含む TLS クライアント Hello メッセージが送信されます。 リモート エンドポイントが可用性テスト クライアントと共通の TLS 構成を共有している場合、TLS ハンドシェイクが成功します。 それ以外の場合、Web テストは TLS ハンドシェイクの失敗によって失敗します。
リモート エンドポイントでどの TLS 構成がサポートされているかを検証するにはどうすればよいですか?
エンドポイントがどの TLS 構成をサポートしているかをテストするために利用できるツールがいくつか存在します。 1 つの方法は、こちらのページで詳しく説明されている例に従うことです。 リモート エンドポイントがパブリック インターネット経由で利用できない場合は、エンドポイントを呼び出すアクセス権を持つマシンから、リモート エンドポイントでサポートされている TLS 構成を検証するようにする必要があります。
注
Web サーバーで必要な TLS 構成を有効にする手順に関して、プロセスが不明な場合は、Web サーバーが実行されているホスティング プラットフォームを所有するチームに連絡することが適切です。
2025 年 5 月 1 日以降、影響を受けるテストの Web テストの動作はどうなりますか?
この非推奨化の影響を受けるすべての TLS ハンドシェイクの失敗で発生する決まった例外型は存在しません。 しかし、Web テストの失敗で発生することになる最も一般的な例外は The request was aborted: Couldn't create SSL/TLS secure channel となるでしょう。 また、影響を受ける可能性がある Web テスト結果に関する TLS 転送のトラブルシューティング手順でも、TLS 関連のエラーを確認できるはずです。
自分の Web テストで現在どの TLS 構成が使用されているかを表示できますか?
Web テストの実行中にネゴシエートされた TLS 構成を表示することはできません。 リモート エンドポイントが可用性テストで一般的な TLS 構成をサポートしている限り、非推奨化後にどのような影響も発生しないはずです。
非推奨化が影響を与える可用性テスト サービス内のコンポーネントはどれですか?
このドキュメントで詳しく説明されている TLS の非推奨化は、2025 年 5 月 1 日以降の可用性テストの Web テスト実行動作にのみ影響します。 CRUD 操作に関する可用性テスト サービスとのやり取りの詳細については、「Azure Resource Manager TLS サポート」を参照してください。 このリソースは、TLS のサポートと非推奨化のタイムラインの詳細について説明しています。
TLS に関するサポートはどこで受けることができますか?
従来の TLS の問題に関する一般的な質問については、「TLS の問題の解決」を参照してください。
可用性テストの TLS サポートに関する詳細情報はどこで入手できますか?
詳細については、「 サポートされている TLS 構成」を参照してください。
Azure App Service for .NET、Node.js、Python、Java アプリケーションでの監視
Application Insights によってどのような変更がプロジェクトに加えられますか?
詳細は、プロジェクトの種類によって異なります。 次のリストは、Web アプリケーションの例です。
ファイルがプロジェクトに追加されます。
- ApplicationInsights.config
- ai.js
NuGet パッケージがインストールされます。
- Application Insights API: コア API
- Application Insights API for Web Applications: サーバーからテレメトリを送信するために使用されます
- Application Insights API for JavaScript Applications: クライアントからテレメトリを送信するために使用されます
パッケージにアセンブリが追加されます。
- Microsoft.ApplicationInsights
- Microsoft.ApplicationInsights.Platform
次の場所に項目を挿入します。
- Web.config
- packages.config
これらを Application Insights リソース ID で初期化するためのスニペットを、クライアントとサーバーのコードに挿入します。 たとえば、MVC アプリでは、コードをメイン ページの Views/Shared/_Layout.cshtml に挿入します。 新規プロジェクトの場合のみ (既存のプロジェクトには Application Insights を手動で追加します)。
Application Insights の標準メトリックと Azure App Service メトリックの違い
Application Insights では、アプリケーションに対して行われた要求のテレメトリを収集します。 WebApps/WebServer でエラーが発生し、要求がユーザー アプリケーションに到達しなかった場合、それに関するテレメトリは Application Insights に含まれません。
Application Insights によって計算された serverresponsetime の期間は、Web Apps から見たサーバー応答時間とは必ずしも一致しません。 この動作は、Application Insights では、要求がユーザー アプリケーションに実際に到達した場合の期間のみがカウントされるためです。 WebServer で要求の送信が滞った場合やキューに入れられた場合、その待機時間は、Web Apps のメトリックに含まれますが Application Insights のメトリックには含まれません。
Azure App Service for .NET、Node.js、Python、Java アプリケーションでの監視の詳細については、どこで入手できますか?
詳細については、「 Azure App Service でアプリケーションの監視を有効にする」を参照してください。
自動インストルメンテーション
"自動インストルメンテーション (autoinstrumentation)" という用語を、ハイフンで分ける必要はありますか?
Microsoft Learn プラットフォームに公開されている製品ドキュメントについては、Microsoft スタイル ガイドに従っています。
一般に、"auto" プレフィックスの後にハイフンは含まれません。
自動侵入に関する詳細情報はどこで入手できますか?
詳細については、「 Azure Monitor Application Insights の自動侵入とは」を参照してください。
Azure Kubernetes Service の自動侵入
Azure Kubernetes Service (AKS) の自動侵入はカスタム メトリックをサポートしていますか?
Node.jsでカスタム メトリックが必要な場合は、Azure Monitor OpenTelemetry Distro を使用してアプリケーションを手動でインストルメント化します。
Java では、自動インストルメンテーションを通してカスタムメトリックが使用できます。 コードを更新してこの機能を有効にすると、 カスタム メトリックを収集 できます。 コードに既にカスタムメトリクスがある場合、自動インストゥルメンテーションが有効になると、それらがフローします。
AKS 自動インストルメンテーションは、オープンソースソフトウェア (OSS) OpenTelemetry SDK でインストルメント化されたアプリケーションに対して動作しますか？
AKS の自動インストルメンテーションにより、OSS OpenTelemetry SDK によってサードパーティに送信されるテレメトリが妨害される可能性があります。
AKS 自動インストルメンテーションは手動インストルメンテーションと共存できますか?
AKS autoinstrumentation は、Application Insights クラシック API SDK と OpenTelemetry Distro の両方の手動インストルメンテーション オプションと共存するように設計されています。
データの重複が常に防止され、カスタム メトリックが確実に機能します。
自動インストルメンテーションまたは手動インストルメンテーションが優先されるタイミングを判断するには、このグラフを参照してください。
| 言語 | 優先順位 |
|---|---|
| Node.js | 手動インストルメンテーション |
| ジャワ | 自動インストルメンテーション |
Azure Monitor OpenTelemetry Distro の最新かつ最も安全なバージョンを使用していることを確認するにはどうすればよいですか?
Azure Monitor OpenTelemetry Distro で検出された脆弱性は、次のバージョンで優先順位付けされ、修正され、リリースされます。
AKS の自動侵入により、デプロイが変更または再起動されるたびに、最新バージョンの Azure Monitor OpenTelemetry Distro がアプリケーション ポッドに挿入されます。
OpenTelemetry Distro は、長期間変更または再起動されないデプロイに対して脆弱になる可能性があります。 このため、ディストリビューションの最新バージョンが使用されるように、デプロイを毎週更新または再起動することをお勧めします。
Azure Monitor OpenTelemetry Distro の詳細については、どうすればよいですか?
この機能は、Azure Monitor OpenTelemetry Distro をアプリケーション ポッドに挿入することで、自動侵入を実現します。
Java の場合、この機能はスタンドアロンの Azure Monitor OpenTelemetry Distro for Java を統合します。 Java インストルメンテーション バイナリの詳細については、Java ディストリビューションのドキュメントを参照してください。
Node.js の場合は、Azure Monitor OpenTelemetry Distro for Node.js に基づいて自動インストルメンテーション バイナリを挿入します。 詳細については、 ディストリビューションのドキュメントNode.js 参照してください。 Node.js 用のスタンドアロンの自動インストルメンテーションがないため、私たちのディストリビューションのドキュメントは手動によるインストルメンテーションに対応しています。 手動インストルメンテーションに関連するコード ベースの構成手順は無視できます。 ただし、この機能には、既定の設定、環境変数の構成など、ディストリビューション ドキュメント内の他のすべてのものが適用されます。
AKS の自動侵入に関する詳細情報はどこで入手できますか?
詳細については、「AKS の自動インストルメンテーション」を参照してください。
接続文字列
新しい Azure リージョンでは、接続文字列を使用する必要がありますか。
新しい Azure リージョンでは、インストルメンテーション キーの代わりに接続文字列を使用する必要があります。 接続文字列により、テレメトリ データと関連付けるリソースが識別されます。 また、リソースでテレメトリの宛先として使用するエンドポイントを変更することもできます。 接続文字列をコピーし、アプリケーションのコードまたは環境変数に追加してください。
接続文字列またはインストルメンテーション キーを使用する必要はありますか?
インストルメンテーション キーの代わりに、接続文字列を使用することをお勧めします。
環境変数を設定する必要がある場合
システムによって自動的に提供されないすべてのシナリオで、 APPLICATIONINSIGHTS_CONNECTION_STRING を手動で設定します。 これらのシナリオには、ローカル開発と、ASP.NET Core 統合を使用した .NET Isolated Functions が含まれますが、これらに限定されません。 このような場合、環境変数により、OpenTelemetry パイプラインから Application Insights にテレメトリを送信できるようになります。 環境変数を使用して接続文字列を構成する方法の詳細については、「 Application Insights での OpenTelemetry の構成」を参照してください。
リージョンのデータ コンプライアンス要件を満たすためにグローバル Web アプリケーションをインストルメント化する方法
リージョンのデータ コンプライアンス要件を満たすには、グローバル エンドポイントではなく、リージョンの Application Insights エンドポイントを使用します。 グローバル エンドポイントでは、データが特定のリージョン内に留まるようには保証されません。 リージョン エンドポイントは、規制対象地域のユーザーからのテレメトリが、それらのリージョンのデータ センターにのみ送信されるようにするのに役立ちます。
リージョンコンプライアンス用にグローバル Web アプリケーションを構成するには:
- 欧州連合や米国などの厳密なコンプライアンス要件を持つリージョンごとに 1 つの Application Insights リソースを作成します。
- 他のすべてのリージョンのユーザー用に別の Application Insights リソースを作成します。
- 各ユーザーのリージョンに基づいて適切な Application Insights リソースにテレメトリを送信するようにアプリケーションを構成します。 IP アドレス、アカウント メタデータ、場所の設定などのシグナルを使用してリージョンを決定します。
- リージョン間で統一されたクエリ エクスペリエンスが必要な場合は、すべての Application Insights リソースを Log Analytics ワークスペースに接続します。
例えば次が挙げられます。
- リージョン A の接続文字列を使用して、リージョン A ユーザーから Application Insights リソースにデータを送信します。
- リージョン B の接続文字列を使用して、リージョン B ユーザーからリージョン B Application Insights リソースにデータを送信します。
- 他のすべてのユーザー データを、別の接続文字列を使用して汎用 Application Insights リソースに送信します。
Von Bedeutung
グローバル エンドポイントを使用しても、リージョンのコンプライアンスは保証されません。 データ所在地の要件を満たすには、常にリージョン固有のエンドポイントを使用し、ユーザーのリージョンに基づいてテレメトリをルーティングします。
次の図は、グローバル Web アプリケーションのセットアップ例を示しています。
Application Insights の接続文字列に関する詳細情報はどこで入手できますか?
詳細については、接続文字列に関するページを参照してください。
Application Insights リソースの作成と構成
Application Insights リソースを新しいリージョンに移動するにはどうすればよいですか?
リージョン間で既存の Application Insights リソースを転送することはできず、履歴データは新しいリージョンに移行できません。 回避策には次のものが含まれます。
- 目的のリージョンに新しい Application Insights リソースを作成する。
- 元のリソース用の独自カスタマイズを新しいリソースで再作成します。
- 新しいリージョンのリソースの接続文字列を使用してアプリケーションを更新します。
- 新しい Application Insights リソースですべてが期待どおりに動作することを確認するためのテストを実施します。
- 元の Application Insights リソースを保持または削除するのか決定します。 従来のリソースを削除すると、すべての履歴データが失われます。 リソースがワークスペース ベースの場合、データは Log Analytics に残るため、保持期間が切れるまで履歴データにアクセスできます。
新しいリージョンのリソースに対して、通常、手動で再作成または更新する必要がある独自のカスタマイズには、以下のものがありますが、これらに限定されません。
- カスタム ダッシュボードとブックを再作成します。
- カスタム ログまたはメトリック アラートのスコープを再作成または更新します。
- 可用性アラートを再作成します。
- ユーザーが新しいリソースにアクセスするために必要なカスタムの Azure ロールベースのアクセス制御設定を再作成します。
- インジェスト サンプリング、データ保有、日次上限、およびカスタム メトリックの有効化を含む設定をレプリケートします。 これらの設定は、 [使用量と推定コスト] ペインで制御します。
- リリース注釈、ライブ メトリックと安全なコントロール チャネルなど、API キーに依存するすべての統合。 新しい API キーを生成し、関連する統合を更新する必要があります。
- クラシック リソースの連続エクスポートを再構成する必要があります。
- ワークスペースベースのリソースの診断設定を再構成する必要があります。
Azure Resource Manager のデプロイで providers('Microsoft.Insights', 'components').apiVersions[0] を使用できますか?
API バージョンの設定に、この方法を使用することは推奨されません。 最新バージョンは、破壊的変更が含まれる可能性があるプレビュー リリースを表す場合があります。 新しいプレビュー以外のリリースでも、API のバージョンは常に既存のテンプレートと下位互換性があるわけではありません。 場合によっては、API バージョンがすべてのサブスクリプションで使用できないことがあります。
Application Insights リソースの作成と構成に関する詳細情報はどこで入手できますか?
詳細については、「 Application Insights リソースの作成と構成」を参照してください。
テレメトリ データ モデル
データ モデルまたはスキーマの問題と提案を報告するにはどうすればよいですか?
データ モデルまたはスキーマの問題と提案を報告するには、 GitHub リポジトリを使用します。
監視キャンペーンの効果を測定するにはどうすればよいですか?
PageView テレメトリには URL が含まれており、Kusto の正規表現関数を使用して UTM パラメーターを解析できます。
ユーザーまたは企業がブラウザーの設定でユーザー エージェントの送信を無効にした場合、このデータが失われることや不正確になることがあります。 UA パーサーの正規表現に、すべてのデバイス情報が含まれていない場合があります。 また、Application Insights に最新の更新プログラムが適用されていない場合があります。
カスタム測定はエラーなしで成功するのに、ログが表示されないのはなぜですか?
これは、文字列値を使用している場合に発生する可能性があります。 カスタム測定値で機能するのは数値のみです。
テレメトリ データ モデルに関する詳細情報はどこで入手できますか?
詳細については、「Application Insights Telemetry のデータ モデル」をご覧ください。
.NET を使用したログ記録
ILogger ログからはどのような種類の Application Insights テレメトリが生成されますか? Application Insights ではどこで ILogger ログを見ることができますか?
ApplicationInsightsLoggerProvider は、ILogger ログをキャプチャし、それから TraceTelemetry を作成します。
Exception オブジェクトが Logの ILogger メソッドに渡されると、ExceptionTelemetry の代わりに TraceTelemetry が作成されます。
ILogger テレメトリを表示する
Azure portal で次の操作を行います。
- Azure portal に移動し、Application Insights リソースにアクセスします。
- Application Insights 内の [ログ] セクションを選択します。
- Kusto 照会言語 (KQL) を使用して、
tracesテーブルに保存されている ILogger メッセージのクエリを実行します。 クエリの例:traces | where message contains "YourSearchTerm"。 - クエリを絞り込み、重要度、時間範囲、または特定のメッセージ コンテンツによって ILogger データをフィルター処理します。
Visual Studio (ローカル デバッガー):
- Visual Studio 内で、アプリケーションをデバッグ モードで実行します。
- アプリケーションの実行中に [診断ツール] ウィンドウを開きます。
- [イベント] タブには、ILogger ログが他のテレメトリ データと共に表示されます。
- 特定の ILogger メッセージを見つけるには、[診断ツール] ウィンドウの検索とフィルターの機能を使います。
常に TraceTelemetry を送信する場合は、このスニペットを使用します。
builder.AddApplicationInsights(
options => options.TrackExceptionsAsExceptionTelemetry = false);
一部の ILogger ログのプロパティが他と同じではないのはなぜですか?
Application Insights では、他のすべてのテレメトリに使用されるのと同じ ILogger情報を使用して、TelemetryConfiguration ログのキャプチャと送信が行われます。 ただし、例外があります。 既定では、TelemetryConfiguration または Startup.cs からログを記録するとき、 は完全には設定されません。 これらの場所からのログには既定の構成がないため、すべての TelemetryInitializer インスタンスおよび TelemetryProcessor インスタンスは実行されません。
スタンドアロン パッケージ Microsoft.Extensions.Logging.ApplicationInsights を使用しており、カスタム テレメトリをさらに手動でログに記録しようと考えています。 どうすればよいですか?
スタンドアロン パッケージを使用するとき、TelemetryClient は依存関係挿入 (DI) コンテナーに挿入されません。 次のコードに示すように、TelemetryClient の新しいインスタンスを作成し、ロガー プロバイダーが使用しているのと同じ構成を使用する必要があります。 この要件により、カスタム テレメトリと、ILogger のテレメトリのすべてに、同じ構成が使われることが保証されます。
public class MyController : ApiController
{
// This TelemetryClient instance can be used to track additional telemetry through the TrackXXX() API.
private readonly TelemetryClient _telemetryClient;
private readonly ILogger _logger;
public MyController(IOptions<TelemetryConfiguration> options, ILogger<MyController> logger)
{
_telemetryClient = new TelemetryClient(options.Value);
_logger = logger;
}
}
注
Microsoft.ApplicationInsights.AspNetCore パッケージを使用して Application Insights を有効にする場合は、このコードを変更して、コンストラクター内で直接 TelemetryClient を取得します。
SDK をインストールせず、Azure Web Apps 拡張機能を使用して ASP.NET Core アプリケーションの Application Insights を有効にしています。 新しいプロバイダーを使用するにはどうすればよいですか?
Azure Web Apps の Application Insights 拡張機能は、新しいプロバイダーを使用します。 フィルタリング規則は、アプリケーションの appsettings.json ファイルで変更することができます。
.NET を使用したログ記録に関する詳細情報はどこで入手できますか?
詳細については、「 .NET を使用した Application Insights のログ記録」を参照してください。
Java Profiler
Azure Monitor Application Insights の Java プロファイルとは何ですか?
Java Profiler では、Java Flight Recorder (JFR) を使い、カスタマイズされた構成によりアプリケーションがプロファイルされます。
Java Flight Recorder とは何ですか?
Java Flight Recorder (JFR) は、実行中の Java アプリケーションのプロファイル データを収集するためのツールです。 JFR は、Java Virtual Machine (JVM) に統合されており、パフォーマンスの問題のトラブルシューティングに使われます。 Java SE JFR ランタイムの詳細を参照してください。
App Insights の Java プロファイルを有効にする場合、価格やライセンス料金はどうなりますか?
Java プロファイルは Application Insights の無料機能です。 Azure Monitor Application Insights の価格は、インジェストのコストに基づいています。
どの Java プロファイル情報が収集されますか?
JFR によって収集されるプロファイル データには、メソッドと実行のプロファイル データ、ガベージ コレクション データ、ロック プロファイルが含まれます。
App Insights の Java プロファイルを使ってデータを視覚化するにはどうすればよいですか?
JFR の記録は、Java Mission Control (JMC) など、任意のツールで表示および分析できます。
App Insights Java プロファイルに関するパフォーマンス診断と修正の推奨事項は提供されますか?
'パフォーマンス診断と推奨事項' は、Application Insights Java 診断としてまもなく提供される新機能です。 サインアップすると、この機能をプレビューできます。 JFR の記録は、Java Mission Control (JMC) で確認できます。
App Insights のオンデマンドと自動の Java プロファイルの違いは何ですか?
オンデマンドはユーザーがリアルタイムでプロファイルをトリガーするのに対し、自動プロファイルは事前に構成されたトリガーで行われます。
オンデマンド プロファイル オプションには、[今すぐプロファイル] を使います。 [今すぐプロファイル] を選ぶと、Application Insights インスタンスにアタッチされたすべてのエージェントが直ちにプロファイルされます。
自動プロファイルは、リソースのしきい値に到達した場合にトリガーされます。
どの Java プロファイル トリガーを構成できますか?
現在、Application Insights Java Agent は CPU とメモリの消費量の監視をサポートしています。 CPU のしきい値は、マシン上で使用できるすべてのコアの割合として構成されます。 メモリは、リージョンの最大可能サイズに対する Tenured メモリ リージョン (OldGen) の現在の占有率です。
Java プロファイルを有効にするために必要な前提条件は何ですか?
前提条件を確認します。
マイクロサービス アプリケーションに Java プロファイルを使用できますか?
はい、JFR を使ってマイクロサービスを実行している JVM をプロファイルできます。
Java Profiler に関する詳細情報はどこで入手できますか?
詳細については、「 Azure Monitor Application Insights Profiler for Java」を参照してください。
サンプリングオーバーライド - Application Insights for Java
サンプリングオーバーライドを有効にするには、手動インストルメンテーションを使用する必要がありますか?
いいえ。サンプリング オーバーライドは一般公開 (GA) になり、自動侵入と手動インストルメンテーションの両方で使用できます。
自動侵入で Azure App Service を使用する場合、サンプリング オーバーライドを構成するにはどうすればよいですか?
自動計装を使用する場合は、Azure ポータルで applicationinsights.json ファイルを更新します。
サンプリングオーバーライドのために Application Insights エージェント ファイルを手動でアップロードする必要がありますか?
自動計装の場合、エージェントの手動アップロードは必要ありません。 ただし、手動インストルメンテーションの場合でも、Application Insights エージェント JAR ファイルと構成ファイルをデプロイ パッケージに含める必要があります。
手動インストルメンテーションのコンテキストにおける "ローカル開発" と "アプリケーション サーバー" の違いは何ですか?
ローカル開発とは、開発者のマシンや Azure Cloud Shell インスタンスなど、アプリがビルドまたはテストされている環境を指します。 アプリケーション サーバーとは、Azure App Service 環境の Tomcat 11 など、アプリケーションを実行している Web サーバーを指します。 手動インストルメンテーションを使用する場合は、エージェント JAR ファイルがアプリケーション サーバーに正しく配置されていることを確認する必要があります。
Java ランタイム (Tomcat 11 など) で Azure App Service を使用している場合、サンプリング オーバーライドを構成するにはどうすればよいですか?
自動侵入の場合は、Azure portal を使用してサンプリングオーバーライドを構成できます。 手動インストルメンテーションを使用する場合は、Application Insights エージェント JAR を適切なディレクトリに配置し、目的のサンプリング設定に applicationinsights.json ファイルを含める必要があります。
サンプリングオーバーライドに関する詳細情報はどこで入手できますか?
詳細については、「 サンプリングオーバーライド - Azure Monitor Application Insights for Java」を参照してください。
テレメトリ プロセッサ
ログ プロセッサが TelemetryClient.trackTrace() を使用してログ ファイルを処理しないのはなぜですか?
TelemetryClient.trackTrace() は Application Insights Classic SDK ブリッジの一部であり、ログ プロセッサは新しい OpenTelemetry ベースのインストルメンテーションでのみ機能します。
テレメトリ プロセッサに関する詳細情報はどこで入手できますか?
詳細については、「 テレメトリ プロセッサ (プレビュー) - Azure Monitor Application Insights for Java」を参照してください。
JavaScript SDK
ユーザー数とセッション数とは何ですか?
- JavaScript SDK では、Web クライアントにユーザー Cookie を設定することで戻ってきたユーザーを識別し、セッション Cookie を設定することでグループ アクティビティを識別します。
- クライアント側のスクリプトがない場合は、サーバーで Cookie を設定できます。
- 1 人の実在するユーザーが、複数の異なるブラウザーや、プライベート/シークレット ブラウズ、または複数のコンピューターでサイトを利用した場合、それらは複数のユーザーとしてカウントされます。
- 複数のコンピューターやブラウザー間でサインイン済みのユーザーを識別するには、setAuthenticatedUserContext() の呼び出しを追加します。
SDK のパフォーマンスとオーバーヘッドについて教えてください。
Application Insights JavaScript SDK は、Web サイトに対して最小限のオーバーヘッドがかかります。 SDK は、ちょうど 36 KB に gzip 圧縮され、初期化に 15 ミリ秒以下しかかからないため、Web サイトの読み込み時間にほとんど影響はありません。 SDK を使用すると、ライブラリの最小限のコンポーネントがすばやく読み込まれ、完全なスクリプトがバックグラウンドでダウンロードされます。
さらに、スクリプトが CDN からダウンロードされている間は、ページのすべての追跡がキューに登録されるため、ページのライフ サイクル全体でテレメトリは一切失われません。 このセットアップ プロセスでは、ユーザーには見えないシームレスな分析システムを使用してページが提供されます。
JavaScript SDK でサポートされているブラウザーは何ですか?
|
|
|
|
|
|---|---|---|---|---|
| Chrome 最新バージョン ✔ | Firefox 最新バージョン ✔ | v3.x: IE 9+ > Microsoft Edge ✔ v2.x: IE 8以上互換 & マイクロソフト エッジ ✔ |
Opera 最新バージョン ✔ | Safari 最新バージョン ✔ |
JavaScript SDK のコードの例はどこで確認できますか?
実行できる例については、Application Insights JavaScript SDK サンプルを参照してください。
JavaScript SDK と ES3/Internet Explorer 8 の互換性について教えてください。
古いブラウザーで読み込まれたときに、この SDK が引き続き "動作" し、JavaScript の実行が中断されないように、必要な手段を講じる必要があります。 古いブラウザーをサポートしないことが理想的ですが、多くの大規模なお客様は、ユーザーが使用するブラウザーを制御できません。
このように述べることは、最も一般的ではない機能セットだけをサポートすることを意味するわけではありません。 ES3 コードの互換性を維持する必要があります。 ES3 JavaScript の解析を中断させない方法で、オプション機能として、新しい機能を追加する必要があります。
Internet Explorer 8 のサポートについて詳しくは、GitHub をご覧ください。
JavaScript SDK はオープンソースですか?
はい。Application Insights JavaScript SDK はオープンソースです。 ソース コードを見たり、プロジェクトに参加したりするには、GitHub の公式リポジトリをご覧ください。
JavaScript SDK に関する詳細情報はどこで入手できますか?
詳細については、「 Azure Monitor Application Insights Real User Monitoring を有効にする」を参照してください。
JavaScript SDK の構成
JavaScript SDK 向けにサード パーティ製サーバー構成を更新するにはどうすればよいですか?
サーバー側は、これらのヘッダーが存在する接続を受け入れる必要があります。 サーバー側の Access-Control-Allow-Headers の構成によっては、Request-Id、Request-Context、traceparent (W3C 分散ヘッダー) を手動で追加してサーバー側のリストを拡張することが必要になることがよくあります。
Access-Control-Allow-Headers: Request-Id、 traceparent、 Request-Context、 <your header>
JavaScript SDK の分散トレースを無効にするにはどうすればよいですか?
分散トレースは、構成で無効にすることができます。
HTTP 502 および 503 の応答は、常に Application Insights によってキャプチャされますか?
いいえ。 "502 無効なゲートウェイです" というエラーと "503 サービスを利用できません" というエラーは、Application Insights によって常にキャプチャされるわけではありません。 監視にクライアント側の JavaScript のみが使用されている場合、この動作が予想されます。これは、HTML ヘッダーと監視 JavaScript スニペットを含むページがレンダリングされる前にエラー応答が返されるためです。
サーバー側の監視が有効になっているサーバーから 502 または 503 の応答が送信された場合、Application Insights SDK によってエラーが収集されます。
アプリケーションの Web サーバーでサーバー側の監視が有効になっていても、Application Insights によって 502 または 503 エラーがキャプチャされない場合があります。 最新の Web サーバーの多くは、クライアントが直接通信することを許可しません。 代わりに、リバース プロキシなどのソリューションを使用して、クライアントとフロントエンド Web サーバーの間で情報がやり取りされます。
このシナリオでは、502 または 503 の応答がクライアントに返される場合がありますが、リバース プロキシ レイヤーでの問題が原因で、Application Insights によってすぐにはキャプチャされません。 このレイヤーで問題を検出するために必要なことは、リバース プロキシから Log Analytics にログを転送すること、および 502 または 503 の応答を確認するカスタム ルールを作成することです。 502 エラーと 503 エラーの一般的な原因について詳しくは、「Azure App Service での HTTP エラー "502 無効なゲートウェイ" と "503 サービス利用不可" のトラブルシューティング」を参照してください。
JavaScript SDK の構成に関する詳細情報はどこで入手できますか?
詳細については、「 Application Insights JavaScript SDK の構成」を参照してください。
JavaScript フレームワーク拡張機能
Application Insights では、ブラウザー、OS、言語、モデルなどのデバイス情報はどのように生成されますか?
ブラウザーによって、要求の HTTP ヘッダーにユーザー エージェント文字列が渡されます。 Application Insights インジェスト サービスでは、UA パーサーを使用して、データ テーブルとエクスペリエンスに表示されるフィールドが生成されます。 その結果、Application Insights ユーザーはこれらのフィールドを変更できなくなります。
ユーザーまたは企業がブラウザーの設定でユーザー エージェントの送信を無効にした場合、このデータが失われることや不正確になることがあります。 UA パーサーの正規表現に、すべてのデバイス情報が含まれていない場合があります。 また、Application Insights に最新の更新プログラムが適用されていない場合があります。
JavaScript フレームワーク拡張機能に関する詳細情報はどこで入手できますか?
詳細については、「 Application Insights JavaScript SDK のフレームワーク拡張機能を有効にする」を参照してください。
マネージド ワークスペース
クラシック リソースを参照するスクリプトまたは自動化を更新する必要がありますか?
いいえ。 既存の ARM テンプレートと API 呼び出しは引き続き機能します。 クラシック リソースを作成しようとすると、代わりにマネージド ワークスペースを持つワークスペース ベースのリソースが作成されます。
リソースが移行される前に通知されますか?
いいえ。 個々のリソース移行についての通知は提供されていません。 リソースを移行するタイミングと方法を制御するには、 手動移行を使用します。
移行プロセスにはどのくらいの時間がかかりますか?
通常、個々の移行は 2 分以内に完了します。 完全なロールアウトは、すべてのリージョンで数週間にわたって行われます。
リソースが移行されたかどうかを確認するにはどうすればよいですか?
移行後、リソースは [概要] ページの Log Analytics ワークスペースにリンクされます。 クラシック引退のお知らせが削除され、引退ワークブックにリソースが一覧表示されなくなります。
移行後に課金は変更されますか?
通常、コストは変わりません。 ワークスペースベースの Application Insights を使用すると、コスト削減機能が有効になり、 価格プランを確認することをお勧めします。
従来の課金モデルを使用している場合は、 価格に関するドキュメント で詳細を確認してください。
移行中にアラートや可用性テストが失われますか?
いいえ。 すべてのアラート、ダッシュボード、および可用性テストはそのまま残り、移行後も引き続き機能します。
マネージド ワークスペースに関する詳細情報はどこで入手できますか?
詳細については、「 Application Insights のマネージド ワークスペース」を参照してください。
Node.js
どうすればテレメトリの関連付けを無効にできますか?
テレメトリの関連付けを無効にするには、構成内で correlationHeaderExcludedDomains プロパティを使用します。 詳細については、「ApplicationInsights-node.js」を参照してください。
目的のログ レベルを構成するにはどうすればよいですか?
Application Insights で使用する目的のログ レベルを構成するには、 APPLICATIONINSIGHTS_INSTRUMENTATION_LOGGING_LEVEL 環境変数を使用します。
サポートされている値は NONE、ERROR、WARN、INFO、DEBUG、VERBOSE、ALL です。
詳細については、「ApplicationInsights-node.js」を参照してください。
Application Insights を使用した Node.js サービスとアプリの監視に関する詳細情報はどこで入手できますか?
詳細については、「 Application Insights を使用して Node.js サービスとアプリを監視する」を参照してください。
Azure Monitor OpenTelemetry (アジュール モニター オープンテレメトリー)
Application Insights SDK のバージョンとその名前の一覧はどこにありますか?
SDK のバージョンと名前の一覧は、GitHub でホストされています。 詳細については、「SDK バージョン」を参照してください。
OpenTelemetry に関する詳細情報はどこで入手できますか?
詳細については、「 Application Insights で OpenTelemetry を使用してテレメトリを収集する」を参照してください。
.NET Application Insights SDK から Azure Monitor OpenTelemetry に移行する
SDK API は OpenTelemetry の概念にどのようにマップされますか?
OpenTelemetry は、ベンダーに依存しない可観測性フレームワークです。 OpenTelemetry SDK またはライブラリに Application Insights API はありません。 移行する前に、OpenTelemetry の概念をいくつか理解しておくことが重要です。
Application Insights では、すべてのテレメトリは 1 つの
TelemetryClientとTelemetryConfigurationで管理されていました。 OpenTelemetry では、3 つのテレメトリ信号 (トレース、メトリック、ログ) のそれぞれに独自の構成があります。 外部ライブラリを使用せずに、.NET ランタイムを使用してテレメトリを手動で作成できます。 詳細については、分散トレース、メトリック、およびログに関する .NET ガイドを参照してください。Application Insights は
TelemetryModulesを使用して、アプリケーションのテレメトリを自動的に収集しました。 代わりに、OpenTelemetry では、インストルメンテーション ライブラリを使用して、特定のコンポーネント (要求に対する AspNetCore や依存関係に対する httpClient など) からテレメトリを収集します。Application Insights は
TelemetryInitializersを使用して、テレメトリを追加情報で強化したり、プロパティをオーバーライドしたりします。 OpenTelemetry を使用すると、プロセッサ を記述して、特定のシグナルをカスタマイズできます。 さらに、多くの OpenTelemetry インストルメンテーション ライブラリには、その特定のコンポーネントによって生成されるテレメトリをカスタマイズするためのEnrichメソッドが用意されています。Application Insights は、テレメトリをフィルター処理するために
TelemetryProcessorsを使用します。 OpenTelemetry プロセッサ を使用して、特定のシグナルにフィルター処理ルールを適用することもできます。
Application Insights テレメトリの種類を OpenTelemetry にマップする方法
次の表は、Application Insights データ型を OpenTelemetry の概念とその .NET 実装にマップします。
| Azure Monitor テーブル | Application Insights データタイプ | OpenTelemetry データタイプ | .NET の実装 |
|---|---|---|---|
| カスタムイベント | EventTelemetry | なし | なし |
| カスタムメトリクス | MetricTelemetry | メトリック | System.Diagnostics.Metrics.Meter |
| 依存関係 | DependencyTelemetry | スパン (クライアント、内部、コンシューマー) | System.Diagnostics.Activity (システム診断.活動) |
| 例外 | ExceptionTelemetry | 例外 | System.Exception |
| リクエスト | RequestTelemetry | スパン (サーバー、プロデューサー) | System.Diagnostics.Activity (システム診断.活動) |
| トレース | TraceTelemetry | ログ | Microsoft.Extensions.Logging.ILogger |
| トレース | TraceTelemetry | Span イベント | System.Diagnostics.ActivityEvent |
詳細については、次のドキュメントを参照してください。
Application Insights サンプリングの概念を OpenTelemetry にマップする方法
Application Insights にはサンプリングを構成するための複数のオプションが用意されていますが、Azure Monitor Exporter または Azure Monitor Distro では固定レート サンプリングのみが提供されます。 要求と依存関係 (OpenTelemetry トレース) のみをサンプリングできます。
サンプリングを構成する方法の詳細なコード サンプルについては、サンプリングを有効にするガイドを参照してください
テレメトリ プロセッサと初期化子を OpenTelemetry にマップする方法
Application Insights .NET SDK で、テレメトリ プロセッサを使用してテレメトリをフィルター処理および変更または破棄します。 テレメトリ初期化子を使用して、カスタム プロパティを追加または変更します。 詳細については、Azure Monitor のドキュメントを参照してください。 OpenTelemetry は、これらの概念をアクティビティ プロセッサまたはログ プロセッサに置き換え、テレメトリを強化およびフィルター処理します。
トレースのフィルター処理
OpenTelemetry でテレメトリ データをフィルター処理するには、アクティビティ プロセッサを実装します。 この例は、Azure Monitor のドキュメントで説明されているテレメトリ データのフィルタリングに関する Application Insights の例と同等です。 この例では、失敗した依存関係の呼び出しがフィルター処理される場所を示します。
using System.Diagnostics;
using OpenTelemetry;
internal sealed class SuccessfulDependencyFilterProcessor : BaseProcessor<Activity>
{
public override void OnEnd(Activity activity)
{
if (!OKtoSend(activity))
{
activity.ActivityTraceFlags &= ~ActivityTraceFlags.Recorded;
}
}
private bool OKtoSend(Activity activity)
{
return activity.Kind == ActivityKind.Client && activity.Status == ActivityStatusCode.Ok;
}
}
このプロセッサを使用するには、TracerProvider より先に AddAzureMonitorTraceExporter を作成し、プロセッサを追加する必要があります。
using OpenTelemetry.Trace;
public static void Main()
{
var tracerProvider = Sdk.CreateTracerProviderBuilder()
.AddProcessor(new SuccessfulDependencyFilterProcessor())
.AddAzureMonitorTraceExporter()
.Build();
}
ログのフィルタリング
ILogger の実装には、ログのフィルタリングを適用するための組み込みメカニズムがあります。 このフィルタリングにより、OpenTelemetryLoggerProvider などの、各登録済みプロバイダーに送信されるログを制御できます。 "OpenTelemetry" は、フィルター処理規則の構成に使用される、 のOpenTelemetryLoggerProviderです。
次の例では、既定の LogLevel として "Error" を定義し、ユーザー定義カテゴリの最小 LogLevel として "警告" を定義します。 定義されているこれらの規則は、OpenTelemetryLoggerProvider にのみ適用されます。
builder.AddFilter<OpenTelemetryLoggerProvider>("*", LogLevel.Error);
builder.AddFilter<OpenTelemetryLoggerProvider>("MyProduct.MyLibrary.MyClass", LogLevel.Warning);
詳細については、ログに関する OpenTelemetry .NET ドキュメントを参照してください。
トレースへのカスタム プロパティの追加
OpenTelemetry では、アクティビティ プロセッサを使用して、テレメトリ データにより多くのプロパティを追加し、内容を充実させることができます。 これは、Application Insights におけるテレメトリ初期化子の使用に類似しており、そこでもテレメトリのプロパティを修正することができます。
既定では、Azure Monitor エクスポーターは応答コードが 400 以上の HTTP 要求を失敗として扱います。 ただし、400 を成功として扱いたい場合は、アクティビティを成功と設定し、さらにテレメトリ プロパティを追加するタグを付与するエンリッチメント アクティビティ プロセッサを追加できます。 これは、Azure Monitor のドキュメントで説明されている Application Insights の初期化子を使用したプロパティの追加や変更と類似しています。
カスタム プロパティを追加し、特定の応答コードの既定の動作をオーバーライドする方法の例を次に示します。
using System.Diagnostics;
using OpenTelemetry;
/// <summary>
/// Custom Processor that overrides the default behavior of treating response codes >= 400 as failed requests.
/// </summary>
internal class MyEnrichingProcessor : BaseProcessor<Activity>
{
public override void OnEnd(Activity activity)
{
if (activity.Kind == ActivityKind.Server)
{
int responseCode = GetResponseCode(activity);
if (responseCode >= 400 && responseCode < 500)
{
// If we set the Success property, the SDK won't change it
activity.SetStatus(ActivityStatusCode.Ok);
// Allow to filter these requests in the portal
activity.SetTag("Overridden400s", "true");
}
// else leave the SDK to set the Success property
}
}
private int GetResponseCode(Activity activity)
{
foreach (ref readonly var tag in activity.EnumerateTagObjects())
{
if (tag.Key == "http.response.status_code" && tag.Value is int value)
{
return value;
}
}
return 0;
}
}
このプロセッサを使用するには、TracerProvider より先に AddAzureMonitorTraceExporter を作成し、プロセッサを追加する必要があります。
using OpenTelemetry.Trace;
public static void Main()
{
var tracerProvider = Sdk.CreateTracerProviderBuilder()
.AddSource("Company.Product.Name")
.AddProcessor(new MyEnrichingProcessor())
.AddAzureMonitorTraceExporter()
.Build();
}
OpenTelemetry を使用してテレメトリを手動で追跡する方法
トレースの送信 - 手動
Application Insights のトレースは、RequestTelemetry および DependencyTelemetry として格納されます。 OpenTelemetry では、トレースは Span クラスを使用して Activity としてモデル化されます。
OpenTelemetry .NET は、.NET ランタイムの一部であるトレースに ActivitySource クラスと Activity クラスを利用します。 このアプローチが特徴的なのは、.NET 実装においてトレース API がランタイム自体に直接組み込まれていることです。
System.Diagnostics.DiagnosticSource パッケージを使用すると、開発者は ActivitySource を使用して Activity インスタンスを作成および管理できます。 このメソッドは、外部ライブラリに依存せずに .NET アプリケーションにトレースを追加し、.NET エコシステムの組み込み機能を適用するシームレスな方法を提供します。 詳細については、分散トレース インストルメンテーションのチュートリアルを参照してください。
手動トレースを移行する方法を次に示します。
注
Application Insights では、ロール名とロール インスタンスをテレメトリごとのレベルで設定できます。 ただし、Azure Monitor Exporter では、テレメトリごとのレベルではカスタマイズできません。 ロール名とロール インスタンスは OpenTelemetry リソースから抽出され、すべてのテレメトリに適用されます。 詳細については、クラウド ロール名とクラウド ロール インスタンスの設定に関するドキュメントを参照してください。
DependencyTelemetry
Application Insights DependencyTelemetry は、送信要求をモデル化するために使用されます。 OpenTelemetry に変換する方法は次のとおりです。
Application Insights の例:
DependencyTelemetry dep = new DependencyTelemetry
{
Name = "DependencyName",
Data = "https://www.example.com/",
Type = "Http",
Target = "www.example.com",
Duration = TimeSpan.FromSeconds(10),
ResultCode = "500",
Success = false
};
dep.Context.Cloud.RoleName = "MyRole";
dep.Context.Cloud.RoleInstance = "MyRoleInstance";
dep.Properties["customprop1"] = "custom value1";
client.TrackDependency(dep);
OpenTelemetry の例:
var activitySource = new ActivitySource("Company.Product.Name");
var resourceAttributes = new Dictionary<string, object>
{
{ "service.name", "MyRole" },
{ "service.instance.id", "MyRoleInstance" }
};
var resourceBuilder = ResourceBuilder.CreateDefault().AddAttributes(resourceAttributes);
using var tracerProvider = Sdk.CreateTracerProviderBuilder()
.SetResourceBuilder(resourceBuilder)
.AddSource(activitySource.Name)
.AddAzureMonitorTraceExporter()
.Build();
// Emit traces
using (var activity = activitySource.StartActivity("DependencyName", ActivityKind.Client))
{
activity?.SetTag("url.full", "https://www.example.com/");
activity?.SetTag("server.address", "www.example.com");
activity?.SetTag("http.request.method", "GET");
activity?.SetTag("http.response.status_code", "500");
activity?.SetTag("customprop1", "custom value1");
activity?.SetStatus(ActivityStatusCode.Error);
activity?.SetEndTime(activity.StartTimeUtc.AddSeconds(10));
}
RequestTelemetry
Application Insights RequestTelemetry は、受信要求をモデル化します。 OpenTelemetry に移行する方法は次のとおりです。
Application Insights の例:
RequestTelemetry req = new RequestTelemetry
{
Name = "RequestName",
Url = new Uri("http://example.com"),
Duration = TimeSpan.FromSeconds(10),
ResponseCode = "200",
Success = true,
Properties = { ["customprop1"] = "custom value1" }
};
req.Context.Cloud.RoleName = "MyRole";
req.Context.Cloud.RoleInstance = "MyRoleInstance";
client.TrackRequest(req);
OpenTelemetry の例:
var activitySource = new ActivitySource("Company.Product.Name");
var resourceAttributes = new Dictionary<string, object>
{
{ "service.name", "MyRole" },
{ "service.instance.id", "MyRoleInstance" }
};
var resourceBuilder = ResourceBuilder.CreateDefault().AddAttributes(resourceAttributes);
using var tracerProvider = Sdk.CreateTracerProviderBuilder()
.SetResourceBuilder(resourceBuilder)
.AddSource(activitySource.Name)
.AddAzureMonitorTraceExporter()
.Build();
// Emit traces
using (var activity = activitySource.StartActivity("RequestName", ActivityKind.Server))
{
activity?.SetTag("url.scheme", "https");
activity?.SetTag("server.address", "www.example.com");
activity?.SetTag("url.path", "/");
activity?.SetTag("http.response.status_code", "200");
activity?.SetTag("customprop1", "custom value1");
activity?.SetStatus(ActivityStatusCode.Ok);
}
カスタム操作の追跡
Application Insights で、StartOperation メソッドと StopOperation メソッドを使用してカスタム操作を追跡します。 OpenTelemetry .NET で ActivitySource と Activity を使用してこれを実現します。
ActivityKind.Server と ActivityKind.Consumer を使用した操作の場合、Azure Monitor Exporter によって RequestTelemetry が生成されます。
ActivityKind.Client、ActivityKind.Producer、および ActivityKind.Internal の場合、DependencyTelemetry が生成されます。 カスタム操作の追跡の詳細については、Azure Monitor のドキュメントを参照してください。 .NET で ActivitySource と Activity を使用する方法の詳細については、.NET 分散トレース インストルメンテーションのチュートリアルを参照してください。
カスタム操作のアクティビティを開始および停止する方法の例を次に示します。
using System.Diagnostics;
using OpenTelemetry;
var activitySource = new ActivitySource("Company.Product.Name");
using var tracerProvider = Sdk.CreateTracerProviderBuilder()
.AddSource(activitySource.Name)
.AddAzureMonitorTraceExporter()
.Build();
// Start a new activity
using (var activity = activitySource.StartActivity("CustomOperation", ActivityKind.Server))
{
activity?.SetTag("customTag", "customValue");
// Perform your custom operation logic here
// No need to explicitly call Activity.Stop() because the using block automatically disposes the Activity object, which stops it.
}
ログの送信
Application Insights のログは、TraceTelemetry および ExceptionTelemetry として格納されます。
TraceTelemetry
OpenTelemetry では、ILogger インターフェイスを介してログ記録が統合されます。
TraceTelemetry を移行する方法は次のとおりです。
Application Insights の例:
TraceTelemetry traceTelemetry = new TraceTelemetry
{
Message = "hello from tomato 2.99",
SeverityLevel = SeverityLevel.Warning,
};
traceTelemetry.Context.Cloud.RoleName = "MyRole";
traceTelemetry.Context.Cloud.RoleInstance = "MyRoleInstance";
client.TrackTrace(traceTelemetry);
OpenTelemetry の例:
var resourceAttributes = new Dictionary<string, object>
{
{ "service.name", "MyRole" },
{ "service.instance.id", "MyRoleInstance" }
};
var resourceBuilder = ResourceBuilder.CreateDefault().AddAttributes(resourceAttributes);
using var loggerFactory = LoggerFactory.Create(builder => builder
.AddOpenTelemetry(logging =>
{
logging.SetResourceBuilder(resourceBuilder);
logging.AddAzureMonitorLogExporter();
}));
// Create a new instance `ILogger` from the above LoggerFactory
var logger = loggerFactory.CreateLogger<Program>();
// Emit log: This uses the logger instance to write a new log
logger.FoodPrice("tomato", 2.99);
internal static partial class LoggerExtensions
{
[LoggerMessage(LogLevel.Warning, "Hello from `{name}` `{price}`.")]
public static partial void FoodPrice(this ILogger logger, string name, double price);
}
ExceptionTelemetry
Application Insights では、例外をログに記録するために ExceptionTelemetry が使用されます。 OpenTelemetry に移行する方法は次のとおりです。
Application Insights の例:
ExceptionTelemetry exceptionTelemetry = new ExceptionTelemetry(new Exception("Test exception"))
{
SeverityLevel = SeverityLevel.Error
};
exceptionTelemetry.Context.Cloud.RoleName = "MyRole";
exceptionTelemetry.Context.Cloud.RoleInstance = "MyRoleInstance";
exceptionTelemetry.Properties["customprop1"] = "custom value1";
client.TrackException(exceptionTelemetry);
OpenTelemetry の例:
var resourceAttributes = new Dictionary<string, object>
{
{ "service.name", "MyRole" },
{ "service.instance.id", "MyRoleInstance" }
};
var resourceBuilder = ResourceBuilder.CreateDefault().AddAttributes(resourceAttributes);
using var loggerFactory = LoggerFactory.Create(builder => builder
.AddOpenTelemetry(logging =>
{
logging.SetResourceBuilder(resourceBuilder);
logging.AddAzureMonitorLogExporter();
}));
// Create a new instance `ILogger` from the above LoggerFactory.
var logger = loggerFactory.CreateLogger<Program>();
try
{
// Simulate exception
throw new Exception("Test exception");
}
catch (Exception ex)
{
// Emit exception: This uses the logger instance to write a new exception
logger?.LogError(ex, "An error occurred");
}
メトリックの送信
Application Insights のメトリックは、MetricTelemetry として格納されます。 OpenTelemetry では、メトリックは Meter パッケージから System.Diagnostics.DiagnosticSource としてモデル化されます。
Application Insights には、事前集計 (TrackMetric()) 以外と事前集計 (GetMetric().TrackValue()) メトリック API の両方があります。 OpenTelemetry とは異なり、Application Insights には Instruments の概念はありません。 Application Insights には、すべてのメトリック シナリオで同じ API があります。
一方、OpenTelemetry では、ユーザーはまずメトリックの実際の意味に基づいて適切なメトリック インストルメントを選択する必要があります。 たとえば、何か (受信したサーバー要求の合計数など) をカウントする場合、OpenTelemetry Counter を使用する必要があります。 さまざまなパーセンタイル (サーバー待機時間の P99 値など) を計算する場合は、OpenTelemetry ヒストグラム インストルメントを使用する必要があります。 Application Insights と OpenTelemetry の基本的な違いにより、それらの間で直接的な比較は行われません。
Application Insights とは異なり、OpenTelemetry には、メトリックを強化またはフィルター処理するための組み込みのメカニズムは用意されていません。 Application Insights では、テレメトリ プロセッサと初期化子を使用してメトリックを変更または破棄できますが、この機能は OpenTelemetry では使用できません。
さらに、OpenTelemetry では、Application Insights の TrackMetric() 機能と同等の機能がないため、直接生のメトリックを送信することはできません。
Application Insights から OpenTelemetry への移行には、すべての Application Insights メトリック API の使用状況を OpenTelemetry API に置き換える必要があります。 さまざまな OpenTelemetry Instruments とそのセマンティクスを理解する必要があります。
ヒント
ヒストグラムは最も汎用性が高く、Application Insights GetMetric().TrackValue() API と最も近いものです。 Application Insights メトリック API をヒストグラムに置き換えて、同じ目的を達成できます。
その他のテレメトリの種類
カスタムイベント
OpenTelemetry ではサポートされていません。
Application Insights の例:
TelemetryClient.TrackEvent()
AvailabilityTelemetry
OpenTelemetry ではサポートされていません。
Application Insights の例:
TelemetryClient.TrackAvailability()
PageViewTelemetry
OpenTelemetry ではサポートされていません。
Application Insights の例:
TelemetryClient.TrackPageView()
コンソールおよびワーカー サービス アプリケーションのライブ メトリックを取得できますか?
ライブ メトリックを含まないコンソールおよびワーカー サービス アプリケーションには、Azure Monitor OpenTelemetry Exporter をお勧めします。
.NET Application Insights SDK から OpenTelemetry への移行に関する詳細情報はどこで入手できますか?
詳細については、「 .NET Application Insights SDK から Azure Monitor OpenTelemetry への移行」を参照してください。
OpenTelemetry サンプリング
Application Insights カスタム サンプラーは tail-based ですか?
Application Insights カスタム サンプラーは、スパン作成の事前ではなく作成後にサンプリングの決定を行うため、従来のヘッドベースのアプローチには従いません。 代わりに、スパンの生成が終了した時点でサンプリングの決定が行われ、スパンが完了した後、エクスポートの前に適用されます。
この動作はいくつかの点で末尾ベースのサンプリングに似ていますが、サンプラーは決定する前に、同じトレースから複数のスパンを収集するのを待機しません。 代わりに、トレース ID のハッシュを使用して、トレースの完全性を確保します。
このアプローチでは、トレースの完全性と効率がバランスを取り、完全なテールベースのサンプリングに関連するコストが高くなるのを回避します。
トレース全体の結果に基づいてサンプリングを決定するには (たとえば、トレース内のスパンが失敗したかどうかを判断する)、ダウンストリーム エージェントまたはコレクターで完全な末尾ベースのサンプリングが必要です。 この機能は現在サポートされていませんが、 フィードバック ハブから新機能として要求できます。
Application Insights カスタム サンプラーは、OpenTelemetry ヘッドベースまたはテールベースのサンプリングとどのように比較されますか?
| サンプリング メソッド | 決定のポイント | 長所 | 弱点 |
|---|---|---|---|
| ヘッドベース | スパンが開始される前 | 待機時間が短く、オーバーヘッドが最小限 | 必要なトレース (エラーを含む) をサンプリングできます |
| Tail-based | 時間またはボリュームのしきい値に基づいてスパンをバッファー処理した後 | 高度に選択的なトレース サンプリング基準を許可する | コストの増加と処理遅延の追加 |
| App Insights カスタム サンプラー | スパン生成の終了 | トレースの完全性と効率性のバランスを取ります | ライブ メトリックとクラシック API の互換性に必要 |
依存関係、要求、またはその他のテレメトリの種類をさまざまなレートでサンプリングできますか?
いいえ。サンプラーは、トレース内のすべてのテレメトリの種類に固定レートを適用します。 要求、依存関係、およびその他のスパンは、同じサンプリング率に従います。 テレメトリの種類ごとに異なるレートを適用するには、OpenTelemetry スパン プロセッサまたは (インジェスト時間変換)[opentelemetry-overview.md#telemetry-routing] の使用を検討してください。
Application Insights カスタム サンプラーはサンプリングの決定をどのように伝達しますか?
Application Insights カスタム サンプラーは、既定で W3C トレース コンテキスト標準を使用してサンプリングの決定を伝達します。 この標準により、サンプリングの決定をサービス間で流すことができます。 ただし、サンプラーは、ダウンストリーム サービスの呼び出し後にスパン生成の終了時にサンプリングの決定を行うため、伝達には不完全なサンプリング情報が含まれます。 この制限は W3C トレース コンテキスト仕様に準拠していますが、ダウンストリーム サービスでは、この伝達されたサンプリング決定を確実に使用できません。
Application Insights カスタム サンプラーは、アップストリーム サービスからのサンプリング決定を尊重していますか?
いいえ。アップストリーム サービスが同じサンプリング アルゴリズムを使用している場合でも、Application Insights カスタム サンプラーは常に独立したサンプリング決定を行います。 W3C トレース コンテキスト ヘッダーを使用するサービスを含むアップストリーム サービスからのサンプリング決定は、ダウンストリーム サービスの決定に影響しません。 ただし、トレースの完全性を確保するために、トレース ID のハッシュに基づいてサンプルを実行します。 整合性を向上させ、トレースが破損する可能性を減らすには、同じサンプラーとサンプリング レートを使用するようにシステム内のすべてのコンポーネントを構成します。
Application Insights カスタム サンプラーを使用している場合でも、一部のトレースが不完全に表示されるのはなぜですか。
トレースが不完全に表示される理由はいくつかあります。
- 分散システム内のノードによって、決定を調整しないさまざまなサンプリング アプローチが使用されます。 たとえば、1 つのノードが OpenTelemetry ヘッド ベースのサンプリングを適用し、別のノードが Azure Monitor カスタム サンプラーを介してサンプリングを適用します。
- ノードが同じサンプリング アプローチを使用している場合でも、異なるノードが異なるサンプリング レートに設定されます。
- サービス側パイプラインでフィルター処理、サンプリング、またはレート キャップを設定すると、トレースの完全性を考慮せずに、この構成によってスパンがランダムにサンプリングされます。
1 つのコンポーネントが (W3C トレース コンテキスト ヘッダーを介して) サンプリングの決定を伝達せずにヘッド ベースのサンプリングを適用する場合、ダウンストリーム サービスはトレースを個別にサンプリングし、その結果、スパンが破棄される可能性があります。 その結果、トレースの一部は、Application Insights で表示されるときに常に使用できるわけではありません。
OpenTelemetry サンプリングに関する詳細情報はどこで入手できますか?
詳細については、「 OpenTelemetry を使用した Azure Monitor Application Insights でのサンプリング」を参照してください。
OpenTelemetry のサポートとフィードバック
OpenTelemetry とは何ですか?
これは、可観測性のためのオープンソース標準です。 詳細については、「OpenTelemetry」を参照してください。
Microsoft Azure Monitor が OpenTelemetry に投資しているのはなぜですか?
Microsoft は次の理由から OpenTelemetry への投資を行っています。
- ベンダーに依存せず、複数の言語にわたって一貫した API/SDK を提供する。
- 時間の経過とともに、Microsoft は、OpenTelemetry によって、Azure Monitor のお客様がサポートされている言語以外の言語で記述されたアプリケーションを監視できるようになると考えるようになりました。
- インストルメンテーション ライブラリのリッチなセットを通じて、利用者が収集できるデータの種類を拡大する。
- OpenTelemetry ソフトウェア開発キット (SDK) は、先行製品である Application Insights SDK よりも大部分で良いパフォーマンスを示す傾向がある。
- OpenTelemetry はオープンソースを推進するという Microsoft の戦略に沿うものである。
OpenTelemetry はどのような状況ですか?
OpenTelemetry の状態を参照してください。
Azure Monitor OpenTelemetry Distro とは
これは、Azure で最上級のエクスペリエンスが得られるように、すべての OpenTelemetry コンポーネントをバンドルするシン ラッパーと考えることができます。 このラッパーは、OpenTelemetry のディストリビューションとも呼ばれます。
Azure Monitor OpenTelemetry Distro を使用する必要がある理由
コミュニティのネイティブ OpenTelemetry よりも Azure Monitor OpenTelemetry Distro を使用することには、いくつかの利点があります。
- 有効化作業を減らす
- Microsoft によってサポートされている
- 次のような Azure 固有の機能が導入されます。
- 従来の Application Insights SDK と互換性のあるサンプリング
- Microsoft Entra 認証
- オフライン ストレージと自動再試行
- Statsbeat
- Application Insights 標準メトリック
- さまざまな Azure 環境でクラウド ロール名とクラウド ロール インスタンスを自動入力するためのリソース メタデータを検出する
- ライブ メトリック
OpenTelemetry の精神に基づいて、ディストリビューションはオープンで拡張できるように設計されています。 たとえば、次のようなものを追加できます。
- OpenTelemetry Protocol (OTLP) エクスポーターと 2 番目の宛先に同時に送信する
- ディストリビューションに含まれていない他のインストルメンテーション ライブラリ
このディストリビューションは OpenTelemetry ディストリビューションを提供しているため、このディストリビューションは OpenTelemetry でサポートされているものすべてをサポートしています。 たとえば、OpenTelemetry でサポートされている場合は、テレメトリ プロセッサ、エクスポーター、インストルメンテーション ライブラリをさらに追加できます。
注
このディストリビューションは、サンプラーを Application Insights のカスタムの固定レート サンプラーに設定します。 これを別のサンプラーに変更できますが、変更した場合、このディストリビューションに含まれる機能の一部が無効になる可能性があります。 サポートされているサンプラーの詳細については、「Azure Monitor OpenTelemetry を構成する」の「サンプリングの有効化」セクションを参照してください。
サポートされているスタンドアロンの OpenTelemetry エクスポーターがない言語の場合、Azure Monitor OpenTelemetry Distro が、Azure Monitor で OpenTelemetry を使用するための現在サポートされている唯一の方法です。 スタンドアロンの OpenTelemetry エクスポーターがサポートされている言語では、テレメトリ シナリオに応じて、Azure Monitor OpenTelemetry Distro または適切なスタンドアロンの OpenTelemetry エクスポーターのいずれかを使用できます。 詳細については、「どのようなときに Azure Monitor OpenTelemetry エクスポーターを使う必要がありますか?」を参照してください。
Azure Monitor OpenTelemetry Distro をテストするにはどうすればよいですか?
.NET、Java、JavaScript (Node.js)、Python に関する Microsoft 提供のドキュメントを確認してください。
OpenTelemetry または Application Insights SDK を使用する必要がありますか?
新しいプロジェクトの 機能 が監視ニーズに合っている場合は、Azure Monitor OpenTelemetry Distro を使用することをお勧めします。 OpenTelemetry は、クロスプラットフォームの可観測性を強化し、テレメトリ収集に標準化されたアプローチを提供する業界標準のフレームワークです。
ただし、Application Insights SDK には、OpenTelemetry でまだ完全に自動化されていない次のような特定の機能が引き続き用意されています。
- 依存関係の自動追跡 – OpenTelemetry では依存関係の追跡がサポートされていますが、Application Insights SDK で使用できる自動追跡と比較して追加の構成が必要な依存関係もあります。
-
AvailabilityTelemetryやPageViewTelemetryなどのカスタム テレメトリの種類 - OpenTelemetry には直接的な同等物はありません。 同様の機能は、手動インストルメンテーションを使用して実装できます。 - テレメトリ プロセッサと初期化子 – OpenTelemetry にはプロセッサとスパン プロセッサがありますが、すべてのシナリオで Application Insights テレメトリ プロセッサと初期化子を完全に置き換えるわけではありません。
- 拡張メトリック収集 – OpenTelemetry には強力なメトリック システムが用意されていますが、Application Insights SDK の組み込みメトリックの中には、OpenTelemetry での手動セットアップが必要なものもあります。
OpenTelemetry には、Application Insights SDK よりも次のような利点もあります。
- プラットフォーム間の標準化の向上
- インストルメンテーション ライブラリの広範なエコシステム
- データ収集と処理の柔軟性の向上
- Azure Monitor OpenTelemetry Distro は引き続き Azure 用に最適化されていますが、ベンダーの中立性が向上しました。
Azure Monitor の OpenTelemetry 統合は継続的に進化しており、Microsoft はその機能を引き続き強化しています。 移行を検討している場合は、OpenTelemetry が現在観測性の要件を満たしているかどうか、または Application Insights SDK がニーズに適しているかどうかを慎重に評価します。
どのようなときに Azure Monitor OpenTelemetry エクスポーターを使う必要がありますか?
ASP.NET Core、Java、Node.js、Python では、Azure Monitor OpenTelemetry Distro の使用をお勧めします。 1 行のコードで始められます。
他のすべての .NET シナリオ (従来の ASP.NET、コンソール アプリ、Windows フォーム (WinForms) など) では、.NET Azure Monitor OpenTelemetry エクスポーター (Azure.Monitor.OpenTelemetry.Exporter) の使用をお勧めします。
高度な構成を必要とするより複雑な Python テレメトリ シナリオでは、Python Azure Monitor OpenTelemetry エクスポーターの使用をお勧めします。
Azure Monitor OpenTelemetry Distro 内の機能は、現在どのようなリリース状態ですか?
次のグラフは、各言語に対する OpenTelemetry 機能のサポートを示しています。
| 特徴 | 。網 | Node.js | Python（プログラミング言語） | ジャワ |
|---|---|---|---|---|
| 分散トレース | ✅ | ✅ | ✅ | ✅ |
| カスタム メトリック | ✅ | ✅ | ✅ | ✅ |
| 標準メトリック | ✅ | ✅ | ✅ | ✅ |
| 固定レート サンプリング | ✅ | ✅ | ✅ | ✅ |
| オフライン ストレージと自動再試行 | ✅ | ✅ | ✅ | ✅ |
| 例外のレポート | ✅ | ✅ | ✅ | ✅ |
| ログの収集 | ✅ | ⚠️ | ✅ | ✅ |
| [カスタム イベント] | ⚠️ | ⚠️ | ⚠️ | ✅ |
| Microsoft Entra 認証 | ✅ | ✅ | ✅ | ✅ |
| ライブ メトリック | ✅ | ✅ | ✅ | ✅ |
| Live Metrics のフィルター処理 | ✅ | ❌ | ❌ | ❌ |
| VM/VMSS と App Service のリソース コンテキストを検出する | ✅ | ❌ | ✅ | ✅ |
| Azure Kubernetes Service (AKS) と関数のリソース コンテキストを検出する | ❌ | ❌ | ❌ | ✅ |
| Track Availability API を使って生成された可用性テスト イベント | ❌ | ❌ | ❌ | ✅ |
| 匿名ユーザー ID と合成ソースによる要求、依存関係、ログ、例外のフィルター処理 | ❌ | ❌ | ❌ | ✅ |
| 操作名による依存関係、ログ、例外のフィルター処理 | ❌ | ❌ | ❌ | ✅ |
| アダプティブ サンプリング | ❌ | ❌ | ❌ | ✅ |
| .NET Profiler | ⚠️ | ❌ | ❌ | ⚠️ |
| スナップショット デバッガー | ❌ | ❌ | ❌ | ❌ |
鍵
- ✅ この機能は、正式なサポートを受けるすべてのお客様が利用できます。
- ⚠️ この機能は、パブリック プレビューとして利用できます。 「Microsoft Azure プレビューの追加利用規約」を参照してください。
- ❌ この機能は利用できないか、適用されません。
OpenTelemetry は Web ブラウザーで使用できますか?
はい。ただし、お勧めしません。また、Azure ではサポートされていません。 OpenTelemetry JavaScript は、Node.js 用に非常に最適化されています。 代わりに、Application Insights JavaScript SDK を使用することをお勧めします。
Web ブラウザーで OpenTelemetry SDK を使用できるようになるのはいつですか?
OpenTelemetry Web SDK が利用可能になるタイムラインはまだ決定されていません。 Application Insights JavaScript SDK の有効な代替手段となるブラウザー SDK が登場するのは、おそらく数年先です。
現在、Web ブラウザーで OpenTelemetry をテストできますか?
OpenTelemetry Web Sandbox は、ブラウザーで OpenTelemetry を動作させるために設計されたフォークです。 Application Insights にテレメトリを送信することはまだできません。 この SDK では、一般的なクライアント イベントは定義されていません。
AppDynamics、DataDog、NewRelic などの競合エージェントと共に Application Insights を実行することはサポートされていますか?
このような実行をテストまたはサポートする予定はありませんが、Distro では、Azure Monitor と共に同時に OTLP エンドポイントにエクスポートできます。
運用環境でプレビュー機能を使用できますか?
それは推奨されません。 「Microsoft Azure プレビューの追加利用規約」を参照してください。
手動インストルメンテーションと自動インストルメンテーションの違いは何ですか?
「OpenTelemetry の概要」を参照してください。
OpenTelemetry Collector を使用できますか?
Microsoft がアプリケーション監視のためのエージェントベースのアプローチをまだ正式にサポートしていないにもかかわらず、一部のお客様は、エージェントの代替として OpenTelemetry-Collector を使い始めています。 その間、オープンソース コミュニティは OpenTelemetry-Collector Azure Monitor エクスポーターを提供してきました。一部のお客様は、これを使ってデータを Azure Monitor Application Insights に送信しています。 これは、Microsoft ではサポートされません。
OpenCensus と OpenTelemetry の違いは何ですか?
OpenCensus は OpenTelemetry の前段階です。 Microsoft は、OpenTracing と OpenCensus を統合して、世界の単一の監視標準である OpenTelemetry の作成を支援しました。 Azure Monitor 用に現在の運用環境で推奨されている Python SDK は、OpenCensus に基づいています。 Microsoft は、Azure Monitor を OpenTelemetry に基づくものにすることに取り組んでいます。
Grafana では、なぜ "Status 500. トレース ビジュアライザーを使用してトレース イベントを視覚化できない
OpenTelemetry トレースでなく、生のテキスト ログを視覚化しようとしている可能性があります。
Application Insights の "トレース" テーブルには、診断目的で生のテキスト ログが格納されます。 ユーザー要求、その他のイベント、および例外レポートに関連付けられているトレースを識別して関連付けるのに役立ちます。 ただし、"トレース" テーブルは、Grafana などの視覚化ツールのエンドツーエンドのトランザクション ビュー (ウォーターフォール チャート) に直接提供されるわけではありません。
クラウドネイティブの実践の導入が拡大するにつれて、テレメトリの収集と用語は進化しています。 OpenTelemetry は、テレメトリ データの収集とインストルメント化の標準となりました。 このコンテキストでは、"トレース" という用語は新しい意味を持ちます。 OpenTelemetry の "トレース" は、生のログではなく、個々の作業単位を表すスパンを含む、より豊富で構造化された形式のテレメトリを意味します。 これらの範囲の拡大は、詳細なトランザクション ビューを構築し、クラウドネイティブ アプリケーションの監視と診断を向上するうえで重要です。
Blazor Apps はどのようにインストルメント化すればよいですか?
Blazor アプリをインストルメント化するには、まずホスティング モデルを特定します。 Blazor Server では、 OpenTelemetry ベースのフル インストルメンテーションがサポートされています。 Blazor WebAssembly はブラウザーで実行され、JavaScript による制限付きインストルメンテーションをサポートします。
OpenTelemetry のサポートとフィードバックに関する詳細情報はどこで入手できますか?
詳細については、「 Application Insights の OpenTelemetry サポートとフィードバック」を参照してください。
概要ダッシュボード
30 日を超えるデータを表示できますか?
いいえ、現在、ダッシュボードに表示されるデータは 30 日分という上限があります。
ダッシュボードに "リソースが見つかりません" というエラーが表示されます。
Application Insights インスタンスを移動または名前変更すると、"リソースが見つかりません" というエラーが発生する場合があります。
この動作を回避するには、既定のダッシュボードを削除し、もう一度 [アプリケーション ダッシュボード] を選択して新しいダッシュボードを再作成してください。
概要ダッシュボードに関する詳細情報はどこで入手できますか?
詳細については、「Application Insights の概要ダッシュボード」をご覧ください。
テレメトリ チャネル
Application Insights のチャネルでは、テレメトリの配信が保証されるのでしょうか? そうでない場合には、テレメトリが失われる可能性があるシナリオはどのようなものでしょうか?
簡潔に言うと、組み込みチャネルのいずれにおいても、バックエンドへのテレメトリ配信に関して、トランザクションのような保証はありません。
ServerTelemetryChannel は配信の信頼性という点で InMemoryChannel よりも優れていますが、こちらもテレメトリの送信はベストエフォートにすぎません。 次のような一般的なシナリオを含め、いくつかの状況ではテレメトリが失われることがあります。
- アプリケーションがクラッシュすると、メモリ内の項目が失われます。
- ネットワークの問題が長期間に及んだ場合には、テレメトリが失われます。 ネットワークの停止中や Application Insights バックエンドでの問題発生時には、テレメトリがローカル ディスクに保存されます。 ただし、48 時間が経過した項目は破棄されます。
- Windows でテレメトリが保存される既定のディスクの場所は、%LOCALAPPDATA% または %TEMP% です。 これらは通常、マシンのローカルの場所です。 アプリケーションがある場所から別の場所に物理的に移行した場合、元の場所に保存されているテレメトリが失われます。
- Windows 上の Azure Web Apps では、既定のディスク ストレージの場所は D:\local\LocalAppData です。 この場所は、永続的なものではありません。 アプリの再起動やスケールアウトなどの操作によりワイプされるので、そこに保存されているテレメトリが失われます。 既定値をオーバーライドして、ストレージに D:\home のような永続的な場所を指定することもできます。 ただし、このような永続的な場所はリモート ストレージによって提供されるので、速度が遅いことがあります。
あまりないことですが、チャネルによってテレメトリ項目が重複する可能性があります。 この動作は、ServerTelemetryChannel がネットワーク障害またはタイムアウトによる再試行、テレメトリがバックエンドに配信されたものの、ネットワークの問題が原因で応答が失われた場合、またはタイムアウトが発生した場合に発生します。
ServerTelemetryChannel は Windows 以外のシステムでも動作しますか?
このチャネルは、パッケージと名前空間の名前に "WindowsServer" という文言が含まれてこそいるものの、次の例外を除き、Windows 以外のシステムでもサポートされます。 Windows 以外のシステムでは、チャネルにより既定でローカル ストレージ フォルダーが作成されることはありません。 ローカル ストレージ フォルダーをご自身で作成したうえで、それを使用するようにチャネルを構成する必要があります。 ローカル ストレージの構成が済んだ後は、チャネルがすべてのシステムで同じように動作します。
注
リリース 2.15.0-beta3 以降、ローカル ストレージは Linux、Mac、Windows で自動的に作成されるようになりました。 Windows 以外のシステムの場合、次のロジックに基づいてローカル ストレージ フォルダーが自動的に作成されます。
-
${TMPDIR}:${TMPDIR}環境変数が設定されている場合、この場所が使用されます。 -
/var/tmp: 前述の場所が存在しない場合は、/var/tmpを試します。 -
/tmp: 前述のどちらの場所も存在しない場合は、tmpを試します。 - これらの場所のいずれも存在しない場合、ローカル ストレージは作成されません。以前と同様に、手動による構成が必要になります。 実装の詳細については、 この GitHub リポジトリを参照してください。
SDK では一時的なローカル ストレージが作成されますか? データはストレージで暗号化されますか?
ネットワークの問題の発生中またはスロットリング中は、SDK によりテレメトリの項目がローカル ストレージに保存されます。 このデータがローカルで暗号化されることはありません。
Windows システムの場合、SDK により自動で %TEMP% または %LOCALAPPDATA% ディレクトリに一時的なローカル フォルダーが作成され、アクセスが管理者と現在のユーザーのみに制限されます。
Windows 以外のシステムの場合、SDK によりローカル ストレージが自動で作成されることはないので、既定ではデータがローカルに保存されません。
注
リリース 2.15.0-beta3 以降、ローカル ストレージは Linux、Mac、Windows で自動的に作成されるようになりました。
ストレージ ディレクトリを作成し、それを使用するようにチャネルを構成できます。 この場合、そのディレクトリのセキュリティ保護については、ご自身の責任となります。 詳細については、 データ保護とプライバシーに関するページを参照してください。
テレメトリ チャネルに関する詳細情報はどこで入手できますか?
詳細については、「 Application Insights のテレメトリ チャネル」を参照してください。
トランザクション検索
保持されるデータの量はどのくらいですか
「制限の概要」を参照してください。
サーバーの要求の POST データを表示するにはどうしたらよいですか
POST データは自動的に記録されませんが、TrackTrace または log の呼び出しを使用できます。 メッセージ パラメーターに POST データを格納します。 プロパティと同じ方法でメッセージをフィルター処理することはできませんが、サイズの制限が緩和されます。
Azure 関数検索で結果が返されないのはなぜですか?
Azure Functions は URL クエリ文字列をログしません。
トランザクション検索に関する詳細情報はどこで入手できますか?
詳細については、「 トランザクション検索と診断」を参照してください。
トランザクション診断
グラフ上に 1 つのコンポーネントが表示され、他のコンポーネントは詳細がない外部依存関係としてのみ表示されるのはなぜですか?
次の理由が考えられます。
- その他のコンポーネントは Application Insights を使用してインストルメント化されましたか。
- それらには Application Insights SDK の最新の安定バージョンが使用されていますか。
- これらのコンポーネントが個別の Application Insights リソースである場合、アクセス権を持っていることを確認します。 アクセス権を持っていて、コンポーネントが最新の Application Insights SDK でインストルメント化されている場合は、右上隅にあるフィードバック チャネルからお知らせください。
依存関係の行が重複しています。 これは期待される動作ですか。
現時点では、送信依存関係呼び出しと受信要求は区別して表示されます。 通常、2 つの呼び出しは、ネットワーク ラウンド トリップのために継続時間の値が異なる以外は、まったく同一に見えます。 先頭のアイコンと継続時間バーの個別のスタイルは、これらを区別するのに役立ちます。 このデータの表示方法はわかりにくいですか。 フィードバックをお待ちしております。
異なるコンポーネント インスタンス間のクロック スキューはどのように処理されますか?
タイムラインは、トランザクションチャートにおけるクロックスキューを考慮して調整されます。 詳細ウィンドウか、または Log Analytics を使用することで、正確なタイムスタンプを確認できます。
関連項目のクエリのほとんどが、新しいエクスペリエンスからなくなっているのはなぜですか?
この動作は設計によるものです。 すべての関連項目は、コンポーネント全体に渡って、上部と下部のセクションの左側で既に使用できます。 新しいエクスペリエンスの左側で扱われない関連項目が 2 つあります。このイベントの 5 分前後からのすべてのテレメトリと、ユーザー タイムラインです。
Application Insights JavaScript SDK を使うときに、トランザクションあたりのイベントが少ないものを表示する方法はありますか?
トランザクション診断エクスペリエンスでは、同じ操作 ID を共有する単一操作のすべてのテレメトリが表示されます。 既定では、Application Insights SDK for JavaScript は、一意のページ ビューごとに新しい操作を作成します。 シングルページ アプリケーション (SPA) では、1 つのページ ビュー イベントのみが生成され、生成されるすべてのテレメトリに対して 1 つの操作 ID が使われます。 その結果、多くのイベントが同じ操作に関連付けられる可能性があります。
このようなシナリオでは、自動ルート追跡を使用すると、SPA でのナビゲーションのために新しい操作が自動的に作成されます。
enableAutoRouteTracking を有効にして、URL ルートが更新されるたびにページ ビューが生成される (論理ページ ビューが発生する) ようにする必要があります。 操作 ID を手動で更新する場合は appInsights.properties.context.telemetryTrace.traceID = Microsoft.ApplicationInsights.Telemetry.Util.generateW3CId() を呼び出します。 手動で PageView イベントをトリガーすると、操作 ID もリセットされます。
トランザクションの詳細時間が上位要求期間に加算されないのはなぜですか。
ガント チャートで説明されていない時間は、追跡される依存関係の対象ではない時間です。 この問題は、外部呼び出しが自動または手動でインストルメント化されていない場合に発生する可能性があります。 また、外部呼び出しのためではなく、処理中にかかった時間が原因で発生することもあります。
すべての呼び出しがインストゥルメント化される場合、時間が費やされる根本原因はおそらくプロセスにあります。 プロセスの診断に役立つツールは .NET Profiler です。
Azure portal で Application Insights を移動中に "データの取得中にエラーが発生しました" というメッセージが表示された場合はどうしますか?
このエラーは、ブラウザーから必要な API を呼び出すことができなかったか、API から失敗応答が返されたことを示します。 この動作をトラブルシューティングするには、ブラウザーの InPrivate ウィンドウを開き、実行されているブラウザーの拡張機能があれば無効にしても、このポータル動作を再現できるかどうかを確認します。 それでもポータル エラーが発生する場合は、他のブラウザーまたは他のマシンでテストを行い、API 呼び出しに失敗しているクライアント コンピューターから DNS や他のネットワーク関連の問題を調査します。 ポータル エラーが続き、さらなる調査が必要な場合は、予期しないポータルの動作を再現しながらブラウザー ネットワーク トレースを収集し、Azure portal からサポート ケースを開きます。
トランザクション診断に関する詳細情報はどこで入手できますか?
詳細については、「 トランザクション検索と診断」を参照してください。
使用状況分析
最初のイベントは、イベントがセッションに初めて表示されるか、またはセッションに出現するたびに表されますか?
視覚化の最初のイベントは、ユーザーがセッションの間にそのページ ビューまたはカスタム イベントを初めて送信した時のみを表します。 ユーザーがセッション内で最初のイベントを何回も送信できる場合、"Step 1" 列は、最初のイベントのすべてのインスタンスではなく、最初のイベントの "最初の" インスタンスの後でユーザーが行ったことだけを示します。
視覚化の一部のノードの階層が高すぎます。 ノードをより詳しく見るにはどうしたらよいですか
[編集] メニューの [次で分割] オプションを使用します。
[イベント] メニューで、分割するイベントを選択します。
[ディメンション] メニューでディメンションを選択します。 たとえば、[Button Clicked](ボタンがクリックされました) というイベントがある場合は、[Button Name](ボタン名) というカスタム プロパティを試してください。
特定の国や地域からのユーザーのコーホートを定義しました。 ユーザー ツールでこのコーホートを、その国や地域に対してフィルターを設定しただけの場合と比較した場合、なぜ異なる結果が表示されるのですか?
コーホートとフィルターは異なります。 英国からのユーザーのコーホートが存在し (前の例のように定義された)、その結果を Country or region = United Kingdom というフィルターを設定した場合と比較するとします。
コーホートの結果には、現在の時間の範囲において英国から 1 つ以上のイベントを送信したユーザーのすべてのイベントが表示されます。 国または地域で分割した場合は、多くの国や地域が表示される可能性が高くなります。
フィルターの結果には、英国からのイベントのみが表示されます。 国または地域で分割した場合は、英国だけ表示されます。
データをさまざまな期間粒度 (日次、月次、週次) で表示する方法
[日付の粒度] フィルターを選択して、粒度を変更できます。 フィルターは、すべてのディメンション タブで使用できます。
![ブックで [日付の粒度] を日次、月次、週次に変更するフィルターを示すスクリーンショット。](media/application-insights-faq/faq-date-grain-monthly.png#lightbox)
HEART ブックでは利用できないアプリケーションからの分析情報を使用するにはどうすればよいですか。
ビジュアルがすべての質問に答えない場合は、HEART ワークブックの元となるデータを詳しく調べることができます。 このタスクを実行するには、Application Insights の [監視 ] セクションで [ ログ] を選択し、 customEvents テーブルに対してクエリを実行します。 Click Analytics 属性の一部は、customDimensions フィールドに含まれています。
クエリの例を次に示します。
customEvents
| where isnotnull(customDimensions.actionType)
| extend parentid=tostring(customDimensions.parenId),
pagename=tostring(customDimensions.pageName),
actiontype=tostring(customDimensions.actionType)
| project actiontype,parentid,pagename,
user_AuthenticatedId,user_Id,session_Id,itemType,timestamp
Azure Monitor のログの詳細については、「Azure Monitor ログの概要」を参照してください。
ワークブックのビジュアルを編集できますか。
はい。 ブック テンプレートを編集する方法については、「 Azure ブック テンプレート」を参照してください。
利用状況分析に関する詳細情報はどこで入手できますか?
詳細については、「 Application Insights を使用した使用状況分析」を参照してください。
Worker Service アプリケーション
どのパッケージを使えばよいのですか?
| .NET Core アプリのシナリオ | パッケージ |
|---|---|
| HostedServices を使わずに | WorkerService |
| HostedServices を使用する | AspNetCore (WorkerService ではない) |
| HostedServices では、HostedServices のみを監視します | WorkerService (まれなシナリオ) |
AspNetCore パッケージを使用する .NET Core アプリ内の HostedServices に TelemetryClient を挿入できますか?
はい。構成は、Web アプリケーションの残りの部分と共有されます。
自動的に収集されないテレメトリを追跡するにはどうすればよいですか?
コンストラクター インジェクションを使用して TelemetryClient のインスタンスを取得し、そのインスタンスで必須の TrackXXX() メソッドを呼び出します。 新しい TelemetryClient インスタンスを作成することはお勧めできません。
TelemetryClient のシングルトン インスタンスが DependencyInjection コンテナーに既に登録されており、それによって TelemetryConfiguration がテレメトリの残りの部分と共有されます。 新しい TelemetryClient インスタンスの作成は、残りのテレメトリとは別の構成が必要な場合にのみ推奨されます。
Visual Studio IDE を使用して、ワーカー サービス プロジェクトに Application Insights をオンボードすることはできますか?
現在、Visual Studio IDE のオンボードは ASP.NET/ASP.NET Core アプリケーションでのみサポートされています。 このドキュメントは、Visual Studio のリリースでワーカー サービス アプリケーションのオンボードがサポートされるようになったときに更新されます。
Azure Monitor Application Insights エージェント (旧名 Status Monitor v2) のようなツールを使用して、Application Insights 監視を有効にできますか?
いいえ。 Azure Monitor Application Insights エージェントでは現在、.NET のみがサポートされています。
Linux でアプリケーションを実行する場合、すべての機能がサポートされますか?
はい。 この SDK の機能サポートは、次の例外を除き、すべてのプラットフォームで同じです。
パフォーマンス カウンターは、Windows でのみサポートされます。ただし、Live Metrics に表示されるプロセス CPU/メモリは例外です。
ServerTelemetryChannelが既定で有効になっていても、アプリケーションが Linux または macOS で実行されているときは、ネットワークに問題がある場合に、チャネルによってテレメトリを一時的に保持するためのローカル ストレージ フォルダーが自動的に作成されることはありません。 この制限のため、ネットワークやサーバーに一時的に問題が発生すると、テレメトリが失われます。 この問題を回避するには、チャネル用のローカル フォルダーを構成します。using Microsoft.ApplicationInsights.Channel; using Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel; public void ConfigureServices(IServiceCollection services) { // The following will configure the channel to use the given folder to temporarily // store telemetry items during network or Application Insights server issues. // User should ensure that the given folder already exists // and that the application has read/write permissions. services.AddSingleton(typeof(ITelemetryChannel), new ServerTelemetryChannel () {StorageFolder = "/tmp/myfolder"}); services.AddApplicationInsightsTelemetryWorkerService(); }
Worker Service アプリケーションに関する詳細情報はどこで入手できますか?
詳細については、「 Application Insights for Worker Service アプリケーション (HTTP 以外のアプリケーション)」を参照してください。