Следите за Azure Front Door

Журналы фиксируют все запросы, проходящие через Azure Front Door. Для обработки и хранения журналов может потребоваться несколько минут.

Существует несколько журналов Front Door, которые можно использовать для различных целей:

• Журналы доступа можно использовать для выявления медленных запросов, определения частоты ошибок и понимания того, как поведение кэширования Front Door работает для вашего решения.
• Журналы брандмауэра веб-приложений (WAF) можно использовать для обнаружения потенциальных атак и ложных срабатываний, которые могут указывать на допустимые запросы, заблокированные WAF. Дополнительные сведения о журналах WAF см. в разделе Мониторинг и ведение журнала в Брандмауэре веб-приложений Azure.
• Журналы проверки работоспособности можно использовать для идентификации источников, которые являются неработоспособными или не отвечают на запросы от некоторых географически распределенных узлов присутствия Front Door.
• Журналы действий обеспечивают видимость операций, выполняемых в ресурсах Azure, таких как изменения конфигурации профиля Azure Front Door.

Журналы доступа и журналы WAF включают идентификатор отслеживания , который также передается в запросах к серверу-источнику и ответах клиенту с помощью заголовка X-Azure-Ref. Вы можете использовать идентификатор отслеживания, чтобы получить полное представление о процессе обработки ваших запросов в приложении.

По умолчанию журналы доступа, журналы проб работоспособности и журналы WAF не включены. Сведения о включении и хранении журналов диагностики см. в статье "Настройка журналов Azure Front Door". Записи этого журнала собираются по умолчанию, и их можно просмотреть на портале Azure.

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

Сведения о каждом запросе вошли в журнал доступа. Каждая запись журнала доступа содержит сведения, перечисленные в следующей таблице.

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

Azure Front Door регистрирует все неудачные запросы пробы работоспособности. Эти журналы могут помочь диагностировать проблемы с источником. Журналы предоставляют сведения, которые можно использовать для изучения причины сбоя, а затем вернуть источник в работоспособное состояние.

Ниже рассматриваются несколько сценариев, в которых будет полезен этот журнал.

• Вы заметили, что трафик Azure Front Door был отправлен в подмножество источников. Например, вы можете заметить, что только три из четырех источников получают трафик. Вы хотите знать, получают ли источники и отвечают на проверки состояния здоровья, чтобы вы знали, в норме ли источники.
• Вы заметили, что метрика процента работоспособности источника ниже, чем ожидалось. Вы хотите знать, какие источники фиксируются как неработоспособные и причина неудач проверки состояния.

Каждая запись журнала проб работоспособности имеет следующую схему:

В следующем примере фрагмент 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. Журналы диагностики предоставляют аналитические сведения об операциях, выполняемых вашим ресурсом. См. дополнительные сведения о журналах диагностики Azure Monitor.

Чтобы настроить журналы диагностики для Azure Front Door (классическая модель):

1. Выберите профиль Azure Front Door (классика).

2. Выберите Параметры диагностики.

3. Выберите Включить диагностику. Вы можете архивировать журналы диагностики и метрики в учетную запись хранения, передать их потоком в концентратор событий или отправить в журналы Azure Monitor.

В настоящее время Front Door предоставляет журналы диагностики. Журналы диагностики содержат сведения о каждом запросе к API со следующей схемой.

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

Свойство необработанного журнала isSentToOriginShield устарело и заменено новым полем IsReceivedFromClient. Используйте новое поле, если вы уже используете нерекомендуемое.

Необработанные логи включают в себя записи, созданные как на граничных серверах CDN (дочерних узлах POP), так и в системе защиты источника. Система Origin Shield относится к родительским узлам, которые стратегически расположены по всему миру. Эти узлы обмениваются данными с серверами-источниками и снижают нагрузку на эти серверы.

Для каждого запроса, который отправляется на оригинальный щит, есть две записи журнала.

• одна для граничных узлов;
• Один для щита происхождения

Чтобы отличить, пришел ли трафик или ответ через граничный узел или систему защиты сервера-источника, можно использовать поле isReceivedFromClient и получить таким образом верные данные.

Если значение ложь, это означает, что ответ на запрос передан с системы защиты источника на граничные узлы. Этот подход эффективен для сравнения необработанных журналов с данными о выставлении счетов. За исходящий трафик из системы защиты сервера-источника на граничные узлы плата не взимается. Плата взимается за исходящий трафик от граничных узлов к клиентам.

Пример запроса Kusto для исключения журналов, созданных в системе защиты сервера-источника в Log Analytics.

AzureDiagnostics | where Category == "FrontdoorAccessLog" and isReceivedFromClient_b == true

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, используется предварительная загрузка для запроса фрагментов с сервера-источника. В основе этой оптимизации лежит поддержка запросов диапазонов байт сервером-источником. Если сервер-источник не поддерживает запросы диапазонов байт, эта оптимизация будет неэффективной.