Resilienz bei der Dienstsuche (Vorschau)

Mit der Ausfallsicherheit von Azure-Container-Apps können Sie mithilfe einfacher Resilienzrichtlinien proaktiv Fehler bei Serviceanfragen verhindern, erkennen und wiederherstellen. In diesem Artikel erfahren Sie, wie Sie Ausfallsicherheitsrichtlinien für Azure-Container-Apps beim Initiieren von Anforderungen mithilfe der Azure Container Apps-Dienstermittlung konfigurieren.

Jede Anforderung an eine Container-App erzwingt Richtlinien. Sie können Richtlinien an die Container-App anpassen, die Anforderungen mit Konfigurationen wie den folgenden akzeptiert:

• Anzahl der Wiederholungsversuche
• Wiederholungs- und Timeoutdauer
• Wiederholungsversuche
• Aufeinander folgende Fehler beim Trennschalter und andere

Der folgende Screenshot zeigt, wie eine Anwendung eine Wiederholungsrichtlinie verwendet, um zu versuchen, aus fehlgeschlagenen Anforderungen wiederherzustellen.

Unterstützte Resilienzrichtlinien

• Timeouts
• Wiederholungen (HTTP und TCP)
• Trennschalter
• Verbindungspools (HTTP und TCP)

Konfigurieren von Resilienzrichtlinien

Unabhängig davon, ob Sie Resilienzrichtlinien mithilfe von Bicep, der CLI oder dem Azure-Portal konfigurieren, können Sie nur eine Richtlinie pro Container-App anwenden.

Wenn Sie eine Richtlinie auf eine Container-App anwenden, gelten die Regeln für alle Anforderungen an diese Container-App, nicht für Anforderungen, die von dieser Container-App vorgenommen wurden. Beispielsweise wird eine Wiederholungsrichtlinie auf eine Container-App mit dem Namen App B angewendet. Alle an App B gerichteten eingehenden Anfragen werden bei einem Fehler automatisch wiederholt. Bei ausgehenden Anforderungen, die von App B gesendet werden, wird jedoch nicht garantiert, dass sie im Fehlerfall wiederholt werden.

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

az login

az extension show --name containerapp
az extension update --name containerapp

az containerapp resiliency create --group MyResourceGroup --name MyResiliencyName --container-app-name MyContainerApp --recommended

httpRetryPolicy:
  matches:
    errors:
    - 5xx
  maxRetries: 3
  retryBackOff:
    initialDelayInMilliseconds: 1000
    maxIntervalInMilliseconds: 10000
tcpRetryPolicy:
  maxConnectAttempts: 3
timeoutPolicy:
  connectionTimeoutInSeconds: 5
  responseTimeoutInSeconds: 60
circuitBreakerPolicy:
  consecutiveErrors: 5
  intervalInSeconds: 10
  maxEjectionPercent: 100

az containerapp resiliency update --group MyResourceGroup --name MyResiliency --container-app-name MyContainerApp --timeout 20 --timeout-connect 5

az containerapp resiliency create --group MyResourceGroup –n MyResiliency --container-app-name MyContainerApp –yaml <MY_YAML_FILE>

timeoutPolicy:
  responseTimeoutInSeconds: 30
  connectionTimeoutInSeconds: 5
httpRetryPolicy:
  maxRetries: 5
  retryBackOff:
    initialDelayInMilliseconds: 1000
    maxIntervalInMilliseconds: 10000
  matches:
    errors:
      - retriable-headers
      - retriable-status-codes
tcpRetryPolicy:
  maxConnectAttempts: 3
circuitBreakerPolicy:
  consecutiveErrors: 5
  intervalInSeconds: 10
  maxEjectionPercent: 50
tcpConnectionPool:
  maxConnections: 100
httpConnectionPool:
  http1MaxPendingRequests: 1024
  http2MaxRequests: 1024

az containerapp resiliency update --group MyResourceGroup --name MyResiliency --container-app-name MyContainerApp --timeout 20

az containerapp resiliency update --name MyResiliency --group MyResourceGroup --container-app-name MyContainerApp --yaml <MY_YAML_FILE>

az containerapp resiliency list --group MyResourceGroup --container-app-name MyContainerApp​

az containerapp resiliency show --group MyResourceGroup --name MyResiliency --container-app-name ​MyContainerApp

az containerapp resiliency delete --group MyResourceGroup --name MyResiliency --container-app-name ​MyContainerApp

Richtlinienspezifikationen

Zeitlimits

Timeouts führen zum vorzeitigen Abbruch von lang andauernden Vorgängen. Die Timeoutrichtlinie enthält die folgenden Eigenschaften.

properties: {
  timeoutPolicy: {
      responseTimeoutInSeconds: 15
      connectionTimeoutInSeconds: 5
  }
}

