Поделиться через

Справочник по данным мониторинга Azure Firewall

В этой статье содержатся все справочные сведения о мониторинге для этой службы.

Дополнительные сведения о данных, которые можно собирать для Azure Firewall и как использовать, см. в Monitor Azure Firewall.

Metrics

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

Сведения о хранении метрик см. в разделе Azure Monitor обзор метрик.

Поддерживаемые метрики для Microsoft.Network/azureFirewalls

В следующей таблице перечислены метрики, доступные для типа ресурса Microsoft.Network/azureFirewalls.

  • Все столбцы могут не присутствовать в каждой таблице.
  • Некоторые столбцы могут находиться за пределами области просмотра страницы. Выберите "Развернуть таблицу ", чтобы просмотреть все доступные столбцы.

Заголовки таблиц

  • Категория — группа метрик или классификация.
  • Метрика — отображаемое имя метрик, отображаемое на портале Azure.
  • Имя в REST API — имя метрики, указанное в REST API.
  • Единица измерения.
  • Аггрегация - Тип агрегации по умолчанию. Допустимые значения: среднее (среднее), минимальное (минимальное), максимальное (максимальное), общее (сумма), число.
  • Измерения - Размеры, доступные для данной метрики.
  • Интервалы интервалов - времени, по которым выборка метрики выполняется. Например, указывает, PT1M что метрика выборка выполняется каждую минуту, каждые 30 минут, PT30MPT1H каждый час и т. д.
  • DS Export— можно ли экспортировать метрику в журналы Azure Monitor с помощью параметров диагностики. Сведения о экспорте метрик см. в разделе Create диагностических параметров в Azure Monitor.
Metric Имя в REST API Unit Aggregation Dimensions Гранулы времени Экспорт данных (DS)
Количество попаданий правил приложения

Число попаданий в правила приложения		 ApplicationRuleHit Count Сумма (Итог) Status, , ReasonProtocol PT1M Yes
Обработанные данные

Общий объем данных, обработанных этим брандмауэром		 DataProcessed Bytes Сумма (Итог) <нет> PT1M Yes
Состояние работоспособности брандмауэра

Указывает общую работоспособность этого брандмауэра		 FirewallHealth Percent Average Status, Reason PT1M Yes
Проба задержки (предварительная версия)

Оценка средней задержки брандмауэра по измерению пробы задержки		 FirewallLatencyPng Milliseconds Average <нет> PT1M Yes
Количество попаданий в правила сети

Число попаданий в сетевые правила		 NetworkRuleHit Count Сумма (Итог) Status, Reason PT1M Yes
Наблюдаемые единицы емкости

Сообщаемое количество единиц емкости для Azure Firewall		 ObservedCapacity Не определено Среднее, Минимум, Максимум <нет> PT1M Yes
Использование портов SNAT

Процент исходящих портов SNAT, используемых в данный момент		 SNATPortUtilization Percent Среднее, максимальное Protocol PT1M Yes
Throughput

Пропускная способность, обрабатываемая этим брандмауэром		 Throughput BitsPerSecond Average <нет> PT1M No

Наблюдаемая емкость

Метрика наблюдаемой емкости — это основное средство для понимания того, как брандмауэр масштабируется на практике.

Рекомендации по использованию наблюдаемой емкости

  • Проверьте настройку предварительного масштабирования: Убедитесь, что брандмауэр постоянно поддерживает определенный minCapacity.
  • Отслеживание поведения масштабирования в режиме реального времени: Используйте агрегирование Avg для просмотра единиц емкости в режиме реального времени.
  • Прогноз будущих потребностей: Объедините историческую емкость с тенденциями трафика (например, ежемесячными пиками или сезонными событиями) для уточнения планирования емкости.
  • Set упреждающих оповещений: Настройте оповещения Azure Monitor для пороговых значений наблюдаемой емкости (например, при масштабировании превышает 80% maxCapacity).
  • Коррелируете с метриками производительности: Связывание наблюдаемой емкости с пропускной способностью, пробой задержки и использованием портов SNAT для диагностики того, поддерживает ли масштабирование спрос.

