Recopilación, retención y almacenamiento de datos en Application Insights

Al instalar el SDK de Application Insights en su aplicación, se envía telemetría sobre la aplicación a la nube. Como desarrollador responsable, desea saber exactamente qué datos se envían, qué les ocurre a los datos y cómo puede mantener el control de los mismos. En concreto, si se puede enviar información confidencial, dónde se almacena y su nivel de seguridad.

En primer lugar, la respuesta corta:

  • Es improbable que los módulos de telemetría estándar que se ejecutan "de fábrica" envíen información confidencial al servicio. La telemetría se ocupa de la carga, las métricas de rendimiento y uso, los informes de excepciones y otros datos de diagnóstico. Los datos de usuario principales visibles en los informes de diagnóstico son direcciones URL. Pero la aplicación no debería, en ningún caso, incluir datos confidenciales en texto sin formato en una dirección URL.
  • Puede escribir código que envíe más telemetría personalizada que le ayude con el uso de la supervisión y el diagnóstico. (Esta extensibilidad es una excelente característica de Application Insights.) Por error, sería posible escribir este código de modo que incluya datos personales y otra información confidencial. Si la aplicación trabaja con estos datos, debe aplicar un proceso de revisión exhaustivo a todo el código que escriba.
  • Al desarrollar y probar la aplicación, es fácil de inspeccionar lo que envía el SDK. Los datos aparecen en las ventanas de salida de depuración tanto del IDE como del explorador.
  • Puede seleccionar la ubicación cuando se crea un nuevo recurso de Application Insights. Para más información sobre la disponibilidad de Application Insights por región, consulte Productos disponibles por región.
  • Revise los datos recopilados, porque pueden incluir datos que se permiten en algunas circunstancias, pero no en otras. Un buen ejemplo de esta circunstancia es el nombre de dispositivo. El nombre del dispositivo de un servidor no afecta a la privacidad y es útil. Un nombre de dispositivo de un teléfono o portátil puede tener implicaciones de privacidad y ser menos útil. Un SDK desarrollado principalmente para los servidores de destino recopilaría el nombre del dispositivo de forma predeterminada. Es posible que esta funcionalidad deba sobrescribirse en eventos normales y excepciones.

En el resto de este artículo se describen estos puntos más plenamente. El artículo es independiente, por lo que puede compartirlo con compañeros que no forman parte de su equipo inmediato.

¿Qué es Application Insights?

Application Insights es un servicio que proporciona Microsoft que le ayuda a mejorar el rendimiento y la facilidad de uso de la aplicación activa. Supervisa la aplicación durante todo el tiempo que se ejecute, tanto durante las pruebas como después de haberla publicado o implementado. Application Insights crea gráficos y tablas que muestran métricas informativas. Por ejemplo, puede ver a qué horas del día se obtiene la mayoría de los usuarios, la capacidad de respuesta de la aplicación y lo bien que la atienden los servicios externos de los que depende. Si hay errores o incidencias de rendimiento, puede buscar en los datos de la telemetría para diagnosticar la causa. El servicio le envía mensajes de correo electrónico si se produce cualquier cambio en la disponibilidad y el rendimiento de la aplicación.

Para obtener esta funcionalidad, instale un SDK de Application Insights en la aplicación, que se convierte en parte de su código. Cuando su aplicación se está ejecutando, el SDK supervisa su funcionamiento y envía telemetría a un área de trabajo de Log Analytics de Application Insights, que es un servicio en la nube alojado en Microsoft Azure. Application Insights también funciona con cualquier aplicación, no solo con las hospedadas en Azure.

Application Insights almacena y analiza la telemetría. Para ver el análisis o realizar búsquedas en la telemetría almacenada, inicie sesión en su cuenta de Azure y abra el recurso Application Insights de la aplicación. También puede compartir el acceso a los datos con otros miembros del equipo o con determinados suscriptores de Azure.

Los datos exportados de Application Insights se pueden exportar, por ejemplo a una base de datos o a herramientas externas. Proporcione a cada herramienta una clave especial, que se obtiene desde el servicio. Si es necesario, dicha clave se puede revocar.

Los SDK de Application Insights están disponibles para una variedad de tipos de aplicación:

  • Servicios web hospedados en sus propios servidores Java EE o ASP.NET, o en Azure
  • Clientes web, es decir, el código que se ejecuta en una página web
  • Aplicaciones y servicios de escritorio
  • Aplicaciones de dispositivo, como Windows Phone, iOS y Android

