Supervisión de métricas y registros en Azure Front Door

Azure Front Door proporciona varias características que le ayudarán a supervisar la aplicación, realizar un seguimiento de las solicitudes y depurar la configuración de su instancia de Front Door.

Los registros y las métricas se almacenan y administran mediante Azure Monitor.

Los informes proporcionan información sobre el flujo del tráfico a través de Azure Front Door, el firewall de aplicaciones web (WAF) y hasta su llegada a la aplicación.

Métricas

Azure Front Door mide y envía sus métricas a intervalos de 60 segundos. Azure Monitor puede tardar hasta 3 minutos en procesar las métricas y es posible que no aparezcan hasta que se complete el procesamiento. Las métricas también se pueden mostrar en gráficos o cuadrículas, y son accesibles mediante Azure Portal, Azure PowerShell, la CLI de Azure y las API de Azure Monitor. Para obtener más información, vea Información general sobre las métricas en Microsoft Azure.

Las métricas enumeradas en la tabla siguiente se registran y almacenan de forma gratuita durante un período de tiempo limitado. Por un costo adicional, puede almacenarlas durante un período más largo.

Métricas	Descripción	Dimensiones	Agregaciones recomendadas
Proporción de aciertos de bytes	El porcentaje de tráfico que se ha servido desde la caché de Azure Front Door, calculado con respecto al tráfico de salida total. La proporción de aciertos de bytes es baja si la mayoría del tráfico se reenvía al origen en lugar de servirlo desde la caché. Proporción de aciertos de bytes = (salida desde el perímetro - salida desde el origen)/salida desde el perímetro. Escenarios excluidos de los cálculos de proporción de aciertos de bytes: Deshabilite explícitamente el almacenamiento en caché, ya sea mediante el motor de reglas o el comportamiento de almacenamiento en caché de cadenas de consulta. Configure explícitamente una directiva Cache-Control con las directivas de caché no-store o private.	Punto de conexión	Promedio, mínimo
Porcentaje de estado origen	El porcentaje de sondeos de estado correctos enviados desde Azure Front Door hasta los orígenes.	Origen, grupo de origen	Avg
Latencia de origen	Azure Front Door calcula el tiempo desde el envío de la solicitud al origen para recibir el último byte de respuesta del origen. WebSocket se excluye de la latencia de origen.	Punto de conexión, origen	Promedio, máximo
Recuento de solicitudes de origen	Número de solicitudes enviadas desde Azure Front Door hasta los orígenes.	Punto de conexión, origen, estado HTTP, grupo de estado HTTP	Promedio, suma
Porcentaje de 4XX	Porcentaje de todas las solicitudes de cliente para las que el código de estado de la respuesta es 4XX.	Punto de conexión, país del cliente, región del cliente	Promedio, máximo
Porcentaje de 5XX	Porcentaje de todas las solicitudes de cliente para las que el código de estado de la respuesta es 5XX.	Punto de conexión, país del cliente, región del cliente	Promedio, máximo
Recuento de solicitudes	Número de solicitudes de cliente servidas mediante Azure Front Door, incluidas las solicitudes que se sirven por completo desde la caché.	Punto de conexión, país del cliente, región del cliente, estado HTTP, grupo de estado HTTP	Promedio, suma
Tamaño de la solicitud	Número de bytes enviados en las solicitudes desde los clientes hasta Azure Front Door.	Punto de conexión, país del cliente, región del cliente, estado HTTP, grupo de estado HTTP	Promedio, máximo
Tamaño de la respuesta	Número de bytes enviados como respuestas de Front Door a los clientes.	Punto de conexión, país del cliente, región del cliente, estado HTTP, grupo de estado HTTP	Promedio, máximo
Latencia total	Azure Front Door recibe la solicitud de cliente y envía el último byte de respuesta al cliente. Este es el tiempo total que se tarda. En el caso de WebSocket, esta métrica hace referencia al tiempo necesario para establecer la conexión de WebSocket.	Punto de conexión, país del cliente, región del cliente, estado HTTP, grupo de estado HTTP	Promedio, máximo
Recuento de solicitudes del firewall de aplicaciones web	Número de solicitudes procesadas por el firewall de aplicaciones web de Azure Front Door.	Acción, nombre de regla, nombre de directiva	Promedio, suma