Состояние работоспособности брандмауэра

В предыдущей таблице метрика состояния работоспособности брандмауэра имеет два измерения:

  • Состояние: возможные значения : "Работоспособные", " Деградированные", " Неработоспособные".
  • Причина: указывает на причину соответствующего состояния брандмауэра.

Если порты SNAT используются более 95%, они считаются исчерпанными, а работоспособность составляет 50% с состоянием=Понижение и причина=SNAT-порт. Брандмауэр сохраняет обработку трафика и существующие подключения не затрагиваются. Однако новые подключения могут не быть установлены периодически.

Если порты SNAT используются менее чем на 95 %, брандмауэр считается работоспособным и отображается уровень работоспособности 100 %.

Если сведения об использовании портов SNAT отсутствуют, отображается состояние работоспособности 0 %.

Использование портов SNAT

Для метрики использования портов SNAT при добавлении дополнительных общедоступных IP-адресов в брандмауэр доступны дополнительные порты SNAT, что снижает использование портов SNAT. Кроме того, при масштабировании брандмауэра по разным причинам (например, ЦП или пропускной способности) больше портов SNAT также становятся доступными.

Фактически этот процент использования портов SNAT может сократиться без добавления общедоступных IP-адресов, так как служба масштабируется. Вы можете напрямую контролировать количество общедоступных IP-адресов, доступных для увеличения портов, доступных в брандмауэре. Но вы не можете напрямую управлять масштабированием брандмауэра.

Если брандмауэр работает с исчерпанием портов SNAT, следует добавить по крайней мере пять общедоступных IP-адресов. Это увеличивает количество доступных портов SNAT. Дополнительные сведения см. в разделе Azure Firewall функции.

Проверка задержки AZFW

Метрика пробы задержки AZFW измеряет общую или среднюю задержку Azure Firewall в миллисекундах. Администраторы могут использовать эту метрику в следующих целях:

  • Диагностика того, вызывает ли Azure Firewall задержку в сети
  • Мониторинг и оповещение о задержках или проблемах с производительностью, поэтому ИТ-группы могут активно взаимодействовать
  • Определите различные факторы, которые могут вызвать высокую задержку в Azure Firewall, такие как высокая загрузка ЦП, высокая пропускная способность или проблемы с сетью

Метрики метрики пробы задержки AZFW

  • Measures: Задержка Azure Firewall на платформе Azure
  • Не измеряется: Сквозная задержка для всего сетевого пути. Метрика отражает производительность брандмауэра, а не задержку, Azure Firewall вводится в сеть.
  • Отчеты об ошибках: Если метрика задержки не работает правильно, она сообщает значение 0 на панели мониторинга метрик, указывающее на сбой пробы или прерывание.

Факторы, влияющие на задержку

Несколько факторов могут повлиять на задержку брандмауэра:

  • Высокая загрузка ЦП.
  • Высокая пропускная способность или загрузка трафика
  • Проблемы с сетью на платформе Azure

Пробы задержки: от ICMP до TCP

В настоящее время проба задержки использует технологию сетки связи Майкрософт, которая основана на ICMP (протокол сообщения управления интернетом). ICMP подходит для быстрых проверок работоспособности, таких как запросы на проверку связи, но это может не точно представлять реальный трафик приложения, который обычно использует TCP. Однако пробы ICMP определяют приоритеты по-разному на Azure платформе, что может привести к изменению номеров SKU. Чтобы уменьшить эти несоответствия, Azure Firewall планирует перейти на пробы на основе TCP.

Важные вопросы:

  • Пики задержки: При использовании проб ICMP периодические пики являются нормальными и частью стандартного поведения сети узла. Не используйте эти пики в качестве проблем брандмауэра, если они не сохраняются.
  • задержка Average: В среднем задержка Azure Firewall диапазоны от 1 мс до 10 мс в зависимости от SKU брандмауэра и размера развертывания.

