Share via

Resilienza dell'individuazione dei servizi (anteprima)

  • Articolo

Con la resilienza di App Azure Container, è 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 Azure Container quando si avviano le richieste usando l'individuazione del servizio App Azure Container.

Nota

Attualmente, i criteri di resilienza non possono essere applicati alle richieste effettuate tramite l'API 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:

  • Numero di tentativi
  • Durata dei tentativi e del timeout
  • Riprovare corrispondenze
  • Errori consecutivi dell'interruttore e altri

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

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

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 la 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 dall'app contenitore. 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 Richiesto 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 una tcpRetryPolicy strategia o per httpRetryPolicy le operazioni non riuscite. I criteri di ripetizione dei tentativi 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 Richiesto 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 da limitare quando l'app deve tentare 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 retriable-headers proprietà error. 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 retriable-status-codes proprietà error. 502, 503
matches.errors Sì Solo i tentativi 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.
Errors

È possibile eseguire nuovi tentativi in 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 devono attivare 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 Richiesto Descrizione Esempio
maxConnectAttempts Sì Impostare il numero massimo di tentativi di connessione (maxConnectionAttempts) per ritentare 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 Richiesto 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 Connessione ion

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

Connessione pool 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 una gestione efficiente delle connessioni.

http Connessione ionPool

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

tcp Connessione ionPool

properties: {
    tcpConnectionPool: {
        maxConnections: 100
    }
}
Metadati UFX Richiesto 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 demonstrating where to find the logs for your container app.

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 dell'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 showing resiliency query results based on provided query example.

Metriche di resilienza

Dal 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 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 demonstrating how to access the resiliency metrics filters for your container app.

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

Screenshot showing the results from example metrics filters for resiliency.

Contenuto correlato

Informazioni sul funzionamento della resilienza per i componenti dapr in App Contenitore di Azure.