Устойчивость обнаружения сервисов (предварительная версия)

Благодаря устойчивости приложений контейнеров Azure можно заранее предотвращать, обнаруживать и восстанавливать сбои запросов на обслуживание с помощью простых политик устойчивости. Из этой статьи вы узнаете, как настроить политики отказоустойчивости Контейнеры приложений Azure при инициации запросов с использованием обнаружения служб Контейнеры приложений Azure.

Каждый запрос к приложению-контейнеру применяет политики. Вы можете настроить политики в приложении-контейнере, которое принимает запросы с такими конфигурациями:

• Количество повторных попыток
• Длительность повтора и времени ожидания
• Повторная попытка сопоставления
• Последовательные ошибки разбиения цепи и другие

На следующем снимку экрана показано, как приложение использует политику повторных попыток для восстановления после неудачных запросов.

Поддерживаемые политики устойчивости

• Время ожидания
• Повторные попытки (HTTP и TCP)
• Автоматические выключатели
• Пулы подключений (HTTP и TCP)

Настройка политик устойчивости

Независимо от того, настраиваете ли политики устойчивости с помощью Bicep, интерфейса командной строки или портала Azure, можно применять только одну политику для каждого приложения контейнера.

При применении политики к приложению-контейнеру правила применяются ко всем запросам, сделанным к приложению контейнера, а не к запросам, сделанным из этого приложения контейнера. Например, политика повторных попыток применяется к приложению-контейнеру с именем App B. Все входящие запросы, сделанные в App B, автоматически отправляются повторно в случае сбоя. Однако исходящие запросы, отправленные приложением B, не гарантируют повторную попытку в случае сбоя.

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

Спецификации политик

Время ожидания

Таймауты прерывают длительные операции. Политика времени ожидания включает следующие свойства.

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

Повторные попытки

Определите tcpRetryPolicy или стратегию httpRetryPolicy для неудачных операций. Политика повторных попыток включает следующие конфигурации.

Политика повторных попыток HTTP (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'
            ]
        }
    } 
}

Совпадения заголовков

Если указать ошибку retriable-headers , можно использовать следующие свойства сопоставления заголовков, чтобы повторить попытку, если ответ включает определенный заголовок.

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

ошибки

Вы можете повторить попытку при любой из следующих ошибок.

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

tcpRetryPolicy

properties: {
    tcpRetryPolicy: {
        maxConnectAttempts: 3
    }
}

Выключатели

Политики выключателя цепи указывают, удаляется ли временно реплика приложения-контейнера из пула балансировки нагрузки на основе триггеров, таких как количество последовательных ошибок.

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

Пулы подключений

Пул подключений Контейнеры приложений Azure поддерживает набор установленных и повторно используемых подключений к контейнерным приложениям. Этот пул подключений снижает затраты на создание и разрыв отдельных подключений для каждого запроса.

Пулы подключений позволяют указать максимальное количество запросов или подключений, разрешенных для службы. Эти ограничения управляют общим количеством одновременных подключений для каждой службы. По достижении этого ограничения новые подключения не устанавливаются в эту службу до тех пор, пока существующие подключения не будут освобождены или закрыты. Этот процесс управления подключениями предотвращает перегрузку ресурсов запросами и обеспечивает эффективное управление подключениями.

пул HTTP-соединений

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

пул TCP соединений

properties: {
    tcpConnectionPool: {
        maxConnections: 100
    }
}

Наблюдаемость устойчивости

Вы можете выполнять наблюдение за устойчивостью с помощью метрик и системных журналов приложения контейнера.

Журналы устойчивости

В разделе Мониторинг приложения-контейнера выберите Журналы.

В области журналов напишите и запустите запрос, чтобы найти события устойчивости в журналах системы приложений контейнера. Например, выполните запрос, аналогичный следующему запросу, чтобы найти события устойчивости и показать их:

• Отметка времени
• Имя среды
• Имя приложения-контейнера
• Тип устойчивости и причина
• Лог-сообщения

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

Выберите "Выполнить" , чтобы запустить запрос и просмотреть результаты.

Метрики устойчивости

В меню "Мониторинг" приложения-контейнера выберите Метрики. В области метрик выберите следующие фильтры:

• Область применения имени вашего контейнерного приложения.
• Пространство имен метрик Standard metrics.
• Метрики устойчивости из раскрывающегося меню.
• Как вы хотите, чтобы данные агрегировались в результатах (по среднему, по максимальному значению и т. д.).
• Длительность времени (например, последние 30 минут или последние 24 часа).

Например, если вы задали метрику "Запрос на устойчивость" в области тестового приложения со средней агрегацией для поиска в течение 30-минутного интервала времени, результаты выглядят следующим образом:

Связанный контент

Узнайте, как работает устойчивость компонентов Dapr в приложениях контейнеров Azure.