Агрегирование и сбор событий с помощью Диагностики Azure для Windows

Статья
05/11/2023

Во время работы кластера Azure Service Fabric рекомендуется централизованно собирать журналы со всех узлов. Централизованное хранение журналов упрощает анализ и устранение неполадок в кластере, а также в приложениях и службах, работающих в этом кластере.

Один из способов отправки и сбора журналов заключается в использовании расширения Диагностики Azure для Windows (WAD), которое отправляет журналы в службу хранилища Azure, а также может отправлять журналы в Azure Application Insights или Центры событий Azure. Вы также можете использовать внешний процесс, чтобы считывать события из хранилища и передавать их в платформу обработки, например в журналы Azure Monitor или другое решение для синтаксического анализа журналов.

Примечание.

Мы рекомендуем использовать модуль Azure Az PowerShell для взаимодействия с Azure. Чтобы начать работу, см. статью Установка Azure PowerShell. Дополнительные сведения см. в статье Перенос Azure PowerShell с AzureRM на Az.

Необходимые компоненты

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

События платформы Service Fabric

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

Рабочие события: операции высокого уровня, выполняемые платформой Service Fabric. Некоторые примеры: создание приложений и служб, изменение состояния узлов и сведения об обновлении. Они передаются в рамках журналов трассировки событий для Windows (ETW).
События модели программирования на основе Reliable Actors.
События модели программирования на основе Reliable Services.

Развертывание расширения системы диагностики с помощью портала

Для сбора журналов прежде всего нужно развернуть расширение системы диагностики на каждом узле масштабируемого набора виртуальных машин в кластере Service Fabric. Расширение системы диагностики собирает журналы на каждой виртуальной машине и отправляет их в указанную учетную запись хранения. Ниже описано, как настроить это для новых и существующих кластеров с помощью портала Azure и шаблонов Azure Resource Manager.

Развертывание расширения системы диагностики в ходе создания кластера с помощью портала Azure

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

Azure Diagnostics settings in the portal for cluster creation

Мы настоятельно рекомендуем скачать шаблон прежде, чем вы щелкнете "Создать" на последнем шаге. Дополнительную информацию см. в статье Создание кластера Service Fabric с помощью Azure Resource Manager. Этот шаблон потребуется для настройки каналов (перечисленных выше), из которых вы намерены собирать данные.

Cluster Template

Итак, вы настроили сбор данных о событиях в хранилище Azure. Теперь следует настроить журналы Azure Monitor для анализа данных и запроса информации с помощью портала журналов Azure Monitor.

Примечание.

Сейчас не поддерживается возможность фильтрации или очистки событий, которые отправляются в таблицы. Если вы не реализуете метод для удаления событий из таблицы, она будет постоянно расти. По умолчанию действует ограничение в 50 ГБ. Вы можете изменить это ограничение, используя инструкции, приведенные ниже в этой статье. Кроме того, там есть пример службы для очистки данных, выполняющийся в примере модуля наблюдения. Мы рекомендуем создать свою службу, если у вас нет веских причин хранить журналы дольше 30 или 90 дней.

Развертывание расширения системы диагностики с помощью Azure Resource Manager

Создание кластера с расширением системы диагностики

Чтобы создать кластер с помощью Resource Manager, добавьте код JSON с конфигурацией системы диагностики в полный шаблон Resource Manager. Мы предоставляем пример шаблона диспетчера ресурсов для кластера из пяти виртуальных машин с конфигурацией системы диагностики (эта конфигурация входит в примеры шаблонов диспетчера ресурсов). Этот шаблон можно найти в коллекции примеров Azure. См. статью Пример шаблона Resource Manager — кластер из пяти узлов с системой диагностики.

Чтобы просмотреть параметр системы диагностики в шаблоне Resource Manager, откройте файл azuredeploy.json и выполните поиск IaaSDiagnostics. Чтобы создать кластер с помощью этого шаблона, нажмите кнопку Развернуть в Azure, которая доступна по ссылке выше.

