Устранение неполадок приема высоких данных в Application Insights

Увеличение расходов на оплату счетов в Application Insights или Log Analytics часто происходит из-за высокого объема поступающих данных. Эта статья поможет устранить эту проблему и предоставляет методы для снижения затрат на прием данных.

Общие действия по устранению неполадок

Шаг 1. Определение ресурсов с высоким уровнем приема данных

На портале Azure перейдите к подписке и выберите управление затратами>анализ затрат. В этом блейде представлены виды анализа затрат для отображения затрат по ресурсам, как показано ниже.

Шаг 2. Определение дорогостоящих таблиц с высоким приемом данных

Когда вы определили ресурс Application Insights или рабочую область Log Analytics, проанализируйте данные и определите, где происходит наибольшее потребление данных. Рассмотрим подход, который лучше всего подходит для вашего сценария:

• На основе количества необработанных записей

  Используйте следующий запрос для сравнения количества записей в таблицах:

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

  Этот запрос может помочь определить самые шумные таблицы. Оттуда можно уточнить запросы, чтобы сузить расследование.

• На основе потребляемых байтов

  Определите таблицы с самым высоким приемом байтов с помощью скалярной функции 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
  

  Как и запросы счетчика записей, предыдущие запросы могут помочь определить наиболее активные таблицы, что позволяет определить конкретные таблицы для дальнейшего изучения.

• Использование рабочих сводов Log Analytics

  На портале Azure перейдите к рабочей области Log Analytics, выберите Мониторинг>Рабочие книги, а затем выберите Использование в Обозрение Рабочей области Log Analytics.

  

  Эта книга предоставляет ценные аналитические сведения, такие как процент приема данных для каждой таблицы и подробные статистические данные о приеме для каждого ресурса, отправляющего отчеты в одну и ту же рабочую область.

Шаг 3. Определение факторов, влияющих на прием больших данных

После идентификации таблиц с высоким объемом данных сосредоточьтесь на таблице с самой высокой активностью и определите факторы, способствующие высокому приему данных. Это может быть конкретное приложение, которое создает больше данных, чем другие, сообщение об исключении, которое регистрируется слишком часто или новая категория средства ведения журнала, которая выдает слишком много информации.

Ниже приведены некоторые примеры запросов, которые можно использовать для этой идентификации:

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

Вы можете попробовать различные поля телеметрии. Например, возможно, сначала выполните следующий запрос и обратите внимание на отсутствие очевидных причин чрезмерной телеметрии:

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

Однако вместо этого можно попробовать другое поле targetтелеметрии, например type.

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

В некоторых сценариях может потребоваться тщательнее изучить конкретное приложение или экземпляр. Используйте следующие запросы для выявления шумных сообщений или типов исключений:

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

Шаг 4. Изучение эволюции приема с течением времени

Изучите эволюцию приема с течением времени на основе факторов, определенных ранее. Таким образом можно определить, согласовано ли это поведение или произошло ли изменение в определенной точке. Анализируя данные таким образом, вы можете определить, когда произошло изменение, и обеспечить более четкое представление о причинах приема высоких данных. Эта информация будет важной для решения проблемы и реализации эффективных решений.

В следующих запросах скалярная функция языка запросов Kusto (KQL) используется для сегментирования данных в однодневные интервалы. Этот подход упрощает анализ тенденций, как можно увидеть, как данные изменились или не изменились с течением времени.

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

min() Используйте функцию агрегирования, чтобы определить самую раннюю записанную метку времени для конкретных факторов. Этот подход помогает установить исходную точку и предоставляет полезную информацию о том, когда события или изменения произошли в первый раз.

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

Действия по устранению неполадок для конкретных сценариев

Сценарий 1. Прием больших данных в Log Analytics

1. Запрос всех таблиц в рабочей области 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
   

   Вы можете определить, какая таблица является наибольшим источником затрат. Ниже приведен пример AppTraces.

   

2. Запросите конкретное приложение, управляющее затратами на трассировку:

   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. Выполните следующий запрос, характерный для этого приложения, и просмотрите дополнительные категории средства ведения журнала, отправляющие данные телеметрии в таблицу AppTraces :

   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
   

   Результат показывает две основные категории, ответственные за затраты:

   

Сценарий 2. Прием больших данных в Application Insights

Чтобы определить факторы, влияющие на затраты, выполните следующие действия.

