Condividi tramite

Resilienza dell'individuazione dei servizi

  • Articolo

Con la resilienza di App contenitore di Azure, è possibile impedire, rilevare e ripristinare in modo proattivo gli errori delle richieste di servizio usando criteri di resilienza semplici. Questo articolo illustra come configurare i criteri di resilienza di App contenitore di Azure quando si avviano le richieste usando l'individuazione del relativo servizio.

Nota

Attualmente, i criteri di resilienza non possono essere applicati alle richieste effettuate tramite l'API di chiamata al servizio Dapr.

I criteri sono validi per ogni richiesta a un'app contenitore. È possibile personalizzare i criteri per l'app contenitore che accetta le richieste con configurazioni come:

  • Il numero di nuovi tentativi
  • Durata dei tentativi e del timeout
  • Corrispondenze tentativi
  • Errori consecutivi dell'interruttore e di altro tipo

Lo screenshot seguente mostra come un'applicazione usa un criterio di ripetizione per tentare di eseguire il ripristino da richieste non riuscite.

Diagramma che illustra la resilienza dell'app contenitore usando il nome del servizio di un'app contenitore.

Criteri di resilienza supportati

Configurare i criteri di resilienza

Sia che si configurino criteri di resilienza usando Bicep, l'interfaccia della riga di comando o il portale di Azure, è possibile applicare un solo criterio per ogni app contenitore.

Quando si applicano criteri a un'app contenitore, le regole vengono applicate a tutte le richieste effettuate all'app contenitore, non alle richieste effettuate da quest'ultima. Ad esempio, un criterio di ripetizione dei tentativi viene applicato a un'app contenitore denominata App B. Tutte le richieste in ingresso effettuate all'app B riprovano automaticamente in caso di errore. Tuttavia, le richieste in uscita inviate dall'app B non hanno la certezza di riprovare in caso di errore.

L'esempio di resilienza seguente illustra tutte le configurazioni disponibili.

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

Specifiche dei criteri

Timeout

I timeout vengono usati per le operazioni con esecuzione prolungata anticipata. I criteri di timeout includono le proprietà seguenti.

properties: {
  timeoutPolicy: {
      responseTimeoutInSeconds: 15
      connectionTimeoutInSeconds: 5
  }
}
Metadati UFX Obbligatorio Descrizione Esempio
responseTimeoutInSeconds Sì Timeout in attesa di una risposta dall'app contenitore. 15
connectionTimeoutInSeconds Sì Timeout per stabilire una connessione all'app contenitore. 5

Nuovi tentativi

Definire un tcpRetryPolicy o una strategia di httpRetryPolicy per le operazioni non riuscite. I criteri di ripetizione includono le configurazioni seguenti.

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'
            ]
        }
    } 
}
Metadati UFX Obbligatorio Descrizione Esempio
maxRetries Sì Numero massimo di tentativi da eseguire per una richiesta HTTP non riuscita. 5
retryBackOff Sì Monitorare le richieste e arrestare tutto il traffico verso il servizio interessato quando vengono soddisfatti i criteri di timeout e ripetizione dei tentativi. N/D
retryBackOff.initialDelayInMilliseconds Sì Ritardo tra il primo errore e il primo tentativo. 1000
retryBackOff.maxIntervalInMilliseconds Sì Ritardo massimo tra i tentativi. 10000
matches Sì Impostare i valori di corrispondenza per limitare quando l'app deve effettuare un nuovo tentativo. headers, httpStatusCodes, errors
matches.headers Y* Riprovare quando la risposta di errore include un'intestazione specifica. *Le intestazioni sono obbligatorie solo se si specifica la proprietà di errore retriable-headers. Altre informazioni sulle corrispondenze di intestazione disponibili. X-Content-Type
matches.httpStatusCodes Y* Riprovare quando la risposta restituisce un codice di stato specifico. *I codici di stato sono proprietà obbligatorie solo se si specifica la proprietà di errore retriable-status-codes. 502, 503
matches.errors Sì Solo i tentativi di quando l'app restituisce un errore specifico. Altre informazioni sugli errori disponibili. connect-failure, reset
Corrispondenze di intestazione

Se è stato specificato l'errore retriable-headers, è possibile usare le proprietà di corrispondenza dell'intestazione seguenti per riprovare quando la risposta include un'intestazione specifica.

matches: {
  headers: [
    { 
      header: 'x-ms-retriable'
      match: {
        exactMatch: 'true'
      }
    }
  ]
}
Metadati UFX Descrizione
prefixMatch I tentativi vengono eseguiti in base al prefisso del valore dell'intestazione.
exactMatch I tentativi vengono eseguiti in base a una corrispondenza esatta del valore dell'intestazione.
suffixMatch I tentativi vengono eseguiti in base al suffisso del valore dell'intestazione.
regexMatch I tentativi vengono eseguiti in base a una regola di espressione regolare in cui il valore dell'intestazione deve corrispondere al modello regex.
Errori

È possibile eseguire nuovi tentativi in caso di uno degli errori seguenti:

matches: {
  errors: [
    'retriable-headers'
    'retriable-status-codes'
    '5xx'
    'reset'
    'connect-failure'
    'retriable-4xx'
  ]
}
Metadati UFX Descrizione
retriable-headers Intestazioni di risposta HTTP che attivano un nuovo tentativo. Viene eseguito un nuovo tentativo se una delle corrispondenze di intestazione corrisponde alle intestazioni di risposta. Obbligatorio se si vuole riprovare su eventuali intestazioni corrispondenti.
retriable-status-codes Codici di stato HTTP che attivano nuovi tentativi. Obbligatorio se si vuole riprovare su qualsiasi codice di stato corrispondente.
5xx Riprovare se il server risponde con qualsiasi codice di risposta 5xx.
reset Riprovare se il server non risponde.
connect-failure Riprovare se una richiesta non è riuscita a causa di una connessione errata con l'app contenitore.
retriable-4xx Riprovare se l'app contenitore risponde con un codice di risposta serie 400, ad esempio 409.

tcpRetryPolicy

properties: {
    tcpRetryPolicy: {
        maxConnectAttempts: 3
    }
}
Metadati UFX Obbligatorio Descrizione Esempio
maxConnectAttempts Sì Impostare il numero massimo di tentativi di connessione (maxConnectionAttempts) per riprovare le connessioni non riuscite. 3

Interruttori

I criteri dell'interruttore specificano se una replica dell'app contenitore viene temporaneamente rimossa dal pool di bilanciamento del carico, in base a trigger come il numero di errori consecutivi.

properties: {
    circuitBreakerPolicy: {
        consecutiveErrors: 5
        intervalInSeconds: 10
        maxEjectionPercent: 50
    }
}
Metadati UFX Obbligatorio Descrizione Esempio
consecutiveErrors Sì Numero consecutivo di errori prima che una replica dell'app contenitore venga temporaneamente rimossa dal bilanciamento del carico. 5
intervalInSeconds Sì Quantità di tempo specificata per determinare se una replica viene rimossa o ripristinata dal pool di bilanciamento del carico. 10
maxEjectionPercent Sì Percentuale massima di repliche dell'app contenitore non riuscite da espellere dal bilanciamento del carico. Rimuove almeno un host indipendentemente dal valore. 50

Pool di connessioni

Il pool di connessioni dell'App contenitore di Azure gestisce un pool di connessioni stabilite e riutilizzabili alle app contenitore. Questo pool di connessioni riduce il sovraccarico della creazione e della rimozione di singole connessioni per ogni richiesta.

I pool di connessioni consentono di specificare il numero massimo di richieste o connessioni consentite per un servizio. Questi limiti controllano il numero totale di connessioni simultanee per ogni servizio. Quando viene raggiunto questo limite, le nuove connessioni non vengono stabilite al servizio finché non vengono rilasciate o chiuse le connessioni esistenti. Questo processo di gestione delle connessioni impedisce il sovraccarico delle risorse da parte delle richieste e mantiene un'efficienza elevata.

httpConnectionPool

properties: {
    httpConnectionPool: {
        http1MaxPendingRequests: 1024
        http2MaxRequests: 1024
    }
}
Metadati UFX Obbligatorio Descrizione Esempio
http1MaxPendingRequests Sì Usato per le richieste di http1. Numero massimo di connessioni aperte a un'app contenitore. 1024
http2MaxRequests Sì Usato per le richieste di http2. Numero massimo di richieste simultanee a un'app contenitore. 1024

tcpConnectionPool

properties: {
    tcpConnectionPool: {
        maxConnections: 100
    }
}
Metadati UFX Obbligatorio Descrizione Esempio
maxConnections Sì Numero massimo di connessioni simultanee a un'app contenitore. 100

Osservabilità della resilienza

È possibile eseguire l'osservabilità della resilienza tramite le metriche e i log di sistema dell'app contenitore.

Log di resilienza

Nella sezione Monitoraggio dell'app contenitore selezionare Log.

Screenshot che illustra dove trovare i log per l'app contenitore.

Nel riquadro Log scrivere ed eseguire una query per trovare la resilienza tramite i log di sistema dell'app contenitore. Ad esempio, eseguire una query simile alla seguente per cercare gli eventi di resilienza e visualizzare i relativi elementi:

  • Timestamp
  • Nome ambiente
  • Nome app contenitore
  • Tipo di resilienza e motivo
  • Messaggi di log
ContainerAppSystemLogs_CL
| where EventSource_s == "Resiliency"
| project TimeStamp_s, EnvironmentName_s, ContainerAppName_s, Type_s, EventSource_s, Reason_s, Log_s

Fare clic su Esegui per eseguire la query e visualizzare i risultati.

Screenshot che mostra i risultati delle query con resilienza in base all'esempio di query fornito.

Metriche di resilienza

Nel menu Monitoraggio dell'app contenitore selezionare Metriche. Nel riquadro Metriche selezionare i filtri seguenti:

  • Ambito del nome dell'app contenitore.
  • Spazio dei nomi delle metriche Metriche standard.
  • Metriche di resilienza dal menu a discesa.
  • Come si vogliono aggregare i dati nei risultati (per media, per massimo e così via).
  • Durata (ultimi 30 minuti, ultime 24 ore e così via).

Screenshot che illustra come accedere ai filtri delle metriche di resilienza per l'app contenitore.

Ad esempio, se si imposta la metrica Tentativi richieste di resilienza nell'ambito test-app con aggregazione Media per eseguire la ricerca in un intervallo di tempo di 30 minuti, i risultati sono simili ai seguenti:

Screenshot che mostra i risultati dei filtri delle metriche di esempio per la resilienza.

Contenuto correlato

Informazioni sul funzionamento della resilienza per i Componenti dapr in App contenitore di Azure.