Также можно скачать пример шаблона Resource Manager, внести в него изменения и создать кластер на основе измененного шаблона с помощью команды New-AzResourceGroupDeployment в окне Azure PowerShell. Параметры, передаваемые в команду, приведены в коде ниже. Дополнительные инструкции по развертыванию группы ресурсов с помощью PowerShell см. в статье Развертывание ресурсов с использованием шаблонов Resource Manager и Azure PowerShell.

Добавление расширения системы диагностики к существующему кластеру

Если у вас есть кластер, в котором еще не развернута система диагностики, вы можете добавить или обновить систему диагностики с помощью шаблона кластера. Измените шаблон Resource Manager, который используется для создания существующего кластера, или скачайте шаблон на портале, как описано выше. Измените файл template.json, выполнив следующие действия.

Добавьте новый ресурс хранилища в шаблон, внеся изменения в раздел resources.

{
	"apiVersion": "2018-07-01",
	"type": "Microsoft.Storage/storageAccounts",
	"name": "[parameters('applicationDiagnosticsStorageAccountName')]",
	"location": "[parameters('computeLocation')]",
	"sku": {
	"name": "[parameters('applicationDiagnosticsStorageAccountType')]"
	"tier": "standard"
  },
	"tags": {
	"resourceType": "Service Fabric",
	"clusterName": "[parameters('clusterName')]"
  }
},

Затем добавьте этот ресурс в раздел parameters сразу после определений учетной записи хранения между supportLogStorageAccountName. Замените текст заполнителя storage account name goes here именем учетной записи хранения, которую вы намерены использовать.

    "applicationDiagnosticsStorageAccountType": {
      "type": "string",
      "allowedValues": [
        "Standard_LRS",
        "Standard_GRS"
      ],
      "defaultValue": "Standard_LRS",
      "metadata": {
        "description": "Replication option for the application diagnostics storage account"
      }
    },
    "applicationDiagnosticsStorageAccountName": {
      "type": "string",
      "defaultValue": "**STORAGE ACCOUNT NAME GOES HERE**",
      "metadata": {
        "description": "Name for the storage account that contains application diagnostics data from the cluster"
      }
    },

Затем добавьте в раздел VirtualMachineProfile файла template.json следующий код в массиве extensions. Обязательно добавьте запятую в конце или в начале в зависимости от места вставки.

{
    "name": "[concat(parameters('vmNodeType0Name'),'_Microsoft.Insights.VMDiagnosticsSettings')]",
    "properties": {
        "type": "IaaSDiagnostics",
        "autoUpgradeMinorVersion": true,
        "protectedSettings": {
        "storageAccountName": "[parameters('applicationDiagnosticsStorageAccountName')]",
        "storageAccountKey": "[listKeys(resourceId('Microsoft.Storage/storageAccounts', parameters('applicationDiagnosticsStorageAccountName')),'2015-05-01-preview').key1]",
        "storageAccountEndPoint": "https://core.windows.net/"
        },
        "publisher": "Microsoft.Azure.Diagnostics",
        "settings": {
        "WadCfg": {
            "DiagnosticMonitorConfiguration": {
            "overallQuotaInMB": "50000",
            "EtwProviders": {
                "EtwEventSourceProviderConfiguration": [
                {
                    "provider": "Microsoft-ServiceFabric-Actors",
                    "scheduledTransferKeywordFilter": "1",
                    "scheduledTransferPeriod": "PT5M",
                    "DefaultEvents": {
                    "eventDestination": "ServiceFabricReliableActorEventTable"
                    }
                },
                {
                    "provider": "Microsoft-ServiceFabric-Services",
                    "scheduledTransferPeriod": "PT5M",
                    "DefaultEvents": {
                    "eventDestination": "ServiceFabricReliableServiceEventTable"
                    }
                }
                ],
                "EtwManifestProviderConfiguration": [
                {
                    "provider": "cbd93bc2-71e5-4566-b3a7-595d8eeca6e8",
                    "scheduledTransferLogLevelFilter": "Information",
                    "scheduledTransferKeywordFilter": "4611686018427387904",
                    "scheduledTransferPeriod": "PT5M",
                    "DefaultEvents": {
                    "eventDestination": "ServiceFabricSystemEventTable"
                    }
                },
                {
                    "provider": "02d06793-efeb-48c8-8f7f-09713309a810",
                    "scheduledTransferLogLevelFilter": "Information",
                    "scheduledTransferKeywordFilter": "4611686018427387904",
                    "scheduledTransferPeriod": "PT5M",
                    "DefaultEvents": {
                    "eventDestination": "ServiceFabricSystemEventTable"
                    }
                }
                ]
            }
            }
        },
        "StorageAccount": "[parameters('applicationDiagnosticsStorageAccountName')]"
        },
        "typeHandlerVersion": "1.5"
    }
}

