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

Устранение неполадок с помощью Диагностики Azure

  • Статья

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

Логические компоненты

Компоненты:

  • Средство запуска подключаемого модуля диагностики (DiagnosticsPluginLauncher.exe): запускает расширение диагностики. Он служит процессом точки входа.
  • Подключаемый модуль диагностики (DiagnosticsPlugin.exe): настраивает, запускает и управляет временем существования агента мониторинга. Это основной процесс, запущенный средством запуска.
  • Агент мониторинга (процессы MonAgent*.exe). Отслеживает, собирает и передает данные диагностики.

Пути к журналам и артефактам

Следующие пути приводят к некоторым важным журналам и артефактам. Мы ссылаемся на эту информацию в этой статье.

Oблачныe службы Azure2

Артефакт Путь
Файл конфигурации системы диагностики Azure %SystemDrive%\Packages\Plugins\Microsoft.Azure.Diagnostics.PaaSDiagnostics<version>\Config.txt
Файлы журналов C:\Logs\Plugins\Microsoft.Azure.Diagnostics.PaaSDiagnostics<version>\
Локальное хранилище данных диагностики C:\Resources\Directory<CloudServiceDeploymentID>.<RoleName>.DiagnosticStore\WAD0107\Tables
Файл конфигурации агента мониторинга C:\Resources\Directory<CloudServiceDeploymentID>.<RoleName>.DiagnosticStore\WAD0107\Configuration\MaConfig.xml
Пакет расширений системы диагностики Azure %SystemDrive%\Packages\Plugins\Microsoft.Azure.Diagnostics.PaaSDiagnostics<version>
Путь к служебной программе сбора журналов %SystemDrive%\Packages\GuestAgent\
Файл журнала MonAgentHost C:\Resources\Directory<CloudServiceDeploymentID>.<RoleName>.DiagnosticStore\WAD0107\Configuration\MonAgentHost.<seq_num>.log

Виртуальные машины

Артефакт Путь
Файл конфигурации системы диагностики Azure C:\Packages\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics<version>\RuntimeSettings
Файлы журналов C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics<DiagnosticsVersion>\
Локальное хранилище данных диагностики C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics<DiagnosticsVersion>\WAD0107\Tables
Файл конфигурации агента мониторинга C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics<DiagnosticsVersion>\WAD0107\Configuration\MaConfig.xml
Состояние файла C:\Packages\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics<version>\Status
Пакет расширений системы диагностики Azure C:\Packages\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics<DiagnosticsVersion>
Путь к служебной программе сбора журналов C:\WindowsAzure\Logs\WaAppAgent.log
Файл журнала MonAgentHost C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics<DiagnosticsVersion>\WAD0107\Configuration\MonAgentHost.<seq_num>.log

Данные метрик не отображаются на портале Azure

Диагностика предоставляет данные метрик, которые можно отобразить в портал Azure. Если у вас возникли проблемы с отображением данных на портале, проверьте WADMetrics\* таблицу в учетной записи хранения диагностики, чтобы узнать, есть ли соответствующие записи метрик и убедитесь, что поставщик ресурсов Microsoft.Insights зарегистрирован.

PartitionKey Здесь таблица представляет собой идентификатор ресурса, виртуальную машину или масштабируемый набор виртуальных машин. RowKey — имя метрики. Оно также называется именем счетчика производительности.

Если идентификатор ресурса неверный, проверьте идентификатор ресурса метрики конфигурации диагностики>>, чтобы проверить правильность установки идентификатора ресурса.

