0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@cyberselfish999

# Application Insights: フロントエンド-バックエンド間の通信エラーをKQLで追跡する方法

0
Posted at

はじめに

Azure App Serviceでフロントエンド(Node.js/Express)とバックエンド(FastAPI)を運用する際、API呼び出しのエラーを適切に追跡することが重要です。しかし、Application InsightsのKQL(Kusto Query Language)でどのテーブルを見るべきかを理解していないと、エラーを見逃してしまいます。

この記事では、まずApplication Insightsの基本的な仕組みを理解した上で、実際のトラブルシューティング経験をもとに、正しいテーブルの選択方法とKQLクエリを解説します。

本記事に含まれるコマンドやクエリは、実際の環境に適用する前に以下の点を必ず確認してください:

  • リソース名、リソースグループ名、アプリケーション名は例示です。実際の環境に合わせて変更してください
  • Application Insights接続文字列などの機密情報は、環境変数やKey Vaultで管理してください
  • 本番環境への適用前に、開発環境での十分なテストを実施してください

リクエストの流れと Application Insights の役割

Application Insightsによる監視を理解するには、まずリクエストがどのように流れ、どこで記録されるかを知ることが重要です。

1. ユーザー操作

ユーザーがブラウザやSPA（Single Page Application）上でボタンをクリックしたり、ページを読み込んだりすると、フロントエンドでイベントが発生します。

2. フロントエンド → バックエンドへの HTTP Request

フロントエンドは、API呼び出しなどの形でバックエンドにHTTPリクエストを送信します。

ここで重要: このフロントエンドからの外部呼び出しは、Application Insightsによって**Dependency telemetry（依存関係テレメトリ）**として記録されます。

┌───────────────┐
│ フロントエンド │ ──HTTP Request→ バックエンド
└───────────────┘
      ↓
[dependencies テーブルに記録]

3. バックエンドでのリクエスト処理

バックエンドがHTTPリクエストを受け取ると、そのリクエストは**Request telemetry（リクエストテレメトリ）**として記録されます。

フロントエンド ──>   ┌──────────────┐
                    │ バックエンド  │
                    └──────────────┘
                          ↓
                [requests テーブルに記録]

4. バックエンド → 外部サービス（Dependencies）

バックエンドは、データベースや外部APIなどの依存サービスにアクセスします。これらの呼び出しもDependency telemetryとして Application Insightsに記録されます。

                    ┌──────────────┐
フロントエンド ──>   │ バックエンド  │ ──→ データベース/外部API
                    └──────────────┘
                          ↓
                [dependencies テーブルに記録]

5. 可視化と分析

Application Insightsのポータルでは、フロントエンドの操作からバックエンドの処理、さらに依存サービスへの呼び出しまでを一連のトレースとして確認できます。これにより、ボトルネックや障害箇所の特定が容易になります。

テレメトリの記録場所まとめ

動作 記録されるテーブル 視点
フロントエンド → バックエンド dependencies フロントエンド
バックエンドがリクエスト受信 requests バックエンド
バックエンド → DB/外部API dependencies バックエンド
アプリケーション例外 exceptions 発生箇所
ログ出力 traces 発生箇所

この基本を理解した上で、実際のトラブルシューティングを見ていきましょう。

調査報告: よくある誤解と正しいエラー追跡方法

発生した問題: requestsテーブルを見てもエラーが見つからない

問題のシナリオ

「APIエラーが頻発しているのに、以下のKQLクエリではsuccess=Trueの結果しか表示されない」

// これではフロントエンドのAPIエラーは見つからない
requests
| where timestamp > ago(24h)
| order by timestamp desc
| take 100

原因: テーブルの役割を誤解している

requestsテーブルは:

  • バックエンドが受け取ったリクエストを記録
  • バックエンドが404や401などを「正常に返却した」場合、success=Trueになる
  • バックエンド視点での成功/失敗を記録

フロントエンドから見たAPIエラーは:

  • dependenciesテーブルに記録される
  • フロントエンド視点での外部依存関係（バックエンドAPI）の成功/失敗を記録

Application Insightsのテーブル構成

主要テーブルの役割