Рекомендации по мониторингу задержки

  • Задайте базовый план: установите базовые показатели задержки в условиях легкого трафика для точного сравнения при обычном или пиковом использовании.

    Note

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

  • Мониторинг шаблонов: ожидайте случайные пики задержки в рамках обычных операций. Если высокая задержка сохраняется за пределами этих нормальных вариаций, это может указывать на более глубокую проблему, требующую исследования.

  • Рекомендуемое пороговое значение задержки. Рекомендуемая рекомендация заключается в том, что задержка не должна превышать 3x базовых показателей. Если это пороговое значение пересекается, рекомендуется дальнейшее исследование.

  • Проверьте ограничение правила: убедитесь, что правила сети находятся в пределах ограничения правила 20K. Превышение этого ограничения может повлиять на производительность.

  • Подключение нового приложения: проверьте наличие новых подключенных приложений, которые могут быть добавлены значительные нагрузки или вызывают проблемы с задержкой.

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

    Screenshot Azure Firewall с метрикой metric.

Метрические размеры

Дополнительные сведения о измерениях метрик см. в разделе "Многомерные метрики".

Эта служба имеет следующие измерения, связанные с ее метриками.

  • Protocol
  • Reason
  • Status

Журналы ресурсов

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

Поддерживаемые журналы ресурсов для Microsoft.Network/azureFirewalls

Category Отображаемое имя категории таблица логов Поддерживает базовый план журнала Поддерживает преобразование времени приема Примеры запросов Затраты на экспорт
AZFWApplicationRule Правило приложения Azure Firewall AZFWApplicationRule

Содержит все данные журнала правил приложения. Каждое совпадение между плоскостью данных и правилом приложения приводит к созданию записи журнала с пакетом плоскости данных и атрибутами соответствующего правила.

 Yes Yes Queries Yes
AZFWApplicationRuleAggregation агрегирование правил приложений Azure Firewall (аналитика политик) AZFWApplicationRuleAggregation

Содержит агрегированные данные журнала правил приложений для Аналитики политик.

 Yes Yes Yes
AZFWDnsAdditional Azure Firewall журнал трассировки потока DNS AZFWDnsFlowTrace

Содержит все данные прокси-сервера DNS между клиентом, брандмауэром и DNS-сервером.

 Yes No Yes
AZFWDnsQuery Azure Firewall DNS-запрос AZFWDnsQuery

Содержит все данные журнала событий DNS-прокси.

 Yes Yes Queries Yes
AZFWFatFlow журнал потока жира Azure Firewall AZFWFatFlow

Этот запрос возвращает верхние потоки между Azure Firewall экземплярами. Журнал содержит сведения о потоке, скорость передачи дат (в мегабитах в секунду) и период времени записи потоков. Следуйте инструкциям в документации, чтобы включить ведение журнала Top flow и подробности о том, как осуществляется запись.

 Yes Yes Queries Yes
AZFWFlowTrace журнал трассировки потока Azure Firewall AZFWFlowTrace

Журналы потоков между экземплярами Azure Firewall. Журнал содержит сведения о потоке, флаги и период времени записи потоков. Следуйте документации, чтобы включить ведение журнала трассировки потока и подробные сведения о том, как она записывается.

 Yes Yes Queries Yes
AZFWFqdnResolveFailure Сбой разрешения полного доменного имени Azure Firewall No No Yes
AZFWIdpsSignature подпись idPS Azure Firewall AZFWIdpsSignature

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

 Yes Yes Queries Yes
AZFWNatRule правило NAT Azure Firewall AZFWNatRule

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

 Yes Yes Queries Yes
AZFWNatRuleAggregation агрегирование правил NAT Azure Firewall (аналитика политик) AZFWNatRuleAggregation

