Pruebas de disponibilidad de Application Insights

Application Insights le permite configurar pruebas web periódicas que supervisan la disponibilidad y la capacidad de respuesta de su sitio web o aplicación desde varios puntos del mundo. Estas pruebas de disponibilidad envían solicitudes web a la aplicación a intervalos regulares y le avisan si la aplicación no responde o si el tiempo de respuesta es demasiado lento.

Las pruebas de disponibilidad no requieren modificaciones en el sitio web o la aplicación que está probando. Funcionan para cualquier punto de conexión HTTP o HTTPS accesible desde la red pública de Internet, incluidas las API REST de las que depende el servicio. Esto significa que puede supervisar no solo sus propias aplicaciones, sino también servicios externos que son críticos para la funcionalidad de la aplicación. Puede crear hasta 100 pruebas de disponibilidad por recurso de Application Insights.

Tipos de pruebas de disponibilidad

Hay cuatro tipos de pruebas de disponibilidad:

• Prueba estándar: tipo de prueba de disponibilidad que comprueba la disponibilidad de un sitio web mediante el envío de una única solicitud, similar a la prueba de ping de URL en desuso. Además de validar si un punto de conexión responde y medir el rendimiento, las pruebas estándar también incluyen la validez del certificado TLS/SSL, la comprobación proactiva de la vigencia, el verbo de solicitud HTTP (por ejemplo, GET, HEAD y POST), los encabezados personalizados y los datos personalizados asociados a la solicitud HTTP.

  Aprenda a crear una prueba estándar.

• Prueba TrackAvailability personalizada: si decide crear una aplicación personalizada para ejecutar pruebas de disponibilidad, puede usar el método TrackAvailability() para enviar los resultados a Application Insights.

  Aprenda a crear una prueba TrackAvailability personalizada.

• (En desuso) Prueba web de varios pasos: puede reproducir esta grabación de una secuencia de solicitudes web para probar escenarios más complejos. Las pruebas web de varios pasos se crean en Visual Studio Enterprise y se cargan en el portal, donde puede ejecutarlas.

• (En desuso) Prueba de ping de URL: puede crear esta prueba mediante Azure Portal para validar si un punto de conexión está respondiendo y medir el rendimiento asociado a esa respuesta. También puede establecer criterios de éxito personalizados junto con características más avanzadas, como analizar solicitudes dependientes y permitir reintentos.

Creación de una prueba de disponibilidad

Alertas de disponibilidad

Las alertas se habilitan automáticamente de forma predeterminada, pero para configurar por completo una alerta, debe crear inicialmente la prueba de disponibilidad.

Etiquetas para rellenar la ubicación

Se pueden usar las siguientes etiquetas de rellenado para el atributo de ubicación geográfica al implementar una prueba Estándar o una prueba de ping de dirección URL mediante Azure Resource Manager.

Habilitación de alertas

1. Después de guardar la prueba de disponibilidad, abra el menú contextual de la prueba que realizó y, a continuación, seleccione la página Abrir reglas (alertas).

   

2. En la página Reglas de alerta, abra la alerta y seleccione Editar en la barra de navegación superior. Aquí se puede establecer el nivel de gravedad, la descripción de la regla, el grupo de acción que tiene las preferencias de notificación que quiere usar para esta regla de alerta.

   

Criterios de alerta

Las alertas de disponibilidad habilitadas automáticamente desencadenarán un correo electrónico cuando el punto de conexión que haya definido no esté disponible y otro correo electrónico cuando esté disponible de nuevo. Las alertas de disponibilidad creadas a través de esta experiencia están basadas en el estado. Cuando se cumplan los criterios de alerta, se generará una única alerta cuando el sitio se detecte como no disponible. Si el sitio sigue fuera de servicio la próxima vez que se evalúen los criterios de alerta, no se generará una nueva alerta.

