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

Мониторинг, диагностика и устранение неполадок со службой хранилища Microsoft Azure (классическая версия)

  • Статья

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

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

Это руководство в первую очередь предназначено для разработчиков веб-служб, использующих службы хранилища Azure, а также для ИТ-специалистов, ответственных за управление ими. Цели этого руководства:

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

Примечание.

Эта статья основана на использовании Аналитика Службы хранилища метрик и журналов, называемых классическими метриками и журналами. Вместо метрик Аналитики Службы хранилища рекомендуется использовать метрики и журналы службы хранилища Azure в Azure Monitor. Дополнительные сведения см. в следующих статьях:

Обзор

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

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

Структура руководства

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

В разделе "Диагностика проблем с хранилищем" описывается, как диагностировать проблемы с помощью ведения журнала служба хранилища Azure Аналитики (ведение журнала хранилища). В нем также описывается, как включить ведение журнала на стороне клиента с помощью средств в одной из клиентских библиотек, таких как клиентская библиотека хранилища для .NET или пакет SDK Azure для Java.

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

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

В разделе "Добавление" содержатся сведения об использовании других средств, таких как Wireshark и Netmon для анализа данных сетевого пакета и Fiddler для анализа сообщений HTTP/HTTPS.

Мониторинг службы хранилища

Если вы знакомы с системным монитором Windows, то можете считать, что метрики хранилища — эквивалент счетчиков службы хранилища Azure. В метриках хранилища вы найдете полный набор метрик (счетчики в терминологии Windows Монитор производительности), такие как доступность службы, общее количество запросов к службе или процент успешных запросов к службе. Полный список доступных метрик см. в статье Storage Analytics Metrics Table Schema (Схема таблицы метрик аналитики хранилища). Вы можете настроить службу хранилища так, чтобы она собирала и агрегировала метрики каждый час или каждую минуту. Дополнительные сведения о том, как включить метрики и отслеживать учетные записи хранения, см. в статье Enabling storage metrics and viewing metrics data (Включение метрик хранилища и просмотр данных метрик).

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

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

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

На портале Azure можно просматривать такие метрики для учетной записи хранения, как доступность, общее количество запросов и средние показатели задержки. Кроме того, на этой странице настроено правило для оповещения администратора о спаде доступности ниже определенного уровня. При просмотре этих данных одна из возможных областей для исследования — это процент успешного выполнения службы таблиц ниже 100 % (дополнительные сведения см . в разделе "Метрики" с низким процентомSuccess или журналов аналитики с состоянием транзакции раздела ClientOtherErrors ).

Вы должны постоянно отслеживать приложения Azure, чтобы обеспечить их работоспособность и выполнение должным образом:

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

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

Схемы с примерами того, как почасовое усреднение метрик может скрывать пики активности.

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

Мониторинг работоспособности службы

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

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

Примечание.

Ранее эта информация, наряду с данными журналов, была доступна на панели мониторинга служб Azure. Дополнительные сведения о Application Insights для Azure DevOps см . в приложении 5. Мониторинг с помощью Application Insights для Azure DevOps.

Мониторинг производительности

Метрики хранилища хранят только метрики емкости для службы BLOB-объектов, так как большие двоичные объекты обычно учитывают большую долю сохраненных данных (во время записи невозможно использовать метрики хранилища для мониторинга емкости таблиц и очередей). Эти данные можно найти в $MetricsCapacityBlob таблице, если вы включили мониторинг для службы BLOB-объектов. Метрики хранилища записывают эти данные один раз в день, и вы можете использовать значение RowKey для определения того, содержит ли строка сущность, связанную с данными пользователя (значение data) или аналитическими данными (значение analytics). Каждая хранимая сущность содержит сведения о объеме используемого хранилища (Capacityизмеряемого в байтах) и текущего количества контейнеров () и больших двоичных объектов (ContainerCountObjectCount) в учетной записи хранения. Дополнительные сведения о метриках емкости, хранящихся в $MetricsCapacityBlob таблице, см. в Аналитика Службы хранилища схеме таблицы метрик.

Примечание.

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

Чтобы оценить размер различных объектов хранилища, таких как большие двоичные объекты, см. статью "Общие сведения о служба хранилища Azure выставлении счетов" — "Пропускная способность", "Транзакции" и "Емкость".

Отслеживание доступности

Вы должны отслеживать доступность служб хранения в учетной записи хранения, отслеживая значение в Availability столбце в таблицах метрик почасовой или минутной метрики — $MetricsHourPrimaryTransactionsBlob, , $MetricsMinutePrimaryTransactionsBlob$MetricsHourPrimaryTransactionsTable$MetricsHourPrimaryTransactionsQueue, . $MetricsMinutePrimaryTransactionsQueue$MetricsCapacityBlob$MetricsMinutePrimaryTransactionsTable Столбец Availability содержит процентное значение, указывающее доступность службы или операцию API, представленную строкой ( RowKey показывает, содержит ли строка метрики для службы в целом или для определенной операции API).

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

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

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

Мониторинг производительности

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

  • Значения в AverageE2ELatency AverageServerLatency столбцах показывают среднее время, когда служба хранилища или тип операции API принимается для обработки запросов. AverageE2ELatency — это мера сквозной задержки, которая включает время, затраченное на чтение запроса и отправку ответа в дополнение к времени, затраченного на обработку запроса (поэтому включает задержку сети после того, как запрос достигнет службы хранилища); AverageServerLatency является мерой простого времени обработки и, следовательно, исключает любую задержку сети, связанную с взаимодействием с клиентом. См. раздел "Метрики" с высоким значением AverageE2ELatency и low AverageServerLatency далее в этом руководстве по обсуждению того, почему между этими двумя значениями может возникнуть существенная разница.
  • Значения в TotalIngress столбцах TotalEgress показывают общий объем данных в байтах, поступающих и выходе из службы хранилища или через определенный тип операции API.
  • Значения в столбце TotalRequests показывают общее количество запросов, которые служба хранилища операции API получает. TotalRequests — общее количество запросов, получаемых службой хранилища.

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

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

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

