Миграция из API сборщика данных HTTP в API приема журналов для отправки данных в журналы Azure Monitor
API приема журналов Azure Monitor обеспечивает большую мощность обработки и большую гибкость в приеме журналов и управлении таблицами, чем устаревший API сборщика данных HTTP. В этой статье описываются различия между API сборщика данных и API приема журналов, а также приведены рекомендации и рекомендации по миграции в новый API приема журналов.
Примечание.
В качестве MVP Microsoft Мортен Уолторп Кнудсен способствовал и предоставил материалы для этой статьи. Пример того, как можно автоматизировать настройку и текущее использование API приема журналов, см. в общедоступном модуле AzLogDcrIngestPS PowerShell.
Преимущества API приема журналов
API приема журналов предоставляет следующие преимущества по API сборщика данных:
- Поддерживает преобразования, которые позволяют изменять данные перед приемом в целевую таблицу, включая фильтрацию и обработку данных.
- Позволяет отправлять данные в несколько назначений.
- Позволяет управлять схемой целевой таблицы, включая имена столбцов, и добавлять новые столбцы в целевую таблицу при изменении схемы исходных данных.
Необходимые компоненты
Процедура миграции, описанная в этой статье, предполагает, что у вас есть:
- Рабочая область Log Analytics, в которой у вас есть по крайней мере права участника.
- Разрешения на создание правил сбора данных в рабочей области Log Analytics.
- Приложение Microsoft Entra для проверки подлинности вызовов API или любой другой схемы проверки подлинности Resource Manager.
Требуемые разрешения
| Действие | Требуемые разрешения |
|---|---|
| Создайте конечную точку сбора данных. | 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,_ResourceIdTypeUniqueId_SubscriptionIdTenantIdиTitleявляются зарезервированными именами столбцов.- Настраиваемые столбцы, добавляемые в таблицу Azure, должны иметь суффикс
_CF. - При обновлении схемы таблицы в рабочей области Log Analytics необходимо также обновить определение входного потока в правиле сбора данных, чтобы получить данные в новых или измененных столбцах.
Вызов API приема журналов
API приема журналов позволяет отправлять до 1 МБ сжатых или несжатых данных на вызов. Если вам нужно отправить более 1 МБ данных, можно одновременно отправлять несколько вызовов. Это изменение с API сборщика данных, которое позволяет отправлять до 32 МБ данных на вызов.
Сведения о вызове API приема журналов см. в статье "Вызов REST API приема журналов".
Изменение схем таблиц и правил сбора данных на основе изменений в объекте исходных данных
Хотя API сборщика данных автоматически настраивает схему целевой таблицы при изменении схемы исходного объекта данных, API приема журналов не выполняется. Это гарантирует, что вы не собираетесь собирать новые данные в столбцы, которые вы не собирали создавать.
При изменении схемы исходных данных можно:
- Измените схемы целевой таблицы и правила сбора данных, чтобы выровнять изменения схемы исходных данных.
- Определите преобразование в правиле сбора данных для отправки новых данных в существующие столбцы в целевой таблице.
- Оставьте целевую таблицу и правило сбора данных без изменений. В этом случае вы не будете прием новых данных.
Примечание.
Нельзя повторно использовать имя столбца с типом данных, который отличается от исходного типа данных, определенного для столбца.