Руководство: Прием событий из Центры событий Azure в журналы Azure Monitor (общедоступная предварительная версия)

Центры событий Azure — это платформа потоковой передачи больших данных, которая собирает события из нескольких источников для приема в Azure и внешних службах. В этой статье объясняется, как получать данные непосредственно из концентратора событий в рабочую область Log Analytics.

В этом руководстве описано следующее:

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

Чтобы отправлять события из Центры событий Azure в журналы Azure Monitor, вам потребуются следующие ресурсы:

• Рабочая область Log Analytics, где у вас есть как минимум права участника.
• Рабочая область Log Analytics должна быть связана с выделенным кластеромили иметь уровень обязательств.
• Пространство имен Центров событий, которое разрешает доступ к общедоступной сети. Если доступ к общедоступной сети отключен, убедитесь, что параметр "Разрешить доверенным службы Майкрософт обойти этот брандмауэр" имеет значение "Да".
• Центр обработки с событиями. Вы можете отправлять события в концентратор событий, выполнив действия, описанные в разделе "Отправка и получение событий" в руководствах Центры событий Azure или путем настройки параметров диагностики ресурсов Azure.

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

Поддерживаемые регионы

Azure Monitor в настоящее время поддерживает прием из Центров событий в следующих регионах:

Необходимо создать ассоциацию правил сбора данных (DCRA) в том же регионе, что и концентратор событий. Рабочая область Log Analytics может находиться в любом регионе, но правило сбора данных (DCR) и конечная точка сбора данных (DCE) должны находиться в том же регионе, что и рабочая область Log Analytics.

Для минимальной задержки рекомендуется разместить все ресурсы в одном регионе.

Сбор необходимых сведений

Вам потребуется идентификатор подписки, имя группы ресурсов, имя рабочей области, идентификатор ресурса рабочей области и идентификатор ресурса концентратора событий в последующих шагах:

1. Перейдите в рабочую область в меню "Рабочие области Log Analytics" и выберите "Свойства " и скопируйте идентификатор подписки, группу ресурсов и имя рабочей области. Эти сведения необходимы для создания ресурсов в этом руководстве.

   

2. Выберите JSON, чтобы открыть экран Resource JSON и скопировать Идентификатор ресурса рабочей области. Для создания правила сбора данных требуется идентификатор ресурса рабочей области.

   

3. Перейдите к экземпляру концентратора событий, выберите JSON, чтобы открыть экран JSON ресурса, и скопируйте идентификатор ресурса концентратора событий. Для связывания правила сбора данных с концентратором событий вам необходим идентификатор ресурса экземпляра концентратора событий.

   

Создание целевой таблицы в рабочей области Log Analytics

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

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

1. Нажмите кнопку Cloud Shell и убедитесь, что среда установлена на PowerShell.

   

2. Выполните следующую команду PowerShell, чтобы создать таблицу, укажите имя таблицы () в ФОРМАТЕ JSON (<table_name>с суффиксом _CL для настраиваемой таблицы) и задайте <subscription_id><resource_group_name><workspace_name><table_name>значения , и <api_version> значения в команде:Invoke-AzRestMethod -Path

   $tableParams = @'
   {
       "properties": {
           "schema": {
               "name": "<table_name>",
               "columns": [
                   {
                       "name": "TimeGenerated",
                       "type": "datetime",
                       "description": "The time at which the data was ingested."
                   },
                   {
                       "name": "RawData",
                       "type": "string",
                       "description": "Body of the event."
                   },
                   {
                       "name": "Properties",
                       "type": "dynamic",
                       "description": "Additional message properties."
                   }
               ]
           }
       }
   }
   '@
   
   $restMethodParams = @{
       Path    = "/subscriptions/<subscription_id>/resourcegroups/<resource_group_name>/providers/microsoft.operationalinsights/workspaces/<workspace_name>/tables/<table_name>?api-version=<api_version>"
       Method  = "PUT"
       Payload = $tableParams}
   
   Invoke-AzRestMethod @restMethodParams
   

Создание конечной точки сбора данных

Для сбора данных с помощью правила сбора данных требуется конечная точка. В этом руководстве описывается создание конечной точки сбора данных (DCE). Необязательный подход, не описанный здесь, заключается в использовании конечной точки приема DCR.

1. Создайте конечную точку сбора данных в том же регионе, что и рабочая область Log Analytics.

2. На обзорном экране точки завершения сбора данных выберите JSON Вид.

   

3. Скопируйте идентификатор ресурса для правила сбора данных. Эти сведения используются на следующем шаге.

   

Создание правила сбора данных

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

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

1. В поле поиска портала введите шаблон и выберите " Развернуть пользовательский шаблон".

   

2. Выберите Создать собственный шаблон в редакторе.

   

