Szolgáltatásfelderítési rugalmasság (előzetes verzió)

Az Azure Container Apps rugalmasságával proaktív módon megelőzheti, észlelheti és helyreállíthatja a szolgáltatáskérések hibáit egyszerű rugalmassági szabályzatok használatával. Ebből a cikkből megtudhatja, hogyan konfigurálhatja az Azure Container Apps rugalmassági szabályzatait, amikor kéréseket kezdeményez az Azure Container Apps szolgáltatásfelderítés használatával.

Feljegyzés

Jelenleg nem alkalmazhat rugalmassági szabályzatokat a Dapr Service Invocation API-val küldött kérelmekre.

A tárolóalkalmazáshoz érkező minden kérés házirendeket kényszerít ki. A szabályzatokat a tárolóalkalmazáshoz igazíthatja, amely elfogad konfigurációkat, mint például:

  • Az újrapróbálkozések száma
  • Újrapróbálkozás és időtúllépés időtartama
  • Az egyezések újrapróbálása
  • Megszakító ismétlődő hibái és egyebek

Az alábbi képernyőkép azt mutatja be, hogy egy alkalmazás hogyan használ újrapróbálkozási szabályzatot a sikertelen kérelmekből való helyreállításra.

Egy ábra, amely bemutatja a tárolóalkalmazások közötti rugalmasságot egy tárolóalkalmazás szolgáltatásnevének használatával.

Támogatott rugalmassági szabályzatok

Rugalmassági szabályzatok konfigurálása

Akár a Bicep, a parancssori felület vagy az Azure Portal használatával konfigurálja a rugalmassági szabályzatokat, tárolóalkalmazásonként csak egy szabályzatot alkalmazhat.

Amikor szabályzatot alkalmaz egy tárolóalkalmazásra, a szabályok az adott tárolóalkalmazásra irányuló összes kérésre vonatkoznak, nem pedig az adott tárolóalkalmazásból érkező kérelmekre. A rendszer például egy újrapróbálkozési szabályzatot alkalmaz egy nevű tárolóalkalmazásra App B. A B alkalmazásnak küldött összes bejövő kérés automatikusan újrapróbálkozza a hibát. Azonban a B alkalmazás által küldött kimenő kérések nem garantáltan próbálkoznak újra meghibásodás esetén.

Az alábbi rugalmassági példa az összes elérhető konfigurációt szemlélteti.

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
    }
  }
}

Szabályzat-specifikációk

Időtúllépések

Az időtúllépések korán megszakítják a hosszú ideig futó műveleteket. Az időtúllépési szabályzat a következő tulajdonságokat tartalmazza.

properties: {
  timeoutPolicy: {
      responseTimeoutInSeconds: 15
      connectionTimeoutInSeconds: 5
  }
}
Metaadatok Kötelező Leírás Példa
responseTimeoutInSeconds Igen Időtúllépés történt a tárolóalkalmazás válaszára várakozva. 15
connectionTimeoutInSeconds Igen Időtúllépés a tárolóalkalmazással való kapcsolat létrehozásához. 5

Újrapróbálkozások

tcpRetryPolicy vagy egy httpRetryPolicy stratégia meghatározása a sikertelen műveletekre. Az újrapróbálkozési szabályzat a következő konfigurációkat tartalmazza.

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'
            ]
        }
    } 
}
Metaadatok Kötelező Leírás Példa
maxRetries Igen Sikertelen HTTP-kérés végrehajtásának maximális újrapróbálkozása. 5
retryBackOff Igen Figyelje a kéréseket, és állítsa le az érintett szolgáltatás felé irányuló összes forgalmat, amikor időtúllépési és újrapróbálkozási feltételek teljesülnek. Nem alkalmazható
retryBackOff.initialDelayInMilliseconds Igen Késleltetés az első hiba és az első újrapróbálkozás között. 1000
retryBackOff.maxIntervalInMilliseconds Igen Az újrapróbálkozások közötti maximális késleltetés. 10000
matches Igen Állítsa be az egyezés értékét, hogy korlátozza, hogy az alkalmazás mikor próbálkozzon újra. \, \, \
matches.headers Y* Próbálkozzon újra, ha a hibaválasz tartalmaz egy adott fejlécet. *A fejlécek csak akkor szükségesek, ha megadja a retriable-headers hibatulajdonságot. További információ az elérhető fejléc-egyezésekről. X-Content-Type
matches.httpStatusCodes Y* Próbálkozzon újra, ha a válasz egy adott állapotkódot ad vissza. *Az állapotkódok csak akkor kötelező tulajdonságok, ha megadja a retriable-status-codes hibatulajdonságot. 502, 503
matches.errors Igen Csak akkor próbálkozzon újra, ha az alkalmazás adott hibát ad vissza. További információ az elérhető hibákról. connect-failure, reset
Fejléc egyezések

