Миграция из API сборщика данных HTTP в API приема журналов

Вывод из эксплуатации HTTP Data Collector API запланирован. Поддержка устаревшего API сборщика данных заканчивается 14 сентября 2026 г. Существующий процесс приема данных продолжает работать, но API получает только критические исправления безопасности. Перейдите в API приема журналов , который обеспечивает большую мощность обработки и гибкость в приеме журналов и управлении таблицами.

В этой статье описываются различия между двумя API и способами миграции в API приема журналов.

На приём данных через API Data Collector влияют две даты. 1 марта 2026 г. конечная точка API перестала принимать устаревшие версии TLS. Клиенты, которые не согласовывают протокол TLS 1.2 или более поздней версии, не могут получать данные. 14 сентября 2026 г. API завершает работу, но прием продолжается для клиентов, совместимых с TLS. Проверьте TLS-конфигурацию клиента, прежде чем считать, что приём данных выполняется корректно, независимо от сроков миграции.

Преимущества API приема журналов

API для приема журналов предоставляет следующие преимущества по сравнению с API сборщика данных:

• Поддерживает преобразования, которые позволяют изменять данные перед приемом данных в целевую таблицу, включая фильтрацию и обработку данных.
• Позволяет отправлять данные в несколько мест назначения.
• Позволяет управлять схемой целевой таблицы, включая имена столбцов, и добавлять новые столбцы в целевую таблицу при изменении схемы исходных данных.
• Поддерживает управление доступом на основе ролей (RBAC), чтобы ограничить прием данных правилом сбора данных и удостоверением.

Предварительные требования

Чтобы выполнить эту миграцию, вам потребуется:

• Рабочая область Log Analytics, в которой у вас есть по крайней мере права участника.
• Разрешения на создание правил сбора данных в рабочей области Log Analytics.
• Приложение Microsoft Entra для проверки подлинности вызовов API или любой другой схемы аутентификации Диспетчера ресурсов.

Требуемые разрешения

API приема журналов использует проверку подлинности на основе OAuth с помощью Microsoft Entra (для регистрации приложений или управляемых удостоверений) и правила сбора данных (DCR) с заданной областью RBAC. Назначьте разрешения приложения DCR и используйте конечную точку сбора данных (DCE) или конечную точку приема данных для запросов приема данных.

Создание новых ресурсов, необходимых для API приема журналов

API для приема журналов требует создать два новых типа ресурсов, которые не требуются для API сборщика данных HTTP:

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

Перенос существующих пользовательских таблиц или создание новых таблиц

Если у вас есть существующая настраиваемая таблица, в которую вы сейчас отправляете данные с помощью API сборщика данных, у вас есть следующие варианты:

• Перенесите таблицу и перейдите в API приема журналов.
• Сохраните существующую таблицу и данные и настройте новую таблицу, в которую вы отправляете данные с помощью API приема журналов. Удалите старую таблицу после готовности.
• (Не рекомендуется) Перенесите таблицу, но по-прежнему используйте устаревший API сборщика данных. Изменения существующих типов данных и нескольких изменений схемы в существующих пользовательских таблицах API сборщика данных могут привести к ошибкам.

Определение классических пользовательских таблиц

Чтобы найти таблицы, использующие API сборщика данных, используйте следующие методы:

• Свойства таблицы (портал):просмотр свойств таблицы. Таблицы, использующие API сборщика данных или прием данных с помощью устаревшего агента Log Analytics (MMA), отображаются Custom table (classic) в качестве свойства Type.

• Свойства таблицы (API):tableSubType — Classic при просмотре свойств таблицы с помощью Tableоперации API управления журналами. Ниже приведен пример команды Azure CLI, которая быстро находит все таблицы с указанными критериями:

az monitor log-analytics workspace table list \
  --resource-group myResourceGroupName --workspace-name myWorkspaceName \
  --query "[?schema.tableSubType=='Classic'].{Name:name, SubType:schema.tableSubType}" -o table

• Эвристики запросов: Подсказки из отдельных записей помогут вам более подробно изучить устаревшее использование API. Записи со значением SourceSystem в поле RestAPI указывают на то, что запись была создана API HTTP Data Collector, а значит, на момент её создания таблица была устаревшего типа. Кроме того, некоторые суффиксы имени столбца указывают, что столбец был создан устаревшим API.

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

Соглашения о суффиксах для столбцов, созданных устаревшим API:

Вопросы миграции

