Referencia de datos de supervisión de Azure Firewall

Este artículo contiene toda la información de referencia de supervisión de este servicio.

Consulte Supervisión de Azure Firewall para más información sobre los datos que puede recopilar para Azure Firewall y cómo usarlo.

Metrics

En esta sección se indican todas las métricas de la plataforma recopiladas automáticamente para este servicio. Estas métricas también forman parte de la lista global de todas las métricas de plataforma admitidas en Azure Monitor.

Para obtener información sobre la retención de métricas, consulte Información general sobre las métricas de Azure Monitor.

Métricas admitidas para Microsoft.Network/azureFirewalls

En la tabla siguiente se enumeran las métricas disponibles para el tipo de recurso Microsoft.Network/azureFirewalls.

• Es posible que todas las columnas no estén presentes en todas las tablas.
• Es posible que algunas columnas estén fuera del área de visualización de la página. Seleccione Expandir tabla para ver todas las columnas disponibles.

Encabezados de tabla

• Categoría: el grupo de métricas o la clasificación.
• Métrica: el nombre de presentación de la métrica tal como aparece en el portal de Azure.
• Nombre en la API REST: el nombre de la métrica por el que se conoce en la API REST.
• Unidad: unidad de medida.
• Agregación: el tipo de agregación predeterminado. Valores válidos: promedio (Avg), mínimo (Min), máximo (Max), total (Sum), recuento.
• Dimensiones - : dimensiones disponibles para la métrica.
• Intervalos de agregación - : intervalos en los que se obtiene una muestra de la métrica. Por ejemplo, PT1M indica que la métrica se muestrea cada minuto, PT30M cada 30 minutos, PT1H cada hora, etc.
• Exportación de DS: indica si la métrica se puede exportar a los registros de Azure Monitor a través de la configuración de diagnóstico. Para obtener más información, consulte Creación de configuración de diagnóstico en Azure Monitor.

Capacidad observada

La métrica Capacidad observada es la herramienta principal para comprender cómo escala el firewall en la práctica.

Procedimientos recomendados para usar la capacidad observada

• Valide la configuración de escalado previo: Confirme que el firewall mantiene de forma coherente la minCapacity que ha definido.
• Seguimiento del comportamiento de escalado en tiempo real: Use la agregación Avg para ver las unidades de capacidad en tiempo real.
• Previsión de necesidades futuras: Combine la capacidad observada histórica con tendencias de tráfico (por ejemplo, picos mensuales o eventos estacionales) para refinar el planeamiento de la capacidad.
• Establecimiento de alertas proactivas: Configure alertas de Azure Monitor en umbrales de capacidad observados (por ejemplo, alerta cuando el escalado supera los 80% de maxCapacity).
• Correlación con las métricas de rendimiento: Empareja la capacidad observada con rendimiento, sondeo de latencia y uso de puertos SNAT para diagnosticar si el escalado se mantiene al día con la demanda.

Firewall health state (Estado de mantenimiento del firewall)

En la tabla anterior, la métrica estado de mantenimiento del firewall tiene dos dimensiones:

• Estado: los valores posibles son Correcto, Degradado, Incorrecto.
• Motivo: indica el motivo del estado correspondiente del firewall.

Si los puertos SNAT se usan más de 95%, se consideran agotados y el estado es de 50% con status=Degradado y reason=puerto SNAT. El firewall sigue procesando el tráfico y las conexiones existentes no se ven afectadas. Sin embargo, es posible que las nuevas conexiones no se establezcan de forma intermitente.

Si se usan puertos SNAT menos del 95 %, el firewall se considera correcto y el mantenimiento se muestra como 100 %.

Si no hay informe sobre el uso de puertos SNAT, el mantenimiento se muestra como 0 %.

SNAT port utilization (Uso de puertos SNAT)

Para la métrica de uso de puertos SNAT, al agregar más direcciones IP públicas al firewall, hay más puertos SNAT disponibles, lo que reduce el uso de puertos SNAT. Además, cuando el firewall se escala horizontalmente por diferentes motivos (por ejemplo, CPU o rendimiento), también estarán disponibles más puertos SNAT.

De hecho, un porcentaje determinado del uso de puertos SNAT podría reducirse sin agregar ninguna dirección IP pública, solo porque el servicio se ha escalado horizontalmente. Puede controlar directamente el número de direcciones IP públicas disponibles para aumentar los puertos disponibles en el firewall. Sin embargo, no puede controlar directamente el escalado del firewall.

