Руководство по устранению неполадок с использованием метрик хранилища Azure

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

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

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

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

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

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

Медленный ответ

Если запрос занимает слишком много времени, его необходимо изучить. Просмотрите значения двух параметров, называемых AverageE2ELatency и AverageServerLatency.

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

Всегда значение AverageE2ELatency будет выше, чем значение AverageServerLatency, но иногда разница может быть очень большой. Например, если время AverageServerLatency составляет 2,17 минуты, а значение AverageE2ELatency — 32,40 минуты, значит, что-то определенно не так.

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

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

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

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

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

Неожиданные задержки в доставке сообщений

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

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

Ошибки регулирования

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

Чтобы определить ошибку регулирования, посмотрите на метрику PercentThrottlingError, которая покажет количество запросов, которые не удалось выполнить с регулированием. Если вы отслеживаете значение этой метрики, вы увидите, что оно увеличивается только тогда, когда количество запросов к хранилищу значительно увеличивается. Иногда он также может возвращать клиенту сообщение «503 Server Busy» или «500 Operation Time Out».

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

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

Сетевые ошибки

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

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

Итак, вот некоторые из распространенных проблем, которые вы можете решить, просмотрев метрики хранилища Azure.

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

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