Поделиться через

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

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

Примечание.

В качестве MVP Microsoft Мортен Уолторп Кнудсен способствовал написанию этой статьи и предоставил существенную обратную связь. Пример того, как можно автоматизировать настройку и текущее использование API приема журналов, см. в общедоступном модуле AzLogDcrIngestPS PowerShell.

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

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

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

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

Процедура миграции, описанная в этой статье, предполагает, что у вас есть:

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

Действие Требуемые разрешения
Создайте конечную точку сбора данных. Microsoft.Insights/dataCollectionEndpoints/writeразрешения, предоставляемые, например, встроенной ролью участника мониторинга.
Создайте или измените правило сбора данных. Microsoft.Insights/DataCollectionRules/Writeразрешения, предоставляемые, например, встроенной ролью участника мониторинга.
Преобразуйте таблицу, которая использует API сборщика данных в правила сбора данных и API приема журналов. Microsoft.OperationalInsights/workspaces/tables/migrate/actionразрешения, предоставляемые встроенной ролью Участника Log Analytics, например.
Создайте новые таблицы или измените схемы таблиц. microsoft.operationalinsights/workspaces/tables/writeразрешения, предоставляемые встроенной ролью Участника Log Analytics, например.
Вызовите API приема журналов. См. раздел "Назначение разрешений для DCR".

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

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

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

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

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

  • Перенесите таблицу, чтобы продолжить прием данных в ту же таблицу с помощью API приема журналов.

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

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

Совет

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

В этой таблице приведены рекомендации, которые следует учитывать для каждого варианта:

Перенос таблиц Параллельное внедрение
Именование таблиц и столбцов Повторное использование существующего имени таблицы.
Параметры именования столбцов:
— Используйте новые имена столбцов и определите преобразование для направления входящих данных в только что именованный столбец.
— Продолжить использование старых имен.		 Задайте свободное имя новой таблицы.
Перед переходом на новую таблицу необходимо настроить интеграцию, панели мониторинга и оповещения.
Процедура миграции Миграция одноуровневой таблицы. Невозможно откатить таблицу после её переноса. Миграция может выполняться постепенно, для каждой таблицы.
После миграции Вы можете продолжать прием данных с помощью API сборщика данных HTTP с существующими столбцами, за исключением пользовательских столбцов.
Загружайте данные в новые столбцы только с помощью API загрузки логов.		 Данные в старой таблице доступны до конца срока хранения.
При первой настройке новой таблицы или внесении изменений схемы может потребоваться 10–15 минут, чтобы изменения данных начали появляться в целевой таблице.

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

POST https://management.azure.com/subscriptions/{subscriptionId}/resourcegroups/{resourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{workspaceName}/tables/{tableName}/migrate?api-version=2021-12-01-preview

Этот вызов является идемпотентным, поэтому он не действует, если таблица уже преобразована.

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

Внимание

  • Имена столбцов должны начинаться с буквы и могут содержать до 45 буквенно-цифровых символов и символов подчеркивания (_).
  • _ResourceId, id, _ResourceId_SubscriptionIdTenantIdTypeUniqueIdи Title являются зарезервированными именами столбцов.
  • Настраиваемые столбцы, добавляемые в таблицу Azure, должны иметь суффикс _CF.
  • При обновлении схемы таблицы в рабочей области Log Analytics необходимо также обновить определение входного потока в правиле сбора данных, чтобы получить данные в новых или измененных столбцах.

Вызов API приема журналов

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

Сведения о вызове API приема журналов см. в статье "Вызов REST API приема журналов".

Изменение схем таблиц и правил сбора данных на основе изменений в объекте исходных данных

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

При изменении схемы исходных данных можно:

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

Примечание.

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

Следующие шаги