Если нет данных для конкретной метрики, необходимо проверить, включена ли метрика (счетчик производительности). Для этого выберите Diagnostics Configuration (Конфигурация диагностики) >PerformanceCounter. Следующие счетчики включены по умолчанию.

  • \Процессор(_общий объем ресурсов)% загруженности процессора
  • \Память\доступные байты
  • \ASP.NET Applications(Total)\Requests/Sec
  • \ASP.NET Applications(Total)\Errors Total/Sec
  • \ASP.NET\Requests Queued
  • \ASP.NET\Requests Rejected
  • \Processor(w3wp)% Processor Time
  • \Process(w3wp)\Private Bytes
  • \Process(WaIISHost)% Processor Time
  • \Process(WaIISHost)\Private Bytes
  • \Process(WaWorkerHost)% Processor Time
  • \Process(WaWorkerHost)\Private Bytes
  • \Memory\Page Faults/sec
  • .NET CLR Memory(Global)% Time in GC
  • \LogicalDisk(C:)\Disk Write Bytes/sec
  • \LogicalDisk(C:)\Disk Read Bytes/sec
  • \LogicalDisk(D:)\Disk Write Bytes/sec
  • \LogicalDisk(D:)\Disk Read Bytes/sec

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

Диагностика Azure не запускается

Сведения о том, почему не удалось запустить диагностику, см . в файлах DiagnosticsPluginLauncher.log и DiagnosticsPlugin.log в расположении файлов журнала, предоставленном ранее.

Если эти журналы указывают Monitoring Agent not reporting success after launch, это означает, что произошел сбой запуска MonAgentHost.exe. Просмотрите журналы в расположении, указанном для MonAgentHost файла журнала в предыдущем разделе "Виртуальные машины".

В последней строке файлов журнала указан код выхода.

DiagnosticsPluginLauncher.exe Information: 0 : [4/16/2016 6:24:15 AM] DiagnosticPlugin exited with code 0

Если вы нашли отрицательный код выхода, см. таблицу кода выхода в разделе "Ссылки".

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

Определите, не отображаются ли данные или какие-либо данные отображаются.

Журналы инфраструктуры диагностики

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

Данные не отображаются

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

Решение. Исправьте файл конфигурации системы диагностики и переустановите систему диагностики.

Если учетная запись хранения настроена правильно, удаленно подключитесь к компьютеру и проверьте, выполняются ли процессы DiagnosticsPlugin.exe и MonAgentCore.exe. Если они не выполняются, выполните действия, описанные в Диагностика Azure, не запускаются.

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

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

  1. Удалите агент.
  2. Удалите каталог C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics.
  3. Снова установите агент.

Отсутствует часть данных

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

Настроен ли сбор?

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

Создает ли узел данные?

  • Счетчики производительности: откройте perfmon и проверьте счетчик.
  • Журналы трассировки: удаленный доступ к виртуальной машине и добавление TextWriterTraceListener в файл конфигурации приложения. Сведения о настройке прослушивателя текста см. в разделе "Создание и инициализация прослушивателей трассировки". Проверьте, имеет ли элемент <trace> значение <trace autoflush="true">. Если журналы трассировки не создаются, см. в разделе "Дополнительные сведения о отсутствующих журналах трассировки".
  • Трассировки событий для Windows (ETW): удаленный доступ к виртуальной машине и установка средства PerfView. Откройте средство PerfView и выберите File (Файл) >User Command (Пользовательская команда) >Ожидать передачи данных>etwprovider2, указав при этом необходимых поставщиков ETW (etwprovder1, etwprovider2 и т. д.). Команда прослушивания учитывает регистр, и между разделенным запятыми списка поставщиков ETW не может быть пробелов. Если команда не удается выполнить, выберите "Журнал " в правом нижнем углу средства PerfView, чтобы увидеть, что пытался выполнить и что это было результатом. Если входные данные правильны, откроется новое окно. Через несколько секунд вы увидите трассировки ETW.
  • Журналы трассировки. Удаленно подключитесь к виртуальной машине. Откройте Просмотр событий и убедитесь, что события существуют.

Сохраняются ли данные локально?

Проверьте, сохраняются ли данные локально. Данные хранятся локально в файлах *.tsf в локальном хранилище для диагностика данных. Различные типы журналов собираются в разных TSF-файлах. Их имена напоминают имена таблиц в службе хранилища Azure.