Содержит агрегированные данные журнала правил NAT для Аналитики политик.

 Yes Yes Yes
AZFWNetworkRule сетевое правило Azure Firewall AZFWNetworkRule

Содержит все данные журнала правил сети. Каждое совпадение между плоскостью данных и правилом сети приводит к созданию записи журнала с пакетом плоскости данных и атрибутами соответствующего правила.

 Yes Yes Queries Yes
AZFWNetworkRuleAggregation агрегирование сетевого правила Azure Firewall (аналитика политик) AZFWNetworkRuleAggregation

Содержит агрегированные данные журнала правил сети для анализа политики.

 Yes Yes Yes
AZFWThreatIntel аналитика угроз Azure Firewall AZFWThreatIntel

Содержит все события аналитики угроз.

 Yes Yes Queries Yes
AzureFirewallApplicationRule правило приложения Azure Firewall (устаревшая версия Azure Diagnostics) AzureDiagnostics

Журналы из нескольких ресурсов Azure.

 No No Queries No
AzureFirewallDnsProxy Azure Firewall DNS-прокси (устаревшая Azure Diagnostics) AzureDiagnostics

Журналы из нескольких ресурсов Azure.

 No No Queries No
AzureFirewallNetworkRule сетевое правило Azure Firewall (устаревшая версия Azure Diagnostics) AzureDiagnostics

Журналы из нескольких ресурсов Azure.

 No No Queries No

Журналы трассировки потока DNS

Журналы трассировки потока DNS обеспечивают более глубокую видимость действий DNS, помогая администраторам устранять проблемы с решением и проверять поведение трафика.

Ранее ведение журнала DNS-прокси было ограничено следующими способами:

  • AZFWDNSQuery — исходный запрос клиента
  • AZFWInternalFqdnResolutionFailure — сбои разрешения FQDN

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

Этапы разрешения DNS

Журналы записывают следующие этапы:

  1. Клиентский запрос: исходный DNS-запрос, отправленный клиентом
  2. Forwarder query: Azure Firewall перенаправление запроса на внешний DNS-сервер (если он не кэширован)
  3. ответ Forwarder: ответ DNS-сервера на Azure Firewall
  4. ответ Client: окончательный разрешенный ответ от Azure Firewall обратно клиенту

На следующей схеме показано высокоуровневое визуальное представление потока запросов DNS:

Diagram с потоком ЗАПРОСОВ DNS от клиента через Azure Firewall на внешний DNS-сервер и back.

Эти журналы предоставляют ценные аналитические сведения, такие как:

  • Dns-сервер запрашивается
  • Разрешенные IP-адреса
  • Используется ли кэш Azure Firewall

Включение журналов трассировки потока DNS

Перед настройкой журналов трассировки потока DNS необходимо сначала включить функцию с помощью Azure PowerShell.

Включение журналов (предварительные требования)

Выполните следующие команды в Azure PowerShell, заменив заполнители значениями:

Set-AzContext -SubscriptionName <SubscriptionName>
$firewall = Get-AzFirewall -ResourceGroupName <ResourceGroupName> -Name <FirewallName>
$firewall.EnableDnstapLogging = $true
Set-AzFirewall -AzureFirewall $firewall

Отключение журналов (необязательно)

Чтобы отключить журналы, используйте ту же предыдущую команду Azure PowerShell и задайте значение False:

Set-AzContext -SubscriptionName <SubscriptionName>
$firewall = Get-AzFirewall -ResourceGroupName <ResourceGroupName> -Name <FirewallName>
$firewall.EnableDnstapLogging = $false
Set-AzFirewall -AzureFirewall $firewall

Настройка журналов трассировки потока DNS и прокси-сервера DNS

