Compartir a través de

Canales de telemetría en Application Insights

Los canales de telemetría son una parte integral de los SDK de Application Insights. Administran el almacenamiento en búfer y la transmisión de telemetría al servicio Application Insights. Las versiones de los SDK de .NET y .NET Core tienen dos canales de telemetría integrados: InMemoryChannel y ServerTelemetryChannel. En este artículo se describe cada canal y se muestra el procedimiento para personalizar el comportamiento del canal.

Precaución

Se recomienda la Distribución de OpenTelemetry de Azure Monitor para nuevas aplicaciones o clientes para potenciar Application Insights de Azure Monitor. La Distribución de OpenTelemetry de Azure Monitor ofrece una funcionalidad y experiencia similares al SDK de Application Insights. Es posible migrar desde el SDK de Application Insights mediante las guías de migración para .NET, Node.jsy Python, pero todavía estamos trabajando para agregar algunas características más para la compatibilidad con versiones anteriores.

¿Qué son los canales de telemetría?

Los canales de telemetría son responsables de almacenar en búfer los elementos de telemetría y enviarlos al servicio Application Insights, donde se almacenan con finalidades de consultas y análisis. Un canal de telemetría es cualquier clase que implementa la interfaz Microsoft.ApplicationInsights.ITelemetryChannel.

El método Send(ITelemetry item) de un canal de telemetría se invoca después de llamar a todos los inicializadores y procesadores de telemetría. Por lo tanto, todos los elementos que proporciona un procesador de telemetría no alcanzarán el canal. Normalmente el método Send() no envía los elementos al back-end de manera instantánea. Por lo general, los almacena en búfer y los envía en lotes a fin de que la transmisión sea eficaz.

Evite llamar a Flush() a menos que sea fundamental enviar datos de telemetría almacenados en búfer inmediatamente. Úselo solo en escenarios como el apagado de la aplicación, el control de excepciones o cuando se usan procesos de corta duración, como trabajos en segundo plano o herramientas de línea de comandos. En aplicaciones web o servicios de larga duración, el SDK controla el envío de telemetría automáticamente. Llamar Flush() innecesariamente puede causar problemas de rendimiento.

Live Metrics Stream también tiene un canal personalizado que alimenta el streaming en vivo de telemetría. Este canal es independiente del canal de telemetría normal, por lo que no se cubre en este documento.

Canales de telemetría integrados

Los SDK de .NET Core y .NET de Application Insights se envían con dos canales integrados:

  • InMemoryChannel: un canal ligero que almacena en búfer los elementos en la memoria hasta que se envían. Los elementos se almacenan en búfer en la memoria y se vacían una vez cada 30 segundos, o cada vez que se almacenan en búfer 500 elementos. Este canal ofrece garantías de confiabilidad mínimas porque no reintenta el envío de telemetría tras un error. Este canal tampoco mantiene elementos en el disco. Por lo tanto, los elementos no enviados se pierden permanentemente al cerrar la aplicación, independientemente de si se cierra de forma adecuada o no. Este canal implementa un método Flush() que puede usarse para vaciar por la fuerza todos los elementos de telemetría que hay en la memoria de manera sincrónica. Resulta adecuado para las aplicaciones de ejecución breve en las que es ideal realizar un vaciado sincrónico.

    El canal forma parte del paquete Microsoft.ApplicationInsights de NuGet más grande y es el que usa el SDK de manera predeterminada cuando no hay nada más configurado.

  • ServerTelemetryChannel: se trata de un canal más avanzado con directivas de reintento y la capacidad de almacenar datos en un disco local. Este canal reintenta el envío de telemetría si se producen errores transitorios. Asimismo, usa el almacenamiento en disco local para mantener los elementos en el disco durante las interrupciones de red o grandes volúmenes de telemetría. Debido a estos mecanismos de reintento y el almacenamiento en disco local, este canal se considera más confiable. Se recomienda para todos los escenarios de producción. Este canal es el valor predeterminado para las aplicaciones ASP.NET y ASP.NET Core configuradas según la documentación oficial. Este canal está optimizado para escenarios de servidor con procesos de larga ejecución. El método Flush() que implementa este canal no es sincrónico.

    Este canal se incluye con el paquete Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel de NuGet y se adquiere automáticamente cuando se utiliza el paquete Microsoft.ApplicationInsights.AspNetCore o Microsoft.ApplicationInsights.Web de NuGet.

