Dela via

Återhämtning för tjänstidentifiering (förhandsversion)

  • Artikel

Med Azure Container Apps återhämtning kan du proaktivt förhindra, identifiera och återställa från fel med tjänstbegäran med hjälp av enkla återhämtningsprinciper. I den här artikeln får du lära dig hur du konfigurerar principer för återhämtning i Azure Container Apps när du initierar begäranden med azure Container Apps-tjänstidentifiering.

Kommentar

För närvarande kan återhämtningsprinciper inte tillämpas på begäranden som görs med dapr-tjänstens anrops-API.

Principer gäller för varje begäran till en containerapp. Du kan skräddarsy principer för containerappen som tar emot begäranden med konfigurationer som:

  • Antalet återförsök
  • Varaktighet för återförsök och tidsgräns
  • Försök matcha igen
  • Kretsbrytare på varandra följande fel och andra

Följande skärmbild visar hur ett program använder en återförsöksprincip för att försöka återställa från misslyckade begäranden.

Diagram som visar containerappens återhämtning för containerappen med hjälp av en containerapps tjänstnamn.

Återhämtningsprinciper som stöds

Konfigurera återhämtningsprinciper

Oavsett om du konfigurerar återhämtningsprinciper med Bicep, CLI eller Azure-portalen kan du bara tillämpa en princip per containerapp.

När du tillämpar en princip på en containerapp tillämpas reglerna på alla begäranden som görs till containerappen, inte på begäranden som görs från containerappen. Till exempel tillämpas en återförsöksprincip på en containerapp med namnet App B. Alla inkommande begäranden som görs till App B försöker automatiskt igen vid fel. Utgående begäranden som skickas av App B är dock inte garanterade att försöka igen i fel.

Följande återhämtningsexempel visar alla tillgängliga konfigurationer.

resource myPolicyDoc 'Microsoft.App/containerApps/resiliencyPolicies@2023-11-02-preview' = {
  name: 'my-app-resiliency-policies'
  parent: '${appName}'
  properties: {
    timeoutPolicy: {
        responseTimeoutInSeconds: 15
        connectionTimeoutInSeconds: 5
    }
    httpRetryPolicy: {
        maxRetries: 5
        retryBackOff: {
          initialDelayInMilliseconds: 1000
          maxIntervalInMilliseconds: 10000
        }
        matches: {
            headers: [
                {
                    header: 'x-ms-retriable'
                    match: { 
                        exactMatch: 'true'
                    }
                }
            ]
            httpStatusCodes: [
                502
                503
            ]
            errors: [
                'retriable-status-codes'
                '5xx'
                'reset'
                'connect-failure'
                'retriable-4xx'
            ]
        }
    } 
    tcpRetryPolicy: {
        maxConnectAttempts: 3
    }
    circuitBreakerPolicy: {
        consecutiveErrors: 5
        intervalInSeconds: 10
        maxEjectionPercent: 50
    }
    tcpConnectionPool: {
        maxConnections: 100
    }
    httpConnectionPool: {
        http1MaxPendingRequests: 1024
        http2MaxRequests: 1024
    }
  }
}

Principspecifikationer

Timeouter

Tidsgränser används för att avsluta tidskrävande åtgärder tidigt. Tidsgränsprincipen innehåller följande egenskaper.

properties: {
  timeoutPolicy: {
      responseTimeoutInSeconds: 15
      connectionTimeoutInSeconds: 5
  }
}
Metadata Obligatoriskt Beskrivning Exempel
responseTimeoutInSeconds Ja Tidsgräns väntar på ett svar från containerappen. 15
connectionTimeoutInSeconds Ja Tidsgräns för att upprätta en anslutning till containerappen. 5

Försök

Definiera en tcpRetryPolicy eller en httpRetryPolicy strategi för misslyckade åtgärder. Återförsöksprincipen innehåller följande konfigurationer.

httpRetryPolicy

