GitHubの公式ドキュメント更新「Bump OpenTelemetry.Exporter.OpenTelemetryProtocol from 1.9.0 to 1.15.3」は、GitHub本体の機能変更ではなく、GitHub上で管理されている.NET公式ドキュメント内サンプルのNuGet依存関係更新です。結論から言うと、該当サンプルを参考にしている.NETアプリ、OpenTelemetryのOTLP exporterを使っている環境、特にdisk retryやOTLP/gRPCを有効にしている環境では、パッケージ更新だけでなく実行時設定とテレメトリー送信テストまで確認すべきです。
今回の更新は小さな差分に見えますが、OpenTelemetry.Exporter.OpenTelemetryProtocol 1.15.3にはセキュリティ修正や動作変更が含まれます。開発者は依存関係、クラウド管理者は環境変数と保存先権限、ソリューションアーキテクトは監視基盤全体への影響を切り分けて確認すると、移行時のトラブルを防ぎやすくなります。
GitHubの公式ドキュメント更新で何が変わったか
今回確認すべき更新は、dotnet/docsリポジトリのPull Request #53512として2026年4月30日にマージされた変更です。Dependabotにより、OpenTelemetry.Exporter.OpenTelemetryProtocol が 1.9.0 から 1.15.3 へ更新されています。PRページでは、対象ブランチ、マージ日、Dependabotによる更新内容が確認できます。(GitHub)
| 確認項目 | 内容 |
|---|---|
| 対象リポジトリ | dotnet/docs |
| 対象PR | #53512 |
| マージ日 | 2026年4月30日 |
| 更新対象 | OpenTelemetry.Exporter.OpenTelemetryProtocol |
| 更新前 | 1.9.0 |
| 更新後 | 1.15.3 |
| 変更ファイル | ConnectionTracingDemo.ServiceDefaults.csproj |
| 変更規模 | 1ファイル、1行追加、1行削除 |
コミット差分では、docs/fundamentals/networking/telemetry/snippets/tracing/ConnectionTracingDemo.ServiceDefaults/ConnectionTracingDemo.ServiceDefaults.csproj 内の PackageReference が Version="1.9.0" から Version="1.15.3" へ変更されています。一方で、同じファイル内の OpenTelemetry.Extensions.Hosting、OpenTelemetry.Instrumentation.AspNetCore、OpenTelemetry.Instrumentation.Http は表示上 1.9.0 のままです。(GitHub)
GitHub自体の仕様変更ではない点に注意
この更新を「GitHubの仕様変更」と捉えると、対応の優先順位を誤ります。今回の主語は、GitHub上で公開・管理されているMicrosoft系の.NETドキュメントサンプルです。
つまり、次のような変更ではありません。
| 誤解しやすい点 | 実際の内容 |
|---|---|
| GitHub Actionsの仕様変更 | いいえ。GitHub Actionsランナーやワークフロー仕様の変更ではありません。 |
| GitHubリポジトリ設定の変更 | いいえ。ブランチ保護やセキュリティ設定の変更ではありません。 |
| docs.github.comの一般ドキュメント更新 | いいえ。dotnet/docs内の.NETドキュメントサンプル更新です。 |
| .NETアプリが自動で更新される | いいえ。自分のプロジェクトでNuGet更新を行わない限り、通常は反映されません。 |
ただし、Microsoft LearnのサンプルやGitHub上の公式サンプルをCIで参照している場合、または過去にこのサンプルをコピーして自社コードに取り込んだ場合は、実プロジェクト側でも同様の依存関係確認が必要です。
OpenTelemetry.Exporter.OpenTelemetryProtocol 1.15.3が重要な理由
OpenTelemetry.Exporter.OpenTelemetryProtocol は、.NETアプリケーションのトレース、メトリクス、ログをOTLPでCollectorや監視バックエンドへ送るためのパッケージです。OpenTelemetry公式ドキュメントでは、OTLP exporterはOpenTelemetryのデータモデルに沿ってテレメトリーを送信でき、多くの監視ツールやベンダーがOTLPをサポートしていると説明されています。(OpenTelemetry)
今回の更新先であるOpenTelemetry .NET 1.15.3は、2026年4月21日にリリースされたバージョンです。リリースノートでは、OTLP exporterについて、.NET 8+でのOtlpLogExporterのIHttpClientFactory利用、persistent storage cleanupの修正、disk retryの既定挙動修正、OTLP/gRPC retry handlingの修正、シグナル別のretry storage分離、内部診断ログでのOTLP endpoint出力修正、OTEL_SPAN_ATTRIBUTE_VALUE_LENGTH_LIMITの適用修正などが挙げられています。(GitHub)
実務で特に確認すべき変更
| 変更・修正ポイント | 実務上の確認内容 |
|---|---|
| disk retryの既定挙動変更 | OTEL_DOTNET_EXPERIMENTAL_OTLP_RETRY=diskを使う場合、専用ディレクトリを明示しているか確認する。 |
| OTLP/gRPC retry handling修正 | OTLP/gRPCでCollectorへ送信しているアプリは、更新後も送信失敗時の再試行やメモリ使用量が安定しているか確認する。 |
| エラーレスポンス読み込み制限 | 1.15.2以降の修正も含め、異常なレスポンスでプロセスのメモリが圧迫されない構成になっているか確認する。 |
.NET 8+でのIHttpClientFactory利用 | DIコンテナをカスタマイズしているアプリでは、ログexporterの起動確認を行う。 |
| OTLP endpointの内部診断ログ出力修正 | トラブルシューティング時に、以前のログ出力前提で運用手順を作っていないか確認する。 |
| 属性値長制限の修正 | span属性の長さ制限を環境変数で管理している場合、更新後に意図どおり切り詰められるか確認する。 |
GitHub Advisory Databaseでは、OTLP exporterのdisk retryが共有一時ディレクトリにフォールバックしていた問題について、影響バージョンが >= 1.8.0, <= 1.15.2、修正バージョンが 1.15.3 とされています。特にマルチユーザー環境では、blob injection、テレメリー情報の読み取り、ディスク消費といったリスクが説明されています。(GitHub)
また、OTLP/gRPC retry handlingでは、grpc-status-details-binの不正な値により過大なメモリ確保が発生し得る問題があり、影響バージョンは >=1.13.1, < 1.15.3、修正バージョンは 1.15.3 とされています。(GitHub)
さらに、OTLP exporterがエラー時のレスポンス本文を上限なく読み込む問題は、影響バージョンが >= 1.13.1, < 1.15.2、修正バージョンが 1.15.2 とされています。今回の更新先である1.15.3には、この1.15.2の修正も含まれると考えて確認するのが現実的です。(GitHub)
影響を受ける可能性がある環境
今回の更新はドキュメントサンプルの変更ですが、次のような環境では実務上の影響確認が必要です。
| 環境・利用状況 | 確認の必要性 |
|---|---|
.NETアプリでOpenTelemetry.Exporter.OpenTelemetryProtocolを使っている | 高い。対象パッケージの更新可否と実行時挙動を確認する。 |
OTEL_DOTNET_EXPERIMENTAL_OTLP_RETRY=diskを使っている | 高い。retry保存先ディレクトリの明示と権限設定が必要。 |
| OTLP/gRPCでCollectorへ送信している | 高い。gRPC retry handling修正の影響をテストする。 |
| Aspire Service DefaultsやMicrosoft Learnのサンプルを流用している | 中〜高。サンプル依存関係と自社コードの差分を確認する。 |
| 開発用にだけ該当サンプルを動かしている | 中。セキュリティ修正の理解と将来の本番流用に備える。 |
| OpenTelemetryを使っていない | 低い。直接対応は不要だが、依存関係管理の参考情報として把握する。 |
Microsoft LearnのSystem.Net分散トレース記事では、AspireのService DefaultsプロジェクトがOpenTelemetryの設定やOTLP exporterを含み、ASP.NETプロジェクトでOpenTelemetryのトレースやメトリクスを導入しやすくする構成として説明されています。今回の変更ファイルがConnectionTracingDemo.ServiceDefaults.csprojである点を踏まえると、AspireやService Defaultsを流用しているチームは特に確認対象に入れるべきです。(Microsoft Learn)
まず確認するべき依存関係
自社プロジェクトで影響を確認する場合は、最初にNuGet依存関係を棚卸しします。Visual StudioのNuGetパッケージマネージャーだけでなく、CLIでも確認しておくとCI環境との差異を見つけやすくなります。
dotnet list package --include-transitiveOpenTelemetry関連だけを確認したい場合は、環境に応じて絞り込みます。
dotnet list package --include-transitive | grep OpenTelemetryWindows環境では次のように確認できます。
dotnet list package --include-transitive | findstr OpenTelemetry確認すべきファイルは、プロジェクト構成によって異なります。
| 構成 | 確認する場所 |
|---|---|
| 通常のプロジェクト参照 | 各.csprojのPackageReference |
| Central Package Management利用 | Directory.Packages.props |
| lock file利用 | packages.lock.json |
| コンテナビルド | Dockerfile、CIのrestore手順 |
| GitHub Actions | workflow内のdotnet restore、dotnet test、キャッシュ設定 |
OpenTelemetry.Exporter.OpenTelemetryProtocolだけを更新して、他のOpenTelemetryパッケージが古いままになるケースがあります。必ずしも即座に問題になるとは限りませんが、複数のOpenTelemetryパッケージを使っている場合は、OpenTelemetry.Extensions.Hostingや各種Instrumentationパッケージとの組み合わせも含めてrestore結果を確認してください。
更新する場合の基本手順
プロジェクト内で直接PackageReferenceしている場合は、次のように更新できます。
dotnet add package OpenTelemetry.Exporter.OpenTelemetryProtocol --version 1.15.3
dotnet restore
dotnet test.csprojを直接編集する場合は、次のようにします。
<PackageReference Include="OpenTelemetry.Exporter.OpenTelemetryProtocol" Version="1.15.3" />Central Package Managementを使っている場合は、Directory.Packages.props側を確認します。
<PackageVersion Include="OpenTelemetry.Exporter.OpenTelemetryProtocol" Version="1.15.3" />更新後は、単にビルドが通るかではなく、次の順番で確認すると失敗を見落としにくくなります。
| 手順 | 確認内容 |
|---|---|
| restore | バージョン競合、lock file不整合、transitive dependencyの変化を確認する。 |
| build | コンパイルエラーや警告の増減を確認する。 |
| unit test | OpenTelemetry設定を含む起動処理が落ちないか確認する。 |
| integration test | Collectorまたは監視バックエンドにテレメトリーが届くか確認する。 |
| runtime log確認 | exporterのエラー、endpoint設定ミス、認証ヘッダー設定漏れを確認する。 |
| rollback確認 | 問題発生時に以前のパッケージへ戻せるか確認する。 |
disk retryを使っている場合の設定確認
今回の更新で最も見落としやすいのは、disk retryの保存先です。OTEL_DOTNET_EXPERIMENTAL_OTLP_RETRY=diskを使っている場合は、専用ディレクトリを明示してください。GitHub Advisoryでは、更新できない場合の緩和策として、共有環境でdisk retryを避けること、厳格なACL・所有権を持つ専用ディレクトリを設定すること、テナントやユーザー間で共有しないこと、予期しない*.blobやretry backlogを監視することが挙げられています。(GitHub)
Linuxのサービスであれば、例えば次のような考え方です。
OTEL_DOTNET_EXPERIMENTAL_OTLP_RETRY=disk
OTEL_DOTNET_EXPERIMENTAL_OTLP_DISK_RETRY_DIRECTORY_PATH=/var/lib/myapp/otel-retryディレクトリは、アプリケーション実行ユーザーだけが読み書きできるようにします。
sudo install -d -o myapp -g myapp -m 0700 /var/lib/myapp/otel-retryWindows ServerやWindowsコンテナでサービスアカウントを使う場合は、%TEMP%や共有フォルダーに頼らず、アプリ専用の保存先を用意します。
C:\ProgramData\YourCompany\YourApp\otel-retry確認のポイントは、パスの存在だけではありません。次の条件を満たしているかを見ます。
| 確認項目 | 判断基準 |
|---|---|
| 所有者 | アプリケーション実行ユーザー、またはサービスアカウントが管理している。 |
| 読み書き権限 | 不特定ユーザーや他テナントから読み書きできない。 |
| 容量制御 | retry失敗が続いてもディスクを圧迫しないよう監視できる。 |
| ローテーション | 古いblobや異常なbacklogを検知・削除する運用がある。 |
| コンテナ構成 | Pod再起動時に必要な保存性とセキュリティ要件を満たしている。 |
OTLP/gRPCとHTTP/protobufの確認ポイント
OpenTelemetry .NETのOTLP exporterは、gRPCとHTTP/protobufの両方を利用できます。公式ドキュメントでも、OTLP endpointへ送る場合はHTTP/protobufまたはgRPCを選択でき、ASP.NET CoreではAddOtlpExporter()でトレース、メトリクス、ログのexporterを設定する例が示されています。(OpenTelemetry)
更新後に確認すべきなのは、プロトコルとポートの組み合わせです。
| プロトコル | 一般的な確認点 |
|---|---|
| OTLP/gRPC | Collector側のgRPC receiver、ポート、TLS、ロードバランサーのHTTP/2対応を確認する。 |
| HTTP/protobuf | /v1/traces、/v1/metrics、/v1/logsなどのパス設定を確認する。 |
| 共通 | 認証ヘッダー、証明書、プロキシ、タイムアウト、リトライ方針を確認する。 |
よくある失敗は、パッケージ更新後に「アプリは起動するがテレメトリーが届かない」状態です。原因はNuGetではなく、環境変数やCollector側のreceiver設定であることも多いため、アプリ側ログとCollector側ログを両方確認してください。
移行時に失敗しやすいポイント
| 失敗しやすいポイント | 起きること | 対策 |
|---|---|---|
| exporterだけ更新し、他のOpenTelemetryパッケージを確認しない | restore後の組み合わせが想定と異なる | dotnet list package --include-transitiveで全体を見る。 |
packages.lock.jsonを更新しない | CIのrestore --locked-modeで失敗する | lock fileを更新し、PRで差分確認する。 |
| disk retryの保存先を指定しない | 以前と同じ一時ディレクトリ前提で動かそうとして失敗する | 専用ディレクトリと権限を明示する。 |
| Collectorのポートを取り違える | gRPCとHTTP/protobufで送信先が合わない | endpoint、protocol、receiver設定をセットで確認する。 |
| 監視ダッシュボードだけを見る | exporter側で失敗していても原因が分からない | アプリログ、Collectorログ、バックエンド到達状況を分けて見る。 |
| サンプル更新を本番更新と同一視する | 不要な緊急対応や誤った設定変更を行う | まず自社プロジェクトの利用有無を確認する。 |
また、該当サンプルが関係するSystem.Netの分散トレースでは、.NET 9の実験的な接続トレースが扱われています。Microsoft Learnでは、接続トレースはDNS、TCP、TLSなどの詳細把握に役立つ一方、ワークロードが多い本番環境で常時使うには冗長でノイズが多い可能性があると説明されています。(Microsoft Learn)
そのため、Experimental.System.Net.*のようなActivitySourceを有効にしている場合は、パッケージ更新と同時に「必要な期間だけ有効にする」「高トラフィック環境ではサンプリングを調整する」「APMツール側のspan link表示負荷を確認する」といった運用判断も必要です。
開発者・クラウド管理者・意思決定者別の見るべき点
開発者が確認すること
開発者は、まずコードと依存関係を確認します。
.csprojまたはDirectory.Packages.propsで対象パッケージのバージョンを確認するAddOtlpExporter()の設定箇所を確認する- gRPCかHTTP/protobufかを明示しているか確認する
- テスト環境のCollectorにトレース、メトリクス、ログが届くか確認する
- 例外、ログ、span属性の長さ制限が期待どおりか確認する
特に、OTEL_SPAN_ATTRIBUTE_VALUE_LENGTH_LIMITを使って属性値の長さを制御している場合は、更新後に実データで挙動を確認してください。
クラウド管理者が確認すること
クラウド管理者は、実行環境と権限設定を中心に確認します。
- Kubernetes、VM、App Service、コンテナ環境ごとの環境変数
- OTLP Collectorへの到達性
- TLS証明書、認証ヘッダー、シークレット管理
- disk retry保存先のマウント、所有者、ACL
- retry backlogやディスク容量の監視
- Collectorや監視基盤のバージョン互換性
disk retryを使う場合は、保存先ディレクトリが共有一時領域になっていないかを必ず確認してください。共有領域にテレメトリーデータが残ると、機密情報の露出や改ざんのリスクにつながります。
ソリューションアーキテクト・技術意思決定者が確認すること
アーキテクトや技術意思決定者は、単一パッケージの更新ではなく、監視基盤の標準化として捉えるべきです。
- OpenTelemetryパッケージの更新方針
- Dependabotや脆弱性管理の運用ルール
- OTLP Collectorを経由するか、各ベンダーバックエンドへ直接送るか
- 本番で有効にするテレメトリーの粒度
- 障害時にretryで守るデータと、保存しないデータの線引き
- セキュリティ修正をどのSLAで取り込むか
OTLPは柔軟性が高い一方、送信先、認証、retry、保存先、サンプリングを設計しないと、監視のための仕組みが新たなリスクになります。今回の更新は、単なるサンプル修正ではなく、自社のOpenTelemetry運用を点検する良いきっかけです。
すぐ更新すべきかの判断基準
| 状況 | 優先度 | 推奨対応 |
|---|---|---|
本番環境でOpenTelemetry.Exporter.OpenTelemetryProtocol 1.15.2以前を使っている | 高 | 1.15.3以降への更新を検討し、テスト後に適用する。 |
OTEL_DOTNET_EXPERIMENTAL_OTLP_RETRY=diskを使っている | 高 | 1.15.3への更新と保存先ディレクトリ明示を優先する。 |
| OTLP/gRPCで外部Collectorへ送信している | 高 | retry handling修正を踏まえて、更新と送信テストを行う。 |
| 開発環境のサンプルのみで利用している | 中 | 急ぎではないが、サンプル更新に合わせて学習・検証環境を更新する。 |
| OpenTelemetryを導入予定 | 中 | 最初から1.15.3以降を前提に設計する。 |
| OpenTelemetryを使っていない | 低 | 直接対応は不要。依存関係管理の参考として把握する。 |
判断に迷う場合は、「本番でOTLP exporterを使っているか」「disk retryを使っているか」「Collector endpointを完全に信頼できるか」の3点で優先順位を決めると実務的です。
GitHubとDependabot運用で見直したいこと
今回の更新はDependabotによるドキュメントサンプルの依存関係更新です。自社リポジトリでもNuGetパッケージ更新をDependabotやCIで管理している場合は、次の点を見直してください。
| 見直し項目 | 実務での狙い |
|---|---|
| OpenTelemetry関連パッケージの更新単位 | exporterだけでなくSDK、hosting、instrumentationも含めて整合性を見る。 |
| セキュリティアドバイザリ対応 | GHSAやCVEをトリガーに優先度を上げられるようにする。 |
| CIでのrestore確認 | lock fileやtransitive dependencyの変化を早期に検知する。 |
| integration test | Collectorに実際に送信できるかを自動確認する。 |
| rollback手順 | 監視基盤の不具合でアプリ本体に影響が出た場合に戻せるようにする。 |
OpenTelemetryの更新は「監視の更新」ではありますが、アプリケーションプロセス内で動作するライブラリ更新でもあります。エクスポート失敗時のメモリ使用量、retry、ログ出力、DIコンテナとの相互作用まで含めてテストするのが安全です。
次に取るべき行動
今回のGitHub documentation updateで最初にやるべきことは、GitHub側の設定変更ではありません。自社の.NETプロジェクトでOpenTelemetry.Exporter.OpenTelemetryProtocolを使っているかを確認し、使っている場合はバージョン、OTLP送信方式、disk retry設定、Collector到達性を順に点検してください。
最小限の確認フローは次のとおりです。
| 順番 | やること |
| -: | ——————————————————————— |
| 1 | dotnet list package --include-transitiveでOpenTelemetry関連パッケージを確認する。 |
| 2 | OpenTelemetry.Exporter.OpenTelemetryProtocolが1.15.3未満なら更新対象にする。 |
| 3 | disk retryを使っている場合は、専用ディレクトリと権限を設定する。 |
| 4 | gRPCまたはHTTP/protobufのendpoint設定を確認する。 |
| 5 | テスト環境でCollectorへトレース、メトリクス、ログが届くか確認する。 |
| 6 | CI、lock file、Dependabot運用に反映する。 |
差分そのものは1行のパッケージ更新ですが、1.15.3にはセキュリティと運用に関わる修正が含まれます。サンプルを読むだけで終わらせず、自社環境の依存関係、環境変数、retry保存先、送信テストまで確認することが、今回の更新から得るべき実務上の対応です。
コメント