Application Insights のテレメトリチャネル

2025-06-23

テレメトリチャネルは、 Application Insights SDK の不可欠な部分です。これにより、テレメトリのバッファリングと Application Insights サービスへの送信が管理されます。この SDK の .NET と .NET Core のバージョンには、InMemoryChannel と ServerTelemetryChannel の 2 つのテレメトリチャネルが組み込まれています。この記事では、各チャネルについて説明し、チャネルの動作をカスタマイズする方法を示します。

注意

Azure Monitor Application Insights を活用するために、新しいアプリケーションや顧客には Azure Monitor OpenTelemetry Distro をお勧めします。 Azure Monitor OpenTelemetry Distro では、Application Insights SDK と同様の機能とエクスペリエンスが提供されます。 .NET、 Node.js、Python の移行ガイドを使用して Application Insights SDK から移行することは可能ですが、下位互換性のためにさらにいくつかの機能を追加する作業を行っています。

テレメトリチャネルとは

テレメトリチャネルの役割は、テレメトリ項目をバッファリングして、Application Insights サービスに送信することです。それらはそこでクエリと解析のために保存されます。テレメトリチャネルは、Microsoft.ApplicationInsights.ITelemetryChannel インターフェイスを実装している任意のクラスです。

テレメトリチャネルの Send(ITelemetry item) メソッドは、テレメトリ初期化子とテレメトリプロセッサがすべて呼び出された後に呼び出されます。つまり、テレメトリプロセッサによって削除された項目はチャネルに到達しません。通常、Send() メソッドが項目をバックエンドにすぐに送信することはありません。通常は、効率的な伝送のため、メモリ内でバッファリングされてから、バッチ単位で送信されます。

バッファーに格納されたテレメトリをすぐに送信することが重要でない限り、 Flush() の呼び出しは避けてください。アプリケーションのシャットダウン、例外処理、バックグラウンドジョブやコマンドラインツールなどの有効期間の短いプロセスを使用する場合にのみ使用します。 Web アプリケーションまたは実行時間の長いサービスでは、SDK はテレメトリ送信を自動的に処理します。 Flush()を不必要に呼び出すと、パフォーマンスの問題が発生する可能性があります。

Live Metrics Stream には、テレメトリのライブストリーミングを利用するカスタムチャネルもあります。このチャネルは通常のテレメトリチャネルから独立しており、このドキュメントはそれには当てはまりません。

組み込みのテレメトリチャネル

Application Insights の .NET と .NET Core の SDK には、2 つの組み込みチャネルが付属しています。

InMemoryChannel: 送信されるまで項目をメモリ内にバッファリングする軽量のチャネル。項目はメモリ内にバッファリングされ、30 秒ごと、または 500 項目がバッファリングされるごとに、1 回フラッシュされます。このチャネルは、障害の後にテレメトリの送信を再試行しないので、保証される信頼性は最小限です。また、このチャネルでは項目はディスク上に保持されません。そのため、アプリケーションのシャットダウン時には、正常かどうかに関係なく、未送信の項目は完全に失われます。このチャネルには、メモリ内のすべてのテレメトリ項目を同期的に強制フラッシュできる Flush() メソッドが実装されています。このチャネルは、同期的にフラッシュすることが理想的な実行時間の短いアプリケーションに適しています。

このチャネルはさらに大きな Microsoft.ApplicationInsights NuGet パッケージの一部であり、他に何も構成されていないときに SDK が使用する既定のチャネルです。
ServerTelemetryChannel: 再試行ポリシーとローカルディスクへのデータ保存機能を備えた、より高度なチャネル。このチャネルでは、一時的なエラーが発生すると、テレメトリの送信が再試行されます。また、このチャネルは、ネットワークの停止時またはテレメトリの量が多いときに、ローカルディスクストレージを使ってディスク上に項目を保持します。このような再試行メカニズムとローカルディスクストレージを備えているため、このチャネルは信頼性が高いと考えられます。すべての運用シナリオにはこれをお勧めします。このチャネルは、公式ドキュメントに従って構成された ASP.NET および ASP.NET Core アプリケーションの既定値です。このチャネルは、実行時間の長いプロセスがあるサーバーのシナリオに最適化されています。このチャネルによって実装される Flush() メソッドは同期的ではありません。