テーブル名 記録内容 フロントエンドAPIエラー バックエンドエラー
dependencies 外部依存関係の呼び出し ✅ ここを見る -
requests 受信したHTTPリクエスト - ✅ ここを見る
exceptions アプリケーション例外 ✅ ✅
traces ログメッセージ ✅ ✅

フロントエンド-バックエンド間エラーの正しい追跡方法

1. フロントエンドから見たAPIエラー（dependenciesテーブル）

// フロントエンドからのバックエンドAPI呼び出しエラー
dependencies
| where timestamp > ago(24h)
| where success == false  // これがAPIエラー
| project 
    timestamp,
    name,                  // API エンドポイント
    target,                // バックエンドのホスト名
    resultCode,            // HTTPステータスコード
    duration,
    data,                  // リクエストURL
    cloud_RoleName         // アプリケーション名
| order by timestamp desc
| take 100

2. エラーがない場合のデバッグ手順

ステップ1: dependenciesテーブルにデータがあるか確認

// dependenciesテーブルに何かデータがあるか確認
dependencies
| where timestamp > ago(24h)
| take 10

結果が空の場合 → フロントエンドのApplication Insights計装に問題あり

ステップ2: すべての依存関係を確認（successフィルターなし）

// フィルター条件を緩めて確認
dependencies
| where timestamp > ago(24h)
| project 
    timestamp,
    name,
    success,
    resultCode,
    target,
    type,
    cloud_RoleName
| order by timestamp desc
| take 100

ステップ3: アプリケーション名でデータを確認

// どのアプリケーション名でデータが記録されているか
dependencies
| where timestamp > ago(24h)
| summarize count() by cloud_RoleName, type

3. 全体像を把握する統合クエリ

// すべてのテーブルから直近のデータを確認
union requests, dependencies, exceptions, traces
| where timestamp > ago(24h)
| summarize count() by 
    TableName = itemType,
    cloud_RoleName,
    success = tostring(success)
| order by count_ desc

このクエリで、どのテーブルにどのようなデータが記録されているかが一目で分かります。

バックエンドエラーの追跡

バックエンドでの処理失敗を確認

// バックエンドで受け取ったリクエストのエラー（500エラーなど）
requests
| where timestamp > ago(24h)
| where cloud_RoleName contains "back"  // バックエンド名でフィルタ（実際の名前に変更）
| where success == false  // バックエンド側の処理失敗
| project 
    timestamp,
    name,
    resultCode,
    success,
    duration,
    url
| order by timestamp desc
| take 100

cloud_RoleNameについて:
cloud_RoleNameは、Application Insightsに設定されたアプリケーション名です。実際の環境では、Azure PortalのApplication Insightsで確認してください。

HTTPステータスコード別の集計

// エラーコード別の集計（4xx, 5xx）
requests
| where timestamp > ago(24h)
| extend StatusCode = toint(resultCode)
| where StatusCode >= 400
| summarize 
    Count = count(),
    AvgDuration = avg(duration),
    MaxDuration = max(duration)
    by resultCode, name
| order by Count desc

実用的なKQLクエリ集

エラー率の時系列グラフ

// エラー率の時系列チャート（5分間隔）
dependencies
| where timestamp > ago(24h)
| where type == "Http"
| summarize 
    TotalCalls = count(),
    FailedCalls = countif(success == false),
    ErrorRate = round(100.0 * countif(success == false) / count(), 2)
    by bin(timestamp, 5m)
| order by timestamp asc
| render timechart

フロントエンド-バックエンド間の統合エラービュー

// フロントエンド-バックエンド間通信エラーの統合ビュー
union requests, dependencies, exceptions
| where timestamp > ago(24h)
| where success == false or (type == "exception")
| extend 
    ErrorType = case(
        itemType == "request", "Backend Request Error",
        itemType == "dependency", "External Dependency Error",
        itemType == "exception", "Application Exception",
        "Other"
    ),
    StatusCode = tostring(coalesce(resultCode, "N/A")),
    ErrorMessage = tostring(coalesce(outerMessage, message, "Unknown error"))
| project 
    timestamp,
    ErrorType,
    name,
    StatusCode,
    ErrorMessage,
    duration,
    operation_Id,
    cloud_RoleName
| order by timestamp desc
| take 100

エラーコード別の円グラフ

