Teilen über

Resilienz bei der Dienstsuche (Vorschau)

  • Artikel

Mit der Resilienz 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 Resilienzsrichtlinien für Azure Container Apps konfigurieren, wenn Sie Anforderungen mithilfe der Azure Container-Apps-Dienstermittlung initiieren.

Hinweis

Derzeit können Resilienzrichtlinien nicht auf Anforderungen angewendet werden, die mit der Dapr-Dienstaufruf-API vorgenommen wurden.

Richtlinien gelten für jede Anforderung an eine Container-App. Sie können die Richtlinien für die Container-App, die Anfragen annimmt, mit Konfigurationen wie der folgenden anpassen:

  • 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.

Diagramm, das die Resilienz von Container-App zu Container-App mit dem Dienstnamen einer Container-App veranschaulicht.

Unterstützte Resilienzrichtlinien

Konfigurieren von Resilienzrichtlinien

Unabhängig davon, ob Sie Resilienzrichtlinien mit Bicep, dem 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, werden die Regeln auf alle Anforderungen angewendet, die bei dieser Container-App vorgenommen wurden, nicht auf 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.

Im folgenden Beispiel zur Resilienz werden alle verfügbaren Konfigurationen veranschaulicht.

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

Richtlinienspezifikationen

Zeitlimits

Timeouts werden verwendet, um lang laufende Vorgänge frühzeitig zu beenden. Die Timeoutrichtlinie enthält die folgenden Eigenschaften.

properties: {
  timeoutPolicy: {
      responseTimeoutInSeconds: 15
      connectionTimeoutInSeconds: 5
  }
}
Metadaten Erforderlich Beschreibung Beispiel
responseTimeoutInSeconds Ja Timeout, das auf eine Antwort der Container-App wartet. 15
connectionTimeoutInSeconds Ja Timeout zum Herstellen einer Verbindung mit der Container-App. 5

Retries

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'
            ]
        }
    } 
}
Metadaten Erforderlich Beschreibung Beispiel
maxRetries Ja Maximale Wiederholungsversuche, die für eine fehlgeschlagene HTTP-Anforderung ausgeführt werden sollen. 5
retryBackOff Ja Überwachen Sie die Anforderungen, und beenden Sie den gesamten Datenverkehr für den betroffenen Dienst, wenn Timeout- und Wiederholungskriterien erfüllt sind. Nicht zutreffend
retryBackOff.initialDelayInMilliseconds Ja Verzögerung zwischen dem ersten Fehler und dem ersten Wiederholungsversuch. 1000
retryBackOff.maxIntervalInMilliseconds Ja Maximale Verzögerung zwischen Wiederholungsversuchen. 10000
matches Ja Legen Sie Übereinstimmungswerte fest, um einzuschränken, wann die Anwendung einen Wiederholungsversuch unternehmen soll. headers, httpStatusCodes, errors
matches.headers J* Wiederholung, wenn die Fehlerantwort eine bestimmte Kopfzeile enthält. *Kopfzeilen sind nur erforderliche Eigenschaften, wenn Sie die Fehlereigenschaft retriable-headers angeben. Weitere Informationen zu verfügbaren Kopfzeilenüberstimmungen. X-Content-Type
matches.httpStatusCodes J* Wiederholen Sie den Vorgang, wenn die Antwort einen bestimmten Statuscode zurückgibt. *Statuscodes sind nur erforderliche Eigenschaften, wenn Sie die Fehlereigenschaft retriable-status-codes angeben. 502, 503
matches.errors Ja Wiederholt nur, wenn die App einen bestimmten Fehler zurückgibt. Weitere Informationen zu verfügbaren Fehlern. connect-failure, reset
Kopfzeilenüberstimmungen

Wenn Sie den Fehler retriable-headers angegeben haben, können Sie die Eigenschaften der folgenden Kopfzeilenübereinstimmung verwenden, um es erneut zu versuchen, wenn die Antwort eine bestimmte Kopfzeile enthält.