Configuración de un canal de telemetría

Para configurar un canal de telemetría, debe establecerlo en la configuración de telemetría activa. En el caso de las aplicaciones de ASP.NET, la configuración implica establecer la instancia del canal de telemetría en TelemetryConfiguration.Active o bien modificar ApplicationInsights.config. Para las aplicaciones de ASP.NET Core, la configuración implica agregar el canal al contenedor de inserción de dependencias.

En las secciones siguientes, se muestran ejemplos de configuración del valor StorageFolder para el canal en distintos tipos de aplicaciones. StorageFolder es solo uno de los valores configurables. Para obtener la lista completa de opciones de configuración, consulte la sección Configuración configurable en canales más adelante en este artículo.

Configuración mediante ApplicationInsights.config para aplicaciones de ASP.NET

En la sección siguiente de ApplicationInsights.config se muestra el canal ServerTelemetryChannel configurado con StorageFolder establecido en una ubicación personalizada:

    <TelemetrySinks>
        <Add Name="default">
            <TelemetryProcessors>
                <!-- Telemetry processors omitted for brevity  -->
            </TelemetryProcessors>
            <TelemetryChannel Type="Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel.ServerTelemetryChannel, Microsoft.AI.ServerTelemetryChannel">
                <StorageFolder>d:\temp\applicationinsights</StorageFolder>
            </TelemetryChannel>
        </Add>
    </TelemetrySinks>

Configuración del código para las aplicaciones de ASP.NET

El código siguiente configura una instancia de ServerTelemetryChannel con StorageFolder establecido en una ubicación personalizada. Agregue este código al principio de la aplicación, normalmente en el método Application_Start() de Global.aspx.cs.

using Microsoft.ApplicationInsights.Extensibility;
using Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel;
protected void Application_Start()
{
    var serverTelemetryChannel = new ServerTelemetryChannel();
serverTelemetryChannel.StorageFolder = @"d:\temp\applicationinsights";
    serverTelemetryChannel.Initialize(TelemetryConfiguration.Active);
    TelemetryConfiguration.Active.TelemetryChannel = serverTelemetryChannel;
}

Configuración del código para las aplicaciones de ASP.NET Core

Modifique el método ConfigureServices de la clase Startup.cs de la siguiente manera:

using Microsoft.ApplicationInsights.Channel;
using Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel;

public void ConfigureServices(IServiceCollection services)
{
    // This sets up ServerTelemetryChannel with StorageFolder set to a custom location.
    services.AddSingleton(typeof(ITelemetryChannel), new ServerTelemetryChannel() {StorageFolder = @"d:\temp\applicationinsights" });

    services.AddApplicationInsightsTelemetry();
}

Importante

No se admite la configuración del canal mediante TelemetryConfiguration.Active para las aplicaciones de ASP.NET Core.

Configuración del código para las aplicaciones de consola de ASP.NET Core o .NET

En el caso de las aplicaciones de consola, el código es el mismo para .NET y .NET Core:

var serverTelemetryChannel = new ServerTelemetryChannel();
serverTelemetryChannel.StorageFolder = @"d:\temp\applicationinsights";
serverTelemetryChannel.Initialize(TelemetryConfiguration.Active);
TelemetryConfiguration.Active.TelemetryChannel = serverTelemetryChannel;

Detalles de funcionamiento de ServerTelemetryChannel