Nota:

Si se agota el tiempo de espera de una solicitud al origen, el valor de la dimensión Estado Http es 0.

Registros

Los registros realizan un seguimiento de todas las solicitudes que pasan por Azure Front Door. Los registros pueden tardar unos minutos en procesarse y almacenarse.

Hay varios registros de Front Door que puede usar para diferentes propósitos:

• Los registros de acceso se pueden usar para identificar solicitudes lentas, determinar las tasas de error y comprender cómo funciona el comportamiento de almacenamiento en caché de Front Door con su solución.
• Los registros de firewall de aplicaciones web (WAF) se pueden usar para detectar posibles ataques y detecciones de falsos positivos que podrían indicar solicitudes legítimas que el WAF bloqueó. Para más información sobre los registros de WAF, consulte Supervisión y registro de Azure Web Application Firewall.
• Los registros de sondeo de estado se pueden usar para identificar los orígenes en mal estado o que no responden a las solicitudes de algunos de los PoP distribuidos geográficamente de Front Door.
• Los registros de actividad proporcionan visibilidad sobre las operaciones realizadas en los recursos de Azure, como los cambios de configuración en el perfil de Azure Front Door.

Los registros de acceso y los registros de WAF incluyen una referencia de seguimiento, que también se propaga en las solicitudes a los orígenes y a las respuestas del cliente mediante el encabezado X-Azure-Ref. Puede usar la referencia de seguimiento para obtener una vista completa del procesamiento de solicitudes de aplicación.

Los registros de acceso, los registros de sondeo de estado y los registros de WAF no están habilitados de manera predeterminada. Para habilitar y almacenar los registros de diagnóstico, consulte Configuración de registros de Azure Front Door. Las entradas del registro de actividades se recopilan de forma predeterminada y se pueden ver en Azure Portal.

Registro de acceso

La información sobre cada solicitud se registra en el registro de acceso. Cada entrada de registro de acceso contiene la información que se muestra en la tabla siguiente.

