Комплексное устранение неполадок с помощью метрик службы хранилища Azure и ведения журнала, AzCopy и Анализатора сообщений

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

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

В этом руководстве приводятся практические сведения о комплексном сценарии устранения неполадок. Подробное концептуальное руководство по устранению неполадок с приложениями хранилища Azure см. в статье Наблюдение, диагностика и устранение неполадокMicrosoft Azure Storage.

Средства устранения неполадок с приложениями службы хранилища Azure

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

• Аналитика службы хранилища Azure. Аналитика службы хранилища Azure предоставляет метрики и ведение журнала для службы хранилища Azure.

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

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

  Для получения сведений о том, как настроить мониторинг на портале Azure, см. раздел Мониторинг учетной записи хранения на портале Azure.

• AzCopy. Журналы сервера для службы хранилища Azure хранятся в виде больших двоичных объектов, поэтому с помощью AzCopy можно скопировать большие двоичные объекты журнала в локальный каталог для анализа с помощью Анализатора сообщений Майкрософт. Для получения дополнительной информации об AzCopy см. раздел Передача данных с помощью утилиты AzCopy Command-Line.

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

Пример сценария

В этом руководстве мы рассмотрим сценарий, в котором метрики службы хранилища Azure указывают на низкую процентную скорость успешного выполнения для приложения, вызывающего службу хранилища Azure. Метрика низкого уровня успешности (показанная как PercentSuccess на портале Azure портале Azure и в таблицах метрик) отслеживает операции, которые выполняются успешно, но возвращают код состояния HTTP, превышающий 299. В файлах журнала хранилища на стороне сервера эти операции записываются с состоянием транзакции ClientOtherErrors. Дополнительные сведения о метрике низкого процента успешности см. в разделе . Метрики показывают низкий процент успешности, или записи журнала аналитики содержат операции с состоянием транзакции ClientOtherErrors.

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

В этом сценарии мы будем считать низким процент успешности всё, что ниже 100%. Вы можете выбрать другой уровень метрик, однако в соответствии с вашими потребностями. Во время тестирования приложения рекомендуется установить базовый уровень допустимости для ключевых метрик производительности. Например, вы можете определить на основе тестирования, что приложение должно иметь стабильный процент успешности 90%или 85%. Если данные метрик показывают, что приложение отличается от этого числа, можно изучить, что может привести к увеличению.

В нашем примере сценария, когда мы установили, что метрика процента успеха ниже 100%, мы рассмотрим журналы, чтобы найти ошибки, которые коррелируют с метриками, и использовать их, чтобы выяснить, что вызывает более низкий процент успешности. Мы конкретно рассмотрим ошибки в диапазоне 400. Затем мы более подробно рассмотрим ошибки 404 (не найдено).

Некоторые причины ошибок диапазона 400

В приведенных ниже примерах показана выборка около 400-диапазонных ошибок для запросов к хранилищу BLOB-объектов Azure и их возможных причин. Любые из этих ошибок, а также ошибки в диапазоне 300 и диапазоне 500 могут способствовать низкому проценту успеха.

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

Примеры кода состояния 404 (не найдено)

Возникает, когда операция чтения для контейнера или блоба завершается неудачно, поскольку блоб или контейнер не найден.

• Происходит, если контейнер или объект был удалён другим клиентом перед этим запросом.
• Происходит при использовании вызова API, который создает контейнер или блоб после проверки его существования. API CreateIfNotExists сначала делают вызов HEAD, чтобы проверить наличие контейнера или большого двоичного объекта; Если он не существует, возвращается ошибка 404, а второй вызов PUT выполняется для записи контейнера или большого двоичного объекта.

Примеры кода состояния 409 (конфликт)

• Возникает, если вы используете API Create для создания нового контейнера или большого двоичного объекта, не проверяя наличие, а контейнер или большой двоичный объект с этим именем уже существует.
• Возникает, если контейнер удаляется, и вы пытаетесь создать контейнер с тем же именем до завершения операции удаления.
• Происходит, если вы указываете назначение аренды на контейнер или блоб, и аренда уже присутствует.