Por ejemplo, suponga que el sitio web está inactivo durante una hora y ha configurado una alerta por correo electrónico con una frecuencia de evaluación de 15 minutos. Solo recibirá un correo electrónico cuando el sitio web deje de funcionar y otro correo electrónico cuando vuelva a estar en línea. No recibirá alertas continuas cada 15 minutos recordándole que el sitio web sigue sin estar disponible.

Modifique los criterios de alerta

Es posible que no quiera recibir notificaciones cuando el sitio web esté inactivo durante un breve período de tiempo, por ejemplo, durante el mantenimiento. Puede cambiar la frecuencia de evaluación a un valor mayor que el tiempo de inactividad esperado, hasta 15 minutos. También puede aumentar el umbral de ubicación de la alerta, para que solo desencadene una alerta si el sitio web está fuera de servicio en un determinado número de regiones.

Para realizar cambios en el umbral de ubicación, el período de agregación y la frecuencia de prueba, vaya a la página Editar regla de alertas (consulte el paso 2 en Habilitar alertas) y seleccione la condición para abrir la ventana Configurar lógica de señal.

Creación de una regla de alertas personalizada

Si necesita funcionalidades avanzadas, puede crear una regla de alerta personalizada desde la pestaña Alertas. Seleccione Crear>Regla de alerta. Elija Métricas para Tipo de señal para que se muestren todas las señales disponibles y seleccione Disponibilidad.

Una regla de alerta personalizada ofrece valores más altos para el período de agregación (hasta 24 horas en lugar de 6 horas) y la frecuencia de prueba (hasta 1 hora en lugar de 15 minutos). También agrega opciones para definir aún más la lógica seleccionando diferentes operadores, tipos de agregación y valores de umbral.

• Alerta sobre errores en X de Y ubicaciones: la regla de alerta de X de Y ubicaciones se habilita de forma predeterminada en la nueva experiencia de alertas unificadas cuando se crea una prueba de disponibilidad. Puede cancelar esta acción si selecciona la opción "clásica" o si deshabilita la regla de alertas. Siga los pasos anteriores para configurar los grupos de acciones y recibir notificaciones cuando se desencadene la alerta. Sin este paso, solo recibirá las notificaciones en el portal cuando se desencadene la regla.

• Alerta sobre métricas de disponibilidad: mediante las nuevas alertas unificadas, también puede generar alertas sobre la disponibilidad agregada segmentada y las métricas de duración de la prueba:

  1. Seleccione un recurso de Application Insights en la experiencia de métricas y seleccione una métrica de disponibilidad.

  2. Al configurar la opción de alertas desde el menú se abrirá la nueva experiencia, donde podrá seleccionar pruebas o ubicaciones específicas para establecer la regla de alertas. También puede configurar los grupos de acciones para esta regla de alertas.

• Alerta sobre consultas de análisis personalizadas: mediante las nuevas alertas unificadas, puede generar alertas sobre las consultas de registro personalizadas. Con las consultas personalizadas, puede enviar alertas sobre cualquier condición arbitraria que le ayude a obtener los indicadores de problemas de disponibilidad más fiables. Esta opción también la puede usar si envía resultados personalizados de disponibilidad mediante el SDK de TrackAvailability.

  Las métricas sobre datos de disponibilidad incluyen los resultados personalizados de disponibilidad que puede enviar mediante una llamada a nuestro SDK de TrackAvailability. Puede usar la compatibilidad con las alertas sobre métricas para generar alertas sobre resultados personalizados de disponibilidad.

Automatización de alertas

Para automatizar este proceso con plantillas de Azure Resource Manager, consulte Creación de una alerta de métrica con una plantilla de Resource Manager.

Visualización de los resultados de las pruebas de disponibilidad

En esta sección se explica cómo revisar los resultados de la prueba de disponibilidad en Azure Portal y consultar los datos mediante Log Analytics. Los resultados de la prueba de disponibilidad se pueden visualizar mediante vistas de línea y de gráfico de dispersión.

