Share via

Odolnost zjišťování služeb (Preview)

  • Článek

Díky odolnosti Azure Container Apps můžete aktivně zabránit selháním požadavků na služby, zjišťovat je a obnovovat pomocí jednoduchýchzásadchch V tomto článku se dozvíte, jak nakonfigurovat zásady odolnosti služby Azure Container Apps při inicializování požadavků pomocí zjišťování služby Azure Container Apps.

Poznámka:

Zásady odolnosti se v současné době nedají použít u požadavků provedených pomocí rozhraní API pro vyvolání služby Dapr.

Zásady platí pro každou žádost o aplikaci kontejneru. Zásady můžete přizpůsobit aplikaci kontejneru, která přijímá požadavky s konfiguracemi, jako jsou:

  • Počet opakování
  • Doba trvání opakování a časového limitu
  • Opakovat shody
  • Po sobě jdoucí chyby jističe a další

Následující snímek obrazovky ukazuje, jak aplikace používá zásadu opakování k pokusu o obnovení z neúspěšných požadavků.

Diagram demonstrating container app to container app resiliency using a container app's service name.

Podporované zásady odolnosti

Konfigurace zásad odolnosti

Bez ohledu na to, jestli konfigurujete zásady odolnosti pomocí Bicep, rozhraní příkazového řádku nebo webu Azure Portal, můžete použít jenom jednu zásadu pro aplikaci typu kontejner.

Když použijete zásadu pro aplikaci kontejneru, pravidla se použijí na všechny požadavky provedené v této aplikaci kontejneru, ne na požadavky provedené z této aplikace kontejneru. Například zásada opakování se použije pro aplikaci kontejneru s názvem App B. Všechny příchozí požadavky provedené v aplikaci B se automaticky opakují při selhání. U odchozích požadavků odesílaných aplikací B ale není zaručeno, že se budou opakovat v selhání.

Následující příklad odolnosti ukazuje všechny dostupné konfigurace.

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

Specifikace zásad

Časové limity

Časové limity se používají k předčasnému ukončení dlouhotrvajících operací. Zásada časového limitu obsahuje následující vlastnosti.

properties: {
  timeoutPolicy: {
      responseTimeoutInSeconds: 15
      connectionTimeoutInSeconds: 5
  }
}
Metadata Požadováno Popis Příklad
responseTimeoutInSeconds Ano Časový limit čekání na odpověď z aplikace kontejneru 15
connectionTimeoutInSeconds Ano Vypršení časového limitu pro navázání připojení k aplikaci kontejneru 5

Opakování

Definujte tcpRetryPolicy nebo strategii httpRetryPolicy pro neúspěšné operace. Zásady opakování zahrnují následující konfigurace.

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 Požadováno Popis Příklad
maxRetries Ano Maximální počet opakovaných pokusů, které se mají provést pro neúspěšný požadavek HTTP. 5
retryBackOff Ano Monitorujte požadavky a vypněte veškerý provoz do ovlivněné služby, když jsou splněna kritéria časového limitu a opakování. –
retryBackOff.initialDelayInMilliseconds Ano Zpoždění mezi první chybou a prvním opakováním. 1000
retryBackOff.maxIntervalInMilliseconds Ano Maximální zpoždění mezi opakovanými pokusy. 10000
matches Ano Nastavte hodnoty shody tak, aby se omezily, když by se aplikace měla pokusit o opakování. headers, httpStatusCodes, errors
matches.headers Y* Zkuste to znovu, když odpověď na chybu obsahuje konkrétní hlavičku. *Hlavičky jsou povinné pouze v případě, že zadáte chybovou retriable-headers vlastnost. Přečtěte si další informace o dostupných shodách hlaviček. X-Content-Type
matches.httpStatusCodes Y* Zkuste to znovu, když odpověď vrátí konkrétní stavový kód. *Stavové kódy jsou povinné pouze vlastnosti, pokud zadáte chybovou retriable-status-codes vlastnost. 502, 503
matches.errors Ano Opakuje se jenom v případě, že aplikace vrátí konkrétní chybu. Přečtěte si další informace o dostupných chybách. connect-failure, reset
Shoda záhlaví

Pokud jste zadali retriable-headers chybu, můžete použít následující vlastnosti shody hlaviček a zkusit to znovu, když odpověď obsahuje konkrétní hlavičku.

matches: {
  headers: [
    { 
      header: 'x-ms-retriable'
      match: {
        exactMatch: 'true'
      }
    }
  ]
}
Metadata Popis
prefixMatch Opakování se provádí na základě předpony hodnoty hlavičky.
exactMatch Opakování se provádí na základě přesné shody hodnoty hlavičky.
suffixMatch Opakování se provádí na základě přípony hodnoty hlavičky.
regexMatch Opakování se provádí na základě pravidla regulárního výrazu, ve kterém se hodnota záhlaví musí shodovat se vzorem regulárních výrazů.
Chyby

Opakování můžete provést u některé z následujících chyb:

matches: {
  errors: [
    'retriable-headers'
    'retriable-status-codes'
    '5xx'
    'reset'
    'connect-failure'
    'retriable-4xx'
  ]
}
Metadata Popis
retriable-headers Hlavičky odpovědi HTTP, které aktivují opakování Opakování se provede, pokud některá z hlaviček odpovídá hlavičce odpovědi. Vyžaduje se, pokud chcete opakovat všechny odpovídající hlavičky.
retriable-status-codes Stavové kódy HTTP, které by měly aktivovat opakování. Vyžaduje se, pokud chcete opakovat všechny odpovídající stavové kódy.
5xx Zkuste to znovu, pokud server odpoví libovolnými kódy odpovědí 5xx.
reset Zkuste to znovu, pokud server nereaguje.
connect-failure Zkuste to znovu, pokud žádost selhala kvůli chybnému připojení k aplikaci kontejneru.
retriable-4xx Zkuste to znovu, pokud aplikace kontejneru odpoví kódem odpovědi řady 400, například 409.

tcpRetryPolicy

properties: {
    tcpRetryPolicy: {
        maxConnectAttempts: 3
    }
}
Metadata Požadováno Popis Příklad
maxConnectAttempts Ano Nastavte maximální počet pokusů o připojení (maxConnectionAttempts) pro opakování neúspěšných připojení. 3

Jističe

Zásady jističe určují, jestli se replika kontejnerové aplikace dočasně odebere z fondu vyrovnávání zatížení na základě aktivačních událostí, jako je počet po sobě jdoucích chyb.

properties: {
    circuitBreakerPolicy: {
        consecutiveErrors: 5
        intervalInSeconds: 10
        maxEjectionPercent: 50
    }
}
Metadata Požadováno Popis Příklad
consecutiveErrors Ano Po sobě jdoucí počet chyb před dočasném odebráním repliky aplikace kontejneru z vyrovnávání zatížení. 5
intervalInSeconds Ano Doba, po kterou se určí, jestli se replika odebere nebo obnoví z fondu vyrovnávání zatížení. 10
maxEjectionPercent Ano Maximální procento neúspěšných replik kontejnerových aplikací k vysunutí z vyrovnávání zatížení Odebere alespoň jednoho hostitele bez ohledu na hodnotu. 50

fondy Připojení ion

Sdružování připojení azure Container App udržuje fond vytvořených a opakovaně použitelných připojení k aplikacím kontejnerů. Tento fond připojení snižuje režii při vytváření a odstraňování jednotlivých připojení pro jednotlivé požadavky.

fondy Připojení umožňují zadat maximální počet požadavků nebo připojení povolených pro službu. Tato omezení řídí celkový počet souběžných připojení pro každou službu. Po dosažení tohoto limitu se nová připojení k této službě nenaváže, dokud nebudou vydána nebo ukončena stávající připojení. Tento proces správy připojení zabraňuje zahlcení prostředků požadavky a udržuje efektivní správu připojení.

http Připojení ionPool

properties: {
    httpConnectionPool: {
        http1MaxPendingRequests: 1024
        http2MaxRequests: 1024
    }
}
Metadata Požadováno Popis Příklad
http1MaxPendingRequests Ano Používá se pro http1 žádosti. Maximální počet otevřených připojení k aplikaci kontejneru 1024
http2MaxRequests Ano Používá se pro http2 žádosti. Maximální počet souběžných požadavků na aplikaci kontejneru 1024

tcp Připojení ionPool

properties: {
    tcpConnectionPool: {
        maxConnections: 100
    }
}
Metadata Požadováno Popis Příklad
maxConnections Ano Maximální počet souběžných připojení k aplikaci kontejneru 100

Pozorovatelnost odolnosti

Pozorovatelnost odolnosti můžete provádět prostřednictvím metrik a systémových protokolů vaší aplikace kontejneru.

Protokoly odolnosti

V části Monitorování aplikace kontejneru vyberte Protokoly.

Screenshot demonstrating where to find the logs for your container app.

V podokně Protokoly napište a spusťte dotaz, abyste zjistili odolnost prostřednictvím protokolů systému kontejnerových aplikací. Spusťte například dotaz podobný následujícímu, abyste vyhledali události odolnosti a zobrazili jejich:

  • Časový údaj
  • Název prostředí
  • Název kontejnerové aplikace
  • Typ odolnosti a důvod
  • Protokolování zpráv
ContainerAppSystemLogs_CL
| where EventSource_s == "Resiliency"
| project TimeStamp_s, EnvironmentName_s, ContainerAppName_s, Type_s, EventSource_s, Reason_s, Log_s

Kliknutím na Spustit spustíte dotaz a zobrazíte výsledky.

Screenshot showing resiliency query results based on provided query example.

Metriky odolnosti

V nabídce Monitorování aplikace kontejneru vyberte Metriky. V podokně Metriky vyberte následující filtry:

  • Obor na název vaší aplikace kontejneru.
  • Obor názvů standardních metrik metrik .
  • Metriky odolnosti z rozevírací nabídky
  • Jak chcete, aby se data agregovala ve výsledcích (podle průměru, podle maxima atd.).
  • Doba trvání (posledních 30 minut, posledních 24 hodin atd.).

Screenshot demonstrating how to access the resiliency metrics filters for your container app.

Pokud například nastavíte metriku Opakování požadavků na odolnost v oboru testovací aplikace s agregací Průměr , která se má prohledávat během 30minutového časového rámce, výsledky vypadají takto:

Screenshot showing the results from example metrics filters for resiliency.

Související obsah

Podívejte se, jak funguje odolnost komponent Dapr v Azure Container Apps.