Примеры кода состояния 412 (сбой предварительных условий)

• Происходит, когда условие, указанное условным заголовком, не выполнено.
• Происходит, когда указанный идентификатор аренды не соответствует идентификатору аренды контейнера или блоба.

Создание файлов журнала для анализа

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

• Журнал сервера, который создается при включении ведения журнала Azure Storage. Журнал сервера содержит данные о каждой операции, вызываемой для одной из служб Azure Storage — BLOB, очередей, таблиц и файлов. Журнал сервера указывает, какая операция была вызвана и какой код состояния был возвращен, а также другие сведения о запросе и ответе.
• журнал клиента .NET, который создается при включении ведения журнала на стороне клиента из приложения .NET. Журнал клиента содержит подробные сведения о том, как клиент подготавливает запрос и получает и обрабатывает ответ.
• журнал трассировки сети HTTP, который собирает данные о HTTP/HTTPS-запросах и ответах, включая операции с хранилищем Azure. В этом руководстве мы создадим сетевую трассировку с помощью анализатора сообщений.

Настройка ведения журнала на стороне сервера и метрик

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

Настройка ведения журнала на стороне клиента .NET

Чтобы настроить ведение журнала на стороне клиента для приложения .NET, включите диагностику .NET в файле конфигурации приложения (web.config или app.config). Дополнительные сведения см. в разделе про клиентское ведение журнала с помощью клиентской библиотеки хранилищ .NET и с использованием SDK Microsoft Azure Storage для Java на сайте MSDN.

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

Клиентская библиотека хранилища хранит данные журнала на стороне клиента в расположении, указанном в файле конфигурации приложения (web.config или app.config).

Сбор трассировки сети

Анализатор сообщений можно использовать для сбора трассировки сети HTTP/HTTPS во время работы клиентского приложения. Анализатор сообщений использует Fiddler в фоновом режиме. Перед сбором трассировки сети рекомендуется настроить Fiddler для записи незашифрованного трафика HTTPS:

1. Установите Fiddler.
2. Запустите Fiddler.
3. Выберите Инструменты | Параметры Fiddler.
4. В диалоговом окне "Параметры" убедитесь, что выбраны как Перехват HTTPS CONNECTs, так и Расшифровка HTTPS-трафика, как показано ниже.

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

1. В анализаторе сообщений выберите Файл | Быстрая трассировка | Незашифрованный HTTPS.

2. Трассировка начнется немедленно. Выберите Остановить, чтобы прервать трассировку и настроить её для отслеживания только трафика хранилища.

3. Выберите Редактировать, чтобы редактировать сеанс трассировки.

4. Выберите ссылку Настройка справа от поставщика Microsoft-Pef-WebProxy ETW.

5. В диалоговом окне Дополнительные параметры щелкните вкладку Поставщик.

6. В поле фильтра имени узла укажите конечные точки хранилища, разделенные пробелами. Например, можно указать конечные точки следующим образом. измените storagesample на имя учетной записи хранения:

   storagesample.blob.core.windows.net storagesample.queue.core.windows.net storagesample.table.core.windows.net

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

Дополнительные сведения см. в использовании функций трассировки сети в Technet.

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

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

Сначала перейдите к учетной записи хранения на портале Azure. По умолчанию на панели учетной записи отображается диаграмма мониторинга с метрикой «процент успешности». Если вы ранее изменили диаграмму для отображения различных метрик, добавьте метрику процент успеха.

Теперь вы увидите процент успеха на диаграмме мониторинга, а также все другие метрики, которые вы могли добавить. В следующем сценарии мы будем исследовать журналы в Анализаторе сообщений, процент успешности немного ниже 100%.

Дополнительные сведения о добавлении и настройке диаграмм метрик см. в разделе Настройка диаграмм метрик.

Использование AzCopy для копирования журналов сервера в локальный каталог