Propiedad	Descripción
TrackingReference	La cadena de referencia única que identifica una solicitud servida por Front Door. La referencia de seguimiento se envía al cliente y al origen mediante los encabezados X-Azure-Ref. Use la referencia de seguimiento al buscar una solicitud específica en los registros de acceso o WAF.
Time	Fecha y hora en la que el borde de Azure Front Door entregó el contenido solicitado al cliente (en formato UTC). En el caso de las conexiones de WebSocket, el tiempo representa cuándo se cierra la conexión.
HttpMethod	Método HTTP usado por la solicitud: DELETE, GET, HEAD, OPTIONS, PATCH, POST o PUT.
HttpVersion	Versión HTTP que el cliente especificó en la solicitud.
RequestUri	URI de la solicitud recibida. Este campo contiene el esquema completo: puerto, dominio, ruta de acceso y cadena de consulta.
HostName	Nombre de host de la solicitud del cliente. Si habilita dominios personalizados y tiene un dominio comodín (*.contoso.com), el valor del campo de registro HostName es subdomain-from-client-request.contoso.com. Si usa el dominio de Azure Front Door (contoso-123.z01.azurefd.net), el valor del campo de registro HostName es contoso-123.z01.azurefd.net.
RequestBytes	El tamaño del mensaje de solicitud HTTP en bytes, incluidos los encabezados de solicitud y el cuerpo de solicitud. En el caso de las conexiones de WebSocket, este es el número total de bytes enviados desde el cliente al servidor a través de la conexión.
ResponseBytes	Tamaño del mensaje de respuesta HTTP, en bytes. En el caso de las conexiones de WebSocket, este es el número total de bytes enviados desde el servidor al cliente a través de la conexión.
UserAgent	Agente de usuario que usó el cliente. Normalmente, el agente de usuario identifica el tipo de explorador.
ClientIp	Dirección IP del cliente que realizó la solicitud original. Si hubiera un encabezado X-Forwarded-For en la solicitud, la dirección IP del cliente se tomaría del mismo encabezado.
SocketIp	La dirección IP de la conexión directa al borde de Azure Front Door. Si el cliente usaba un proxy HTTP o un equilibrador de carga para enviar la solicitud, el valor de SocketIp es la dirección IP del proxy o del equilibrador de carga.
TimeTaken	La duración desde que el borde de Azure Front Door recibió la solicitud del cliente hasta que se envió el último byte de la respuesta al cliente, medida en segundos. Esta métrica excluye la latencia de red y el almacenamiento en búfer TCP. En el caso de las conexiones de WebSocket, representa la duración de la conexión desde el establecimiento hasta el cierre.
RequestProtocol	Protocolo especificado por el cliente en la solicitud. Los valores posibles son HTTP, HTTPS. En el caso de WebSocket, los protocolos son WS, WSS. Solo las solicitudes que se actualicen correctamente a WebSocket tendrán WS o WSS.
SecurityProtocol	Versión del protocolo TLS/SSL utilizada por la solicitud o NULL si la solicitud no usó cifrado. Los valores posibles son SSLv3, TLSv1, TLSv1.1, TLSv1.2.
SecurityCipher	Cuando el valor del protocolo de la solicitud es HTTPS, este campo indica el cifrado TLS/SSL negociado por el cliente y Azure Front Door.
Punto de conexión	Nombre de dominio del punto de conexión de Azure Front Door, como contoso-123.z01.azurefd.net.
HttpStatusCode	El código de estado HTTP devuelto de Azure Front Door. Si se agota el tiempo de espera de la solicitud al origen, el valor del campo HttpStatusCode es establece en 0. Si el cliente cerró la conexión, el valor del campo HttpStatusCode es 499.
PoP	El punto de presencial (PoP) del borde de Azure Front que respondió a la solicitud del usuario.
Estado de la caché	El modo en que se controló la solicitud mediante la caché de Azure Front Door. Los valores posibles son: HIT y REMOTE_HIT: la solicitud HTTP se ha servido desde la caché de Azure Front Door. MISS: la solicitud HTTP se sirvió desde el origen. PARTIAL_HIT: algunos de los bytes se han servido desde la caché PoP del borde de Azure Front Door y otros se han servido desde el origen. Este estado indica un escenario de fragmentación de objetos. CACHE_NOCONFIG: la solicitud se reenvió sin la configuración de almacenamiento en caché, incluidos los escenarios de omisión. PRIVATE_NOSTORE: el cliente no configuró ninguna caché en la configuración de almacenamiento en caché. N/A: una dirección URL firmada o reglas WAF denegaron la solicitud.
MatchedRulesSetName	Nombres de las reglas del motor de reglas que se procesaron.
RouteName	Nombre de la ruta que coincidió con la solicitud.
ClientPort	Puerto IP del cliente que realizó la solicitud.
Referrer	Dirección URL del sitio que originó la solicitud.
TimetoFirstByte	El tiempo, en segundos, transcurrido desde que el borde de Azure Front Door recibió la solicitud hasta que se envió el primer byte al cliente, medido por Azure Front Door. Esta propiedad no mide los datos del cliente.
ErrorInfo	Si se produjo un error durante el procesamiento de la solicitud, este campo proporciona información detallada sobre el error. Los valores posibles son: NoError: indica que no se encontró ningún error. CertificateError: error genérico de certificado SSL. CertificateNameCheckFailed: el nombre de host del certificado SSL no es válido o no coincide con la dirección URL solicitada. ClientDisconnected: error en la solicitud debido a un problema de conexión de red del cliente. ClientGeoBlocked: el cliente se bloqueó debido a la ubicación geográfica de la dirección IP. UnspecifiedClientError: error genérico de cliente. InvalidRequest: solicitud no válida. Esta respuesta indica un encabezado, un cuerpo o una dirección URL con formato incorrecto. DNSFailure: se produjo un error durante la resolución DNS. DNSTimeout: se agotó el tiempo de espera de la consulta de DNS para resolver la dirección IP de origen. DNSNameNotResolved: no se pudo resolver el nombre o la dirección del servidor. OriginConnectionAborted: la conexión con el origen se desconectó de forma anómala. OriginConnectionError: error genérico de conexión con el origen. OriginConnectionRefused: no se pudo establecer la conexión con el origen. OriginError: error genérico del origen. ResponseHeaderTooBig: el origen devolvió un encabezado de respuesta demasiado grande. OriginInvalidResponse: el origen devolvió una respuesta no válida o desconocida. OriginTimeout: se agotó el período de tiempo de espera de la solicitud de origen. ResponseHeaderTooBig: el origen devolvió un encabezado de respuesta demasiado grande. RestrictedIP: la solicitud se bloqueó debido a una IP restringida. SSLHandshakeError: Azure Front Door no pudo establecer una conexión con el origen debido a un error de protocolo de enlace SSL. SSLInvalidRootCA: el certificado de la entidad de certificación raíz no era válido. SSLInvalidCipher: la conexión HTTPS se estableció mediante un cifrado no válido. OriginConnectionAborted: la conexión con el origen se desconectó de forma anómala. OriginConnectionRefused: no se pudo establecer la conexión con el origen. UnspecifiedError: se produjo un error que no coincidía con ninguno de los errores de la tabla.
OriginURL	Dirección URL completa del origen donde se envió la solicitud. La dirección URL se compone del esquema, el encabezado host, el puerto, la ruta de acceso y la cadena de consulta. URL rewrite: si el motor de reglas reescribió la dirección URL de la solicitud, la ruta de acceso hace referencia a la ruta de acceso reescrita. Cache on edge PoP: si la solicitud se ha servido desde la caché de Azure Front Door, el origen es N/A. Large request: si el contenido solicitado es grande y hay varias solicitudes fragmentadas que regresan al origen, este campo se corresponde con la primera solicitud al origen. Para más información, consulte Fragmentación de objetos.
OriginIP	Dirección IP del origen que ha servido la solicitud. Cache on edge PoP: si la solicitud se ha servido desde la caché de Azure Front Door, el origen es N/A. Large request: si el contenido solicitado es grande y hay varias solicitudes fragmentadas que regresan al origen, este campo se corresponde con la primera solicitud al origen. Para más información, consulte Fragmentación de objetos.
OriginName	Nombre de host completo (nombre DNS) del origen. Cache on edge PoP: si la solicitud se ha servido desde la caché de Azure Front Door, el origen es N/A. Large request: si el contenido solicitado es grande y hay varias solicitudes fragmentadas que regresan al origen, este campo se corresponde con la primera solicitud al origen. Para más información, consulte Fragmentación de objetos.
Resultado	SSLMismatchedSNI es un código de estado que indica que la solicitud fue correcta, pero hubo falta de coincidencia entre la indicación de nombre de servidor (SNI) y el encabezado de host. Este código de estado implica el enmascaramiento de dominio, una técnica que infringe los términos de servicio de Azure Front Door. Las solicitudes con SSLMismatchedSNI se rechazarán después del 22 de enero de 2024.
SNI	Este campo especifica la indicación de nombre de servidor (SNI) que se envía durante el protocolo de enlace TLS/SSL. Se puede usar para identificar el valor SNI exacto si había un código de estado SSLMismatchedSNI. Además, se puede comparar con el valor de host en el campo requestUri para detectar y resolver el problema de coincidencia.