Comprobación de la disponibilidad

Empiece por revisar el gráfico en la experiencia Disponibilidad de Azure Portal.

De forma predeterminada, la experiencia Disponibilidad muestra un gráfico de líneas. Cambie la vista al gráfico de dispersión (alternar encima del gráfico) para ver ejemplos de los resultados de la prueba que incluyen detalles sobre los pasos de las pruebas diagnóstico. El motor de pruebas almacena los detalles de diagnóstico de las pruebas con errores. En el caso de las pruebas correctas, los detalles de diagnóstico se almacenan para un subconjunto de las ejecuciones. Para ver esta prueba, el nombre de esta y la ubicación, mueva el puntero sobre cualquiera de los puntos verdes o cruces rojas.

Seleccione una prueba o ubicación determinada. O bien, puede reducir el período de tiempo para ver más resultados del período de tiempo que le interese. Use el Explorador de búsqueda para ver los resultados de todas las ejecuciones. También puede usar consultas de Log Analytics para ejecutar informes personalizados en estos datos.

Para ver los detalles de la transacción completa, en Aumentar detalle seleccione Correcto o Erróneo. Luego, seleccione una muestra. También puede obtener los detalles de la transacción de un extremo a otro seleccionando un punto de datos en el gráfico.

Inspección y edición de pruebas

Para editar, deshabilitar temporalmente o eliminar una prueba, abra el menú contextual (puntos suspensivos) por la prueba y, a continuación, seleccione Editar. La propagación de los cambios a todos los agentes de pruebas puede demorar hasta 20 minutos después de realizar un cambio.

Si ve errores

Para abrir la vista Detalles de transacción de un extremo a otro, seleccione una cruz roja en el gráfico de dispersión.

Aquí puede:

• Revise el Informe de solución de problemas para determinar lo que podría hacer que se produzca un error en la prueba.
• Inspeccionar la respuesta recibida desde el servidor.
• Diagnosticar errores con la telemetría de lado servidor correlacionada que se recopiló durante el procesamiento de la prueba de disponibilidad con error.
• Realice un seguimiento del problema mediante el registro de una incidencia o de un elemento de trabajo en Git o Azure Boards. El error contiene un vínculo al evento en Azure Portal.
• Abra el resultado de la prueba web en Visual Studio.

Para más información sobre la experiencia completa de diagnóstico de transacciones, consulte la documentación sobre el diagnóstico de transacciones.

Seleccione la fila de excepciones para ver los detalles de la excepción del lado servidor que ha provocado un error en la prueba de disponibilidad sintética. También puede obtener la instantánea de depuración para realizar diagnósticos de nivel de código más completos.

Además de los resultados sin formato, también puede ver dos métricas de disponibilidad clave en el Explorador de métricas:

• Disponibilidad: porcentaje de las pruebas que obtuvieron resultados satisfactorios en todas las ejecuciones.
• Duración de la prueba: duración media de las pruebas en todas las ejecuciones.

Consulta en análisis de registros

Puede usar Log Analytics para ver los resultados de disponibilidad (availabilityResults), dependencias (dependencies) y mucho más. Para más información acerca del análisis de registros, visite Introducción a las consultas de registros.

Migración de pruebas de ping de URL clásicas a pruebas estándar

Los pasos siguientes le guiarán por el proceso de creación de pruebas estándar que replican la funcionalidad de las pruebas de ping de dirección URL. Permite empezar más fácilmente a usar las características avanzadas de las pruebas estándar mediante las pruebas de ping de URL creadas anteriormente.

Requisitos previos

Introducción

1. Conéctese a la suscripción con Azure PowerShell (Connect-AzAccount + Set-AzContext).

2. Indique todas las pruebas de ping de URL en la suscripción actual:

   Get-AzApplicationInsightsWebTest | `
   Where-Object { $_.WebTestKind -eq "ping" } | `
   Format-Table -Property ResourceGroupName,Name,WebTestKind,Enabled;
   