Чтобы настроить DNS-прокси и включить журналы трассировки потока DNS, выполните следующие действия.

  1. Включите DNS-прокси:

    1. Перейдите к Azure Firewall параметрам DNS и включите DNS-прокси.
    2. Настройте пользовательский DNS-сервер или используйте Azure DNS по умолчанию.
    3. Перейдите к Virtual Network параметрам DNS и задайте частный IP-адрес брандмауэра в качестве основного DNS-сервера.

  2. Включите журналы трассировки потока DNS:

    1. Перейдите к Azure Firewall на портале Azure.
    2. Выберите параметры диагностики в разделе "Мониторинг".
    3. Выберите существующий параметр диагностики или создайте новую.
    4. В разделе "Журнал" выберите журналы трассировки потока DNS.
    5. Выберите нужное место назначения (Log Analytics или учетную запись хранения).

    Note

    DNS Flow Trace Logs не поддерживаются с Event Hub в качестве назначения.

    1. Сохранить параметры.

  3. Проверьте конфигурацию:

    1. Создайте запросы DNS от клиентов и проверьте журналы в выбранном месте назначения.

Общие сведения о журналах

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

Тип Description Поля ключа
Client Query Исходный DNS-запрос, отправленный клиентом. SourceIp: внутренний IP-адрес клиента, выполняющего DNS-запрос, QueryMessage: полная полезные данные DNS-запроса, включая запрошенный домен.
Forwarder Query Azure Firewall перенаправление DNS-запроса на внешний DNS-сервер (если он не кэширован). ServerIp: IP-адрес внешнего DNS-сервера, получающего запрос, QueryMessage: полезные данные перенаправленного DNS-запроса, идентичные или на основе клиентского запроса.
Forwarder Response Ответ DNS-сервера на Azure Firewall. ServerMessage: полезные данные ответа DNS с внешнего сервера. AnswerSectionСодержит разрешенные IP-адреса, CNAMEs и любые результаты проверки DNSSEC (если это применимо).
Client Response Окончательный разрешенный ответ от Azure Firewall обратно клиенту. ResolvedIp: IP-адрес (или адреса), разрешенные для запрашиваемого домена.: ResponseTimeобщее время, затраченное на разрешение запроса, измеряемое из запроса клиента на возвращаемый ответ.

Приведенные выше поля — это только подмножество доступных полей в каждой записи журнала.

Важные примечания:

  • Если используется кэш DNS, создаются только записи запроса клиента и ответа клиента .
  • Журналы включают стандартные метаданные, такие как метки времени, ip-адреса источника и назначения, протоколы и содержимое сообщения DNS.
  • Чтобы избежать чрезмерного объема журналов в средах с большим количеством коротких запросов, включите дополнительные журналы DNS-прокси, только если требуется более глубокое устранение неполадок DNS.

Верхние потоки

Журнал основных потоков известен в отрасли как журнал потоков fat flow log и в предыдущей таблице как Azure Firewall журнал потока жира. В журнале верхних потоков отображаются верхние подключения, которые способствуют максимальной пропускной способности через брандмауэр.

Tip

Активируйте журналы верхних потоков только при устранении конкретной проблемы, чтобы избежать чрезмерного использования ЦП Azure Firewall.

Скорость потока определяется как скорость передачи данных в мегабитах в секунду. Это мера объема цифровых данных, которые могут передаваться по сети за период времени через брандмауэр. Протокол Top Flows периодически выполняется каждые три минуты. Минимальное пороговое значение для рассмотрения верхнего потока — 1 Мбит/с.

Включение журналов основных потоков

Используйте следующие команды Azure PowerShell, чтобы включить журналы основных потоков:

Set-AzContext -SubscriptionName <SubscriptionName>
$firewall = Get-AzFirewall -ResourceGroupName <ResourceGroupName> -Name <FirewallName>
$firewall.EnableFatFlowLogging = $true
Set-AzFirewall -AzureFirewall $firewall

Отключение журналов верхних потоков

Чтобы отключить журналы, используйте ту же команду Azure PowerShell и задайте значение False. Рассмотрим пример.

