Сбор журналов и метрик с помощью Azure Log Analytics

В этой статье описывается конечная точка Azure Log Analytics для модуля диагностики Fabric Apache Spark, использующая API приема журналов.

Эмиттер диагностики Apache Spark Fabric предоставляет общую модель конфигурации для диагностики Spark для различных направлений. Для Azure Log Analytics рекомендуется использовать API приема журналов в качестве модели приема.

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

Сведения об архитектуре и выборе назначения в средстве диагностики Fabric Apache Spark см. в обзоре средства диагностики Fabric Apache Spark.

Миграция из API сборщика данных

API HTTP Data Collector устарел. Перейдите на API приема журналов, чтобы избежать сбоев и обеспечить соответствие текущим шаблонам приема данных в Azure Monitor.

Ключевые изменения в новой модели:

• Определения схемы являются явными благодаря правилам сбора данных (DCR), что обеспечивает предсказуемую валидацию схемы и более согласованные результаты запросов по сравнению с прежним подходом со свободной формой загрузки данных.
• Прием направляется через конечные точки сбора данных (DCE) и отображения DCR, которые обеспечивают более контролируемый путь приема, чем непосредственная отправка в конечную точку API для сбора данных.
• Проверка подлинности поддерживает как секрет клиента субъекта-службы, так и параметры на основе сертификатов .
• Тип испускателя изменяется с AzureLogAnalytics на AzureLogIngestion.

Миграция обычно включает создание ресурсов DCR и DCE, обновление свойств среды Spark Fabric и проверку приема данных в пользовательские таблицы Log Analytics.

Обзор API приема логов

Для диагностики Apache Spark в Microsoft Fabric API приема журналов предоставляет структурированную модель приема для проверки подлинности, определения схемы, маршрутизации и доставки таблиц в Azure Log Analytics.

Ключевые компоненты

Для программного сбора можно использовать только созданные пользователем правила сбора данных, настроенные для API получения журналов.

Пошаговые настройки

Шаг 1. Подготовка рабочей области Log Analytics

Для получения диагностики Spark требуется рабочая область Log Analytics. Это базовая единица хранения и запроса для журналов Azure Monitor.

Если у вас нет одного, создайте рабочую область Log Analytics на портале Azure.

Шаг 2. Создание конечной точки сбора данных (DCE)

Создайте конечную точку сбора данных (DCE) на портале Azure. DCE предоставляет URI конечной точки, который вы настраиваете в свойствах Spark для API сбора журналов. Регион DCE должен совпадать с регионом вашей Log Analytics рабочей области.

Пользователи могут при необходимости создавать одну или несколько типов таблиц (logs, events, metrics) metadataв зависимости от их сценария, а каждый тип таблицы имеет собственную конфигурацию DCR и имя потока. Создайте и настройте нужные типы таблиц.

1. На портале Azure перейдите к Monitor в области навигации слева.

2. В разделе "Параметры" выберите конечные точки сбора данных и нажмите кнопку "Создать".

   

3. Создайте конечную точку, а затем запишите имя DCE (например, DCEdemo).

Шаг 3. Подготовка примера схемы JSON

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

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

• Журналы событий Spark — пример схемы JSON таблицы событий Spark
• Журналы драйвера Spark и экзекьютора — пример схемы JSON таблицы логов
• Метрики Spark — пример схемы JSON таблицы метрик
• Метаданные платформы — пример схемы JSON таблицы метаданных платформы

Ниже приведен пример образца схемы JSON для таблицы логов драйвера и исполнителя Spark в Azure Log Analytics. Используйте эту схему в качестве ссылки при создании пользовательских таблиц и контроллеров домена для приема журналов.

[
  {
    "applicationId_s": "<APPLICATION_ID>",
    "applicationName_s": "<NOTEBOOK_NAME>",
    "artifactId_g": "<ARTIFACT_GUID>",
    "artifactType_s": "SynapseNotebook",
    "capacityId_g": "<CAPACITY_GUID>",
    "Category": "Log",
    "executorId_s": "driver",
    "executorMax_s": 9,
    "executorMin_s": 1,
    "ExtraFields": {
      "Category": "Log",
      "JobId": "1"
    },
    "fabricEnvId_g": "<FABRIC_ENV_GUID>",
    "fabricLivyId_g": "<FABRIC_LIVY_GUID>",
    "fabricTenantId_g": "<FABRIC_TENANT_GUID>",
    "fabricWorkspaceId_g": "<FABRIC_WORKSPACE_GUID>",
    "isHighConcurrencyEnabled_s": false,
    "Level": "INFO",
    "logger_name_s": "org.apache.spark.scheduler.dynalloc.ExecutorMonitor",
    "Message": "Executor 1 is removed.",
    "thread_name_s": "spark-listener-group-executorManagement",
    "TimeGenerated": "<TIME_GENERATED>",
    "userId_g": "<USER_ID>"
  }
]