Диагностика неполадок с хранилищем

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

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

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

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

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

Проблемы с работоспособностью службы

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

Проблемы с производительностью

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

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

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

Диагностика ошибок

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

Примечание.

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

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

Проблемы с эмулятором хранения

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

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

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

Ведение журналов хранилища подразумевает запись в журнал на стороне сервера запросов к хранилищу в вашей учетной записи хранения Azure. Дополнительные сведения о том, как включить ведение журнала на стороне сервера, и о доступе к данным журнала см. в статье Enabling Storage Logging and Accessing Log Data (Включение ведения журнала и доступ к данным журнала хранилища).

С помощью клиентской библиотеки хранилища для .NET вы можете собирать на стороне клиента данные журнала, связанные с операциями хранилища, которые выполняются приложением. Дополнительные сведения см. в статье Client-side Logging with the .NET Storage Client Library (Ведение журналов на стороне клиента с помощью клиентской библиотеки хранилища для .NET).

Примечание.

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

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

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

  • Fiddler — это бесплатный веб-прокси для отладки, с помощью которого можно проверять заголовки и полезные данные HTTP- и HTTPS-запросов, а также ответных сообщений. Дополнительные сведения см. в приложении 1 "Отслеживание HTTP- и HTTPS-трафика с помощью Fiddler".
  • Microsoft Network Monitor (Netmon) и Wireshark — бесплатные средства для анализа сетевых протоколов, с помощью которых можно просматривать подробную информацию о пакетах для широкого спектра сетевых протоколов. Дополнительные сведения о Wireshark см . в приложении 2. Использование Wireshark для записи сетевого трафика.
  • Если вы хотите выполнить базовый тест подключения, чтобы проверить, может ли клиентская машина подключиться к службе хранилища Azure по сети, этого не удастся сделать с помощью стандартного инструмента ping на клиенте. Однако вы можете воспользоваться для проверки подключения инструментом tcping .

Во многих случаях данных журналов хранилища и клиентской библиотеки хранилища достаточно для диагностики проблемы, но иногда вам могут потребоваться более подробные сведения, чем способны предоставить эти инструменты. Например, используя Fiddler для просмотра сообщений HTTP и HTTPS, вы можете видеть заголовки и полезные данные, отправленные в службы хранилища и из них. Это позволяет проверить, как работает повтор операций хранилища в клиентском приложении. Средства для анализа протоколов, такие как Wireshark, работают на уровне пакетов, благодаря чему вы можете просматривать данные TCP и выявлять потерянные пакеты и проблемы с подключением.

Комплексная трассировка

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

Сопоставление данных журналов

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

Идентификатор запроса клиента

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

  • В клиентском журнале, который создает клиентская библиотека хранилища, идентификатор запроса клиента отображается в Client Request ID поле каждой записи журнала, связанной с запросом.
  • В трассировке сети, такой как один, захваченный Fiddler, идентификатор запроса клиента отображается в сообщениях запроса в качестве x-ms-client-request-id значения заголовка HTTP.
  • В журнале хранилища на стороне сервера идентификатор запроса клиента отображается в столбце "ИД запроса клиента".

Примечание.

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

Идентификатор запроса сервера

Служба хранилища автоматически генерирует идентификаторы запросов сервера.

  • В журнале ведения журнала хранилища на стороне сервера идентификатор запроса сервера отображается в столбце Request ID header .
  • В трассировке сети, такой как один, захваченный Fiddler, идентификатор запроса сервера отображается в ответных сообщениях в качестве x-ms-request-id значения заголовка HTTP.
  • В клиентском журнале, который создает клиентская библиотека хранилища, идентификатор запроса сервера отображается в Operation Text столбце записи журнала с подробными сведениями о ответе сервера.

Примечание.

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

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

var connectionString = Constants.connectionString;

BlobServiceClient blobServiceClient = new BlobServiceClient(connectionString);

BlobContainerClient blobContainerClient = blobServiceClient.GetBlobContainerClient("demcontainer");

BlobClient blobClient = blobContainerClient.GetBlobClient("testImage.jpg");

string clientRequestID = String.Format("{0} {1} {2} {3}", HOSTNAME, APPNAME, USERID, Guid.NewGuid().ToString());

using (HttpPipeline.CreateClientRequestIdScope(clientRequestID))
{
    BlobDownloadInfo download = blobClient.Download();

    using (FileStream downloadFileStream = File.OpenWrite("C:\\testImage.jpg"))
    {
        download.Content.CopyTo(downloadFileStream);
        downloadFileStream.Close();
    }
}

Метки времени

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

Рекомендации по устранению неполадок

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

Дерево принятия решений по устранению неполадок

Относится ли ваша проблема к производительности одной из служб хранилища?

Связана ли неполадка с доступностью одной из служб хранилища?

Получает ли клиентское приложение ответ HTTP 4XX (например, с кодом 404) от службы хранилища?

Метрики показывают низкий процентSuccess или записи журнала аналитики с состоянием транзакции ClientOtherErrors.

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

Проблема возникает из-за использования эмулятора хранилища для разработки или тестирования.

Возникают проблемы с установкой пакета SDK Azure для .NET.

У вас есть другая проблема со службой хранения.

Метрики содержат высокие значения AverageE2ELatency и низкие значения AverageServerLatency

На приведенной ниже иллюстрации из средства мониторинга на портале Azure показана ситуация, когда значение метрики AverageE2ELatency значительно выше значения метрики AverageServerLatency.