3. Busque la prueba de ping de URL que quiere migrar y anote su grupo de recursos y su nombre.

4. Cree una prueba estándar con la misma lógica que la prueba de ping de dirección URL mediante los siguientes comandos, que funcionan para los puntos de conexión HTTP y HTTPS.

   $resourceGroup = "pingTestResourceGroup";
   $appInsightsComponent = "componentName";
   $pingTestName = "pingTestName";
   $newStandardTestName = "newStandardTestName";
   
   $componentId = (Get-AzApplicationInsights -ResourceGroupName $resourceGroup -Name $appInsightsComponent).Id;
   $pingTest = Get-AzApplicationInsightsWebTest -ResourceGroupName $resourceGroup -Name $pingTestName;
   $pingTestRequest = ([xml]$pingTest.ConfigurationWebTest).WebTest.Items.Request;
   $pingTestValidationRule = ([xml]$pingTest.ConfigurationWebTest).WebTest.ValidationRules.ValidationRule;
   
   $dynamicParameters = @{};
   
   if ($pingTestRequest.IgnoreHttpStatusCode -eq [bool]::FalseString) {
   $dynamicParameters["RuleExpectedHttpStatusCode"] = [convert]::ToInt32($pingTestRequest.ExpectedHttpStatusCode, 10);
   }
   
   if ($pingTestValidationRule -and $pingTestValidationRule.DisplayName -eq "Find Text" `
   -and $pingTestValidationRule.RuleParameters.RuleParameter[0].Name -eq "FindText" `
   -and $pingTestValidationRule.RuleParameters.RuleParameter[0].Value) {
   $dynamicParameters["ContentMatch"] = $pingTestValidationRule.RuleParameters.RuleParameter[0].Value;
   $dynamicParameters["ContentPassIfTextFound"] = $true;
   }
   
   New-AzApplicationInsightsWebTest @dynamicParameters -ResourceGroupName $resourceGroup -Name $newStandardTestName `
   -Location $pingTest.Location -Kind 'standard' -Tag @{ "hidden-link:$componentId" = "Resource" } -TestName $newStandardTestName `
   -RequestUrl $pingTestRequest.Url -RequestHttpVerb "GET" -GeoLocation $pingTest.PropertiesLocations -Frequency $pingTest.Frequency `
   -Timeout $pingTest.Timeout -RetryEnabled:$pingTest.RetryEnabled -Enabled:$pingTest.Enabled `
   -RequestParseDependent:($pingTestRequest.ParseDependentRequests -eq [bool]::TrueString);
   

   De manera predeterminada, la nueva prueba estándar no tiene reglas de alerta, por lo que no crea alertas molestas. No se realizan cambios en la prueba de ping de dirección URL, por lo que puede seguir confiando en ella para las alertas.

5. Valide la funcionalidad de la nueva prueba estándar y, después, actualice las reglas de alerta que hacen referencia a la prueba de ping de dirección URL para hacer referencia a la prueba estándar en su lugar.

6. Deshabilite o elimine la prueba de ping de dirección URL. Para ello, con Azure PowerShell, puede usar este comando:

   Remove-AzApplicationInsightsWebTest -ResourceGroupName $resourceGroup -Name $pingTestName;
   

Pruebas detrás de un servidor de seguridad

Para garantizar la disponibilidad del punto de conexión detrás de los firewalls, habilite las pruebas de disponibilidad pública o ejecute pruebas de disponibilidad en escenarios de entrada desconectados o sin entrada.

Habilitación de zonas de disponibilidad públicas

Asegúrese de que el sitio web interno tiene un registro público del sistema de nombres de dominio (DNS). Se produce un error en las pruebas de disponibilidad si no se puede resolver DNS. Para más información, consulte el artículo sobre la creación de un nombre de dominio personalizado para la aplicación interna.

Autenticación del tráfico

Establezca encabezados personalizados en pruebas estándar para validar el tráfico.