Ha megadja a retriable-headers hibát, a következő fejléc-egyezés tulajdonságaival újrapróbálkozhat, ha a válasz tartalmaz egy adott fejlécet.

matches: {
  headers: [
    { 
      header: 'x-ms-retriable'
      match: {
        exactMatch: 'true'
      }
    }
  ]
}
Metaadatok Leírás
prefixMatch Az újrapróbálkozások a fejlécérték előtagja alapján történnek.
exactMatch Az újrapróbálkozások a fejlécérték pontos egyezése alapján történnek.
suffixMatch Az újrapróbálkozások a fejlécérték utótagja alapján történnek.
regexMatch Az újrapróbálkozási műveletek egy reguláris kifejezési szabály alapján lesznek végrehajtva, amelyben a fejléc értékének meg kell egyeznie a regex mintával.
Hibák

Az alábbi hibák bármelyikén végrehajthat újrapróbálkozásokat:

matches: {
  errors: [
    'retriable-headers'
    'retriable-status-codes'
    '5xx'
    'reset'
    'connect-failure'
    'retriable-4xx'
  ]
}
Metaadatok Leírás
retriable-headers Újrapróbálkozási folyamatot aktiváló HTTP-válaszfejlécek. Újrapróbálkozás akkor történik, ha a fejlécek bármelyike megegyezik a válaszfejlécekkel. Kötelező, ha újra meg szeretné próbálni bármely egyező fejlécre.
retriable-status-codes AZ újrapróbálkozásokat aktiváló HTTP-állapotkódok. Kötelező, ha újra meg szeretné próbálni bármely egyező állapotkód esetén.
5xx Próbálkozzon újra, ha a kiszolgáló bármilyen 5xx válaszkóddal válaszol.
reset Próbálkozzon újra, ha a kiszolgáló nem válaszol.
connect-failure Próbálkozzon újra, ha egy kérés a tárolóalkalmazással való hibás kapcsolat miatt meghiúsult.
retriable-4xx Próbálkozzon újra, ha a tárolóalkalmazás egy 400-sorozatú válaszkóddal válaszol, például 409.

tcpRetryPolicy

properties: {
    tcpRetryPolicy: {
        maxConnectAttempts: 3
    }
}
Metaadatok Kötelező Leírás Példa
maxConnectAttempts Igen Állítsa be a sikertelen kapcsolatok újrapróbálkozási kísérleteinek (maxConnectionAttempts) maximális korlátját. 3

Megszakítók

Az áramkör-megszakító házirendek megadják, hogy a tárolóalkalmazás-replika ideiglenesen törlődik-e a terheléselosztási készletből az olyan eseményindítók alapján, mint az egymást követő hibák száma.

properties: {
    circuitBreakerPolicy: {
        consecutiveErrors: 5
        intervalInSeconds: 10
        maxEjectionPercent: 50
    }
}
Metaadatok Kötelező Leírás Példa
consecutiveErrors Igen A tárolóalkalmazás-replikák terheléselosztásból való ideiglenes eltávolítása előtt jelentkező egymást követő hibák száma. 5
intervalInSeconds Igen Annak meghatározására szánt időtartam, hogy a replika kikerül-e vagy visszahelyezésre kerül-e a terheléselosztó készletbe. 10
maxEjectionPercent Igen A sikertelen tárolóalkalmazás-replikák maximális aránya, amelyek eltávolításra kerülnek a terheléselosztásból. Az értéktől függetlenül eltávolít legalább egy gazdagépet. 50

Kapcsolatkészletek