Иллюстрация: портал Azure с примером, в котором значение метрики AverageE2ELatency значительно выше значения метрики AverageServerLatency.

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

Примечание.

Вы также можете просмотреть метрики E2ELatency и ServerLatency для отдельных операций хранилища в журнале хранилища.

Изучение проблем с производительностью клиента

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

Для служб таблиц и очередей алгоритм Nagle также может вызвать высокий показатель AverageE2ELatency по сравнению с AverageServerLatency. Дополнительные сведения см. в разделе "Алгоритм Nagle" не является понятным для небольших запросов. Алгоритм Nagle в коде можно отключить с помощью ServicePointManager класса в System.Net пространстве имен. Это необходимо сделать, прежде чем выполнять вызовы к службам таблиц или очередей в приложении, так как это не влияет на подключения, которые уже открыты. Следующий пример приводится из Application_Start метода в рабочей роли.

var connectionString = Constants.connectionString;

QueueServiceClient queueServiceClient = new QueueServiceClient(connectionString);

ServicePoint queueServicePoint = ServicePointManager.FindServicePoint(queueServiceClient.Uri);
queueServicePoint.UseNagleAlgorithm = false;

Необходимо проверить журналы на стороне клиента, чтобы узнать, сколько запросов ваше клиентское приложение отправляет и проверяет общие сведения. Узкие места производительности, связанные с NET в клиенте, такие как ЦП, сборка мусора .NET, использование сети или память. В качестве отправной точки для устранения неполадок в клиентских приложениях .NET используйте статью Debugging, Tracing, and Profiling (Отладка, трассировка и профилирование).

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

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

Дополнительные сведения об использовании Wireshark для устранения проблем с сетью см . в приложении 2. Использование Wireshark для записи сетевого трафика.

Метрики содержат низкие значения AverageE2ELatency и низкие значения AverageServerLatency, но клиент сталкивается с большой задержкой

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

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

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

  • Изучите журналы аналитики хранилища. Если выполняется сразу несколько попыток, вы увидите несколько операций с одинаковым идентификатором запроса клиента, но с разными идентификаторами запроса сервера.
  • Изучите журналы клиента. Подробное ведение журнала позволит определить наличие повторной попытки.
  • Отладка кода и проверка свойств объекта, связанного OperationContext с запросом. Если операция повторилась, RequestResults свойство будет содержать несколько уникальных идентификаторов запросов сервера. Можно также проверить время начала и окончания для каждого запроса. Для получения дополнительных сведений изучите пример кода в разделе Идентификатор запроса сервера.

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

Дополнительные сведения об использовании Wireshark для устранения проблем с сетью см . в приложении 2. Использование Wireshark для записи сетевого трафика.

Метрики содержат высокие значения AverageServerLatency

В случае высокого значения AverageServerLatency для запросов на загрузку BLOB-объектов следует просмотреть журналы хранилища, чтобы проверить, нет ли повторных запросов для одного и того же BLOB-объекта (или набора BLOB-объектов). Для запросов на отправку BLOB-объектов следует изучить размер блока, который использует клиент (например, блоки менее 64 K в размере могут привести к затратам, если операции чтения также не находятся в менее чем 64 Kunks) и если несколько клиентов отправляют блоки в один большой двоичный объект параллельно. Кроме того, следует проверить метрики за минуту для пиковых показателей числа запросов, которые приводят к превышению целевых показателей масштабируемости в секунду. Дополнительные сведения см. в разделе "Метрики" с увеличением процента PercentTimeoutError.

Если вы видите высокий уровень AverageServerLatency для запросов загрузки BLOB-объектов при наличии повторяющихся запросов для одного и того же большого двоичного объекта или набора больших двоичных объектов, рассмотрите возможность кэширования этих BLOB-объектов с помощью кэша Azure или Azure сеть доставки содержимого (CDN). Для запросов отправки пропускную способность можно увеличить с помощью блоков большего размера. Для запросов к таблицам также можно реализовать кэширование на стороне клиента на клиентах, выполняющих те же операции запросов и где данные часто не изменяются.

Высокие значения метрики AverageServerLatency также могут быть симптомом неправильной структуры таблиц или запросов, которая приводит к выполнению операций сканирования или построена по ошибочному шаблону добавления в конец и начало. Дополнительные сведения см. в разделе "Метрики" с увеличением процента PercentThrottlingError.

Примечание.

Полный контрольный список производительности можно найти здесь: служба хранилища Microsoft Azure контрольный список производительности и масштабируемости.

При доставке сообщений в очередь возникают неожиданные задержки

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

  • Убедитесь, что приложение успешно добавляет сообщения в очередь. Убедитесь, что приложение не повторяет AddMessage метод несколько раз, прежде чем выполнить успешное выполнение. В журналах клиентской библиотеки хранилища содержатся записи о повторных попытках выполнения операций с хранилищем.
  • Убедитесь, что между рабочей ролью нет отклонений между рабочей ролью, которая добавляет сообщение в очередь и рабочая роль, которая считывает сообщение из очереди. Отклонение часов делает его вид, как если бы в обработке произошла задержка.
  • Проверьте, нет ли сбоев рабочей роли, считывающей сообщения из очереди. Если клиент очереди вызывает GetMessage метод, но не отвечает с подтверждением, сообщение остается невидимым в очереди до invisibilityTimeout истечения срока действия. После этого сообщение снова станет доступным для обработки.
  • Проверьте, не увеличивается ли длина очереди со временем. Это может произойти, если у вас недостаточно рабочих ролей для обработки всех сообщений, которые другие работники помещают в очередь. Кроме того, проверьте метрики, чтобы узнать, завершаются ли запросы на удаление, а отсчитывается от сообщений, что может указывать на повторяющиеся неудачные попытки удаления сообщения.
  • Проверьте журналы хранилища на наличие операций с очередью, имеющих неожиданно высокие значения метрик E2ELatency и ServerLatency в течение более длительного периода времени, чем обычно.

