App Service で動かす Web アプリに Application Insights を接続し、ライブメトリックを主役にリアルタイムのリクエストを観察します。さらにトランザクション検索・アプリマップ・KQL ログで挙動と失敗を補助的に可視化します。curl で確実に負荷をかけて生のテレメトリを発生させ、何が遅く何が落ちているかをコードに触れず突き止めます。
本番でアプリが「なんとなく遅い」「たまに 500 が出る」と言われたとき、従来はサーバーにログインしてログファイルを直接漁る必要がありました。リクエストごとの所要時間、依存先の呼び出し、例外のスタックトレースが、デプロイ後に自動で集まっている状態をどう作るか。それがこのラボのテーマです。
題材として Linux の App Service(B1)に小さな Web アプリを置き、そこへ Application Insights を接続します。アプリ側のコードは一切書き換えません。App Service の自動インストルメンテーションと接続文字列だけでテレメトリが流れ始める様子を見たうえで、curl でアプリへ明示的にトラフィックを送り込み、ライブメトリックでリアルタイムのリクエストを眺めます。そこから補助的にトランザクション検索で個々のリクエストを追い、アプリマップで構成を俯瞰し、最後は KQL で requests テーブルを自分のクエリで切り出します。
Application Insights は裏側で Log Analytics ワークスペースにデータを書くワークスペースベース構成が標準なので、ワークスペースの作成から始めます。なお App Service 上の Node.js 自動インストルメンテーションは執筆時点でパブリックプレビューで、テレメトリが画面へ届くまで数分のラグがあったり、安定して出すには継続的なトラフィックが要ることがあります。だからこそ「リクエストをこちらから絶やさず送り続ける」のがこのラボのコツで、待ち時間を逆算した順序で進めます。
操作はすべて japaneast の単一リソースグループ内で完結し、課金設定やアラート通知の構成には踏み込みません。Contributor 相当の一時ユーザーでサインイン済みの前提で進めます。