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

  • Статья

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

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

Ниже перечислены компоненты.

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

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

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

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

Артефакт Путь
Файл конфигурации системы диагностики 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 — это имя метрики. Оно также называется именем счетчика производительности.

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

Если нет данных для конкретной метрики, необходимо проверить, включена ли метрика (счетчик производительности). Для этого выберите 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 и т. д.). Команда Listen учитывает регистр, и между разделенным запятыми списком поставщиков трассировки событий Windows не может быть пробелов. Если выполнить команду не удается, выберите Log (Журнал ) в правом нижнем углу средства PerfView, чтобы узнать, что пыталось выполнить, и результат. Если входные данные верны, откроется новое окно. Через несколько секунд вы увидите трассировки трассировки событий Windows.
  • Журналы трассировки. Удаленно подключитесь к виртуальной машине. Откройте Просмотр событий и убедитесь, что события существуют.

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

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

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

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

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

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

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

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

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

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

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

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

        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 коды выхода подключаемого модуля

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

Код выхода Описание
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 , убедитесь, что DiagnosticMonitorTraceListener находится в app.config. По умолчанию он находится в web.config, но применяется только к коду, выполняемму в w3wp.exe. Поэтому он понадобится в app.config для записи трассировок, выполняющихся в WaIISHost.exe.
  • Убедитесь, что вы используете Diagnostics.Trace.TraceXXX вместо Diagnostics.Debug.WriteXXX. Инструкции Debug удаляются из сборки выпуска.
  • Убедитесь, что скомпилированный код действительно содержит строки Diagnostics.Trace. Для проверки используйте Reflector, 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.