しばやん雑記

Azure とメイドさんが大好きなフリーランスのプログラマーのブログ

既存の Application Insights を Workspace ベースに移行した

これまでのリソースが Classic 扱いになって今後が気になる Application Insights ですが、実際に Log Analytics Workspace ベースに移行してみないとよく分からないと思ったので、手持ちの Azure Functions と組み合わせて使っていたリソースをいくつか移行してみました。

Ignite 2020 合わせで Workspace ベースが GA していたことにブチザッキで気が付きました。

Log Analytics Workspace ベースに移行してメリットがあるのかと言われると、正直なところ劇的なものは無さそうでした。移行ドキュメントに新機能としてまとめられているので、目を通しておくと良いです。

新機能として挙げられている Private Link や CMK / BYOS などは完全にエンタープライズ向けの機能といった感じです。確かに Snapshot Debugger で収集されたデータはメモリダンプが含まれているので、セキュアに扱いたいものですが本番ではまあ使わないです。

Azure Functions との組み合わせでカジュアルに使っている場合には、何も変わらない代わりにメリットもあまり無いように見えます。一応データインジェストが高速化されるとありますが、数値として出ていないため改善されたかどうかの把握が難しいです。

とは言え最近は RBAC を使ったアクセスコントロールが必要な場面があったり、App Service / Front Door などのサービスが Log Analytics へアクセスログなどを転送できるようにもなっているので、Application Insights のデータも同じ Log Analytics に送信できると確かに便利そうです。

1 日に100GB 以上といった大量のデータを扱う場合には 20% 以上の割引も効いてくるので、お得なケースもあるでしょう。Consumption でサクサク作っていた場合には、やはりマッチしないなという印象はあります。

とりあえず実際に Workspace ベースに移行してみます。当然ながら Log Analytics Workspace を作成しておく必要がありますが、移行作業自体は非常にシンプルです。Azure Portal を使う場合は Properties から "Migrate to Workspace-based" を選ぶだけです。

f:id:shiba-yan:20200927210244p:plain

移行を選択すると送信先の Log Analytics を選ぶ画面と元に戻せないという警告が表示されますが、分かっていることなので作成した Log Analytics を選んで保存します。

ちなみに Workspace ベースに移行すると、後から送信先の Log Analytics を変更も出来ます。

f:id:shiba-yan:20200927210251p:plain

今回は Azure Functions と使っていた Application Insights なので、適当に Function を実行してログを送信しました。Log Analytics でクエリ可能になるまで 1,2 分という感じだったので、5 分程度の遅延と言われている Application Insights よりは速くなっている気がします。

Workspace ベースになると Table の名前とスキーマが変わるので、既にクエリを書いている場合には注意が必要になりそうです。既存のアラートなどは Application Insights 側で問題なく動作するようです。

f:id:shiba-yan:20200927210259p:plain

Prefix として App が付いているものは大体 Application Insights と考えておいてよいです。

Table 名とスキーマの差分についてはドキュメントが公開されているので、これを見て読み替えればよいです。Application Insights の Logs から扱う分にはこれまで通りのスキーマで扱えるので、サポートが終わるまで使うというのもありな気はします。

KQL で書くのは変わらずにスキーマが変わっているぐらいなので、適当にデータを見てクエリを書きなおすというのも良いかもしれません。こちらの方が一般的なスキーマになっているので、他のログと組み合わせやすいというメリットがあります。

すぐに違いが分かるのは camelCase から PascalCase になっている点だと思います。地味にはまりそう。

f:id:shiba-yan:20200927210309p:plain

個人的には timestampTimeGenerated に統一されたのが嬉しいです。割と混乱するので。

これまでの Application Insights から唯一落ちた機能として連続エクスポートがありますが、これは Diagnostic settings を使うことでほぼ同じことが実現できるようです。

f:id:shiba-yan:20200927214518p:plain

ここまで Workspace ベースに移行した Application Insights を触ってきましたが、ぶっちゃけた話どっちでも良いなと思いました。今後を考えると Workspace ベースの一択ではありますが、今すぐ既存のリソースを移行する必要性をあまり感じませんでした。

ただし既に Log Analytics を使っている場合には Application Insights のログも統合した方が楽になりそうです。移行自体はとても簡単なので、サクサク終わるはずです。

結局は Application Insights の機能はほぼ全て使えるのと課金体系も同じなので、新しくアプリケーションを作る時には Log Analytics を中心に置いた設計にすればよいかなという結論です。Application Insights 自体を分けるべきか、それとも統合するべきかはまた別途悩むポイントです。