Например, счетчики производительности собираются в PerformanceCountersTable.tsf. Журналы событий собираются в WindowsEventLogsTable.tsf. Откройте локальный набор файлов, используя указания в разделе Извлечение локального журнала, и проверьте, записываются ли они на диск.

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

Кроме того, просмотрите конфигурацию, созданную для MaConfig.xml MonitoringAgent. Убедитесь, что есть раздел, описывающий соответствующий источник журнала. Затем убедитесь, что он не потерян в переводе между конфигурацией диагностики и конфигурацией агента мониторинга.

Передаются ли данные?

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

  • Убедитесь, что вы предоставили правильную учетную запись хранения и не перевернули ключи для данной учетной записи хранения. Для Azure Облачные службы иногда пользователи не обновляютсяuseDevelopmentStorage=true.
  • Проверьте правильность указанной учетной записи хранения. Убедитесь, что у вас нет ограничений сети, запрещающих компонентам доступ к конечным точкам общедоступного хранилища. Один из способов сделать это заключается в удаленном доступе к компьютеру и попытаться записать что-то в ту же учетную запись хранения самостоятельно.
  • Наконец, вы можете посмотреть, какие ошибки сообщаются агентом мониторинга. Агент мониторинга записывает журналы в maeventtable.tsf, который находится в локальном хранилище для диагностика данных. Следуйте инструкциям в разделе извлечения локальных журналов, чтобы открыть этот файл. Попытайтесь определить наличие errors, указывающих на сбои при чтении в локальных файлах и записи в хранилище.

Сбор и архивирование журналов

Если вы думаете об обращении в службу поддержки, первое, что они могут попросить вас собрать журналы с компьютера. Вы можете сэкономить время, сделав это самостоятельно. Запустите служебную CollectGuestLogs.exe программу в пути к сбору журналов. В той же папке она создаст ZIP-файл со всеми соответствующими журналами Azure.

Таблицы данных диагностики не найдены

Таблицы в служба хранилища Azure, в которых хранятся события ETW, именуются с помощью следующего кода:

        if (String.IsNullOrEmpty(eventDestination)) {
            if (e == "DefaultEvents")
                tableName = "WADDefault" + MD5(provider);
            else
                tableName = "WADEvent" + MD5(provider) + eventId;
        }
        else
            tableName = "WAD" + eventDestination;

Приведем пример:

        <EtwEventSourceProviderConfiguration provider="prov1">
          <Event id="1" />
          <Event id="2" eventDestination="dest1" />
          <DefaultEvents />
        </EtwEventSourceProviderConfiguration>
        <EtwEventSourceProviderConfiguration provider="prov2">
          <DefaultEvents eventDestination="dest2" />
        </EtwEventSourceProviderConfiguration>

"EtwEventSourceProviderConfiguration": [
    {
        "provider": "prov1",
        "Event": [
            {
                "id": 1
            },
            {
                "id": 2,
                "eventDestination": "dest1"
            }
        ],
        "DefaultEvents": {
            "eventDestination": "DefaultEventDestination",
            "sinks": ""
        }
    },
    {
        "provider": "prov2",
        "DefaultEvents": {
            "eventDestination": "dest2"
        }
    }
]

Этот код создает четыре таблицы:

Мероприятие Имя таблицы
provider="prov1" <Event id="1" /> WADEvent+MD5("prov1")+"1"
provider="prov1" <Event id="2" eventDestination="dest1" /> WADdest1
provider="prov1" <DefaultEvents /> WADDefault+MD5("prov1")
provider="prov2" <DefaultEvents eventDestination="dest2" /> WADdest2

Ссылки

Ознакомьтесь со следующими ссылками

Проверка конфигурации расширения диагностики

