Azure MonitorでApplication InsightsのOpenTelemetryを有効化する場合、やるべきことは「監視をオンにする」だけではありません。結論から言うと、対象アプリにAzure Monitor OpenTelemetry DistroまたはExporterを導入し、Application Insightsの接続文字列を安全に設定し、Cloud Role Name・サンプリング・Live Metrics・移行方針を確認してから展開します。
特に既存のApplication Insights SDKやOpenCensusから移行する環境では、重複計装、データ量の増加、Application Mapの表示崩れ、テレメトリ欠落の誤解が起きやすい点に注意が必要です。2026年5月時点の公式情報では、Azure Monitor OpenTelemetry Distroは.NET、Node.js、Python、Java向けに提供され、トレース、メトリック、ログ、例外、カスタムテレメトリ、Live Metricsに対応する構成として説明されています。(Microsoft Learn)
Azure MonitorのOpenTelemetry有効化で何が変わるのか
Azure Monitorの「Enable OpenTelemetry in Application Insights」は、Application Insightsに送る監視データをOpenTelemetryベースで収集・送信するための公式手順です。
従来のApplication Insights SDKだけに依存する構成から、ベンダー中立のOpenTelemetryの考え方に寄せることで、アプリケーションの可観測性を標準化しやすくなります。Azure Monitor Application InsightsはAzure MonitorのAPM機能であり、OpenTelemetryで収集したテレメトリをApplication Insightsで分析できます。(Microsoft Learn)
実務上の変更点は、主に次の5つです。
| 変更点 | 実務での意味 |
|---|---|
| OpenTelemetry DistroまたはExporterを導入する | 言語ごとにNuGet、npm、PyPI、Java agentなどの導入作業が必要 |
| 接続文字列で送信先を指定する | Application Insightsリソースごとの接続文字列を環境変数などで管理する |
| トレース、メトリック、ログをOpenTelemetryのシグナルとして扱う | 従来SDKの独自APIから、OpenTelemetryの概念に合わせた設計が必要になる |
| サンプリングやLive Metricsの既定動作を確認する | コスト、データ欠落の見え方、リアルタイム監視に影響する |
| Cloud Role Nameを明示する重要性が増す | 複数サービスを同じApplication Insightsリソースへ送る場合、Application Mapの見やすさに直結する |
つまり、Azure Monitor OpenTelemetryの有効化は、単なる監視設定ではなく「アプリケーション監視の設計変更」です。小規模な単体アプリなら短時間で導入できますが、マイクロサービス、AKS、App Service、複数言語の混在環境では、展開前の設計が重要になります。
対象になるアプリケーションと確認すべき前提条件
公式手順の主な対象は、.NET、Node.js、Python、Javaのアプリケーションです。Azure Functionsやブラウザーのユーザー操作監視は別ルートになるため、同じOpenTelemetry有効化手順をそのまま適用しないようにします。(Microsoft Learn)
| 対象 | 主な導入方法 | 確認ポイント |
|---|---|---|
| ASP.NET Core / .NETアプリ | Azure.Monitor.OpenTelemetry.AspNetCoreまたはExporter | .NET / .NET Frameworkの対応バージョン、既存SDKとの重複 |
| Javaアプリ | applicationinsights-agentをJVM引数に追加 | Java 8以降、agentのバージョン、サンプリング既定値 |
| Java native / GraalVM | Spring Boot native、Quarkus向け構成 | GraalVM 17以降、Live Metricsなど一部機能の可否 |
| Node.jsアプリ | @azure/monitor-opentelemetry | useAzureMonitor()の呼び出し順、対応Node.jsランタイム |
| Pythonアプリ | azure-monitor-opentelemetry | Python 3.8以降、logger設定、OpenCensus移行 |
| Azure Functions | Functions向けのOpenTelemetry手順 | host.jsonのtelemetryMode、C# in-processの制約 |
| ブラウザー計測 | Application Insights JavaScript SDK | ブラウザーアプリではOpenTelemetryではなくJavaScript SDKを使う |
ブラウザーのページビューやユーザー操作はApplication Insights JavaScript SDKを使う前提で、OpenTelemetryではありません。また、Azure Functionsではhost.jsonに"telemetryMode": "OpenTelemetry"を設定し、Application Insightsの接続文字列をアプリ設定に追加する流れになります。公式概要では、C# in-processのFunctionsではOpenTelemetryが現在サポートされない点も明記されています。(Microsoft Learn)
管理者が最初に確認すべき設定
Azure Monitor OpenTelemetryを展開する前に、管理者は「どのApplication Insightsリソースに、どのアプリのテレメトリを、どの権限とコスト設計で送るのか」を決めておく必要があります。
Application Insightsリソースと接続文字列
Azure Monitor OpenTelemetry Distroは、Application Insightsリソースの接続文字列を使ってテレメトリの送信先を判断します。公式手順では、接続文字列はApplication Insightsリソースの概要画面から取得し、本番環境では環境変数またはJavaの構成ファイルを使うことが推奨されています。コードに直接設定する方法は、ローカル開発やテスト環境向けと考えるべきです。(Microsoft Learn)
本番で避けたいのは、接続文字列をソースコード、Dockerfile、公開リポジトリ、フロントエンドコードに埋め込むことです。接続文字列自体はパスワードと同じ扱いではないものの、送信先リソースを示す重要な設定です。ブラウザー側で露出する計測とサーバー側の計測は、必要に応じて別のApplication Insightsリソースに分けると、スパム的なテレメトリやコスト増加の影響を切り分けやすくなります。
Cloud Role NameとCloud Role Instance
複数サービスが同じApplication Insightsリソースへテレメトリを送る場合、Cloud Role Nameの設定は必須に近い確認項目です。公式手順でも、2つ以上のサービスが同じApplication Insightsリソースへ送信する場合は、Application Map上で正しく表すためにCloud Role Nameを設定する必要があるとされています。(Microsoft Learn)
設定しない場合、Application Map上のノード名が曖昧になり、障害調査時に「どのAPI」「どのWorker」「どのバッチ」から出た依存関係なのか判断しづらくなります。
実務では、次のような命名が扱いやすいです。
| 用途 | Cloud Role Nameの例 |
|---|---|
| フロントエンドAPI | web-api |
| 注文処理API | order-api |
| 決済連携Worker | payment-worker |
| 夜間バッチ | daily-batch |
| 管理画面 | admin-portal |
OpenTelemetryのResource属性では、service.nameやservice.namespace、service.instance.idを使ってCloud Role NameやCloud Role Instanceに対応させる構成が説明されています。設定しない場合、Cloud Role NameはApplication Insightsリソース名、Cloud Role Instanceはマシン名に既定設定される可能性があります。(Microsoft Learn)
サンプリングとコスト管理
OpenTelemetry導入後に最も誤解されやすいのがサンプリングです。サンプリングは、すべてのトレースを送信せず、一定割合または一定レートで送信量を制御する仕組みです。これはコスト管理に有効ですが、「すべてのリクエストがApplication Insightsに見える」と思っていると、データ欠落に見えてしまいます。
公式構成では、固定割合サンプリングとレート制限サンプリングの例が示されており、環境変数とコードの両方で設定できます。また、コードレベルの設定と環境変数が両方ある場合、環境変数が優先されると説明されています。(Microsoft Learn)
Java agentでは、バージョン3.4.0以降でレート制限サンプリングが利用され、既定でおおよそ1秒あたり最大5リクエストを取得する設定が説明されています。高トラフィック環境では、既定値のまま本番展開すると、障害調査に必要なトレースが想定より少なく見える可能性があります。(Microsoft Learn)
判断基準は次のとおりです。
| 状況 | 推奨判断 |
|---|---|
| 低トラフィックの社内システム | 最初は高めの取得率で検証し、コストを見ながら調整 |
| 高トラフィックのAPI | レート制限サンプリングを前提に、重要な失敗系の可視性を確認 |
| 障害調査を重視する本番環境 | トレースだけでなく、メトリックとログアラートも併用 |
| リリース直後の監視 | 一時的にサンプリング率を上げ、安定後に下げる運用も検討 |
サンプリングを「コスト削減のための設定」とだけ見るのは危険です。アラート、障害分析、SLO監視の精度にも影響するため、監視設計の一部として扱いましょう。
開発者が実装時に行う基本手順
開発者が行う作業は、言語ごとに異なります。ただし、大きな流れは共通しています。
| 手順 | 作業内容 | 失敗しやすいポイント |
|---|---|---|
| 1 | 既存のApplication Insights SDKやOpenCensus利用状況を確認 | 二重送信、古いAPI依存を見落とす |
| 2 | 対象言語のDistroまたはExporterをインストール | パッケージ名やagentバージョンを固定せずに展開する |
| 3 | アプリ起動時にAzure Monitorを使う設定を追加 | Node.jsで読み込み順を誤る |
| 4 | APPLICATIONINSIGHTS_CONNECTION_STRINGを設定 | 環境ごとの送信先を取り違える |
| 5 | Cloud Role Nameを設定 | Application Mapでサービスが混在する |
| 6 | サンプリング、Live Metrics、ログ収集範囲を調整 | ログ過多やコスト増加に気づかない |
| 7 | Application Insightsでデータ到達を確認 | 表示まで数分かかることを異常と判断する |
.NETの基本例
ASP.NET Coreでは、NuGetパッケージを追加し、UseAzureMonitor()を起動処理に組み込みます。
dotnet add package Azure.Monitor.OpenTelemetry.AspNetCoreusing Azure.Monitor.OpenTelemetry.AspNetCore;
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddOpenTelemetry().UseAzureMonitor();
var app = builder.Build();
app.Run();トレース、メトリック、ログを個別にExporterへ送る構成もあります。公式手順では、Azure.Monitor.OpenTelemetry.AspNetCoreやAzure.Monitor.OpenTelemetry.Exporterの導入、UseAzureMonitor()、AddAzureMonitorTraceExporter()などの例が示されています。(Microsoft Learn)
Javaの基本例
Javaでは、Application Insights agentをJVM引数に追加する形が中心です。
java -javaagent:/path/to/applicationinsights-agent-3.7.8.jar -jar myapp.jar接続文字列は、環境変数、システムプロパティ、構成ファイルなどで設定できます。Javaでは設定の優先順位や複数アプリを同じJVMで動かす場合の考慮もあるため、アプリケーションサーバーやコンテナの起動引数を必ず確認してください。(Microsoft Learn)
Node.jsの基本例
Node.jsでは、@azure/monitor-opentelemetryを導入し、アプリの早い段階でuseAzureMonitor()を呼び出します。
npm install @azure/monitor-opentelemetryconst { useAzureMonitor } = require("@azure/monitor-opentelemetry");
useAzureMonitor();既存のApplication Insights SDK 2.xから移行する場合、useAzureMonitor()は他のライブラリをインポートする前に呼び出す必要があります。順番を誤ると、起動直後のテレメトリを取りこぼす可能性があります。(Microsoft Learn)
Pythonの基本例
Pythonでは、PyPIパッケージを導入し、configure_azure_monitor()で構成します。
pip install azure-monitor-opentelemetryimport logging
from azure.monitor.opentelemetry import configure_azure_monitor
configure_azure_monitor(
logger_name="your_logger_namespace",
)
logger = logging.getLogger("your_logger_namespace")Pythonでは、ログ収集対象のlogger namespaceを明確にすることが重要です。広すぎる範囲を収集すると、アプリ本体ではなくSDKやライブラリ由来のログまで増え、ノイズやコスト増加につながります。
移行時に確認すべきポイント
既存環境でApplication Insightsを使っている場合、OpenTelemetry化は「新規導入」よりも慎重に進める必要があります。
.NETではSDK 3.xとDistroの併用を避ける
.NETでは、Application Insights .NET SDK 3.xを使ってApplication Insights SDK 2.xからOpenTelemetryベースの実装へ移行する選択肢があります。SDK 3.xは多くのTelemetryClientやTelemetryConfiguration APIを維持しつつ、Azure Monitor OpenTelemetry Exporterを使ってApplication Insightsへ送信します。ただし、新規アプリやすでにAzure Monitor OpenTelemetry Distroを使う環境ではDistroを使い、Application Insights .NET SDK 3.xとDistroを同じアプリで併用しないよう公式に説明されています。(Microsoft Learn)
実務では、次のように判断すると安全です。
| 状況 | 選ぶ方針 |
|---|---|
| 新規のASP.NET Coreアプリ | Azure Monitor OpenTelemetry Distroを使う |
既存.NETアプリでTelemetryClient依存が大きい | SDK 3.x移行を検討し、段階的にOpenTelemetryへ寄せる |
| すでにOpenTelemetryを導入済み | DistroまたはExporterを軸に整理し、従来SDKとの二重化を避ける |
Node.jsではクリーン導入かSDK 3.x移行かを選ぶ
Node.jsの移行では、Azure Monitor OpenTelemetry Distroをクリーンインストールする方法と、Application Insights SDK 3.xへアップグレードする方法があります。Distroへ移行するとOpenTelemetryの考え方に合わせやすくなりますが、Application Insights SDK 2.xのAPIがそのまま使えるわけではありません。TelemetryProcessor相当の処理も、OpenTelemetryのSpanProcessorやLogRecordProcessorの考え方に合わせる必要があります。(Microsoft Learn)
「短期間で壊さず移行したい」のか、「将来を見据えてOpenTelemetry標準へ寄せたい」のかで選択が変わります。
Javaではagent 3.x移行時のデータ差分を見る
Javaでは、2.x系のApplication Insights SDKやagentから3.x agentへ移行する場合、依存関係、ログ連携、TelemetryInitializer、TelemetryProcessor、operation nameの見え方が変わる可能性があります。
特に、以前のApplication Insights Java 2.x SDKで使っていたTelemetryInitializerやTelemetryProcessorが、3.x agentでは同じように動かないケースがあります。移行前後で、依存関係、例外、ログ、Application Map、Kustoクエリの結果を比較することが重要です。(Microsoft Learn)
PythonでOpenCensusを使っている場合は削除が前提
PythonでOpenCensusを使っている場合、Azure Monitor向けにはOpenCensus関連ライブラリを削除し、Azure Monitor OpenTelemetry Distroへ移行する流れが示されています。公式移行手順では、opencensus-*で始まるPyPIパッケージのアンインストールや、OpenCensus SDKおよびAzure Monitor OpenCensus exporterのコード削除が説明されています。(Microsoft Learn)
OpenCensusとOpenTelemetryを一時的に混在させると、同じリクエストが別形式で送られたり、相関が崩れたりする可能性があります。移行計画では、削除対象のimport文、初期化コード、カスタムメトリック送信処理を洗い出しましょう。
展開時に失敗しやすいポイント
接続文字列を設定したのにデータが出ない
最初に確認すべきなのは、環境変数名です。基本は次の名前です。
APPLICATIONINSIGHTS_CONNECTION_STRING=<Your connection string>本番環境では、App Serviceのアプリケーション設定、AKSのSecret、コンテナ実行環境の環境変数、CI/CDのシークレット管理など、どこで値を注入しているかを明確にします。
また、Application Insights上にデータが表示されるまで数分かかる場合があります。公式手順でも、アプリケーションを実行してからAzure portalでApplication Insightsを開き、データ表示まで数分かかる可能性があると説明されています。(Microsoft Learn)
Application Mapがサービス単位で分かれない
複数アプリが同じApplication Insightsリソースに送っているのにCloud Role Nameを設定していないと、Application Mapが見づらくなります。
たとえば、api、worker、batchが同じ名前やマシン名で表示されると、障害発生時に「どのコンポーネントが遅いのか」を即座に判断できません。OpenTelemetry導入時は、接続文字列と同じくらいCloud Role Nameを重視しましょう。
サンプリングで「データが欠落した」と誤解する
高トラフィック環境でサンプリングが有効な場合、すべてのリクエストがトレースとして残るとは限りません。これは設定ミスではなく、コストとデータ量を制御するための仕様です。
ただし、障害調査に必要な情報まで見えなくなると困ります。重要なAPI、失敗リクエスト、決済・認証などのクリティカルな処理では、サンプリング設定、ログ、メトリック、アラートを組み合わせて確認してください。
Live Metricsの扱いを確認していない
Live Metricsは、運用中アプリの動作をリアルタイムに近い形で確認できる機能です。Azure Monitor OpenTelemetry DistroではLive Metricsに関する設定が説明されており、構成によって有効・無効を切り替えられます。一方で、.NET Exporter単体やGraalVM nativeなど、利用可否に注意が必要なケースもあります。(Microsoft Learn)
リリース直後の監視ではLive Metricsが役立ちますが、対応していない構成で「見えない」と判断しないよう、事前に対象言語と導入方式を確認しましょう。
オフラインストレージのディスク権限を見落とす
Azure Monitor OpenTelemetry系の実装では、Application Insightsへ送信できない場合にテレメトリを一時的にローカルへ保存し、再送する仕組みがあります。公式構成では、切断時にキャッシュし、最大48時間の再送を行う説明があります。また、高負荷時には時間やファイルサイズの制限によりテレメトリが破棄される可能性があります。(Microsoft Learn)
Java agentでは、送信できなかったテレメトリをjava.io.tmpdir配下のtelemetryフォルダーに保存し、既定で最大50MBまで保持し、48時間を超えたファイルは削除されると説明されています。(Microsoft Learn)
コンテナ環境では、次を確認してください。
| 確認項目 | 理由 |
|---|---|
| 一時ディレクトリに書き込み権限があるか | 権限不足だと再送用ファイルを保存できない |
| Pod再起動時に一時領域が消えるか | 未送信テレメトリが失われる可能性がある |
| ストレージ上限を超えないか | 高負荷時に古いイベントが破棄される可能性がある |
| 個人情報を含むログを保存していないか | 一時ファイルにもデータ保護の観点が必要 |
セキュリティとガバナンスで見るべき点
OpenTelemetryを有効にすると、トレース、ログ、例外、依存関係、カスタム属性など、アプリケーションの内部情報がApplication Insightsへ送られます。これは障害調査には有効ですが、個人情報や機密情報の混入リスクもあります。
Application InsightsのFAQでは、既定のSDKモジュールは通常、機密性の高い個人データを含めないものの、URLやカスタムテレメトリに個人情報を入れないよう注意が促されています。データはHTTPSで送信され、保存時やデータセンター間移動時にも暗号化される説明がありますが、送信前のデータ設計は利用者側の責任です。(Microsoft Learn)
管理者と開発者は、次のルールを決めておくと運用が安定します。
| ルール | 具体例 |
|---|---|
| URLに個人情報を入れない | /users/[email protected]/ordersではなく、IDやマスク済み値を使う |
| カスタム属性の命名を統一する | tenant.id、feature.nameなどをチームで標準化 |
| ログレベルを環境ごとに分ける | 本番はInformation以上、調査時のみ一時的に詳細化 |
| 接続文字列の管理場所を限定する | Key Vault、CI/CD Secret、アプリ設定で管理 |
| 送信量を定期確認する | 予期しない課金やデータインジェスト増加を早期に検知 |
さらに安全性を高めたい場合は、Microsoft Entra ID認証による取り込みも検討できます。公式構成では、Entra認証によりAzureへの接続をより安全にし、不正なテレメトリ取り込みを防ぐ方法として説明されています。ただし、GraalVM Nativeでは利用できないなど、対象ごとの制約確認が必要です。(Microsoft Learn)
導入前チェックリスト
本番展開前には、次の項目を確認してください。
| チェック項目 | 確認内容 |
|---|---|
| 対象アプリの棚卸し | .NET、Java、Node.js、Python、Functions、ブラウザーのどれか |
| 既存SDKの確認 | Application Insights SDK、OpenCensus、独自Exporterの有無 |
| 送信先設計 | 環境別、サービス別、ブラウザー別にApplication Insightsリソースを分けるか |
| 接続文字列の管理 | 環境変数、構成ファイル、Secret管理のどれを使うか |
| Cloud Role Name | Application Mapで識別できる名前を設定したか |
| サンプリング | 既定値、固定割合、レート制限、アラート影響を確認したか |
| Live Metrics | 対象構成で使えるか、有効・無効の方針を決めたか |
| オフラインストレージ | 書き込み権限、容量、保持期間、コンテナ再起動時の影響を確認したか |
| セキュリティ | 個人情報、接続文字列、Entra認証、RBACを確認したか |
| 検証方法 | Application Insights、Log Analytics、Application Map、Live Metricsで確認したか |
まず何から始めるべきか
Azure Monitor OpenTelemetryを有効にするなら、最初に全アプリへ一斉展開するのではなく、代表的な1サービスでパイロット導入するのが安全です。
おすすめの進め方は次の順番です。
- 既存のApplication Insights SDKやOpenCensus利用箇所を洗い出す
- ステージング環境にAzure Monitor OpenTelemetry Distroを導入する
- 接続文字列を環境変数で設定する
- Cloud Role Nameを明示する
- サンプリングとログレベルを本番想定に近づける
- Application Insightsでリクエスト、依存関係、例外、ログ、Application Mapを確認する
- 既存監視と差分を比較する
- 本番展開後のコスト、データ量、アラートを監視する
Azure Monitor OpenTelemetryの価値は、導入そのものではなく、障害調査・性能分析・コスト管理を標準化できる点にあります。接続文字列だけを設定して終わりにせず、Cloud Role Name、サンプリング、移行方式、セキュリティ、展開後の確認手順までセットで整備することで、Application Insightsを実運用で使える監視基盤にできます。
コメント