// エラーコード別の分布
dependencies
| where timestamp > ago(24h)
| where success == false
| summarize Count = count() by resultCode
| render piechart

トラブルシューティング: dependenciesテーブルにデータがない場合

原因1: フロントエンドの計装が未設定

**server.js（またはapp.js）**で以下が設定されているか確認:

const appInsights = require("applicationinsights");
appInsights
  .setup(process.env.APPLICATIONINSIGHTS_CONNECTION_STRING)  // 環境変数から取得
  .setAutoDependencyCorrelation(true)
  .setAutoCollectRequests(true)
  .setAutoCollectPerformance(true)
  .setAutoCollectExceptions(true)
  .setAutoCollectDependencies(true)  // ← dependenciesテーブルへの記録に重要
  .setAutoCollectConsole(true)
  .start();

セキュリティのポイント:

  • 接続文字列は絶対にソースコードにハードコードしないでください
  • 環境変数APPLICATIONINSIGHTS_CONNECTION_STRINGで管理してください
  • Azure Key Vaultの使用も検討してください

原因2: 環境変数が設定されていない

Azure App Serviceの環境変数を確認:

# 環境変数の確認（リソース名は実際の環境に合わせて変更）
az webapp config appsettings list \
  --resource-group <your-resource-group> \
  --name <your-frontend-app-name> \
  --query "[?name=='APPLICATIONINSIGHTS_CONNECTION_STRING']"

環境変数が設定されていない場合:

# 環境変数の設定（接続文字列はAzure Portalから取得）
az webapp config appsettings set \
  --resource-group <your-resource-group> \
  --name <your-frontend-app-name> \
  --settings APPLICATIONINSIGHTS_CONNECTION_STRING="<your-connection-string>"

原因3: データ送信の遅延

Application Insightsへのデータ送信には最大5分程度の遅延があります。直近のエラーを確認する場合は時間範囲を広げてください。

// 過去1時間に範囲を広げる
dependencies
| where timestamp > ago(1h)
| where success == false
| order by timestamp desc
| take 100

Azure Dashboardへの統合

ダッシュボードの作成手順

  1. Azure Portal → ダッシュボード → + 新しいダッシュボード
  2. ダッシュボード名を入力（例: "API Error Monitoring"）
  3. Application Insights → ログ でクエリを実行
  4. クエリ結果の上部にある 「📌 ダッシュボードにピン留め」 をクリック
  5. タイトルとサブタイトルを設定して 「適用」

推奨ダッシュボードレイアウト

効果的な監視ダッシュボードには以下のタイルを配置することをおすすめします:

  1. エラー率の時系列グラフ - トレンド把握
  2. 最新エラーリスト - 即座の問題確認
  3. エラーコード別分布（円グラフ） - 問題の種類を把握
  4. 依存関係エラー - 外部サービスの問題を特定
  5. 例外トップ10 - アプリケーションレベルの問題

まとめ

フロントエンド-バックエンド間のエラー追跡のポイント

確認したいこと 使用するテーブル 重要なフィルタ
フロントエンドから見たAPIエラー dependencies success == false
バックエンドの処理エラー requests success == false
アプリケーション例外 exceptions cloud_RoleName
ログメッセージ traces severityLevel >= 2

よくある間違い

❌ 間違い: requestsテーブルでフロントエンドのAPIエラーを探す
✅ 正解: dependenciesテーブルでフロントエンドのAPIエラーを探す

❌ 間違い: success == falseがないからエラーがないと判断
✅ 正解: まずdependenciesテーブル自体にデータがあるか確認

トラブルシューティングの手順

  1. dependenciesテーブルにデータがあるか確認
  2. cloud_RoleNameでアプリケーションを特定
  3. success == falseでエラーをフィルタ
  4. 統合クエリで全体像を把握

この手順で、フロントエンド-バックエンド間の通信エラーを確実に追跡できます。

セキュリティチェックリスト

この記事を参考に実装する際は、以下を必ず確認してください:

  • Application Insights接続文字列を環境変数で管理している
  • ソースコードに機密情報をハードコードしていない
  • Azure Key Vaultの使用を検討している
  • リソース名は実際の環境に合わせて変更している
  • 本番環境への適用前に開発環境でテストしている
  • KQLクエリに個人情報や機密情報のフィルタを追加していない

参考資料

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?