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

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

  • Статья

Во время работы кластера 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. Расширение системы диагностики собирает журналы на каждой виртуальной машине и отправляет их в указанную учетную запись хранения. Ниже описано, как настроить это для новых и существующих кластеров с помощью портала Azure и шаблонов Azure Resource Manager.

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

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

Параметры системы диагностики Azure на портале для создания кластера

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

Шаблон кластера

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

Примечание.

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

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

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

Чтобы создать кластер с помощью Resource Manager, добавьте код JSON с конфигурацией системы диагностики в полный шаблон Resource Manager. Мы предоставляем шаблон Resource Manager для кластера с пятью виртуальными машинами с конфигурацией диагностики, добавленной в него в рамках примеров шаблонов 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). Ссылки на метрики производительности для списка счетчиков производительности, которые мы рекомендуем собирать.

Если вы используете приемник 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.

Добавление AIKey

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

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

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

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

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

  2. Включите приемник в 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 дней.