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

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

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

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

Примечание.

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

Предупреждение

Application Insights для пакета SDK Service Fabric больше не поддерживается.

Предпосылки

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

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

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

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

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

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

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

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

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

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

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

Примечание.

В настоящее время нет способа фильтрации или очистки событий, отправляемых в таблицы. Если вы не реализуете процесс удаления событий из таблицы, таблица продолжает расти (ограничение по умолчанию — 50 ГБ). Вы можете изменить это ограничение, используя инструкции, приведенные ниже в этой статье. Кроме того, есть пример службы очистки данных, работающей в примере Watchdog, и рекомендуется написать один для себя, если нет хорошей причины для хранения журналов за пределами 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')]"
  }
},

Затем добавьте в раздел параметров сразу после определений учетной записи хранения между 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" в список поставщиков ETW.

      "scheduledTransferKeywordFilter": "4611686018427387912"

  • Канал данных и обмена сообщениями — основа: критически важные журналы и события, создаваемые в канале обмена сообщениями (в настоящее время только ReverseProxy) и в канале данных, а также подробные журналы операционного канала. Эти события включают сбои при обработке запросов и другие критические проблемы в ReverseProxy, а также обработанные запросы. Это наша рекомендация для ведения подробного журнала. Чтобы просмотреть эти события в средстве просмотра диагностических событий Visual Studio, добавьте "Microsoft-ServiceFabric:4:0x4000000000000010" в список поставщиков ETW.

      "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 (Мониторинг производительности с помощью расширения системы диагностики Microsoft Azure). См. метрики производительности для списка счетчиков производительности, которые мы рекомендуем собирать.

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

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

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

Предупреждение

Application Insights для пакета SDK Service Fabric больше не поддерживается.

Существует два основных способа отправки данных из 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 добавьте элемент "Sink", внесите следующие два изменения.

  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, вы увидите данные из журналов ETW и EventSource в таблицах хранилища. При использовании журналов Azure Monitor, Kibana или любой другой платформы для аналитики и визуализации, которая не настроена в шаблоне Resource Manager явным образом, убедитесь, что выбранная платформа настроена для чтения данных из таблиц хранилища. Сделать это для журналов Azure Monitor несложно. Дополнительные сведения см. в статье об анализе событий и журналов. В этом смысле Application Insights — это особый случай, так как его можно настроить в рамках конфигурации расширения диагностики, поэтому, если вы решите использовать AI, обратитесь к соответствующей статье.

Примечание.

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

  • Last updated on