Мониторинг метрик и журналов в Azure Front Door
Azure Front Door предоставляет несколько функций для мониторинга приложения, отслеживания запросов и отладки конфигурации Front Door.
Журналы и метрики хранятся и управляются Azure Monitor.
Отчеты содержат сведения о том, как трафик проходит через Azure Front Door, брандмауэр веб-приложения (WAF) и приложение.
Метрики
Служба Azure Front Door измеряет и отправляет свои метрики с 60-секундным интервалом. Метрики могут занять до 3 минут, чтобы получить обработку Azure Monitor, и они могут не отображаться до завершения обработки. Метрики также могут отображаться в диаграммах или сетках и доступны через портал Azure, Azure PowerShell, Azure CLI и API Azure Monitor. Дополнительные сведения см. в статье Обзор метрик в Microsoft Azure.
Метрики, перечисленные в следующей таблице, записываются и хранятся бесплатно в течение ограниченного периода времени. Для дополнительной стоимости можно хранить в течение более длительного периода времени.
| Показатели | Description | Измерения | Рекомендуемые агрегаты |
|---|---|---|---|
| Byte Hit Ratio | Процент трафика, который был обработан из кэша Azure Front Door, вычисляемый по общему трафику исходящего трафика. Соотношение попаданий байтов низко, если большая часть трафика пересылается в источник, а не обслуживается из кэша. Коэффициент попаданий байт в кэш = (объем исходящего трафика с граничного узла — объем исходящего трафика с сервера-источника)/объем исходящего трафика с граничного узла. Сценарии, исключенные из вычислений коэффициента попадания байтов:
|
Конечная точка | Среднее, Мин |
| Origin Health Percentage | Процент успешных проб работоспособности, отправленных из Azure Front Door в источники. | Источник, группа источников | Ср. |
| Origin Latency | Azure Front Door вычисляет время отправки запроса в источник до получения последнего байта ответа из источника. | Конечная точка, источник | Avg, Max |
| Origin Request Count | Количество запросов, отправленных из Azure Front Door в источники. | Конечная точка, источник, состояние HTTP, группа состояния HTTP | Среднее, сумма |
| Percentage of 4XX | Процент всех клиентских запросов, для которых код состояния отклика — 4XX. | Конечная точка, страна клиента, регион клиента | Avg, Max |
| Percentage of 5XX | Процент всех клиентских запросов, для которых код состояния отклика — 5XX. | Конечная точка, страна клиента, регион клиента | Avg, Max |
| Число запросов | Количество клиентских запросов, обслуживаемых через Azure Front Door, включая запросы, обслуживаемых полностью из кэша. | Конечная точка, страна клиента, регион клиента, состояние HTTP, группа состояния HTTP | Среднее, сумма |
| Размер запроса | Количество байтов, отправленных клиентами в Azure Front Door. | Конечная точка, страна клиента, регион клиента, состояние HTTP, группа состояния HTTP | Avg, Max |
| Размер ответа | Число байт, отправленных клиентам в качестве ответов из службы Front Door. | Конечная точка, страна клиента, регион клиента, состояние HTTP, группа состояния HTTP | Avg, Max |
| Total Latency (Общая задержка) | Azure Front Door получает запрос клиента и отправляет последний байт ответа клиенту. Это общее время. | Конечная точка, страна клиента, регион клиента, состояние HTTP, группа состояния HTTP | Avg, Max |
| Web Application Firewall Request Count (Число запросов к брандмауэру веб-приложения) | Количество запросов, обработанных брандмауэром веб-приложения Azure Front Door. | Действие, имя политики, имя правила | Среднее, сумма |
Примечание.
Если запрос к источнику истекает, значение измерения состояния Http равно 0.
Журналы
Журналы отслеживают все запросы, проходящие через Azure Front Door. Для обработки и хранения журналов может потребоваться несколько минут.
Существует несколько журналов Front Door, которые можно использовать для различных целей:
- Журналы доступа можно использовать для выявления медленных запросов, определения частоты ошибок и понимания того, как поведение кэширования Front Door работает для вашего решения.
- Журналы брандмауэра веб-приложений (WAF) можно использовать для обнаружения потенциальных атак и ложных срабатываний, которые могут указывать на допустимые запросы, заблокированные WAF. Дополнительные сведения о журналах WAF см. в статье Azure Брандмауэр веб-приложений мониторинга и ведения журнала.
- Журналы проб работоспособности можно использовать для идентификации источников, которые являются неработоспособными или не отвечают на запросы некоторых географически распределенных poPs Front Door.
- Журналы действий обеспечивают видимость операций, выполняемых в ресурсах Azure, таких как изменения конфигурации профиля Azure Front Door.
Журналы доступа и журналы WAF включают ссылку на отслеживание, которая также распространяется в запросах на источники и ответы клиента с помощью заголовкаX-Azure-Ref. Вы можете использовать ссылку на отслеживание для получения комплексного представления обработки запросов приложения.
По умолчанию журналы доступа, журналы проб работоспособности и журналы WAF не включены. Сведения о включении и хранении журналов диагностики см. в статье "Настройка журналов Azure Front Door". Записи этого журнала собираются по умолчанию, и их можно просмотреть на портале Azure.
журнал доступа;
Сведения о каждом запросе вошли в журнал доступа. Каждая запись журнала доступа содержит сведения, перечисленные в следующей таблице.
| Свойство | Description |
|---|---|
| TrackingReference | Уникальная строка ссылки, которая идентифицирует запрос, обслуженный Azure Front Door. Ссылка на отслеживание отправляется клиенту и источнику с помощью X-Azure-Ref заголовков. Используйте ссылку на отслеживание при поиске определенного запроса в журналах доступа или WAF. |
| Время | Дата и время, когда пограничный сервер 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 | IP-адрес прямого подключения к пограничному краю Azure Front Door. Если клиент для отправки запроса использовал прокси-сервер 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, это поле указывает шифр TLS/SSL, согласованный клиентом и Azure Front Door. |
| Конечная точка | Доменное имя конечной точки Azure Front Door, например contoso-123.z01.azurefd.net. |
| HttpStatusCode | Код состояния HTTP, полученный от Azure Front Door. Если время ожидания запроса к источнику истекло, значение поля HttpStatusCode равно 0. Если клиент закрыл подключение, значение поля HttpStatusCode равно 499. |
| Pop | Граничная точка присутствия Azure Front Door (PoP), которая ответила на запрос пользователя. |
| Состояние кэша | Как запрос был обработан кэшом Azure Front Door. Возможные значения:
|
| MatchedRulesSetName | Имена правил обработчика правил, которые были обработаны. |
| Имя маршрута | Имя маршрута, которому соответствует запрос. |
| 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 будут отклонены после 22 января 2024 г. |
| Sni | Это поле указывает указание имени сервера (SNI), которое отправляется во время подтверждения TLS/SSL. Его можно использовать для идентификации точного SSLMismatchedSNI значения SNI, если был код состояния. Кроме того, его можно сравнить со значением узла в requestUri поле для обнаружения и устранения проблемы несоответствия. |
Журнал проверки работоспособности
Azure Front Door регистрирует все неудачные запросы пробы работоспособности. Эти журналы помогают диагностировать проблемы с источником. Журналы предоставляют сведения, которые можно использовать для изучения причины сбоя, а затем вернуть источник в работоспособное состояние.
Ниже рассматриваются несколько сценариев, в которых будет полезен этот журнал.
- Вы заметили, что трафик Azure Front Door был отправлен в подмножество источников. Например, возможно, вы заметили, что только три из четырех источников получают трафик. Вы хотите знать, получают ли источники и отвечают на пробы работоспособности, чтобы вы знали, являются ли источники здоровыми.
- Вы заметили, что метрика процента работоспособности источника ниже, чем ожидалось. Вы хотите знать, какие источники записываются как неработоспособные и причина сбоев пробы работоспособности.
Каждая запись журнала проб работоспособности имеет следующую схему:
| Свойство | Description |
|---|---|
| HealthProbeId | Уникальный идентификатор для идентификации запроса пробы работоспособности. |
| Время | Дата и время отправки пробы работоспособности (в формате UTC). |
| HttpMethod | Метод HTTP, используемый запросом пробы работоспособности. Значения включают GET и HEAD на основе конфигурации пробы работоспособности. |
| Результат | Состояние пробы работоспособности. Значением является успешное или описание ошибки, полученной пробой. |
| HttpStatusCode | Код состояния HTTP, возвращаемый источником. |
| ProbeURL | Полный целевой URL-адрес, в который был отправлен запрос пробы. URL-адрес состоит из схемы, заголовка узла, пути и строки запроса. |
| OriginName | Имя источника, в который была отправлена проба работоспособности. Это поле помогает найти источники, интересующие вас, если источник настроен для использования полного доменного имени. |
| POP | Пограничный poP, отправляющий запрос пробы. |
| Исходный IP-адрес | IP-адрес источника, в который была отправлена проба работоспособности. |
| TotalLatency | Время, когда пограничный сервер Azure Front Door отправил запрос пробы работоспособности источнику, когда источник отправил последний ответ в Azure Front Door. |
| ConnectionLatency | Время, затраченное на настройку TCP-подключения для отправки запроса пробы HTTP в источник. |
| DNSResolution Latency | Время, затраченное на разрешение DNS. Это поле имеет только значение, если источник настроен на полное доменное имя вместо IP-адреса. Если источник настроен для использования 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"
}
}
]
}
Журнал брандмауэра веб-приложения
Дополнительные сведения о журналах брандмауэра веб-приложений Front Door (WAF) см. в статье azure Брандмауэр веб-приложений мониторинга и ведения журнала.
Журналы действий
Журналы действий содержат сведения об операциях управления в ресурсах Azure Front Door. В журналах содержатся сведения о каждой операции записи, выполняемой в ресурсе Azure Front Door, включая время выполнения операции, выполнение операции и операции.
Примечание.
Журналы действий не включают операции чтения. Они также могут не включать все операции, выполняемые с помощью портал Azure или классических API управления.
Дополнительные сведения см. в разделе "Просмотр журналов действий".
Следующие шаги
Сведения о включении и хранении журналов диагностики см. в статье "Настройка журналов Azure Front Door".
Внимание
Azure Front Door (классическая версия) будет прекращена 31 марта 2027 г. Чтобы избежать нарушений работы служб, важно перенести профили Azure Front Door (классический) на уровень Azure Front Door standard или Premium к марту 2027 года. Дополнительные сведения см. в статье azure Front Door (классическая версия) для выхода на пенсию.
С помощью Azure Front Door (классическая модель) можно отслеживать ресурсы следующим образом.
- Метрики. В настоящее время Azure Front Door имеет восемь метрик для просмотра счетчиков производительности.
- Журналы. Журналы действий и диагностики позволяют сохранять или использовать данные производительности, доступа и другие данные, относящиеся к ресурсу, чтобы отслеживать его состояние.
Метрики
Метрики — это функция определенных ресурсов Azure, позволяющая просматривать данные счетчиков производительности на портале. Ниже перечислены доступные метрики Front Door.
| Metric | Отображаемое имя метрики | Единица измерения | Измерения | Description |
|---|---|---|---|---|
| RequestCount | Число запросов | Count | HttpStatus HttpStatusGroup ClientRegion ClientCountry |
Число клиентских запросов, обслуженных службой Front Door. |
| RequestSize | Размер запроса | Байт | HttpStatus HttpStatusGroup ClientRegion ClientCountry |
Число байт, отправленных в качестве запросов от клиентов в службу Front Door. |
| ResponseSize | Размер ответа | Байт | HttpStatus HttpStatusGroup ClientRegion ClientCountry |
Число байт, отправленных клиентам в качестве ответов из службы Front Door. |
| TotalLatency | Total Latency (Общая задержка) | Миллисекунды | HttpStatus HttpStatusGroup ClientRegion ClientCountry |
Общее время, прошедшее с получения Front Door запроса клиента, до отправки последнего байта ответа из Front Door клиенту. |
| BackendRequestCount | Число запросов к серверному компоненту | Count | HttpStatus HttpStatusGroup Backend |
Число запросов, отправленных из службы Front Door к серверным частям. |
| BackendRequestLatency | Backend Request Latency (Задержка запросов к серверным частям) | Миллисекунды | Раздел | Время с момента отправки запроса службой Front Door к серверной части до получения Front Door последнего байта ответа от серверной части. |
| BackendHealthPercentage | Работоспособность серверного компонента (в процентах) | Процент | Backend BackendPool |
Процент успешных проб работоспособности от службы Front Door к серверным частям. |
| WebApplicationFirewallRequestCount | Web Application Firewall Request Count (Число запросов к брандмауэру веб-приложения) | Count | PolicyName RuleName Action |
Количество клиентских запросов, обрабатываемых механизмом безопасности на прикладном уровне службы Front Door. |
Журналы действий
Журналы действий содержат сведения об операциях, выполненных в профиле Azure Front Door (классическая модель). Они также определяют характер для любых операций записи (размещение, публикация или удаление), выполненных с профилем Azure Front Door (классическая модель).
Примечание.
Если запрос к источнику истекает, значение httpStatusCode равно 0.
Доступ к журналам действий осуществляется через Front Door или через все журналы ресурсов Azure в Azure Monitor. Чтобы просмотреть журналы действий, сделайте следующее:
Выберите имя экземпляра Front Door.
Выберите Журнал действий.
Выберите область действия фильтра и нажмите Применить.
Примечание.
В журналах действий не содержатся операции GET, а также операции, выполняемые через портал Azure или исходный API управления.
Журналы диагностики
Журналы диагностики предоставляют широкие сведения об операциях и ошибках, полезные для аудита и (или) устранения неполадок. Журналы диагностики отличаются от журналов действий.
Журналы действий позволяют анализировать операции, выполненные с ресурсами Azure. Журналы диагностики содержат аналитические сведения об операциях, выполняемых самим ресурсом. См. дополнительные сведения о журналах диагностики Azure Monitor.
Чтобы настроить журналы диагностики для Azure Front Door (классическая модель):
Выберите профиль Azure Front Door (классическая модель).
Выберите Параметры диагностики.
Выберите Включить диагностику. Вы можете архивировать журналы диагностики и метрики в учетную запись хранения, передать их потоком в концентратор событий или отправить в журналы Azure Monitor.
В настоящее время Front Door предоставляет журналы диагностики. Журналы диагностики содержат сведения о каждом запросе к API со следующей схемой.
| Свойство | Description |
|---|---|
| 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. DNSNameNotRe resolve: имя сервера или адрес не удалось разрешить. OriginConnectionAborted: связь с источником была остановлена резко. OriginConnectionError: ошибка подключения универсального источника. OriginConnectionRefused: соединение с источником не удалось установить. OriginError: ошибка универсального источника. OriginInvalidResponse: Источник вернул недопустимый или нераспознанный ответ. OriginTimeout: срок ожидания для запроса на источник истек. ResponseHeaderTooBig: источник вернул слишком большой заголовка ответа. RestrictedIP: запрос был заблокирован из-за ограниченного IP-адреса. SSLHandshakeError: не удается установить подключение к источнику из-за сбоя встряхивания ssl-рук. НеопределенныйError: произошла ошибка, которая не соответствовала ни одной из ошибок в таблице. SSLMismatchedSNI:Запрос был недопустим, так как заголовок HTTP-сообщения не совпадал со значением, представленным в расширении TLS SNI во время настройки подключения SSL/TLS. |
| Результат | SSLMismatchedSNI — это код состояния, который обозначает успешный запрос с предупреждением о несоответствии между SNI и заголовком узла. Этот код состояния подразумевает интерфейс домена, метод, который нарушает условия обслуживания Azure Front Door. Запросы с SSLMismatchedSNI будут отклонены после 22 января 2024 г. |
| Sni | Это поле указывает указание имени сервера (SNI), которое отправляется во время подтверждения TLS/SSL. Его можно использовать для идентификации точного SSLMismatchedSNI значения SNI, если был код состояния. Кроме того, его можно сравнить со значением узла в requestUri поле для обнаружения и устранения проблемы несоответствия. |
Свойство "Отправлено на защиту источника" больше не поддерживается
Свойство необработанного журнала isSentToOriginShield устарело и заменено новым полем IsReceivedFromClient. Используйте новое поле, если вы уже используете нерекомендуемое.
Необработанные журналы включают в себя журналы, созданные на граничном сервере CDN (дочерней точке POP) и в системе защиты сервера-источника. Система защиты сервера-источника ссылается на родительские узлы, которые стратегически расположены по всему миру. Эти узлы обмениваются данными с серверами-источниками и снижают нагрузку на эти серверы.
Для каждого запроса, который отправляется на экран источника, есть две записи журнала:
- одна для граничных узлов;
- одна для системы защиты сервера-источника.
Чтобы отличить, пришел ли трафик или ответ через граничный узел или систему защиты сервера-источника, можно использовать поле isReceivedFromClient и получить таким образом верные данные.
Значение False, означает, что ответ на запрос получен на граничных узлах из системы защиты сервера-источника. Этот подход эффективен для сравнения необработанных журналов с данными о выставлении счетов. За исходящий трафик из системы защиты сервера-источника на граничные узлы плата не взимается. Плата взимается за исходящий трафик от граничных узлов к клиентам.
Пример запроса Kusto для исключения журналов, созданных в системе защиты сервера-источника в Log Analytics.
AzureDiagnostics | where Category == "FrontdoorAccessLog" and isReceivedFromClient_b == true
Примечание.
Для различных конфигураций маршрутизации и поведений трафика некоторые поля, такие как backendHostname, cacheStatus, isReceivedFromClient и POP, могут отвечать различными значениями. В следующей таблице описаны различные значения этих полей для различных сценариев:
| Сценарии | Число записей в журнале | POP | BackendHostname | isReceivedFromClient | CacheStatus |
|---|---|---|---|---|---|
| Правило маршрутизации без включенного кэширования | 1 | Код POP граничного узла | Серверная часть, в которой был перенаправлен запрос | Истина | CONFIG_NOCACHE |
| Правило маршрутизации с включенным кэшированием. Попадание в кэше на POP граничного узла | 1 | Код POP граничного узла | Нет значения | Истина | HIT |
| Правило маршрутизации с включенным кэшированием. Промахи кэша на POP граничного узла, но попадания в кэше на POP родительского кэша | 2 | 1. Код POP граничного узла 2. Код POP родительского кэша |
1. Имя узла POP родительского кэша 2. Нет значения |
1. True 2. False |
1. MISS 2. HIT |
| Правило маршрутизации с включенным кэшированием. Промах кэша на POP граничного узла, но ЧАСТИЧНОЕ попадание на POP родительского кэша | 2 | 1. Код POP граничного узла 2. Код POP родительского кэша |
1. Имя узла POP родительского кэша 2. Серверная часть, которая помогает заполнять кэш |
1. True 2. False |
1. MISS 2. PARTIAL_HIT |
| Правило маршрутизации с включенным кэшированием. PARTIAL_HIT на POP граничного узла, но попадания в кэше на 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 |
| Произошла ошибка при обработке запроса | Неприменимо |
Примечание.
Для сценариев кэширования значение состояния кэша будет partial_hit, когда некоторые байты запроса обслуживаются из кэша защиты источника или граничного узла Azure Front Door, а другие — из источника для больших объектов.
Azure Front Door использует метод фрагментирования объекта. Когда запрашивается большой файл, Azure Front Door извлекает меньшие фрагменты файла из источника. Когда сервер POP Azure Front Door получит полный или частичный байтовый диапазон запрошенного файла, граничный сервер Azure Front Door будет запрашивать файл из источника фрагментами по 8 МБ.
Когда фрагмент поступает в граничный узел Azure Front Door, он кэшируется и немедленно отправляется пользователю. Одновременно с этим Azure Front Door предварительно загружает следующий фрагмент. Эта предварительная загрузка гарантирует, что всегда будет загружен следующий фрагмент содержимого (по сравнению с тем фрагментом, который просматривает пользователь), что позволяет снизить задержку. Этот процесс продолжается до тех пор, пока не будет скачан весь файл (если он запрашивался), пока не будут скачаны все запрошенные диапазоны байт (если они запрашивались) или пока клиент не завершит соединение. Дополнительные сведения о запросе диапазона байт см. в разделе RFC 7233. Azure Front Door кэширует все фрагменты по мере их получения. Весь файл не кэшируется в кэше Front Door. Последующие запросы файла или диапазонов байтов обслуживаются из кэша Azure Front Door. Если в Azure Front Door отсутствуют некоторые фрагменты файла, запрошенные недостающие фрагменты будут предварительно загружены с сервера-источника. В основе этой оптимизации лежит поддержка запросов диапазонов байт сервером-источником. Если сервер-источник не поддерживает запросы диапазонов байт, эта оптимизация будет неэффективной.