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

  • Статья

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

Примечание.

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

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

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

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

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

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

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

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

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

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

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

http Подключение ionPool

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

tcp Подключение ionPool

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

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

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

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

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

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

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

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

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

Screenshot showing resiliency query results based on provided query example.

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

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

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

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

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

Screenshot showing the results from example metrics filters for resiliency.

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

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