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

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

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

Дополнительные сведения о данных, собираемых для Брандмауэр Azure, и их использовании см. в Брандмауэр Azure мониторинга.

Metrics

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

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

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

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

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

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

  • Категория — группа метрик или классификация.
  • Metric - Название метрики, как оно отображается в портале Azure.
  • Имя в REST API — имя метрики, указанное в REST API.
  • Единица измерения.
  • Аггрегация - Тип агрегации по умолчанию. Допустимые значения: среднее (среднее), минимальное (минимальное), максимальное (максимальное), общее (сумма), число.
  • Измерения - Размеры, доступные для данной метрики.
  • Интервалы интервалов - времени, по которым выборка метрики выполняется. Например, указывает, PT1M что метрика выборка выполняется каждую минуту, каждые 30 минут, PT30MPT1H каждый час и т. д.
  • Экспорт DS— можно ли экспортировать метрики в журналы Azure Monitor с помощью параметров диагностики. Сведения об экспорте метрик см. в статье "Создание параметров диагностики" в 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		 ObservedCapacity Не определено Среднее, Минимум, Максимум <нет> PT1M Yes
Использование портов SNAT

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

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

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

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

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

  • Проверьте настройку предварительного масштабирования: Убедитесь, что брандмауэр постоянно поддерживает определенный minCapacity.
  • Отслеживание поведения масштабирования в режиме реального времени: Используйте агрегирование Avg для просмотра единиц емкости в режиме реального времени.
  • Прогноз будущих потребностей: Объедините историческую емкость с тенденциями трафика (например, ежемесячными пиками или сезонными событиями) для уточнения планирования емкости.
  • Настройка упреждающих оповещений: Настройте оповещения 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Note

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

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

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

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

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

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

    Снимок экрана: метрика Брандмауэр Azure пробы задержки.

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

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

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

  • Protocol
  • Reason
  • Status

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

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

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

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

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

 Yes Yes Queries Yes
AZFWApplicationRuleAggregation агрегирование сетевого правила Брандмауэр Azure (аналитика политик) AZFWApplicationRuleAggregation

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

 Yes Yes Yes
AZFWDnsAdditional Журнал трассировки потока DNS брандмауэра Azure AzureDiagnostics

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

 No No Queries Yes
AZFWDnsQuery Брандмауэр Azure DNS-запрос AZFWDnsQuery

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

 Yes Yes Queries Yes
AZFWFatFlow журнал потока жира Брандмауэр Azure AZFWFatFlow

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

 Yes Yes Queries Yes
AZFWFlowTrace Журнал трассировки потока Брандмауэр Azure AZFWFlowTrace

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

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

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

 Yes Yes Queries Yes
AZFWNatRule правило NAT Брандмауэр Azure AZFWNatRule

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

 Yes Yes Queries Yes
AZFWNatRuleAggregation агрегирование правил NAT Брандмауэр Azure (аналитика политик) AZFWNatRuleAggregation

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

 Yes Yes Yes
AZFWNetworkRule Правило сети службы "Брандмауэр Azure" AZFWNetworkRule

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

 Yes Yes Queries Yes
AZFWNetworkRuleAggregation агрегирование правил приложений Брандмауэр Azure (аналитика политик) AZFWNetworkRuleAggregation

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

 Yes Yes Yes
AZFWThreatIntel аналитика угроз Брандмауэр Azure AZFWThreatIntel

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

 Yes Yes Queries Yes
AzureFirewallApplicationRule правило приложения Брандмауэр Azure (устаревшая версия Диагностика Azure) AzureDiagnostics

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

 No No Queries No
AzureFirewallDnsProxy Брандмауэр Azure DNS-прокси (устаревшая версия Диагностика Azure) AzureDiagnostics

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

 No No Queries No
AzureFirewallNetworkRule сетевое правило Брандмауэр Azure (устаревшая версия Диагностика Azure) AzureDiagnostics

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

 No No Queries No

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

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

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

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

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

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

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

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

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

Схема, показывающая поток dns-запросов от клиента через брандмауэр Azure к внешнему DNS-серверу и обратно.

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

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

Включение журналов трассировки потока 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. Перейдите к параметрам DNS брандмауэра Azure и включите DNS-прокси.
    2. Настройте пользовательский DNS-сервер или используйте Azure DNS по умолчанию.
    3. Перейдите к параметрам DNS виртуальной сети и задайте частный IP-адрес брандмауэра в качестве основного DNS-сервера.

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

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

    Note

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

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

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

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

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

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

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

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

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

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

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

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

Tip

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

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

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

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

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

Tip

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

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

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

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

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

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

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

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

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

    • Пакет TCP приземляется в экземпляре Масштабируемые наборы виртуальных машин, который не имеет предыдущей истории для этого пакета.
    • Пакеты 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, чтобы изменения вступят в силу немедленно.

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

Чтобы проверить состояние регистрации 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

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

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

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

Брандмауэр Azure Microsoft.Network/azureFirewalls

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

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

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

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

  • Last updated on