Azure Front Door を監視する
Azure Monitor は、システムからメトリックとログを収集して集計し、可用性、パフォーマンス、回復性を監視し、システムに影響する問題を通知します。 Azure portal、PowerShell、Azure CLI、REST API、またはクライアント ライブラリは、監視データの設定および表示に使用できます。
リソースの種類に応じてさまざまなメトリックとログが使用できます。 この記事では、このサービスで収集できる監視データの種類と、そのデータを分析する方法について説明します。
レポート に、Azure Front Door 経由や Web アプリケーション ファイアウォール (WAF) 経由の、アプリケーションへのトラフィックのフローに関する分析情報が提供されます。
重要
Azure Front Door (クラシック) は、2027 年 3 月 31 日に廃止されます。 サービスの中断を回避するには、2027 年 3 月までに Azure Front Door の Standard または Premium レベルに Azure Front Door (クラシック) プロファイルを移行することが重要です。 詳細については、Azure Front Door (クラシック) の廃止に関するページを参照してください。
Azure Monitor エージェントを使用してデータを収集する
次の表では、サービスを監視するためにデータを収集する方法と、収集されたデータに対して実行できる操作について説明します:
| 収集するデータ | 説明 | データを収集してルーティングする方法 | データを表示する場所 | サポートされるデータ |
|---|---|---|---|---|
| メトリック データ | メトリックは、特定の時点におけるシステムの側面を表す数値です。 メトリックにより、アルゴリズムを使用して集計し、その他のメトリックと比較して、時間の経過による傾向を分析できます。 | - 定期的に自動的に収集されます。 - 一部のプラットフォーム メトリックを Log Analytics ワークスペースにルーティングして、他のデータでクエリを実行できます。 各メトリックの DS エクスポート設定を確認して、診断設定を使用してメトリック データをルーティングできるかどうかを確認します。 |
メトリックス エクスプローラー | Azure Monitor でサポートされる Azure Front Door メトリック |
| リソース ログ データ | ログには、タイムスタンプ付きのシステム イベントが記録されます。 ログには、構造化または自由形式のテキストのさまざまなデータを含めることができます。 データは、クエリと分析のために Log Analytics ワークスペースにルーティングできます。 | 診断設定を作成して、リソース ログ データを収集してルーティングします。 | Log Analytics | Azure Monitor でサポートされる Azure Front Door リソース ログ データ |
| アクティビティ ログのデータ | Azure Monitor アクティビティ ログは、サブスクリプション レベルのイベントに関する分析情報を提供します。 このアクティビティ ログには、リソースが変更されたときや仮想マシンが起動されたときなどの情報が含まれます。 | - 自動的に収集されます。 - 無料で Log Analytics ワークスペースに診断設定を作成します。 |
アクティビティ ログ |
Azure Monitor でサポートされているすべてのデータの一覧については、次を参照してください:
Azure Front Door の組み込み監視
ログは、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)。 WebSocket 接続の場合、時刻は接続が閉じる時刻を表します。 |
| 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 要求メッセージのサイズ (バイト単位)。 WebSocket 接続の場合、この値は接続を介してクライアントからサーバーに送信された合計バイト数です。 |
| ResponseBytes | HTTP 応答メッセージのサイズ (バイト単位)。 WebSocket 接続の場合、この値は接続を介してサーバーからクライアントに送信された合計バイト数です。 |
| UserAgent | クライアントで使用されたユーザー エージェント。 通常、ユーザー エージェントはブラウザーの型を特定します。 |
| ClientIp | 元の要求を行ったクライアントの IP アドレス。 要求に X-Forwarded-For ヘッダーがあった場合、ヘッダーからクライアント IP アドレスが取得されます。 |
| SocketIp | Azure Front Door エッジへの直接接続の IP アドレス。 クライアントが HTTP プロキシまたはロード バランサーを使用して要求を送信した場合、SocketIp の値はプロキシまたはロード バランサーの IP アドレスです。 |
| TimeTaken | Azure Front Door エッジがクライアントの要求を受信してから、応答の最後のバイトがクライアントに送信されるまでの時間。秒単位で測定されます。 このメトリックでは、ネットワーク待機時間と TCP バッファリングが除外されます。 WebSocket 接続の場合は、接続が確立してから終了するまでの時間を表します。 |
| RequestProtocol | 要求でクライアントによって指定されたプロトコル。 有効な値には、HTTP、HTTPS があります。 WebSocket の場合、プロトコルは WS、WSS です。 WebSocket に正常にアップグレードされた要求にのみ WS/WSS が含まれます。 |
| 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 | 正常性プローブが送信された配信元の名前。 配信元が FQDN を使用するように構成されている場合、このフィールドは目的の配信元を見つけるのに役立ちます。 |
| POP | プローブ要求を送信したエッジ PoP。 |
| 送信元の IP | 正常性プローブが送信された配信元の IP アドレス。 |
| TotalLatency | Azure Front Door エッジが正常性プローブ要求を配信元に送信した時点から、配信元が最後の応答を Azure Front Door に送信した時点までの時間。 |
| ConnectionLatency | HTTP プローブ要求を配信元に送信するための TCP 接続の設定にかかった時間。 |
| DNSResolution Latency | DNS 解決にかかった時間。 このフィールドに値があるのは、発信元が IP アドレスではなく FQDN になるように構成されている場合だけです。 配信元が 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 リソースに対して行われた操作に関する分析情報を提供します。 診断ログは、自分のリソースが実行する操作に関する分析情報を提供します。 詳細については、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
Note
さまざまなルーティング構成やトラフィック動作に対し、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 |
| 要求のエラー処理 | 該当なし |
Note
キャッシュのシナリオでは、要求のバイトの一部が 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 Monitor ツールを使用してデータを分析する
これらの Azure Monitor ツールは、監視データの分析に役立つ Azure portal で使用できます:
一部の Azure サービスには、Azure portal に監視ダッシュボードが組み込まれています。 これらのダッシュボードは、"分析情報" と呼ばれており、Azure portal の Azure Monitor の [分析情報] セクションにあります。
メトリックス エクスプローラーを使用すると、Azure リソースのメトリックを表示および分析できます。 詳細については、「Azure Monitor メトリック ス エクスプローラーを使用したメトリックの分析」を参照してください。
Log Analytics を使用すると、Kusto 照会言語 (KQL) を使用してログ データの照会と分析を行います。 詳細については、「Azure Monitor でログ クエリの使用を開始する」を参照してください。
Azure portal には、アクティビティ ログの表示と基本的な検索のためのユーザー インターフェイスがあります。 より詳細な分析を行うには、データを Azure Monitor ログにルーティングし、Log Analytics でより複雑なクエリを実行します。
Application Insights は Web アプリケーションの可用性、パフォーマンス、使用状況を監視するため、ユーザーの報告を待たずにエラーを特定して診断できます。
Application Insights にはさまざまな開発ツールへの接続ポイントが含まれており、DevOps プロセスをサポートする Visual Studio とも統合されています。 詳細については、「Azure App Service のアプリケーション監視」を参照してください。
より複雑な視覚化を可能にするツールは次のとおりです。
- ダッシュボードを使用すると、さまざまな種類のデータを組み合わせて、Azure portal 内の 1 つのペインに表示できます。
- ブック。Azure portal で作成できるカスタマイズ可能なレポート。 ブックには、テキスト、メトリック、ログ クエリを含めることができます。
- Grafana。運用ダッシュボードに優れたオープン プラットフォーム ツール。 Grafana を使用して、Azure Monitor 以外の複数のソースからのデータを含むダッシュボードを作成できます。
- Power BI。さまざまなデータ ソースにわたって対話型の視覚化を提供するビジネス分析サービス。 Azure Monitor からログ データを自動的にインポートするように Power BI を構成して、これらの視覚化を利用できます。
Azure Monitor データのエクスポート
次を使用して、Azure Monitor から他のツールにデータをエクスポートできます:
メトリック:メトリック用 REST API を使用して、Azure Monitor メトリック データベースからメトリック データを抽出します。 詳細については、Azure Monitor REST API のリファレンスをご覧ください。
ログ: REST API または関連するクライアント ライブラリを使用します。
Azure Monitor REST API の使用を開始するには、「Azure 監視 REST API のチュートリアル」を参照してください。
Kusto クエリを使用してログ データを分析する
Kusto 照会言語 (KQL) を使用して、Azure Monitor ログ データを分析できます。 詳細については、「Azure Monitor でのログ クエリ」を参照してください。
Azure Monitor アラートを使用して問題を通知する
Azure Monitor アラート、システム内の問題を特定して対処し、監視データに特定の条件が見つかった場合は、顧客が気付く前に事前に通知することができます。 Azure Monitor データ プラットフォームでは、任意のメトリックまたはログ データ ソースに対してアラートを生成できます。 監視対象のサービスと収集する監視データによって、さまざまな種類の Azure Monitor アラートがあります。 「適切な種類のアラート ルールを選ぶ」を参照してください。
Azure リソースに関する一般的なアラートの例については、ログ アラート クエリのサンプルに関するページをご覧ください。
大規模なアラートの実装
一部のサービスでは、同じ Azure リージョン内に存在する同じ種類の複数のリソースに同じメトリック警告ルールを適用することで、大規模に監視することができます。 Azure Monitor ベースライン アラート (AMBA) サイトには、重要なプラットフォーム メトリックのアラート、ダッシュボード、ガイドラインを大規模に実装するための半自動化された方法が用意されています。
Azure Advisor を使用してパーソナライズされたおすすめ候補を取得する
一部のサービスでは、リソースの操作中にクリティカルな条件や差し迫った変更が発生した場合は、ポータルのサービス [概要] ページにアラートが表示されます。 アラートの詳細と推奨される修正は、左側のメニューの [監視] の下の [アドバイザーのレコメンデーション] に表示されます。 通常の操作中、アドバイザーのレコメンデーションは表示されません。
Azure Advisor の詳細については、Azure Advisor の概要に関するページをご覧ください。