Solución de problemas de ingesta de datos elevados en Application Insights

A menudo se produce un aumento de los cargos de facturación de Application Insights o Log Analytics debido a una ingesta de datos elevada. Este artículo le ayuda a solucionar este problema y proporciona métodos para reducir los costos de ingesta de datos.

Pasos generales para solucionar problemas

Paso 1: Identificación de recursos que presentan una ingesta de datos elevada

En el portal de Azure, vaya a la suscripción y seleccione Cost Management>Análisis de costos. Este panel ofrece vistas de análisis de costos para visualizar costos por recurso de la siguiente manera:

Paso 2: Identificación de tablas costosas con ingesta de datos elevada

Una vez que haya identificado un recurso de Application Insights o un área de trabajo de Log Analytics, analice los datos y determine dónde se produce la ingesta más alta. Tenga en cuenta el enfoque que mejor se adapte a su escenario:

• Basado en el recuento de registros sin procesar

  Use la consulta siguiente para comparar recuentos de registros entre tablas:

  search *
  | where timestamp > ago(7d)
  | summarize count() by $table
  | sort by count_ desc
  

  Esta consulta puede ayudar a identificar las tablas más ruidosas . Desde allí, puede refinar las consultas para restringir la investigación.

• Basado en bytes consumidos

  Determine las tablas con la ingesta de bytes más alta mediante la función escalar format_bytes():

  systemEvents
  | where timestamp > ago(7d)
  | where type == "Billing"
  | extend BillingTelemetryType = tostring(dimensions["BillingTelemetryType"])
  | extend BillingTelemetrySizeInBytes = todouble(measurements["BillingTelemetrySize"])
  | summarize TotalBillingTelemetrySize = sum(BillingTelemetrySizeInBytes) by BillingTelemetryType
  | extend BillingTelemetrySizeGB = format_bytes(TotalBillingTelemetrySize, 1 ,"GB")
  | sort by BillingTelemetrySizeInBytes desc
  | project-away BillingTelemetrySizeInBytes
  

  De forma similar a las consultas de recuento de registros, las consultas anteriores pueden ayudar a identificar las tablas más activas, lo que le permite identificar tablas específicas para una investigación más detallada.

• Uso de Cuadernos del área de trabajo de Log Analytics

  En el portal de Azure, vaya al área de trabajo de Log Analytics, seleccione Supervisión>Workbooks y, a continuación, seleccione Uso en Información del área de trabajo de Log Analytics.

  

  Este cuaderno proporciona información valiosa, como el porcentaje de ingesta de datos para cada tabla y estadísticas de ingesta detalladas para cada recurso que reporta al mismo espacio de trabajo.

Paso 3: Determinación de factores que contribuyen a una ingesta de datos elevada

Después de identificar las tablas con una ingesta de datos elevada, céntrese en la tabla con la actividad más alta y determine los factores que contribuyen a la ingesta de datos elevada. Puede ser una aplicación específica que genera más datos que los demás, un mensaje de excepción que se registra con demasiada frecuencia o una nueva categoría de registrador que emite demasiada información.

Estas son algunas consultas de ejemplo que puede usar para esta identificación:

requests
| where timestamp > ago(7d)
| summarize count() by cloud_RoleInstance
| sort by count_ desc

requests
| where timestamp > ago(7d)
| summarize count() by operation_Name
| sort by count_ desc

dependencies
| where timestamp > ago(7d)
| summarize count() by cloud_RoleName
| sort by count_ desc

dependencies
| where timestamp > ago(7d)
| summarize count() by type
| sort by count_ desc

traces
| where timestamp > ago(7d)
| summarize count() by message
| sort by count_ desc

exceptions
| where timestamp > ago(7d)
| summarize count() by message
| sort by count_ desc

Puede probar diferentes campos de telemetría. Por ejemplo, quizás primero ejecute la consulta siguiente y observe que no hay ninguna causa obvia para la telemetría excesiva:

dependencies
| where timestamp > ago(7d)
| summarize count() by target
| sort by count_ desc

Sin embargo, puede probar otro campo de telemetría en lugar de target, como type.

dependencies
| where timestamp > ago(7d)
| summarize count() by type
| sort by count_ desc

En algunos escenarios, es posible que tenga que investigar una aplicación o una instancia específicas más adelante. Use las siguientes consultas para identificar mensajes ruidosos o tipos de excepción:

traces
| where timestamp > ago(7d)
| where cloud_RoleName == 'Specify a role name'
| summarize count() by type
| sort by count_ desc

exceptions
| where timestamp > ago(7d)
| where cloud_RoleInstance == 'Specify a role instance'
| summarize count() by type
| sort by count_ desc

Paso 4: Investigar la evolución de la ingesta a lo largo del tiempo

Examine la evolución de la ingesta con el tiempo en función de los factores identificados anteriormente. De este modo, puede determinar si este comportamiento ha sido coherente o si se han producido cambios en un punto específico. Al analizar los datos de esta manera, puede identificar cuándo se produjo el cambio y proporcionar una comprensión más clara de las causas detrás de la ingesta de datos elevada. Esta información será importante para abordar el problema e implementar soluciones eficaces.

En las consultas siguientes, la función escalar bin() Kusto Query Language (KQL) se usa para segmentar los datos en intervalos de un día. Este enfoque facilita el análisis de tendencias, ya que puede ver cómo han cambiado o no los datos a lo largo del tiempo.

dependencies
| where timestamp > ago(30d)
| summarize count() by bin(timestamp, 1d), operation_Name
| sort by timestamp desc

Use la min() función de agregación para identificar la marca de tiempo registrada más antigua para factores específicos. Este enfoque ayuda a establecer una línea base y ofrece información sobre cuándo se produjeron los eventos o los cambios por primera vez.

dependencies
| where timestamp > ago(30d)
| where type == 'Specify dependency type being investigated'
| summarize min(timestamp) by type
| sort by min_timestamp desc

Pasos de solución de problemas para escenarios específicos

Escenario 1: Ingesta de datos elevada en Log Analytics

1. Consulte todas las tablas de un área de trabajo de Log Analytics:

   search *
   | where TimeGenerated > ago(7d)
   | where _IsBillable == true
   | summarize TotalBilledSize = sum(_BilledSize) by $table
   | extend IngestedVolumeGB = format_bytes(TotalBilledSize, 1, "GB")
   | sort by TotalBilledSize desc
   | project-away TotalBilledSize
   

   Puede saber cuál tabla es la mayor contribuyente a los costos. Este es un ejemplo de AppTraces:

   

2. Consulte la aplicación específica que impulsa los costos de los seguimientos:

   AppTraces
   | where TimeGenerated > ago(7d)
   | where _IsBillable == true
   | summarize TotalBilledSize = sum(_BilledSize) by  AppRoleName
   | extend IngestedVolumeGB = format_bytes(TotalBilledSize, 1, "GB")
   | sort by TotalBilledSize desc
   | project-away TotalBilledSize
   

   

3. Ejecute la siguiente consulta específica de esa aplicación y busque más en las categorías de registrador específicas que envían telemetría a la AppTraces tabla:

   AppTraces
   | where TimeGenerated > ago(7d)
   | where _IsBillable == true
   | where AppRoleName contains 'transformation'
   | extend LoggerCategory = Properties['Category']
   | summarize TotalBilledSize = sum(_BilledSize) by tostring(LoggerCategory)
   | extend IngestedVolumeGB = format_bytes(TotalBilledSize, 1, "GB")
   | sort by TotalBilledSize desc
   | project-away TotalBilledSize
   

   El resultado muestra dos categorías principales responsables de los costos:

   

Escenario 2: Ingesta de datos alta en Application Insight

Para determinar los factores que contribuyen a los costos, siga estos pasos:

1. Consulte la telemetría en todas las tablas y obtenga un recuento de registros por tabla y versión del SDK:

   search *
   | where TimeGenerated > ago(7d)
   | summarize count() by $table, SDKVersion
   | sort by count_ desc
   

   En el ejemplo siguiente se muestra que Azure Functions genera una gran cantidad de telemetría de seguimiento y excepciones:

   

2. Ejecute la consulta siguiente para obtener la aplicación específica que genera más seguimientos que los demás:

   AppTraces
   | where TimeGenerated > ago(7d)
   | where SDKVersion == 'azurefunctions: 4.34.2.22820'
   | summarize count() by AppRoleName
   | sort by count_ desc
   

   

3. Refinar la consulta para incluir esa aplicación específica y generar un recuento de registros por cada mensaje individual:

   AppTraces
   | where TimeGenerated > ago(7d)
   | where SDKVersion == 'azurefunctions: 4.34.2.22820'
   | where AppRoleName contains 'inbound'
   | summarize count() by Message
   | sort by count_ desc
   

   El resultado puede mostrar el mensaje específico que aumenta los costos de ingesta.

   

