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

• Портал Azure

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

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

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

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

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

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

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

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

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

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

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

О примере сценария

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

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

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

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

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

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

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

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

Возникает при сбое операции чтения для BLOB-объекта или контейнера, если не найден BLOB-объект или контейнер.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сбор данных трассировки сети

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

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

В учебнике сначала производится сбор и сохранение сетевой трассировки в анализаторе сообщений, а затем создание сеанса анализа для анализа трассировки и журналов. Сбор трассировки сети в анализаторе сообщений:

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

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

3. Выберите Изменить для изменения сеанса трассировки.

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

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

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

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

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

Примечание

После завершения сбора трассировки сети настоятельно рекомендуется восстанавливать параметры, которые могли быть изменены Fiddler для расшифровки HTTPS-трафика. В диалоговом окне "Параметры Fiddler" снимите флажки Захват подключений HTTPS и Расшифровка трафика HTTPS.

Для получения дополнительных сведений см. раздел Использование трассировки сети в библиотеке Technet.

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

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

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

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

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

Примечание

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

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

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

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

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

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

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

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

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

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

Примечание

Для целей данного учебника установите все ресурсы хранилища Azure.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание

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

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

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

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

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

С помощью цветовых правил хранилища Azure можно определить и сохранить собственные правила.

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

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

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

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

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

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

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

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

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

Примечание

Можно выполнить фильтрацию по столбцу StatusCode и по-прежнему отображать данные из всех трех журналов, включая журнал клиента, если добавить выражение в фильтр, которое включает записи журнала с кодом состояния, имеющим значение null. Чтобы создать этот критерий фильтра, используйте следующее:

*StatusCode >= 400 or !*StatusCode

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

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

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

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

2. В окне "Фильтр представления" выберите БиблиотекаAzure Storage и выполните поиск по, чтобы найти фильтры службы хранилища Azure. Выберите фильтр для сообщения 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. Этот макет представления отображает данные от клиента журнала, а также журналы трассировки сервера и сети. По умолчанию он отсортирован по столбцу MessageNumber .

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

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

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

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

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

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

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

Для изучения...	Использование выражения фильтра	Выражение применяется к журналу (клиента, сервера, сети, всех)
Непредвиденные задержки при доставке сообщений в очередь	AzureStorageClientDotNetV4.Description содержит "Повторное выполнение неудавшейся операции".	клиент
Увеличение HTTP в PercentThrottlingError	HTTP. Response.StatusCode == 500 || HTTP. Response.StatusCode == 503	Сеть
Увеличение PercentTimeoutError	HTTP.Response.StatusCode == 500	Сеть
Увеличение PercentTimeoutError (все)	*StatusCode == 500	All
Увеличение PercentNetworkError	AzureStorageClientDotNetV4.EventLogEntry.Level < 2	клиент
Сообщения HTTP 403 (запрещено)	HTTP.Response.StatusCode == 403	Сеть
Сообщения HTTP 404 (не найдено)	HTTP.Response.StatusCode == 404	Сеть
404 (все)	*StatusCode == 404	All
Общие проблемы авторизации подписи доступа (SAS)	AzureStorageLog.RequestStatus == "SASAuthorizationError"	Сеть
Сообщения HTTP 409 (конфликт)	HTTP.Response.StatusCode == 409	Сеть
409 (все)	*StatusCode == 409	Все
Низкие значения PercentSuccess, или в записях журналов аналитики присутствуют операции с состоянием транзакции ClientOtherErrors	AzureStorageLog.RequestStatus == "ClientOtherError"	Сервер
Предупреждение Nagle	((AzureStorageLog.EndToEndLatencyMS — AzureStorageLog.ServerLatencyMS) > (AzureStorageLog.ServerLatencyMS * 1.5)) и (AzureStorageLog.RequestPacketSize <1460) и (AzureStorageLog.EndToEndLatencyMS - AzureStorageLog.ServerLatencyMS >= 200)	Сервер
Диапазон времени в журналах сервера и сети	>#Timestamp = 2014-10-20T16:36:38 и #Timestamp <= 2014-10-20T16:36:39	Сервер, сеть
Диапазон времени в журналах сервера	AzureStorageLog.Timestamp >= 2014-10-20T16:36:38 и AzureStorageLog.Timestamp <= 2014-10-20T16:36:39	Сервер

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

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

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