Registro de sondeo de estado

Azure Front Door registra cada solicitud de sondeo de estado con errores. Estos registros pueden ayudarle a diagnosticar problemas con un origen. Los registros proporcionan información que puede usar para investigar el motivo del error y, a continuación, devolver el origen a un estado correcto.

Algunos escenarios en los que puede resultar útil este registro son:

• Ha observado que el tráfico de Azure Front Door se envió a un subconjunto de los orígenes. Por ejemplo, es posible que haya observado que solo tres de cuatro orígenes reciben tráfico. Quiere saber si los orígenes reciben sondeos de estado y responden a estos para saber si los orígenes son correctos.
• Ha observado que la métrica de porcentaje de estado de origen es inferior a la esperada. Quiere saber qué orígenes se registran como incorrectos y el motivo de los errores de sondeo de estado.

Cada registro de sondeo de estado tiene el siguiente esquema:

Propiedad	Descripción
HealthProbeId	Identificador único para identificar la solicitud de sondeo de estado.
Time	Fecha y hora en que se envió el sondeo de estado (en UTC).
HttpMethod	Método HTTP utilizado por la solicitud del sondeo de estado. Los valore son GET y HEAD, en función de la configuración del sondeo de estado.
Resultado	Estado del sondeo de estado. El valor es correcto o una descripción del error que recibió el sondeo.
HttpStatusCode	Código de estado HTTP devuelto por el origen.
ProbeURL	Dirección URL de destino completa a la que se envió la solicitud de sondeo. La dirección URL se compone del esquema, el encabezado host, la ruta de acceso y la cadena de consulta.
OriginName	Nombre del origen al que se envió el sondeo de estado. Este campo ayuda a encontrar los orígenes de interés si el origen está configurado para usar un FQDN.
POP	PoP de borde que envió la solicitud de sondeo.
IP de origen	Dirección IP del origen al que se envió el sondeo de estado.
TotalLatency	Tiempo transcurrido desde que el borde de Azure Front Door envió la solicitud de sondeo de estado al origen hasta que el origen envió la última respuesta a Azure Front Door.
ConnectionLatency	Tiempo invertido en la configuración de la conexión TCP para enviar la solicitud de sondeo HTTP al origen.
DNSResolution Latency	El tiempo dedicado a la resolución DNS. Este campo solo tiene un valor si el origen está configurado para ser un FQDN en lugar de una dirección IP. Si el origen está configurado para usar una dirección IP, el valor es N/A.