Служба хранилища Azure записывает данные журнала сервера в объекты BLOB, а метрики — в таблицы. Лог-файлы блобов доступны в известном контейнере $logs для вашей учетной записи хранения. Журнальные блобы структурированы иерархически по годам, месяцам, дням и часам, чтобы можно было легко найти временной диапазон, который вы хотите проанализировать. Например, в учетной записи storagesample контейнер для журнальных BLOB-объектов за 01.02.2015 с 8 до 9 утра - это https://storagesample.blob.core.windows.net/$logs/blob/2015/01/08/0800. Отдельные блобы в этом контейнере именуются последовательно, начиная с 000000.log.

С помощью средства командной строки AzCopy можно скачать эти файлы журналов на стороне сервера в выбранное расположение на локальном компьютере. Например, с помощью следующей команды можно скачать лог-файлы операций BLOB, которые произошли 2 января 2015 года, в папку C:\Temp\Logs\Server; замените <storageaccountname> на имя вашей учетной записи хранения.

azcopy copy 'http://<storageaccountname>.blob.core.windows.net/$logs/blob/2015/01/02' 'C:\Temp\Logs\Server'  --recursive

AzCopy доступен для скачивания на странице загрузок Azure . Дополнительные сведения об использовании AzCopy см. в разделе Передачи данных с помощью служебной программы AzCopy Command-Line.

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

Анализ данных журнала с помощью анализатора сообщений Майкрософт

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

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

Скачивание и установка анализатора сообщений и ресурсов службы хранилища Azure

1. Загрузите анализатор сообщений .
2. Запустите анализатор сообщений.
3. В меню инструментов выберите Asset Manager. В диалоговом окне диспетчера активов выберите Загрузки, а затем отфильтруйте по Azure Хранилище. Вы увидите ресурсы службы хранилища Azure, как показано на рисунке ниже.
4. Щелкните Синхронизировать все отображаемые элементы, чтобы выполнить установку объектов хранилища Azure. Доступные ресурсы:
   • правила цвета службы хранилища Azure: правила цвета службы хранилища Azure позволяют определять специальные фильтры, использующие цвета, текст и стили шрифтов для выделения сообщений, содержащих определенные сведения в трассировке.
   • Azure Storage диаграммы: диаграммы Azure Storage — это предопределенные диаграммы, которые отображают данные журнала сервера. Обратите внимание, что в настоящее время, чтобы использовать диаграммы хранилища Azure, можно загрузить только журнал сервера в Analysis Grid.
   • Парсеры Azure Storage: Парсеры Azure Storage анализируют клиентские, серверные и HTTP-журналы службы хранилища Azure, чтобы отобразить их в сетке анализа.
   • фильтры службы хранилища Azure: фильтры службы хранилища Azure являются предопределенными критериями, которые можно использовать для запроса данных в сетке анализа.
   • макеты представления Azure Storage: макеты представления и группировки столбцов в сетке анализа по умолчанию.
5. Перезапустите Анализатор сообщений после установки ресурсов.

Импорт файлов журнала в анализатор сообщений

Вы можете импортировать все сохраненные файлы журнала (серверные, клиентские и сетевые) в один сеанс в анализаторе сообщений Майкрософт для анализа.

1. В меню файла в Анализаторе сообщений Майкрософт щелкните Новый сеанс, а затем щелкните Пустой сеанс. В диалоговом окне "Новый сеанс" введите имя сеанса анализа. В панели сведений о сеансе нажмите кнопку "Файлы".
2. Чтобы загрузить данные трассировки сети, созданные анализатором сообщений, щелкните Добавить файлы, перейдите к расположению, где сохранен файл MATP из сеанса веб-трассировки, выберите matp-файл и щелкните Открыть.
3. Чтобы загрузить данные журнала на стороне сервера, щелкните Добавить файлы, перейдите в расположение, в котором вы скачали журналы на стороне сервера, выберите файлы журнала для диапазона времени, который требуется проанализировать, и щелкните Открыть. Затем в панели Сведения о сеансе настройте раскрывающийся список Конфигурация текстового журнала для каждого файла журнала на стороне сервера на AzureStorageLog, чтобы убедиться, что анализатор сообщений Microsoft может правильно анализировать файл журнала.
4. Чтобы загрузить данные журнала на стороне клиента, щелкните Добавить файлы, перейдите к расположению, в котором сохранены журналы на стороне клиента, выберите файлы журнала, которые нужно проанализировать, и щелкните Открыть. Затем на панели Сведения о сеансе установите раскрывающийся список Конфигурации текстового журнала для каждого клиентского файла журнала на значение AzureStorageClientDotNetV4, чтобы убедиться, что анализатор сообщений Microsoft может правильно обработать файл журнала.
5. Нажмите Пуск в диалоговом окне Новый Сеанс, чтобы загрузить и проанализировать данные журнала. Данные журнала отображаются в сетке анализа сообщений.

