Pruebas de disponibilidad de Application Insights

Artículo
2025-04-30

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.

Nota:

Las pruebas de disponibilidad se almacenan cifradas, según las directivas de cifrado de 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 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.

Importante

Hay dos próximas retiradas de pruebas de disponibilidad:

Pruebas web de varios pasos: Application Insights retira las pruebas web de varios pasos el 31 de agosto de 2024. Para mantener la supervisión de disponibilidad, cambie a pruebas de disponibilidad alternativas antes de esta fecha. Después de la retirada, la plataforma quita la infraestructura subyacente, lo que hace que se produzcan errores en 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. Se eliminan las pruebas de ping de URL existentes de tus 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.

Requisitos previos

Recurso de Application Insights basado en área de trabajo

Primeros pasos

Vaya al recurso de Application Insights y abra la experiencia Disponibilidad.
Seleccione Agregar prueba estándar en la barra de navegación superior.

Escriba el nombre de la prueba, la dirección URL y los demás valores que se describen en la tabla siguiente; a continuación, seleccione Crear.

Sección	Configuración	Descripción
Basic Information (Información básica)
	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 carga imágenes, scripts, archivos de estilo y otros recursos de la página web en prueba. Registra el tiempo de respuesta, incluido el tiempo para recuperar estos archivos. Se produce un error en la prueba si no puede descargar todos los recursos dentro del tiempo de espera. Si no habilita la opción, la prueba solo carga el archivo en la dirección URL especificada. Habilitarla hace que el comprobador sea más estricto, lo que podría generar errores en los casos en los que la exploración manual no se detectaría. La prueba analiza hasta 15 solicitudes dependientes.
	Habilitar reintentos para las pruebas de disponibilidad con errores	Cuando la prueba da un 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 el próximo éxito. 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.
	Habilitar la validación del certificado SSL	Para confirmar la configuración correcta, compruebe el certificado SSL en su sitio web. Asegúrese de que está instalado correctamente, válido, de confianza y de que no genera errores para los usuarios. La prueba de disponibilidad solo valida el certificado SSL en la URL final redirigida.
	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.
Información de la prueba estándar
	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.
	Agregar encabezados personalizados	Pares clave-valor que definen los parámetros operativos. Los encabezados "Host" y "User-Agent" están reservados en pruebas de disponibilidad y no se pueden modificar ni sobrescribir.
Criterios de éxito
	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 tienen que recibir durante este período.
	Respuesta HTTP	El código de estado devuelto se cuenta como un éxito. El código que indica que se ha devuelto una página web normal es 200.
	Coincidencia de contenido	Una cadena, como "Bienvenido". Probamos que se produce una coincidencia exacta entre mayúsculas y minúsculas en todas las respuestas. Debe ser una cadena sin formato, sin caracteres comodín. No olvide que, si el contenido de su página cambia, es posible que tenga que actualizarlo. En la coincidencia de contenido solo se admiten caracteres en inglés.

Importante

TrackAvailability() requiere realizar una inversión de desarrollador al escribir y mantener código personalizado potencialmente complejo.

Las pruebas estándar deben usarse siempre que sea posible, ya que requieren poca inversión, cero mantenimiento y tienen pocos requisitos previos.

Este ejemplo se ha diseñado únicamente para mostrar la mecánica de cómo actúa la llamada API de TrackAvailability() en una aplicación de Azure Functions. No muestra cómo se escribe el código de prueba HTTP o la lógica de negocios subyacentes que se necesitarían para convertir esta llamada en un ejemplo de disponibilidad totalmente funcional.

Requisitos previos

Recurso de Application Insights basado en área de trabajo
Acceso al código fuente de una aplicación de Azure Functions
Experiencia del desarrollador para crear código personalizado para TrackAvailability(), adaptado a sus necesidades empresariales específicas

Comienza

Nota:

Para seguir estas instrucciones, debe usar el plan deApp Service o el plan Premium de Functions para permitir la edición de código en el Editor de App Service. También debe elegir una versión en ejecución que admita el modelo en proceso.

Si está probando detrás de una red virtual o probando puntos de conexión no públicos, debe usar el plan Functions Premium.

Creación de una función de desencadenador de temporizador

Cree un recurso de Azure Functions con la siguiente consideración:
- Si aún no tiene un recurso de Application Insights para la función desencadenada por el temporizador, se crea de forma predeterminada al crear una aplicación de Azure Functions.
- Si ya tiene un recurso de Application Insights, vaya a la pestaña Supervisión al crear la aplicación de Azure Functions y seleccione o escriba el nombre del recurso existente en la lista desplegable Application Insights:
Siga las instrucciones para crear una función desencadenada por el temporizador.

Adición y edición de código en el editor de App Service

Vaya a la aplicación de Azure Functions implementada y, en Herramientas de desarrollo, seleccione la pestaña Editor de App Service.

Para crear un nuevo archivo, haga clic con el botón derecho en la función de desencadenador de temporizador (por ejemplo, TimerTrigger1) y seleccione Nuevo archivo. A continuación, escriba el nombre del archivo y seleccione Introducir.