Todos ellos envían telemetría al mismo servicio.

Nota:

El 31 de marzo de 2025 finalizará la compatibilidad con la ingesta de claves de instrumentación. La ingesta de claves de instrumentación seguirá funcionando, pero la característica ya no recibirá actualizaciones ni soporte técnico. Transición a las cadenas de conexión para aprovechar las nuevas funcionalidades.

¿Qué datos recopila?

Hay tres orígenes de datos:

  • El SDK, que se integra con la aplicación en la fase de desarrollo o en tiempo de ejecución. Existen distintos SDK para los diferentes tipos de aplicaciones. También hay un SDK para páginas web, que se carga en el explorador del usuario final junto con la página.

    • Cada SDK tiene muchos módulos que emplean diferentes técnicas para recopilar distintos tipos de datos de telemetría.
    • Si instala el SDK en la fase de desarrollo, puede usar su API para enviar su propia telemetría, además de los módulos estándar. Esta telemetría personalizada puede incluir los datos que desee enviar.
  • En algunos servidores web, también hay agentes que se ejecutan junto con la aplicación y envían datos de telemetría de la CPU, memoria y ocupación de la red. Por ejemplo, las máquinas virtuales de Azure, los hosts de Docker y los servidores de aplicaciones Java pueden tener dichos agentes.

  • Información general de disponibilidad son procesos que ejecuta Microsoft que envían solicitudes a una aplicación web a intervalos regulares. Los resultados se envían a Application Insights.

¿Qué tipo de datos se recopilan?

Las principales categorías son:

  • Telemetría de servidor web: solicitudes HTTP. Identificador URI, tiempo invertido en procesar la solicitud, código de respuesta y dirección IP del cliente. Session id.
  • Páginas web: contadores de sesión, página y usuario. Tiempos de carga de las páginas. Excepciones. Llamadas AJAX.
  • Contadores de rendimiento: memoria, CPU, E/S y ocupación de la red.
  • Contexto de cliente y servidor: SO, configuración regional, tipo de dispositivo, explorador y resolución de pantalla.
  • Excepciones y bloqueos: volcados de pila, build id y tipo de CPU.
  • Dependencias: llamadas a servicios externos como REST, SQL y AJAX. Identificador URI o cadena de conexión, duración, con éxito y comando.
  • Pruebas de disponibilidad: duración de prueba y pasos, respuestas.
  • Registros de seguimiento y telemetría personalizada: todo el código que se escribe en los registros o telemetría.

Para más información, consulte la sección Datos enviados por Application Insights.

¿Cómo se puede comprobar lo que se recopila?

Si desarrolla una aplicación mediante Visual Studio, ejecútela en modo de depuración (F5). Los datos de telemetría aparecen en la ventana Salida. Desde ahí, puede copiarlos y darles formato como JSON para facilitar su inspección.

Captura de pantalla que muestra la ejecución de la aplicación en modo de depuración en Visual Studio.

También existe una vista más legible en la ventana Diagnóstico.

En el caso de las páginas web, abra la ventana de depuración del explorador. Seleccione F12 y abra la pestaña Red.

Captura de pantalla que muestra la pestaña Red abierta.

¿Puedo escribir código para filtrar los datos de telemetría antes de enviarlos?

Deberá escribir un complemento de procesador de telemetría.

¿Cuánto tiempo se conservan los datos?

Los puntos de datos sin procesar (es decir, elementos que puede consultar en Analytics e inspeccionar en la funcionalidad de búsqueda) se conservan hasta 730 días. Puede seleccionar una duración de retención de 30, 60, 90, 120, 180, 270, 365, 550 o 730 días. Si necesita conservar los datos más de 730 días, puede usar la configuración de diagnóstico.

Los datos que se conservan durante más de 90 días incurren en cargos adicionales. Para más información sobre los precios de Application Insights, consulte la página de precios de Azure Monitor.

Los datos agregados (es decir, recuentos, promedios y otros datos estadísticos que se ven en el explorador de métricas) se retienen con un nivel de detalle de un minuto durante 90 días.

Las instantáneas de depuración se guardan durante 15 días. Esta directiva de retención se establece para cada aplicación. Si necesita aumentar este valor, puede solicitar un aumento abriendo una incidencia de soporte técnico en Azure Portal.

¿Quién puede acceder a los datos?

Usted puede ver los datos y, si tiene una cuenta de organización, también pueden los miembros del equipo.

Los puede exportar tanto usted como los miembros del equipo y pueden copiarse a otras ubicaciones y pasarse a otras personas.