3. Вставьте следующий шаблон Resource Manager в редактор и нажмите кнопку "Сохранить".

   

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

   • identity — определяет, какой тип управляемого удостоверения использовать. В нашем примере мы используем назначаемое системой удостоверение. Вы также можете настроить управляемую идентичность, назначаемую пользователем.

   • dataCollectionEndpointId — идентификатор ресурса конечной точки сбора данных.

   • streamDeclarations — определяет, какие данные следует принять из концентратора событий (входящие данные). Невозможно изменить объявление потока.

     • TimeGenerated — Время приема данных из концентратора событий в журналы Azure Monitor.
     • RawData — Основная часть события. Дополнительные сведения см. в разделе "Чтение событий".
     • Properties — Свойства пользователя из события. Дополнительные сведения см. в разделе "Чтение событий".

   • datasources — указывает группу потребителей концентратора событий и поток, в который вы отправляете данные.

   • destinations — указывает все назначения, в которых будут отправляться данные. Вы можете загружать данные в одну или несколько рабочих областей Log Analytics.

   • dataFlows — соответствует потоку с целевой рабочей областью и указывает запрос преобразования и целевую таблицу. В нашем примере мы вводим данные в созданную ранее пользовательскую таблицу. Вы также можете загружать данные в поддерживаемую таблицу Azure.

   • transformKql — указывает преобразование, которое будет применяться к входящим данным (объявлению потока) перед отправкой в рабочую область. В нашем примере мы установили transformKql на source, что никак не изменяет данные из источника, потому что мы отображаем входящие данные на пользовательскую таблицу, созданную специально с соответствующей схемой. Если вы загружаете данные в таблицу с другой схемой или фильтруете данные перед загрузкой, определите преобразование для сбора данных.

   {
       "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
       "contentVersion": "1.0.0.0",
       "parameters": {
           "dataCollectionRuleName": {
               "type": "string",
               "metadata": {
                   "description": "Specifies the name of the data collection Rule to create."
               }
           },
           "workspaceResourceId": {
               "type": "string",
               "metadata": {
                   "description": "Specifies the Azure resource ID of the Log Analytics workspace to use."
               }
           },
           "endpointResourceId": {
               "type": "string",
               "metadata": {
                   "description": "Specifies the Azure resource ID of the data collection endpoint to use."
               }
           },
           "tableName": {
               "type": "string",
               "metadata": {
                   "description": "Specifies the name of the table in the workspace."
               }
           },
           "consumerGroup": {
               "type": "string",
               "metadata": {
                   "description": "Specifies the consumer group of event hub."
               },
               "defaultValue": "$Default"
           }
       },
       "resources": [
           {
               "type": "Microsoft.Insights/dataCollectionRules",
               "name": "[parameters('dataCollectionRuleName')]",
               "location": "[resourceGroup().location]", 
               "apiVersion": "2022-06-01",
               "identity": {
                   "type": "systemAssigned"
               },
               "properties": {
                   "dataCollectionEndpointId": "[parameters('endpointResourceId')]",
                   "streamDeclarations": {
                       "Custom-MyEventHubStream": {
                           "columns": [
                               {
                                   "name": "TimeGenerated",
                                   "type": "datetime"
                               },
                               {
                                   "name": "RawData",
                                   "type": "string"
                               },
                               {
                                   "name": "Properties",
                                   "type": "dynamic"
                               }
                           ]
                       }
                   },
                   "dataSources": {
                       "dataImports": {
                           "eventHub": {
                               "consumerGroup": "[parameters('consumerGroup')]",
                               "stream": "Custom-MyEventHubStream",
                               "name": "myEventHubDataSource1"
                           }
                       }
                   },
                   "destinations": {
                       "logAnalytics": [
                           {
                               "workspaceResourceId": "[parameters('workspaceResourceId')]",
                               "name": "MyDestination"
                           }
                       ]
                   },
                   "dataFlows": [
                       {
                           "streams": [
                               "Custom-MyEventHubStream"
                           ],
                           "destinations": [
                               "MyDestination"
                           ],
                           "transformKql": "source",
                           "outputStream": "[concat('Custom-', parameters('tableName'))]"
                       }
                   ]
               }
           }
       ]
   }
   

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

   • Регион — регион для правила сбора данных. Заполняется автоматически на основе выбранной группы ресурсов.
   • Имя правила сбора данных — присвойте правилу имя.
   • Идентификатор ресурса рабочей области - см. Сбор необходимых сведений.
   • Идентификатор ресурса конечной точки— создается при создании конечной точки сбора данных.
   • Имя таблицы — имя целевой таблицы. В нашем примере и всякий раз, когда вы используете пользовательскую таблицу, имя таблицы должно заканчиваться суффиксом _CL. Если вы вводите данные в таблицу Azure, введите имя таблицы ( например, Syslog без суффикса).
   • Группа потребителей — по умолчанию для группы потребителей задано $Defaultзначение . При необходимости измените значение на другую группу потребителей концентратора событий.

   

5. Нажмите Просмотр и создание, а затем Создать, когда вы просмотрите сведения.

6. По завершении развертывания разверните поле сведений о развертывании и выберите правило сбора данных для просмотра сведений. Выберите режим JSON.

   

7. Скопируйте идентификатор ресурса для правила сбора данных. Эти сведения используются на следующем шаге.

   

Настройка назначаемого пользователем управляемого удостоверения (необязательно)

