Canales de telemetría en Application Insights

Artículo
10/15/2024

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.

Nota:

La siguiente documentación se basa en la API clásica de Application Insights. El plan a largo plazo de Application Insights consiste en recopilar datos mediante OpenTelemetry. Para más información, vea Habilitación de OpenTelemetry de Azure Monitor para aplicaciones de .NET, Node.js, Python y Java y nuestro plan de desarrollo de OpenTelemetry. La guía de migración está disponible para .NET, Node.jsy Python.

¿Cuáles 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.

Live Metrics Stream también tiene un canal personalizado que sustenta el streaming en vivo de la 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 mayor paquete Microsoft.ApplicationInsights de NuGet 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. Es la opción predeterminada para las aplicaciones ASP.NET y ASP.NET Core que están 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 valores de configuración, consulte la sección Valores configurables en los 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 configurado ServerTelemetryChannel 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 Transmissioncontiene 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 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 usará una lógica de retroceso exponencial que va de 10 segundos a 1 hora antes de reintentar el envío de 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 duración. El método Flush() implementado por ServerTelemetryChannel no es sincrónico. Tampoco garantiza que se envíen todos los elementos pendientes de la memoria o disco.

Si utiliza este canal en escenarios en que la aplicación está a punto de cerrarse, introduzca algún retraso después de llamar a Flush(). La cantidad exacta de retraso que puede necesitar no es predecible. Depende de factores como el número de elementos o de instancias de Transmission que hay en la memoria, de cuántos están en el disco y cuántos se están transmitiendo al back-end y de si el canal está en medio de escenarios de retroceso exponenciales.

Si necesita realizar un vaciado sincrónico, use InMemoryChannel.

Preguntas más frecuentes

Esta sección proporciona respuestas a preguntas comunes.

¿El canal de Application Insights garantiza la entrega de los datos de telemetría? Si no es así, ¿cuáles son los escenarios en los que se pueden perder los datos de telemetría?

La respuesta corta es que ninguno de los canales integrados ofrece una garantía de tipo de transacción de entrega de telemetría al back-end. El canal ServerTelemetryChannel es más avanzado comparado con InMemoryChannel en lo que respecta a la entrega confiable, pero solo hace un intento de mejor esfuerzo para enviar la telemetría. Aún así, igualmente se pueden perder datos de telemetría en diversas situaciones, incluidos los escenarios comunes siguientes:

Los elementos en la memoria se pierden cuando se bloquea la aplicación.
Los datos de telemetría se pierden durante largos períodos de problemas de red. Los datos de telemetría se almacenan en el disco local durante las interrupciones de red o cuando se producen problemas con el back-end de Application Insights. Sin embargo, se descartan los elementos anteriores a 48 horas.
Las ubicaciones predeterminadas del disco en las que se almacenan datos de telemetría en Windows son %LOCALAPPDATA% o %TEMP%. Normalmente, estas ubicaciones se encuentran en el entorno local de la máquina. Si la aplicación se migra físicamente desde una ubicación a otra, se pierde cualquier telemetría almacenada en la ubicación original.
En Azure Web Apps en Windows, la ubicación de almacenamiento en disco predeterminada es D:\local\LocalAppData. Esta ubicación no se conserva. Se borra cuando se realizan reinicios de la aplicación, escalados horizontales y otras operaciones similares, lo que da lugar a la pérdida de cualquier telemetría almacenada. Puede reemplazar el valor predeterminado y especificar el almacenamiento en una ubicación persistente como D:\home. Sin embargo, dado que estas ubicaciones persistentes las proporciona el almacenamiento remoto, pueden ser lentas.

Aunque es menos probable, también es posible que el canal pueda generar elementos de telemetría duplicados. Este comportamiento se produce cuando ServerTelemetryChannel hace reintentos debido a errores de red o tiempo de espera, cuando la telemetría se entregó al back-end, pero la respuesta se perdió debido a problemas de red o hubo un tiempo de espera.

¿ServerTelemetryChannel funciona en sistemas distintos de Windows?

Aunque el nombre de su paquete y el espacio de nombres incluye "WindowsServer", este canal se admite en sistemas distintos de Windows, con la siguiente excepción. En los sistemas distintos de Windows, el canal no crea una carpeta de almacenamiento local de forma predeterminada. Debe crear una carpeta de almacenamiento local y configurar el canal para que la use. Una vez configurado el almacenamiento local, el canal funciona del mismo modo en todos los sistemas.

Nota

Con la versión 2.15.0-beta3 y superior, ahora se crea automáticamente almacenamiento local para Linux, Mac y Windows. En el caso de sistemas que no son Windows, el SDK creará automáticamente una carpeta de almacenamiento local basada en la siguiente lógica:

${TMPDIR}: si está establecida la variable de entorno ${TMPDIR}, se usa esta ubicación.
/var/tmp: si la ubicación anterior no existe, se prueba /var/tmp.
/tmp: si las dos ubicaciones anteriores no existen, se prueba tmp.
Si no existe ninguna de esas ubicaciones, no se crea almacenamiento local y todavía se requiere configuración manual. Para obtener información completa sobre la implementación, consulte este repositorio de GitHub.

¿El SDK crea almacenamiento local temporal? ¿Se cifran los datos en el almacenamiento?

El SDK almacena elementos de telemetría en el almacenamiento local cuando se producen problemas de red o hay una limitación. Estos datos no se cifran localmente.

En el caso de los sistemas Windows, el SDK crea automáticamente una carpeta temporal local en el directorio %LOCALAPPDATA% o %TEMP% y restringe el acceso solo a los administradores y al usuario actual.

Para los sistemas que distintos de Windows, no se crea ningún almacenamiento local automáticamente mediante el SDK, por lo que no se almacena ningún dato localmente de forma predeterminada.

Nota

Con la versión 2.15.0-beta3 y superior, ahora se crea automáticamente almacenamiento local para Linux, Mac y Windows.

Puede crear un directorio de almacenamiento usted mismo y configurar el canal para que lo utilice. En este caso, es su responsabilidad asegurarse de que se protege el directorio. Obtenga más información sobre la protección y la privacidad de los datos.

SDK de código abierto

Al igual que todos los SDK de Application Insights, los canales son código abierto. Puede leer el código y contribuir en este, o bien notificar problemas en el repositorio oficial de GitHub.

Compartir a través de