После изменения файла template.json (как описано выше) повторно опубликуйте шаблон Resource Manager. Если шаблон экспортирован, для повторной публикации шаблона выполните файл deploy.ps1. После развертывания убедитесь, что параметр ProvisioningState имеет значение Succeeded.

Совет

Если планируется развернуть контейнеры в кластере, разрешите WAD получать статистику Docker, добавив в раздел WadCfg > DiagnosticMonitorConfiguration следующий код:

"DockerSources": {
    "Stats": {
        "enabled": true,
        "sampleRate": "PT1M"
    }
},

Изменение квоты хранилища

Это расширение постоянно увеличивает размер заполняемых таблиц, пока не будет достигнута квота хранилища. Возможно, вы захотите уменьшить эту квоту. По умолчанию квота имеет значение 50 ГБ, а изменить ее можно в шаблоне, в поле overallQuotaInMB раздела DiagnosticMonitorConfiguration.

"overallQuotaInMB": "50000",

Настройка сбора журналов

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

Операционный канал — базовые сведения (включен по умолчанию). Содержит события высокоуровневых операций, выполняемых Service Fabric и кластером, таких как открытие узла, развертывание нового приложения, откат обновления и т. д. Список поддерживаемых событий операционного канала вы найдете здесь.
```
  "scheduledTransferKeywordFilter": "4611686018427387904"
```
Операционный канал — подробные сведения. Включает отчеты о работоспособности и решения о балансировке нагрузки, а также все содержимое операционного канала базовых сведений. Эти события создаются системой или кодом через API отчетов о работоспособности и (или) нагрузке, такие как ReportPartitionHealth или ReportLoad. Чтобы просмотреть эти события в окне просмотра событий диагностики Visual Studio, добавьте Microsoft-ServiceFabric:4:0x4000000000000008 в список поставщиков трассировки событий Windows.
```
  "scheduledTransferKeywordFilter": "4611686018427387912"
```
Канал данных и обмена сообщениями — базовые сведения. Содержит критически важные журналы и события, создаваемые в системе обмена сообщениями (пока только ReverseProxy) и пути обработки данных, а также подробные журналы операционного канала. Эти события также включают сбои при обработке запросов и другие критические проблемы для ReverseProxy и обрабатываемых запросов. Мы рекомендуем использовать этот уровень для ведения подробного журнала. Чтобы просмотреть эти события в средстве просмотра диагностических событий Visual Studio, добавьте Microsoft-ServiceFabric:4:0x4000000000000010 в список поставщиков трассировки событий Windows.
```
  "scheduledTransferKeywordFilter": "4611686018427387928"
```
Канал данных и обмена сообщениями — подробные сведения. Этот канал содержит развернутую информацию из некритических журналов для процессов обработки данных и обмена сообщениями в кластере, а также все содержимое операционного канала подробных сведений. Подробные сведения об устранении любых неполадок, связанных с событиями обратного прокси-сервера, приведены в руководстве по диагностике обратного прокси-сервера. Чтобы просмотреть эти события в средстве просмотра диагностических событий Visual Studio, добавьте Microsoft-ServiceFabric:4:0x4000000000000020 в список поставщиков трассировки событий Windows.
```
  "scheduledTransferKeywordFilter": "4611686018427387944"
```

