Inzicht in de HTTP-pijplijn en herhalingspogingen in de Azure SDK voor Python

Wanneer u een aanroep uitvoert naar een Azure-service met behulp van de Azure SDK voor Python, gaat uw aanvraag niet rechtstreeks naar de Azure-service. Het maakt niet uit of het Azure Blob Storage, Azure Key Vault, Azure Cosmos DB of een andere HTTP-service is. In plaats daarvan loopt uw aanvraag via een geavanceerde HTTP-pijplijn die kritieke kruislingse problemen automatisch afhandelt.

Begrijpen hoe de HTTP-pijplijn werkt, is essentieel voor het bouwen van robuuste en krachtige toepassingen. De pijplijn:

  • Beheert herhaalde pogingen voor tijdelijke fouten.
  • Hiermee wordt verificatie afgehandeld.
  • Biedt mogelijkheden voor logboekregistratie.
  • Hiermee kunt u aangepast gedrag toevoegen wanneer dat nodig is.

Deze kennis helpt u bij het opsporen van prestatieproblemen, het optimaliseren van tolerantie en het aanpassen van de interactie van uw toepassing met Azure-services.

Wat is de HTTP-pijplijn?

De Azure SDK voor Python maakt gebruik van een interne HTTP-pijplijnarchitectuur om alle aanvragen en antwoorden te verwerken. Deze pijplijn bestaat uit een reeks beleidsregels die op volgorde worden uitgevoerd. Elk beleid is verantwoordelijk voor een specifiek aspect van de HTTP-communicatie. U kunt de pijplijn beschouwen als een keten van verwerkingsstappen:

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

Elk beleid in de pijplijn kan het volgende doen:

  • Wijzig de aanvraag voordat deze wordt verzonden.
  • Het antwoord verwerken nadat het is ontvangen.
  • Voer acties uit, zoals het opnieuw proberen van mislukte aanvragen.
  • Voeg headers, logboekgegevens toe of implementeer aangepaste logica.

Sleutelbeleid in de pijplijn

De Azure SDK voor Python bevat verschillende ingebouwde beleidsregels die algemene scenario's verwerken:

  • RetryPolicy: Probeert automatisch opnieuw verzoeken die mislukken door tijdelijke fouten. Dit beleid implementeert intelligente logica voor opnieuw proberen met exponentieel uitstel om overweldigende services tijdens storingen te voorkomen.
  • BearerTokenCredentialPolicy: hiermee beheert u verificatie door automatisch toegangstokens te verkrijgen en te vernieuwen. Dit beleid zorgt ervoor dat uw aanvragen geldige verificatiereferenties bevatten zonder handmatig tokenbeheer.
  • NetworkTraceLoggingPolicy: legt gedetailleerde informatie vast over HTTP-aanvragen en -antwoorden voor foutopsporingsdoeleinden. Dit beleid is van groot belang wanneer u communicatieproblemen oplost.
  • HttpTransport: De laagste laag van de pijplijn die HTTP-aanvragen daadwerkelijk via het netwerk verzendt. In de Azure SDK voor Python wordt dit beleid doorgaans geïmplementeerd met behulp van aanvragen of aiohttp voor asynchrone bewerkingen.

Ander beleid

  • RedirectPolicy: verwerkt HTTP-omleidingen automatisch.
  • DistributedTracingPolicy: integreert met gedistribueerde traceringssystemen voor bewaking.
  • ProxyPolicy: routes aanvragen via HTTP-proxy's wanneer deze zijn geconfigureerd.
  • UserAgentPolicy: Voegt SDK-versiegegevens toe om headers aan te vragen.

Gedrag voor opnieuw proberen

De Azure SDK voor Python implementeert intelligente logica voor opnieuw proberen om tijdelijke fouten automatisch af te handelen. Als u dit gedrag begrijpt, kunt u tolerantere toepassingen bouwen.

Voorwaarden die automatisch opnieuw zijn geprobeerd

De SDK probeert aanvragen voor deze HTTP-statuscodes opnieuw uit te voeren:

  • 408 Verzoek Time-out: De server heeft gewacht op de aanvraag en is daardoor in de time-out gegaan.
  • 429 Te veel aanvragen: snelheidsbeperking is van kracht.
  • 500 Interne serverfout: tijdelijk serverprobleem.
  • 502 Ongeldige gateway: tijdelijk netwerkprobleem.
  • 503 Service niet beschikbaar: Service tijdelijk niet beschikbaar.
  • 504 Gateway Time-out: Uitvaltijd limiet van een gateway of proxy.