1. Cree una cadena alfanumérica sin espacios para identificar esta prueba de disponibilidad (por ejemplo, MyAppAvailabilityTest). Desde aquí, nos referimos a esta cadena como el identificador de cadena de la prueba de disponibilidad.

2. Agregue el encabezado personalizado X-Customer-InstanceId con el valor ApplicationInsightsAvailability:<your availability test string identifier> de la sección Información de prueba estándar al crear o actualizar las pruebas de disponibilidad.

   

3. Asegúrese de que el servicio comprueba si el tráfico entrante incluye el encabezado y el valor definidos en los pasos anteriores.

Como alternativa, establezca el identificador de cadena de prueba de disponibilidad como parámetro de consulta.

Ejemplo: https://yourtestendpoint/?x-customer-instanceid=applicationinsightsavailability:<your availability test string identifier>

Configuración del firewall para permitir solicitudes entrantes de pruebas de disponibilidad

Para simplificar la habilitación de los servicios Azure sin autorizar direcciones IP individuales ni mantener una lista actualizada de direcciones IP, use las Etiquetas de servicio. Aplique estas etiquetas en Azure Firewall y grupos de seguridad de red, lo que permite el acceso del servicio de prueba de disponibilidad a los puntos de conexión. La etiqueta de servicioApplicationInsightsAvailability se aplica a todas las pruebas de disponibilidad.

1. Si usa grupos de seguridad de red de Azure, vaya al recurso del grupo de seguridad de red y, en Configuración, abra la experiencia Reglas de seguridad de entrada y, después, seleccione Agregar.

2. Luego, seleccione Etiqueta de servicio como origen y ApplicationInsightsAvailability como la etiqueta de servicio de origen. Use los puertos abiertos 80 (http) y 443 (https) para el tráfico entrante desde la etiqueta de servicio.

Para administrar el acceso cuando sus puntos de conexión están fuera de Azure o cuando las etiquetas de servicio no son una opción, permita las Direcciones IP de nuestros agentes de prueba web. Puede consultar intervalos IP mediante PowerShell, la CLI de Azure o una llamada REST con la API de etiquetas de servicio. Para obtener una lista completa de las etiquetas de servicio actuales y sus detalles de IP, descargue el Archivo JSON.

1. En el recurso del grupo de seguridad de red, en Configuración, abra la experiencia Reglas de seguridad de entrada y seleccione Agregar.

2. A continuación, seleccione Direcciones IP como origen. Después, agregue las direcciones IP a una lista delimitada por comas en intervalos de direcciones IP/CIRD de origen.

Escenarios desconectados o sin entrada

1. Conecte el recurso de Application Insights al punto de conexión de servicio interno mediante Azure Private Link.

2. Escriba código personalizado para comprobar periódicamente el servidor interno o los puntos de conexión. Envíe los resultados a Application Insights mediante la API de TrackAvailability() en el paquete del SDK principal.

Configuraciones de TLS admitidas

Para proporcionar el mejor cifrado de clase, todas las pruebas de disponibilidad usan Seguridad de la capa de transporte (TLS) 1.2 y 1.3 como mecanismo de cifrado de preferencia. Además, los siguientes conjuntos de cifrado y curvas elípticas también se admiten en cada versión.

TLS 1.3 solo está disponible actualmente en estas regiones de prueba de disponibilidad: NorthCentralUS, CentralUS, EastUS, SouthCentralUS y WestUS.

Desuso de la configuración de TLS

TLS 1.0 y TLS 1.1

TLS 1.0 y TLS 1.1 se están retirando.

TLS 1.2 y TLS 1.3

Solución de problemas

Libro de tiempo de inactividad e interrupciones