Cree un archivo nuevo denominado function.proj y pegue en él el código siguiente:

<Project Sdk="Microsoft.NET.Sdk"> 
    <PropertyGroup> 
        <TargetFramework>netstandard2.0</TargetFramework> 
    </PropertyGroup> 
    <ItemGroup> 
        <PackageReference Include="Microsoft.ApplicationInsights" Version="2.15.0" /> <!-- Ensure you're using the latest version --> 
    </ItemGroup> 
</Project>

Cree un archivo nuevo denominado runAvailabilityTest.csx y pegue el código siguiente:

using System.Net.Http; 

public async static Task RunAvailabilityTestAsync(ILogger log) 
{ 
    using (var httpClient = new HttpClient()) 
    { 
        // TODO: Replace with your business logic 
        await httpClient.GetStringAsync("https://www.bing.com/"); 
    } 
}

Reemplace el código existente de run.csx por lo siguiente:

#load "runAvailabilityTest.csx" 

using System; 

using System.Diagnostics; 

using Microsoft.ApplicationInsights; 

using Microsoft.ApplicationInsights.Channel; 

using Microsoft.ApplicationInsights.DataContracts; 

using Microsoft.ApplicationInsights.Extensibility; 

private static TelemetryClient telemetryClient; 

// ============================================================= 

// ****************** DO NOT MODIFY THIS FILE ****************** 

// Business logic must be implemented in RunAvailabilityTestAsync function in runAvailabilityTest.csx 

// If this file does not exist, add it first 

// ============================================================= 

public async static Task Run(TimerInfo myTimer, ILogger log, ExecutionContext executionContext) 

{ 
    if (telemetryClient == null) 
    { 
        // Initializing a telemetry configuration for Application Insights based on connection string 

        var telemetryConfiguration = new TelemetryConfiguration(); 
        telemetryConfiguration.ConnectionString = Environment.GetEnvironmentVariable("APPLICATIONINSIGHTS_CONNECTION_STRING"); 
        telemetryConfiguration.TelemetryChannel = new InMemoryChannel(); 
        telemetryClient = new TelemetryClient(telemetryConfiguration); 
    } 

    string testName = executionContext.FunctionName; 
    string location = Environment.GetEnvironmentVariable("REGION_NAME"); 
    var availability = new AvailabilityTelemetry 
    { 
        Name = testName, 

        RunLocation = location, 

        Success = false, 
    }; 

    availability.Context.Operation.ParentId = Activity.Current.SpanId.ToString(); 
    availability.Context.Operation.Id = Activity.Current.RootId; 
    var stopwatch = new Stopwatch(); 
    stopwatch.Start(); 

    try 
    { 
        using (var activity = new Activity("AvailabilityContext")) 
        { 
            activity.Start(); 
            availability.Id = Activity.Current.SpanId.ToString(); 
            // Run business logic 
            await RunAvailabilityTestAsync(log); 
        } 
        availability.Success = true; 
    } 

    catch (Exception ex) 
    { 
        availability.Message = ex.Message; 
        throw; 
    } 

    finally 
    { 
        stopwatch.Stop(); 
        availability.Duration = stopwatch.Elapsed; 
        availability.Timestamp = DateTimeOffset.UtcNow; 
        telemetryClient.TrackAvailability(availability); 
        telemetryClient.Flush(); 
    } 
}

Nota:

Las pruebas creadas con TrackAvailability() aparecen con CUSTOM junto al nombre de la prueba.

Captura de pantalla que muestra la experiencia de disponibilidad con dos pruebas diferentes enumeradas.

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.

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 ubicación de 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 población para el atributo de ubicación geográfica al implementar una prueba estándar o una prueba de ping de URL mediante Azure Resource Manager.

Proveedor	Nombre para mostrar	Nombre de población
Azure
	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
	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
	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

Nota:

Para recibir alertas a través de los grupos de acciones configurados, establezca las preferencias de notificación y gravedad de la regla de alertas en la experiencia de alertas unificadas. Sin completar los pasos siguientes, solo recibirá notificaciones en el portal.

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).
En la página Reglas de alerta, abra la alerta y seleccione Editar en la barra de navegación superior. Aquí puedes establecer el nivel de gravedad, la descripción de la regla, y el grupo de acción que tiene las preferencias de notificación que deseas usar para esta regla de alerta.

Criterios de alerta

Las alertas de disponibilidad habilitadas automáticamente enviarán un correo electrónico cuando el punto de conexión no esté disponible, y otro cuando vuelva a estar disponible. 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.

Sugerencia

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.

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, a continuación, seleccione la condición para abrir la Configure signal logic ventana.

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. La Configure alerts opción del menú le lleva a la nueva experiencia donde puede seleccionar pruebas o ubicaciones específicas en las que configurar reglas de alerta. 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 de datos de disponibilidad incluyen los resultados personalizados de disponibilidad que puede enviar mediante una llamada al SDK de TrackAvailability. Puede utilizar el soporte de alertas en métricas para generar alertas sobre resultados de disponibilidad personalizados.

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 pruebas exitosas, los detalles de diagnóstico se almacenan para un subconjunto de las ejecuciones. Para ver la prueba, el nombre y la ubicación, pase el cursor sobre cualquiera de los puntos verdes o las 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 de principio a fin, bajo Profundizar en, seleccione Éxitoso o Fallido. 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.