このチャネルは、Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel NuGet パッケージとして提供されるものであり、Microsoft.ApplicationInsights.Web または Microsoft.ApplicationInsights.AspNetCore NuGet パッケージを使用している場合には自動的に取得されます。

テレメトリチャネルを構成する

テレメトリチャネルを構成するには、それをアクティブなテレメトリ構成に設定します。 ASP.NET アプリケーションの構成では、テレメトリチャネルインスタンスを TelemetryConfiguration.Active に設定するか、ApplicationInsights.config を変更します。 ASP.NET Core アプリケーションの構成では、依存関係挿入コンテナーにチャネルを追加します。

以降のセクションでは、さまざまなアプリケーションの種類でチャネルの StorageFolder 設定を構成する例を示します。 StorageFolder は構成可能な設定の 1 つに過ぎません。構成設定の完全な一覧については、この記事の後半の「チャネルの構成可能な設定」セクションを参照してください。

ApplicationInsights.config を使用した ASP.NET アプリケーション用の構成

ApplicationInsights.config の次のセクションでは、ServerTelemetryChannelをカスタムの場所に設定して構成されたStorageFolder チャネルを示します。

    <TelemetrySinks>
        <Add Name="default">
            <TelemetryProcessors>
                <!-- Telemetry processors omitted for brevity  -->
            </TelemetryProcessors>
            <TelemetryChannel Type="Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel.ServerTelemetryChannel, Microsoft.AI.ServerTelemetryChannel">
                <StorageFolder>d:\temp\applicationinsights</StorageFolder>
            </TelemetryChannel>
        </Add>
    </TelemetrySinks>

コードでの ASP.NET アプリケーション用の構成

次のコードでは、カスタムの場所に設定された StorageFolder を使って ServerTelemetryChannel インスタンスを設定しています。このコードをアプリケーションの先頭、通常は Global.aspx.cs の Application_Start() メソッド内に追加します。

using Microsoft.ApplicationInsights.Extensibility;
using Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel;
protected void Application_Start()
{
    var serverTelemetryChannel = new ServerTelemetryChannel();
serverTelemetryChannel.StorageFolder = @"d:\temp\applicationinsights";
    serverTelemetryChannel.Initialize(TelemetryConfiguration.Active);
    TelemetryConfiguration.Active.TelemetryChannel = serverTelemetryChannel;
}

コードでの ASP.NET Core アプリケーション用の構成

Startup.cs クラスの ConfigureServices メソッドを次のように変更します。

using Microsoft.ApplicationInsights.Channel;
using Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel;

public void ConfigureServices(IServiceCollection services)
{
    // This sets up ServerTelemetryChannel with StorageFolder set to a custom ___location.
    services.AddSingleton(typeof(ITelemetryChannel), new ServerTelemetryChannel() {StorageFolder = @"d:\temp\applicationinsights" });

    services.AddApplicationInsightsTelemetry();
}

重要

ASP.NET Core アプリケーションでは、TelemetryConfiguration.Active を使用したチャネルの構成はサポートされていません。

コードでの .NET と .NET Core コンソールアプリケーション用の構成

コンソールアプリのコードは、.NET と .NET Core で同じです。

var serverTelemetryChannel = new ServerTelemetryChannel();
serverTelemetryChannel.StorageFolder = @"d:\temp\applicationinsights";
serverTelemetryChannel.Initialize(TelemetryConfiguration.Active);
TelemetryConfiguration.Active.TelemetryChannel = serverTelemetryChannel;

ServerTelemetryChannel の動作の詳細

ServerTelemetryChannel は、到着した項目をメモリ内バッファーに格納します。項目は、シリアル化されて圧縮され、30 秒ごとに、または 500 項目がバッファリングされるごとに 1 回、Transmission インスタンスに格納されます。 1 つの Transmission インスタンスは、最大 500 個の項目を含み、Application Insights サービスに対する 1 回の HTTPS 呼び出しで送信されるテレメトリのバッチを表します。