Метрики показывают увеличение значения PercentThrottlingError

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

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

Увеличение процента PercentThrottlingError часто происходит одновременно с увеличением количества запросов на хранение или при первоначальном нагрузочном тестировании приложения. Это также может проявляться в получении сообщений о состоянии HTTP 503 "Сервер занят" или 500 "Время ожидания операции истекло" в клиенте при операциях с хранилищем.

Временное увеличение значения PercentThrottlingError

Если вы видите пики в значении PercentThrottlingError , которое совпадает с периодами высокой активности для приложения, вы можете реализовать экспоненциальную (не линейную) стратегию возврата для повторных попыток в клиенте. Обратные повторные попытки снижают немедленную нагрузку на секцию и помогают приложению сглаживать пики трафика. Дополнительные сведения о том, как реализовать политики повтора с помощью клиентской библиотеки хранилища, см. в статье Пространство имен Microsoft.Azure.Storage.RetryPolicies.

Примечание.

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

Постоянное увеличение процента PercentThrottlingError

Если вы видите стабильно высокое значение для PercentThrottlingError после постоянного увеличения объема транзакций или при выполнении первоначальных нагрузочных тестов в приложении, необходимо оценить, как приложение использует секции хранилища и подходит ли оно к целевым показателям масштабируемости для учетной записи хранения. Например, если вы видите ошибки регулирования в очереди (которая считается одной секцией), рассмотрите возможность использования дополнительных очередей для распределения транзакций по нескольким секциям. Если в таблице возникают ошибки регулирования, необходимо использовать другую схему секционирования для распределения транзакций по нескольким секциям с помощью более широкого диапазона значений ключа секции. Одной из распространенных причин этой проблемы является предустановка или добавление антишаблоны, в которой вы выбираете дату в качестве ключа секции, а затем все данные в определенный день записываются в одну секцию: при загрузке это может привести к узким местам записи. Измените схему секционирования или оцените возможность использования хранилища BLOB-объектов как более оптимального решения. Кроме того, проверьте, происходит ли регулирование в результате пиков трафика и изучите способы сглаживания шаблонов запросов.

Если транзакции распределяются между несколькими разделами, следует тем не менее учитывать предельные значения масштабируемости, установленные для учетной записи хранения. Например, если вы использовали десять очередей, каждая обработка не более 2000 1 КБ сообщений в секунду, вы будете в общей сложности 20 000 сообщений в секунду для учетной записи хранения. Если необходимо обработать более 20 000 сущностей в секунду, рассмотрите возможность использования нескольких учетных записей хранения. Также следует помнить, что размер ваших запросов и сущностей влияет на то, когда служба хранилища регулирует ваши клиенты. Если у вас есть более крупные запросы и сущности, вы можете регулироваться раньше.

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

Примечание.

Неэффективная структура запросов должна выявляться при тестировании производительности приложения.

Метрики показывают увеличение значения PercentTimeoutError

Вы можете наблюдать увеличение метрики PercentTimeoutError для одной из служб хранилища. В то же время клиент может получать большое число сообщений о состоянии HTTP 500 "Время ожидания операции истекло" при операциях с хранилищем.

Примечание.

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

Метрика PercentTimeoutError является сводной и состоит из следующих метрик: ClientTimeoutError, AnonymousClientTimeoutError, SASClientTimeoutError, ServerTimeoutError, AnonymousServerTimeoutError и SASServerTimeoutError.

Время ожидания сервера истекает из-за ошибок на сервере. Время ожидания клиента происходит, так как операция на сервере превысила время ожидания, указанное клиентом; Например, клиент с помощью клиентской библиотеки хранилища может задать время ожидания для операции с помощью ServerTimeout свойства QueueRequestOptions класса.

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

Метрики показывают увеличение значения PercentNetworkError

Вы можете наблюдать увеличение метрики PercentNetworkError для одной из служб хранилища. Метрика PercentNetworkError является сводной и состоит из следующих метрик: NetworkError, AnonymousNetworkError и SASNetworkError. Это происходит, когда служба хранилища обнаруживает ошибку сети при выполнении клиентом запроса к хранилищу.

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

Клиент получает сообщения «HTTP 403 (запрещено)»

Если в клиентском приложении происходят ошибки HTTP 403 (Запрещено), наиболее вероятная причина заключается в использовании клиентом подписанного URL-адреса (SAS) с истекшим сроком действия при отправке запроса к хранилищу (хотя возможны и другие причины: рассинхронизация по времени, недействительные ключи и пустые заголовки). Если ключ SAS с истекшим сроком действия является причиной, вы не увидите записи в данных журнала журнала хранилища на стороне сервера. В приведенной ниже таблице показан пример этой неполадки в журнале на стороне клиента, созданном клиентской библиотекой хранилища.