Шаг 4. Создание пользовательской таблицы (Прямое поступление)

Создайте настраиваемую таблицу в рабочей области Log Analytics с параметром API приема журналов и отправьте пример схемы JSON в связанный DCR. Этот шаг необходим для настройки цели диагностики Spark и гарантии того, что принятые данные соответствуют ожидаемой схеме. Регион рабочей области Log Analytics, DCE и DCR должен быть одинаковым для успешной загрузки.

1. На портале Azure откройте рабочую область Log Analytics (например, loganalyticsworkspacedemo).

2. Выберите таблицы>создать>новый настраиваемый журнал (прямая приемка).

   

3. Введите параметры таблицы:

   • Имя таблицы: например, SparkLogTest (суффикс "_CL" автоматически добавляется).
   • План таблицы: аналитика
   • Правило сбора данных: создание нового DCR (например, SparkLogTestrule).
   • Конечная точка сбора данных: выберите DCE на шаге "Создание конечной точки сбора данных( DCE) (например, DCEdemo).

   

4. Нажмите кнопку Далее.

5. В схеме и преобразовании отправьте пример схемы JSON. Не нужно настраивать преобразование DCR, так как схема полностью стабилизирована на стороне клиента.

Шаг 5. Подготовка субъекта-службы к проверке подлинности

1. Зарегистрируйте приложение в Microsoft Entra ID.

   

2. Запишите Идентификатор клиента, ClientId и ClientSecret (если используется проверка подлинности секрета клиента). Эти значения используются в конфигурации Spark на шаге 6.

3. Предоставьте приложению роль Monitoring Metrics Publisher для каждого ресурса DCR таблицы. Инструкции по назначению ролей см. в разделе Назначение ролей Azure с помощью портала Azure.

   

4. Получение имени потока и идентификатора DCR. Вы можете получить идентификатор DCR и имя потока для каждой созданной вами таблицы из представления JSON ресурса Data Collection Rule (DCR) на портале Azure.

   Формат имени потока всегда: Custom-<Log Analytics table name>. Например, если имя вашей таблицы — AppLogs_CL, имя потока будет: Custom-AppLogs_CL

   На следующем шаге вы настроите в конфигурации Spark, используя эти имена потоков, значения соответствующих logStream, eventStream, metricStream или metaStream, а также значения logDcr, eventDcr, metricDcr и metaDcr.

   

Шаг 6. Настройка свойств Spark

Чтобы настроить Spark, создайте среду в Fabric и выберите один из следующих вариантов проверки подлинности. Используйте только один вариант для данного эмитатора.

Среда в Fabric хранит параметры и библиотеки Spark, которые используются записными книжками и определениями заданий Spark во время выполнения. Инструкции по созданию см. в разделе Создание, настройка и использование среды в Fabric.

• Выберите вариант 1 , если требуется упростить настройку с помощью секрета клиента.
• Выберите Option 2 если для организации требуется проверка подлинности на основе сертификатов и централизованное управление сертификатами в Azure Key Vault.

В обоих вариантах можно выбрать Добавить из .yml в среде для импорта .yml файла конфигурации.

Вариант 1. Настройте с помощью учетной записи службы и клиентского секрета

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

1. Создайте среду в Fabric.

