Мониторинг метрик и журналов в Azure Front Door

Статья
12/19/2023

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, вычисляемый по общему трафику исходящего трафика. Соотношение попаданий байтов низко, если большая часть трафика пересылается в источник, а не обслуживается из кэша. Коэффициент попаданий байт в кэш = (объем исходящего трафика с граничного узла — объем исходящего трафика с сервера-источника)/объем исходящего трафика с граничного узла. Сценарии, исключенные из вычислений коэффициента попадания байтов: Вы явным образом отключаете кэширование с помощью обработчика правил или кэширования строк запроса. Вы явно настраиваете `Cache-Control` директиву с `no-store` помощью директив или `private` кэша.	Конечная точка
Origin Health Percentage	Процент успешных проб работоспособности, отправленных из Azure Front Door в источники.	Источник, группа источников
Origin Latency	Azure Front Door вычисляет время отправки запроса в источник до получения последнего байта ответа из источника.	Конечная точка, источник
Origin Request Count	Количество запросов, отправленных из Azure Front Door в источники.	Конечная точка, источник, состояние HTTP, группа состояния HTTP
Percentage of 4XX	Процент всех клиентских запросов, для которых код состояния отклика — 4XX.	Конечная точка, страна клиента, регион клиента
Percentage of 5XX	Процент всех клиентских запросов, для которых код состояния отклика — 5XX.	Конечная точка, страна клиента, регион клиента
Число запросов	Количество клиентских запросов, обслуживаемых через Azure Front Door, включая запросы, обслуживаемых полностью из кэша.	Конечная точка, страна клиента, регион клиента, состояние HTTP, группа состояния HTTP
Размер запроса	Количество байтов, отправленных клиентами в Azure Front Door.	Конечная точка, страна клиента, регион клиента, состояние HTTP, группа состояния HTTP
Размер ответа	Число байт, отправленных клиентам в качестве ответов из службы Front Door.	Конечная точка, страна клиента, регион клиента, состояние HTTP, группа состояния HTTP
Total Latency (Общая задержка)	Azure Front Door получает запрос клиента и отправляет последний байт ответа клиенту. Это общее время.	Конечная точка, страна клиента, регион клиента, состояние HTTP, группа состояния HTTP
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. Возможные значения: HIT и REMOTE_HIT: HTTP-запрос был обработан из кэша Azure Front Door. MISS — HTTP-запрос был обработан в оригинальном виде. PARTIAL_HIT: некоторые из байтов обслуживались из кэша PoP Front Door edge, а другие байты обслуживались из источника. Это состояние указывает на сценарий фрагментирования объектов. CACHE_NOCONFIG. Запрос был перенаправлен без кэширования параметров, включая сценарии обхода. PRIVATE_NOSTORE. В параметрах кэширования клиентом не было настроен кэша. N/A: запрос был отклонен подписанным URL-адресом или обработчиком правил.
MatchedRulesSetName	Имена правил обработчика правил, которые были обработаны.
Имя маршрута	Имя маршрута, которому соответствует запрос.
ClientPort	IP-порт клиента, отправившего запрос.
Referrer	URL-адрес сайта, откуда исходит запрос.
TimetoFirstByte	Продолжительность времени в секундах, от момента, когда край Azure Front Door получил запрос до момента, когда первый байт был отправлен клиенту, как измеряется Azure Front Door. Это свойство не учитывает данные клиента.
ErrorInfo	Если во время обработки запроса произошла ошибка, это поле содержит подробные сведения об ошибке. Возможные значения: NoError: ошибок не обнаружено. CertificateError: общая ошибка SSL-сертификата. CertificateNameCheckFailed: имя узла в SSL-сертификате недопустимо или не соответствует запрошенным URL-адресу. ClientDisconnected: сбой запроса из-за проблемы с подключением к сети клиента. ClientGeoBlocked: клиент был заблокирован из-за географического расположения IP-адреса. UnspecifiedClientError — общая ошибка на стороне клиента. InvalidRequest — недопустимый запрос. Этот ответ указывает на неправильный заголовок, текст или URL-адрес. DNSFailure: произошел сбой во время разрешения DNS. DNSTimeout: DNS-запрос для разрешения времени ожидания исходного IP-адреса. DNSNameNotResolved — не удалось разрешить имя или адрес сервера. OriginConnectionAborted — соединение с источником прервано из-за сбоя. OriginConnectionAborted — общая ошибка подключения к источнику. OriginConnectionRefused — соединение с источником не было установлено. OriginError — общая ошибка на стороне источника. ResponseHeaderTooBig — источник вернул слишком длинный заголовок ответа. OriginInvalidResponse: источник вернул недопустимый или нераспознанный ответ. OriginTimeout: срок ожидания для запроса источника истек. ResponseHeaderTooBig — источник вернул слишком длинный заголовок ответа. RestrictedIP: запрос был заблокирован из-за ограниченного IP-адреса. SSLHandshakeError: Azure Front Door не удалось установить соединение с источником из-за сбоя подтверждения SSL. SSLInvalidRootCA: сертификат корневого центра сертификации недопустим. SSLInvalidCipher: подключение HTTPS было установлено с помощью недопустимого шифра. OriginConnectionAborted — соединение с источником прервано из-за сбоя. OriginConnectionRefused — соединение с источником не было установлено. UnspecifiedError — произошла ошибка, которая не включена в эту таблицу.
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/27CAFCA8-B9A4-4264-B399-45D0C9CCA1AB/RESOURCEGROUPS/AFDXPRIVATEPREVIEW/PROVIDERS/MICROSOFT.CDN/PROFILES/AFDXPRIVATEPREVIEW-JESSIE",
      "category": "FrontDoorHealthProbeLog",
      "operationName": "Microsoft.Cdn/Profiles/FrontDoorHealthProbeLog/Write",
      "properties": {
        "healthProbeId": "9642AEA07BA64675A0A7AD214ACF746E",
        "POP": "MAA",
        "httpVerb": "HEAD",
        "result": "OriginError",
        "httpStatusCode": "400",
        "probeURL": "http://afdxprivatepreview.blob.core.windows.net:80/",
        "originName": "afdxprivatepreview.blob.core.windows.net",
        "originIP": "52.239.224.228:80",
        "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	Отображаемое имя метрики	Unit	Измерения	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. DNSNameNotResolved — не удалось разрешить имя или адрес сервера. OriginConnectionAborted — подключение к источнику было внезапно остановлено. OriginConnectionAborted — общая ошибка подключения к источнику. OriginConnectionRefused — не удалось установить подключение к источнику. OriginError — общая ошибка на стороне источника. OriginError — источник вернул недопустимый или нераспознанный ответ. OriginTimeout — истек срок ожидания ответа от источника. ResponseHeaderTooBig — источник вернул слишком длинный заголовок ответа. RestrictedIP — запрос был заблокирован по причине ограничения IP-адреса. SSLHandshakeError — не удалось установить подключение к источнику по причине сбоя рукопожатия SSL. UnspecifiedError — произошла ошибка, которая не включена в эту таблицу. 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 отсутствуют некоторые фрагменты файла, запрошенные недостающие фрагменты будут предварительно загружены с сервера-источника. В основе этой оптимизации лежит поддержка запросов диапазонов байт сервером-источником. Если сервер-источник не поддерживает запросы диапазонов байт, эта оптимизация будет неэффективной.

Следующие шаги

Узнайте, как создать профиль Azure Front Door (классическая модель).
Узнайте, как работает Azure Front Door (классическая модель)

Мониторинг метрик и журналов в Azure Front Door

Метрики

Журналы

журнал доступа;

Журнал проверки работоспособности

Журнал брандмауэра веб-приложения

Журналы действий

Следующие шаги

Метрики

Журналы действий

Журналы диагностики

Свойство "Отправлено на защиту источника" больше не поддерживается

Следующие шаги

Дополнительные ресурсы