Исходный код Уровень детализации Уровень детализации Идентификатор запроса клиента Operation Text
Microsoft.Azure.Storage Информация 3 85d077ab- Starting operation with location Primary per location mode PrimaryOnly.
Microsoft.Azure.Storage Информация 3 85d077ab - Starting synchronous request to https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Synchronous_and_Asynchronous_Requests#Synchronous_request.
Microsoft.Azure.Storage Информация 3 85d077ab - Waiting for response.
Microsoft.Azure.Storage Предупреждение 2 85d077ab - Exception thrown while waiting for response: The remote server returned an error: (403) Forbidden.
Microsoft.Azure.Storage Информация 3 85d077ab - Response received. Status code = 403, Request ID = <Request ID>, Content-MD5 = , ETag = .
Microsoft.Azure.Storage Предупреждение 2 85d077ab - Exception thrown during the operation: The remote server returned an error: (403) Forbidden..
Microsoft.Azure.Storage Информация 3 85d077ab - Checking if the operation should be retried. Retry count = 0, HTTP status code = 403, Exception = The remote server returned an error: (403) Forbidden..
Microsoft.Azure.Storage Информация 3 85d077ab - The next location has been set to Primary, based on the location mode.
Microsoft.Azure.Storage Ошибка 1 85d077ab - Retry policy did not allow for a retry. Failing with The remote server returned an error: (403) Forbidden.

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

  • Как правило, не следует задавать время начала при создании SAS для клиента, который будет использоваться немедленно. Если между узлом, создающим SAS, существуют небольшие различия между текущим временем и службой хранения, то служба хранилища может получить SAS, который еще не действителен.
  • Не устанавливайте очень короткое время истечения срока действия в SAS. Опять же, небольшие часы между узлом, создающим SAS и службой хранилища, могут привести к тому, что SAS, казалось бы, истекает раньше, чем ожидалось.
  • Соответствует ли параметр версии в ключе SAS (например, sv=2015-04-05) версии используемой клиентской библиотеки хранилища? Всегда используйте последнюю версию клиентской библиотеки хранилища.
  • Повторное создание ключей доступа к хранилищу может привести к тому, что существующие токены SAS станут недействительными. Эта проблема может возникнуть при генерации маркеров SAS с большим сроком действия для кэширования клиентскими приложениями.

Если вы используете клиентскую библиотеку хранилища для создания маркеров SAS, то легко создать действительный маркер. Однако если вы используете REST API хранилища и создаете маркеры SAS вручную, см . раздел "Делегирование доступа с помощью подписанного URL-адреса".

Клиент получает сообщения «HTTP 404 (не найдено)»

Если клиентское приложение получает сообщение HTTP 404 (не найдено) от сервера, это означает, что объект, который клиент пытается использовать (например, сущность, таблицу, большой двоичный объект, контейнер или очередь) не существует в службе хранилища. Это может быть вызвано несколькими причинами, включая перечисленные ниже.

Объект удален ранее клиентом или другим процессом.

В сценариях, когда клиент пытается считывать, обновлять или удалять данные в службе хранилища, обычно легко идентифицировать в журналах на стороне сервера предыдущую операцию, которая удалила объект из службы хранилища. По данным журнала очень часто можно увидеть, что объект удален другим пользователем или объектом. В журнале хранилища на стороне сервера есть столбцы Operation-type (Тип операции) и Requested-object-key (Ключ запрошенного объекта), по которым можно понять, когда объект был удален клиентом.

В сценарии, когда клиент пытается вставить объект, он может быть не сразу очевиден, почему это приводит к ответу HTTP 404 (не найдено), учитывая, что клиент создает новый объект. Однако если клиент создает большой двоичный объект, он должен быть в состоянии найти контейнер BLOB-объектов. Если клиент создает сообщение, он должен иметь возможность найти очередь. И если клиент добавляет строку, она должна иметь возможность найти таблицу.

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

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

Идентификатор запроса Операция
07b26a5d-... DeleteIfExists метод удаления контейнера BLOB-объектов. Обратите внимание, что эта операция включает HEAD запрос на проверку существования контейнера.
e2d06d78 CreateIfNotExists метод создания контейнера BLOB-объектов. Обратите внимание, что эта операция включает HEAD запрос, который проверяет наличие контейнера. Возвращается HEAD сообщение 404, но продолжается.
de8b1c3c-... UploadFromStream метод создания большого двоичного объекта. Запрос PUT завершается ошибкой с сообщением 404.

Записи журнала:

Идентификатор запроса Operation Text
07b26a5d-... Starting synchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer.
07b26a5d-... StringToSign = HEAD............x-ms-client-request-id:07b26a5d-....x-ms-date:Tue, 03 Jun 2014 10:33:11 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer.restype:container.
07b26a5d-... Waiting for response.
07b26a5d-... Response received. Status code = 200, Request ID = eeead849-...Content-MD5 = , ETag = &quot;0x8D14D2DC63D059B&quot;.
07b26a5d-... Response headers were processed successfully, proceeding with the rest of the operation.
07b26a5d-... Downloading response body.
07b26a5d-... Operation completed successfully.
07b26a5d-... Starting synchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer.
07b26a5d-... StringToSign = DELETE............x-ms-client-request-id:07b26a5d-....x-ms-date:Tue, 03 Jun 2014 10:33:12 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer.restype:container.
07b26a5d-... Waiting for response.
07b26a5d-... Response received. Status code = 202, Request ID = 6ab2a4cf-..., Content-MD5 = , ETag = .
07b26a5d-... Response headers were processed successfully, proceeding with the rest of the operation.
07b26a5d-... Downloading response body.
07b26a5d-... Operation completed successfully.
e2d06d78-... Starting asynchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer.
e2d06d78-... StringToSign = HEAD............x-ms-client-request-id:e2d06d78-....x-ms-date:Tue, 03 Jun 2014 10:33:12 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer.restype:container.
e2d06d78-... Waiting for response.
de8b1c3c-... Starting synchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer/blobCreated.txt.
de8b1c3c-... StringToSign = PUT...64.qCmF+TQLPhq/YYK50mP9ZQ==........x-ms-blob-type:BlockBlob.x-ms-client-request-id:de8b1c3c-....x-ms-date:Tue, 03 Jun 2014 10:33:12 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer/blobCreated.txt.
de8b1c3c-... Preparing to write request data.
e2d06d78-... Exception thrown while waiting for response: The remote server returned an error: (404) Not Found..
e2d06d78-... Response received. Status code = 404, Request ID = 353ae3bc-..., Content-MD5 = , ETag = .
e2d06d78-... Response headers were processed successfully, proceeding with the rest of the operation.
e2d06d78-... Downloading response body.
e2d06d78-... Operation completed successfully.
e2d06d78-... Starting asynchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer.
e2d06d78-... StringToSign = PUT...0.........x-ms-client-request-id:e2d06d78-....x-ms-date:Tue, 03 Jun 2014 10:33:12 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer.restype:container.
e2d06d78-... Waiting for response.
de8b1c3c-... Writing request data.
de8b1c3c-... Waiting for response.
e2d06d78-... Exception thrown while waiting for response: The remote server returned an error: (409) Conflict..
e2d06d78-... Response received. Status code = 409, Request ID = c27da20e-..., Content-MD5 = , ETag = .
e2d06d78-... Downloading error response body.
de8b1c3c-... Exception thrown while waiting for response: The remote server returned an error: (404) Not Found..
de8b1c3c-... Response received. Status code = 404, Request ID = 0eaeab3e-..., Content-MD5 = , ETag = .
de8b1c3c-... Exception thrown during the operation: The remote server returned an error: (404) Not Found..
de8b1c3c-... Retry policy did not allow for a retry. Failing with The remote server returned an error: (404) Not Found..
e2d06d78-... Retry policy did not allow for a retry. Failing with The remote server returned an error: (409) Conflict..