En esta sección, se presenta una manera simple de calcular e informar sobre el Acuerdo de Nivel de Servicio para las pruebas web a través de un panel único para todos los recursos de Application Insights y las suscripciones a Azure. El informe sobre tiempo de inactividad e interrupciones proporciona eficaces consultas y visualizaciones de datos generadas previamente para mejorar su comprensión de la conectividad del cliente, el tiempo de respuesta típico de la aplicación y el tiempo de inactividad ocurrido.

Se puede acceder a la plantilla de libro del Acuerdo de Nivel de Servicio desde el recurso de Application Insights de dos maneras:

• Abra la experiencia Disponibilidad y seleccione Informe de Acuerdo de Nivel de Servicio en la barra de navegación superior.

• Abra la experiencia Libros y, a continuación, seleccione la plantilla Tiempo de inactividad e interrupciones.

Flexibilidad de parámetros

Los parámetros establecidos en el libro influyen en el resto del informe.

• Subscriptions, App Insights Resources y Web Test: estos parámetros determinan las opciones de recursos generales disponibles. Se basan en consultas de Log Analytics y se usan en todas las consultas de informe.
• Failure Threshold y Outage Window: puede usar estos parámetros para determinar sus criterios propios para una interrupción del servicio. Un ejemplo son los criterios para una alerta de disponibilidad de Application Insights en función de un contador de las ubicaciones con error durante un período elegido. El umbral típico es de tres ubicaciones en un período de cinco minutos.
• Maintenance Period: puede usar este parámetro para seleccionar la frecuencia de mantenimiento típica. Maintenance Window es un selector de fecha y hora para un período de mantenimiento de ejemplo. Todos los datos que se produzcan durante el período identificado se omitirán en los resultados.
• Availability Target %: este parámetro especifica el objetivo de destino y toma valores personalizados.

Página de información general

La página de información general contiene información sobre lo siguiente:

• El Acuerdo de Nivel de Servicio total (excepto los períodos de mantenimiento, si se definen)
• Las instancias de interrupción de un extremo a otro
• Tiempo de inactividad de la aplicación

Las instancias de interrupción se determinan desde el momento en que una prueba comienza a producir un error hasta que se supera correctamente de nuevo, según los parámetros de interrupción. Si se produce un error en una prueba a las 8:00 a. m. y se realiza de nuevo a las 10:00 a. m., todo el período de datos se considera como la misma interrupción. También puede investigar la interrupción más larga que se produjo durante el período del informe.

Algunas pruebas se pueden vincular al recurso de Application Insights correspondiente para una mejor inspección, pero eso solo es posible en el recurso de Application Insights basado en áreas de trabajo.

Tiempo de inactividad, interrupciones y errores

Hay dos pestañas más junto a la página Información general:

• La pestaña Interrupciones y tiempo de inactividad tiene información sobre las instancias de interrupción total y el tiempo de inactividad total desglosado por prueba.

• La pestaña Errores por ubicación incluye un mapa geográfico de ubicaciones de prueba con errores para ayudarlo a identificar las áreas de conexión problemáticas posibles.

Otras características

• Personalización: puede editar el informe como cualquier otro libro de Azure Monitor y personalizar las consultas o visualizaciones en función de las necesidades del equipo.

• Log Analytics: todas las consultas se pueden ejecutar en Log Analytics y se usan en otros informes o paneles. Quite la restricción de parámetros y reutilice la consulta principal.

• Acceso y uso compartido: el informe se puede compartir con sus equipos o con la dirección, o bien pueden anclarse a un panel para su uso posterior. El usuario debe tener permisos de lectura y acceso al recurso de Application Insights en el que se almacena el libro real.

Preguntas más frecuentes

Esta sección proporciona respuestas a preguntas comunes.

General

¿Puedo ejecutar pruebas de disponibilidad en un servidor de intranet?

Las pruebas de disponibilidad se ejecutan en puntos de presencia que se distribuyen en todo el mundo. Hay dos soluciones:

• Puerta de firewall: permitir solicitudes al servidor desde la lista larga y modificable de agentes de prueba web.
• Código personalizado: escribir su propio código para enviar solicitudes periódicas a su servidor desde dentro de la intranet. Con este fin, puede ejecutar pruebas web de Visual Studio. El evaluador puede enviar los resultados a Application Insights mediante la API TrackAvailability().

¿Cuál es la cadena del agente de usuario para las pruebas de disponibilidad?

La cadena del agente de usuario es Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0; AppInsights)

Soporte técnico de TLS

¿Cómo afecta esta desuso a mi comportamiento de prueba web?

Las pruebas de disponibilidad actúan como un cliente distribuido en cada una de las ubicaciones de prueba web admitidas. Cada vez que se ejecuta una prueba web, el servicio de prueba de disponibilidad intenta ponerse en contacto con el punto de conexión remoto definido en la configuración de prueba web. Se envía un mensaje de Hello de TLS Client que contiene toda la configuración de TLS admitida actualmente. Si el punto de conexión remoto comparte una configuración TLS común con el cliente de prueba de disponibilidad, el protocolo de enlace TLS se realiza correctamente. De lo contrario, se produce un error en la prueba web con un error de protocolo de enlace TLS.

¿Cómo puedo asegurarme de que mi prueba web no se vea afectada?

Para evitar cualquier impacto, cada punto de conexión remoto (incluidas las solicitudes dependientes) con la que interactúa la prueba web debe admitir al menos una combinación de la misma versión de protocolo, conjunto de cifrado y curva elíptica que realiza la prueba de disponibilidad. Si el punto de conexión remoto no admite la configuración de TLS necesaria, debe actualizarse con compatibilidad con alguna combinación de la configuración de TLS posterior al desuso mencionado anteriormente. Estos puntos de conexión se pueden detectar mediante la visualización de los Detalles de transacción de la prueba web (idealmente para una ejecución correcta de pruebas web).

¿Cómo se valida la configuración de TLS que admite un punto de conexión remoto?

Hay varias herramientas disponibles para probar qué configuración de TLS admite un punto de conexión. Una manera sería seguir el ejemplo detallado en esta página. Si el punto de conexión remoto no está disponible a través de la red pública de Internet, debe asegurarse de validar la configuración de TLS admitida en el punto de conexión remoto desde una máquina que tenga acceso para llamar al punto de conexión.

Después del 1 de marzo de 2025, ¿cuál será el comportamiento de la prueba web para las pruebas afectadas?

No hay ningún tipo de excepción en el que todos los errores de protocolo de enlace TLS afectados por este desuso se presentarían a sí mismos. Sin embargo, la excepción más común con la que la prueba web empezaría a producir errores sería The request was aborted: Couldn't create SSL/TLS secure channel. También debería poder ver los errores relacionados con TLS en el Paso de solución de problemas Transporte de TLS para el resultado de la prueba web que podría verse afectado.

¿Puedo ver qué configuración de TLS está usando actualmente mi prueba web?

La configuración de TLS negociada durante una ejecución de prueba web no se puede ver. Siempre que el punto de conexión remoto admita la configuración de TLS común con pruebas de disponibilidad, no se debería ver ningún impacto después del desuso.

¿Qué componentes afecta el desuso en el servicio de prueba de disponibilidad?

La desuso de TLS detallada en este documento solo debe afectar al comportamiento de ejecución de pruebas web de prueba de disponibilidad después del 1 de marzo de 2025. Para más información sobre cómo interactuar con el servicio de prueba de disponibilidad para las operaciones CRUD, consulte Compatibilidad con TLS de Azure Resource Manager. Este recurso proporciona más detalles sobre la compatibilidad y las escalas de tiempo de desuso de TLS.

¿Dónde puedo obtener compatibilidad con TLS?

Para ver cualquier pregunta general sobre el problema de TLS heredado, consulte Solución de problemas de TLS.

Pasos siguientes

• Solución de problemas
• Plantilla de Azure Resource Manager para pruebas web
• API de REST de prueba web