En el siguiente fragmento de código JSON de ejemplo se muestra una entrada del registro de sondeo de estado para una solicitud de sondeo de estado con errores.

{
  "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"
      }
    }
  ]
}

Registro del firewall de aplicaciones web

Para más información sobre los registros del firewall de aplicaciones web (WAF) de Front Door, consulte Supervisión y registro de Azure Web Application Firewall.

Registros de actividad

Los registros de actividad proporcionan información sobre las operaciones de administración realizadas en los recursos de Azure Front Door. Los registros incluyen detalles sobre cada operación de escritura que se realizó en un recurso de Azure Front Door, como cuándo se produjo la operación, quién la realizó y cuál fue la operación.

Nota

Los registros de actividad no incluyen operaciones de lectura. También es posible que no incluyan todas las operaciones que realice mediante Azure Portal o las API de administración clásicas.

Para más información, consulta Visualización de los registros de actividad.

Pasos siguientes

Para habilitar y almacenar los registros de diagnóstico, consulte Configuración de registros de Azure Front Door.

Importante

Azure Front Door (clásico) se retirará el 31 de marzo de 2027. Para evitar cualquier interrupción del servicio, es importante migrar los perfiles de Azure Front Door (clásico) al nivel Estándar o Premium de Azure Front Door para marzo de 2027. Para obtener más información, consulte retirada de Azure Front Door (clásico).

Al usar Azure Front Door (clásico), puede supervisar los recursos de las siguientes maneras:

• Métricas. Azure Front Door tiene actualmente ocho métricas para ver los contadores de rendimiento.
• Registros. Los registros de actividad y diagnóstico permiten que un recurso guarde o consuma datos de rendimiento, acceso u otros con fines de supervisión.

Métricas

Las métricas son una característica de determinados recursos de Azure en los que puede ver contadores de rendimiento en el portal. Las métricas siguientes están disponibles en Front Door:

Métrica	Nombre de métrica para mostrar	Unidad	Dimensions	Descripción
RequestCount	Recuento de solicitudes	Count	HttpStatus HttpStatusGroup ClientRegion ClientCountry	Número de solicitudes de cliente que atiende Front Door.
RequestSize	Tamaño de la solicitud	Bytes	HttpStatus HttpStatusGroup ClientRegion ClientCountry	Número de bytes enviados como solicitudes de clientes a Front Door.
ResponseSize	Tamaño de la respuesta	Bytes	HttpStatus HttpStatusGroup ClientRegion ClientCountry	Número de bytes enviados como respuestas de Front Door a los clientes.
TotalLatency	Latencia total	Milisegundos	HttpStatus HttpStatusGroup ClientRegion ClientCountry	El tiempo total desde la solicitud de cliente recibida por Front Door hasta el último byte de respuesta enviado desde ADF al cliente.
BackendRequestCount	Recuento de solicitudes de back-end	Count	HttpStatus HttpStatusGroup Backend	Número de solicitudes enviadas de Front Door a los servidores back-end.
BackendRequestLatency	Latencia de las solicitudes de back-end	Milisegundos	Back-end	Tiempo calculado desde que Front Door envía la solicitud al servidor back-end hasta que Front Door recibe el último byte de respuesta del servidor back-end.
BackendHealthPercentage	Porcentaje de estado del back-end	Percent	Backend BackendPool	El porcentaje de sondeos de estado correctos de Front Door a los servidores back-ends.
WebApplicationFirewallRequestCount	Recuento de solicitudes del firewall de aplicaciones web	Count	PolicyName RuleName Action	Número de solicitudes de cliente procesadas por la seguridad del nivel de aplicación de Front Door.