В этом примере журнал показывает, что клиент чередует запросы из метода (идентификатор запроса e2d06d78...) с запросами из CreateIfNotExists UploadFromStream метода (de8b1c3c-...). Это происходит, так как клиентское приложение вызывает эти методы асинхронно. Измените код с асинхронными вызовами в клиенте таким образом, чтобы он создавал контейнер до того, как попытается передать какие-либо данные в большой двоичный объект в этом контейнере. В идеале нужно создавать все контейнеры заранее.

Проблема с авторизацией подписанного URL-адреса (SAS)

Если клиентское приложение пытается использовать ключ SAS, который не включает необходимые разрешения для операции, служба хранилища возвращает сообщение HTTP 404 (не найдено) клиенту. В то же время вы также увидите ненулевое значение SASAuthorizationError в метриках.

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

Имя. Значение
Request start time (Время начала запроса) 2014-05-30T06:17:48.4473697Z
Тип операции GetBlobProperties
Статус запроса SASAuthorizationError
Код состояния HTTP 404
Тип аутентификации SAS
тип услуги; BLOB-объект
Запросить URL-адрес https://domemaildist.blob.core.windows.net/azureimblobcontainer/blobCreatedViaSAS.txt
  ?sv=2014-02-14&sr=c&si=mypolicy&sig=XXXXX&; api-version=2014-02-14
Request ID header (Заголовок идентификатора запроса) <Заголовок идентификатора запроса>
Идентификатор запроса клиента <Идентификатор запроса клиента>

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

Клиентский код JavaScript не имеет разрешения на доступ к объекту

Если вы используете клиент JavaScript, а служба хранилища возвращает сообщения HTTP 404, проверьте следующие ошибки JavaScript в браузере:

SEC7120: источник http://localhost:56309 не найден в заголовке Access-Control-Allow-Origin.
SCRIPT7002: XMLHttpRequest: ошибка сети 0x80070005, доступ запрещен.

Примечание.

Средства разработчика F12 в Internet Explorer можно использовать для трассировки сообщений, обмениваемых между браузером и службой хранилища при устранении неполадок JavaScript на стороне клиента.

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

Чтобы обойти проблему JavaScript, можно настроить общий доступ к ресурсам между источниками (CORS) для службы хранилища, к ней обращается клиент. Дополнительные сведения см. в статье Cross-Origin Resource Sharing (CORS) Support for Azure Storage Services (Поддержка общего доступа к ресурсам независимо от источника (CORS) для служб хранилища Azure).

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

var connectionString = Constants.connectionString;

 BlobServiceClient blobServiceClient = new BlobServiceClient(connectionString);

 BlobServiceProperties sp = blobServiceClient.GetProperties();

 // Set the service properties.
 sp.DefaultServiceVersion = "2013-08-15";
 BlobCorsRule bcr = new BlobCorsRule();
 bcr.AllowedHeaders = "*";

 bcr.AllowedMethods = "GET,POST";
 bcr.AllowedOrigins = "http://www.contoso.com";
 bcr.ExposedHeaders = "x-ms-*";
 bcr.MaxAgeInSeconds = 5;
 sp.Cors.Clear();
 sp.Cors.Add(bcr);
 blobServiceClient.SetProperties(sp);

Сбой сети

В некоторых обстоятельствах потеря сетевых пакетов может привести к тому, что служба хранилища будет возвращать клиенту сообщения HTTP 404. Например, когда клиентское приложение удаляет сущность из службы таблиц, клиент выдает исключение хранилища, сообщающее сообщение о состоянии HTTP 404 (Не найдено) из службы таблиц. Если вы посмотрите на таблицу в службе таблиц, то поймете, что субъект удален в соответствии с запросом.

Сведения об исключении в клиенте включают идентификатор запроса (7e84f12d...), назначенный службой таблиц для запроса. Эти сведения можно использовать для поиска сведений о запросе в журналах хранилища на стороне сервера, выполнив поиск в request-id-header столбце в файле журнала. Кроме того, можно проверить метрики для того, чтобы выяснить, когда возникают такие ошибки, а затем выполнить поиск в файлах журналов по зафиксированному в метриках времени. Эта запись журнала указывает на то, что удаление не выполнено и возвращено сообщение о состоянии HTTP (404) Client Other Error (Другая ошибка клиента). Та же запись журнала также содержит идентификатор запроса, созданный клиентом в столбце client-request-id (813ea74f...).

Журнал на стороне сервера также включает другую запись с тем же client-request-id значением (813ea74f...) для успешной операции удаления для одной и той же сущности и из того же клиента. Успешная операция удаления была выполнена непосредственно перед тем, как запрос на удаление завершился с ошибкой.