properties: {
    httpRetryPolicy: {
        maxRetries: 5
        retryBackOff: {
          initialDelayInMilliseconds: 1000
          maxIntervalInMilliseconds: 10000
        }
        matches: {
            headers: [
                {
                    header: 'x-ms-retriable'
                    match: { 
                       exactMatch: 'true'
                    }
                }
            ]
            httpStatusCodes: [
                502
                503
            ]
            errors: [
                'retriable-headers'
                'retriable-status-codes'
            ]
        }
    } 
}
Metadata Obligatoriskt Beskrivning Exempel
maxRetries Ja Maximalt antal återförsök som ska köras för en misslyckad http-begäran. 5
retryBackOff Ja Övervaka begäranden och stäng av all trafik till den påverkade tjänsten när tidsgränsen och återförsökskriterierna uppfylls. Ej tillämpligt
retryBackOff.initialDelayInMilliseconds Ja Fördröjning mellan det första felet och första återförsöket. 1000
retryBackOff.maxIntervalInMilliseconds Ja Maximal fördröjning mellan återförsök. 10000
matches Ja Ange matchningsvärden för att begränsa när appen ska försöka göra ett nytt försök. headers, , httpStatusCodeserrors
matches.headers Y* Försök igen när felsvaret innehåller ett specifikt huvud. *Rubriker är bara obligatoriska egenskaper om du anger felegenskapen retriable-headers . Läs mer om tillgängliga sidhuvudmatchningar. X-Content-Type
matches.httpStatusCodes Y* Försök igen när svaret returnerar en specifik statuskod. *Statuskoder är endast obligatoriska egenskaper om du anger felegenskapen retriable-status-codes . 502, 503
matches.errors Ja Försök endast igen när appen returnerar ett specifikt fel. Läs mer om tillgängliga fel. connect-failure, reset
Rubrikmatchningar

Om du angav retriable-headers felet kan du använda följande rubrikmatchningsegenskaper för att försöka igen när svaret innehåller en specifik rubrik.

matches: {
  headers: [
    { 
      header: 'x-ms-retriable'
      match: {
        exactMatch: 'true'
      }
    }
  ]
}
Metadata beskrivning
prefixMatch Återförsök utförs baserat på prefixet för huvudvärdet.
exactMatch Återförsök utförs baserat på en exakt matchning av rubrikvärdet.
suffixMatch Återförsök utförs baserat på suffixet för rubrikvärdet.
regexMatch Återförsök utförs baserat på en regel för reguljära uttryck där rubrikvärdet måste matcha regex-mönstret.
Fel

Du kan utföra återförsök på något av följande fel:

matches: {
  errors: [
    'retriable-headers'
    'retriable-status-codes'
    '5xx'
    'reset'
    'connect-failure'
    'retriable-4xx'
  ]
}
Metadata beskrivning
retriable-headers HTTP-svarshuvuden som utlöser ett nytt försök. Ett nytt försök utförs om någon av huvudmatchningarna matchar svarshuvudena. Krävs om du vill försöka igen på matchande rubriker.
retriable-status-codes HTTP-statuskoder som ska utlösa återförsök. Krävs om du vill försöka igen med matchande statuskoder.
5xx Försök igen om servern svarar med 5xx-svarskoder.
reset Försök igen om servern inte svarar.
connect-failure Försök igen om en begäran misslyckades på grund av en felaktig anslutning till containerappen.
retriable-4xx Försök igen om containerappen svarar med en svarskod i 400-serien, till exempel 409.

tcpRetryPolicy

properties: {
    tcpRetryPolicy: {
        maxConnectAttempts: 3
    }
}
Metadata Obligatoriskt Beskrivning Exempel
maxConnectAttempts Ja Ange maximalt antal anslutningsförsök (maxConnectionAttempts) för återförsök vid misslyckade anslutningar. 3

Kretsbrytare

Principer för kretsbrytare anger om en containerappreplik tillfälligt tas bort från belastningsutjämningspoolen, baserat på utlösare som antalet på varandra följande fel.