matches: {
  headers: [
    { 
      header: 'x-ms-retriable'
      match: {
        exactMatch: 'true'
      }
    }
  ]
}
Metadaten Beschreibung
prefixMatch Wiederholungsversuche werden auf der Grundlage des Präfix des Kopfzeilenwerts durchgeführt.
exactMatch Wiederholungen werden basierend auf einer genauen Übereinstimmung des Kopfzeilenwerts ausgeführt.
suffixMatch Wiederholungsversuche werden auf der Grundlage des Suffix des Kopfzeilenwerts durchgeführt.
regexMatch Wiederholungsversuche werden auf der Grundlage einer Regel für reguläre Ausdrücke durchgeführt, wobei der Kopfzeilenwert mit dem Regex-Muster übereinstimmen muss.
Fehler

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'
  ]
}
Metadaten Beschreibung
retriable-headers HTTP-Antwortheader, die einen Wiederholungsversuch auslösen. Eine Wiederholung wird ausgeführt, wenn eine der Kopfzeilenübereinstimmungen mit den Antwortheadern übereinstimmt. Erforderlich, wenn Sie alle übereinstimmenden Kopfzeilen wiederholen möchten.
retriable-status-codes HTTP-Statuscodes, die Wiederholungen auslösen sollen. Erforderlich, wenn Sie alle übereinstimmenden Statuscodes wiederholen möchten.
5xx Wiederholung, wenn der Server mit einem beliebigen 5xx-Antwortcode antwortet.
reset Wiederholung, wenn der Server nicht antwortet.
connect-failure Wiederholung, wenn eine Anfrage aufgrund einer fehlerhaften Verbindung mit der Container-App fehlgeschlagen ist.
retriable-4xx Wiederholung, wenn die Container-App mit einem Antwortcode der 400er-Reihe antwortet, wie z. B. 409.

tcpRetryPolicy

properties: {
    tcpRetryPolicy: {
        maxConnectAttempts: 3
    }
}
Metadaten Erforderlich Beschreibung Beispiel
maxConnectAttempts Ja Legen Sie die maximalen Verbindungsversuche (maxConnectionAttempts) fest, die bei fehlgeschlagenen Verbindungen wiederholt werden sollen. 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
    }
}
Metadaten Erforderlich Beschreibung Beispiel
consecutiveErrors Ja Fortlaufende Anzahl von Fehlern, bevor ein Container-App-Replikat vorübergehend aus dem Lastenausgleich entfernt wird. 5
intervalInSeconds Ja Die Zeitspanne, die benötigt wird, um festzustellen, ob ein Replikat aus dem Lastausgleichspool entfernt oder wiederhergestellt wurde. 10
maxEjectionPercent Ja Maximaler Prozentsatz der ausfallenden Container-App-Replikate, die aus dem Lastausgleich entfernt werden. Entfernt mindestens einen Host unabhängig vom Wert. 50

Verbindungspools

Das Verbindungspooling von Azure-Container-App verwaltet einen Pool von etablierten und wiederverwendbaren Verbindungen zu 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
    }
}
Metadaten Erforderlich Beschreibung Beispiel
http1MaxPendingRequests Ja Wird für http1-Anforderungen verwendet. Maximale Anzahl geöffneter Verbindungen mit einer Container-App. 1024
http2MaxRequests Ja Wird für http2-Anforderungen verwendet. Maximale Anzahl gleichzeitiger Anforderungen an eine Container-App. 1024

tcpConnectionPool

properties: {
    tcpConnectionPool: {
        maxConnections: 100
    }
}
Metadaten Erforderlich Beschreibung Beispiel
maxConnections Ja Maximale Anzahl gleichzeitiger Verbindungen mit einer Container-App. 100

Beobachten der Resilienz

Sie können die Resilienz über die Metriken und Systemprotokolle Ihrer Container-Anwendung beobachten.

Resilienzprotokolle

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

Screenshot: Speicherort der Protokolle für Ihre Container-App.

Schreiben Sie im Protokollbereich eine Abfrage und führen diese aus, um Resilienz über Ihre Container-App-Systemprotokolle zu finden. Führen Sie zum Beispiel eine Abfrage ähnlich der folgenden aus, um nach Resilienzereignissen zu suchen und diese 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

Klicken Sie auf Ausführen, um die Abfrage auszuführen und resultierende Ergebnisse anzuzeigen.

Screenshot: Ergebnisse der Resilienzabfrage basierend auf dem bereitgestellten Abfragebeispiel.

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 (letzte 30 Minuten, letzte 24 Stunden usw.).

Screenshot: Zugriff auf die Resilienzmetrikenfilter für Ihre Container-App.

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:

Screenshot: Ergebnisse der Beispielmetrikenfilter für die Resilienz.

Zugehöriger Inhalt

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