Наиболее вероятной причиной этого сценария является то, что клиент отправил запрос на удаление сущности в службу таблиц, которая завершилась успешно, но не получила подтверждения от сервера (возможно, из-за временной сетевой проблемы). Затем клиент автоматически извлек операцию (используя ту же client-request-id), и эта повторная попытка завершилась ошибкой, так как сущность уже была удалена.

Если вы часто сталкиваетесь с этой проблемой, попытайтесь выяснить, почему клиент не получает подтверждений от службы таблиц. Если проблема не постоянна, вам нужно обработать ошибку «HTTP (404) — не найдено» и внести ее в журнал клиента, но позволить клиенту продолжить работу.

Клиент получает сообщения HTTP 409 (конфликт)

В следующей таблице показано извлечение из журнала на стороне сервера для двух клиентских операций: DeleteIfExists за которым следует немедленно CreateIfNotExists использовать одно и то же имя контейнера BLOB-объектов. Каждая операция клиента приводит к двум запросам, отправленным серверу, сначала GetContainerProperties запрос на проверку наличия контейнера, за которым следует DeleteContainer или CreateContainer запрос.

Метка времени Операция Результат Имя контейнера Идентификатор запроса клиента
05:10:13.7167225 GetContainerProperties 200 mmcont c9f52c89-
05:10:13.8167325 DeleteContainer 202 mmcont c9f52c89-
05:10:13.8987407 GetContainerProperties 404 mmcont bc881924-
5:10:14.2147723 CreateContainer 409 mmcont bc881924-

Код в клиентском приложении удаляется, а затем немедленно создает контейнер BLOB-объектов с тем же именем: CreateIfNotExists метод (идентификатор запроса клиента bc881924-...) в конечном итоге завершается ошибкой HTTP 409 (конфликт). Когда клиент удаляет контейнеры больших двоичных объектов, таблицы или очереди, перед тем как имя станет доступным снова, существует короткий период.

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

Метрики отображают низкое значение PercentSuccess или в записях журналов аналитики присутствуют операции с состоянием транзакции ClientOtherErrors

В метрике PercentSuccess (Процент удачных завершений) фиксируется доля успешно завершенных операций с учетом кода состояния HTTP. Операции с кодами состояния 2XX счетчика как успешные, в то время как операции с кодами состояния в 3XX, 4XX и диапазонах 5XX считаются неудачными и ниже значения метрик PercentSuccess . В файлах журналов хранилища на стороне сервера такие операции отображаются с состоянием транзакции ClientOtherErrors(Другие ошибки клиента).

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

  • ResourceNotFound (Не найден 404), например, из запроса на большой двоичный GET объект, который не существует.
  • ResourceAlreadyExists (Конфликт 409), например из CreateIfNotExist операции, в которой ресурс уже существует.
  • ConditionNotMet (Not Modified 304), например из условной операции, например, когда клиент отправляет ETag значение и заголовок HTTP If-None-Match для запроса изображения, только если он был обновлен с момента последней операции.

Вы можете найти список распространенных кодов ошибок REST API, возвращаемых службами хранилища на странице Распространенные коды ошибок REST API.

Метрики объема показывают неожиданный рост потребления объема хранилища

Если вы видите внезапные непредвиденные изменения в использовании емкости в учетной записи хранения, вы можете изучить причины, сначала взглянув на метрики доступности; Например, увеличение количества неудачных запросов на удаление может привести к увеличению объема хранилища BLOB-объектов, используемого в качестве операций очистки для конкретного приложения, которые, возможно, не будут работать должным образом (например, поскольку маркеры SAS, используемые для освобождения места, истекли).

Проблема связана с использованием эмулятора хранения на этапе разработки или тестирования

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

Функция X не работает в эмуляторе хранения

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

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

При использовании эмулятора хранения возникает ошибка, связанная с неправильным форматом значения одного из заголовков HTTP

Вы тестируете приложение, использующее клиентская библиотека хранилища для локального эмулятора хранения, и вызовы методов, такие как CreateIfNotExists сбой с сообщением об ошибке "Значение для одного из заголовков HTTP не соответствует правильному формату". Это означает, что используемая версия эмулятора хранилища не поддерживает версию клиентской библиотеки хранилища, которую вы используете. Клиентская библиотека хранилища добавляет заголовок x-ms-version ко всем выполняемым запросам. Если эмулятор хранилища не распознает значение в заголовке x-ms-version , он отклоняет запрос.

Журналы клиента библиотеки хранилища можно использовать для просмотра значения отправки x-ms-version header . Можно также увидеть значение x-ms-version header , если вы используете Fiddler для трассировки запросов из клиентского приложения.

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

Для запуска эмулятора хранения требуются права администратора

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

Дополнительные сведения см. в статье Использование эмулятора хранения Azure для разработки и тестирования. Чтобы инициализировать эмулятор хранения в Visual Studio, вам также потребуются права администратора.

При установке пакета SDK для Azure для .NET возникают проблемы

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

  • CAQuietExec. Ошибка: не удалось получить доступ к экземпляру SQL
  • CAQuietExec. Ошибка: не удалось создать базу данных

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

sqllocaldb stop v11.0
sqllocaldb delete v11.0
delete %USERPROFILE%\WAStorageEmulatorDb3*.*
sqllocaldb create v11.0

Команда delete удаляет все старые файлы базы данных из предыдущих установок эмулятора хранения.

