Resiliência de descoberta de serviço (versão prévia)
Com a resiliência dos Aplicativos de Contêiner do Azure, você pode prevenir, detectar e recuperar proativamente de falhas de solicitação de serviço usando políticas de resiliência simples. Neste artigo, você aprenderá a configurar políticas de resiliência dos Aplicativos de Contêiner do Azure ao iniciar solicitações usando a descoberta de serviço dos Aplicativos de Contêiner do Azure.
Observação
Atualmente, as políticas de resiliência não podem ser aplicadas a solicitações feitas usando a API de Invocação de Serviço Dapr.
As políticas estão em vigor para cada solicitação para um aplicativo de contêiner. Você pode personalizar políticas para o aplicativo de contêiner aceitando solicitações com configurações como:
- O número de repetições
- Duração do tempo limite de repetições
- Repetir correspondências
- Erros consecutivos de disjuntor e outros
A captura de tela a seguir mostra como um aplicativo usa uma política de repetição para tentar se recuperar de solicitações com falha.
Políticas de resiliência com suporte
Configurar políticas de resiliência
Se você configurar políticas de resiliência usando o Bicep, a CLI ou o portal do Azure, você só poderá aplicar uma política por aplicativo de contêiner.
Quando você aplica uma política a um aplicativo de contêiner, as regras são aplicadas a todas as solicitações feitas a esse aplicativo de contêiner, não às solicitações feitas desse aplicativo de contêiner. Por exemplo, uma política de repetição é aplicada a um aplicativo de contêiner chamado App B
. Todas as solicitações de entrada feitas ao Aplicativo B são repetidas automaticamente em caso de falha. No entanto, as solicitações de saída enviadas pelo aplicativo B não têm garantia de repetição em caso de falha.
O exemplo de resiliência a seguir demonstra todas as configurações disponíveis.
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
}
}
}
Especificações da política
Tempos limite
Os tempos limite são usados para encerrar operações de execução longa antecipada. A política de tempo limite inclui as propriedades a seguir.
properties: {
timeoutPolicy: {
responseTimeoutInSeconds: 15
connectionTimeoutInSeconds: 5
}
}
Metadados | Obrigatório | Descrição | Exemplo |
---|---|---|---|
responseTimeoutInSeconds |
Sim | Tempo limite aguardando uma resposta do aplicativo de contêiner. | 15 |
connectionTimeoutInSeconds |
Sim | Tempo limite para estabelecer uma conexão com o aplicativo de contêiner. | 5 |
Repetições
Defina tcpRetryPolicy
ou uma estratégia de httpRetryPolicy
para operações com falha. A política de repetição inclui as configurações a seguir.
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'
]
}
}
}
Metadados | Obrigatório | Descrição | Exemplo |
---|---|---|---|
maxRetries |
Sim | Repetições máximas a serem executadas para uma solicitação http com falha. | 5 |
retryBackOff |
Sim | Monitore as solicitações e desligue todo o tráfego para o serviço afetado quando os critérios de tempo limite e repetição forem atendidos. | N/D |
retryBackOff.initialDelayInMilliseconds |
Sim | Atraso entre o primeiro erro e a primeira repetição. | 1000 |
retryBackOff.maxIntervalInMilliseconds |
Sim | Atraso máximo entre as repetições. | 10000 |
matches |
Sim | Defina valores de correspondência para limitar quando o aplicativo deve tentar uma repetição. | headers , httpStatusCodes , errors |
matches.headers |
Y* | Tente novamente quando a resposta de erro incluir um cabeçalho específico. *Os cabeçalhos só serão propriedades obrigatórias se você especificar a propriedade de erro retriable-headers . Saiba mais sobre correspondências de cabeçalho disponíveis. |
X-Content-Type |
matches.httpStatusCodes |
Y* | Tente novamente quando a resposta retornar um código de status específico. *Os códigos de status só serão propriedades obrigatórias se você especificar a propriedade de erro retriable-status-codes . |
502 , 503 |
matches.errors |
Sim | Só tenta novamente quando o aplicativo retorna um erro específico. Saiba mais sobre extensões disponíveis. | connect-failure , reset |
Correspondências de cabeçalho
Se você especificou o erro retriable-headers
, poderá usar as propriedades de correspondência de cabeçalho a seguir para tentar novamente quando a resposta incluir um cabeçalho específico.
matches: {
headers: [
{
header: 'x-ms-retriable'
match: {
exactMatch: 'true'
}
}
]
}
Metadados | Descrição |
---|---|
prefixMatch |
As repetições são executadas com base no prefixo do valor do cabeçalho. |
exactMatch |
As repetições são executadas com base em uma correspondência exata do valor do cabeçalho. |
suffixMatch |
As repetições são executadas com base no sufixo do valor do cabeçalho. |
regexMatch |
As repetições são executadas com base em uma regra de expressão regular em que o valor do cabeçalho deve corresponder ao padrão regex. |
Errors
Você pode executar repetições em qualquer um dos seguintes erros:
matches: {
errors: [
'retriable-headers'
'retriable-status-codes'
'5xx'
'reset'
'connect-failure'
'retriable-4xx'
]
}
Metadados | Descrição |
---|---|
retriable-headers |
Cabeçalhos de resposta HTTP que disparam uma repetição. Uma repetição será executada se qualquer uma das correspondências de cabeçalho corresponder aos cabeçalhos de resposta. Obrigatório se você quiser repetir em quaisquer cabeçalhos correspondentes. |
retriable-status-codes |
Códigos de status HTTP que devem disparar repetições. Obrigatório se você quiser repetir em quaisquer código de status correspondentes. |
5xx |
Repita se o servidor responder com quaisquer códigos de resposta 5xx. |
reset |
Repita se o servidor não responder. |
connect-failure |
Repita se uma solicitação falhou devido a uma conexão com falha com o aplicativo de contêiner. |
retriable-4xx |
Repita se o aplicativo contêiner responder com um código de resposta da série 400, como 409 . |
tcpRetryPolicy
properties: {
tcpRetryPolicy: {
maxConnectAttempts: 3
}
}
Metadados | Obrigatório | Descrição | Exemplo |
---|---|---|---|
maxConnectAttempts |
Sim | Defina as tentativas máximas de conexão (maxConnectionAttempts ) para repetir em conexões com falha. |
3 |
Disjuntores
As políticas de disjuntor especificam se uma réplica de aplicativo de contêiner é temporariamente removida do pool de balanceamento de carga, com base em gatilhos como o número de erros consecutivos.
properties: {
circuitBreakerPolicy: {
consecutiveErrors: 5
intervalInSeconds: 10
maxEjectionPercent: 50
}
}
Metadados | Obrigatório | Descrição | Exemplo |
---|---|---|---|
consecutiveErrors |
Sim | Número consecutivo de erros antes que uma réplica de aplicativo de contêiner seja temporariamente removida do balanceamento de carga. | 5 |
intervalInSeconds |
Sim | A quantidade de tempo fornecida para determinar se uma réplica é removida ou restaurada do pool de balanceamento de carga. | 10 |
maxEjectionPercent |
Sim | Percentual máximo de réplicas de aplicativo de contêiner com falha para ejetar do balanceamento de carga. Remove pelo menos um host, independentemente do valor. | 50 |
Pools de conexões
O pool de conexões do Aplicativo de Contêiner do Azure mantém um pool de conexões estabelecidas e reutilizáveis para aplicativos de contêiner. Esse pool de conexões reduz a sobrecarga de criar e derrubar conexões individuais para cada solicitação.
Os pools de conexões permitem especificar o número máximo de solicitações ou conexões permitidas para um serviço. Esses limites controlam o número total de conexões simultâneas para cada serviço. Quando esse limite é atingido, novas conexões não são estabelecidas para esse serviço até que as conexões existentes sejam liberadas ou fechadas. Esse processo de gerenciamento de conexões impede que os recursos sejam sobrecarregados por solicitações e mantém um gerenciamento eficiente de conexões.
httpConnectionPool
properties: {
httpConnectionPool: {
http1MaxPendingRequests: 1024
http2MaxRequests: 1024
}
}
Metadados | Obrigatório | Descrição | Exemplo |
---|---|---|---|
http1MaxPendingRequests |
Sim | Usado para solicitações de http1 . Número máximo de conexões abertas para um aplicativo de contêiner. |
1024 |
http2MaxRequests |
Sim | Usado para solicitações de http2 . Número máximo de solicitações simultâneas. |
1024 |
tcpConnectionPool
properties: {
tcpConnectionPool: {
maxConnections: 100
}
}
Metadados | Obrigatório | Descrição | Exemplo |
---|---|---|---|
maxConnections |
Sim | Número máximo de conexões simultâneas com um aplicativo contêiner. | 100 |
Observabilidade de resiliência
Você pode executar a observabilidade de resiliência por meio das métricas e logs do sistema do seu aplicativo de contêiner.
Logs de resiliência
Na seção Monitoramento do aplicativo de contêiner, selecione Logs.
No painel Logs, grave e execute uma consulta para localizar resiliência por meio dos logs do sistema do aplicativo de contêiner. Por exemplo, execute uma consulta semelhante à seguinte para pesquisar eventos de resiliência e mostrar:
- Carimbo de data/hora
- Nome do ambiente
- Nome do aplicativo de contêiner
- Tipo de resiliência e motivo
- Mensagens de Log
ContainerAppSystemLogs_CL
| where EventSource_s == "Resiliency"
| project TimeStamp_s, EnvironmentName_s, ContainerAppName_s, Type_s, EventSource_s, Reason_s, Log_s
Clique em Executar para executar a consulta e visualizar os resultados.
Métricas de resiliência
Na seção Monitoramento do menu de contêiner, selecione Métricas. No painel Métricas, selecione os seguintes filtros:
- O escopo do nome do aplicativo de contêiner.
- O namespace das métricas Métricas padrão.
- As métricas de resiliência do menu suspenso.
- Como você gostaria dos dados agregados nos resultados (por média, por máximo, etc.).
- A duração do tempo (últimos 30 minutos, últimas 24 horas etc.).
Por exemplo, se você definir a métrica Repetições de Solicitação de Resiliência no escopo do test-app com agregação Média para pesquisar em um período de 30 minutos, os resultados serão semelhantes aos seguintes:
Conteúdo relacionado
Veja como a resiliência funciona para Componentes dapr nos Aplicativos de Contêiner do Azure.