Registros de actividad

Los registros de actividad proporcionan información sobre las operaciones hechas en un perfil de Azure Front Door (clásico). También determinan qué, quién y cuándo para cualquier operación de escritura (put, post o delete) hecha en un perfil de Azure Front Door (clásico).

Nota:

Si se agota el tiempo de espera de una solicitud al origen, el valor de HttpStatusCode es establece en 0.

Acceda a registros de actividad en Front Door o a los registros de todos los recursos de Azure en Azure Monitor. Para ver los registros de actividad:

1. Seleccione la instancia de Front Door.

2. Seleccione Registro de actividad.

   

3. Elija un ámbito de filtrado y, a continuación, seleccione Aplicar.

Nota

El registro de actividad no incluye ninguna operación GET ni operaciones que realice mediante Azure Portal o la API de administración original.

Registros de diagnóstico

Los registros de diagnóstico proporcionan información valiosa acerca de las operaciones y los errores que son importantes para la auditoría, así como para solucionar problemas. Los registros de diagnóstico son diferentes de los registros de actividad.

Los registros de actividad proporcionan información sobre las operaciones llevadas a cabo en los recursos de Azure. Los registros de diagnóstico proporcionan conclusiones detalladas sobre las operaciones que ha hecho el recurso. Para más información, vea Información general sobre los registros de diagnóstico de Azure.

Para configurar los registros de diagnóstico para Azure Front Door (clásico):

1. Seleccione su perfil de servicio Azure Front Door (clásico).

2. Seleccione Configuración de diagnóstico.

3. Seleccione Activar diagnósticos. Archive los registros de diagnóstico junto con las métricas en una cuenta de almacenamiento, transmítalos en secuencias a un centro de eventos o envíelos a los registros de Azure Monitor.

Front Door actualmente proporciona los registros de diagnóstico. Los registros de diagnóstico proporcionan solicitudes API individuales con cada entrada con el siguiente esquema:

