Общие сведения о конвейере HTTP и повторных попытках в пакете SDK Azure для Python

При вызове любой службы Azure с помощью пакета AZURE SDK для Python запрос не переходит непосредственно в службу Azure. Это не имеет значения, является ли это хранилище BLOB-объектов Azure, Azure Key Vault, Azure Cosmos DB или любая другая служба на основе HTTP. Вместо этого запрос выполняется через сложный конвейер HTTP, который автоматически обрабатывает критически важные перекрестные проблемы.

Понимание того, как работает конвейер HTTP, является важным для создания надежных и эффективных приложений. Конвейер:

  • Управляет повторными попытками в случае временных сбоев.
  • Обрабатывает проверку подлинности.
  • Предоставляет возможности ведения журнала.
  • Позволяет добавлять настраиваемое поведение при необходимости.

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

Что такое конвейер HTTP?

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

Client Request → Retry Policy → Authentication Policy → Logging Policy → HTTP Transport → Azure Service
                                                                                              ↓
Client Response ← Retry Policy ← Authentication Policy ← Logging Policy ← HTTP Transport ← Response

Каждая политика в конвейере может:

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

Ключевые политики в конвейере

Пакет SDK Azure для Python включает несколько встроенных политик, которые обрабатывают распространенные сценарии:

  • RetryPolicy: автоматически повторяет запросы, которые завершаются сбоем из-за временных ошибок. Эта политика реализует интеллектуальную логику повторных попыток с экспоненциальным обратным выходом, чтобы избежать подавляющие службы во время сбоев.
  • BearerTokenCredentialPolicy: управляет аутентификацией путем автоматического получения и обновления токенов доступа. Эта политика гарантирует, что ваши запросы включают допустимые аутентификационные данные без ручного управления токенами.
  • NetworkTraceLoggingPolicy: записывает подробные сведения о HTTP-запросах и ответах в целях отладки. Эта политика является бесценной при устранении неполадок связи.
  • HttpTransport: самый низкий уровень конвейера, который фактически отправляет HTTP-запросы по сети. В пакете SDK Azure для Python эта политика обычно реализуется с помощью запросов или aiohttp для асинхронных операций.

Другие политики

  • RedirectPolicy: автоматически обрабатывает перенаправления HTTP.
  • DistributedTracingPolicy: интегрируется с распределенными системами трассировки для мониторинга.
  • ProxyPolicy: маршрутизирует запросы через прокси-серверы HTTP при настройке.
  • UserAgentPolicy: добавляет сведения о версии пакета SDK в заголовки запросов.

Поведение повторных попыток

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

Автоматически извлекаемые условия

Пакет SDK повторяет запросы для следующих кодов состояния HTTP:

  • Время ожидания запроса 408. Время ожидания сервера истекло.
  • 429 слишком много запросов: ограничение скорости действует.
  • 500 Внутренняя ошибка сервера: проблема с временным сервером.
  • 502 Ошибочный шлюз: временная проблема с сетью.
  • Служба 503 недоступна: служба временно недоступна.
  • Время ожидания шлюза 504: время ожидания шлюза или прокси-сервера.

Конфигурация повторных попыток по умолчанию

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

  • Максимальные попытки повторных попыток: 3
  • Режим повтора: Экспоненциальная пауза между операциями
  • Базовая задержка: 0,8 секунды
  • Максимальная задержка: 60 секунд
  • Максимальное общее время повтора: 120 секунд

Вычисление экспоненциальной обратной передачи следует следующему шаблону:

delay = min(base_delay * (2 ** retry_attempt), max_delay)

Настройка повторных попыток

Вы можете настроить поведение повторных попыток при создании клиентов ПАКЕТА SDK в соответствии с конкретными требованиями приложения.

from azure.storage.blob import BlobServiceClient
from azure.core.pipeline.policies import RetryPolicy

# Custom retry configuration
retry_policy = RetryPolicy(
    retry_total=5,                    # Maximum number of retry attempts
    retry_backoff_factor=0.5,         # Base backoff time in seconds
    retry_backoff_max=120,            # Maximum backoff time in seconds
    retry_on_status_codes=[429, 500, 502, 503, 504]  # HTTP status codes to retry
)