既定では、最大 10 個の Transmission インスタンスを並列に送信できます。これより速いペースでテレメトリが到着する場合、またはネットワークや Application Insights のバックエンドが低速の場合は、Transmission インスタンスがメモリ内に格納されます。このメモリ内 Transmission バッファーの既定の容量は 5 MB です。メモリ内の容量を超過した場合、Transmission インスタンスは 50 MB を上限としてローカルディスクに保存されます。

ネットワークに問題がある場合も、Transmission インスタンスはローカルディスクに保存されます。アプリケーションがクラッシュした場合に消えずに残るのは、ローカルディスクに保存されている項目のみです。これらは、アプリケーションが再起動すると常に送信されます。ネットワークの問題が解決しない場合、 ServerTelemetryChannel はテレメトリの送信を再試行する前に 10 秒から 1 時間の指数バックオフロジックを使用します。

チャネルの構成可能な設定

各チャネルの構成可能な設定の完全な一覧については、次を参照してください。

ここでは、ServerTelemetryChannel で最もよく使われる設定について説明します。

MaxTransmissionBufferCapacity: 転送をメモリ内にバッファリングするためにチャネルで使われるメモリの最大量 (バイト単位)。この容量に達すると、新しい項目はローカルディスクに直接保存されます。既定値は 5 MB です。これより高い値を設定するとディスクの使用量は減りますが、アプリケーションがクラッシュするとメモリ内の項目は失われることに注意してください。
MaxTransmissionSenderCapacity: Application Insights に同時に送信される Transmission インスタンスの最大数。既定値は 10 です。この設定はさらに高い値に構成でき、大量のテレメトリが生成される場合はそうすることをお勧めします。量が多くなるのは、通常、ロードテストの間や、サンプリングがオフになっている場合です。
StorageFolder:必要に応じてディスクに項目を保存するためにチャネルが使用するフォルダー。 Windows では、他のパスが明示的に指定されない限り、%LOCALAPPDATA% または %TEMP% が使用されます。 Windows 以外の環境では、ユーザーが有効な場所を指定する必要があります。そうしないと、テレメトリはローカルディスクに保存されません。

使用すべきチャネル

実行時間の長いアプリケーションが含まれるほとんどの運用シナリオでは、ServerTelemetryChannel をお勧めします。テレメトリのフラッシュの詳細については、Flush() の使用に関するページを参照してください。

Flush() を使用する場合

Flush()メソッドは、バッファーに格納されたテレメトリを直ちに送信します。ただし、特定のシナリオでのみ使用する必要があります。

次のようなときは Flush() を使います。

アプリケーションがシャットダウンされようとしており、終了する前にテレメトリが確実に送信されるようにする必要があります。
例外ハンドラーを使用していて、テレメトリが配信されていることを保証する必要があります。
すぐに終了するバックグラウンドジョブや CLI ツールのような有効期間の短いプロセスを記述しています。

Web サービスなどの実行時間の長いアプリケーションでは、 Flush() を使用しないでください。 SDK は、バッファリングと転送を自動的に管理します。 Flush()を不必要に呼び出すとパフォーマンスの問題が発生する可能性があり、特に同期的にフラッシュされないServerTelemetryChannelを使用している場合は、すべてのデータが送信されるとは限りません。

オープンソース SDK

Application Insights の他の SDK と同じく、チャネルもオープンソースです。コードを読んで投稿するか、 GitHub の公式リポジトリで問題を報告します。

次のステップ

よく寄せられる質問 (FAQ) を確認するには、テレメトリチャネルに関する FAQ を参照してください
サポートされているバージョンの Application Insights SDK を実行していることを確認します。
サンプリング
SDK のトラブルシューティング

次の方法で共有

Application Insights のテレメトリ チャネル

テレメトリ チャネルとは

組み込みのテレメトリ チャネル

テレメトリ チャネルを構成する