2. Добавьте следующие свойства Spark с соответствующими значениями в среду или выберите "Добавить из .yml" на ленте, чтобы импортировать .yml файл конфигурации.

   spark.synapse.diagnostic.emitters: <EMITTER_NAME>
   spark.synapse.diagnostic.emitter.<EMITTER_NAME>.type: AzureLogIngestion
   spark.synapse.diagnostic.emitter.<EMITTER_NAME>.categories: DriverLog,ExecutorLog,EventLog,Metrics
   spark.synapse.diagnostic.emitter.<EMITTER_NAME>.dceUri: https://<DCE_NAME>.<REGION>.ingest.monitor.azure.com
   spark.synapse.diagnostic.emitter.<EMITTER_NAME>.logDcr: <LOG_DCR_ID>
   spark.synapse.diagnostic.emitter.<EMITTER_NAME>.logStream: <LOG_STREAM_NAME>
   spark.synapse.diagnostic.emitter.<EMITTER_NAME>.eventDcr: <EVENT_DCR_ID>
   spark.synapse.diagnostic.emitter.<EMITTER_NAME>.eventStream: <EVENT_STREAM_NAME>
   spark.synapse.diagnostic.emitter.<EMITTER_NAME>.metricDcr: <METRIC_DCR_ID>
   spark.synapse.diagnostic.emitter.<EMITTER_NAME>.metricStream: <METRIC_STREAM_NAME>
   spark.synapse.diagnostic.emitter.<EMITTER_NAME>.metaDcr: <META_DCR_ID>
   spark.synapse.diagnostic.emitter.<EMITTER_NAME>.metaStream: <META_STREAM_NAME>
   spark.synapse.diagnostic.emitter.<EMITTER_NAME>.secret: <SP_CLIENT_SECRET>
   spark.synapse.diagnostic.emitter.<EMITTER_NAME>.tenantId: <SP_TENANT_ID>
   spark.synapse.diagnostic.emitter.<EMITTER_NAME>.clientId: <SP_CLIENT_ID>
   spark.fabric.pools.skipStarterPools: 'true'
   

3. Сохраните и опубликуйте изменения.

Вариант 2: Настройка с использованием аутентификации с сертификатом служебного принципала

Используйте этот параметр, если для организации требуется проверка подлинности на основе сертификатов.

Перед началом работы убедитесь, что учетная запись службы создана с помощью сертификата. Дополнительные сведения см. в разделе Создание сервис-принципала, содержащего сертификат, с помощью Azure CLI.

1. Создайте среду в Fabric.

2. Добавьте следующие свойства Spark с соответствующими значениями в среду или выберите "Добавить из .yml" на ленте, чтобы импортировать .yml файл конфигурации.

   spark.synapse.diagnostic.emitters: <EMITTER_NAME>
   spark.synapse.diagnostic.emitter.<EMITTER_NAME>.type: AzureLogIngestion
   spark.synapse.diagnostic.emitter.<EMITTER_NAME>.categories: DriverLog,ExecutorLog,EventLog,Metrics
   spark.synapse.diagnostic.emitter.<EMITTER_NAME>.dceUri: https://<DCE_NAME>.<REGION>.ingest.monitor.azure.com
   spark.synapse.diagnostic.emitter.<EMITTER_NAME>.logDcr: <LOG_DCR_ID>
   spark.synapse.diagnostic.emitter.<EMITTER_NAME>.logStream: <LOG_STREAM_NAME>
   spark.synapse.diagnostic.emitter.<EMITTER_NAME>.eventDcr: <EVENT_DCR_ID>
   spark.synapse.diagnostic.emitter.<EMITTER_NAME>.eventStream: <EVENT_STREAM_NAME>
   spark.synapse.diagnostic.emitter.<EMITTER_NAME>.metricDcr: <METRIC_DCR_ID>
   spark.synapse.diagnostic.emitter.<EMITTER_NAME>.metricStream: <METRIC_STREAM_NAME>
   spark.synapse.diagnostic.emitter.<EMITTER_NAME>.metaDcr: <META_DCR_ID>
   spark.synapse.diagnostic.emitter.<EMITTER_NAME>.metaStream: <META_STREAM_NAME>
   spark.synapse.diagnostic.emitter.<EMITTER_NAME>.certificate.keyVault.certificateName: <SP_CERT-NAME>
   spark.synapse.diagnostic.emitter.<EMITTER_NAME>.certificate.keyVault: https://<KEYVAULT_NAME>.vault.azure.net/
   spark.synapse.diagnostic.emitter.<EMITTER_NAME>.tenantId: <SP_TENANT_ID>
   spark.synapse.diagnostic.emitter.<EMITTER_NAME>.clientId: <SP_CLIENT_ID>
   spark.fabric.pools.skipStarterPools: 'true'
   

3. Сохраните и опубликуйте изменения.

Шаг 7. Подключите среду к записным книжкам или определениям заданий Spark или задайте ее в качестве рабочей области по умолчанию

Используйте один из следующих подходов в зависимости от вашего объёма работы.

• Подключите среду к конкретным записным книжкам или определениям заданий Spark, если требуется адресное развертывание, тестирование или индивидуальное управление.
• Установите среду в качестве рабочей области по умолчанию, если требуется согласованные параметры диагностики Spark, применяемые в рабочей области.

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

1. Перейдите к блокноту или определению задания Spark в Fabric.
2. Выберите меню "Среда" на вкладке "Главная" и выберите настроенную среду.
3. Конфигурация будет применена после запуска сеанса Spark.

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