Примечание.

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

Чтобы включить рекомендуемый режим подробного ведения журналов с наименьшими помехами (Операционный канал базовых сведений), используйте следующее значение EtwManifestProviderConfiguration для WadCfg в шаблоне :

  "WadCfg": {
        "DiagnosticMonitorConfiguration": {
          "overallQuotaInMB": "50000",
          "EtwProviders": {
            "EtwEventSourceProviderConfiguration": [
              {
                "provider": "Microsoft-ServiceFabric-Actors",
                "scheduledTransferKeywordFilter": "1",
                "scheduledTransferPeriod": "PT5M",
                "DefaultEvents": {
                  "eventDestination": "ServiceFabricReliableActorEventTable"
                }
              },
              {
                "provider": "Microsoft-ServiceFabric-Services",
                "scheduledTransferPeriod": "PT5M",
                "DefaultEvents": {
                  "eventDestination": "ServiceFabricReliableServiceEventTable"
                }
              }
            ],
            "EtwManifestProviderConfiguration": [
              {
                "provider": "cbd93bc2-71e5-4566-b3a7-595d8eeca6e8",
                "scheduledTransferLogLevelFilter": "Information",
                "scheduledTransferKeywordFilter": "4611686018427387904",
                "scheduledTransferPeriod": "PT5M",
                "DefaultEvents": {
                  "eventDestination": "ServiceFabricSystemEventTable"
                }
              },
              {
                "provider": "02d06793-efeb-48c8-8f7f-09713309a810",
                "scheduledTransferLogLevelFilter": "Information",
                "scheduledTransferKeywordFilter": "4611686018427387904",
                "scheduledTransferPeriod": "PT5M",
                "DefaultEvents": {
                "eventDestination": "ServiceFabricSystemEventTable"
                }
              }
            ]
          }
        }
      },

Сбор из новых каналов EventSource

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

В раздел EtwEventSourceProviderConfiguration файла template.json нужно добавить записи для новых каналов EventSource. Это следует сделать до обновления конфигурации с помощью команды PowerShell New-AzResourceGroupDeployment. Имя источника события определяется как часть кода в файле ServiceEventSource.cs, созданном в Visual Studio.

Например, если источнику события задано имя My-Eventsource, добавьте следующий код для помещения событий из источника My-Eventsource в таблицу MyDestinationTableName.

{
  "provider": "My-Eventsource",
  "scheduledTransferPeriod": "PT5M",
  "DefaultEvents": {
    "eventDestination": "MyDestinationTableName"
  }
}

Чтобы собрать данные счетчиков производительности и журналов событий, измените шаблон Resource Manager, используя примеры в статье Создание виртуальной машины Windows с мониторингом и диагностикой с использованием шаблона Azure Resource Manager. Затем опубликуйте шаблон Resource Manager.

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

Для сбора метрик производительности из кластера добавьте счетчики производительности в элемент "WadCfg > DiagnosticMonitorConfiguration" в шаблоне Resource Manager для кластера. Дополнительные сведения о том, как изменить WadCfg, чтобы собрать данные конкретных счетчиков производительности, см. в статье Performance monitoring with Windows Azure Diagnostics extension (Мониторинг производительности с помощью расширения системы диагностики Microsoft Azure). Список счетчиков производительности Service Fabric, которые мы рекомендуем собирать, см. в статье Метрики производительности.

Если вы используете приемник Application Insights, как описано в разделе ниже, и вам нужно, чтобы эти метрики отображались в Application Insights, добавьте имя приемника в соответствующем разделе, как показано выше. Это позволит автоматически отправлять счетчики производительности, отдельно настроенные для ресурса Application Insights.

Отправка журналов в Application Insights

Настройка Application Insights с помощью WAD

Примечание.

В настоящее время это распространяется только на кластеры Windows.