Escenario 3: Alcanzar el límite diario inesperadamente

Supongamos que alcanzó el límite diario inesperadamente el 4 de septiembre. Use la consulta siguiente para obtener un recuento de eventos personalizados e identificar la marca de tiempo más reciente asociada a cada evento:

customEvents
| where timestamp between(datetime(8/25/2024) .. 15d)
| summarize count(), min(timestamp) by name

Este análisis indica que ciertos eventos comenzaron a ingerirse el 4 de septiembre y, posteriormente, se volvieron ruidosos muy rápidamente.

Reducción de los costos de ingesta de datos

Después de identificar los factores de las tablas de Azure Monitor responsables de la ingesta de datos inesperadas, reduzca los costos de ingesta de datos mediante los métodos siguientes según sus escenarios.

Método 1: Actualización de la configuración de límite diario

Ajuste el límite diario para evitar una ingesta excesiva de telemetría.

Método 2: Cambiar el plan de tabla

Cambie a otro plan de tabla compatible para Application Insights. La facturación por la ingesta de datos depende del plan de tabla y de la región del espacio de trabajo de Log Analytics. Consulte Planes de tablas y Tablas que admiten el plan de tabla básico en los registros de Azure Monitor.

Método 3: Uso de características del SDK de telemetría para el agente de Java

La solución recomendada predeterminada usa anulaciones de muestreo. El agente de Java de Application Insights proporciona dos tipos de muestreo. Un caso de uso común es suprimir la recopilación de telemetría para las comprobaciones de estado.

Hay algunos métodos suplementarios para sobreposiciones de muestreo:

• Reduzca el costo de la traces tabla:

  • Reduzca el nivel de registro de telemetría.

  • Quite los registros de aplicación (no marcos o bibliotecas) con el atributo MDC y la invalidación de muestreo.

  • Deshabilite la instrumentación de registros mediante la actualización del archivo applicationinsights.json :

    {
      "instrumentation": {
        "logging": {
          "enabled": false
        }
      }
    }
    

• Reduzca el costo en la tabla dependencies.

  • Suprima la recopilación de telemetría para el método Java que genera la telemetría de dependencia.

  • Deshabilite la instrumentación que genera los datos de telemetría de dependencia.

    Si la dependencia es una llamada de base de datos, no verá la base de datos en el mapa de la aplicación. Si quita la instrumentación de dependencias de una llamada HTTP o de un mensaje (por ejemplo, un mensaje de Kafka), se eliminan todos los datos de telemetría descendentes.

• Reduzca el costo de la customMetrics tabla:

  • Aumente el intervalo de métricas.
  • Excluya una métrica con un procesador de telemetría.
  • Aumente el intervalo de latido.

• Reduzca el costo de los atributos de OpenTelemetry.

  Los atributos OpenTelemetry se agregan a la columna customDimensions . Se representan como propiedades en Application Insights. Puede quitar atributos mediante un procesador de telemetría de atributos. Para obtener más información, consulte Ejemplos de procesador de telemetría: Eliminación.

Método 4: Actualización del código de la aplicación (niveles de registro o excepciones)

En algunos escenarios, actualizar el código de la aplicación directamente podría ayudar a reducir la cantidad de telemetría generada y consumida por el servicio back-end de Application Insights. Un ejemplo común podría ser una excepción ruidosa expuesta por la aplicación.

Referencias

• Precios de Azure Monitor
• Cambio del plan de tarifa para el área de trabajo de Log Analytics
• Planes de tabla en Azure Monitor
• Costo y uso de Azure Monitor
• Análisis del uso en un área de trabajo de Log Analytics
• Optimización de costos en Azure Monitor

Exención de responsabilidad de contacto con terceros

Microsoft proporciona información de contacto de terceros para ayudarle a encontrar información adicional sobre este tema. Esta información de contacto puede cambiar sin previo aviso. Microsoft no garantiza la exactitud de la información de contacto de terceros.

Ponte en contacto con nosotros para obtener ayuda

Si tiene preguntas o necesita ayuda, cree una solicitud de soporte técnico o solicite soporte técnico a la comunidad de Azure. También puede enviar comentarios sobre el producto a la comunidad de comentarios de Azure.