1. Перейдите к параметрам рабочей области в Fabric.
2. Найдите параметры Spark в параметрах рабочей области (параметры рабочей области>Инженерия/Наука о данных>параметры Spark).
3. Перейдите на вкладку "Среда " и выберите среду с настроенными свойствами Spark диагностики и нажмите кнопку "Сохранить".

Шаг 8. Запуск рабочих нагрузок Spark и проверка журналов и метрик

Используйте созданную и присоединенную среду в предыдущем разделе, а затем запустите рабочие нагрузки Spark и проверьте прием в Log Analytics.

1. Запустите рабочие нагрузки Spark с помощью среды, настроенной в предыдущем разделе. Можно использовать один из следующих методов:
   • Запустите записную книжку в Fabric.
   • Отправьте пакетное задание Spark с помощью определения задания Spark.
   • Запустите действия Spark в конвейере.
2. Откройте целевую рабочую область Log Analytics и убедитесь, что журналы и метрики получены для выполняемой рабочей нагрузки.
3. Чтобы проверить ингестацию и инспектировать записи, используйте примеры Kusto в разделе Запрос данных с помощью Kusto.

Создайте настраиваемые журналы приложений

Используйте пользовательские журналы приложений, если требуется бизнес-уровень или события для конкретного приложения в дополнение к диагностике платформы. Эти журналы создаются через один и тот же диагностический конвейер и отображаются в Log Analytics вместе с журналами Spark, журналами событий и метриками.

Используйте Apache Log4j в коде Spark для отправки пользовательских сообщений журнала. В следующих примерах показан минимальный шаблон для Scala и PySpark.

Пример Scala:

%%spark
val logger = org.apache.log4j.LogManager.getLogger("com.contoso.LoggerExample")
logger.info("info message")
logger.warn("warn message")
logger.error("error message")
//log exception
try {
      1/0
 } catch {
      case e:Exception =>logger.warn("Exception", e)
}
// run job for task level metrics
val data = sc.parallelize(Seq(1,2,3,4)).toDF().count()

Пример PySpark:

%%pyspark
logger = sc._jvm.org.apache.log4j.LogManager.getLogger("com.contoso.PythonLoggerExample")
logger.info("info message")
logger.warn("warn message")
logger.error("error message")

Запрос данных с помощью Kusto

Используйте запросы Kusto для подтверждения того, что поглощение данных работает, и чтобы исследовать срабатывание Spark. Замените значения заполнителей, например {FabricWorkspaceId}, {ArtifactId} и {LivyId} значениями из собственного запуска.

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

Запрос событий Apache Spark:

SparkEventTest_CL
| where fabricWorkspaceId_g == "{FabricWorkspaceId}" and artifactId_g == "{ArtifactId}" and fabricLivyId_g == "{LivyId}"
| order by TimeGenerated desc
| limit 100 

Чтобы запросить журналы драйвера приложения Spark и исполнителя, выполните приведенные ниже действия.

SparkLogTest_CL
| where fabricWorkspaceId_g == "{FabricWorkspaceId}" and artifactId_g == "{ArtifactId}" and fabricLivyId_g == "{LivyId}"
| order by TimeGenerated desc
| limit 100 

Запрос метрик Apache Spark:

SparkMetricsTest_CL
| where fabricWorkspaceId_g == "{FabricWorkspaceId}" and artifactId_g == "{ArtifactId}" and fabricLivyId_g == "{LivyId}"
| where name_s endswith "jvm.total.used"
| summarize max(value_d) by bin(TimeGenerated, 30s), executorId_s
| order by TimeGenerated asc

Запрос метаданных платформы:

SparkMetadataTest_CL 
| where fabricWorkspaceId_g == "{FabricWorkspaceId}" and artifactId_g == "{ArtifactId}" and fabricLivyId_g == "{LivyId}"
| order by TimeGenerated desc
| limit 100

Рабочие области Fabric с управляемой виртуальной сетью

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

Доступные конфигурации Apache Spark

В следующей таблице перечислены конфигурации Spark для отправки журналов и метрик в Azure Log Analytics с помощью API приема журналов.

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

• Создать определение задания Apache Spark
• Создание, настройка и использование среды в Microsoft Fabric
• Разработка, выполнение и управление блокнотами Microsoft Fabric
• Мониторинг приложений Spark
• Сбор диагностических данных Apache Spark с помощью Центры событий Azure
• Соберите диагностику Apache Spark с помощью служба хранилища Azure учетной записи