соединители Microsoft Sentinel переходят на соединители CCF без кода, доступные через Центр содержимого. Эти коннекторы CCF используют правила сбора данных (DCR) с API приема логов. Этот подход обеспечивает управление схемой, управляемое DCR, применяет преобразования для нормализации и повышает надежность и масштабируемость по сравнению с устаревшим API сборщика данных. Миграция может привести к новым или обновленным именам таблиц и схемам. Старые соединители на основе Функции Azure, использующие устаревший API сборщика данных HTTP и новые соединители CCF, могут временно существовать в течение переходного периода.

При миграции коннекторов Sentinel необходимо обновить зависимые артефакты (правила аналитики, запросы для поиска угроз, рабочие книги, плейбуки, парсеры) так, чтобы они ссылались на новые таблицы на базе CCF или измененные схемы. Проверьте и обновите запросы KQL, оповещения и контент-пакеты, чтобы предотвратить пробелы в приеме или обнаружении после миграции.

В этой таблице приведены рекомендации по каждому варианту.

Преобразование таблицы из версии 1 в версию 2

Чтобы преобразовать таблицу, использующую API сборщика данных (V1), в правила сбора данных и API приема журналов (V2), выполните для этой таблицы операцию миграции. Если таблица уже преобразована, эта операция не действует.

# Set variables
resourceGroupName="<ResourceGroupName>"
workspaceName="<WorkspaceName>"
tableName="<TableName_CL>"

# Migrate the table from V1 to V2
az monitor log-analytics workspace table migrate \
  --resource-group "$resourceGroupName" \
  --workspace-name "$workspaceName" \
  --table-name "$tableName"

# Set variables
$resourceGroupName = "<ResourceGroupName>"
$workspaceName = "<WorkspaceName>"
$tableName = "<TableName_CL>"

# Define parameters for Invoke-AzOperationalInsightsMigrateTable
$invokeAzOperationalInsightsMigrateTableParams = @{
    ResourceGroupName = $resourceGroupName
    WorkspaceName     = $workspaceName
    TableName         = $tableName
}

# Migrate the table from V1 to V2
Invoke-AzOperationalInsightsMigrateTable @invokeAzOperationalInsightsMigrateTableParams

POST https://management.azure.com/subscriptions/{SubscriptionId}/resourceGroups/{ResourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{WorkspaceName}/tables/{TableName_CL}/migrate?api-version=2025-07-01
Authorization: Bearer {AccessToken}

Операция migrate включает в таблице все функции настраиваемых журналов на основе DCR. Если API сборщика данных продолжает прием данных в существующие столбцы, он не создает новые столбцы. Все ранее определенные настраиваемые поля перестают получать новые данные. Не изменяйте схему для создания новых столбцов, иначе API Data Collector перестанет принимать данные для всей таблицы. Примените преобразование рабочей области, чтобы перевести таблицу на DCR и отложить переход на API приема журналов.

Уменьшите размер данных за вызов

API приема журналов принимает до 1 МБ сжатых или несжатых данных на вызов. Если необходимо отправить более 1 МБ данных, отправьте несколько вызовов параллельно. Это ограничение отличается от API сборщика данных, который принимает до 30 МБ данных на вызов.

Чтобы вызвать API приема журналов, ознакомьтесь с вызовом REST API приема журналов.

Обработка различий в типе данных GUID

Azure Monitor Logs хранит идентификаторы GUID в виде строк. API таблиц принимает guid в качестве типа столбца, но API запросов журналов и API приема журналов рассматривают и записывают этот тип данных как string. Объявите GUID-идентификаторы источников данных как string в вашем DCRstreamDeclarations. Это поведение одинаково для интерфейсов API приема данных, поэтому миграция из API сборщика данных не изменяет способ хранения или запроса существующих значений GUID. Дополнительные сведения см. в разделе "Типы данных столбцов таблицы".

Обработка изменений схемы исходных данных

API Data Collector автоматически корректирует схему устаревшей целевой таблицы при изменении схемы исходного объекта данных, а API приема журналов этого не делает. API приема логов гарантирует, что вы не будете собирать новые данные в столбцы, которые не планируете создавать.

При изменении схемы исходных данных выберите один из следующих вариантов:

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

Связанный контент

Microsoft MVP Morten Waltorp Knudsen внесли свой вклад в эту статью. Пример автоматизации установки и текущего использования API приема журналов см. в модуле AzLogDcrIngestPS PowerShell.

• Tutorial: отправка пользовательских журналов с помощью портала Azure
• Tutorial: отправка пользовательских журналов с помощью шаблонов Resource Manager и REST API