Чтобы настроить правило сбора данных для поддержки пользовательского назначенного удостоверения, в шаблоне DCR замените:

    "identity": {
        "type": "systemAssigned"
    },

С:

    "identity": {
        "type": "userAssigned",
        "userAssignedIdentities": {
            "<identity_resource_Id>": {
            }
        }
    },

Чтобы найти <identity_resource_Id> значение, перейдите к ресурсу управляемого удостоверения, назначенному пользователем, на портале Azure, выберите JSON, чтобы открыть экран Resource JSON и скопировать идентификатор ресурса управляемого удостоверения.

Прием данных журнала в таблицу Azure (необязательно)

Чтобы получить данные в таблицу Azure, поддерживающую API приема журналов:

1. В правиле сбора данных измените outputStream:

   От: "outputStream": "[concat('Custom-', parameters('tableName'))]"

   Кому: "outputStream": "outputStream": "[concat(Microsoft-', parameters('tableName'))]"

2. В transformKql, определите преобразование, которое отправляет полученные данные в целевые столбцы в таблице назначения Azure.

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

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

1. В концентраторе событий или пространстве имен Центров событий в портале Azure выберите контроль доступа (IAM), затем >.

   

2. Выберите Приемник данных Центры событий Azure и выберите Далее.

   

3. Выберите управляемое удостоверение для назначения доступа и нажмите кнопку "Выбрать участников". Выберите правило сбора данных, найдите правило сбора данных по имени и нажмите кнопку "Выбрать".

   

4. Выберите «Проверить и назначить» и проверьте сведения перед сохранением назначения роли.

   

Свяжите правило сбора данных с концентратором событий

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

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

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

1. На портале Azure в поле поиска введите шаблон, а затем выберите Развернуть настраиваемый шаблон.

2. Выберите Создать собственный шаблон в редакторе.

3. Вставьте следующий шаблон Resource Manager в редактор и нажмите кнопку "Сохранить".

   {
     "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
     "contentVersion": "1.0.0.0",
     "parameters": {
       "eventHubResourceID": {
         "type": "string",
         "metadata": {
           "description": "Specifies the Azure resource ID of the event hub instance to use."
         }
       },
       "associationName": {
         "type": "string",
         "metadata": {
           "description": "The name of the association."
         }
       },
       "dataCollectionRuleID": {
         "type": "string",
         "metadata": {
           "description": "The resource ID of the data collection rule."
         }
       }
     },
     "resources": [
       {
         "type": "Microsoft.Insights/dataCollectionRuleAssociations",
         "apiVersion": "2021-09-01-preview",
         "scope": "[parameters('eventHubResourceId')]",
         "name": "[parameters('associationName')]",
         "properties": {
           "description": "Association of data collection rule. Deleting this association will break the data collection for this event hub.",
           "dataCollectionRuleId": "[parameters('dataCollectionRuleId')]"
         }
       }
     ]
   }
   

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

   • Регион — заполняется автоматически на основе выбранной группы ресурсов.
   • Идентификатор ресурса экземпляра центра событий — см. Сбор необходимых сведений.
   • Имя ассоциации — присвойте ассоциации имя.
   • Идентификатор правила сбора данных— создается при создании правила сбора данных.

   

5. Нажмите Просмотр и создание, а затем Создать, когда вы просмотрите сведения.

Проверьте целевую таблицу на наличие загруженных событий

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

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

1. Перейдите в ваше рабочее пространство и выберите Журналы.

2. Напишите простой запрос в редакторе запросов и нажмите кнопку "Выполнить".

   <table_name>
   

   События должны отображаться из вашего концентратора событий.

   

Очистка ресурсов

В этом руководстве вы создали следующие ресурсы:

• Пользовательская таблица
• Конечная точка сбора данных
• Правило сбора данных
• Сопоставление правил сбора данных

Оцените, требуются ли эти ресурсы. Удалите ресурсы, которые вам не нужны отдельно, или удалите все эти ресурсы одновременно, удалив группу ресурсов. Оставленные в работе ресурсы могут приводить к дополнительным затратам.

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

Рекомендации

• Если вы передаете подписку между каталогами Microsoft Entra, необходимо выполнить действия, описанные в разделе "Известные проблемы с управляемыми удостоверениями для ресурсов Azure" для продолжения приема данных.
• Azure Monitor журналы принимают сообщения, принимаемые из Центров событий до максимального размера 64 КБ.

Альтернативные решения

Если вы не можете настроить прием из Центров событий из-за ограничений емкости в целевом регионе, рассмотрите один из следующих вариантов:

1. Разверните в другом регионе Azure, где доступна емкость, если это разрешено для архитектуры и соответствия требованиям.

2. Используйте альтернативные методы приема Azure Monitor, если применимо:

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

3. Используйте Azure Logic Apps для извлечения событий из Центров событий и потоковой передачи в рабочую область Log Analytics с помощью API приема журналов.

4. Потоковая передача событий из концентратора событий в рабочую область Log Analytics с помощью подключаемого модуля вывода Logstash.

Связанные материалы

• Создайте настраиваемую таблицу.
• Создайте конечную точку сбора данных.
• Обновите существующее правило сбора данных.