Pruebas de disponibilidad de Application Insights

Artículo
10/15/2024

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

Requisitos previos

Recurso de Application Insights basado en área de trabajo

Introducción

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 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. Solo analizamos 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 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.
	Habilitar la 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.
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.
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 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.

Importante

TrackAvailability() requiere un esfuerzo por parte del desarrollador en cuanto a la escritura y mantenimiento del 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

Introducción

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.

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

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() aparecerán con CUSTOM junto al nombre de la prueba.

Captura de pantalla que muestra la experiencia 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 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 Estándar o una prueba de ping de dirección URL mediante Azure Resource Manager.

Proveedor	Nombre para mostrar	Nombre de rellenado
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:

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

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

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

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

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.

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.

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

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

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

El 1 de marzo de 2025, en sintonía con la retirada de TLS heredado en todo Azure, se retirarán las versiones de protocolo TLS 1.0/1.1 y los conjuntos de cifrado y curvas elípticas heredados TLS 1.2/1.3 enumerados para las pruebas de disponibilidad de Application Insights.

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

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 ejecuten 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 más información, consulte el artículo de 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.

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

Compartir vía

Pruebas de disponibilidad de Application Insights

Tipos de pruebas de disponibilidad

Creación de una prueba de disponibilidad

Requisitos previos

Introducción

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

Introducción

Pruebas detrás de un servidor de seguridad

Habilitación de zonas de disponibilidad públicas

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

Solución de problemas

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