Si el firewall se está ejecutando en el agotamiento de puertos SNAT, debe agregar al menos cinco direcciones IP públicas. Así se aumenta el número de puertos SNAT disponibles. Para más información, consulte Características de Azure Firewall.

Sondeo de latencia de AZFW

La métrica de sondeo de latencia de AZFW mide la latencia general o media de Azure Firewall en milisegundos. Los administradores pueden usar esta métrica para los siguientes fines:

• Diagnóstico de si Azure Firewall provoca latencia en la red
• Supervisión y alerta de problemas de latencia o rendimiento, por lo que los equipos de TI pueden interactuar de forma proactiva
• Identificar varios factores que pueden provocar una latencia alta en Azure Firewall, como un uso elevado de la CPU, un alto rendimiento o problemas de red

Qué mide la métrica de sondeo de latencia de AZFW

• Medidas: Latencia de Azure Firewall dentro de la plataforma Azure
• No mide: Latencia de un extremo a otro para toda la ruta de acceso de red. La métrica refleja el rendimiento dentro del firewall en lugar de la latencia que Azure Firewall introduce en la red.
• Informes de errores: Si la métrica de latencia no funciona correctamente, notifica un valor de 0 en el panel de métricas, lo que indica un error de sondeo o una interrupción.

Factores que afectan a la latencia

Varios factores pueden afectar a la latencia del firewall:

• Uso elevado de CPU
• Alto rendimiento o carga de tráfico
• Problemas de red dentro de la plataforma Azure

Sondeos de latencia: de ICMP a TCP

Actualmente, el sondeo de latencia usa la tecnología Ping Mesh de Microsoft, que se basa en ICMP (Protocolo de mensajes de control de Internet). ICMP es adecuado para comprobaciones rápidas de estado, como las solicitudes de ping, pero es posible que no represente con precisión el tráfico de aplicaciones del mundo real, que normalmente se basa en TCP. Sin embargo, los sondeos ICMP priorizan de forma diferente en la plataforma Azure, lo que puede dar lugar a una variación entre SKU. Para reducir estas discrepancias, Azure Firewall planea realizar la transición a sondeos basados en TCP.

Consideraciones importantes:

• Picos de latencia: Con los sondeos ICMP, los picos intermitentes son normales y forman parte del comportamiento estándar de la red host. No malinterprete estos picos como problemas de firewall a menos que persistan.
• Latencia media: En promedio, la latencia de Azure Firewall oscila entre 1 ms y 10 ms, según el tamaño de implementación y la SKU del firewall.

Procedimientos recomendados para supervisar la latencia

• Establecer una línea base: establezca una línea base de latencia en condiciones de tráfico ligero para comparaciones precisas durante el uso normal o máximo.

  Note

  Al establecer la línea base, espere picos de métricas ocasionales debido a cambios recientes en la infraestructura. Estos picos temporales son normales y resultan de ajustes de informes de métricas, no de problemas reales. Solo envíe una solicitud de soporte técnico si los picos se conservan a lo largo del tiempo.

• Supervisión de patrones: espere picos de latencia ocasionales como parte de las operaciones normales. Si la latencia alta persiste más allá de estas variaciones normales, puede indicar un problema más profundo que requiere investigación.

• Umbral de latencia recomendado: una guía recomendada es que la latencia no debe superar 3 veces la línea base. Si se cruza este umbral, se recomienda realizar una investigación adicional.

• Compruebe el límite de reglas: asegúrese de que las reglas de red están dentro del límite de reglas de 20 000. Superar este límite puede afectar al rendimiento.

• Nueva incorporación de aplicaciones: compruebe si hay aplicaciones recién incorporadas que podrían agregar una carga significativa o causar problemas de latencia.

• Solicitud de soporte técnico: si observa una degradación continua de la latencia que no se alinea con el comportamiento esperado, considere la posibilidad de presentar una incidencia de soporte técnico para obtener más ayuda.

  

Dimensiones de métricas

Para obtener más información sobre las dimensiones de métricas, consulte Métricas multidimensionales.

Este servicio tiene las siguientes dimensiones asociadas a sus métricas.

• Protocol
• Reason
• Status

Registros de recursos

En esta sección se enumeran los tipos de registros de recursos que se pueden recopilar para este servicio. La sección extrae de la lista de todos los tipos de categorías de registros admitidos en Azure Monitor.

Registros de recursos admitidos para Microsoft.Network/azureFirewalls

Registros de seguimiento de flujo de DNS

