全てのサービスのアップグレードがこうであるといいのだけれどなぁ。のような気持ちとやったことのメモ記事。
.NET Core 3.1くらいのころからAzure App Serviceで動かしているアプリケーションがあるのだけれど、それは常にApplication Insightsとともにあった。
主には何かしら不測の出来事があった際に「何があったのか」を調べるのに使っているのだけれど、例外とその前後の出来事が分かりやすくてとても便利だ。
Application Insightsは大分前に世代が変わって、Azure Monitorと統合、アプリケーションからのAPIも大きく変わった。具体的にはOpenTeremetryベースになっている。
これに対応するには多少の作業が発生するのでサボっていたのだけれど、先ごろ観念して更新対応した。この際の体験がとても楽でよかったのでそのお気持ちを記録した次第。

ぶっちゃけ「楽でした」で終わりなのだけれど、それだけではあんまりだろうと思うので、どういう感じだったのかをメモしておく。
なお、先に書いた通り.NET(ASP.NET Core)が対象なので、他の言語やフレームワークについては知らん模様。
対象=Azure の PaaS でのWebアプリケーションホスティングとのゆるい付き合い - koudenpaのブログ
- Azure Monitorの中のApplication Insights
- ワークスペース新規作成
- サーバサイド修正
- クライアントサイド修正
- 軽微な更新作業で変わらない体験
- オマケ: UseAzureMonitorは何をしているか?
Azure Monitorの中のApplication Insights
旧来のApplication Insightsと何が違うのか? 大して追いかけていないのだけれど、元々Application Insightsは完全に独立した1つのサービスだったものが、Azureのモニタリング全般を司るAzure Monitorのログ基盤であるLog Analyticsに集積したログを可視化するサービスになった。このLog Analyticsにデータを送信するAPIにOpenTelemetryが採用されている。と理解している。
この辺どっかにまとまってるのだと思うのだけれど、追いかけていないので知らないし、探すのたるいので探していない。激しく違っているようだったら正しい情報を教えてくれ!
参考:
- Application Insights の概要 - Azure Monitor | Microsoft Learn
- Making Azure the Best Place to Observe Your Apps with OpenTelemetry
ワークスペース新規作成
更新前と見比べたかったので新しく作った。単に作るだけ。
接続文字列を環境変数に設定してやる。
サーバサイド修正
- services.AddApplicationInsightsTelemetry(); + services.AddOpenTelemetry().UseAzureMonitor();
※差分は実装コードのみ、パッケージの構成やusingは割愛
クライアントサイド修正
- @inject Microsoft.ApplicationInsights.AspNetCore.JavaScriptSnippet JavaScriptSnippet // - @Html.Raw(JavaScriptSnippet.FullScript) + <script type="text/javascript"> + !(function (cfg){~略~{ + src: "https://js.monitor.azure.com/scripts/b/ai.3.gbl.min.js", + // ~略~ + cfg: { // Application Insights Configuration + connectionString: "@(Environment.GetEnvironmentVariable("APPLICATIONINSIGHTS_CONNECTION_STRING"))" + }}); + </script>
参照: Microsoft Azure Monitor の Application Insights JavaScript SDK - Azure Monitor | Microsoft Learn
接続文字列がエンドユーザに露出するが、これは「認証情報ではないよ」とのこと。これは他のクライアントサイドトレースサービスと同様。
軽微な更新作業で変わらない体験
結局のところこれが全て。正直ユーザーとしてはアーキテクチャやAPIが変わったとか興味ない。サービス提供側の好きにしてくれ。
そんなことより、先に挙げたような軽微な作業で元々得られていた例外の追跡等を変わらず行えていることが素晴らしい。後方互換性も維持されていて、ユーザーに無用な負荷をかけていない。
「Application Insightsを使います」と構成するだけで必要十分なアプリケーションの状態追跡が行える。という元々の非常に優れた体験が継続されていてすこぶる良かった。
Webアプリケーションの開発運用に当たって、ASP.NET Core+Microsoft Azureの組み合わせは最も実用的な構成の1つであることは間違いない。今後もいい良い開発運用体験をさせてもらいたいと思う。
オマケ: UseAzureMonitorは何をしているか?
.NETで何らかのサービスを使うに当たっての構成は、UseNanigashi拡張メソッドを呼べばいい感じに構成される。ブラックボックスのままでも困らないが、軽く眺めておくとどういう構成を行っているのか知れて便利なのでなるべく見るようにしている。
Azure.Monitor.OpenTelemetry.AspNetCore/src/OpenTelemetryBuilderExtensions.cs
眺めると、実装はREADMEのWhat is Included in the Distroの項に書かれている通りになっていることが分かる。
各種OTelのInstrumentationと、Application Insights固有のトレース、メトリクス、ログの送信を構成している。
「各種OTelのInstrumentation」はApplication Insights専用のものではないので、OpenTelemetryに対応しているサービスへの送信に用いることもできる。ASP.NETのアプリケーションの可視化にApplication Insights以外を選択する必要性はあまりないと思うが、何らかの事情で他のサービスを使う場合には便利に使えるのではないだろうか。