На рисунке ниже показан пример сеанса, настроенного с файлами журнала трассировки сервера, клиента и сети.

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

Во-первых, определите интервал времени, который вы хотите просмотреть, и сделайте этот интервал времени как можно меньше. Во многих случаях вам потребуется просмотреть период в несколько минут или часов. Импортируйте наименьший набор журналов, который может соответствовать вашим потребностям.

Если у вас по-прежнему есть большой объем данных журнала, возможно, потребуется указать фильтр сеанса для фильтрации данных журнала перед загрузкой. В поле Фильтр сеансов нажмите кнопку библиотеки, чтобы выбрать предопределенный фильтр; например, выберите Глобальный фильтр времени I из фильтров службы хранилища Azure, чтобы отфильтровать по интервалу времени. Затем можно изменить критерии фильтра, чтобы указать начальную и конечную метку времени для интервала, который вы хотите просмотреть. Вы также можете отфильтровать определенный код состояния; Например, можно загрузить только записи журнала, в которых код состояния равен 404.

Дополнительные сведения об импорте данных журнала в Анализатор сообщений Майкрософт см. в статье Получение данных сообщений на сайте TechNet.

Использование идентификатора запроса клиента для сопоставления данных файла журнала

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

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

Выбор макета представления для отображения в сетке анализа

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

На рисунке ниже показано меню «Макет представления», доступное путем выбора «Макет представления» на панели инструментов. Макеты представлений для Azure Storage группируются под узлом Azure Storage в меню. Вы можете найти Azure Storage в поисковом поле, чтобы отфильтровать только макеты представлений хранилища Azure. Вы также можете выбрать звезду рядом с макетом представления, чтобы сделать ее избранной и отобразить ее в верхней части меню.

Для начала выберите , сгруппированный по ClientRequestID, и модуль. Макет представления группирует данные всех трех журналов сначала по идентификатору запроса клиента, а затем по исходному файлу журнала (или модулю в анализаторе сообщений ). В этом представлении можно перейти к детальной информации по определенному идентификатору запроса клиента и просмотреть данные из всех трех файлов журнала для этого идентификатора.

На рисунке ниже показан макет, примененный к образцу данных журнала, с отображением подмножества столбцов. Вы увидите, что для определенного идентификатора запроса клиента сетка анализа отображает данные из журнала клиента, журнала сервера и сетевой трассировки.

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

Применение правил цвета к сетке анализа

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

Чтобы применить правила цвета, выберите правила цвета на ленте панели инструментов. В меню вы увидите правила цвета службы хранилища Azure. В этом руководстве выберите ошибки клиента (StatusCode в диапазоне от 400 до 499), как показано на рисунке ниже.

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

Группируйте и фильтруйте данные журналов для поиска ошибок 400-го диапазона

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

1. Найдите столбец StatusCode в сетке анализа, щелкните правой кнопкой мыши заголовок столбца и выберите группу .

2. Затем сгруппируйте по столбцу ClientRequestId. Вы увидите, что данные в сетке анализа теперь организованы по коду состояния и идентификатору запроса клиента.

3. Отображение окна средства "Фильтр представления", если оно еще не отображается. На ленте панели инструментов выберите окна инструментов, затем фильтр просмотра.

4. Чтобы отфильтровать данные журнала для отображения только 400-диапазонных ошибок, добавьте следующие критерии фильтра в окно просмотр фильтра и нажмите кнопку Применить:

   (AzureStorageLog.StatusCode >= 400 && AzureStorageLog.StatusCode <=499) || (HTTP.StatusCode >= 400 && HTTP.StatusCode <= 499)