¿Qué hace Microsoft con la información que la aplicación envía a Application Insights?

Microsoft usa los datos solamente para proporcionarle el servicio.

¿Donde se conservan los datos?

Puede seleccionar la ubicación cuando se crea un nuevo recurso de Application Insights. Para más información sobre la disponibilidad de Application Insights, consulte Productos disponibles por región.

¿Están seguros mis datos?

Application Insights es un servicio de Azure. Las directivas de seguridad se describen en las notas del producto de seguridad, privacidad y cumplimiento de Azure.

Los datos se almacenan en servidores de Microsoft Azure. En el caso de las cuentas de Azure Portal, las restricciones se describen en el documento Seguridad, privacidad y cumplimiento de Azure.

El acceso a los datos por parte del personal de Microsoft está restringido. El acceso a los datos solo se realiza con su permiso y si es necesario para prestarle soporte en el uso de Application Insights.

Los datos que se agregan en todas las aplicaciones de nuestros clientes, por ejemplo, la velocidad de datos y el tamaño medio de los seguimientos, se usan para mejorar Application Insights.

¿Puede interferir la telemetría de otro usuario con mis datos de Application Insights?

Alguien podría enviar más datos de telemetría a la cuenta mediante la clave de instrumentación. Esta clave se puede encontrar en el código de las páginas web. Si tienen demasiados datos adicionales, las métricas no representan correctamente el rendimiento y el uso de la aplicación.

Si comparte el código con otros proyectos, no olvide quitar la clave de instrumentación.

¿Se cifran los datos?

Todos los datos se cifran en reposo y al moverse entre centros de datos.

¿Se cifran los datos en tránsito desde mi aplicación a los servidores de Application Insights?

Sí. Usamos HTTPS para enviar datos al portal desde casi todos los SDK, incluidos servidores web, dispositivos y páginas web HTTPS.

¿El SDK crea almacenamiento local temporal?

Sí. Ciertos canales de telemetría conservarán los datos localmente si no se puede alcanzar un punto de conexión. En los párrafos siguientes se describen qué marcos y canales de telemetría se ven afectados:

  • Los canales de telemetría que utilizan almacenamiento local crean archivos temporales en los directorios TEMP o APPDATA que están restringidos a la cuenta específica que ejecuta la aplicación. Esta situación puede ocurrir cuando un punto de conexión no estaba disponible temporalmente o si se alcanza el límite. Cuando se resuelva este problema, el canal de telemetría reanudará el envío de todos los datos nuevos y conservados.
  • Los datos conservados no se cifran localmente. Si esta incidencia supone un problema, revise los datos y limite la recopilación de datos privados. Para obtener más información, consulte Cómo exportar y eliminar datos privados.
  • Si un cliente necesita para configurar este directorio con requisitos de seguridad específicos, se puede configurar para cada marco de trabajo. Asegúrese de que el proceso que ejecuta la aplicación tiene acceso de escritura a este directorio. Asegúrese también de que este directorio está protegido para evitar que los usuarios no deseados lean la telemetría.

Java

La carpeta C:\Users\username\AppData\Local\Temp se utiliza para datos persistentes. Esta ubicación no es configurable desde el directorio de configuración y los permisos para acceder a esta carpeta están restringidos a un usuario específico con las credenciales necesarias. Para obtener más información, consulte Implementación.

.NET

De forma predeterminada, ServerTelemetryChannel usa la carpeta de datos de la aplicación local del usuario actual %localAppData%\Microsoft\ApplicationInsights o la carpeta temporal %TMP%. Para obtener más información, consulte Implementación.

Mediante el archivo de configuración:

<TelemetryChannel Type="Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel.ServerTelemetryChannel,   Microsoft.AI.ServerTelemetryChannel">
    <StorageFolder>D:\NewTestFolder</StorageFolder>
</TelemetryChannel>

Mediante código:

  • Quite ServerTelemetryChannel del archivo de configuración.

  • Agregue este fragmento de código a la configuración:

    ServerTelemetryChannel channel = new ServerTelemetryChannel();
    channel.StorageFolder = @"D:\NewTestFolder";
    channel.Initialize(TelemetryConfiguration.Active);
    TelemetryConfiguration.Active.TelemetryChannel = channel;
    

NetCore

De forma predeterminada, ServerTelemetryChannel usa la carpeta de datos de la aplicación local del usuario actual %localAppData%\Microsoft\ApplicationInsights o la carpeta temporal %TMP%. Para obtener más información, consulte Implementación.