Wiederholungsversuche

Definieren Sie eine tcpRetryPolicy- oder eine httpRetryPolicy-Strategie für fehlgeschlagene Vorgänge. Die Wiederholungsrichtlinie enthält die folgenden Konfigurationen.

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

Kopfzeilenüberstimmungen

Wenn Sie den retriable-headers Fehler angeben, können Sie die folgenden Header-Abgleichseigenschaften verwenden, um es erneut zu versuchen, wenn die Antwort einen bestimmten Header enthält.

matches: {
  headers: [
    { 
      header: 'x-ms-retriable'
      match: {
        exactMatch: 'true'
      }
    }
  ]
}

Errors

Sie können Wiederholungen für einen der folgenden Fehler ausführen:

matches: {
  errors: [
    'retriable-headers'
    'retriable-status-codes'
    '5xx'
    'reset'
    'connect-failure'
    'retriable-4xx'
  ]
}

tcpRetryPolicy

properties: {
    tcpRetryPolicy: {
        maxConnectAttempts: 3
    }
}

Trennschalter

Richtlinien für Trennschalter legen fest, ob eine Container-App-Replik vorübergehend aus dem Lastenausgleichspool entfernt wird, basierend auf Auslösern wie der Anzahl der aufeinanderfolgenden Fehler.

properties: {
    circuitBreakerPolicy: {
        consecutiveErrors: 5
        intervalInSeconds: 10
        maxEjectionPercent: 50
    }
}

Verbindungspools

Azure Container Apps-Verbindungspooling verwaltet einen Pool etablierter und wiederverwendbarer Verbindungen mit Container-Apps. Dieser Verbindungspool reduziert den Aufwand für den Auf- und Abbau einzelner Verbindungen für jede Anfrage.

Mit Verbindungspools können Sie die maximale Anzahl von Anforderungen oder Verbindungen angeben, die für einen Dienst zulässig sind. Diese Grenzwerte steuern die Gesamtanzahl der gleichzeitigen Verbindungen für jeden Dienst. Wenn dieser Grenzwert erreicht ist, werden neue Verbindungen mit diesem Dienst erst hergestellt, wenn vorhandene Verbindungen freigegeben oder geschlossen werden. Dieser Prozess der Verbindungsverwaltung verhindert, dass die Ressourcen durch Anfragen überlastet werden und sorgt für eine effiziente Verbindungsverwaltung.

httpConnectionPool

properties: {
    httpConnectionPool: {
        http1MaxPendingRequests: 1024
        http2MaxRequests: 1024
    }
}

tcpConnectionPool

properties: {
    tcpConnectionPool: {
        maxConnections: 100
    }
}

Beobachten der Resilienz

Sie können Resilienz-Observability über die Metriken und Systemprotokolle Ihrer Container-App durchführen.

Resilienzprotokolle

Wählen Sie im Abschnitt Überwachung Ihrer Container-App die Option Protokolle aus.

Schreiben und ausführen Sie im Protokollbereich eine Abfrage, um Resilienzereignisse in Ihren Container-App-Systemprotokollen zu finden. Führen Sie beispielsweise eine Abfrage ähnlich der folgenden Abfrage aus, um nach Resilienzereignissen zu suchen und deren Ergebnisse anzuzeigen:

• Zeitstempel
• Umgebungsname
• Name der Container-App
• Resilienztyp und Grund
• Protokollmeldungen

ContainerAppSystemLogs_CL
| where EventSource_s == "Resiliency"
| project TimeStamp_s, EnvironmentName_s, ContainerAppName_s, Type_s, EventSource_s, Reason_s, Log_s

Wählen Sie "Ausführen" aus, um die Abfrage auszuführen und ergebnisse anzuzeigen.

Resilienzmetriken

Wählen Sie im Menü Überwachung Ihrer Container-App die Option Metriken aus. Wählen Sie im Bereich Metriken die folgenden Filter aus:

• Den Bereich für den Namen Ihrer Container-App.
• Den Metrik-Namespace für Standardmetriken.
• Die Resilienzmetriken aus dem Dropdownmenü.
• Wie die Daten in den Ergebnissen aggregiert werden sollen (durchschnittlich, nach Maximum usw.).
• Die Zeitdauer (z. B. letzte 30 Minuten oder letzte 24 Stunden).

Wenn Sie beispielsweise die Metrik Resilienzanforderungsversuche im Test-App-Bereich mit durchschnittlicher Aggregation festlegen, um innerhalb eines 30-minütigen Zeitrahmens zu suchen, sehen die Ergebnisse wie folgt aus:

Verwandte Inhalte

Erfahren Sie, wie Resilienz für Dapr-Komponenten in Azure Container Apps funktioniert.