properties: {
    circuitBreakerPolicy: {
        consecutiveErrors: 5
        intervalInSeconds: 10
        maxEjectionPercent: 50
    }
}
Metadata Obligatoriskt Beskrivning Exempel
consecutiveErrors Ja På varandra följande antal fel innan en containerappreplik tillfälligt tas bort från belastningsutjämningen. 5
intervalInSeconds Ja Hur lång tid det tar att avgöra om en replik tas bort eller återställs från lastbalanspoolen. 10
maxEjectionPercent Ja Maximal procent av misslyckade containerapprepliker för att mata ut från belastningsutjämning. Tar bort minst en värd oavsett värde. 50

Anslutningspooler

Azure Container Apps anslutningspool underhåller en pool med etablerade och återanvändbara anslutningar till containerappar. Den här anslutningspoolen minskar kostnaderna för att skapa och ta bort enskilda anslutningar för varje begäran.

Med anslutningspooler kan du ange det maximala antalet begäranden eller anslutningar som tillåts för en tjänst. Dessa gränser styr det totala antalet samtidiga anslutningar för varje tjänst. När den här gränsen har nåtts upprättas inte nya anslutningar till den tjänsten förrän befintliga anslutningar släpps eller stängs. Den här processen med att hantera anslutningar förhindrar att resurser överbelastas av begäranden och upprätthåller effektiv anslutningshantering.

httpConnectionPool

properties: {
    httpConnectionPool: {
        http1MaxPendingRequests: 1024
        http2MaxRequests: 1024
    }
}
Metadata Obligatoriskt Beskrivning Exempel
http1MaxPendingRequests Ja Används för http1 begäranden. Maximalt antal öppna anslutningar till en containerapp. 1024
http2MaxRequests Ja Används för http2 begäranden. Maximalt antal samtidiga begäranden till en containerapp. 1024

tcpConnectionPool

properties: {
    tcpConnectionPool: {
        maxConnections: 100
    }
}
Metadata Obligatoriskt Beskrivning Exempel
maxConnections Ja Maximalt antal samtidiga anslutningar till en containerapp. 100

Återhämtningsobservabilitet

Du kan utföra återhämtningsobservabilitet via containerappens mått och systemloggar.

Återhämtningsloggar

I avsnittet Övervakning i containerappen väljer du Loggar.

Skärmbild som visar var du hittar loggarna för containerappen.

I fönstret Loggar skriver och kör du en fråga för att hitta återhämtning via systemloggarna för containerappen. Kör till exempel en fråga som liknar följande för att söka efter återhämtningshändelser och visa deras:

  • Tidstämpel
  • Miljönamn
  • Namn på containerapp
  • Återhämtningstyp och orsak
  • Loggmeddelanden
ContainerAppSystemLogs_CL
| where EventSource_s == "Resiliency"
| project TimeStamp_s, EnvironmentName_s, ContainerAppName_s, Type_s, EventSource_s, Reason_s, Log_s

Klicka på Kör för att köra frågan och visa resultat.

Skärmbild som visar frågeresultat för återhämtning baserat på det angivna frågeexemplet.

Återhämtningsmått

På menyn Övervakning i containerappen väljer du Mått. I fönstret Mått väljer du följande filter:

  • Omfånget för namnet på containerappen.
  • Namnrymden standardmåttmått .
  • Återhämtningsmåtten från den nedrullningsbara menyn.
  • Hur du vill att data ska aggregeras i resultatet (i genomsnitt, med maximum osv.).
  • Tidsvaraktighet (senaste 30 minuterna, senaste 24 timmarna osv.).

Skärmbild som visar hur du kommer åt filter för återhämtningsmått för din containerapp.

Om du till exempel anger måttet Resiliency Request Retries i testappsomfånget med Genomsnittlig aggregering för sökning inom en tidsram på 30 minuter ser resultatet ut så här:

Skärmbild som visar resultatet från exempel på måttfilter för återhämtning.

Relaterat innehåll

Se hur återhämtning fungerar för Dapr-komponenter i Azure Container Apps.