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:
|
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. | 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. | 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). |
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. |
ResponseBytes | Tamaño del mensaje de respuesta HTTP, en bytes. |
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 | El período de tiempo desde que el borde de Azure Front Door recibió la solicitud del cliente hasta el momento en que Azure Front Door envió el último byte de la respuesta al cliente, en segundos. Este campo no tiene en cuenta la latencia de red y el almacenamiento en búfer de TCP. |
RequestProtocol | Protocolo especificado por el cliente en la solicitud. Los valores posibles son HTTP, HTTPS. |
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:
|
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:
|
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 FDQN 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:
Seleccione la instancia de Front Door.
Seleccione Registro de actividad.
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):
Seleccione su perfil de servicio Azure Front Door (clásico).
Seleccione Configuración de diagnóstico.
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)