1. Запросите данные телеметрии во всех таблицах и получите количество записей для каждой таблицы и версии пакета SDK:

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

   В следующем примере показано, как функции Azure создают множество данных телеметрии трассировки и исключений:

   

2. Выполните следующий запрос, чтобы получить конкретное приложение, создающее больше трассировок, чем другие:

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

   

3. Уточняйте запрос, чтобы включить это конкретное приложение и создать количество записей на каждое отдельное сообщение:

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

   Результат может показать конкретные расходы на прием сообщений:

   

Сценарий 3. Неожиданное достижение ежедневной крышки

Представьте, что вы неожиданно достигли дневного лимита 4 сентября. Используйте следующий запрос, чтобы получить количество пользовательских событий и определить самую последнюю метку времени, связанную с каждым событием:

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

Этот анализ указывает, что некоторые события начали поступать 4 сентября и впоследствии быстро вызвали много шума.

Сокращение затрат на прием данных

После определения факторов в таблицах Azure Monitor, ответственных за непредвиденное прием данных, уменьшите затраты на прием данных с помощью следующих методов в соответствии с вашими сценариями.

Метод 1. Обновление конфигурации ежедневного ограничения

Настройте ежедневное ограничение, чтобы предотвратить чрезмерное прием данных телеметрии.

Метод 2. Переключение плана таблицы

Переключитесь на другой поддерживаемый план таблицы для Application Insights. Выставление счетов за прием данных зависит от плана таблицы и региона рабочей области Log Analytics. Ознакомьтесь с планами таблиц и таблицами, поддерживающими план базовой таблицы в журналах Azure Monitor.

Метод 3. Использование функций пакета SDK телеметрии для агента Java

Рекомендуемое базовое решение — использовать переопределения выборок. Агент Java Application Insights предоставляет два типа выборки. Распространенный вариант использования — отключение сбора телеметрических данных для проверки состояния системы.

Есть несколько дополнительных методов для изменения параметров выборки.

• Уменьшите затраты из traces таблицы:

  • Уменьшите уровень журнала телеметрии.

  • Удалите журналы приложений (не frameworks/libs) с помощью атрибута MDC и переопределения выборки.

  • Отключите инструментирование журнала, обновив файл applicationinsights.json :

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

• Уменьшите затраты из dependencies таблицы:

  • Отключение сбора телеметрии для метода Java, генерирующего телеметрию зависимостей.

  • Отключите инструментирование, создающее телеметрические данные о зависимостях.

    Если зависимость является вызовом базы данных, вы не увидите базу данных на карте приложения. При удалении инструментирования зависимостей вызова HTTP или сообщения (например, сообщения Kafka) удаляются все подчиненные данные телеметрии.

• Уменьшите затраты из customMetrics таблицы:

  • Увеличьте интервал метрик.
  • Исключение метрики с помощью обработчика телеметрии
  • Увеличьте интервал пульса.

• Уменьшите затраты на атрибуты OpenTelemetry:

  Атрибуты OpenTelemetry добавляются в столбец customDimensions . Они представлены как свойства в Application Insights. Атрибуты можно удалить с помощью обработчика телеметрии атрибутов. Дополнительные сведения см. в Примерах обработчика телеметрии — Удаление.

Метод 4. Обновление кода приложения (уровни логов или исключения)

В некоторых сценариях обновление кода приложения напрямую может помочь уменьшить объем данных телеметрии, созданных и потребляемых серверной службой Application Insights. Типичным примером может быть шумное исключение, которое отображается приложением.

Ссылки

• Цены на Azure Monitor
• Изменение ценовой категории для рабочей области Log Analytics
• Планы таблиц в Azure Monitor
• Стоимость и использование Azure Monitor
• Анализ использования в рабочей области Log Analytics
• Оптимизация затрат в Azure Monitor

Заявление об отказе от ответственности за контактные данные сторонней организации

Корпорация Майкрософт предоставляет сторонние контактные данные, которые помогут вам найти дополнительные сведения об этом разделе. Эти контактные данные могут изменяться без уведомления. Корпорация Майкрософт не гарантирует точность сторонних контактных данных.

Свяжитесь с нами для получения помощи

Если у вас есть вопросы или вам нужна помощь, создайте запрос в службу поддержки или обратитесь за поддержкой сообщества Azure. Вы также можете отправить отзыв о продукте в сообщество отзывов Azure.