Los registros de seguimiento de flujo de DNS proporcionan una mayor visibilidad de la actividad dns, lo que ayuda a los administradores a solucionar problemas de resolución y a comprobar el comportamiento del tráfico.

Anteriormente, el registro de proxy DNS estaba limitado a:

• AZFWDNSQuery : la consulta de cliente inicial
• AZFWInternalFqdnResolutionFailure : errores de resolución de FQDN

Con los registros de seguimiento de flujo dns, los administradores pueden realizar un seguimiento del flujo de resolución DNS completo desde la consulta de cliente a través de Azure Firewall como proxy DNS, al servidor DNS externo y volver al cliente.

Fases de resolución dns

Los registros capturan las siguientes fases:

1. Consulta de cliente: la consulta DNS inicial enviada por el cliente
2. Consulta del reenviador: Azure Firewall reenvía la consulta a un servidor DNS externo (si no se almacena en caché)
3. Respuesta del reenviador: respuesta del servidor DNS a Azure Firewall
4. Respuesta del cliente: la respuesta resuelta final de Azure Firewall de vuelta al cliente

En el diagrama siguiente se muestra una representación visual de alto nivel del flujo de consulta DNS:

Estos registros proporcionan información valiosa, como:

• Servidor DNS consultado
• Direcciones IP resueltas
• Si se usó la caché de Azure Firewall

Habilitación de registros de seguimiento de flujo de DNS

Antes de configurar los registros de seguimiento de flujo de DNS, primero debe habilitar la característica mediante Azure PowerShell.

Habilitación de registros (requisito previo)

Ejecute los siguientes comandos en Azure PowerShell y reemplace los marcadores de posición por sus valores:

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

Deshabilitar registros (opcional)

Para deshabilitar los registros, use el mismo comando anterior de Azure PowerShell y establezca el valor en False:

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

Configuración del proxy DNS y los registros de seguimiento de flujo de DNS

Siga estos pasos para configurar el proxy DNS y habilitar los registros de seguimiento de flujo de DNS:

1. Habilitar proxy DNS:

   1. Vaya a la configuración de DNS de Azure Firewall y habilite el proxy DNS.
   2. Configure un servidor DNS personalizado o use el DNS de Azure predeterminado.
   3. Vaya a Configuración de DNS de red virtual y establezca la dirección IP privada del firewall como servidor DNS principal.

2. Habilite los registros de seguimiento de flujo de DNS:

   1. Vaya a Azure Firewall en Azure Portal.
   2. Seleccione Configuración de diagnóstico en Supervisión.
   3. Elija una configuración de diagnóstico existente o cree una nueva.
   4. En la sección Registro , seleccione Registros de seguimiento de flujo de DNS.
   5. Elige el destino que desee (Log Analytics o Cuenta de Almacenamiento).

   Note

   Los registros de traza de flujo DNS no están compatibles con Event Hub como destino.

   6. Guarda la configuración

3. Pruebe la configuración:

   1. Genere consultas DNS desde clientes y compruebe los registros en el destino elegido.

Descripción de los registros

Cada entrada de registro corresponde a una fase específica del proceso de resolución de DNS. En la tabla siguiente se describen los tipos de registro y los campos clave:

Los campos anteriores son solo un subconjunto de los campos disponibles en cada entrada de registro.

Notas clave:

• Si se usa la caché DNS, solo se generan entradas de consulta de cliente y respuesta de cliente .
• Los registros incluyen metadatos estándar, como marcas de tiempo, direcciones IP de origen/destino, protocolos y contenido de mensajes DNS.
• Para evitar un volumen excesivo de registros en entornos con muchas consultas de corta duración, habilite registros de proxy DNS adicionales solo cuando se requiera una solución de problemas de DNS más profunda.

Principales flujos

El registro de flujos principales se conoce en el sector como registro de flujo de grasa y, en la tabla anterior, como registro de flujo de grasa de Azure Firewall. El registro de flujos principales muestra las conexiones principales que contribuyen al mayor rendimiento a través del firewall.

La velocidad de flujo se define como la velocidad de transmisión de datos en megabits por segundo unidades. Es una medida de la cantidad de datos digitales que se pueden transmitir a través de una red en un período de tiempo a través del firewall. El protocolo Top Flows se ejecuta periódicamente cada tres minutos. El umbral mínimo que se va a considerar un flujo superior es de 1 Mbps.

Habilitación de los registros de flujos principales

