Odporność odnajdywania usług (wersja zapoznawcza)

  • Artykuł

Dzięki odporności usługi Azure Container Apps można aktywnie zapobiegać, wykrywać i odzyskiwać żądania obsługi przy użyciu prostych zasad odporności. Z tego artykułu dowiesz się, jak skonfigurować zasady odporności usługi Azure Container Apps podczas inicjowania żądań przy użyciu odnajdywania usługi Azure Container Apps.

Uwaga

Obecnie nie można zastosować zasad odporności do żądań wysyłanych przy użyciu interfejsu API wywołania usługi Dapr.

Zasady obowiązują dla każdego żądania do aplikacji kontenera. Zasady można dostosować do aplikacji kontenera akceptującej żądania przy użyciu konfiguracji, takich jak:

  • Liczba ponownych prób
  • Czas trwania ponawiania prób i przekroczenia limitu czasu
  • Ponów próbę dopasowania
  • Wyłącznik kolejne błędy i inne

Poniższy zrzut ekranu przedstawia sposób, w jaki aplikacja używa zasad ponawiania prób odzyskania po żądaniach, które zakończyły się niepowodzeniem.

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

Obsługiwane zasady odporności

Konfigurowanie zasad odporności

Niezależnie od tego, czy zasady odporności są konfigurowane przy użyciu aplikacji Bicep, interfejsu wiersza polecenia czy witryny Azure Portal, można zastosować tylko jedną zasadę dla aplikacji kontenera.

Po zastosowaniu zasad do aplikacji kontenera reguły są stosowane do wszystkich żądań wysyłanych do tej aplikacji kontenera, a nie do żądań wysyłanych z tej aplikacji kontenera. Na przykład zasady ponawiania są stosowane do aplikacji kontenera o nazwie App B. Wszystkie żądania przychodzące wysyłane do aplikacji B są automatycznie ponawiane po niepowodzeniu. Jednak żądania wychodzące wysyłane przez aplikację B nie mają gwarancji ponawiania próby w przypadku niepowodzenia.

Poniższy przykład odporności przedstawia wszystkie dostępne konfiguracje.

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

Specyfikacje zasad

Limity czasu

Limity czasu są używane do wczesnego zakończenia długotrwałych operacji. Zasady limitu czasu zawierają następujące właściwości.

properties: {
  timeoutPolicy: {
      responseTimeoutInSeconds: 15
      connectionTimeoutInSeconds: 5
  }
}
Metadane Wymagania opis Przykład
responseTimeoutInSeconds Tak Limit czasu oczekiwania na odpowiedź z aplikacji kontenera. 15
connectionTimeoutInSeconds Tak Limit czasu nawiązywania połączenia z aplikacją kontenera. 5

Ponowne próby

Zdefiniuj strategię tcpRetryPolicy lub dla operacji, które zakończyły się niepowodzeniem httpRetryPolicy . Zasady ponawiania prób obejmują następujące konfiguracje.

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'
            ]
        }
    } 
}
Metadane Wymagania opis Przykład
maxRetries Tak Maksymalna liczba ponownych prób do wykonania dla nieudanego żądania HTTP. 5
retryBackOff Tak Monitoruj żądania i wyłącza cały ruch do usługi, której dotyczy ten wpływ, po przekroczeniu limitu czasu i spełnieniu kryteriów ponawiania prób. Nie dotyczy
retryBackOff.initialDelayInMilliseconds Tak Opóźnienie między pierwszym błędem a pierwszą ponowną próbą. 1000
retryBackOff.maxIntervalInMilliseconds Tak Maksymalne opóźnienie między ponownych prób. 10000
matches Tak Ustaw wartości dopasowania, aby ograniczyć, kiedy aplikacja powinna spróbować ponowić próbę. headers, httpStatusCodes, errors
matches.headers Y* Ponów próbę, gdy odpowiedź o błędzie zawiera określony nagłówek. *Nagłówki są wymagane tylko w przypadku określenia retriable-headers właściwości error. Dowiedz się więcej o dostępnych dopasowaniach nagłówka. X-Content-Type
matches.httpStatusCodes Y* Spróbuj ponownie, gdy odpowiedź zwróci określony kod stanu. *Kody stanu są wymagane tylko w przypadku określenia retriable-status-codes właściwości error. 502, 503
matches.errors Tak Ponawia próbę tylko wtedy, gdy aplikacja zwróci określony błąd. Dowiedz się więcej o dostępnych błędach. connect-failure, reset
Dopasowania nagłówka