Самый простой способ проверить конфигурацию расширения — перейти в Обозреватель ресурсов Azure. Затем перейдите к виртуальной машине или облачной службе, где находится расширение диагностики (IaaSDiagnostics / PaaDiagnostics).

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

В любом случае найдите поле Microsoft.Azure.Diagnostics и xmlCfg или WadCfg.

Если поиск выполняется на виртуальной машине и вы видите поле WadCfg, это означает, что файл конфигурации имеет формат JSON. Если поле xmlCfg присутствует, это означает, что конфигурация находится в ФОРМАТЕ XML и закодирована в кодировке Base64. Его необходимо декодировать, чтобы увидеть XML-файл, который был загружен системой диагностики.

Для роли облачной службы, если выбрать конфигурацию на диске, данные закодированы в кодировке Base64. Необходимо декодировать его , чтобы увидеть XML-файл, загруженный диагностикой.

коды выхода Диагностика Azure подключаемых модулей

Подключаемый модуль возвращает следующие коды выхода:

Код выхода Description
0 Успех.
-1 Общая ошибка.
-2 Невозможно загрузить RCF-файл.

Эта внутренняя ошибка должна возникать только в том случае, если средство запуска подключаемого модуля гостевого агента вручную вызывается неправильно на виртуальной машине.
-3 Не удается загрузить файл конфигурации диагностики.

Решение. Это вызвано тем, что файл конфигурации не прошел проверку схемы. Следует предоставить файл конфигурации, соответствующий схеме.
-4 Другой экземпляр системы диагностики агента мониторинга уже использует локальный каталог ресурсов.

Решение. Укажите другое значение для LocalResourceDirectory.
-6 Средство запуска подключаемого модуля гостевого агента попыталось запустить диагностику с недопустимой командной строкой.

Эта внутренняя ошибка должна возникать только в том случае, если средство запуска подключаемого модуля гостевого агента вручную вызывается неправильно на виртуальной машине.
-10 Подключаемый модуль диагностики завершился с необработанным исключением.
-11 Гостевому агенту не удалось создать процесс, ответственный за запуск и мониторинг агента мониторинга.

Решение. Убедитесь, что доступных системных ресурсов достаточно для запуска новых процессов.
–101 Недопустимые аргументы при вызове подключаемого модуля диагностики.

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

Решение. Убедитесь, что доступных системных ресурсов достаточно для запуска новых процессов.
103 Процесс подключаемого модуля не может инициализировать себя. В частности, не удается создать объект средства ведения журнала.

Решение. Убедитесь, что доступных системных ресурсов достаточно для запуска новых процессов.
104 Не удалось загрузить RCF-файл, предоставленный гостевым агентом.

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

Эта внутренняя ошибка должна возникать только в том случае, если подключаемый модуль диагностики вызывается неправильно на виртуальной машине.
–106 Не удается прочитать файл конфигурации диагностики.

Это вызвано тем, что файл конфигурации не прошел проверку схемы.

Решение. Следует предоставить файл конфигурации, соответствующий схеме. Дополнительные сведения см. в разделе "Проверка конфигурации расширения диагностики".
-107 Недопустимая передача каталога ресурсов в агент мониторинга.

Эта внутренняя ошибка может возникать, только если агент мониторинга вызван вручную, неправильно и на виртуальной машине.
-108 Не удалось преобразовать файл конфигурации системы диагностики в файл конфигурации агента мониторинга.

Эта внутренняя ошибка должна возникать только в том случае, если подключаемый модуль диагностики вызывается вручную с недопустимым файлом конфигурации.
-110 Общая ошибка конфигурации системы диагностики.

Эта внутренняя ошибка должна возникать только в том случае, если подключаемый модуль диагностики вызывается вручную с недопустимым файлом конфигурации.
-111 Не удалось запустить агент мониторинга.

Решение. Убедитесь, что доступен достаточный объем системных ресурсов.
-112 Общая ошибка.

Извлечение локального журнала

