Pruebas de disponibilidad de Application Insights
Después de implementar la aplicación o el sitio web, puede configurar pruebas periódicas para supervisar la disponibilidad y capacidad de respuesta. Application Insights envía solicitudes web a la aplicación a intervalos regulares desde puntos de todo el mundo. Puede enviar una alerta si la aplicación no responde o si responde de manera demasiada lenta. Puede crear hasta 100 pruebas de disponibilidad por recurso de Application Insights.
Las pruebas de disponibilidad no requieren ningún cambio en el sitio web que esté probando y funcionan para cualquier punto de conexión HTTP o HTTPS al que se pueda acceder desde la red pública de Internet. También puede probar la disponibilidad de una API de REST de la que depende su servicio.
Nota:
Las pruebas de disponibilidad se almacenan cifradas, según las directivas de cifrado datos de Azure en reposo.
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
yPOST
), los encabezados personalizados y los datos personalizados asociados a la solicitud HTTP.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.
(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.
Importante
Hay dos próximas retiradas de pruebas de disponibilidad:
Pruebas web de varios pasos: el 31 de agosto de 2024 se retirarán las pruebas web de varios pasos en Application Insights. Recomendamos a los usuarios de estas pruebas que realicen la transición a pruebas de disponibilidad alternativas antes de la fecha de retirada. Después de esta fecha, se quitará la infraestructura subyacente que interrumpirá las pruebas de varios pasos restantes.
Pruebas de ping de URL: el 30 de septiembre de 2026, se retirarán las pruebas de ping de URL de Application Insights. Las pruebas de ping de dirección URL existentes se quitarán de los recursos. Revise los precios correspondientes a las pruebas estándar y la transición a su uso antes del 30 de septiembre de 2026 para asegurarse de que puede seguir ejecutando pruebas de disponibilidad de un solo paso en los recursos de Application Insights.
Creación de una prueba de disponibilidad
Sugerencia
Si actualmente usa otras pruebas de disponibilidad, como las pruebas de ping de URL, puede agregar las pruebas estándar para usarlas junto con las demás. Si quiere usar pruebas estándar en lugar de una de las otras pruebas, agregue una prueba estándar y elimine la anterior.
Requisitos previos
Introducción
Vaya al recurso Application Insights y seleccione el panel Disponibilidad.
Seleccione Agregar prueba estándar.
Escriba el nombre de la prueba, la dirección URL y los demás valores que se describen en la tabla siguiente. Seleccione Crear.
Configuración Descripción URL La dirección URL puede ser cualquier página web que desee probar, pero debe ser visible desde la red pública de Internet. La dirección URL puede incluir una cadena de consulta. Así, por ejemplo, se puede ejercitar un poco la base de datos. Si la dirección URL se resuelve en una redirección, la seguimos, hasta 10 redirecciones. Analizar solicitudes dependientes La prueba solicitará imágenes, scripts, archivos de estilo y otros archivos que forman parte de la página web a prueba. El tiempo de respuesta registrado incluye el tiempo dedicado a obtener estos archivos. La prueba da error si cualquiera de estos recursos no se puede descargar correctamente dentro del tiempo de espera de la prueba entera. Si la opción no está seleccionada, la prueba solo solicitará el archivo en la dirección URL que especificó. Si se habilita esta opción, se realiza una comprobación más estricta. Podría producirse un error en la prueba en ciertos casos y es posible que no lo note al examinar el sitio de forma manual. Tenga en cuenta que solo analizamos hasta 15 solicitudes dependientes. Habilitar reintentos Cuando la prueba da error, se reintenta tras un corto intervalo. Se notifica un error únicamente si los tres intentos sucesivos producen un error. Las sucesivas pruebas se realizan según la frecuencia habitual de la prueba. El reintento se suspende temporalmente hasta que uno se complete correctamente. Esta regla se aplica independientemente en cada ubicación de la prueba. Se recomienda esta opción. Como media, cerca del 80 % de los errores desaparecen al reintentar. SSL certificate validation test (Prueba de validación del certificado SSL) Puede comprobar el certificado SSL de su sitio web para asegurarse de que está instalado correctamente, es válido, es de confianza y no da ningún error a ninguno de los usuarios. Proactive lifetime check (Comprobación proactiva de la duración) Esta configuración le permite definir un período de tiempo establecido antes de que expire el certificado SSL. Después de que expire, se producirá un error en la prueba. Frecuencia de prueba establece la frecuencia con que se ejecuta la prueba desde cada ubicación de prueba. Con una frecuencia predeterminada de cinco minutos y cinco ubicaciones de prueba, el sitio se prueba, de media, cada minuto. Ubicaciones de prueba Nuestros servidores envían solicitudes web a la dirección URL desde estas ubicaciones. El número mínimo de ubicaciones de prueba recomendado es cinco para garantizar que puede distinguir los problemas del sitio web de los problemas de la red. Puede seleccionar hasta 16 ubicaciones. Encabezados personalizados Pares clave-valor que definen los parámetros operativos. HTTP request verb (Verbo de la solicitud HTTP) Indique qué acción desea realizar con la solicitud. Cuerpo de la solicitud Datos personalizados asociados a la solicitud HTTP. Puede cargar sus propios archivos, escribir el contenido o deshabilitar esta característica.
Criterios de éxito
Configuración | Descripción |
---|---|
Tiempo de espera de prueba | reduzca este valor para recibir una alerta sobre las respuestas lentas. La prueba se considera un error si no se han recibido respuestas de su sitio dentro de este período. Si seleccionó Analizar solicitudes dependientes, todas las imágenes, archivos de estilo, scripts y otros recursos dependientes se deben haber recibido durante este período. |
Respuesta HTTP | El código de estado devuelto que se considera correcto. El código que indica que se ha devuelto una página web normal es 200. |
Coincidencia de contenido | En una cadena como "¡Bienvenido!", probamos que se produce una coincidencia exacta entre mayúsculas y minúsculas con una cadena en todas las respuestas. Debe ser una cadena sin formato, sin caracteres comodín. No olvide que, si el contenido cambia, es posible que tenga que actualizarla. En la coincidencia de contenido solo se admiten caracteres en inglés. |
Alertas de disponibilidad
Configuración | Descripción |
---|---|
Casi en tiempo real | Se recomienda usar alertas casi en tiempo real. La configuración de este tipo de alertas se realiza después de crear la prueba de disponibilidad. |
Umbral de la ubicación de la alerta | se recomienda un mínimo de 3/5 ubicaciones. La relación óptima entre el umbral de ubicación de la alerta y el número de ubicaciones de prueba es umbral de ubicación de la alerta = número de ubicaciones de prueba - 2, con un mínimo de cinco ubicaciones de prueba. |
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 de ping de dirección URL de disponibilidad mediante Azure Resource Manager.
Azure
Nombre para mostrar | Nombre de rellenado |
---|---|
Este de Australia | emea-au-syd-edge |
Sur de Brasil | latam-br-gru-edge |
Centro de EE. UU. | us-fl-mia-edge |
Este de Asia | apac-hk-hkn-azr |
Este de EE. UU. | us-va-ash-azr |
Sur de Francia (anteriormente Centro de Francia) | emea-ch-zrh-edge |
Centro de Francia | emea-fr-pra-edge |
Japón Oriental | apac-jp-kaw-edge |
Norte de Europa | emea-gb-db3-azr |
Centro-Norte de EE. UU | us-il-ch1-azr |
Centro-sur de EE. UU. | us-tx-sn1-azr |
Sudeste de Asia | apac-sg-sin-azr |
Oeste de Reino Unido | emea-se-sto-edge |
Oeste de Europa | emea-nl-ams-azr |
Oeste de EE. UU. | us-ca-sjc-azr |
Sur de Reino Unido | emea-ru-msa-edge |
Azure Government
Nombre para mostrar | Nombre de rellenado |
---|---|
USGov Virginia | usgov-va-azr |
USGov: Arizona | usgov-phx-azr |
USGov Texas | usgov-tx-azr |
Departamento de Defensa del este de EE. UU | usgov-ddeast-azr |
Departamento de Defensa de centro de EE. UU. | usgov-ddcentral-azr |
Microsoft Azure operado por 21Vianet
Nombre para mostrar | Nombre de rellenado |
---|---|
Este de China | mc-cne-azr |
Este de China 2 | mc-cne2-azr |
Norte de China | mc-cnn-azr |
Norte de China 2 | mc-cnn2-azr |
Habilitación de alertas
Las alertas ahora se habilitan automáticamente de forma predeterminada, pero para configurar por completo una alerta, debe crear inicialmente la prueba de disponibilidad.
Nota:
Con las nuevas alertas unificadas, la gravedad de la regla de alertas y las preferencias de notificación con grupos de accionesse tienen que configurar en la experiencia de alertas. Sin los pasos siguientes, solo recibirá las notificaciones del portal.
Después de guardar la prueba de disponibilidad, en la pestaña de detalles, seleccione en el signo de puntos suspensivos junto a la prueba que acaba de realizar. Haga clic en la página Abrir reglas (alertas).
Defina 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 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.
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. En el caso de que se programen tiempos de inactividad más largos, puede desactivar temporalmente la regla de alerta o crear una regla personalizada. Esto le proporcionará más opciones para tener en cuenta el tiempo de inactividad.
Modifique los criterios de alerta
Para realizar cambios en el umbral de ubicación, el período de agregación y la frecuencia de prueba, seleccione la condición en la página de edición de la regla de alerta 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:
Seleccione un recurso de Application Insights en la experiencia de métricas y seleccione una métrica de disponibilidad.
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 pestaña Disponibilidad del recurso de Application Insights.
En la vista de gráfico de dispersión se muestran ejemplos de los resultados de las pruebas, que incluyen detalles sobre los pasos de las pruebas de 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. Mantenga el mouse sobre cualquiera de los puntos rojos o verdes para ver la prueba, el nombre de esta y su ubicación.
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, seleccione los puntos suspensivos junto al nombre de la prueba. La propagación de los cambios a todos los agentes de pruebas puede demorar hasta 20 minutos después de realizar un cambio.
Es posible que quiera deshabilitar las pruebas de disponibilidad o las reglas de alerta asociadas a ellas mientras realiza el mantenimiento del servicio.
Si ve errores
Seleccione un punto rojo.
Puede ver los detalles de transacción en todos los componentes desde el resultado de la prueba de disponibilidad. Aquí puede:
- Revise el informe de solución de problemas para determinar qué puede haber provocado que la prueba falle, pero que la aplicación siga disponible.
- 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.
- Registrar un problema o elemento de trabajo en GIT o Azure Boards para realizar un seguimiento del problema. El error contiene un vínculo a este evento.
- 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 el análisis de registros para ver los resultados de disponibilidad, dependencias, etc. Para más información acerca del análisis de registros, visite Introducción a las consultas de registros.
Migración de pruebas de disponibilidad
En este artículo, le guiamos a través del proceso de migración de las pruebas de ping de URL clásicas a las modernas y eficientes pruebas estándar .
Simplificamos este proceso proporcionando instrucciones paso a paso claras para garantizar una transición sin problemas y equipar las aplicaciones con las funcionalidades de supervisión más actualizadas.
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.
Importante
La ejecución de pruebas estándar lleva asociada un coste. Una vez creada una prueba estándar, se le cobrará por las ejecuciones de pruebas. Consulte los precios de Azure Monitor antes de iniciar este proceso.
Requisitos previos
- Cualquier prueba de ping de URL en Application Insights
- Acceso a Azure PowerShell
Introducción
Conéctese a la suscripción con Azure PowerShell (Connect-AzAccount + Set-AzContext).
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;
Busque la prueba de ping de URL que quiere migrar y anote su grupo de recursos y su nombre.
Los siguientes comandos crean una prueba estándar con la misma lógica que la prueba de ping de dirección URL.
Nota:
Los comandos siguientes funcionan para los puntos de conexión HTTP y HTTPS, que se usan en las pruebas de ping de dirección URL.
$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.
Una vez que haya validado la funcionalidad de la nueva prueba estándar, 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. A continuación, deshabilite o elimine la prueba de ping de dirección URL.
Para eliminar una prueba de ping de dirección URL 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.
Advertencia
Las direcciones IP usadas por el servicio de pruebas de disponibilidad se comparten y pueden exponer los puntos de conexión de servicio protegidos por firewall a otras pruebas. El filtrado de direcciones IP solo no protege el tráfico del servicio, por lo que se recomienda agregar encabezados personalizados adicionales para comprobar el origen de la solicitud web. Para más información, consulte Etiquetas de servicio de red virtual.
Autenticación del tráfico
Establezca encabezados personalizados en pruebas de disponibilidad estándar para validar el tráfico.
Genere un token o GUID para identificar el tráfico de las pruebas de disponibilidad.
Agregue el encabezado personalizado "X-Customer-InstanceId" con el valor
ApplicationInsightsAvailability:<GUID generated in step 1>
de la sección "Información de prueba estándar" al crear o actualizar las pruebas de disponibilidad.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 token como parámetro de consulta. Por ejemplo, https://yourtestendpoint/?x-customer-instanceid=applicationinsightsavailability:<your guid>
.
Configuración del firewall para permitir solicitudes entrantes de pruebas de disponibilidad
Nota:
Este ejemplo es específico del uso de etiquetas de servicio del grupo de seguridad de red. Muchos servicios de Azure aceptan etiquetas de servicio, cada una de las cuales requiere distintos pasos de configuración.
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 servicio
ApplicationInsightsAvailability
se aplica a todas las pruebas de disponibilidad.Si usa grupos de seguridad de red de Azure, vaya al recurso del grupo de seguridad de red y, en Configuración, seleccione Reglas de seguridad de entrada. A continuación, seleccione Agregar.
Luego, seleccione Etiqueta de servicio como origen y ApplicationInsightsAvailability como 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.
En el recurso del grupo de seguridad de red, en Configuración, seleccione Reglas de seguridad de entrada. A continuación, seleccione Agregar.
A continuación, seleccione Direcciones IP como origen. Luego, agregue las direcciones IP a una lista delimitada por comas en intervalos de direcciones IP/CIRD de origen.
Escenarios desconectados o sin entrada
Conecte el recurso de Application Insights al punto de conexión de servicio interno mediante Azure Private Link.
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.
Nota:
TLS 1.3 solo está disponible actualmente en estas regiones de prueba de disponibilidad: NorthCentralUS, CentralUS, EastUS, SouthCentralUS y WestUS.
TLS 1.2
Conjuntos de cifrado
- TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
Curvas elípticas
- NistP384
- NistP256
TLS 1.3
Conjuntos de cifrado
- TLS_AES_256_GCM_SHA384
- TLS_AES_128_GCM_SHA256
Curvas elípticas:
- NistP384
- NistP256
Desuso de la configuración de TLS
Advertencia
El 31 de octubre de 2024, en consonancia con el desuso de TLS heredado de Azure se retirarán las versiones de protocolo TLS 1.0/1.1 y los conjuntos de cifrado y curvas elípticas TLS 1.2/1.3 heredados enunciados a continuación para las pruebas de disponibilidad de Application Insights.
TLS 1.0 y TLS 1.1
Ya no se admitirán las versiones de protocolo.
TLS 1.2
Conjuntos de cifrado
- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
- TLS_RSA_WITH_AES_256_GCM_SHA384
- TLS_RSA_WITH_AES_128_GCM_SHA256
- TLS_RSA_WITH_AES_256_CBC_SHA256
- TLS_RSA_WITH_AES_128_CBC_SHA256
- TLS_RSA_WITH_AES_256_CBC_SHA
- TLS_RSA_WITH_AES_128_CBC_SHA
Curvas elípticas:
- curve25519
TLS 1.3
Curvas elípticas
- curve25519
Solución de problemas
Advertencia
Recientemente hemos habilitado TLS 1.3 en las pruebas de disponibilidad. Si ve nuevos mensajes de error como resultado, asegúrese de que los clientes que se ejecutan en Windows Server 2022 con TLS 1.3 habilitado pueden conectarse al punto de conexión. Si no puede hacerlo, considere la posibilidad de deshabilitar temporalmente TLS 1.3 en el punto de conexión para que las pruebas de disponibilidad vuelvan a versiones anteriores de TLS.
Para obtener más información, consulte el artículo de solución de problemas.
Consulte el artículo de solución de problemas dedicado.
Libro sobre tiempo de inactividad, Acuerdo de Nivel de Servicio e interrupciones
En este artículo, 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 el panel Disponibilidad y seleccione Informe de Acuerdo de Nivel de Servicio en la parte superior de la pantalla.
Abra el panel Libros y seleccione 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
yWeb 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
yOutage 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 están definida entre cuando una prueba comienza a devolver errores hasta que se realiza correctamente, en función de 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
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.
Editar el informe
Puede editar el informe como cualquier otro libro de Azure Monitor.
Puede personalizar las consultas o visualizaciones en función de las necesidades de su equipo.
Log Analytics
Todas las consultas se pueden ejecutar en Log Analytics y usarse 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 o 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?
Nuestras pruebas web se ejecutan en puntos de presencia que están repartidos por 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.
Nota:
Para conocer los pasos necesarios para habilitar la configuración de TLS necesaria en el servidor web, es mejor ponerse en contacto con el equipo que posee la plataforma de hospedaje en la que se ejecuta el servidor web si no se conoce el proceso.
Después del 31 de octubre de 2024, ¿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?
El desuso de TLS detallado en este documento solo debe afectar al comportamiento de ejecución de pruebas web de prueba de disponibilidad después del 31 de octubre de 2024. 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.