Jeśli określono retriable-headers błąd, możesz użyć następujących właściwości dopasowania nagłówka, aby ponowić próbę, gdy odpowiedź zawiera określony nagłówek.

matches: {
  headers: [
    { 
      header: 'x-ms-retriable'
      match: {
        exactMatch: 'true'
      }
    }
  ]
}
Metadane opis
prefixMatch Ponowne próby są wykonywane na podstawie prefiksu wartości nagłówka.
exactMatch Ponowne próby są wykonywane na podstawie dokładnego dopasowania wartości nagłówka.
suffixMatch Ponowne próby są wykonywane na podstawie sufiksu wartości nagłówka.
regexMatch Ponowne próby są wykonywane na podstawie reguły wyrażenia regularnego, w której wartość nagłówka musi być zgodna ze wzorcem wyrażenia regularnego.
Błędy

Ponawianie prób można wykonać na dowolnym z następujących błędów:

matches: {
  errors: [
    'retriable-headers'
    'retriable-status-codes'
    '5xx'
    'reset'
    'connect-failure'
    'retriable-4xx'
  ]
}
Metadane opis
retriable-headers Nagłówki odpowiedzi HTTP, które wyzwalają ponowienie próby. Ponowna próba jest wykonywana, jeśli którykolwiek z nagłówków pasuje do nagłówków odpowiedzi. Wymagane, jeśli chcesz ponowić próbę na dowolnych pasujących nagłówkach.
retriable-status-codes Kody stanu HTTP, które powinny wyzwalać ponawianie prób. Wymagane, jeśli chcesz ponowić próbę w przypadku jakichkolwiek pasujących kodów stanu.
5xx Ponów próbę, jeśli serwer odpowiada z dowolnymi kodami odpowiedzi 5xx.
reset Spróbuj ponownie, jeśli serwer nie odpowie.
connect-failure Ponów próbę, jeśli żądanie nie powiodło się z powodu błędnego połączenia z aplikacją kontenera.
retriable-4xx Spróbuj ponownie, jeśli aplikacja kontenera odpowie kodem odpowiedzi serii 400, na przykład 409.

tcpRetryPolicy

properties: {
    tcpRetryPolicy: {
        maxConnectAttempts: 3
    }
}
Metadane Wymagania opis Przykład
maxConnectAttempts Tak Ustaw maksymalną liczbę prób nawiązania połączenia (maxConnectionAttempts), aby ponowić próbę w przypadku połączeń, które zakończyły się niepowodzeniem. 3

Wyłączniki

Zasady wyłącznika określają, czy replika aplikacji kontenera jest tymczasowo usuwana z puli równoważenia obciążenia, na podstawie wyzwalaczy, takich jak liczba kolejnych błędów.

properties: {
    circuitBreakerPolicy: {
        consecutiveErrors: 5
        intervalInSeconds: 10
        maxEjectionPercent: 50
    }
}
Metadane Wymagania opis Przykład
consecutiveErrors Tak Kolejna liczba błędów przed tymczasowe usunięciem repliki aplikacji kontenera z równoważenia obciążenia. 5
intervalInSeconds Tak Czas określony do określenia, czy replika została usunięta lub przywrócona z puli równoważenia obciążenia. 10
maxEjectionPercent Tak Maksymalny procent niepowodzenia replik aplikacji kontenera do wysuwania z równoważenia obciążenia. Usuwa co najmniej jednego hosta niezależnie od wartości. 50

