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

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

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

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

Обзор

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

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

Как организовано это руководство

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Емкость мониторинга

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

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

Мониторинг доступности

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

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

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

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

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

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

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

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

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

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

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

Существует несколько способов узнать о проблеме или проблеме в приложении, в том числе:

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

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

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

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

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

Работоспособность служб проблемы обычно находятся вне вашего контроля. В портал Azure содержатся сведения о любых текущих проблемах со службами Azure, включая службы хранилища. Если вы выбрали хранилище Read-Access Geo-Redundant при создании учетной записи хранения, то если данные становятся недоступными в основном расположении, приложение может временно переключиться на копию только для чтения в дополнительном расположении. Чтобы считывать данные из дополнительного хранилища, приложение должно иметь возможность переключаться между основным и дополнительным расположениями хранилища и работать в режиме ограниченной функциональности с данными только для чтения. Клиентские библиотеки службы хранилища Azure позволяют определить политику повторных попыток, которая может считывать данные из дополнительного хранилища в случае сбоя чтения из первичного хранилища. Приложение также должно учитывать, что данные в дополнительном расположении в конечном итоге согласованы. Дополнительные сведения см. в записи блога Параметры избыточности службы хранилища Azure и Геоизбыточное хранилище для чтения.

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

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

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

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

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

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

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

• Распространенные коды ошибок REST API
• Коды ошибок службы BLOB-объектов
• Коды ошибок службы очередей
• Коды ошибок службы таблиц
• Коды ошибок службы файлов

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

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

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

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

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

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

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

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

• Fiddler — это бесплатный прокси-сервер для веб-отладки, который позволяет просматривать заголовки и полезные данные http и HTTPS-сообщений запросов и ответов. Дополнительные сведения см. в приложении 1. Использование Fiddler для отслеживания трафика HTTP и HTTPS.
• Microsoft Network Monitor (Netmon) и Wireshark — это бесплатные анализаторы сетевых протоколов, которые позволяют просматривать подробные сведения о пакетах для широкого спектра сетевых протоколов. Дополнительные сведения о Wireshark см. в приложении 2. Использование Wireshark для сбора сетевого трафика.
• Если вы хотите выполнить простую проверку подключения, чтобы проверка, что клиентский компьютер может подключаться к службе хранилища Azure по сети, это невозможно сделать с помощью стандартного средства проверки связи на клиенте. Однако для проверка подключения можно использовать средство 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();
    }
}

//Parse the connection string for the storage account.
const string ConnectionString = "DefaultEndpointsProtocol=https;AccountName=account-name;AccountKey=account-key";
CloudStorageAccount storageAccount = CloudStorageAccount.Parse(ConnectionString);
CloudBlobClient blobClient = storageAccount.CreateCloudBlobClient();

// Create an Operation Context that includes custom ClientRequestId string based on constants defined within the application along with a Guid.
OperationContext oc = new OperationContext();
oc.ClientRequestID = String.Format("{0} {1} {2} {3}", HOSTNAME, APPNAME, USERID, Guid.NewGuid().ToString());

try
{
    CloudBlobContainer container = blobClient.GetContainerReference("democontainer");
    ICloudBlob blob = container.GetBlobReferenceFromServer("testImage.jpg", null, null, oc);  
    var downloadToPath = string.Format("./{0}", blob.Name);
    using (var fs = File.OpenWrite(downloadToPath))
    {
        blob.DownloadToStream(fs, null, null, oc);
        Console.WriteLine("\t Blob downloaded to file: {0}", downloadToPath);
    }
}
catch (StorageException storageException)
{
    Console.WriteLine("Storage exception {0} occurred", storageException.Message);
    // Multiple results may exist due to client side retry logic - each retried operation will have a unique ServiceRequestId
    foreach (var result in oc.RequestResults)
    {
            Console.WriteLine("HttpStatus: {0}, ServiceRequestId {1}", result.HttpStatusCode, result.ServiceRequestID);
    }
}

Временные метки

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

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

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

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

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

• Метрики показывают высокий показатель AverageE2ELatency и низкий AverageServerLatency.
• Метрики показывают низкие значения AverageE2ELatency и Low AverageServerLatency, но у клиента наблюдается большая задержка.
• Метрики показывают высокий уровень AverageServerLatency.
• Возникают непредвиденные задержки при доставке сообщений в очередь.

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

• Метрики показывают увеличение процентаThrottlingError.
• Метрики показывают увеличение percentTimeoutError.
• Метрики показывают увеличение процентаNetworkError.

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

• Клиент получает сообщения HTTP 403 (запрещено).
• Клиент получает сообщения HTTP 404 (не найдено).
• Клиент получает сообщения HTTP 409 (конфликт).

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

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

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

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

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

Метрики показывают высокий средний показательE2ELatency и низкий СреднийСерверЛатентность

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

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

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

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

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

var connectionString = Constants.connectionString;

QueueServiceClient queueServiceClient = new QueueServiceClient(connectionString);

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

var storageAccount = CloudStorageAccount.Parse(connStr);
ServicePoint queueServicePoint = ServicePointManager.FindServicePoint(storageAccount.QueueEndpoint);
queueServicePoint.UseNagleAlgorithm = false;

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

Изучение проблем с задержкой сети

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

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

Метрики показывают низкие значения AverageE2ELatency и low AverageServerLatency, но у клиента наблюдается большая задержка.

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

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

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

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

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

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

Метрики показывают высокий уровень AverageServerLatency

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

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

Значения High AverageServerLatency также могут быть признаком плохо спроектированных таблиц или запросов, которые приводят к операциям сканирования или следуют шаблону добавления или предварительного добавления. Дополнительные сведения см. в разделе Метрики показывают увеличение ПроцентаThrottlingError.

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

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

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

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

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

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

• Временное увеличение в PercentThrottlingError
• Постоянное увеличение ошибки PercentThrottlingError

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

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

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

Постоянное увеличение PercentThrottlingError

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Клиент или другой процесс ранее удалил объект .
• Проблема с авторизацией подписанного URL-адреса (SAS).
• Клиентский код JavaScript не имеет разрешения на доступ к объекту.
• Сбой сети.

Клиент или другой процесс ранее удалил объект

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы обойти проблему JavaScript, можно настроить общий доступ к ресурсам между источниками (CORS) для службы хранилища, к ней обращается клиент. Дополнительные сведения см. в статье Поддержка общего доступа к ресурсам между источниками (CORS) для служб хранилища Azure.

В следующем примере кода показано, как настроить службу BLOB-объектов, чтобы разрешить JavaScript, работающему в домене Contoso, доступ к BLOB-объекту в службе хранилища 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);

CloudBlobClient client = new CloudBlobClient(blobEndpoint, new StorageCredentials(accountName, accountKey));
// Set the service properties.
ServiceProperties sp = client.GetServiceProperties();
sp.DefaultServiceVersion = "2013-08-15";
CorsRule cr = new CorsRule();
cr.AllowedHeaders.Add("*");
cr.AllowedMethods = CorsHttpMethods.Get | CorsHttpMethods.Put;
cr.AllowedOrigins.Add("http://www.contoso.com");
cr.ExposedHeaders.Add("x-ms-*");
cr.MaxAgeInSeconds = 5;
sp.Cors.CorsRules.Clear();
sp.Cors.CorsRules.Add(cr);
client.SetServiceProperties(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) Not Found" и записать ее в клиент, но разрешить клиенту продолжить работу.

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

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

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

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

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

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

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

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

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

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

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

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

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

• Функция "X" не работает в эмуляторе хранения.
• Ошибка "Значение для одного из заголовков HTTP не в правильном формате" при использовании эмулятора хранения.
• Для запуска эмулятора хранения требуются права администратора.

Функция "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, для чего также потребуются права администратора.

Возникают проблемы с установкой пакета Azure SDK для .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. Использование Fiddler для сбора трафика HTTP и HTTPS

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

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

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

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

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

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

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

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

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

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

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

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

   

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

6. По завершении выберите Пункт Остановить запись> в меню main.

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

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

Вы также можете просмотреть данные TCP по мере их просмотра на уровне приложения, щелкнув правой кнопкой мыши данные TCP и выбрав Пункт Следовать tcp-Stream. Это полезно, если вы захватили дамп без фильтра записи. Дополнительные сведения см. в разделе Следующие потоки TCP.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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