Агент мониторинга сохраняет данные журналов и артефактов как файлы с расширением .tsf. Файл .tsf недоступен для чтения, но его можно преобразовать в следующее .csv :

<Azure diagnostics extension package>\Monitor\x64\table2csv.exe <relevantLogFile>.tsf

После этого создается файл <relevantLogFile>.csv в том же расположении, что и соответствующий файл TSF (.tsf).

Примечание.

Эту программу необходимо запустить только для основного .tsf файла (например, PerformanceCountersTable.tsf). Сопровождающие файлы (например, PerformanceCountersTables_\*\*001.tsf) PerformanceCountersTables_\*\*002.tsfобрабатываются автоматически.

Дополнительные сведения об отсутствии журналов трассировки

Примечание.

Следующие сведения применяются в основном к Azure Облачные службы, если вы не настроили DiagnosticsMonitorTraceListener приложение, работающее на виртуальной машине IaaS.

  • Убедитесь, что средство DiagnosticMonitorTraceListener настроено в файле web.config или app.config. Он настраивается по умолчанию в проектах облачной службы. Однако некоторые клиенты комментируют его, что приводит к тому, что инструкции трассировки не собираются диагностикой.
  • Если журналы не записываются из метода OnStart или Run , убедитесь, что журналы не записываются в файл app.config. По умолчанию он находится в файле web.config, но применяется только к коду, работающему в w3wp.exe. Поэтому для записи трассировок, выполняемых в WaIISHost.exe, требуется в app.config.
  • Убедитесь, что вы используете diagnostics.Trace.TraceXXXX вместо Diagnostics.Debug.WriteXXXX. Инструкции отладки удаляются из сборки выпуска.
  • Убедитесь, что скомпилированный код фактически содержит строки Diagnostics.Trace. Используйте Отражатель, ildasm или ILSpy для проверки. Команды Diagnostics.Trace удаляются из скомпилированного двоичного файла, если не используется символ условной компиляции трассировки. Эта распространенная проблема возникает при использовании MSBuild для создания проекта.

Известные проблемы и устранения рисков

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

Зависимость .NET 4.5

Расширение Диагностика Azure для Windows зависит от платформа .NET Framework 4.5 или более поздней версии. На момент написания записи все компьютеры, подготовленные для Azure Облачные службы, и все официальные образы, основанные на виртуальных машинах Azure, установили .NET 4.5 или более поздней версии.

По-прежнему можно столкнуться с ситуацией, когда вы пытаетесь запустить расширение Диагностика Azure для Windows на компьютере, который не имеет .NET 4.5 или более поздней версии. Эта ситуация возникает при создании компьютера на основе старого образа или моментального снимка или при переносе собственного пользовательского диска.

Эта проблема обычно манифестирует как код выхода 255 при запуске DiagnosticsPluginLauncher.exe. Сбой происходит из-за следующего необработанного исключения:

System.IO.FileLoadException: Could not load file or assembly 'System.Threading.Tasks, Version=1.5.11.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies

Устранение. Установите на виртуальной машине платформу .NET версии 4.5 или более поздней.

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

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

  • Указаны ли имена счетчиков в хранилище на английском. Если имена счетчиков не заданы на английском языке, диаграмма метрик портала не распознает ее.

    • Предотвращение. Изменить язык системных учетных записей виртуальной машины на английский. Для этого выберите Панель управления>Регион>Административный>Настройка копирования. Затем снимите экран приветствия и системные учетные записи, чтобы пользовательский язык не применялся к системной учетной записи.

  • Если вы используете подстановочные знаки (*) в именах счетчиков производительности, портал не может сопоставить настроенный и собранный счетчик при отправке счетчиков производительности в приемник служба хранилища Azure.

    • Устранение рисков. Чтобы вы могли использовать подстановочные знаки, а портал разворачивал узел (*), перенаправьте данные счетчиков производительности в приемник Azure Monitor.