Pule Połączenie ion

Pula połączeń aplikacji kontenera platformy Azure obsługuje pulę ustanowionych i wielokrotnego użytku połączeń z aplikacjami kontenerów. Ta pula połączeń zmniejsza nakład pracy związany z tworzeniem i usuwaniem poszczególnych połączeń dla każdego żądania.

pule Połączenie ion umożliwiają określenie maksymalnej liczby żądań lub połączeń dozwolonych dla usługi. Te limity kontrolują łączną liczbę współbieżnych połączeń dla każdej usługi. Po osiągnięciu tego limitu nowe połączenia nie zostaną nawiązane z tą usługą, dopóki istniejące połączenia nie zostaną zwolnione lub zamknięte. Ten proces zarządzania połączeniami uniemożliwia przeciążenie zasobów żądaniami i utrzymanie wydajnego zarządzania połączeniami.

http Połączenie ionPool

properties: {
    httpConnectionPool: {
        http1MaxPendingRequests: 1024
        http2MaxRequests: 1024
    }
}
Metadane Wymagania opis Przykład
http1MaxPendingRequests Tak Służy do http1 obsługi żądań. Maksymalna liczba otwartych połączeń z aplikacją kontenera. 1024
http2MaxRequests Tak Służy do http2 obsługi żądań. Maksymalna liczba współbieżnych żądań do aplikacji kontenera. 1024

tcp Połączenie ionPool

properties: {
    tcpConnectionPool: {
        maxConnections: 100
    }
}
Metadane Wymagania opis Przykład
maxConnections Tak Maksymalna liczba współbieżnych połączeń z aplikacją kontenera. 100

Możliwość obserwacji odporności

Możliwość obserwowania odporności można wykonywać za pomocą metryk i dzienników systemowych aplikacji kontenera.

Dzienniki odporności

W sekcji Monitorowanie aplikacji kontenera wybierz pozycję Dzienniki.

Screenshot demonstrating where to find the logs for your container app.

W okienku Dzienniki napisz i uruchom zapytanie, aby znaleźć odporność za pośrednictwem dzienników systemu aplikacji kontenera. Na przykład uruchom zapytanie podobne do poniższego, aby wyszukać zdarzenia odporności i wyświetlić je:

  • Sygnatura czasowa
  • Nazwa środowiska
  • Nazwa aplikacji kontenera
  • Typ odporności i przyczyna
  • Komunikaty dziennika
ContainerAppSystemLogs_CL
| where EventSource_s == "Resiliency"
| project TimeStamp_s, EnvironmentName_s, ContainerAppName_s, Type_s, EventSource_s, Reason_s, Log_s

Kliknij przycisk Uruchom , aby uruchomić zapytanie i wyświetlić wyniki.

Screenshot showing resiliency query results based on provided query example.

Metryki odporności

Z menu Monitorowanie aplikacji kontenera wybierz pozycję Metryki. W okienku Metryki wybierz następujące filtry:

  • Zakres do nazwy aplikacji kontenera.
  • Przestrzeń nazw metryk standardowych.
  • Metryki odporności z menu rozwijanego.
  • Jak chcesz, aby dane zagregowane w wynikach (według średniej, maksymalnej itp.).
  • Czas trwania (ostatnie 30 minut, ostatnie 24 godziny itp.).

Screenshot demonstrating how to access the resiliency metrics filters for your container app.

Jeśli na przykład ustawisz metrykę Żądania odporności ponawiania prób w zakresie test-aplikacji z wartością Średnia agregacja do wyszukiwania w przedziale czasu 30 minut, wyniki wyglądają następująco:

Screenshot showing the results from example metrics filters for resiliency.

Powiązana zawartość

Zobacz, jak działa odporność składników języka Dapr w usłudze Azure Container Apps.