En un entorno Linux, se deshabilitará el almacenamiento local a menos que se especifique una carpeta de almacenamiento.

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 ServerTelemetryChannel almacena los datos de telemetría en la carpeta predeterminada durante los errores transitorios en entornos que no son de Windows.

El fragmento de código siguiente muestra cómo establecer ServerTelemetryChannel.StorageFolder en el método ConfigureServices() de la clase Startup.cs:

services.AddSingleton(typeof(ITelemetryChannel), new ServerTelemetryChannel () {StorageFolder = "/tmp/myfolder"});

Para obtener más información, consulte Configuración personalizada de AspNetCore.

Node.js

De forma predeterminada, se utiliza %TEMP%/appInsights-node{INSTRUMENTATION KEY} para guardar los datos. Los permisos para acceder a esta carpeta están restringidos al usuario actual y los administradores. Para más información, consulte la implementación.

El prefijo de la carpeta appInsights-node se puede invalidar cambiando el valor en tiempo de ejecución de la variable estática Sender.TEMPDIR_PREFIX que se encuentra en Sender.ts.

JavaScript (explorador)

Se usa almacenamiento de sesión de HTML5 para conservar los datos. Se usan dos búferes independientes: AI_buffer y AI_sent_buffer. La telemetría por lotes y en espera de ser enviada se almacena en AI_buffer. La telemetría que se acaba de enviar se coloca en AI_sent_buffer hasta que el servidor de ingesta responde que se ha recibido correctamente.

Una vez que la telemetría se ha recibido correctamente, se quita de todos los búferes. En los errores transitorios (por ejemplo, un usuario pierde la conectividad de red), la telemetría permanece en AI_buffer hasta que se recibe correctamente o el servidor de ingesta responde que no es válida (esquema incorrecto o demasiado antiguo, por ejemplo).

Los búferes de telemetría se pueden deshabilitar si se establece enableSessionStorageBuffer en false. Cuando se desactiva el almacenamiento de sesión, en su lugar se usa una matriz local como almacenamiento persistente. Dado que el SDK de JavaScript se ejecuta en un dispositivo cliente, el usuario tiene acceso a esta ubicación de almacenamiento mediante las herramientas de desarrollo del explorador.

Python para OpenCensus

De forma predeterminada, el SDK de Python para OpenCensus usa la carpeta del usuario actual %username%/.opencensus/.azure/. Los permisos para acceder a esta carpeta están restringidos al usuario actual y los administradores. Para más información, consulte la implementación. La carpeta con los datos persistentes se denominará según el archivo de Python que generó la telemetría.

Puede cambiar la ubicación del archivo de almacenamiento si pasa el parámetro storage_path en el constructor del exportador que usa.

AzureLogHandler(
  connection_string='InstrumentationKey=00000000-0000-0000-0000-000000000000',
  storage_path='<your-path-here>',
)

¿Cómo se envían datos a Application Insights con TLS 1.2?

Para garantizar la seguridad de los datos en tránsito a los puntos de conexión de Application Insights, se recomienda encarecidamente a los clientes configurar su aplicación para que use al menos Seguridad de la capa de transporte (TLS) 1.2. Las versiones anteriores de la TLS o la Capa de sockets seguros (SSL) eran vulnerables y no se recomienda usarlas. Aunque todavía funcionan para permitir la compatibilidad con versiones anteriores, no están recomendadas. El sector se mueve rápidamente para abandonar la compatibilidad con estos protocolos más antiguos.

PCI Security Standards Council ha establecido una fecha límite el 30 de junio de 2018 para deshabilitar las versiones anteriores de TLS/SSL y actualizar a protocolos más seguros. Después de que Azure quite la compatibilidad heredada, si la aplicación o los clientes no pueden comunicarse a través de TLS 1.2 como mínimo, podría no ser capaz de enviar datos a Application Insights. El enfoque que adopte para probar y validar la compatibilidad con TLS de la aplicación variará según el sistema operativo o la plataforma, así como el lenguaje o marco que la aplicación use.

No se recomienda establecer explícitamente la aplicación para que solo use TLS 1.2, a menos que sea necesario. Esta configuración puede interrumpir las características de seguridad a nivel de la plataforma que le permiten detectar y aprovechar automáticamente las ventajas de los protocolos más seguros más recientes a medida que estén disponibles, como TLS 1.3. Se recomienda realizar una auditoría completa del código de la aplicación para comprobar la codificación rígida de versiones específicas de TLS/SSL.