Propiedad	Descripción
BackendHostname	Si la solicitud se reenvió a un back-end, este campo representa el nombre de host del back-end. Este campo está en blanco si la solicitud se redirige o reenvía a una caché regional (si el almacenamiento en caché está habilitado para la regla de enrutamiento).
CacheStatus	En el caso de los escenarios de almacenamiento en caché, este campo define el número de aciertos y errores de caché en el POP
ClientIp	Dirección IP del cliente que realizó la solicitud. Si hubiera un encabezado X-Forwarded-For en la solicitud, la dirección IP del cliente se seleccionaría del mismo.
ClientPort	Puerto IP del cliente que realizó la solicitud.
HttpMethod	Método HTTP utilizado por la solicitud.
HttpStatusCode	El código de estado HTTP devuelto desde el servidor proxy. Si se agota el tiempo de espera de una solicitud al origen, el valor de HttpStatusCode es establece en 0.
HttpStatusDetails	Estado resultante en la solicitud. El significado de este valor de cadena puede encontrarse en una tabla de referencia de estado.
HttpVersion	Tipo de la solicitud o conexión.
POP	Nombre corto del perímetro en el que ha aterrizado la solicitud.
RequestBytes	El tamaño del mensaje de solicitud HTTP en bytes, incluidos los encabezados de solicitud y el cuerpo de solicitud.
RequestUri	URI de la solicitud recibida.
ResponseBytes	Bytes enviados por el servidor back-end como respuesta.
RoutingRuleName	El nombre de la regla de enrutamiento que coincidió con la solicitud.
RulesEngineMatchNames	Los nombres de las reglas que coincidieron con la solicitud.
SecurityProtocol	La versión del protocolo TLS/SSL utilizada por la solicitud o null si no hay cifrado.
SentToOriginShield (en desuso)* Consulte las notas sobre el desuso en la sección siguiente.	Si es True, significa que la solicitud se respondió desde la memoria caché del escudo de origen en lugar del PoP perimetral. El escudo de origen es una memoria caché primaria que se usa para mejorar la proporción de aciertos de caché.
isReceivedFromClient	Si es true, significa que la solicitud procedía del cliente. Si es false, la solicitud es una línea no ejecutada en el servidor perimetral (POP secundario) y se responde desde el escudo de origen (POP primario).
TimeTaken	Período de tiempo desde el primer byte de la solicitud en Front Door hasta el último byte de la respuesta, en segundos.
TrackingReference	La cadena de referencia exclusiva que identifica una solicitud atendida por Front Door, que también se envía como encabezado X-Azure-Ref al cliente. Se requiere para buscar los detalles en los registros de acceso para una solicitud específica.
UserAgent	Tipo de explorador utilizado por el cliente.
ErrorInfo	Este campo contiene el tipo específico de error para facilitar la solución de problemas. Valores posibles incluyen: NoError: Indica que no se encontró ningún error. CertificateError: Error de certificado SSL genérico. CertificateNameCheckFailed: El nombre de host del certificado SSL no es válido o no coincide. ClientDisconnected: Error de solicitud debido a la conexión de red del cliente. UnspecifiedClientError: Error de cliente genérico. InvalidRequest: Solicitud no válida. Podría producirse debido a un encabezado, un cuerpo y una dirección URL con formato incorrecto. DNSFailure: Error de DNS. DNSNameNotResolved: No se pudo resolver el nombre o la dirección del servidor. OriginConnectionAborted: La conexión con el origen se detuvo abruptamente. OriginConnectionError: Error de conexión de origen genérico. OriginConnectionRefused: No se pudo establecer la conexión con el origen. OriginError: Error de origen genérico. OriginInvalidResponse: El Origen devolvió una respuesta no válida o no reconocida. OriginTimeout: El período de tiempo de espera de la solicitud de origen expiró. ResponseHeaderTooBig: El origen devolvió demasiado grande un encabezado de respuesta. RestrictedIP: La solicitud se bloqueó debido a una dirección IP restringida. SSLHandshakeError: No se puede establecer la conexión con el origen debido a un error de agitación de mano SSL. UnspecifiedError: Se produjo un error que no cabe en ninguno de los errores de la tabla. SSLMismatchedSNI: la solicitud no era válida porque el encabezado del mensaje HTTP no coincide con el valor presentado en la extensión SNI de TLS durante la configuración de la conexión SSL/TLS.
Resultado	SSLMismatchedSNI es un código de estado que indica que la solicitud fue correcta, pero hubo falta de coincidencia entre la indicación de nombre de servidor (SNI) y el encabezado de host. Este código de estado implica el enmascaramiento de dominio, una técnica que infringe los términos de servicio de Azure Front Door. Las solicitudes con SSLMismatchedSNI se rechazarán después del 22 de enero de 2024.
SNI	Este campo especifica la indicación de nombre de servidor (SNI) que se envía durante el protocolo de enlace TLS/SSL. Se puede usar para identificar el valor SNI exacto si había un código de estado SSLMismatchedSNI. Además, se puede comparar con el valor de host en el campo requestUri para detectar y resolver el problema de coincidencia.

Desuso de la propiedad de envío al escudo de origen

La propiedad isSentToOriginShield del registro sin procesar está en desuso y se ha reemplazado por un nuevo campo, isReceivedFromClient. Use el nuevo campo si aún usa el campo en desuso.

Los registros sin procesar incluyen los registros generados tanto desde el servidor perimetral de la red CDN (POP secundario) como desde el escudo de origen. El escudo de origen hace referencia a los nodos primarios que están ubicados de manera estratégica por todo el planeta. Estos nodos se comunican con los servidores de origen y reducen la carga de tráfico en el origen.

Por cada solicitud que va al escudo de origen, hay dos entradas de registro:

• Una para los nodos perimetrales y
• otra para el escudo de origen.

Para diferenciar la salida o las respuestas de los nodos perimetrales de las del escudo de origen, puede usar el campo isReceivedFromClient para obtener los datos correctos.

Si el valor es false, significa que la solicitud se responde desde el escudo de origen a los nodos perimetrales. Este enfoque es eficaz para comparar los registros sin procesar con los datos de facturación. No se paga por la salida del escudo de origen a los nodos perimetrales. Se paga por la salida de los nodos perimetrales a los clientes.

