Tolerantie voor servicedetectie (preview)
Met tolerantie van Azure Container Apps kunt u proactief fouten in serviceaanvragen voorkomen, detecteren en herstellen met behulp van eenvoudig tolerantiebeleid. In dit artikel leert u hoe u tolerantiebeleid voor Azure Container Apps configureert bij het initiëren van aanvragen met behulp van Azure Container Apps-servicedetectie.
Notitie
Op dit moment kan tolerantiebeleid niet worden toegepast op aanvragen die zijn gedaan met behulp van de Aanroep-API van de Dapr-service.
Beleidsregels zijn van kracht voor elke aanvraag voor een container-app. U kunt beleidsregels aanpassen aan de container-app die aanvragen accepteert met configuraties zoals:
- Het aantal nieuwe pogingen
- Duur van opnieuw proberen en time-out
- Overeenkomsten voor opnieuw proberen
- Opeenvolgende fouten van circuitonderbrekers en andere
In de volgende schermopname ziet u hoe een toepassing een beleid voor opnieuw proberen gebruikt om te proberen om te herstellen van mislukte aanvragen.
Ondersteund tolerantiebeleid
Beleid voor tolerantie configureren
Of u nu tolerantiebeleid configureert met Bicep, de CLI of Azure Portal, u kunt slechts één beleid per container-app toepassen.
Wanneer u een beleid toepast op een container-app, worden de regels toegepast op alle aanvragen die zijn gedaan op die container-app, niet op aanvragen van die container-app. Een beleid voor opnieuw proberen wordt bijvoorbeeld toegepast op een container-app met de naam App B
. Alle binnenkomende aanvragen die naar App B zijn verzonden, worden automatisch opnieuw geprobeerd bij een fout. Uitgaande aanvragen die door App B worden verzonden, worden echter niet gegarandeerd opnieuw geprobeerd.
In het volgende voorbeeld van tolerantie ziet u alle beschikbare configuraties.
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
}
}
}
Beleidsspecificaties
Time-outs
Time-outs worden gebruikt om langdurige bewerkingen vroegtijdig te beëindigen. Het time-outbeleid bevat de volgende eigenschappen.
properties: {
timeoutPolicy: {
responseTimeoutInSeconds: 15
connectionTimeoutInSeconds: 5
}
}
Metagegevens | Vereist | Beschrijving | Voorbeeld |
---|---|---|---|
responseTimeoutInSeconds |
Ja | Time-out die wacht op een reactie van de container-app. | 15 |
connectionTimeoutInSeconds |
Ja | Time-out voor het tot stand brengen van een verbinding met de container-app. | 5 |
Nieuwe pogingen
Definieer een tcpRetryPolicy
of een httpRetryPolicy
strategie voor mislukte bewerkingen. Het beleid voor opnieuw proberen bevat de volgende configuraties.
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'
]
}
}
}
Metagegevens | Vereist | Beschrijving | Voorbeeld |
---|---|---|---|
maxRetries |
Ja | Maximum aantal nieuwe pogingen dat moet worden uitgevoerd voor een mislukte http-aanvraag. | 5 |
retryBackOff |
Ja | Bewaak de aanvragen en sluit al het verkeer naar de betrokken service af wanneer aan de time-out en criteria voor opnieuw proberen wordt voldaan. | N.v.t. |
retryBackOff.initialDelayInMilliseconds |
Ja | Vertraging tussen eerste fout en eerste nieuwe poging. | 1000 |
retryBackOff.maxIntervalInMilliseconds |
Ja | Maximale vertraging tussen nieuwe pogingen. | 10000 |
matches |
Ja | Stel overeenkomende waarden in om te beperken wanneer de app een nieuwe poging moet doen. | headers , , httpStatusCodes errors |
matches.headers |
Y* | Probeer het opnieuw wanneer het foutbericht een specifieke header bevat. *Headers zijn alleen vereiste eigenschappen als u de retriable-headers fouteigenschap opgeeft. Meer informatie over beschikbare headerovereenkomsten. |
X-Content-Type |
matches.httpStatusCodes |
Y* | Probeer het opnieuw wanneer het antwoord een specifieke statuscode retourneert. *Statuscodes zijn alleen vereiste eigenschappen als u de retriable-status-codes fouteigenschap opgeeft. |
502 , 503 |
matches.errors |
Ja | Alleen nieuwe pogingen wanneer de app een specifieke fout retourneert. Meer informatie over beschikbare fouten. | connect-failure , reset |
Koptekstovereenkomsten
Als u de retriable-headers
fout hebt opgegeven, kunt u de volgende eigenschappen van de headerovereenkomst gebruiken om het opnieuw te proberen wanneer het antwoord een specifieke header bevat.
matches: {
headers: [
{
header: 'x-ms-retriable'
match: {
exactMatch: 'true'
}
}
]
}
Metagegevens | Beschrijving |
---|---|
prefixMatch |
Nieuwe pogingen worden uitgevoerd op basis van het voorvoegsel van de headerwaarde. |
exactMatch |
Nieuwe pogingen worden uitgevoerd op basis van een exacte overeenkomst van de headerwaarde. |
suffixMatch |
Nieuwe pogingen worden uitgevoerd op basis van het achtervoegsel van de headerwaarde. |
regexMatch |
Nieuwe pogingen worden uitgevoerd op basis van een reguliere expressieregel waarbij de headerwaarde moet overeenkomen met het regex-patroon. |
Fouten
U kunt nieuwe pogingen uitvoeren op een van de volgende fouten:
matches: {
errors: [
'retriable-headers'
'retriable-status-codes'
'5xx'
'reset'
'connect-failure'
'retriable-4xx'
]
}
Metagegevens | Beschrijving |
---|---|
retriable-headers |
HTTP-antwoordheaders die een nieuwe poging activeren. Er wordt een nieuwe poging uitgevoerd als een van de header-overeenkomsten overeenkomt met de antwoordheaders. Vereist als u het opnieuw wilt proberen voor overeenkomende headers. |
retriable-status-codes |
HTTP-statuscodes die nieuwe pogingen moeten activeren. Vereist als u het opnieuw wilt proberen voor overeenkomende statuscodes. |
5xx |
Probeer het opnieuw als de server reageert met 5xx-antwoordcodes. |
reset |
Probeer het opnieuw als de server niet reageert. |
connect-failure |
Probeer het opnieuw als een aanvraag is mislukt vanwege een foutieve verbinding met de container-app. |
retriable-4xx |
Probeer het opnieuw als de container-app reageert met een antwoordcode uit de 400-serie, zoals 409 . |
tcpRetryPolicy
properties: {
tcpRetryPolicy: {
maxConnectAttempts: 3
}
}
Metagegevens | Vereist | Beschrijving | Voorbeeld |
---|---|---|---|
maxConnectAttempts |
Ja | Stel de maximum aantal verbindingspogingen (maxConnectionAttempts ) in om het opnieuw te proberen voor mislukte verbindingen. |
3 |
Stroomonderbrekers
Beleidsregels voor circuitonderbrekers geven aan of een replica van een container-app tijdelijk wordt verwijderd uit de taakverdelingsgroep, op basis van triggers zoals het aantal opeenvolgende fouten.
properties: {
circuitBreakerPolicy: {
consecutiveErrors: 5
intervalInSeconds: 10
maxEjectionPercent: 50
}
}
Metagegevens | Vereist | Beschrijving | Voorbeeld |
---|---|---|---|
consecutiveErrors |
Ja | Opeenvolgend aantal fouten voordat een container-app-replica tijdelijk wordt verwijderd uit taakverdeling. | 5 |
intervalInSeconds |
Ja | De hoeveelheid tijd die wordt opgegeven om te bepalen of een replica wordt verwijderd of hersteld uit de load balance-pool. | 10 |
maxEjectionPercent |
Ja | Maximumpercentage van mislukte container-app-replica's om uit taakverdeling te werpen. Hiermee verwijdert u ten minste één host, ongeacht de waarde. | 50 |
Verbindingsgroepen
De groepsgewijze verbinding van Azure Container App onderhoudt een groep bestaande en herbruikbare verbindingen met container-apps. Deze verbindingsgroep vermindert de overhead van het maken en verwijderen van afzonderlijke verbindingen voor elke aanvraag.
Met verbindingsgroepen kunt u het maximum aantal aanvragen of verbindingen opgeven dat is toegestaan voor een service. Deze limieten bepalen het totale aantal gelijktijdige verbindingen voor elke service. Wanneer deze limiet is bereikt, worden nieuwe verbindingen niet tot stand gebracht voor die service totdat bestaande verbindingen worden vrijgegeven of gesloten. Dit proces voor het beheren van verbindingen voorkomt dat resources worden overweldigd door aanvragen en zorgt voor efficiënt verbindingsbeheer.
httpConnectionPool
properties: {
httpConnectionPool: {
http1MaxPendingRequests: 1024
http2MaxRequests: 1024
}
}
Metagegevens | Vereist | Beschrijving | Voorbeeld |
---|---|---|---|
http1MaxPendingRequests |
Ja | Wordt gebruikt voor http1 aanvragen. Maximum aantal geopende verbindingen met een container-app. |
1024 |
http2MaxRequests |
Ja | Wordt gebruikt voor http2 aanvragen. Maximum aantal gelijktijdige aanvragen voor een container-app. |
1024 |
tcpConnectionPool
properties: {
tcpConnectionPool: {
maxConnections: 100
}
}
Metagegevens | Vereist | Beschrijving | Voorbeeld |
---|---|---|---|
maxConnections |
Ja | Maximum aantal gelijktijdige verbindingen met een container-app. | 100 |
Waarneembaarheid van tolerantie
U kunt de waarneembaarheid van tolerantie uitvoeren via de metrische gegevens en systeemlogboeken van uw container-app.
Tolerantielogboeken
Selecteer Logboeken in de sectie Bewaking van uw container-app.
Schrijf en voer in het deelvenster Logboeken een query uit om tolerantie te vinden via de systeemlogboeken van uw container-app. Voer bijvoorbeeld een query uit die vergelijkbaar is met de volgende om te zoeken naar tolerantiegebeurtenissen en de bijbehorende waarden weer te geven:
- Tijdstempel
- Omgevingsnaam
- Naam container-app
- Tolerantietype en reden
- Logboekberichten
ContainerAppSystemLogs_CL
| where EventSource_s == "Resiliency"
| project TimeStamp_s, EnvironmentName_s, ContainerAppName_s, Type_s, EventSource_s, Reason_s, Log_s
Klik op Uitvoeren om de query uit te voeren en resultaten weer te geven.
Metrische gegevens over tolerantie
Selecteer metrische gegevens in het menu Bewaking van uw container-app. Selecteer in het deelvenster Metrische gegevens de volgende filters:
- Het bereik voor de naam van uw container-app.
- De standaardnaamruimte voor metrische gegevens voor metrische gegevens .
- De metrische gegevens over tolerantie in de vervolgkeuzelijst.
- Hoe u de gegevens wilt aggregeren in de resultaten (gemiddeld, maximaal, enzovoort).
- De tijdsduur (afgelopen 30 minuten, afgelopen 24 uur, enzovoort).
Als u bijvoorbeeld de metriek Tolerantieaanvraag opnieuw probeert in te stellen in het bereik van de test-app met gemiddelde aggregatie om binnen een periode van 30 minuten te zoeken, zien de resultaten er als volgt uit:
Gerelateerde inhoud
Bekijk hoe tolerantie werkt voor Dapr-onderdelen in Azure Container Apps.