Instrucciones específicas para la plataforma y el lenguaje

Plataforma/lenguaje Soporte técnico Más información
Azure App Services Compatible, puede requerir configuración. La compatibilidad se anunció en abril de 2018. Lea el anuncio para obtener los detalles de configuración.
Azure Function Apps Compatible, puede requerir configuración. La compatibilidad se anunció en abril de 2018. Lea el anuncio para obtener los detalles de configuración.
.NET Una versión admitida con soporte técnico de larga duración (LTS). Para obtener información detallada sobre la configuración, consulte estas instrucciones.
Agente de Application Insights Compatible, se requiere configuración. El agente de Application Insights se basa en la Configuración del sistema operativo + Configuración de .NET para admitir TLS 1.2.
Node.js Compatible, en v10.5.0, puede requerir configuración. Use la documentación oficial de Node.js TLS/SSL para cualquier configuración específica de la aplicación.
Java Compatible, se agregó compatibilidad de JDK para TLS 1.2 en la actualización 121 de JDK 6 y JDK 7. JDK 8 usa TLS 1.2 de forma predeterminada.
Linux Las distribuciones de Linux tienden a basarse en OpenSSL para la compatibilidad con TLS 1.2. Compruebe el registro de cambios de OpenSSL para confirmar si su versión de OpenSSL es compatible.
Windows 8.0 a 10 Compatible y habilitado de manera predeterminada. Para confirmar que aún usa la configuración predeterminada.
Windows Server 2012 a 2016 Compatible y habilitado de manera predeterminada. Para confirmar que aún usa la configuración predeterminada.
Windows 7 SP1 y Windows Server 2008 R2 SP1 Compatible, pero no habilitado de manera predeterminada. Consulte la página Configuración del registro de TLS para obtener más información sobre cómo se habilita.
Windows Server 2008 SP2 La compatibilidad con TLS 1.2 requiere una actualización. Consulte Actualización para agregar compatibilidad con TLS 1.2 en Windows Server 2008 SP2.
Windows Vista No se admite. N/D

Comprobación de qué versión de OpenSSL se ejecuta para su distribución de Linux

Para comprobar qué versión de OpenSSL tiene instalada, abra el terminal y ejecute:

openssl version -a

Ejecución de una transacción de TLS 1.2 de prueba en Linux

Para ejecutar una prueba preliminar a fin de comprobar si el sistema de Linux puede comunicarse a través de TLS 1.2, abra el terminal y ejecute lo siguiente:

openssl s_client -connect bing.com:443 -tls1_2

Datos personales almacenados en Application Insights

Para una explicación detallada sobre este problema, consulte Administración de datos personales en Log Analytics y Application Insights.

¿Pueden los usuarios desactivar Application Insights?

No directamente. No se proporciona un conmutador que los usuarios puedan operar para desactivar Application Insights.

Puede implementar esta característica en la aplicación. Todos los SDK incluyen un valor de configuración de la API que desactiva la recopilación de telemetría.

Datos enviados por Application Insights

Los SDK varían entre las distintas plataformas, y hay varios componentes que se pueden instalar. Para más información, consulte Introducción sobre Application Insights. Cada componente envía datos diferentes.

Clases de datos que se envían en distintos escenarios

Acción del usuario Clases de datos recopilados (ver tabla siguiente)
Adición del SDK de Application Insights a un proyecto web de .NET ServerContext
Inferidos
Contadores de rendimiento
Requests
Excepciones
Sesión
users
Instalación del agente de Application Insights en IIS Dependencias
ServerContext
Inferidos
Contadores de rendimiento
Adición del SDK de Application Insights a una aplicación web de Java ServerContext
Inferidos
Solicitud
Sesión
users
Incorporación del SDK de JavaScript a una página web ClientContext
Inferidos
Página
ClientPerf
Ajax
Definición de propiedades predeterminadas Propiedades en todos los eventos estándar y personalizados
Llamar a TrackMetric Valores numéricos
Propiedades
Llamar a Track* Nombre del evento
Propiedades
Llamar a TrackException Excepciones
Volcado de la pila
Propiedades
El SDK no puede recopilar datos. Por ejemplo:
- No se puede acceder a los contadores de rendimiento
- Excepción en el inicializador de telemetría
Diagnóstico de SDK

En el caso de los SDK de otras plataformas, consulte los documentos correspondientes.

Clases de los datos recopilados