Az Azure Container Apps-kapcsolatkészletezés a tárolóalkalmazásokkal létesített és újrafelhasználható kapcsolatok készletét tartja fenn. Ez a kapcsolatkészlet csökkenti az egyes kérések egyedi kapcsolatainak létrehozásának és megszakadásának többletterhelését.

A kapcsolatkészletekkel megadhatja a szolgáltatáshoz engedélyezett kérelmek vagy kapcsolatok maximális számát. Ezek a korlátok szabályozzák az egyes szolgáltatások egyidejű kapcsolatainak teljes számát. Ha eléri ezt a korlátot, a rendszer nem hoz létre új kapcsolatokat a szolgáltatás számára, amíg a meglévő kapcsolatok ki nem adhatók vagy bezáródnak. A kapcsolatok kezelésének folyamata megakadályozza, hogy a kérések túlterhelik az erőforrásokat, és hatékony kapcsolatkezelést tartson fenn.

httpConnectionPool

properties: {
    httpConnectionPool: {
        http1MaxPendingRequests: 1024
        http2MaxRequests: 1024
    }
}
Metaadatok Kötelező Leírás Példa
http1MaxPendingRequests Igen Kérésekhez http1 használatos. Egy tárolóalkalmazás nyitott kapcsolatainak maximális száma. 1024
http2MaxRequests Igen Kérésekhez http2 használatos. Tárolóalkalmazásra irányuló egyidejű kérések maximális száma. 1024

tcpConnectionPool

properties: {
    tcpConnectionPool: {
        maxConnections: 100
    }
}
Metaadatok Kötelező Leírás Példa
maxConnections Igen Tárolóalkalmazások egyidejű kapcsolatainak maximális száma. 100

Feljegyzés

Ha nem állítod be a(z) maxConnections értéket, alapértelmezés szerint legfeljebb 10 240 egyidejű kapcsolat van érvényben. Állítsd maxConnections be, hogy növeld vagy csökkented ezt a határt a konténeralkalmazásodnál.

Rugalmasság megfigyelhetősége

A rugalmasság megfigyelhetőségét a tárolóalkalmazás metrikái és rendszernaplói segítségével végezheti el.

Rugalmassági naplók

A tárolóalkalmazás Figyelés szakaszában válassza a Naplók lehetőséget.

A tárolóalkalmazás naplóinak megkeresését bemutató képernyőkép.

A Naplók panelen írjon és futtasson egy lekérdezést, amely rugalmassági eseményeket keres a tárolóalkalmazás rendszernaplóiban. Futtasson például egy, a következő lekérdezéshez hasonló lekérdezést a rugalmassági események kereséséhez és azok megjelenítéséhez:

  • Időbélyegző
  • Környezet neve
  • Tárolóalkalmazás neve
  • Rugalmasság típusa és oka
  • Naplóüzenetek
ContainerAppSystemLogs_CL
| where EventSource_s == "Resiliency"
| project TimeStamp_s, EnvironmentName_s, ContainerAppName_s, Type_s, EventSource_s, Reason_s, Log_s

Válassza a Futtatás lehetőséget a lekérdezés futtatásához és az eredmények megtekintéséhez.

Képernyőkép a rugalmassági lekérdezés eredményeiről a megadott lekérdezési példa alapján.

Rugalmassági metrikák

A tárolóalkalmazás Figyelés menüjében válassza a Metrikák lehetőséget. A Metrikák panelen válassza ki a következő szűrőket:

  • A tárolóalkalmazás nevének hatóköre.
  • A Standard metrikák névtér.
  • A rugalmassági metrikák a legördülő menüből.
  • Hogyan szeretné összesíteni az adatokat az eredményekben (átlag, maximum stb.).
  • Az időtartam (például az elmúlt 30 perc vagy az utolsó 24 óra).

Képernyőkép a tárolóalkalmazás rugalmassági metrikák szűrőinek eléréséről.

Ha például a rugalmassági kérelem újrapróbálkozási metrikáját a tesztalkalmazás hatókörében az Átlagos aggregáció beállításával állítja be, hogy 30 perces időkereten belül keressen, az eredmények a következőképpen néznek ki:

Képernyőkép a rugalmasságra vonatkozó példametrikaszűrők eredményeiről.

Kapcsolódó tartalom

Megtudhatja, hogyan működik a rugalmasság a Dapr-összetevőkhöz az Azure Container Appsben.

  • Last updated on