Supervisión de Azure Front Door
Azure Monitor recopila y agrega métricas y registros del sistema para supervisar la disponibilidad, el rendimiento y la resistencia, y le notifica los problemas que afectan al sistema. Puede usar Azure Portal, PowerShell, la CLI de Azure, la API de REST o las bibliotecas cliente para configurar y ver los datos de supervisión.
Hay diferentes métricas y registros disponibles para distintos tipos de recursos. En este artículo se describen los tipos de datos de supervisión que puede recopilar para este servicio y las formas de analizarlos.
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.
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).
Recopilación de datos con Azure Monitor
En esta tabla se describe cómo puede recopilar datos para supervisar el servicio y lo que puede hacer con los datos una vez recopilados:
| Datos que se van a recopilar | Descripción | Recopilación y enrutamiento de los datos | Dónde ver los datos | Datos admitidos |
|---|---|---|---|---|
| Datos métricos | Las métricas son valores numéricos que describen un aspecto de un sistema en un momento dado. Las métricas se pueden agregar mediante algoritmos, compararse con otras métricas y analizarse en busca de tendencias a lo largo del tiempo. | - Se recopilan automáticamente a intervalos regulares. - Puede redirigir algunas métricas de la plataforma a un área de trabajo de Log Analytics para consultarlas con otros datos. Compruebe la configuración exportación de DS para cada métrica para ver si puede usar una configuración de diagnóstico para enrutar los datos de métricas. |
Explorador de métricas | Métricas de Azure Front Door compatibles con Azure Monitor |
| Datos de registro de recursos | Los registros son eventos del sistema registrados con una marca de tiempo. Los registros pueden contener diferentes tipos de datos, ser de texto estructurado o de forma libre, y contienen una marca de tiempo. Puede enrutar datos de registro de recursos a áreas de trabajo de Log Analytics para realizar consultas y análisis. | Cree una configuración de diagnóstico para recopilar y enrutar datos de registro de recursos. | Log Analytics | Datos de registro de recursos de Azure Front Door compatibles con Azure Monitor |
| Datos del registro de actividad | El registro de actividad de Azure Monitor proporciona información sobre los eventos del nivel de suscripción. El registro de actividad incluye información como, por ejemplo, cuándo se modificó un recurso o cuándo se inició una máquina virtual. | - Recopilado automáticamente. - Cree una configuración de diagnóstico para un área de trabajo de Log Analytics sin coste alguno. |
Registro de actividad |
Para obtener la lista de todos los datos admitidos por Azure Monitor, consulte:
Supervisión integrada para Azure Front Door
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. Para conexiones WebSocket, este valor 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. Para las conexiones WebSocket, este valor 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 actualizan correctamente a WebSocket tienen WS/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é | Cómo controla la caché de Azure Front Door la solicitud. 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. Reescritura de URL: 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, puede observar 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.
En el caso de Azure Front Door clásico, la supervisión integrada incluye registros de diagnóstico.
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 información sobre las operaciones que realiza 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 genérico de certificado SSL. 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 de forma abrupta. OriginConnectionError: error de conexión de origen genérico. OriginConnectionRefused: no se pudo establecer la conexión con el origen. OriginError: error genérico del origen. OriginInvalidResponse: el origen devolvió una respuesta no válida o desconocida. OriginTimeout: el tiempo de espera de la solicitud de origen ha expirado. ResponseHeaderTooBig: el origen devolvió un encabezado de respuesta demasiado grande. RestrictedIP: la solicitud se bloqueó debido a una IP restringida. SSLHandshakeError: no se puede establecer la conexión con el origen debido a un error del protocolo de enlace SSL. UnspecifiedError: se produjo un error que no coincidía con 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:
Para varias configuraciones de enrutamiento y comportamientos de tráfico, algunos de los campos como backendHostname, cacheStatus, isReceivedFromClient y el campo POP pueden responder con valores diferentes. En la tabla siguiente se explican los distintos valores que tienen estos campos para varios 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é es 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.
Uso de herramientas de Azure Monitor para analizar los datos
Estas herramientas de Azure Monitor están disponibles en Azure Portal para ayudarle a analizar los datos de supervisión:
Algunos servicios de Azure tienen un panel de supervisión integrado en Azure Portal. Estos paneles se denominan Información, y puede encontrarlos en la sección Información de Azure Monitor en Azure Portal.
Explorador de métricas le permite ver y analizar métricas de recursos de Azure. Para obtener más información, consulte Análisis de métricas con el explorador de métricas de Azure Monitor.
Log Analytics le permite consultar y analizar datos de registro mediante el Lenguaje de consulta Kusto (KQL). Para más información, consulta Introducción a las consultas de registro en Azure Monitor.
Azure Portal tiene una interfaz de usuario para la visualización y búsquedas básicas del registro de actividad. Para realizar un análisis más detallado, enrute los datos a los registros de Azure Monitor y ejecute consultas más complejas en Log Analytics.
Application Insights supervisa la disponibilidad, el rendimiento y el uso de las aplicaciones web, por lo que puede identificar y diagnosticar errores sin esperar a que un usuario los notifique.
Application Insights incluye puntos de conexión con una serie de herramientas de desarrollo y se integra con Visual Studio para admitir los procesos de DevOps. Para más información, consulte Supervisión de aplicaciones para App Service.
Entre las herramientas que permiten una visualización más compleja se incluyen:
- Paneles que permiten combinar diferentes tipos de datos en un único panel de Azure Portal.
- Libros: informes personalizables que se pueden crear en Azure Portal. Los libros pueden incluir texto, métricas y consultas de registro.
- Grafana: una herramienta de plataforma abierta que se destaca en los paneles operativos. Puede usar Grafana para crear paneles que incluyan datos de varios orígenes distintos de Azure Monitor.
- Power BI: un servicio de análisis empresarial que proporciona visualizaciones interactivas en varios orígenes de datos. Puede configurar Power BI para que los datos de registro se importen automáticamente desde Azure Monitor y utilizar estas otras adicionales.
Exportación de datos de Azure Monitor
Puede exportar datos de Azure Monitor a otras herramientas mediante:
Métricas: con la API de REST para métricas puede extraer datos de métricas de la base de datos de métricas de Azure Monitor. Para obtener más información, consulte Referencia de la API de REST de Azure Monitor.
Registros: use la API de REST o las bibliotecas de cliente asociadas.
La exportación de datos del área de trabajo de Log Analytics.
Para empezar a trabajar con la API de REST de Azure Monitor, consulte Tutorial sobre la API de REST de supervisión de Azure.
Uso de consultas de Kusto para analizar datos de registro
Puede analizar los datos de registro de Azure Monitor mediante el Lenguaje de consulta Kusto (KQL). Para más información, vea Consultas de registro en Azure Monitor.
Uso de alertas de Azure Monitor para notificarle problemas
Las alertas de Azure Monitor le permiten identificar y solucionar problemas en el sistema y le notifican de forma proactiva cuando se detectan condiciones específicas en los datos de supervisión antes de que los clientes se den cuenta. Puede alertar sobre cualquier métrica o fuente de datos de registro en la plataforma de datos de Azure Monitor. Hay muchos tipos diferentes de alertas de Azure Monitor en función de los servicios que esté supervisando y de los datos de supervisión que esté recopilando. Ver Elección del tipo correcto de regla de alertas.
Para obtener ejemplos de alertas comunes para recursos de Azure, consulte Consultas de alertas de registro de ejemplo.
Implementación de alertas a escala
Para algunos servicios, puede supervisar a escala aplicando la misma regla de alertas de métricas a varios recursos del mismo tipo que existen en la misma región de Azure. El sitio de Alertas de línea de base de Azure Monitor (AMBA) proporciona un método semiautomatizado para implementar alertas, paneles e instrucciones importantes de métricas de plataforma a escala.
Obtención de información personalizada sobre las recomendaciones mediante Azure Advisor
Para algunos servicios, si se producen condiciones críticas o cambios inminentes durante las operaciones de recursos, se muestra una alerta en la página Información general del servicio del portal. Puede encontrar más información y correcciones recomendadas para la alerta en Recomendaciones de Advisor en Supervisión en el menú izquierdo. Durante las operaciones normales, no se muestran recomendaciones de Advisor.
Para más información sobre Azure Advisor, consulte Introducción a Azure Advisor.