Set-AzContext -SubscriptionName <SubscriptionName>
$firewall = Get-AzFirewall -ResourceGroupName <ResourceGroupName> -Name <FirewallName>
$firewall.EnableFatFlowLogging = $false
Set-AzFirewall -AzureFirewall $firewall

Проверка конфигурации

Существует несколько способов проверить успешность обновления. Перейдите к обзору брандмауэра и выберите представление JSON в правом верхнем углу. Ниже приведен пример:

Снимок экрана: JSON с дополнительной проверкой журнала.

Сведения о создании параметра диагностики и включении таблицы для конкретных ресурсов см. в разделе Create диагностических параметров в Azure Monitor.

Трассировка потока

Журналы брандмауэра показывают трафик через брандмауэр в первой попытке TCP-подключения, известного как пакет SYN . Однако такая запись не показывает полного пути передачи пакета в подтверждения TCP. В результате сложно устранить неполадки, если пакет удален или асимметричная маршрутизация. Журнал трассировки потока Azure Firewall решает эту проблему.

Tip

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

Свойства трассировки потока

Можно добавить следующие свойства:

  • SYN-ACK: флаг ACK, указывающий подтверждение пакета SYN.

  • FIN: завершен флаг исходного потока пакетов. В потоке TCP больше не передаются данные.

  • FIN-ACK: флаг ACK, указывающий подтверждение пакета FIN.

  • RST: флаг сброса указывает, что исходный отправитель не получает больше данных.

  • INVALID (потоки): указывает, что пакет не может быть идентифицирован или не имеет состояния.

    Рассмотрим пример.

    • Пакет TCP приземляется на экземпляре Virtual Machine Scale Sets, который не имеет предыдущей истории для этого пакета.
    • Пакеты Bad CheckSum
    • Запись таблицы отслеживания подключений заполнена, а новые подключения не могут быть приняты
    • Чрезмерно отложенные пакеты ACK

Включение журналов трассировки потока

Используйте следующие команды Azure PowerShell, чтобы включить журналы трассировки потока. Кроме того, перейдите на портал и найдите включение ведения журнала tcp-подключений:

Connect-AzAccount 
Select-AzSubscription -Subscription <subscription_id> or <subscription_name>
Register-AzProviderFeature -FeatureName AFWEnableTcpConnectionLogging -ProviderNamespace Microsoft.Network
Register-AzResourceProvider -ProviderNamespace Microsoft.Network

Это изменение может занять несколько минут. После регистрации функции рассмотрите возможность немедленного выполнения обновления Azure Firewall изменения.

Проверка состояния регистрации

Чтобы проверить состояние регистрации AzResourceProvider, выполните следующую команду Azure PowerShell:

Get-AzProviderFeature -FeatureName "AFWEnableTcpConnectionLogging" -ProviderNamespace "Microsoft.Network"

Отключение журналов трассировки потока

Чтобы отключить журнал, используйте следующие команды Azure PowerShell:

Connect-AzAccount 
Select-AzSubscription -Subscription <subscription_id> or <subscription_name>
$firewall = Get-AzFirewall -ResourceGroupName <ResourceGroupName> -Name <FirewallName>
$firewall.EnableTcpConnectionLogging = $false
Set-AzFirewall -AzureFirewall $firewall

Сведения о создании параметра диагностики и включении таблицы для конкретных ресурсов см. в разделе Create диагностических параметров в Azure Monitor.

таблицы журналов Azure Monitor

В этом разделе перечислены таблицы журналов Azure Monitor, относящиеся к этой службе, которые доступны для запроса Log Analytics с помощью запросов Kusto. Таблицы содержат данные журнала ресурсов и, возможно, больше в зависимости от собираемых и перенаправленных к ним данных.

Azure Firewall Microsoft.Network/azureFirewalls

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

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

Дополнительные сведения о схеме записей журнала действий см . в схеме журнала действий.

Связанный контент

  • Last updated on