На рисунке ниже показаны результаты этой группировки и фильтрации. При раскрытии поля ClientRequestID в разделе для кода состояния 409 показывается, например, операция, которая привела к этому коду состояния.

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

Фильтрация данных журнала для поиска ошибок 404

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

1. Отображение окна средства "Фильтр представления", если оно еще не отображается. На ленте панели инструментов выберите окна инструментов, затем фильтр просмотра.

2. В окне фильтрации представления выберите Библиотекуи выполните поиск по Azure Storage, чтобы найти фильтры Azure Storage. Выберите фильтр для сообщений 404 (Не найдено) во всех журналах.

3. Снова откройте меню библиотеки и найдите и выберите глобальный фильтр времени.

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

5. Фильтр должен выглядеть примерно так же, как в приведенном ниже примере. Щелкните Применить, чтобы применить фильтр к сетке анализа.

   ((AzureStorageLog.StatusCode == 404 || HTTP.StatusCode == 404)) And (#Timestamp >= 2014-10-20T16:36:38 and #Timestamp <= 2014-10-20T16:36:39)

   

Анализ данных журнала

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

На рисунке ниже показан конкретный запрос, в котором операция Get Blob вернула код 404, так как Blob не существует. Обратите внимание, что некоторые столбцы были удалены из стандартного представления, чтобы отобразить соответствующие данные.

Затем мы сопоставим этот идентификатор запроса клиента с данными журнала клиента, чтобы узнать, какие действия выполняет клиент при возникновении ошибки. Вы можете отобразить новое представление сетки анализа для этого сеанса, чтобы просмотреть данные журнала клиента, открываемые на второй вкладке:

1. Сначала скопируйте значение поля ClientRequestId в буфер обмена. Это можно сделать, выбрав любую строку, найдя поле ClientRequestId, щелкнув правой кнопкой мыши на значении данных и выбрав Копировать 'ClientRequestId'.

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

3. На ленте панели инструментов выберите Представление макета, а затем выберите Все столбцы .NET-клиента в разделе Azure Storage. В этом макете представления отображаются данные из журнала клиента, а также журналы трассировки сервера и сети. По умолчанию он сортируется по столбцу MessageNumber.

4. Затем выполните поиск по журналу клиента для идентификатора запроса клиента. На ленте панели инструментов выберите Найти сообщения, а затем укажите пользовательский фильтр по идентификатору запроса клиента в поле Найти. Используйте этот синтаксис для фильтра, указав собственный идентификатор запроса клиента:

   *ClientRequestId == "398bac41-7725-484b-8a69-2a9e48fc669a"

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

журнал клиента

Используя данные, отображаемые в макетах представления на этих двух вкладках, можно проанализировать данные запроса, чтобы определить, что могло вызвать ошибку. Вы также можете просмотреть запросы, предшествующие этому, чтобы узнать, может ли предыдущее событие привести к ошибке 404. Например, можно просмотреть записи журнала клиента, предшествующие этому идентификатору запроса клиента, чтобы определить, может ли BLOB быть удалён, или если ошибка произошла из-за вызова API CreateIfNotExists в контейнере или BLOB. В журнале клиента можно найти адрес большого двоичного объекта в поле Описание; в журналах трассировки сервера и сети эти сведения отображаются в поле Сводка.

Как только вы получите адрес блоба, вызвавшего ошибку 404, можно продолжить его исследование. При поиске записей журнала для других сообщений, связанных с операциями с тем же объектом BLOB, можно проверить, удалял ли клиент сущность ранее.

Анализ других типов ошибок хранилища

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

Дальнейшие действия

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

• Наблюдение, диагностика и устранение неисправностей хранилища Microsoft Azure
• Аналитика службы хранилища
• Мониторинг учетной записи хранения на портале Azure
• Передача данных с помощью служебной программы командной строки AzCopy
• руководство по работе с анализатором сообщений Майкрософт