Standaardconfiguratie voor opnieuw proberen

De standaardinstellingen voor opnieuw proberen bieden een goede balans tussen tolerantie en prestaties:

  • Maximum aantal nieuwe pogingen: 3
  • Opnieuw proberen-modus: Exponentiële back-off
  • Basisvertraging: 0,8 seconden
  • Maximale vertraging: 60 seconden
  • Maximale totale tijd voor opnieuw proberen: 120 seconden

De exponentiële uitstelberekening volgt dit patroon:

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

Herhalingspogingen aanpassen

U kunt het gedrag van nieuwe pogingen aanpassen wanneer u SDK-clients maakt die overeenkomen met de specifieke vereisten van uw toepassing.

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
)

Herhalingen uitschakelen

Voor scenario's waarbij nieuwe pogingen niet geschikt zijn:

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
)

Gedrag voor opnieuw proberen vaststellen en fouten opsporen

Inzicht in wanneer en waarom nieuwe pogingen optreden, is van cruciaal belang voor het oplossen van prestatieproblemen.

SDK-logboekregistratie inschakelen

De Azure SDK voor Python maakt gebruik van het standaardframework voor logboekregistratie van 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

Identificeer herhaalpatronen

Zoek naar logboekvermeldingen zoals:

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

Veelvoorkomende valkuilen voor nieuwe pogingen

  • Niet-tijdelijke fouten opnieuw proberen: De SDK probeert clientfouten (4xx) niet opnieuw, met uitzondering van 408 en 429.
  • Latentie voor opnieuw proberen wordt genegeerd: Vergeet niet dat nieuwe pogingen latentie toevoegen aan mislukte bewerkingen.
  • Onvoldoende time-out instellen: Zorg ervoor dat uw totale bewerkingstime-out rekening houdt met vertragingen door opnieuw proberen.

Geavanceerd: Aangepast beleid toevoegen

U kunt de pijplijn uitbreiden met aangepast beleid voor gespecialiseerde scenario's.

Aangepast beleid maken

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

Aangepast beleid toepassen

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
)

Volgorde van beleid

Beleidsregels worden uitgevoerd in een specifieke volgorde:

  • Beleid per aanroep (één keer per bewerking uitvoeren).
  • Beleid voor opnieuw proberen.
  • Beleid per nieuwe poging (wordt uitgevoerd bij elke poging).
  • Verificatiebeleid.
  • HTTP-transport.

Beste praktijken

Standaardinstellingen gebruiken indien mogelijk

De standaardconfiguratie voor opnieuw proberen werkt goed voor de meeste scenario's. Pas alleen aan wanneer u specifieke vereisten hebt.

Aanpassingsrichtlijnen

Wanneer u het gedrag voor opnieuw proberen aanpast:

  • Exponentieel uitstel gebruiken: Gebruik dit om overweldigende services tijdens het herstel te voorkomen.
  • Stel redelijke limieten in: Beperk de totale wachttijd voor nieuwe pogingen om onbepaalde wachttijd te voorkomen.
  • Metrische gegevens voor opnieuw proberen bewaken: Volg de frequenties voor nieuwe pogingen in productie om problemen te identificeren.
  • Overweeg circuitonderbrekers: Implementeer circuitonderbrekerpatronen voor scenario's met grote volumes.

Wat u niet opnieuw moet proberen

Vermijd het opnieuw proberen van deze typen fouten:

  • Verificatiefouten (401, 403): Verificatiefouten vereisen het herstellen van referenties, niet opnieuw proberen.
  • Clientfouten (400, 404): Clientfouten geven problemen aan met de aanvraag zelf.
  • Bedrijfslogicafouten: Toepassingsspecifieke fouten die niet worden opgelost met nieuwe pogingen.

Operationele uitmuntendheid

  • Correlatie-id's voor logboeken: Opnemen x-ms-client-request-id in logboeken voor Azure-ondersteuning.
  • Stel de juiste time-outs in: Balans tussen betrouwbaarheid en gebruikerservaring.
  • Gedrag voor opnieuw proberen testen: Controleer of uw toepassing nieuwe pogingen correct afhandelt.
  • Prestaties bewaken: Houd P95/P99-latenties (metrische latentiegegevens op basis van percentiel) bij, inclusief overhead voor opnieuw proberen.

Verwante inhoud

  • Laatst bijgewerkt om