# Apply custom retry policy to client
client = BlobServiceClient(
    account_url="https://myaccount.blob.core.windows.net",
    credential=credential,
    retry_policy=retry_policy
)

Отключение повторных попыток

В сценариях, когда повторные попытки не подходит:

from azure.core.pipeline.policies import RetryPolicy

# Disable retries completely
no_retry_policy = RetryPolicy(retry_total=0)

client = BlobServiceClient(
    account_url="https://myaccount.blob.core.windows.net",
    credential=credential,
    retry_policy=no_retry_policy
)

Диагностика и отладка поведения повторных попыток

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

Включение ведения журнала пакета SDK

Пакет SDK Azure для Python использует стандартную платформу ведения журналов Python:

import logging
import sys

# Configure logging to see retry attempts
logging.basicConfig(
    level=logging.DEBUG,
    format='%(asctime)s - %(name)s - %(levelname)s - %(message)s',
    stream=sys.stdout
)

# Enable specific Azure SDK loggers
azure_logger = logging.getLogger('azure')
azure_logger.setLevel(logging.DEBUG)

# Now SDK operations will log retry attempts

Определение шаблонов повторных попыток

Найдите такие записи журнала, как:

Retry attempt 1 for request [GET] https://myaccount.blob.core.windows.net/container/blob
Waiting 0.8 seconds before retry

Распространенные ошибки повторных попыток

  • Повторная попытка ошибок, не являющихся временными: Пакет SDK не повторяет ошибки клиента (4xx), кроме 408 и 429.
  • Игнорирование задержки повторных попыток: Помните, что повторные попытки добавляют задержку к неудачным операциям.
  • Нехватка времени ожидания: Убедитесь, что общая продолжительность времени ожидания операции учитывает задержки повторных попыток.

Дополнительно: добавление настраиваемых политик

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

Создание настраиваемой политики

from azure.core.pipeline import PipelineRequest, PipelineResponse
from azure.core.pipeline.policies import HTTPPolicy
from typing import Any, Optional

class CustomTelemetryPolicy(HTTPPolicy):
    """Custom policy to add telemetry headers"""
    
    def send(self, request: PipelineRequest) -> PipelineResponse:
        # Add custom header before sending request
        request.http_request.headers['X-Custom-Telemetry'] = 'my-app-v1.0'
        
        # Continue with the pipeline
        response = self.next.send(request)
        
        # Log response time
        print(f"Request to {request.http_request.url} completed")
        
        return response

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

from azure.storage.blob import BlobServiceClient

# Create client with custom policy
client = BlobServiceClient(
    account_url="https://myaccount.blob.core.windows.net",
    credential=credential,
    per_call_policies=[CustomTelemetryPolicy()],  # Policies that run per request
    per_retry_policies=[]  # Policies that run per retry attempt
)

Упорядочение политик

Политики выполняются в определенном порядке:

  • Политики на каждый вызов (выполняются один раз для каждой операции).
  • Политика повторных попыток.
  • Настройки повторных попыток (выполняются при каждой попытке).
  • Политика проверки подлинности.
  • Транспорт HTTP.

Лучшие практики

Используйте параметры по умолчанию, если это возможно

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

Рекомендации по настройке

Когда вы настраиваете поведение повторных попыток:

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

Что не повторить

Не используйте следующие типы ошибок:

  • Сбои проверки подлинности (401, 403): Ошибки проверки подлинности требуют исправления учетных данных, а не повторных попыток.
  • Ошибки клиента (400, 404): Ошибки клиента указывают на проблемы с самим запросом.
  • Ошибки бизнес-логики: Ошибки, связанные с приложением, которые не разрешаются с повторными попытками.

Эффективность работы

  • Идентификаторы корреляции журналов: Включите x-ms-client-request-id в журналы для поддержки Azure.
  • Задайте соответствующие тайм-ауты: Баланс между надежностью и взаимодействием с пользователем.
  • Тестирование поведения повторных попыток: Убедитесь, что ваше приложение корректно обрабатывает повторные попытки.
  • Мониторинг производительности: Отслеживайте задержки P95/P99 (метрики задержки на основе процентили), включая затраты на повторные попытки.

Связанный контент

  • Последнее обновление: