Azure Monitorの「Configuring OpenTelemetry in Application Insights – Azure Monitor」は、Application InsightsでOpenTelemetryを使うための設定ガイドです。結論から言うと、確認すべき中心は「接続文字列」「Cloud Role名」「サンプリング」「ログとメトリックの扱い」「Live Metrics」「Microsoft Entra ID認証」「オフラインストレージ」「OTLP併用」「URLクエリ文字列の秘匿」です。
特に本番環境では、OpenTelemetryを有効化するだけでは不十分です。テレメトリの送信先、コスト、障害調査時の粒度、機密情報の混入、複数サービスの見え方まで、設定によって大きく変わります。
Microsoft Learnの日本語版では、該当ページは2026年4月23日が最終更新日として表示されています。本記事では、2026年5月7日時点でAzure Monitor Application InsightsのOpenTelemetry構成を確認する管理者・開発者向けに、実務で見落としやすい変更点と展開時の注意点を整理します。 (Microsoft Learn)
Azure Monitor OpenTelemetry構成でまず押さえるべきこと
Azure Monitor OpenTelemetry構成の目的は、.NET、Java、Node.js、Pythonなどのアプリケーションから、Application Insightsへ一貫したテレメトリを送ることです。公式ドキュメントでは、Azure Monitor OpenTelemetry Distroを使ってApplication InsightsでOpenTelemetryを構成する方法が説明されています。Azure Functionsについては別ドキュメント扱いです。 (Microsoft Learn)
ここで重要なのは、OpenTelemetryは「入れたら終わり」の監視設定ではないという点です。接続文字列だけ設定しても、次のような問題が残ることがあります。
| 確認不足の項目 | 起きやすい問題 |
|---|---|
| 接続文字列の設定場所 | 開発環境や旧リソースへテレメトリが送られる |
| Cloud Role名 | Application Mapでサービス名が分かりにくくなる |
| サンプリング | 障害調査に必要なトレースやログが想定より少なくなる |
| Live Metrics | リアルタイム監視できると思っていた構成で使えない |
| オフラインストレージ | コンテナや一時ディスクでテレメトリ保持に失敗する |
| URLクエリ文字列 | SASトークンなどの機密情報が収集される可能性がある |
| OTLP併用 | サポート範囲を誤解して二重送信や運用負荷が増える |
管理者は「監視データが正しい場所に、適切な量で、安全に送られているか」を確認し、開発者は「コード・環境変数・構成ファイルのどこで何を上書きしているか」を確認する必要があります。
対象になるアプリケーションと関係者
今回のAzure Monitor OpenTelemetry構成は、主にApplication InsightsへOpenTelemetryベースのテレメトリを送るアプリケーションが対象です。公式ドキュメントでは、ASP.NET Core、.NET、Java、Java native、Node.js、Python向けの設定が扱われています。 (Microsoft Learn)
影響を受ける関係者は、次のように分けると分かりやすくなります。
| 立場 | 確認すべきポイント |
|---|---|
| Azure管理者 | Application Insightsリソース、接続文字列、Entra ID認証、コスト管理 |
| SRE・運用担当 | サンプリング、Live Metrics、アラート、障害調査時のログ粒度 |
| 開発者 | Distro導入、Resource属性、Cloud Role名、言語別SDK設定 |
| セキュリティ担当 | URLクエリ文字列、SASトークン、認証方式、オフライン保存先 |
| DevOps担当 | 環境変数、CI/CD、ステージング展開、構成ファイルの差分管理 |
特に複数のアプリケーションを1つのApplication Insightsリソースへ送っている場合、Cloud Role名やResource属性の設計が重要です。名前付けが曖昧だと、Application Map上でどのサービスが遅いのか、どのインスタンスで障害が起きているのかを判断しにくくなります。
接続文字列は「どこで設定しているか」を必ず棚卸しする
Application Insightsでは、接続文字列がテレメトリの送信先を決めます。ASP.NET Coreでは、コード、環境変数、appsettings.jsonで接続文字列を設定でき、複数箇所に設定した場合はコード、環境変数、構成ファイルの順で優先されます。 (Microsoft Learn)
実務では、接続文字列の重複設定が最も分かりにくいトラブルになります。たとえば、コード上では新しいApplication Insightsリソースを指定しているのに、CI/CDの環境変数に古い接続文字列が残っているケースです。逆に、環境変数で本番向けの送信先を指定したつもりでも、コード側で別の値が優先される構成もあります。
確認する順序は次の通りです。
| 確認場所 | 見るべき内容 |
|---|---|
| アプリケーションコード | UseAzureMonitor()やExporter設定で接続文字列を直書きしていないか |
| 環境変数 | APPLICATIONINSIGHTS_CONNECTION_STRINGが環境ごとに正しいか |
| 構成ファイル | appsettings.jsonやapplicationinsights.jsonに古い値がないか |
| CI/CD | デプロイ先スロット、コンテナ、App Service設定で上書きされていないか |
| Key Vault連携 | 参照先のシークレット名やバージョンが正しいか |
接続文字列は、基本的には環境変数やシークレット管理で扱うのが安全です。コードに直書きすると、環境差し替えやリソース移行時に事故が起きやすくなります。
Cloud Role名は運用チームが読める名前にする
Azure Monitor OpenTelemetry Distroは、サポートされる環境ではリソースコンテキストを自動検出し、Cloud Role NameとCloud Role Instanceの既定値を提供します。ただし、運用上分かりやすい名前に上書きしたい場面があります。Cloud Role名はApplication Map上のノード名として表示されます。 (Microsoft Learn)
Cloud Role名は、OpenTelemetryのResource属性で設定します。公式情報では、Cloud Role名にはservice.namespaceとservice.nameが使われ、Cloud Role Instanceにはservice.instance.idが使われると説明されています。未設定の場合、Cloud Role名はApplication Insightsリソース名、Cloud Role Instanceはマシン名が既定になります。 (Microsoft Learn)
おすすめは、次のような命名規則を事前に決めることです。
| 用途 | 例 |
|---|---|
| サービス名 | billing-api、order-worker、customer-web |
| 名前空間 | prod、stg、jp-east、commerce |
| インスタンスID | Pod名、VM名、ホスト名、コンテナIDなど |
| Cloud Role名 | commerce.billing-api、prod.order-worker |
Cloud Role名を決めるときは、開発チームの都合だけでなく、障害対応時に運用チームが読めるかを基準にしてください。たとえばapp1やservice-newのような名前は、数か月後に意味が分からなくなりがちです。
サンプリングはコストと調査精度の両方に影響する
サンプリングは、Application Insightsへ取り込むテレメトリ量を減らし、コストを抑えるための重要な設定です。Azure Monitor OpenTelemetry Distroでは、トレースに対して固定率サンプリングとレート制限付きサンプリングを扱えます。公式ドキュメントでは、サンプリングはトレースに適用され、メトリックはサンプリングされないと説明されています。 (Microsoft Learn)
ここで注意したいのは、サンプリングは単なるコスト削減機能ではないということです。設定値を下げすぎると、低頻度のエラーや一部ユーザーだけに発生する遅延が見えにくくなります。一方で、すべてを収集すると、アクセス増加時に取り込み量とコストが膨らむ可能性があります。
固定率サンプリングとレート制限付きサンプリングの使い分け
| 方式 | 向いている場面 | 注意点 |
|---|---|---|
| 固定率サンプリング | リクエスト量が比較的安定しているWebアプリ | 急なアクセス増加時は取り込み量も増えやすい |
| レート制限付きサンプリング | アクセス量の変動が大きいサービス | ピーク時に取得できるトレースが限定される |
| サンプリングなし | 低トラフィック環境、検証環境、重要な短期調査 | 本番で常時使うとコスト増になりやすい |
Javaエージェントでは、サンプリング未設定時にレート制限付きサンプリングで最大およそ1秒あたり5リクエストをキャプチャする既定動作が説明されており、以前の「すべての要求をキャプチャする」既定値を置き換える内容として記載されています。 (Microsoft Learn)
本番展開では、既定値に任せるよりも「なぜその値にするのか」を明示するのが安全です。たとえば、障害調査を重視するAPIでは固定率を高めにし、大量アクセスがある静的なエンドポイントではレート制限を使う、といった設計が考えられます。
ログはトレースサンプリングと連動する点に注意
ログのトレースベースサンプリングを有効にすると、サンプリングされていないトレースに属するログレコードは削除されます。一方で、トレースコンテキストを持たないログは影響を受けません。この機能は既定で有効と説明されています。 (Microsoft Learn)
これは、障害調査で重要です。たとえば「エラーのログは出ているはずなのに、該当リクエストのトレースが見つからない」という状況では、サンプリング設定によってログとトレースの見え方が変わっている可能性があります。
運用前に、次の観点で検証してください。
| 検証項目 | 確認方法 |
|---|---|
| エラー時のトレースが残るか | ステージングで意図的に例外を発生させる |
| ログとトレースが紐づくか | Trace ID、Span IDで検索する |
| サンプリング後もアラートが機能するか | メトリックベースのアラートと併用する |
| 低頻度エラーを拾えるか | サンプリング率を下げた状態で再現テストする |
アラートは、サンプリングの影響を受けにくいメトリックを中心に設計すると安定します。詳細調査はトレース、継続監視はメトリックという役割分担を意識すると、運用しやすくなります。
Live Metricsは既定有効だが、構成ごとの制限を確認する
Live Metricsは、アプリケーションのアクティビティやパフォーマンスをリアルタイムに把握するための機能です。公式ドキュメントでは、Live Metricsは既定で有効とされ、Distro構成時に無効化できると説明されています。一方で、Azure Monitor .NET Exporterでは利用できず、GraalVMネイティブアプリケーションでも利用できないと記載されています。 (Microsoft Learn)
この違いは、運用設計に直結します。たとえば、ASP.NET CoreのWebアプリではLive Metricsを使える想定でも、同じ.NET系のworkerサービスでExporterを使っている場合は期待通りに使えない可能性があります。
Live Metricsを使う場合は、次の点を確認してください。
| 確認項目 | 理由 |
|---|---|
| DistroかExporterか | Live Metricsの利用可否が変わる |
| 言語・ランタイム | GraalVM nativeなど制限がある |
| 本番で有効にするか | リアルタイム監視の必要性とポリシーを確認する |
| プレビュー条件 | 公式ページではAzureプレビュー利用規約への案内がある |
「使えると思っていたが本番で見えない」という事態を避けるため、ステージング環境でAzureポータルのLive Metrics画面まで確認してから展開しましょう。
Microsoft Entra ID認証はセキュリティ要件が高い環境で優先する
Azure Monitorへのより安全な接続を作るには、Microsoft Entra ID認証の利用を検討します。公式ドキュメントでは、この認証方法により、承認されていないテレメトリがサブスクリプションに取り込まれるのを防げると説明されています。 (Microsoft Learn)
接続文字列だけに依存すると、値が漏えいした場合に不正なテレメトリ送信のリスクが残ります。特に、金融、医療、公共系、社内の厳格なセキュリティ基準がある環境では、Entra ID認証の適用可否を早めに確認してください。
ただし、すべての構成で同じように使えるわけではありません。公式情報では、GraalVM NativeアプリケーションではMicrosoft Entra ID認証を利用できないと記載されています。 (Microsoft Learn)
オフラインストレージと自動再試行はコンテナ環境で特に注意する
Azure MonitorのOpenTelemetryベースの機能は、Application Insightsへ接続できないときにテレメトリをキャッシュし、最大48時間の再送を試みます。高負荷時には、許容時間や最大ファイルサイズを超えることでテレメトリが削除される場合があり、必要に応じて古いイベントより最近のイベントが優先されます。 (Microsoft Learn)
この機能は便利ですが、コンテナや一時ディスクを使う環境では注意が必要です。たとえば、Podが再起動されると一時ディスク上のキャッシュが失われる場合があります。保存先ディレクトリに書き込み権限がないと、再送以前にキャッシュ自体ができないこともあります。
展開前に、次の点を確認してください。
| 環境 | 注意点 |
|---|---|
| App Service | 一時領域と永続領域の違いを確認する |
| AKS・コンテナ | 再起動時にキャッシュが消える前提で設計する |
| Linux VM | /tmpや/var/tmpの容量・権限を確認する |
| Windows VM | %LOCALAPPDATA%や%TEMP%の権限を確認する |
| 高トラフィック環境 | 48時間以内でも容量制限で古いイベントが落ちる可能性を考慮する |
オフラインストレージは「必ず全データを守る仕組み」ではありません。一時的なネットワーク断への耐性を上げる仕組みとして扱い、重要な監査ログや業務ログは別途適切な保管先を設計してください。
OTLP Exporter併用はサポート範囲を誤解しない
Azure Monitor ExporterとOTLP Exporterを併用すると、テレメトリをAzure Monitorと別のOpenTelemetry Collectorなどへ送る構成を検討できます。ただし、公式ドキュメントではOTLP Exporterは便宜上示されているものであり、MicrosoftはOTLP Exporterや下流のコンポーネント、サードパーティ体験を正式サポートしないと説明しています。 (Microsoft Learn)
また、Application Insights JavaエージェントはOTLPをサポートしていないとされ、Azure Monitor Exporterと一緒にOTLP Exporterを有効にして2か所へ送信することはできないという記載もあります。 (Microsoft Learn)
OTLP併用を検討する場合は、次のように判断してください。
| 判断基準 | 方針 |
|---|---|
| Azure Monitorだけで監視が完結する | OTLP併用は不要 |
| 既存のOpenTelemetry Collector基盤がある | サポート範囲を確認して限定的に検証 |
| サードパーティAPMへも送信したい | 障害時の責任分界点を明確にする |
| Javaエージェントを使っている | OTLP併用前提にしない |
| 本番で二重送信する | コスト、重複、遅延、個人情報の送信先を確認する |
二重送信は便利に見えますが、トラブル時に「どちらのバックエンドが正しいのか」を判断しにくくなることがあります。まずAzure Monitor側で必要な可視化を満たし、不足分だけOTLP併用を検討するのが現実的です。
URLクエリ文字列はSASトークン混入を前提に対策する
URLクエリ文字列には、アクセストークン、検索条件、ユーザー識別子、SASトークンなど、収集したくない情報が含まれることがあります。公式ドキュメントでは、Azure StorageをSASトークンで呼び出す場合、クエリ文字列の収集をオフにすることが推奨されています。 (Microsoft Learn)
特に.NETでは、DistroパッケージとExporter利用時で既定動作が異なる点に注意が必要です。Azure.Monitor.OpenTelemetry.AspNetCore DistroではASP.NET CoreとHttpClientのInstrumentationが含まれ、クエリ文字列の編集が既定でオフとされています。一方、Azure.Monitor.OpenTelemetry.Exporterを使う場合はInstrumentationライブラリを手動で含める必要があり、それらではクエリ文字列の編集が既定で有効と説明されています。 (Microsoft Learn)
実務では、次のように整理すると安全です。
| 状況 | 推奨対応 |
|---|---|
| SASトークン付きURLを扱う | クエリ文字列を収集しない設定を優先 |
| URLに個人情報が入る可能性がある | アプリ側でURL設計も見直す |
| DistroとExporterが混在 | 既定値の違いを環境ごとに確認 |
| Node.jsで独自処理が必要 | Span Processorでマスク処理を検討 |
| 監査が必要 | 収集対象とマスク方針を文書化する |
「後から消せばよい」ではなく、最初から収集しない設計が基本です。Application Insightsに送られた後のデータ削除は、調査・手続き・影響確認に時間がかかります。
メトリックのエクスポート間隔は60秒を基準に考える
メトリックのエクスポート間隔は、OTEL_METRIC_EXPORT_INTERVALで構成できます。公式ドキュメントでは既定値が60,000ミリ秒、つまり60秒とされ、Azure Monitor MetricsとAzure Monitor Workspaceはカスタムメトリックを固定の60秒間隔で取り込むと説明されています。より短い間隔で送信したメトリックは60秒ごとに処理され、Log Analyticsでは短い間隔がコスト増につながる可能性があります。 (Microsoft Learn)
そのため、理由なくエクスポート間隔を短くするのは避けましょう。短くすればリアルタイム性が上がるとは限らず、むしろコストやノイズが増えることがあります。
判断基準は次の通りです。
| 目的 | 設定方針 |
|---|---|
| 一般的なアプリ監視 | 既定の60秒を基準にする |
| 短時間の負荷試験 | 一時的に短縮し、終了後に戻す |
| コスト最適化 | Log Analytics側の取り込み量も確認する |
| アラート設計 | メトリック間隔と評価期間をセットで調整する |
管理者が確認すべき設定チェックリスト
Azure管理者やSREは、アプリケーションコードよりも「どの環境で、どのリソースへ、どれだけ送っているか」を重視して確認します。
| チェック項目 | 確認内容 |
|---|---|
| Application Insightsリソース | 本番・検証・開発でリソースが分離されているか |
| 接続文字列 | 環境変数やシークレットに古い値が残っていないか |
| Entra ID認証 | セキュリティ要件を満たす構成になっているか |
| サンプリング | コストと障害調査のバランスが取れているか |
| Live Metrics | 本番で使う必要があるか、対象構成で使えるか |
| オフラインストレージ | 保存先の権限、容量、永続性に問題がないか |
| データ保持 | Application InsightsやLog Analyticsの保持期間と合っているか |
| アラート | サンプリングの影響を受けにくいメトリック中心になっているか |
特にコスト管理では、サンプリングだけに頼らないことが重要です。高頻度ログ、不要なカスタムイベント、短すぎるメトリック間隔、重複送信も取り込み量を増やします。
開発者が確認すべき設定チェックリスト
開発者は、アプリケーション内でOpenTelemetry設定がどのように組み込まれているかを確認します。
| チェック項目 | 確認内容 |
|---|---|
| Distro導入 | 対象言語に合ったAzure Monitor OpenTelemetry Distroを使っているか |
| Resource属性 | service.name、service.namespace、service.instance.idを設定しているか |
| 初期化位置 | アプリ起動時にOpenTelemetry設定が確実に読み込まれるか |
| 環境変数 | ローカル、ステージング、本番で値が混ざっていないか |
| 例外・ログ | エラー時にトレース、ログ、メトリックが確認できるか |
| クエリ文字列 | URLに機密情報が含まれない、またはマスクされるか |
| サンプリング | 開発環境と本番環境で設定差分を把握しているか |
OpenTelemetry構成は、アプリケーションの起動直後に読み込まれることが多いため、設定変更後は単にデプロイするだけでなく、プロセス再起動やコンテナ再作成が必要になる場合があります。環境変数を変更したのに挙動が変わらない場合は、まず反映タイミングを確認してください。
移行・展開時のおすすめ手順
既存のApplication Insights SDKや旧設定からAzure Monitor OpenTelemetry構成へ移行する場合は、いきなり全環境で切り替えないことが重要です。次の順序で進めると、送信先の誤りやコスト急増を避けやすくなります。
| 手順 | 作業内容 | 成功の確認ポイント |
|---|---|---|
| 既存設定の棚卸し | SDK、接続文字列、環境変数、構成ファイルを確認 | どこで何を設定しているか一覧化できている |
| 検証環境でDistro導入 | 対象言語に合わせてOpenTelemetryを有効化 | Application Insightsにテレメトリが流れる |
| Cloud Role名を設定 | サービス単位でResource属性を設定 | Application Mapで識別しやすい名前になる |
| サンプリングを明示 | 固定率またはレート制限を決める | 想定した件数・粒度で収集される |
| セキュリティ確認 | Entra ID認証、URLクエリ文字列、保存先を確認 | 機密情報が混入していない |
| 本番前比較 | 旧構成と新構成のメトリック・ログ量を比較 | エラー率、応答時間、依存関係が見える |
| 段階展開 | 一部サービスまたは一部インスタンスから展開 | コスト・アラート・Live Metricsに異常がない |
| 本番反映 | 全体展開後にダッシュボードとアラートを調整 | 運用担当が必要な情報を追える |
移行時のポイントは、「データが出ているか」だけでなく「必要なデータが、必要な名前で、必要な量だけ出ているか」を確認することです。
よくある失敗と対策
Azure Monitor OpenTelemetry構成で起きやすい失敗は、技術的な不具合よりも設定の思い込みに起因することが多いです。
| 失敗例 | 原因 | 対策 |
|---|---|---|
| テレメトリが別リソースに送られる | 接続文字列の優先順位を誤解している | コード、環境変数、構成ファイルを同時に確認する |
| Application Mapが分かりにくい | Cloud Role名を未設定にしている | service.nameとservice.namespaceを決める |
| ログが少なく見える | トレースベースのログサンプリングを理解していない | サンプリング設定とログの紐づきを検証する |
| コストが急増する | サンプリング未設定、ログ過多、短すぎるメトリック間隔 | 取り込み量と設定値を定期的に確認する |
| Live Metricsが使えない | DistroとExporterの違いを見落としている | 対象ランタイムとパッケージを確認する |
| SASトークンが記録される | URLクエリ文字列の収集を許可している | クエリ文字列の収集停止やマスクを設定する |
| 一時障害後にデータが欠ける | オフラインストレージの容量・権限・永続性が不足 | 保存先と再送条件を事前にテストする |
| OTLP併用で運用が複雑化する | サポート範囲と責任分界点が曖昧 | Azure Monitor単独で足りない理由を明確にする |
次に取るべき行動
Azure MonitorのOpenTelemetry構成では、まず接続文字列とCloud Role名を確認し、その後にサンプリング、ログ、メトリック、セキュリティ設定を見直すのが効果的です。特に本番環境では、既定値に任せず、環境ごとの設定値を明文化してください。
最初に行うべき作業は、次の3つです。
APPLICATIONINSIGHTS_CONNECTION_STRINGと構成ファイルの設定場所をすべて洗い出すservice.name、service.namespace、service.instance.idの命名規則を決める- サンプリング設定とログの見え方をステージング環境で検証する
この3点を押さえるだけでも、送信先の誤り、Application Mapの混乱、コスト増、障害調査時の情報不足を大きく減らせます。Azure Monitor OpenTelemetryは、単なる監視ツールの導入ではなく、アプリケーション運用の見える化を設計するための設定です。
コメント