Поделиться через

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

  • Статья

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

Примечание.

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

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

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

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

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

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

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

Если вы настраиваете политики устойчивости с помощью 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
    }
  }
}

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

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

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

properties: {
  timeoutPolicy: {
      responseTimeoutInSeconds: 15
      connectionTimeoutInSeconds: 5
  }
}
Метаданные Обязательное поле Описание Пример
responseTimeoutInSeconds Да Время ожидания ожидания ответа от приложения контейнера. 15
connectionTimeoutInSeconds Да Время ожидания для установления подключения к приложению-контейнеру. 5

Повторы

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

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'
            ]
        }
    } 
}
Метаданные Обязательное поле Описание Пример
maxRetries Да Максимальное количество повторных попыток, выполняемых для неудачного http-запроса. 5
retryBackOff Да Отслеживайте запросы и отключите весь трафик к затронутой службе при выполнении условий ожидания и повторных попыток. Н/П
retryBackOff.initialDelayInMilliseconds Да Задержка между первой ошибкой и первой попыткой. 1000
retryBackOff.maxIntervalInMilliseconds Да Максимальная задержка между повторными попытками. 10000
matches Да Задайте значения соответствия, чтобы ограничить, когда приложение должно попытаться повторить попытку. headers, , httpStatusCodeserrors
matches.headers Да* Повторите попытку, если ответ на ошибку содержит определенный заголовок. *Заголовки являются обязательными свойствами, если указать retriable-headers свойство ошибки. Дополнительные сведения о доступных совпадениях заголовков. X-Content-Type
matches.httpStatusCodes Да* Повторите попытку, когда ответ возвращает определенный код состояния. *Коды состояния являются обязательными свойствами, если указать retriable-status-codes свойство ошибки. 502, 503
matches.errors Да Повторяется только при возврате приложения определенной ошибки. Узнайте больше о доступных ошибках. connect-failure, reset
Совпадения заголовков

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

matches: {
  headers: [
    { 
      header: 'x-ms-retriable'
      match: {
        exactMatch: 'true'
      }
    }
  ]
}
Метаданные Description
prefixMatch Повторные попытки выполняются на основе префикса значения заголовка.
exactMatch Повторные попытки выполняются на основе точного соответствия значения заголовка.
suffixMatch Повторные попытки выполняются на основе суффикса значения заголовка.
regexMatch Повторные попытки выполняются на основе правила регулярного выражения, в котором значение заголовка должно соответствовать шаблону regex.
ошибки

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

matches: {
  errors: [
    'retriable-headers'
    'retriable-status-codes'
    '5xx'
    'reset'
    'connect-failure'
    'retriable-4xx'
  ]
}
Метаданные Description
retriable-headers Заголовки ответа HTTP, которые активируют повторную попытку. Повтор выполняется, если любое из совпадений заголовков соответствует заголовкам ответа. Требуется, если вы хотите повторить попытку в любых соответствующих заголовках.
retriable-status-codes Коды состояния HTTP, которые должны активировать повторные попытки. Требуется, если вы хотите повторить попытку в соответствии с соответствующими кодами состояния.
5xx Повторите попытку, если сервер отвечает с помощью любых кодов отклика 5xx.
reset Повторите попытку, если сервер не отвечает.
connect-failure Повторите попытку, если запрос завершился сбоем из-за сбоя подключения к приложению контейнера.
retriable-4xx Повторите попытку, если приложение-контейнер отвечает с кодом ответа серии 400, например 409.

tcpRetryPolicy

properties: {
    tcpRetryPolicy: {
        maxConnectAttempts: 3
    }
}
Метаданные Обязательное поле Описание Пример
maxConnectAttempts Да Задайте максимальное количество попыток подключения (maxConnectionAttempts) для повторных попыток при неудачных подключениях. 3

Выключатели

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

properties: {
    circuitBreakerPolicy: {
        consecutiveErrors: 5
        intervalInSeconds: 10
        maxEjectionPercent: 50
    }
}
Метаданные Обязательное поле Описание Пример
consecutiveErrors Да Последовательное количество ошибок перед временной репликой приложения-контейнера удаляется из балансировки нагрузки. 5
intervalInSeconds Да Время, заданное для определения того, удаляется ли реплика или восстанавливается из пула балансировки нагрузки. 10
maxEjectionPercent Да Максимальный процент отработки отказа реплик приложения-контейнера для извлечения из балансировки нагрузки. Удаляет по крайней мере один узел независимо от значения. 50

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

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

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

httpConnectionPool

properties: {
    httpConnectionPool: {
        http1MaxPendingRequests: 1024
        http2MaxRequests: 1024
    }
}
Метаданные Обязательное поле Описание Пример
http1MaxPendingRequests Да Используется для http1 запросов. Максимальное количество открытых подключений к приложению-контейнеру. 1024
http2MaxRequests Да Используется для http2 запросов. Максимальное количество одновременных запросов к приложению-контейнеру. 1024

tcpConnectionPool

properties: {
    tcpConnectionPool: {
        maxConnections: 100
    }
}
Метаданные Обязательное поле Описание Пример
maxConnections Да Максимальное количество одновременных подключений к приложению-контейнеру. 100

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

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

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

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

Снимок экрана, показывающий, где найти журналы для приложения-контейнера.

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

  • Отметка времени
  • Имя среды
  • Имя приложения-контейнера
  • Тип устойчивости и причина
  • Сообщения журнала
ContainerAppSystemLogs_CL
| where EventSource_s == "Resiliency"
| project TimeStamp_s, EnvironmentName_s, ContainerAppName_s, Type_s, EventSource_s, Reason_s, Log_s

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

Снимок экрана: результаты запроса устойчивости на основе предоставленного примера запроса.

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

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

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

Снимок экрана: доступ к фильтрам метрик устойчивости для приложения-контейнера.

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

Снимок экрана: результаты из примеров фильтров метрик для обеспечения устойчивости.

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

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