Application Gateway の診断ログ
Application Gateway ログは、リソースとその操作に関連するイベントの詳細情報を提供します。 これらのログは、アクセス、アクティビティ、ファイアウォール、パフォーマンスなどのイベントで使用できます (V1 の場合のみ)。 ログの詳細な情報は、問題のトラブルシューティングを行ったり、この生データを使用して分析ダッシュボードを構築したりするときに役立ちます。
ログは Application Gateway のすべてのリソースで利用できますが、利用するには、選択した保存場所でその収集を有効にする必要があります。 Azure Application Gateway のログは、Azure Monitor サービスによって有効になります。 Log Analytics ワークスペースを使用すると、定義済みクエリをすぐに使用したり、特定のログ条件に基づいてアラートを設定したりできるため、これを使用することをお勧めします。
診断ログの種類
Azure の各種ログを使用して、アプリケーション ゲートウェイの管理とトラブルシューティングを行うことができます。 ここでは、このような種類について詳しく説明します。
- アクティビティ ログ: Azure アクティビティ ログ (以前の操作ログと監査ログ) を使用すると、Azure サブスクリプションに送信されるすべての操作とその操作の状態を表示できます。 アクティビティ ログ エントリは既定で収集され、Azure Portal で表示できます。
- アクセス ログ: このログを使用して Application Gateway のアクセス パターンを表示し、重要な情報を分析できます。 これには、呼び出し元の IP、要求された URL、応答の待機時間、リターン コード、入出力バイトが含まれます。アクセス ログは 60 秒ごとに収集されます。 このログには、Application Gateway のインスタンスごとに 1 つのレコードが含まれます。 Application Gateway のインスタンスは、instanceId プロパティで識別されます。
- パフォーマンス ログ: このログを使用すると、Application Gateway のインスタンスの実行状況を確認できます。 このログでは、インスタンスごとのパフォーマンス情報 (処理された要求の総数、スループット (バイト単位)、失敗した要求の数、正常および異常なバックエンド インスタンスの数など) が取得されます。 パフォーマンス ログは 60 秒ごとに収集されます。 パフォーマンス ログは v1 SKU でのみ使用できます。 v2 SKU の場合は、パフォーマンス データにメトリックを使用します。
- ファイアウォール ログ: このログを使用すると、Web アプリケーション ファイアウォールが構成された Application Gateway の、検出モードまたは防止モードでログに記録された要求を表示することができます。 ファイアウォール ログは 60 秒ごとに収集されます。
Note
ログは、Azure Resource Manager デプロイ モデルでデプロイされたリソースについてのみ使用できます。 クラシック デプロイ モデルのリソースでログを使用することはできません。 2 つのモデルについて理解を深めるには、「Resource Manager デプロイとクラシック デプロイ」を参照してください。
保存場所
ログを任意の場所に保存するオプションを次に示します。
ログ解析ワークスペース: このオプションにより、定義済みのクエリ、視覚化をすぐに使用し、特定のログ条件に基づいてアラートを設定できます。 ログ解析ワークスペースのリソース ログで使用されるテーブルは、リソースで使用されているコレクションの種類によって異なります。
Azure 診断: すべてのデータが Azure Diagnostics テーブルに書き込まれます。 Azure Diagnostics テーブルは複数のリソースの種類にわたり共有され、それぞれに独自のカスタム フィールドが追加されます。 Azure Diagnostics テーブルに取り込まれたカスタム フィールドの数が 500 を超えると、新しいフィールドは最上位レベルとしては追加されず、動的キー値ペアとして "AdditionalFields" フィールドに追加されます。
リソース固有 (推奨): - データは、リソースのカテゴリごとに専用のテーブルに書き込まれます。 リソース固有モードでは、診断設定で選択された各ログ カテゴリに、選択したワークスペース内の独自のテーブルが割り当てられます。 これには、次のようないくつかの利点があります。
- ログ クエリでのデータ操作の簡素化
- スキーマとその構造のより確実な発見
- インジェスト待機時間およびクエリ時間のパフォーマンス向上
- 特定のテーブルに対する、Azure ロールベースのアクセス制御を割り当て可能
Application Gateway には、リソース固有モードでは次の 3 つのテーブルが作成されます。
Note
リソース固有オプションは現在、すべてのパブリック リージョンで利用できます。
既存ユーザーは引き続き Azure Diagnostics を使用することも、API の宛先で診断設定をリソース固有または専用に切り替えることで専用テーブルを選択することもできます。 デュアル モードは使用できません。 すべてのログのデータは、Azure Diagnostics または専用テーブルに流すことができます。 ただし、複数の診断設定により、1 つのデータ フローが Azure Diagnostic に対して行われ、別のデータ フローが同時に特定のリソースを使用するようにすることもできます。
Log Analytics で宛先テーブルを選択する: すべての Azure サービスで、最終的にリソース固有のテーブルが使用されます。 この移行の一環として、トグル ボタンを使用して、診断設定で Azure 診断またはリソース固有のテーブルを選択できます。 切り替えの既定では リソース固有 に設定されています。このモードでは、選択した新しいカテゴリのログが Log Analytics の専用テーブルに送信されますが、既存のストリームは変更されません。 次の例を参照してください。
ワークスペース変換: リソース固有のオプションを選択すると、ワークスペース変換で取り込まれる前に、データをフィルター処理および変更できます。 これにより、詳細な制御が可能になり、データ コストを削減し、セキュリティを強化することで、ログの最も適切な情報に集中できます。 ワークスペース変換の設定の詳細な手順については、「チュートリアル: Azure portalを使用して Azure Monitor ログにワークスペース変換を追加する」を参照してください。
ワークスペース変換を使用してアクセス ログを最適化する例
例 1: 列の選択的投影: 20 列のアプリケーション ゲートウェイ アクセス ログがあり、そのうち 6 つの特定の列にあるデータのみを分析したい場合を考慮します。 ワークスペース変換を使用すると、これらの 6 つの列をワークスペースに投影し、他の 14 列は実質的に除外することができます。 除外された列の元のデータは保存されませんが、それらの空のプレースホルダーは [ログ] ブレードに表示されます。 この方法では、ストレージが最適化され、分析のために関連するデータのみが保持されます。
Note
[ログ] ブレードで、[新しい Log Analytics を試す] オプションを選択すると、ユーザー インターフェイスに表示される列をより詳しく制御できます。
例 2: 特定の状態コードに焦点を当てる: アクセス ログを分析するときに、すべてのログ エントリを処理するのではなく、特定の HTTP 状態コード (4xx や 5xx など) を持つ行のみを取得するクエリを記述できます。 ほとんどの要求は 2xx と 3xx (正常な応答を表します) のカテゴリに分類されることが望ましいため、問題のある状態コードに焦点を当てると、データ セットを絞り込めます。 この標的を絞ったアプローチを使用すると、最も関連性が高く実用的な情報を抽出し、有益でコスト効率の高い情報を得ることができます。
Azure 分析からリソース固有のテーブルに移行するための推奨される移行戦略:
- 現在のデータ保有期間を評価する: Azure 診断テーブルに現在保持されているデータの期間を決定します (たとえば、診断テーブルに 15 日間データが保持されると仮定します)。
- リソース固有のリテンション期間を確立する: リソース固有のテーブルを使用して新しい診断設定を実装します。
- 並列データ収集: 一時的に、Azure Diagnostics とリソース固有の設定の両方で同時にデータを収集します。
- データの精度を確認する: 両方の設定でデータ収集が正確で一貫性があることを確認します。
- Azure 診断設定の削除: 重複するデータ収集を防ぐために、Azure 診断設定を削除します。
他の保存場所
- Azure Storage アカウント: ストレージ アカウントは、ログを長期間保存し、必要に応じて参照する場合に最適です。
- Azure Event Hubs:イベント ハブは、他のセキュリティ情報/イベント管理 (SIEM) ツールと統合してリソースに関するアラートを取得する場合に便利なオプションです。
- Azure Monitor パートナーとの統合。
Azure Monitor の診断設定の宛先について説明します。
PowerShell を使用したログの有効化
アクティビティ ログは、Resource Manager のすべてのリソースで自動的に有効になります。 アクセス ログとパフォーマンス ログで使用可能なデータの収集を開始するには、これらのログを有効にする必要があります。 ログ記録を有効にするには、次の手順に従います。
ログ データを保存するストレージ アカウントのリソース ID をメモしておきます。 この値の形式は、/subscriptions/<サブスクリプション ID>/resourceGroups/<リソース グループ名>/providers/Microsoft.Storage/storageAccounts/<ストレージ アカウント名> です。 サブスクリプション内の任意のストレージ アカウントを使用できます。 この情報は、Azure Portal で確認できます。
ログを有効にするアプリケーション ゲートウェイのリソース ID をメモしておきます。 この値の形式は、/subscriptions/<サブスクリプション ID>/resourceGroups/<リソース グループ名>/providers/Microsoft.Network/applicationGateways/<Application Gateway 名> です。 この情報は、ポータルで確認できます。
次の PowerShell コマンドレットを使用して、診断ログを有効にします。
Set-AzDiagnosticSetting -ResourceId /subscriptions/<subscriptionId>/resourceGroups/<resource group name>/providers/Microsoft.Network/applicationGateways/<application gateway name> -StorageAccountId /subscriptions/<subscriptionId>/resourceGroups/<resource group name>/providers/Microsoft.Storage/storageAccounts/<storage account name> -Enabled $true
ヒント
アクティビティ ログでは別のストレージ アカウントは必要ありません。 アクセス ログとパフォーマンス ログにストレージを使用すると、サービス料金が発生します。
Azure Portal を使用したログの有効化
Azure portal で、ご使用のリソースを見つけ、 [診断設定] を選択します。
Application Gateway では、次の 3 つのログを使用できます。
- アクセス ログ
- パフォーマンス ログ
- ファイアウォール ログ
データの収集を開始するには、 [診断を有効にする] を選択します。
[診断設定] ページに、診断ログの設定が表示されます。 この例では、Log Analytics を使用してログを保存します。 イベント ハブとストレージ アカウントを使用して診断ログを保存することもできます。
設定の名前を入力し、設定を確認した後、 [保存] を選択します。
アクティビティ ログ
アクティビティ ログは、既定では Azure によって生成されます。 ログは、Azure のイベント ログ ストアに 90 日間保存されます。 これらのログの詳細については、「イベントとアクティビティ ログの表示」を参照してください。
アクセス ログ
アクセス ログは、前の手順で示したように、Application Gateway のインスタンスごとにログを有効にした場合にのみ生成されます。 データは、ログ記録を有効にしたときに指定したストレージ アカウントに格納されます。 次に示すように、Application Gateway の各アクセスは JSON 形式でログに記録されます。
Application Gateway と WAF v2 SKU の場合
Note
TLS/TCP プロキシに関する情報については、「データ リファレンス」を参照してください。
| Value | 説明 |
|---|---|
| instanceId | 要求を処理した Application Gateway のインスタンス。 |
| clientIP | Application Gateway の直接のクライアントの IP。 別のプロキシがアプリケーション ゲートウェイの前面にある場合、その前面のプロキシの IP が表示されます。 |
| httpMethod | 要求で使用される HTTP メソッド。 |
| requestUri | 受信した要求の URI。 |
| UserAgent | HTTP 要求ヘッダーからのユーザー エージェント。 |
| httpStatus | Application Gateway からクライアントに返される HTTP 状態コード。 |
| httpVersion | 要求の HTTP バージョン。 |
| receivedBytes | 受信したパケットのサイズ (バイト単位)。 |
| sentBytes | 送信したパケットのサイズ (バイト単位)。 |
| clientResponseTime | アプリケーション ゲートウェイからクライアントに送信された、最初のバイトと最後のバイトの間の時間差 (秒単位)。 応答または低速なクライアントに対する Application Gateway の処理時間を測定するのに役立ちます。 |
| timeTaken | クライアント要求の最初のバイトが処理され、その最後のバイトがクライアントへの応答で送信されるためにかかる時間の長さ (秒単位)。 通常、timeTaken フィールドには、要求パケットと応答パケットがネットワーク経由で移動する時間が含まれています。 |
| WAFEvaluationTime | 要求が WAF によって処理されるためにかかる時間の長さ (秒単位)。 |
| WAFMode | 値は、Detection または Prevention のいずれかです |
| transactionId | クライアントから受信した要求を関連付ける一意識別子 |
| sslEnabled | バックエンド プールへの通信に TLS を使用したかどうか。 有効な値は on と off です。 |
| sslCipher | TLS 通信に使用されている暗号スイート (TLS が有効な場合)。 |
| sslProtocol | 使用されている SSL または TLS プロトコル (TLS が有効な場合)。 |
| serverRouted | アプリケーション ゲートウェイから要求がルーティングされる先のバックエンド サーバー。 |
| serverStatus | バックエンド サーバーの HTTP 状態コード。 |
| serverResponseLatency | バックエンド サーバーからの応答の待機時間 (秒単位)。 |
| host | 要求のホスト ヘッダーに表示されているアドレス。 ヘッダーの書き換えによって書き換えられた場合、このフィールドには更新されたホスト名が含まれます |
| originalRequestUriWithArgs | このフィールドには元の要求 URL が含まれています |
| requestUri | このフィールドには、Application Gateway での書き換え操作後の URL が含まれています |
| upstreamSourcePort | バックエンド ターゲットへの接続を開始するときに Application Gateway によって使用されるソース ポート |
| originalHost | このフィールドには、元の要求ホスト名が含まれています |
| error_info | 4xx および 5xx エラーの理由。 失敗した要求のエラー コードを表示します。 詳細については、「エラー コード情報」を参照してください。 |
| contentType | Application Gateway によって処理または配信されているコンテンツまたはデータの種類 |
{
"timeStamp": "2021-10-14T22:17:11+00:00",
"resourceId": "/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/{resourceGroupName}/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/{applicationGatewayName}",
"listenerName": "HTTP-Listener",
"ruleName": "Storage-Static-Rule",
"backendPoolName": "StaticStorageAccount",
"backendSettingName": "StorageStatic-HTTPS-Setting",
"operationName": "ApplicationGatewayAccess",
"category": "ApplicationGatewayAccessLog",
"properties": {
"instanceId": "appgw_2",
"clientIP": "185.42.129.24",
"clientPort": 45057,
"httpMethod": "GET",
"originalRequestUriWithArgs": "\/",
"requestUri": "\/",
"requestQuery": "",
"userAgent": "Mozilla\/5.0 (Windows NT 6.1; WOW64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/52.0.2743.116 Safari\/537.36",
"httpStatus": 200,
"httpVersion": "HTTP\/1.1",
"receivedBytes": 184,
"sentBytes": 466,
"clientResponseTime": 0,
"timeTaken": 0.034,
"WAFEvaluationTime": "0.000",
"WAFMode": "Detection",
"transactionId": "592d1649f75a8d480a3c4dc6a975309d",
"sslEnabled": "on",
"sslCipher": "ECDHE-RSA-AES256-GCM-SHA384",
"sslProtocol": "TLSv1.2",
"sslClientVerify": "NONE",
"sslClientCertificateFingerprint": "",
"sslClientCertificateIssuerName": "",
"serverRouted": "52.239.221.65:443",
"serverStatus": "200",
"serverResponseLatency": "0.028",
"upstreamSourcePort": "21564",
"originalHost": "20.110.30.194",
"host": "20.110.30.194",
"error_info":"ERRORINFO_NO_ERROR",
"contentType":"application/json"
}
}
Note
clientIP 値 127.0.0.1 のアクセス ログは、アプリケーション ゲートウェイ インスタンスで実行されている内部セキュリティ プロセスから発生します。 これらのログ エントリは無視してかまいません。
Application Gateway Standard および WAF SKU (v1) の場合
| 値 | 説明 |
|---|---|
| instanceId | 要求を処理した Application Gateway のインスタンス。 |
| clientIP | 要求の送信元 IP。 |
| clientPort | 要求の送信元ポート。 |
| httpMethod | 要求で使用される HTTP メソッド。 |
| requestUri | 受信した要求の URI。 |
| RequestQuery | Server-Routed: 要求が送信されたバックエンド プールのインスタンス。 X-AzureApplicationGateway-LOG-ID: 要求に使用される関連付け ID。 バックエンド サーバー上のトラフィックの問題をトラブルシューティングするために使用できます。 SERVER-STATUS: Application Gateway でバックエンドから受信した HTTP 応答コード。 |
| UserAgent | HTTP 要求ヘッダーからのユーザー エージェント。 |
| httpStatus | Application Gateway からクライアントに返される HTTP 状態コード。 |
| httpVersion | 要求の HTTP バージョン。 |
| receivedBytes | 受信したパケットのサイズ (バイト単位)。 |
| sentBytes | 送信したパケットのサイズ (バイト単位)。 |
| timeTaken | 要求の処理および応答の送信にかかった時間 (ミリ秒単位)。 これは、Application Gateway がHTTP 要求の最初のバイトを受信してから、応答の送信操作が完了するまでの間隔として計算されます。 通常、timeTaken フィールドには、要求パケットと応答パケットがネットワーク経由で移動する時間が含まれています。 |
| sslEnabled | バックエンド プールへの通信に TLS または SSL を使用したかどうか。 有効な値は on と off です。 |
| host | 要求がバックエンド サーバーに送信された対象のホスト名。 バックエンドのホスト名が上書きされている場合、この名前にそれが反映されます。 |
| originalHost | Application Gateway でクライアントから要求を受信した対象のホスト名。 |
{
"resourceId": "/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/PEERINGTEST/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/{applicationGatewayName}",
"operationName": "ApplicationGatewayAccess",
"time": "2017-04-26T19:27:38Z",
"category": "ApplicationGatewayAccessLog",
"properties": {
"instanceId": "ApplicationGatewayRole_IN_0",
"clientIP": "191.96.249.97",
"clientPort": 46886,
"httpMethod": "GET",
"requestUri": "/phpmyadmin/scripts/setup.php",
"requestQuery": "X-AzureApplicationGateway-CACHE-HIT=0&SERVER-ROUTED=10.4.0.4&X-AzureApplicationGateway-LOG-ID=874f1f0f-6807-41c9-b7bc-f3cfa74aa0b1&SERVER-STATUS=404",
"userAgent": "-",
"httpStatus": 404,
"httpVersion": "HTTP/1.0",
"receivedBytes": 65,
"sentBytes": 553,
"timeTaken": 205,
"sslEnabled": "off",
"host": "www.contoso.com",
"originalHost": "www.contoso.com"
}
}
エラー コード情報
Application Gateway で要求を完了できない場合は、アクセス ログの error_info フィールドに次のいずれかの理由コードが保存されます。
| 4XX エラー | (4xx エラー コードは、クライアントの要求に問題があり、Application Gateway で処理できないことを示しています)。 |
|---|---|
| ERRORINFO_INVALID_METHOD | クライアントによって、RFC に準拠していない要求が送信されました。 考えられる理由: HTTP メソッドを使用するクライアントがサーバーでサポートされていない、メソッドのスペルが間違っている、HTTP プロトコルのバージョンに互換性がないなどです。 |
| ERRORINFO_INVALID_REQUEST | 構文が正しくないため、サーバーでは要求を処理できません。 |
| ERRORINFO_INVALID_VERSION | Application Gateway で、無効であるかサポートされていない HTTP バージョンの要求を受信しました。 |
| ERRORINFO_INVALID_09_METHOD | クライアントによって、HTTP プロトコル バージョン 0.9 で要求が送信されました。 |
| ERRORINFO_INVALID_HOST | "Host" ヘッダーに指定された値が欠けているか、正しく書式設定されていないか、期待されるホスト値と一致しません。 たとえば、Basic リスナーがなく、マルチサイト リスナーのホスト名がホストと一致しない場合などです。 |
| ERRORINFO_INVALID_CONTENT_LENGTH | content-Length ヘッダーでクライアントによって指定されたコンテンツの長さが、要求内のコンテンツの実際の長さと一致しません。 |
| ERRORINFO_INVALID_METHOD_TRACE | クライアントによって、アプリケーション ゲートウェイでサポートされていない HTTP TRACE メソッドが送信されました。 |
| ERRORINFO_CLIENT_CLOSED_REQUEST | クライアントは、アイドル タイムアウト期間が経過する前に、アプリケーション ゲートウェイとの接続を閉じました。 クライアントのタイムアウト期間が、アプリケーション ゲートウェイのアイドル タイムアウト期間より長いかどうかを確認します。 |
| ERRORINFO_REQUEST_URI_INVALID | クライアントの要求で指定される Uniform Resource Identifier (URI) に関する問題を示します。 |
| ERRORINFO_HTTP_NO_HOST_HEADER | クライアントによってホスト ヘッダーなしで要求が送信されました。 |
| ERRORINFO_HTTP_TO_HTTPS_PORT | クライアントによって HTTPS ポートにプレーン HTTP 要求が送信されました。 |
| ERRORINFO_HTTPS_NO_CERT | 相互 TLS 認証中に、適切に構成された有効な TLS 証明書がクライアントから送信されていないことを示します。 |
| 5XX エラー | 説明 |
|---|---|
| ERRORINFO_UPSTREAM_NO_LIVE | Application Gateway では、受信要求を処理するアクティブまたは到達可能なバックエンド サーバーを見つけることができません |
| ERRORINFO_UPSTREAM_CLOSED_CONNECTION | バックエンド サーバーで、予期せず、または要求が完全に処理される前に接続を閉じました。 これは、バックエンド サーバーで制限に達し、クラッシュしたなどが原因で発生する可能性があります。 |
| ERRORINFO_UPSTREAM_TIMED_OUT | サーバーとの確立された TCP 接続は、構成されたタイムアウト値よりも長くかかったので閉じられました。 |
パフォーマンス ログ
パフォーマンス ログは、前の手順で示したように、Application Gateway のインスタンスごとにログを有効にした場合にのみ生成されます。 データは、ログ記録を有効にしたときに指定したストレージ アカウントに格納されます。 パフォーマンス ログ データは、1 分間隔で生成されます。 これは v1 SKU でのみ使用できます。 v2 SKU の場合は、パフォーマンス データにメトリックを使用します。 次のデータがログに記録されます。
| 値 | 説明 |
|---|---|
| instanceId | パフォーマンス データを生成中の Application Gateway のインスタンス。 複数インスタンスの Application Gateway の場合、インスタンスごとに 1 行が使用されます。 |
| healthyHostCount | バックエンド プール内の正常なホストの数。 |
| unHealthyHostCount | バックエンド プール内の異常なホストの数。 |
| requestCount | 処理された要求の数。 |
| latency | インスタンスから要求を処理するバックエンドへの要求の平均待機時間 (ミリ秒単位)。 |
| failedRequestCount | 失敗した要求の数。 |
| throughput | 最後のログ以降の平均スループット (1 秒あたりのバイト数)。 |
{
"resourceId": "/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/{resourceGroupName}/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/{applicationGatewayName}",
"operationName": "ApplicationGatewayPerformance",
"time": "2016-04-09T00:00:00Z",
"category": "ApplicationGatewayPerformanceLog",
"properties":
{
"instanceId":"ApplicationGatewayRole_IN_1",
"healthyHostCount":"4",
"unHealthyHostCount":"0",
"requestCount":"185",
"latency":"0",
"failedRequestCount":"0",
"throughput":"119427"
}
}
Note
待機時間は、HTTP 要求の最初のバイトが受信されたときから、HTTP 応答の最後のバイトが送信されたときまでで計算されます。 これは、Application Gateway の処理時間、バックエンドへのネットワーク コスト、およびバックエンドが要求の処理に要した時間を加えたものです。
ファイアウォール ログ
ファイアウォール ログは、前の手順で示したように、Application Gateway のインスタンスごとにログを有効にした場合にのみ生成されます。 このログを使用するには、Application Gateway で Web アプリケーション ファイアウォールを構成する必要もあります。 データは、ログ記録を有効にしたときに指定したストレージ アカウントに格納されます。 次のデータがログに記録されます。
| 値 | 説明 |
|---|---|
| instanceId | ファイアウォール データを生成中の Application Gateway のインスタンス。 複数インスタンスの Application Gateway の場合、インスタンスごとに 1 行が使用されます。 |
| clientIp | 要求の送信元 IP。 |
| clientPort | 要求の送信元ポート。 |
| requestUri | 受信した要求の URL。 |
| ruleSetType | ルール セットの種類。 使用できる値は OWASP です。 |
| ruleSetVersion | 使用されるルール セットのバージョン。 使用できる値は 2.2.9 と 3.0 です。 |
| ruleId | トリガーするイベントのルール ID。 |
| message | トリガーするイベントのわかりやすいメッセージ。 詳細は details セクションに示されます。 |
| action | 要求に対して実行されるアクション。 使用可能な値は Blocked と Allowed (カスタム ルールの場合)、Matched (ルールが要求の一部と一致する場合)、Detected と Blocked (どちらも必須ルールの場合。WAF のモードが検出なのか防止なのかによって異なる)。 |
| サイト | ログの生成対象のサイト。 ルールがグローバルであるため、現時点では Global のみ表示されます。 |
| details | トリガーするイベントの詳細。 |
| details.message | ルールの説明。 |
| details.data | 要求で見つかった、ルールに一致するデータ。 |
| details.file | ルールが含まれている構成ファイル。 |
| details.line | イベントをトリガーした、構成ファイル内の行番号。 |
| hostname | Application Gateway のホスト名または IP アドレス。 |
| transactionId | 同じ要求内で発生した複数の規則違反をグループ化するのに役立つ、指定されたトランザクションの一意の ID。 |
{
"timeStamp": "2021-10-14T22:17:11+00:00",
"resourceId": "/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/{resourceGroupName}/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/{applicationGatewayName}",
"operationName": "ApplicationGatewayFirewall",
"category": "ApplicationGatewayFirewallLog",
"properties": {
"instanceId": "appgw_2",
"clientIp": "185.42.129.24",
"clientPort": "",
"requestUri": "\/",
"ruleSetType": "OWASP_CRS",
"ruleSetVersion": "3.0.0",
"ruleId": "920350",
"message": "Host header is a numeric IP address",
"action": "Matched",
"site": "Global",
"details": {
"message": "Warning. Pattern match \\\"^[\\\\d.:]+$\\\" at REQUEST_HEADERS:Host .... ",
"data": "20.110.30.194:80",
"file": "rules\/REQUEST-920-PROTOCOL-ENFORCEMENT.conf",
"line": "791"
},
"hostname": "20.110.30.194:80",
"transactionId": "592d1649f75a8d480a3c4dc6a975309d",
"policyId": "default",
"policyScope": "Global",
"policyScopeName": "Global"
}
}
アクティビティ ログの表示と分析
次のいずれかの方法を使用して、アクティビティ ログのデータを表示および分析できます。
- Azure Tools:Azure PowerShell、Azure CLI、Azure REST API、または Azure portal を使用して、アクティビティ ログから情報を取得します。 それぞれの方法の詳細な手順については、「リソース マネージャーの監査操作」を参照してください。
- Power BI: Power BI アカウントをまだ所有していない場合は、無料で試すことができます。 Power BI テンプレート アプリを使用して、データを分析できます。
アクセス ログ、パフォーマンス ログ、ファイアウォール ログの表示と分析
Azure Monitor ログでは、BLOB ストレージ アカウントからカウンターとイベントのログ ファイルを収集できます。 このツールには、ログを分析するための視覚化と強力な検索機能が含まれています。
自身のストレージ アカウントに接続して、アクセス ログとパフォーマンス ログの JSON ログ エントリを取得することもできます。 JSON ファイルをダウンロードした後、そのファイルを CSV に変換し、Excel、Power BI などのデータ視覚化ツールで表示できます。
ヒント
Visual Studio を使い慣れていて、C# の定数と変数の値を変更する基本的な概念を理解している場合は、GitHub から入手できるログ変換ツールを使用できます。
GoAccess を介してアクセス ログを分析する
Microsoft は、人気のある GoAccess ログ アナライザーをインストールし、Application Gateway アクセス ログに対して実行する、Resource Manager テンプレートを発行しています。 GoAccess では、ユニーク ビジター、要求されたファイル、ホスト、オペレーティング システム、ブラウザー、HTTP 状態コードなど、重要な HTTP トラフィック統計情報が提供されます。 詳細については、GitHub の Resource Manager テンプレート フォルダーにある Readme ファイルを参照してください。
次のステップ
- Azure Monitor ログを使用して、カウンターとイベント ログを視覚化します。
- Power BI を使用した Azure アクティビティ ログの視覚化に関するブログ
- Power BI などでの Azure アクティビティ ログの表示と分析に関するブログ