Captura de pantalla que muestra la selección de una prueba de disponibilidad de ejemplo

Inspección y edición de pruebas

Para editar, deshabilitar temporalmente o eliminar una prueba, abra el menú contextual (puntos suspensivos) junto a 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.

Sugerencia

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

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 el fallo con la telemetría de servidor correlacionada que se recopiló durante el procesamiento de la prueba de disponibilidad fallida.
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 en bruto, también puede ver dos métricas clave de disponibilidad 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.

Importante

La ejecución de pruebas estándar lleva asociada un coste. Una vez creada una prueba estándar, se le cobrará por ejecuciones de prueba. 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

Primeros pasos

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.

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) -RuleSslCheck:$false;

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.

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.
Deshabilite o elimine la prueba de ping de la URL. Para ello, con Azure PowerShell, puede usar este comando:
```
Remove-AzApplicationInsightsWebTest -ResourceGroupName $resourceGroup -Name $pingTestName;
```

Pruebas detrás de un firewall

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 pruebas de disponibilidad pública

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

El servicio de pruebas de disponibilidad usa direcciones IP compartidas, que pueden exponer los puntos de conexión protegidos por firewall al tráfico de otras pruebas. Para proteger el servicio, no confíe solo en el filtrado de direcciones IP. Agregue encabezados personalizados para comprobar el origen de cada solicitud web. Para más información, consulte Etiquetas de servicio de red virtual.

Autenticación del tráfico

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

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.
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.
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

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 servicioApplicationInsightsAvailability 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, abra la experiencia Reglas de seguridad de entrada y, después, seleccione Agregar.
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 los puntos de conexión están fuera de Azure o cuando las etiquetas de servicio no son una opción, permita incluir 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, abra la experiencia Reglas de seguridad de entrada y seleccione Agregar.
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

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, Application Insights usa Seguridad de la capa de transporte (TLS) 1.2 y 1.3 como mecanismos de cifrado preferidos. Además, los siguientes conjuntos de cifrado y curvas elípticas también se admiten en cada versión.

Versión	Conjuntos de cifrado	Curvas elípticas
TLS 1.2	• 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	• NistP384 • NistP256
TLS 1.3	• TLS_AES_256_GCM_SHA384 • TLS_AES_128_GCM_SHA256	• NistP384 • NistP256

Desuso de la configuración de TLS

Importante

Para mejorar la seguridad, Azure retirará las siguientes configuraciones TLS para Application Insights el 1 de mayo de 2025. Este cambio forma parte del retiro del TLS legado a nivel de Azure:

Versiones del protocolo TLS 1.0 y TLS 1.1
Conjuntos de cifrado TLS 1.2 y TLS 1.3 heredados
Curvas elípticas de TLS heredadas

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

Versión	Conjuntos de cifrado	Curvas elípticas
TLS 1.2	• 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	• curve25519
TLS 1.3		• curve25519

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 SLA de dos maneras desde el recurso de Application Insights.

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 de trabajo 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 de alto nivel acerca de su:

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 una prueba empieza a fallar a las 8:00 a. m. y vuelve a tener éxito a las 10:00 a. m., todo el período de datos se considera 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 de nuevo a su recurso de Application Insights para una investigación más detallada. Pero eso solo es posible en el recurso de Application Insights basado en el área 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 de trabajo.

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.

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 1 de mayo 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?

El desuso de TLS detallado en este documento solo debe afectar al comportamiento de ejecución de las pruebas de disponibilidad en la web después del 1 de mayo 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.

Compartir a través de

Pruebas de disponibilidad de Application Insights

Tipos de pruebas de disponibilidad

Creación de una prueba de disponibilidad

Requisitos previos

Primeros pasos

Alertas de disponibilidad

Etiquetas para rellenar la ubicación

Habilitación de alertas

Criterios de alerta

Modifique los criterios de alerta

Creación de una regla de alertas personalizada

Automatización de alertas

Visualización de los resultados de las pruebas de disponibilidad

Comprobación de la disponibilidad

Inspección y edición de pruebas

Si ve errores

Consulta en análisis de registros

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

Requisitos previos

Primeros pasos

Pruebas detrás de un firewall

Habilitación de pruebas de disponibilidad pública

Autenticación del tráfico

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

Escenarios desconectados o sin entrada

Configuraciones de TLS admitidas

Desuso de la configuración de TLS

TLS 1.0 y TLS 1.1

TLS 1.2 y TLS 1.3

Libro de tiempo de inactividad e interrupciones

Flexibilidad de parámetros

Página de información general

Tiempo de inactividad, interrupciones y errores

Otras características

Preguntas más frecuentes

General

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

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

Soporte técnico de TLS

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

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

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

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

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

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

¿Dónde puedo obtener compatibilidad con TLS?

Pasos siguientes

Comentarios

Recursos adicionales