Pruebas de disponibilidad de Application Insights

Artículo
07/19/2024

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 y POST), 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.

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

Recurso de Application Insights basado en área de trabajo

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.

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.

Requisitos previos

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

Ejemplo de código básico

Nota:

Este ejemplo se ha diseñado únicamente para mostrar la mecánica de cómo actúa la llamada a la API de TrackAvailability() en una función de Azure. 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.

De forma predeterminada, si sigue este ejemplo, creará una prueba HTTP GET de disponibilidad básica. Para seguir estas instrucciones, debe usar el plan dedicado para permitir la edición de código en Editor de App Service.

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

Cree un recurso de Azure Functions.
- Si ya tiene un recurso de Application Insights:
  
  De forma predeterminada, Azure Functions crea un recurso de Application Insights. Si desea usar un recurso que creó anteriormente, debe especificarlo durante la creación.
  
  Siga las instrucciones sobre cómo crear un recurso de Azure Functions con la modificación siguiente:
  
  En la pestaña Supervisión, seleccione el cuadro desplegable Application Insights e introduzca o seleccione el nombre del recurso:
- Si aún no tiene un recurso de Application Insights creado para la función desencadenada por el temporizador:
  
  De manera predeterminada, al crear una aplicación de Azure Functions, se crea un recurso de Application Insights de forma automática. Siga las instrucciones sobre cómo crear un recurso de Azure Functions.
Nota:

Puede hospedar las funciones en un plan de consumo, Premium o App Service. Si está probando con una red virtual o probando puntos de conexión no públicos, deberá usar el plan Premium en lugar del plan de consumo. Seleccione el plan en la pestaña Hosting. Al crear la aplicación de funciones, asegúrese de que la versión más reciente de .NET está seleccionada.
Cree una función de desencadenador de temporizador.
1. En su aplicación de función, seleccione la pestaña Funciones.
2. Seleccione Agregar. En el panel Agregar función, seleccione las siguientes configuraciones:
  - Entorno de desarrollo: desarrollo en portal
  - Seleccione una plantilla: Desencadenador de temporizador
3. Seleccione Agregar para crear la función Desencadenador de temporizador.

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

Vaya a la aplicación de funciones 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/"); 
    } 
}

Defina la variable de REGION_NAME entorno como una ubicación de disponibilidad válida de Azure.

Ejecute el siguiente comando en la CLI de Azure para enumerar las regiones disponibles.
```
az account list-locations -o table
```

Copie el código siguiente en el archivo run.csx. (Reemplace el código preexistente).

#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, please 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(); 
    } 
}

Ejemplo de código de prueba web de varios pasos

Siga las mismas instrucciones anteriores y pegue el código siguiente en el archivo runAvailabilityTest.csx:

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/"); 

        // TODO: Replace with your business logic for an additional monitored endpoint, and logic for additional steps as needed
        await httpClient.GetStringAsync("https://www.learn.microsoft.com/"); 
    } 
}

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:
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 pestaña Disponibilidad del recurso de Application Insights.

Prueba estándar
TrackAvailability

Captura de pantalla que muestra la página Disponibilidad con el botón Actualizar resaltado.

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.

Captura de pantalla que muestra la vista de línea.

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

Captura de pantalla que muestra los detalles de Ver prueba. Editar y Deshabilitar una prueba web.

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.

Captura de pantalla de la pestaña de detalles de una transacción de un extremo a otro.

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.

Captura de pantalla que muestra los diagnósticos del lado servidor.

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 servicioApplicationInsightsAvailability se aplica a todas las pruebas de disponibilidad.
1. Si usa grupos de seguridad de red de Azure, vaya al recurso del grupo de seguridad de red y, en Configuración, seleccione Reglas de seguridad de entrada. A continuación, seleccione Agregar.
2. 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.
1. En el recurso del grupo de seguridad de red, en Configuración, seleccione Reglas de seguridad de entrada. A continuación, seleccione Agregar.
2. 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 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 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.

Captura de pantalla que muestra la selección del botón Editar para cambiar la visualización a un gráfico circular.

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.

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.

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

Criterios de éxito

Alertas de disponibilidad

Etiquetas para rellenar la ubicación

Azure

Azure Government

Microsoft Azure operado por 21Vianet

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 disponibilidad

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

TLS 1.2

TLS 1.3

Desuso de la configuración de TLS

TLS 1.0 y TLS 1.1

TLS 1.2

TLS 1.3

Solución de problemas

Libro sobre tiempo de inactividad, Acuerdo de Nivel de Servicio e interrupciones

Flexibilidad de parámetros

Página de información general

Tiempo de inactividad, interrupciones y errores

Editar el informe

Log Analytics

Acceso y uso compartido

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 31 de octubre de 2024, ¿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

Comentarios

Recursos adicionales