Azure Front Door でのメトリックとログの監視
Azure Front Door には、アプリケーションの監視、要求の追跡、Front Door 構成のデバッグに役立ついくつかの機能が用意されています。
ログとメトリックは、Azure Monitor によって保存および管理されます。
レポート に、Azure Front Door 経由や Web アプリケーション ファイアウォール (WAF) 経由の、アプリケーションへのトラフィックのフローに関する分析情報が提供されます。
メトリック
Azure Front Door では、メトリックが 60 秒間隔で測定されて送信されます。 メトリックが Azure Monitor で処理されるまでに最大 3 分かかる場合があり、処理が完了するまで表示されません。 メトリックはグラフかグリッドで表示することもでき、Azure portal、Azure PowerShell、Azure CLI、Azure Monitor API からアクセスできます。 詳細については、「Azure Monitor metrics」(Azure Monitor メトリック) を参照してください。
次の表にリストされているメトリックは、一定期間無料で記録されて保存されます。 追加費用を支払うと、さらに長い期間保存できます。
| メトリック | 説明 | Dimensions | 推奨される集計 |
|---|---|---|---|
| バイト ヒット率 | Azure Front Door キャッシュからサービス提供されたトラフィックの割合。エグレス トラフィックの合計に対して計算されます。 ほとんどのトラフィックがキャッシュからサービス提供されず配信元に転送される場合、バイト ヒット率は低くなります。 バイト ヒット率 = (エッジからのエグレス - オリジンからのエグレス)/エッジからのエグレス。 バイト ヒット率の計算から除外されるシナリオ:
|
エンドポイント | 平均、最小 |
| 配信元の正常性の割合 | Azure Front Door から配信元に送信され成功した正常性プローブの割合。 | 配信元、配信元グループ | Avg |
| 配信元の待機時間 | Azure Front Door は、要求を配信元に送信してから、配信元から最後の応答バイトを受信するまでの時間を計算します。 | エンドポイント、配信元 | 平均、最大 |
| 配信元の要求数 | Azure Front Door から配信元に送信された要求の数。 | エンドポイント、配信元、HTTP 状態、HTTP 状態グループ | Avg、Sum |
| 4XX の割合 | 応答の状態コードが 4XX であるすべてのクライアント要求の割合。 | エンドポイント、クライアントの国、クライアントのリージョン | 平均、最大 |
| 5XX の割合 | 応答の状態コードが 5XX であるすべてのクライアント要求の割合。 | エンドポイント、クライアントの国、クライアントのリージョン | 平均、最大 |
| 要求数 | キャッシュから完全にサービス提供された要求を含む、Azure Front Door によりサービス提供されたクライアント要求の数。 | エンドポイント、クライアントの国、クライアントのリージョン、HTTP 状態、HTTP 状態グループ | Avg、Sum |
| 要求サイズ | クライアントからの要求の形式で Azure Front Door に送信されたバイト数。 | エンドポイント、クライアントの国、クライアントのリージョン、HTTP 状態、HTTP 状態グループ | 平均、最大 |
| 応答サイズ | クライアントに Front Door からの応答として送信されたバイト数。 | エンドポイント、クライアントの国、クライアントのリージョン、HTTP 状態、HTTP 状態グループ | 平均、最大 |
| 合計待機時間 | Azure Front Door は、クライアント要求を受信し、最後の応答バイトをクライアントに送信します。 これは、合計所要時間です。 | エンドポイント、クライアントの国、クライアントのリージョン、HTTP 状態、HTTP 状態グループ | 平均、最大 |
| Web アプリケーション ファイアウォール要求の数 | Azure Front Door Web アプリケーション ファイアウォールによって処理される要求の数。 | アクション、ポリシー名、ルール名 | Avg、Sum |
Note
配信元に対する要求がタイムアウトになった場合、Http Status ディメンションの値は 0 になります。
ログ
ログは、Azure Front Door をパススルーするすべての要求を追跡します。 ログが処理されて保存されるまでに数分かかる場合があります。
以下の複数の Front Door ログがあり、さまざまな目的で使用できます。
- アクセス ログ を使用すると、低速な要求を特定し、エラー発生率を判断し、ソリューションに対して Front Door のキャッシュ動作がどのように機能しているか把握できます。
- Web アプリケーション ファイアウォール (WAF) ログを使用すると、潜在的な攻撃を検出したり、WAF がブロックした正当な要求を示している可能性がある擬陽性の検出を行ったりできます。 WAF ログの詳細については、「Azure Web アプリケーション ファイアウォールの監視とログ記録」を参照してください。
- 正常性プローブ ログ を使用すると、異常な配信元や、Front Door の地理的に分散した PoP の一部からの要求に応答しない配信元を特定できます。
- アクティビティ ログ を使用すると、Azure Front Door プロファイルへの構成変更など、Azure リソースに対して実行される操作を可視化できます。
アクセス ログと WAF ログには "追跡参照" が含まれています。これは、X-Azure-Ref ヘッダーを使用して配信元とクライアント応答への要求にも反映されます。 追跡参照を使用して、アプリケーション要求処理のエンド ツー エンド ビューを取得できます。
アクセス ログ、正常性プローブ ログ、WAF ログは、既定では有効になっていません。 診断ログを有効にして保存するには、「Azure Front Door のログ」を参照してください。 アクティビティ ログ エントリは既定で収集され、Azure Portal で表示できます。
アクセス ログ
すべての要求に関する情報がアクセス ログにログされます。 各アクセス ログ エントリには、次の表にリストされている情報が含まれています。
| プロパティ | 説明 |
|---|---|
| TrackingReference | Azure Front Door によって提供される要求を示す一意の参照文字列。 追跡参照は、X-Azure-Ref ヘッダーを使用してクライアントと配信元に送信されます。 追跡参照は、アクセス ログまたは WAF ログ内の特定の要求を検索する際に使用します。 |
| Time | 要求されたコンテンツを Azure Front Door エッジがクライアントに配信した日付と時刻 (UTC)。 |
| HttpMethod | 要求で使用される HTTP メソッド: DELETE、GET、HEAD、OPTIONS、PATCH、POST、または PUT。 |
| HttpVersion | クライアントによって要求で指定された HTTP バージョン。 |
| RequestUri | 受信した要求の URI。 このフィールドには、完全なスキーム、ポート、ドメイン、パス、クエリ文字列が含まれます。 |
| HostName | クライアントからの要求に含まれるホスト名。 カスタム ドメインを有効にし、ワイルドカード ドメイン (*.contoso.com) がある場合、HostName ログ フィールドの値は subdomain-from-client-request.contoso.com です。 Azure Front Door ドメイン (contoso-123.z01.azurefd.net) を使用する場合、HostName ログ フィールドの値は contoso-123.z01.azurefd.net です。 |
| RequestBytes | 要求ヘッダーと要求本文を含む HTTP 要求メッセージのサイズ (バイト単位)。 |
| ResponseBytes | HTTP 応答メッセージのサイズ (バイト単位)。 |
| UserAgent | クライアントで使用されたユーザー エージェント。 通常、ユーザー エージェントはブラウザーの型を特定します。 |
| ClientIp | 元の要求を行ったクライアントの IP アドレス。 要求に X-Forwarded-For ヘッダーがあった場合、ヘッダーからクライアント IP アドレスが取得されます。 |
| SocketIp | Azure Front Door エッジへの直接接続の IP アドレス。 クライアントが HTTP プロキシまたはロード バランサーを使用して要求を送信した場合、SocketIp の値はプロキシまたはロード バランサーの IP アドレスです。 |
| timeTaken | Azure Front Door エッジがクライアントの要求を受信してから、Azure Front Door が応答の最後のバイトをクライアントに送信するまでの時間 (秒単位)。 このフィールドでは、ネットワーク待ち時間と TCP バッファリングは考慮されません。 |
| RequestProtocol | クライアントによって要求で指定されたプロトコル。 有効な値には、HTTP、HTTPS があります。 |
| SecurityProtocol | 要求によって使用された TLS/SSL プロトコルのバージョン。要求で暗号化が使用されなかった場合は null 値。 有効な値には、SSLv3、TLSv1、TLSv1.1、TLSv1.2 があります。 |
| SecurityCipher | 要求のプロトコルの値が HTTPS の場合、このフィールドは、クライアントと Azure Front Door によってネゴシエートされた TLS/SSL 暗号を示します。 |
| エンドポイント | Azure Front Door エンドポイントのドメイン名 (contoso-123.z01.azurefd.net など)。 |
| HttpStatusCode | Azure Front Door から返される HTTP 状態コード。 配信元に対する要求がタイムアウトになった場合、HttpStatusCode フィールドの値は 0 になります。 クライアントが接続を閉じた場合、HttpStatusCode フィールドの値は 499 になります。 |
| Pop | ユーザー要求に応答した Azure Front Door エッジのポイント オブ プレゼンス (PoP)。 |
| Cache Status | Azure Front Door キャッシュによって要求が処理された方法。 使用できる値:
|
| MatchedRulesSetName | 処理されたルール エンジンのルールの名前。 |
| RouteName | 要求が一致したルートの名前。 |
| ClientPort | 要求を行ったクライアントの IP アドレス。 |
| Referrer | 要求を開始したサイトの URL。 |
| TimetoFirstByte | Azure Front Door で測定された、Azure Front Door エッジが要求を受信してから最初のバイトがクライアントに送信されるまでの時間の長さ (秒単位)。 このプロパティでは、クライアント データは測定されません。 |
| ErrorInfo | 要求の処理中にエラーが発生した場合、このフィールドにはエラーに関する詳細情報が示されます。 使用できる値:
|
| OriginURL | 要求が送信された配信元の完全な URL。 URL はスキーム、ホスト ヘッダー、ポート、パス、クエリ文字列で構成されています。 URL 書き換え: 要求 URL がルール エンジンによって書き換えられた場合、そのパスは書き換えられたパスを参照します。 エッジ PoP のキャッシュ: Azure Front Door キャッシュから要求がサービス提供された場合、配信元は N/A です。 大きい要求 要求されたコンテンツが大きく、配信元に戻されるチャンク要求が複数ある場合、このフィールドは配信元への最初の要求に対応します。 詳しくは、オブジェクト チャンクに関する記事をご覧ください。 |
| OriginIP | 要求をサービス提供した配信元の IP アドレス。 エッジ PoP のキャッシュ: Azure Front Door キャッシュから要求がサービス提供された場合、配信元は N/A です。 大きい要求 要求されたコンテンツが大きく、配信元に戻されるチャンク要求が複数ある場合、このフィールドは配信元への最初の要求に対応します。 詳しくは、オブジェクト チャンクに関する記事をご覧ください。 |
| OriginName | 配信元の完全なホスト名 (DNS 名)。 エッジ PoP のキャッシュ: Azure Front Door キャッシュから要求がサービス提供された場合、配信元は N/A です。 大きい要求 要求されたコンテンツが大きく、配信元に戻されるチャンク要求が複数ある場合、このフィールドは配信元への最初の要求に対応します。 詳しくは、オブジェクト チャンクに関する記事をご覧ください。 |
| 結果 | SSLMismatchedSNI は、SNI とホスト ヘッダーの間で要求が成功したが不一致の警告があることを示す状態コードです。 この状態コードは、Azure Front Door のサービス使用条件に違反する手法であるドメイン フロンティングを意味します。 SSLMismatchedSNI を含む要求は、2024 年 1 月 22 日以降は拒否されます。 |
| Sni | このフィールドは、TLS/SSL ハンドシェイク中に送信される Server Name Indication (SNI) を指定します。 SSLMismatchedSNI 状態コードがある場合は、正確な SNI 値を識別するために使用できます。 さらに、requestUri フィールド内のホスト値と比較して、不一致の問題を検出して解決することができます。 |
正常性プローブ ログ
Azure Front Door では、失敗した正常性プローブ要求がすべてログされます。 これらのログは、配信元に関する問題を診断するのに役立ちます。 ログに示されている情報は、失敗の理由を調査してから配信元を正常な状態に戻すために使用できます。
このログが役立つ可能性のあるシナリオを、いくつか次に示します。
- Azure Front Door トラフィックが配信元のサブセットに送信されていることに気付きました。 たとえば、4 つの配信元のうち 3 つだけがトラフィックを受信していることに気付くことがあります。 配信元が正常かどうかを知るために、配信元が正常性プローブを受信して応答しているかどうかを知る必要があります。
- 配信元の正常性の割合メトリックが想定より低いことに気付きます。 異常として記録される配信元と、正常性プローブの失敗の理由を知る必要があります。
各正常性プローブ ログ エントリには、次のスキーマがあります。
| プロパティ | 説明 |
|---|---|
| HealthProbeId | 正常性プローブ要求を識別する一意の ID。 |
| Time | 正常性プローブが送信された日付と時刻 (UTC)。 |
| HttpMethod | 正常性プローブ要求によって使用される HTTP メソッド。 値には、正常性プローブの構成に基づき GET と HEAD があります。 |
| 結果 | 正常性プローブの状態。 値は success か、プローブが受け取ったエラーの説明です。 |
| HttpStatusCode | 配信元によって返された HTTP 状態コード。 |
| ProbeURL | プローブ要求が送信された完全なターゲット URL。 URL はスキーム、ホスト ヘッダー、パス、クエリ文字列で構成されています。 |
| OriginName | 正常性プローブが送信された配信元の名前。 配信元が FDQN を使用するように構成されている場合、このフィールドは目的の配信元を見つけるのに役立ちます。 |
| POP | プローブ要求を送信したエッジ PoP。 |
| 送信元の IP | 正常性プローブが送信された配信元の IP アドレス。 |
| TotalLatency | Azure Front Door エッジが正常性プローブ要求を配信元に送信した時点から、配信元が最後の応答を Azure Front Door に送信した時点までの時間。 |
| ConnectionLatency | HTTP プローブ要求を配信元に送信するための TCP 接続の設定にかかった時間。 |
| DNSResolution Latency | DNS 解決にかかった時間。 このフィールドに値があるのは、発信元が IP アドレスではなく FDQN になるように構成されている場合だけです。 配信元が IP アドレスを使用するように構成されている場合は、値は N/A です。 |
次の JSON スニペットの例は、失敗した正常性プローブ要求に関する正常性プローブ ログ エントリを示しています。
{
"records": [
{
"time": "2021-02-02T07:15:37.3640748Z",
"resourceId": "/SUBSCRIPTIONS/mySubscriptionID/RESOURCEGROUPS/myResourceGroup/PROVIDERS/MICROSOFT.CDN/PROFILES/MyProfile",
"category": "FrontDoorHealthProbeLog",
"operationName": "Microsoft.Cdn/Profiles/FrontDoorHealthProbeLog/Write",
"properties": {
"healthProbeId": "9642AEA07BA64675A0A7AD214ACF746E",
"POP": "MAA",
"httpVerb": "HEAD",
"result": "OriginError",
"httpStatusCode": "400",
"probeURL": "http://www.example.com:80/",
"originName": "www.example.com",
"originIP": "PublicI:Port",
"totalLatencyMilliseconds": "141",
"connectionLatencyMilliseconds": "68",
"DNSLatencyMicroseconds": "1814"
}
}
]
}
Web アプリケーション ファイアウォールのログ
Front Door Web アプリケーション ファイアウォール (WAF) ログの詳細については、「Azure Web アプリケーション ファイアウォールの監視とログ記録」を参照してください。
アクティビティ ログ
アクティビティ ログは、Azure Front Door リソースに対する管理操作に関する情報を提供します。 ログには、Azure Front Door リソースに対して実行された各書き込み操作についての詳細 (どのような操作がだれによっていつ行われたかなど) が含まれています。
Note
アクティビティ ログには、読み取り操作は含まれません。 また、Azure portal または従来の管理 API を使用して実行するすべての操作が含まれるわけではありません。
詳しくは、「View your activity logs (アクティビティ ログを表示する)」をご覧ください。
次のステップ
診断ログを有効にして保存するには、「Azure Front Door のログ」を参照してください。
重要
Azure Front Door (クラシック) は、2027 年 3 月 31 日に廃止されます。 サービスの中断を回避するには、2027 年 3 月までに Azure Front Door の Standard または Premium レベルに Azure Front Door (クラシック) プロファイルを移行することが重要です。 詳細については、Azure Front Door (クラシック) の廃止に関するページを参照してください。
Azure Front Door (クラシック) を使用する場合、次の方法でリソースを監視できます。
- メトリック。 現在、Azure Front Door にはパフォーマンス カウンターを表示するメトリックが 8 つあります。
- ログ。 アクティビティ ログや診断ログでは、リソースのパフォーマンス、アクセス、その他のデータを監視目的で保存または使用することができます。
メトリック
メトリックとは、ポータルでパフォーマンス カウンターを表示できるようにする特定の Azure リソース用の機能です。 利用可能な Front Door メトリックは次のとおりです。
| メトリック | メトリックの表示名 | ユニット | Dimensions | 説明 |
|---|---|---|---|---|
| RequestCount | 要求数 | Count | HttpStatus HttpStatusGroup ClientRegion ClientCountry |
Front Door によって処理されるクライアント要求の数。 |
| RequestSize | 要求サイズ | バイト | HttpStatus HttpStatusGroup ClientRegion ClientCountry |
Front Door にクライアントからの要求として送信されたバイト数。 |
| ResponseSize | 応答サイズ | バイト | HttpStatus HttpStatusGroup ClientRegion ClientCountry |
クライアントに Front Door からの応答として送信されたバイト数。 |
| TotalLatency | 合計待機時間 | ミリ秒 | HttpStatus HttpStatusGroup ClientRegion ClientCountry |
クライアント要求が Front Door によって受信されてから、最後の応答バイトが AFD からクライアントに送信されるまでの合計時間。 |
| BackendRequestCount | バックエンド要求数 | Count | HttpStatus HttpStatusGroup Backend |
バックエンドに Front Door から送信された要求の数。 |
| BackendRequestLatency | バックエンド要求の待機時間 | ミリ秒 | バックエンド | Front Door によってバックエンドに要求が送信されてから、Front Door でバックエンドから最後の応答バイトが受信されるまでの算出時間。 |
| BackendHealthPercentage | バックエンドの正常性の割合 | Percent | Backend BackendPool |
Front Door からバックエンドへの成功した正常性プローブの割合。 |
| WebApplicationFirewallRequestCount | Web アプリケーション ファイアウォール要求の数 | Count | PolicyName RuleName Action |
Front Door のアプリケーション レイヤー セキュリティによって処理されたクライアント要求の数。 |
アクティビティ ログ
アクティビティ ログにより、Azure Front Door (クラシック) プロファイルに対して行われた操作に関する情報が提供されます。 また、これらにより、Azure Front Door (クラシック) プロファイルに対して行われた書き込み操作 (PUT、POST、DELETE) について、いつだれが何を行ったのかが示されます。
Note
配信元に対する要求がタイムアウトになった場合、HttpStatusCode の値は 0 に設定されます。
アクティビティ ログに Front Door でアクセスするか、Azure リソースのすべてのログに Azure Monitor でアクセスします。 アクティビティ ログを表示するには、次の手順に従います。
Front Door インスタンスを選択します。
[アクティビティ ログ] を選択します。
フィルター処理のスコープを選択し、 [適用] を選択します。
注意
アクティビティ ログには、Azure portal または元の Management API を使用して実行する GET 操作や操作は含まれません。
診断ログ
診断ログは、監査やトラブルシューティングにとって重要な操作とエラーに関する豊富な情報を提供します。 診断ログは、アクティビティ ログとは異なります。
アクティビティ ログは、Azure リソースに対して行われた操作に関する分析情報を提供します。 診断ログは、自分のリソースが実行した操作に関する分析情報を提供します。 詳細については、Azure Monitor の診断ログに関するドキュメントを参照してください。
Azure Front Door (クラシック) の診断ログを構成するには:
Azure Front Door (クラシック) プロファイルを選択します。
[診断設定] を選択します。
[診断を有効にする] を選択します。 診断ログをメトリックと共にストレージ アカウントにアーカイブし、それらをイベント ハブにストリーム配信したり、Azure Monitor ログに送信したりします。
現在、Front Door では診断ログが提供されています。 診断ログでは、次のスキーマを使用した各エントリが個々の API 要求に提供されます。
| プロパティ | 説明 |
|---|---|
| BackendHostname | 要求がバックエンドに転送されていた場合、このフィールドではバックエンドのホスト名が示されます。 要求がリージョンのキャッシュにリダイレクトまたは転送された場合は (ルーティング規則でキャッシュが有効になっている場合)、このフィールドは空白になります。 |
| CacheStatus | キャッシュのシナリオの場合、このフィールドでは POP でのキャッシュのヒットとミスが定義されます |
| ClientIp | 要求を行ったクライアントの IP アドレス。 要求に X-Forwarded-For ヘッダーがあった場合、同じものからクライアント IP が選択されます。 |
| ClientPort | 要求を行ったクライアントの IP アドレス。 |
| HttpMethod | 要求で使用される HTTP メソッド。 |
| HttpStatusCode | プロキシから返された HTTP 状態コード。 配信元に対する要求がタイムアウトになった場合、HttpStatusCode の値は 0 に設定されます。 |
| HttpStatusDetails | 要求の結果の状態。 この文字列値の意味は、状態参照テーブルで確認できます。 |
| HttpVersion | 要求または接続の種類。 |
| POP | 要求が到着したエッジの短い名前。 |
| RequestBytes | 要求ヘッダーと要求本文を含む HTTP 要求メッセージのサイズ (バイト単位)。 |
| RequestUri | 受信した要求の URI。 |
| ResponseBytes | 応答としてバックエンド サーバーによって送信されたバイト数。 |
| RoutingRuleName | 要求が一致したルーティング規則の名前。 |
| RulesEngineMatchNames | 要求が一致した規則の名前。 |
| SecurityProtocol | 要求によって使用された TLS/SSL プロトコルのバージョン。暗号化がない場合は、null 値。 |
| SentToOriginShield (非推奨) * 次のセクションの非推奨に関する注意事項を参照してください。 |
true の場合、要求は、エッジ ポップではなく、オリジン シールド キャッシュから応答されました。 オリジン シールドは、キャッシュ ヒット率を向上させる目的で使用される親キャッシュです。 |
| isReceivedFromClient | true の場合、要求はクライアントから送信されます。 false の場合、要求はエッジ (子 POP) で不成功となり、オリジン シールド (親 POP) から応答されます。 |
| TimeTaken | Front Door への要求の最初のバイトから、出される応答の最後のバイトまでの時間の長さ (秒単位)。 |
| TrackingReference | Front Door によって提供された要求を識別する一意の参照文字列。X-Azure-Ref ヘッダーとしてクライアントにも送信されます。 アクセス ログで特定の要求の詳細を検索するために必要です。 |
| UserAgent | クライアントで使用されたブラウザーの種類。 |
| ErrorInfo | このフィールドには、詳細なトラブルシューティングのための特定の種類のエラーが含まれています。 指定できる値は、次のとおりです。 NoError: エラーが見つからなかったことを示します。 CertificateError: 一般的な SSL 証明書エラー。 CertificateNameCheckFailed: SSL 証明書のホスト名が無効であるか、一致しません。 ClientDisconnected: クライアント ネットワーク接続による要求の失敗。 UnspecifiedClientError: 一般的なクライアント エラー。 InvalidRequest: 無効な要求です。 ヘッダー、本文、URL の形式が間違っていることが原因で発生する可能性があります。 DNSFailure: DNS エラー。 DNSNameNotResolved: サーバー名またはアドレスを解決できませんでした。 OriginConnectionAborted: 配信元との接続が突然停止しました。 OriginConnectionError: 一般的な配信元接続エラー。 OriginConnectionRefused: 配信元との接続を確立できませんでした。 OriginError: 一般的な配信元エラー。 OriginInvalidResponse: 配信元から無効な応答または認識できない応答が返されました。 OriginTimeout: 配信元要求のタイムアウト期間が経過しました。 ResponseHeaderTooBig: 配信元から返された応答ヘッダーが大きすぎます。 RestrictedIP: 制限付き IP のため、要求はブロックされました。 SSLHandshakeError: SSL ハンドシェイク エラーのため、配信元との接続を確立できません。 UnspecifiedError: テーブルのいずれのエラーにも適合しなかったエラーが発生しました。 SSLMismatchedSNI:HTTP メッセージ ヘッダーが SSL/TLS 接続の設定中に TLS SNI 拡張機能で示された値と一致しなかったため、要求は無効でした。 |
| 結果 | SSLMismatchedSNI は、SNI とホスト ヘッダーの間で要求が成功したが不一致の警告があることを示す状態コードです。 この状態コードは、Azure Front Door のサービス使用条件に違反する手法であるドメイン フロンティングを意味します。 SSLMismatchedSNI を含む要求は、2024 年 1 月 22 日以降は拒否されます。 |
| Sni | このフィールドは、TLS/SSL ハンドシェイク中に送信される Server Name Indication (SNI) を指定します。 SSLMismatchedSNI 状態コードがある場合は、正確な SNI 値を識別するために使用できます。 さらに、requestUri フィールド内のホスト値と比較して、不一致の問題を検出して解決することができます。 |
Sent to origin shield の非推奨化
生のログ プロパティ isSentToOriginShield は非推奨となり、新しいフィールド isReceivedFromClient に置き換えられました。 非推奨化されたフィールドを既に使用している場合は、新しいフィールドを使用してください。
生ログには、CDN エッジ (子 POP) とオリジン シールドの両方から生成されたログが含まれます。 オリジン シールドとは、世界中に戦略的に配置された親ノードを指します。 これらのノードが配信元サーバーと通信を行うことで、配信元におけるトラフィック負荷が軽減されます。
オリジン シールドに向かう各要求について、次の 2 つのログ エントリが存在します。
- エッジ ノード由来
- オリジン シールド由来
エグレスまたは応答がエッジ ノード由来かオリジン シールド由来かは、isReceivedFromClient フィールドを使用して正しいデータを取得することで区別できます。
この値が false の場合、その要求に対する応答はオリジン シールドからエッジ ノードに返されたことを意味します。 このアプローチは、生ログを課金データと比較する際に有効です。 オリジン シールドからエッジ ノードへのエグレスに料金は発生しません。 料金は、エッジ ノードからクライアントへのエグレスで発生します。
Log Analytics のオリジン シールドで生成されたログを除外するための Kusto クエリ サンプル。
AzureDiagnostics | where Category == "FrontdoorAccessLog" and isReceivedFromClient_b == true
注意
さまざまなルーティング構成やトラフィック動作に対し、backendHostname、cacheStatus、isReceivedFromClient、POP などの一部のフィールドでは、応答の値が異なる場合があります。 次の表では、さまざまなシナリオでこれらのフィールドに設定される異なる値について説明します。
| シナリオ | ログ エントリの数 | POP | BackendHostname | isReceivedFromClient | CacheStatus |
|---|---|---|---|---|---|
| キャッシュが有効になっていないルーティング規則 | 1 | エッジの POP コード | 要求が転送されたバックエンド | True | CONFIG_NOCACHE |
| キャッシュが有効になっているルーティング規則。 エッジ POP でのキャッシュ ヒット | 1 | エッジの POP コード | Empty | True | HIT |
| キャッシュが有効になっているルーティング規則。 エッジ POP ではキャッシュ ミスだが、親キャッシュ POP でキャッシュ ヒット | 2 | 1. エッジの POP コード 2. 親キャッシュの POP コード |
1. 親キャッシュの POP ホスト名 2. Empty |
1. True 2. False |
1. MISS 2. HIT |
| キャッシュが有効になっているルーティング規則。 エッジ POP ではキャッシュ ミスだが、親キャッシュ POP で PARTIAL キャッシュ ヒット | 2 | 1. エッジの POP コード 2. 親キャッシュの POP コード |
1. 親キャッシュの POP ホスト名 2. キャッシュの設定に役立つバックエンド |
1. True 2. False |
1. MISS 2. PARTIAL_HIT |
| キャッシュが有効になっているルーティング規則。 エッジ POP ではキャッシュ PARTIAL_HIT だが、親キャッシュ POP でキャッシュ ヒット | 2 | 1. エッジの POP コード 2. 親キャッシュの POP コード |
1. エッジの POP コード 2. 親キャッシュの POP コード |
1. True 2. False |
1. PARTIAL_HIT 2. HIT |
| キャッシュが有効になっているルーティング規則。 エッジと親キャッシュの両方の POP でキャッシュ ミス | 2 | 1. エッジの POP コード 2. 親キャッシュの POP コード |
1. エッジの POP コード 2. 親キャッシュの POP コード |
1. True 2. False |
1. MISS 2. MISS |
| 要求のエラー処理 | 該当なし |
注意
キャッシュのシナリオでは、要求のバイトの一部が Azure Front Door エッジまたはオリジン シールド キャッシュから提供され、一方でバイトの一部がラージ オブジェクト用の配信元から提供される場合、[Cache Status] (キャッシュの状態) の値は partial_hit になります。
Azure Front Door では、オブジェクト チャンクと呼ばれる方法が使用されます。 大きなファイルが要求されると、Azure Front Door は配信元からファイルを分割して取得します。 Azure Door POP サーバーが、要求されたファイルの全体またはバイト範囲を受け取った後、Azure Front Door エッジ サーバーは、8 MB のチャンク単位で配信元にファイルを要求します。
Azure Front Door エッジに届いたチャンクはキャッシュされ、ただちにユーザーに提供されます。 その後、Azure Front Door は並列処理で次のチャンクをプリフェッチします。 このプリフェッチにより、コンテンツはチャンク 1 つ分だけ常にユーザーより先行することになるため、待ち時間が短縮されます。 この処理は、ファイル全体がダウンロードされるか (要求があった場合)、すべてのバイト範囲が利用可能になるか (要求があった場合)、クライアントが接続を終了するまで続けられます。 バイト範囲の要求の詳細については、RFC 7233 をご覧ください。 Azure Front Door は受信したチャンクをすべてキャッシュします。 ファイル全体を Front Door のキャッシュに保存する必要はありません。 ファイルまたはバイト範囲に対する後続の要求に対しては、Azure Front Door キャッシュの内容が提供されます。 すべてのチャンクが Azure Front Door にキャッシュされていない場合、プリフェッチを使用して配信元にチャンクが要求されます。 この最適化は、配信元サーバーのバイト範囲要求をサポートする機能に依存します。 配信元サーバーがバイト範囲要求をサポートしていない場合、この最適化の効果はありません。
次のステップ
- Azure Front Door (クラシック) プロファイルを作成する方法を確認します
- Azure Front Door (クラシック) のしくみについて学習します