Use los siguientes comandos de Azure PowerShell para habilitar los registros de flujos principales:

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

Deshabilitación de los registros de flujos principales

Para deshabilitar los registros, use el mismo comando de Azure PowerShell y establezca el valor en False. Por ejemplo:

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

Comprobación de la configuración

Hay varias maneras de comprobar que la actualización se realizó correctamente. Vaya a la información general del firewall y seleccione la vista JSON en la esquina superior derecha. Este es un ejemplo:

Para crear una configuración de diagnóstico y habilitar la tabla específica del recurso, consulte Creación de una configuración de diagnóstico en Azure Monitor.

Seguimiento de flujo

Los registros de firewall muestran el tráfico a través del firewall en el primer intento de una conexión TCP, conocida como paquete SYN . Sin embargo, esta entrada no muestra el recorrido completo del paquete en el protocolo de enlace TCP. Como resultado, es difícil solucionar problemas si se quita un paquete o se produce un enrutamiento asimétrico. El registro de seguimiento de Flujo de Azure Firewall soluciona este problema.

Propiedades de seguimiento de flujo

Se pueden agregar las siguientes propiedades:

• SYN-ACK: marca ACK que indica la confirmación del paquete SYN.

• FIN: marca finalizada del flujo de paquetes original. No se transmiten más datos en el flujo TCP.

• FIN-ACK: marca ACK que indica la confirmación del paquete FIN.

• RST: la marca Reset indica que el remitente original no recibe más datos.

• INVALID (flujos): indica que el paquete no se puede identificar o no tiene ningún estado.

  Por ejemplo:

  • Un paquete TCP llega a una instancia de Microsoft Azure Virtual Machine Scale Sets que no tiene ningún historial anterior para este paquete.
  • Paquetes de CheckSum incorrectos
  • La entrada de la tabla de seguimiento de conexiones está llena y no se pueden aceptar nuevas conexiones
  • Paquetes de ACK demasiado retrasados

Habilitación de los registros de seguimiento de Flow

Use los siguientes comandos de Azure PowerShell para habilitar los registros de seguimiento de Flow. Como alternativa, vaya al portal y busque Habilitar el registro de conexiones TCP:

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

Este cambio puede tardar varios minutos en surtir efecto. Una vez registrada la función, considere la posibilidad de realizar una actualización en Azure Firewall para que el cambio surta efecto inmediatamente.

Comprobación del estado del registro

Para comprobar el estado del registro de AzResourceProvider, ejecute el siguiente comando de Azure PowerShell:

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

Deshabilitación de los registros de seguimiento de Flow

Para deshabilitar el registro, use los siguientes comandos de 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

Para crear una configuración de diagnóstico y habilitar la tabla específica del recurso, consulte Creación de una configuración de diagnóstico en Azure Monitor.

Tablas de registros de Azure Monitor

En esta sección, se enumeran todas las tablas de registros de Azure Monitor relacionadas con este servicio y que están disponibles para consulta mediante Log Analytics con consultas de Kusto. Las tablas contienen datos de registro de recursos y, posiblemente, más dependiendo de lo que se recopila y se enrutan a ellos.

Azure Firewall Microsoft.Network/azureFirewalls

• AZFWNetworkRule
• AZFWFatFlow
• AZFWFlowTrace
• AZFWApplicationRule
• AZFWThreatIntel
• AZFWNatRule
• AZFWIdpsSignature
• AZFWDnsQuery
• AZFWInternalFqdnResolutionFailure
• AZFWNetworkRuleAggregation
• AZFWApplicationRuleAggregation
• AZFWNatRuleAggregation
• AzureActivity
• AzureMetrics
• AzureDiagnostics

Registro de actividad

En la tabla vinculada se enumeran las operaciones que se pueden registrar en el registro de actividad de este servicio. Estas operaciones son un subconjunto de todas las posibles operaciones del proveedor de recursos en el registro de actividad.

Para obtener más información sobre el esquema de las entradas del registro de actividad, consulte Esquema del registro de actividad.

• Operaciones del proveedor de recursos de red

Contenido relacionado

• Consulte Supervisión de Azure Firewall para obtener una descripción de la supervisión de Azure Firewall.
• Consulte Seguimiento de los cambios del conjunto de reglas para obtener consultas detalladas de Azure Resource Graph para realizar un seguimiento de las modificaciones de las reglas de firewall.
• Consulte Supervisión de los recursos de Azure con Azure Monitor para obtener información sobre la supervisión de los recursos de Azure.