Clase de datos recopilados Se incluyen (no es una lista exhaustiva)
Propiedades Cualquier dato - determinado por el código
DeviceContext Id, IP, configuración regional, modelo de dispositivo, red, tipo de red, nombre de OEM, resolución de pantalla, instancia de rol, nombre de rol, tipo de dispositivo
ClientContext Sistema operativo, configuración regional, idioma, red, resolución de ventana
Sesión session id
ServerContext Nombre del equipo, configuración regional, sistema operativo, dispositivo, sesión de usuario, contexto de usuario, operación
Inferidos Ubicación geográfica de dirección IP, marca de tiempo, sistema operativo, explorador
Métricas Nombre y valor de la métrica
Eventos Nombre y valor del evento
PageViews URL y nombre de página o nombre de pantalla
Rendimiento del cliente URL o nombre de página, tiempo de carga del explorador
Ajax Llamadas HTTP de la página web al servidor
Requests URL, duración, código de respuesta
Dependencias Tipo (SQL, HTTP, ...), cadena de conexión o URI, sincronización/asincrónico, duración, éxito, instrucción SQL (con agente de Application Insights)
Excepciones Tipo, mensaje, pilas de llamadas, archivo de origen, número de línea, thread id
Bloqueos Process id, parent process id, crash thread id; revisión de aplicación, id, compilación; tipo de excepción, dirección, razón; símbolos y registros confusos, direcciones binarias inicial y final, nombre binario y ruta de acceso, tipo de CPU
Seguimiento Mensaje y nivel de gravedad
Contadores de rendimiento Tiempo de procesador, memoria disponible, velocidad de solicitudes, tasa de excepciones, bytes privados del proceso, velocidad de E/S, duración de la solicitud, longitud de la cola de solicitudes
Disponibilidad Código de respuesta de prueba web, duración de cada paso de la prueba, nombre de la prueba, marca de tiempo, éxito, tiempo de respuesta, ubicación de la prueba
Diagnóstico de SDK Mensaje de seguimiento o de excepción

También puede desactivar algunos de los datos mediante la edición de ApplicationInsights.config.

Nota

La IP del cliente se usa para deducir la ubicación geográfica, pero de forma predeterminada ya no se almacenan datos de IP y todos los ceros se escriben en el campo asociado. Para más información sobre el control de datos personales, consulte Administración de datos personales en Log Analytics y Application Insights. Si necesita almacenar datos de direcciones IP, el artículo sobre geolocalización y control de direcciones IP le guiará por las opciones.

¿Puedo modificar o actualizar los datos una vez recopilados?

No. Los datos son de solo lectura y solo se pueden eliminar a través de la funcionalidad de purga. Para obtener más información, consulte Guía sobre datos personales almacenados en Log Analytics y Application Insights.

Preguntas más frecuentes

Esta sección proporciona respuestas a preguntas comunes.

¿Qué ocurre con los datos de telemetría de Application Insights cuando un servidor o dispositivo pierde la conexión con Azure?

Todos nuestros SDK, incluido el SDK web, incluyen transporte confiable o transporte eficaz. Cuando el servidor o el dispositivo pierde la conexión con Azure, los datos de telemetría se almacenan localmente en el sistema de archivos (los SDK de servidor) o en el almacenamiento de la sesión HTML5 (SDK web). El SDK vuelve a intentar periódicamente enviar estos datos de telemetría hasta que nuestro servicio de ingesta los considere "obsoletos" (48 horas en el caso de los registros y 30 minutos en el caso de las métricas). Se quita la telemetría obsoleta. En algunos casos, como cuando el almacenamiento local está lleno, no se realizará ningún reintento.

¿Se envían datos personales en la telemetría?

Puede enviar datos personales si el código envía tales datos. También puede ocurrir si las variables de los seguimientos de pila incluyen datos personales. El equipo de desarrollo debe llevar a cabo las evaluaciones de riesgo para asegurarse de que los datos personales se tratan correctamente. Más información sobre la retención y la privacidad de los datos.

Todos los octetos de la dirección web del cliente siempre se establecen en 0 después de que se buscan los atributos de ubicación geográfica.

De forma predeterminada, el SDK de JavaScript de Application Insights no incluye los datos personales en su función de autocompletar de manera predeterminada. Sin embargo, el SDK podría recoger algunos datos personales que se usan en la aplicación (por ejemplo, los nombres completos en window.title o los id. de cuenta en los parámetros de consulta de dirección URL de XHR). Para el enmascaramiento personalizado de datos personales, agregue un inicializador de telemetría.