Со службой хранилища возникла другая проблема

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

  • Проверьте метрики, чтобы узнать, изменилось ли поведение ожидаемых базовых показателей. Из метрик вы можете определить, является ли проблема временной или постоянной, и какие операции хранения влияют на проблему.
  • Значения метрик могут помочь в поиске более подробной информации о возникающих ошибках в журналах на стороне сервера. Эта информация может помочь в диагностировании и устранении проблемы.
  • Если сведения в журналах на стороне сервера недостаточно для устранения проблемы, можно использовать клиентские журналы клиентской библиотеки хранилища для изучения поведения клиентского приложения клиента и таких средств, как Fiddler и Wireshark для изучения сети.

Дополнительные сведения об использовании Fiddler см . в приложении 1. Использование Fiddler для записи трафика HTTP и HTTPS.

Дополнительные сведения об использовании Wireshark см . в приложении 2. Использование Wireshark для записи сетевого трафика.

Приложения

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

Приложение 1. Отслеживание HTTP- и HTTPS-трафика с помощью Fiddler

Fiddler — это полезное средство для анализа трафика HTTP и HTTPS между клиентским приложением и службой хранилища Azure, которую вы используете.

Примечание.

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

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

После запуска средства Fiddler оно начинает захват трафика HTTP и HTTPS на локальном компьютере. Вот некоторые полезные команды для управления Fiddler:

  • Остановка и запуск захвата трафика. В главном меню перейдите к файлу , а затем выберите "Записать трафик ", чтобы включить и отключить запись.
  • Сохранение захваченных данных трафика. В главном меню выберите "Файл", нажмите кнопку "Сохранить", а затем выберите "Все сеансы". Это позволяет сохранить трафик в файле архива сеансов. Вы можете перезагрузить архив сеансов позже для анализа или отправить его при запросе в службу поддержки Майкрософт.

Чтобы ограничить объем трафика, который фиксирует Fiddler, можно использовать фильтры, настроенные на вкладке "Фильтры ". На следующем снимке экрана показан фильтр, который записывает только трафик, отправленный в конечную точку contosoemaildist.table.core.windows.net хранилища:

Снимок экрана: фильтр, который позволяет захватывать только трафик, отправляемый в конечную точку хранилища contosoemaildist.table.core.windows.net.

Приложение 2. Отслеживание сетевого трафика с помощью Wireshark

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

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

  1. Запустите Wireshark на локальном компьютере.

  2. В разделе Start (Запуск) выберите локальный сетевой интерфейс или интерфейсы, подключенные к Интернету.

  3. Выберите "Параметры записи".

  4. В текстовом поле Capture Filter (Фильтр захвата) добавьте фильтр. Например, host contosoemaildist.table.core.windows.net настроит Wireshark запись только пакетов, отправленных в конечную точку службы таблиц в учетной записи хранения contosoemaildist . Ознакомьтесь с полным списком фильтров захвата.

    Снимок экрана: добавление фильтра в текстовое поле

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

  6. По завершении нажмите кнопку "Остановить запись>" в главном меню.

  7. Чтобы сохранить захваченные данные в файле записи Wireshark, выберите "Сохранить файл>" в главном меню.

Обнаруженные ошибки будут выделены в окне со списком пакетов WireShark. Вы также можете использовать окно сведений эксперта (выберите "Анализ>сведений эксперта") для просмотра сводки ошибок и предупреждений.

Снимок экрана: окно

Кроме того, вы можете просмотреть данные TCP так, как они видны прикладному уровню. Для этого щелкните данные TCP правой кнопкой мыши и выберите пункт Отслеживать поток TCP. Это полезно в том случае, если дамп был получен без использования фильтра захвата. Дополнительные сведения см. в разделе Following TCP Streams (Отслеживание потоков TCP).

Снимок экрана: просмотр данных о протоколе TCP на уровне приложения.

Примечание.

Дополнительную информацию об использовании Wireshark см. в руководстве пользователя Wireshark.

Приложение 4. Просмотр метрик и данных журналов с помощью Excel

Многие средства позволяют загружать данные метрик хранилища из хранилища таблиц Azure в формате с разделителями. Данные в таком формате можно легко загрузить в Excel для просмотра и анализа. Данные журналов хранилища, полученные из Хранилища BLOB-объектов Azure, уже представлены в формате с разделителями, и их можно загрузить в Excel. Однако необходимо добавить соответствующие заголовки столбцов на основе сведений в формате журнала Аналитика Службы хранилища и схеме таблицы метрик Аналитика Службы хранилища.

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

  • В меню "Данные" выберите "Из текста".
  • Перейдите к файлу журнала, который вы хотите просмотреть, и нажмите кнопку "Импорт".
  • На шаге 1 мастера импорта текста выберите разделители.

На шаге 1 мастера импорта текста выберите точку с запятой в качестве единственного разделителя и выберите двойную кавычку в качестве квалификатора текста. Затем нажмите кнопку "Готово " и выберите место размещения данных в книге.

Приложение 5. Мониторинг с использованием Application Insights для Azure DevOps

Вы также можете использовать компонент Application Insights для Azure DevOps при мониторинге производительности и доступности. Это средство предоставляет указанные ниже возможности.

  • Проверка того, что веб-служба доступна и отвечает на запросы. Независимо от того, является ли ваше приложение веб-сайтом или приложением устройства, использующим веб-службу, он может тестировать URL-адрес каждые несколько минут от расположений по всему миру и сообщить вам, есть ли проблема.
  • Быстрая диагностика любых проблем с производительностью или исключений в веб-службе. Определяйте, не исчерпаны ли ресурсы ЦП и другие ресурсы, получайте данные трассировки стека исключений и легко выполняйте поиск по журналам трассировки. Если производительность приложения опустится ниже допустимого предела, мы можем оповестить вас по электронной почте. Вы можете отслеживать веб-службы .NET и Java.

Дополнительные сведения см. в статье Что такое Azure Application Insights?

Следующие шаги

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

Заявление об отказе от ответственности за сведения о продуктах сторонних производителей

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

Свяжитесь с нами для получения помощи

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