Существует два основных способа отправки данных из WAD в Application Insights. Для этого нужно добавить приемник Application Insights в конфигурацию WAD через портал Azure или шаблон Azure Resource Manager.

При создании кластера на портале Azure добавьте ключ инструментирования Application Insights.

Adding an AIKey

Если при создании кластера диагностика включена, появляется дополнительное поле для ввода ключа инструментирования Application Insights. Если вставить сюда ключ Application Insights, в шаблоне Resource Manager, используемом для развертывания кластера, будет автоматически настроен приемник Application Insights.

Добавление приемника Application Insights в шаблон Resource Manager

В разделе WadCfg шаблона Resource Manager добавьте приемник, внеся два указанных ниже изменения.

Добавьте конфигурацию приемника сразу после объявления DiagnosticMonitorConfiguration:

"SinksConfig": {
    "Sink": [
        {
            "name": "applicationInsights",
            "ApplicationInsights": "***ADD INSTRUMENTATION KEY HERE***"
        }
    ]
}

Включите приемник в DiagnosticMonitorConfiguration, добавив следующую строку в DiagnosticMonitorConfigurationWadCfg (сразу перед объявлением EtwProviders):
```
"sinks": "applicationInsights"
```

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

Сейчас журналы кластера отображаются в средстве просмотра журналов Application Insights как трассировки. Так как большинство трассировок, поступающих от платформы, имеют уровень "Информационный", вы можете изменить конфигурацию приемника так, чтобы отправлялись журналы только типов "Предупреждение" или "Ошибка". Для этого в приемник можно добавить каналы, как показано в этой статье.

Примечание.

Если вы укажете на портале или в шаблоне Resource Manager неправильный ключ Application Insights, придется вручную заменить его, а затем обновить или повторно развернуть кластер.

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

Если вы правильно настроили диагностику Azure, данные из журнала трассировки событий Windows и журнала EventSource станут появляться в таблице хранилища. При использовании журналов Azure Monitor, Kibana или любой другой платформы для аналитики и визуализации, которая не настроена в шаблоне Resource Manager явным образом, убедитесь, что выбранная платформа настроена для чтения данных из таблиц хранилища. Сделать это для журналов Azure Monitor несложно. Дополнительные сведения см. в статье об анализе событий и журналов. В этом смысле Application Insights — это особый случай, так как это решение можно настроить при настройке расширения диагностики. Дополнительные сведения об Application Insights см. в этой статье.

Примечание.

Сегодня не существует способа фильтрации или очистки событий, которые отправляются в таблицу. Если не реализовать метод удаления событий из таблицы, она продолжит расти. Сейчас есть пример службы очистки данных, выполняющийся в примере модуля наблюдения. Мы также советуем написать собственный пример, если у вас нет веских причин для хранения журналов дольше 30 или 90 дней.

Узнайте, как собирать данные счетчиков производительности или журналы, используя расширения системы диагностики.
Event Analysis and Visualization with Application Insights (Анализ событий и визуализация с помощью Application Insights)
Анализ и визуализация событий с помощью журналов Azure Monitor
Event Analysis and Visualization with Application Insights (Анализ событий и визуализация с помощью Application Insights)
Анализ и визуализация событий с помощью журналов Azure Monitor

Агрегирование и сбор событий с помощью Диагностики Azure для Windows

Необходимые компоненты

События платформы Service Fabric

Развертывание расширения системы диагностики с помощью портала

Развертывание расширения системы диагностики в ходе создания кластера с помощью портала Azure

Развертывание расширения системы диагностики с помощью Azure Resource Manager

Создание кластера с расширением системы диагностики

Добавление расширения системы диагностики к существующему кластеру

Изменение квоты хранилища

Настройка сбора журналов

Сбор из новых каналов EventSource

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

Отправка журналов в Application Insights

Настройка Application Insights с помощью WAD

При создании кластера на портале Azure добавьте ключ инструментирования Application Insights.

Добавление приемника Application Insights в шаблон Resource Manager

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

Дополнительные ресурсы