ServerTelemetryChannel almacena los elementos que llegan de un búfer en memoria. Los elementos se serializan, comprimen y almacenan en una instancia de Transmission una vez cada 30 segundos, o cuando se han almacenado en búfer 500 elementos. Una sola instancia de Transmission contiene hasta 500 elementos y representa un lote de datos de telemetría que se envía a través de una sola llamada HTTPS al servicio de Application Insights.

De forma predeterminada, se puede enviar un máximo de 10 instancias de Transmission en paralelo. Si llegan datos de telemetría a velocidades más rápidas, o si el back-end de Application Insights o la red funcionan con lentitud, las instancias de Transmission se almacenan en memoria. La capacidad predeterminada de este búfer de Transmission en memoria es de 5 MB. Cuando se ha superado la capacidad en memoria, las instancias de Transmission se almacenan en el disco local hasta un límite de 50 MB.

Las instancias de Transmission también se almacenan en el disco local cuando hay problemas de red. Solo los elementos que se almacenan en un disco local sobreviven a un bloqueo de la aplicación. Se envían siempre que la aplicación se inicia de nuevo. Si los problemas de red persisten, ServerTelemetryChannel usa una lógica de retroceso exponencial que oscila entre 10 segundos y 1 hora antes de volver a intentar enviar telemetría.

Valores configurables en los canales

Para obtener la lista completa de valores configurables de cada canal, consulte:

A continuación, le mostramos la configuración que se usa con más frecuencia para ServerTelemetryChannel:

  • MaxTransmissionBufferCapacity: cantidad máxima de memoria, en bytes, que usa el canal para las transmisiones de búfer en memoria. Cuando se alcanza esta capacidad, los nuevos elementos se almacenan directamente en el disco local. El valor predeterminado es de 5 MB. Si se establece un valor superior, el uso del disco se reduce, sin embargo, recuerde que los elementos en memoria se perderán si se bloquea la aplicación.
  • MaxTransmissionSenderCapacity: número máximo de instancias de Transmission que se enviarán a Application Insights al mismo tiempo. El valor predeterminado es 10. Este valor puede configurarse en un número mayor, lo que se recomienda cuando se genera un gran volumen de telemetría. El gran volumen normalmente tiene lugar durante las pruebas de carga o cuando se desactiva el muestreo.
  • StorageFolder: Carpeta que usa el canal para almacenar elementos en el disco según sea necesario. En Windows, se usa %LOCALAPPDATA% o %TEMP% si no se especifica ninguna otra ruta de acceso de forma explícita. En entornos que no son de Windows, debe especificar una ubicación válida o, de lo contrario, la telemetría no se almacenará en el disco local.

¿Qué canal debería usar?

Recomendamos ServerTelemetryChannel para la mayoría de los escenarios de producción que impliquen aplicaciones de larga ejecución. Para más información sobre el vaciado de telemetría, lea Acerca del uso Flush().

Cuándo usar Flush()

El Flush() método envía cualquier telemetría almacenada en búfer inmediatamente. Sin embargo, solo se debe usar en escenarios específicos.

Utilice Flush() si:

  • La aplicación está a punto de apagarse y quiere asegurarse de que la telemetría se envía antes de salir.
  • Está en un controlador de excepciones y necesita garantizar que se entregue la telemetría.
  • Estás escribiendo un proceso de corta duración, como un trabajo en segundo plano o una herramienta de la CLI que termina rápidamente.

Evite el uso Flush() de aplicaciones de larga duración, como los servicios web. El SDK administra automáticamente el almacenamiento en búfer y la transmisión. Llamar Flush() innecesariamente puede causar problemas de rendimiento y no garantiza que se envíen todos los datos, especialmente cuando se usa ServerTelemetryChannel, que no se vacía sincrónicamente.

SDK de código abierto

Al igual que todos los SDK de Application Insights, los canales son código abierto. Lea y contribuya al código o informe de problemas en el repositorio oficial de GitHub.

Pasos siguientes