Ejemplo de consulta Kusto para excluir los registros generados en el escudo de origen en Log Analytics.

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

Nota

En el caso de varias configuraciones de enrutamiento y comportamientos de tráfico, algunos de los campos, como backendHostname, cacheStatus, isReceivedFromClient y POP, pueden responder con valores diferentes. En la tabla siguiente se explican los distintos valores que estos campos tendrán en diversos escenarios:

Escenarios	Recuento de entradas de registro	POP	BackendHostname	isReceivedFromClient	CacheStatus
Regla de enrutamiento sin almacenamiento en caché habilitado	1	Código POP perimetral	El back-end al que se reenvió la solicitud	Verdadero	CONFIG_NOCACHE
Regla de enrutamiento con almacenamiento en caché habilitado. Aciertos de caché en el POP perimetral	1	Código POP perimetral	Vacío	Verdadero	HIT
Regla de enrutamiento con almacenamiento en caché habilitado. Errores de caché en el POP perimetral pero acierto en el POP de la caché primaria	2	1. Código POP perimetral 2. Código POP de caché primaria	1. Nombre de host de POP de caché primaria 2. Vacío	1. True 2. False	1. MISS 2. HIT
Regla de enrutamiento con almacenamiento en caché habilitado. Error de cachés en el POP perimetral pero acierto PARTIAL en el POP de la caché primaria	2	1. Código POP perimetral 2. Código POP de caché primaria	1. Nombre de host de POP de caché primaria 2. Back-end que ayuda a rellenar la memoria caché	1. True 2. False	1. MISS 2. PARTIAL_HIT
Regla de enrutamiento con almacenamiento en caché habilitado. PARTIAL_HIT en el POP perimetral pero acierto en el POP de la caché primaria	2	1. Código POP perimetral 2. Código POP de caché primaria	1. Código POP perimetral 2. Código POP de caché primaria	1. True 2. False	1. PARTIAL_HIT 2. HIT
Regla de enrutamiento con almacenamiento en caché habilitado. Errores de caché en el POP perimetral y en el de caché primaria	2	1. Código POP perimetral 2. Código POP de caché primaria	1. Código POP perimetral 2. Código POP de caché primaria	1. True 2. False	1. MISS 2. MISS
Se produjo un error al procesar la solicitud					N/D

Nota

En el caso de los escenarios de almacenamiento en caché, el valor del estado de la memoria caché será partial_hit cuando se sirvan algunos de los bytes para una solicitud desde la memoria caché del escudo de origen o perimetral de Azure Front Door, mientras que algunos de los bytes se sirven desde el origen de los objetos grandes.

Azure Front Door usa una técnica denominada fragmentación de objetos. Cuando se solicita un archivo grande, Azure Front Door recupera partes más pequeñas del origen. Una vez que el servidor POP de Azure Front Door recibe una solicitud de archivo completa o de intervalo de bytes, el servidor perimetral de Azure Front Door solicita el archivo al origen en fragmentos de 8 MB.

Una vez que llega el fragmento al perímetro de la red Azure Front Door, se almacena en caché y se sirve inmediatamente al usuario. Después, Azure Front Door hace una captura previa del siguiente fragmento en paralelo. Este captura previa garantiza que el contenido sigue estando un fragmento por delante del usuario, lo que reduce la latencia. Este proceso continúa hasta que se descarga todo el archivo (si se solicita), todos los intervalos de bytes están disponibles (si se solicitan) o el cliente cierra la conexión. Para más información sobre la solicitud de intervalo de bytes, vea RFC 7233. La red Azure Front Door almacena en caché los fragmentos cuando se reciben. No es necesario almacenar el archivo entero en la caché de Front Door. Las solicitudes subsiguientes del archivo o los intervalos de bytes se sirven desde la caché de Azure Front Door. Si no se almacenan en caché todos los fragmentos en la red Azure Front Door, se usa la captura previa para solicitar fragmentos del origen. Esta optimización se basa en la capacidad del servidor de origen de admitir solicitudes de intervalo de bytes. Si el servidor de origen no admite solicitudes de intervalo de bytes, esta optimización no es efectiva.

Pasos siguientes

• Aprenda a crear un perfil de Azure Front Door (clásico)
• Aprenda sobre el Funcionamiento de Azure Front Door (clásico)