Устранение распространенных сбоев развертывания в Контейнеры приложений Azure

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

Tip

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

Начните с симптома

Используйте следующую таблицу для выбора пути устранения неполадок.

Симптом Вероятная причина Перейти к
Создание среды не завершается из-за ошибки нехватки ресурсов Ограниченная региональная пропускная способность Устранение ошибок нехватки ресурсов среды
Не удается выполнить развертывание, и ревизия не создаётся Проблема аутентификации образа или реестра образов Развёртывание завершается с ошибкой до создания редакции
ошибка ImagePullBackOff или UNAUTHORIZED Тег изображения или учетные данные реестра Развёртывание не удаётся до создания ревизии
CrashLoopBackOff или контейнер немедленно завершается Сбой при запуске Сбои контейнера и сбои запуска
Редакция Degraded с 0 готовыми репликами Сбои тестирования работоспособности Сбои пробы работоспособности
Правка остается в Provisioning Время запуска контейнера инициализации или проверки Проблемы с временем инициализации
Секрет или переменная среды пуста во время выполнения Проблема с секретным идентификатором или синхронизацией Проблемы с доступом к секретам
Управляемое удостоверение возвращает 401 или 403 Неверная конфигурация удостоверения личности Неправильная настройка управляемой идентификации
Эндпоинт возвращает 403 или 502 Проблема с ingress или сетью Запросы завершаются с ошибкой или ведут себя неожиданно

Выберите правильный источник журнала

Используйте логи, если диагностика портала или состояние CLI не показывают первопричину.

Тип журнала Что это показывает Основные сведения
Системные журналы События на уровне платформы, включая статус извлечения образов, результаты проверок, ошибки, связанные с удостоверением, и результаты синхронизации секретов. Системные события уровня реплики включают идентификатор реплики: ReplicaName_s в ContainerAppSystemLogs_CL или ReplicaName в ContainerAppSystemLogs.
Журналы консоли Приложения stdout/stderr, включая трассы стека, сообщения при запуске и ошибки выполнения. Консольные логи включают ContainerGroupName_s в ContainerAppConsoleLogs_CL или ContainerGroupName в ContainerAppConsoleLogs для устранения неполадок на уровне реплики.
Журналы HTTP Журналы запросов на уровне Ingress, включая коды состояния, задержку, пути и детали ответа. HTTP-логи включают поле ReplicaName . Включите их через диагностические настройки Azure Monitor в среде.

Развёртывание завершается сбоем до создания ревизии

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

Проверьте состояние портала

В портале Azure перейдите в Container AppНастройкаДополнительноРедакции и реплики. Если список пуст или содержит неудачную запись, проверьте, нет ли ошибки загрузки образа или ошибки проверки шаблона. Вы также можете искать «image pull» в Диагностика и решение проблем для автоматического анализа.

# Check app-level provisioning state and error
az containerapp show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> \
  --query "{provisioning:properties.provisioningState, error:properties.provisioningError, latestRevision:properties.latestRevisionName}" -o json

# List revisions. Expect no revision or a failed revision.
az containerapp revision list -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> \
  --query "[].{name:name, health:properties.healthState, provisioning:properties.provisioningState}" -o table

Проверьте системные журналы на предмет событий загрузки образов

В портале Azure перейдите в Container App>Observe>Log Stream и выберите System logs. Ищите ошибки при загрузке образов.

az containerapp logs show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --type system --tail 50

Проверьте конфигурацию образа и реестра

В портале Azure перейдите в Container App>Настройка>Контейнер. Проверьте имя изображения, тег и настройки реестра.

# Check configured registries
az containerapp show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> \
  --query "properties.configuration.registries" -o json

# Verify that the image tag exists in your registry
az acr repository show-tags --name <AZURE_CONTAINER_REGISTRY_NAME> --repository <REPOSITORY_NAME>

# Verify that ACR credentials work
az acr login --name <AZURE_CONTAINER_REGISTRY_NAME>
docker pull <AZURE_CONTAINER_REGISTRY_NAME>.azurecr.io/<REPOSITORY_NAME>:<IMAGE_TAG>

Исправьте распространённые проблемы с образом и реестром

Если вы видите это условие Выполните это действие
manifest unknown или tag not found Убедитесь, что точный тег изображения существует в вашем регистри.
UNAUTHORIZED: authentication required Настройте учетные данные реестра. Чтобы использовать управляемую идентичность для вытягивания ACR, запустите az containerapp registry set -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --server <AZURE_CONTAINER_REGISTRY_NAME>.azurecr.io --identity system.
name unknown или сбой разрешения DNS Проверьте, что значение --image использует правильное имя хоста <REGISTRY>.azurecr.io.
Тайм-аут соединения с реестром Если вы используете кастомную VNet, убедитесь, что исходящий доступ обеспечен. Добавьте тег службы AzureContainerRegistry или правила FQDN.
UNAUTHORIZED с настроенным пользователем-администратором Включите пользователя-администратора с помощью az acr update -n <AZURE_CONTAINER_REGISTRY_NAME> --admin-enabled true, или переключитесь на управляемую идентичность с ролью AcrPull.
UNAUTHORIZED с управляемой идентификацией Назначьте роль AcrPull с помощью az role assignment create --role AcrPull --assignee <PRINCIPAL_ID> --scope <ACR_RESOURCE_ID>.

Note

Для подробного руководства по проблемам со скачиванием образов, включая ограничения частоты запросов к реестру и поведение проверки скачивания образов, см. раздел «Устранение неполадок при сбоях скачивания образов».

Проверка не выполнена или привела к ухудшению

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

Сбои контейнера и сбои запуска

Используйте этот раздел при запуске контейнера, немедленном завершении или при переходе в цикл перезапусков из-за сбоев. Версия существует, но не может обслуживать трафик.

Проверьте состояние версии

В портале Azure перейдите в Container AppConfigureMoreРедакции и реплики, а затем выберите сбойную редакцию. Ищите события BackOffили CrashLoopBackOff в сведениях об изменении.

az containerapp revision show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --revision <REVISION_NAME> \
  --query "{health:properties.healthState, running:properties.runningState, details:properties.runningStateDetails, error:properties.provisioningError}" -o json

Проверьте консольные логи на наличие трассировок стека

В портале Azure перейдите в Container App>Observe>Log Stream и выберите Console logs. Ищите трассы стека или сообщения об ошибках. В логах консоли есть идентификатор реплики, ContainerGroupName_s в ContainerAppConsoleLogs_CL или ContainerGroupName в ContainerAppConsoleLogs, так что можно фильтровать по конкретной реплике.

# Pull console logs if the app wrote output
az containerapp logs show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --tail 100

# Pull system logs for platform-level events
az containerapp logs show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --type system --tail 50

Проверить конфигурацию контейнера

В портале Azure перейдите в Container App>Configure>Container. Проверьте команду, аргументы, переменные среды и лимиты ресурсов.

az containerapp revision show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --revision <REVISION_NAME> \
  --query "properties.template.containers[].{command:command, args:args, env:env, resources:resources}" -o json

Исправьте распространённые проблемы с вылетами и запуском

Если вы видите эту ошибку Сделайте это
Трассировка стека в логах консоли Исправлена ошибка приложения. Если логи пусты, сбой происходит до сброса буфера stdout. Добавьте раннее логирование или настройте среду выполнения так, чтобы отключить буферизацию вывода. Например, установите значение PYTHONUNBUFFERED=1.
exec format error или executable file not found Проверьте, что контейнер command и args соответствуют ожиданиям изображения.
KeyError, undefined, или null-ссылка Проверьте, что все необходимые переменные среды установлены. См. проблемы с секретным доступом.
OOMKilled Увеличьте лимиты памяти и процессора с помощью az containerapp update -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --cpu 1.0 --memory 2.0Gi.

Note

Для дополнительного устранения неполадок при запуске контейнеров, включая локальное тестирование Docker и ограничение процессора, см. раздел «Устранение неполадок: сбои запуска контейнера». Для диагностики событий выхода из контейнера в портале см. раздел «Устранение неполадок: сбои выхода из контейнера».

Сбои тестирования работоспособности

Используйте этот раздел, когда редакция развёртывается, но проверка состояния не проходит. Платформа отмечает реплики как нездоровые или перезапускает их. Приложение может работать локально, но в Container Apps не проходит проверки зонда.

Проверьте системные журналы на наличие отказов датчика

В портале Azure перейдите в Container App>Observe>Log Stream и выберите System logs. Ищите Unhealthy события с подробностями о сбое проверки. Вы также можете искать «health probe» в Diagnose and solve problems для автоматического анализа.

# System logs for probe failure events
az containerapp logs show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --type system --tail 50

Проверьте конфигурацию зонда

В портале Azure перейдите в Container App>Configure>Container>Health Probes. Проверьте настройки порта, пути и тайминга.

az containerapp revision show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --revision <REVISION_NAME> \
  --query "properties.template.containers[].probes" -o json

Проверьте endpoint зонда

Убедитесь, что ваш эндпоинт проверки работоспособности возвращает HTTP 200 в пределах настроенного тайм-аута. Если вы используете TCP-зонды, проверьте, что ваше приложение слушает на ожидаемом порте.

Исправьте распространённые проблемы проверки работоспособности

Если вы видите это условие Выполните это действие
Проба возвращает отклоненное подключение Задайте порт пробы targetPortдля сопоставления порта прослушивания приложения и входящего трафика.
Проверка завершается с ошибкой до того, как приложение будет готово, и редакция становится Degraded Увеличьте initialDelaySeconds значение для проверок работоспособности и готовности. Если ваше приложение требует длительного запуска, настройте настройки проверки, чтобы избежать ненужных перезапусков.
Сбой пробы с ошибкой HTTP Убедитесь, что эндпоинт health возвращает код 200. Для HTTP-проверок убедитесь, что путь существует и корректно отвечает.
Проба подключается до прослушивания приложения Используйте пробу запуска с более failureThreshold высоким уровнем, чтобы предоставить приложению время привязки порта.

Note

Для диагностики зонда на основе портала см. раздел «Устранение неисправностей при сбоях проверки работоспособности». Для диагностики несоответствия целевых портов см. Устранение неполадок параметров целевого порта.

Значения пробы по умолчанию

Когда вы включаете ингресс и не настраиваете зонды, Container Apps применяет эти настройки по умолчанию.

Имущество Startup Живость Готовность
Protocol HTTP GET / HTTP GET / HTTP GET /
Порт Целевой порт Ingress или 80, если не установлен Целевой порт Ingress, или 80, если не установлен Целевой порт ingress, или 80, если не установлен
Начальная задержка 1с 1с 3 с
Период 10 10 с 10 с
Таймаут 1с 1с 1с
Порог успешности 1 1 1
Порог сбоя 48 3 3

Проблемы с временем инициализации

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

Проверьте состояние ревизии

В портале Azure перейдите в раздел Container AppConfigureMoreРедакции и реплики, а затем выберите редакцию. Ищите события init container в сведениях о ревизии.

az containerapp revision show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --revision <REVISION_NAME> \
  --query "{running:properties.runningState, details:properties.runningStateDetails}" -o json

Проверьте журналы init-контейнера

В портале Azure перейдите в Container App>Observe>Log Stream, а затем выберите init контейнер в раскрывающемся списке контейнеров.

az containerapp logs show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --container <INIT_CONTAINER_NAME> --tail 100

Проверьте поведение завершения init-контейнера

Убедитесь, что init container выполняет команду, выполнение которой завершается, и выходит с кодом 0. Контейнеры Init, которые работают бесконечно, блокируют основной контейнер.

Исправление распространённых проблем с инициализацией

Если вы видите эту ошибку Выполните это действие
В подключении отказано или тайм-аут в журналах init-контейнера Добавьте логику повторной попытки или проверку готовности. Не предполагайте, что зависимые службы доступны во время инициализации.
Редакция Provisioning остаётся на неопределённый срок Убедитесь, что init container выполняет команду, которая завершается, и выходит с кодом 0.
Init контейнер завершается с ошибкой 401 или 403 В окружениях с профилями только потребления и с выделенными профилями рабочих нагрузок только основные контейнеры могут использовать управляемую идентичность. В условиях профиля нагрузки потребления init-контейнеры могут по умолчанию использовать управляемую идентификацию. С версией API 2024-02-02-preview или более поздней можно identitySettings ограничить идентичность для Init, Main, None или All.
Не удается загрузить образ init-контейнера Примените ту же аутентификацию реестра и проверку тегов образов, что и в Сбой развертывания до создания редакции.
Контейнер Init считывает пустой секрет Не думайте, что секреты, на которые есть ссылка из Key Vault, обновятся сразу. Если init контейнер зависит от значения, связанного с Key Vault, добавьте логику повтора или используйте прямой секрет Container Apps для зависимостей в init-time. Для неверсированных ссылок на Key Vault извлечение новых версий может занимать до 30 минут.

Приложение запускается без конфигурации

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

Проблемы с доступом к секретам

Используйте этот раздел, когда ожидаемое значение конфигурации, например секрет или ссылка на Key Vault, пусто или отсутствует во время выполнения.

Проверьте секреты и ссылки на переменные среды

В портале Azure перейдите в Container App>Configure>Identity>Secrets и проверьте наличие секрета. Если вы используете ссылки на Key Vault, ищите предупреждающие значки. Затем перейдите в Container App>Configure>More>Revisions & Replicas, выберите редакцию и проверьте Container details>Environment variables, чтобы убедиться, что значения secretRef правильны.

# List secrets defined on the app
az containerapp secret list -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> -o table

# Verify environment variable references in the revision template
az containerapp revision show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --revision <REVISION_NAME> \
  --query "properties.template.containers[].env" -o json

Проверьте доступ к Key Vault

Используйте этот шаг только если вы используете ссылки на Key Vault.

В портале Azure выполните поиск «Key Vault» в разделе Диагностика и решение проблем для автоматического анализа.

# Verify that managed identity is assigned
az containerapp identity show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME>

# Check system logs for Key Vault sync errors
az containerapp logs show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --type system --tail 50

Исправьте распространённые проблемы с секретами

Если вы видите эту ошибку Выполните это действие
Значение переменной среды пусто secretRef должно точно совпадать с именем секрета. Совпадение зависит от регистра.
Ошибка развертывания, ссылающаяся на неизвестный секрет Определите секрет перед развертыванием с помощью az containerapp secret set -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --secrets mysecret=myvalue.
Старое секретное значение в Container Apps сохраняется после обновления Развернуть новую редакцию или перезапустить существующую с помощью az containerapp revision restart -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --revision <REVISION_NAME>. Обновление секрета приложения в Container Apps не запускает новую редакцию.
Контейнер не запускается после удаления секрета Разверните новую редакцию, которая удаляет ссылку на удаленный секрет, а затем деактивирует старые редакции.
Managed identity not configured с Key Vault Включите управляемое удостоверение с помощью az containerapp identity assign -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --system-assigned.
Authorization failedна Key Vault Присвойте роль Key Vault Secrets User управляемому удостоверению с помощью az role assignment create --role "Key Vault Secrets User" --assignee <IDENTITY_PRINCIPAL_ID> --scope <KEY_VAULT_RESOURCE_ID>.
Файрвол Key Vault запрещает доступ Добавьте исходящие IP среды Container Apps в межсетевой экран Key Vault или настройте приватную конечную точку.
Упомянутый секрет Key Vault отключён Активируйте секрет в Key Vault. В портале Azure перейдите в Key Vault>Secrets, выберите секрет, а затем выберите Включить.
Некорректный URI Key Vault Проверьте формат: https://<KEY_VAULT_NAME>.vault.azure.net/secrets/<SECRET_NAME> или https://<KEY_VAULT_NAME>.vault.azure.net/secrets/<SECRET_NAME>/<SECRET_VERSION>.
Доступ к Key Vault работает примерно через 5–10 минут Подождите и повторите попытку. Распространение RBAC может занять до 10 минут.

Important

Секреты приложений Container Apps ограничены конкретным приложением, а ссылки на переменные среды — на ревизию. Обновление секрета приложения Container Apps не создаёт новую версию. Развернуть новую версию или перезапустить существующую, чтобы изменения секрета приложения вступили в силу. Для неверсионных ссылок Key Vault Container Apps может получить новые версии в течение 30 минут и автоматически перезапускать активные редакции, ссылающиеся на секрет в переменной среды.

Неверная конфигурация управляемого удостоверения

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

Проверьте, что идентификатор назначен

В портале Azure перейдите в Container App>Configure>Identity>Identity. Проверьте, что назначенная системой — Вкл., или что указан правильный идентификатор, назначенный пользователем.

az containerapp identity show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME>

Проверьте распределение ролей на целевом ресурсе

В портале Azure перейдите к целевому ресурсу, например, к учетной записи хранения или в Key Vault, затем перейдите к Управление доступом (IAM)>Назначения ролей. Проверьте, что идентификатор субъекта безопасности имеет необходимую роль.

az role assignment list --assignee <PRINCIPAL_ID> --all -o table

Проверьте логи консолей на ошибки аутентификации

В портале Azure перейдите в Container App>Observe>Log Stream. Ищите ошибки 401 или 403 в выходе приложения.

az containerapp logs show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --tail 100

Исправление распространённых проблем с управляемым удостоверением

Если вы видите эту ошибку Выполните это действие
ManagedIdentityCredential Ошибка Назначьте идентификатор с помощью az containerapp identity assign -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --system-assigned.
403 на целевом ресурсе с управляемой идентичностью, назначаемой пользователем Укажите идентификатор клиента в вашем коде с помощью DefaultAzureCredential(managed_identity_client_id="<CLIENT_ID>").
403 даже при назначенной управляемой идентификации Назначьте необходимую роль для целевого ресурса. Например, назначьте Storage Blob Data Contributor на аккаунт хранения.
init-контейнер не запускается из-за ошибки аутентификации В окружениях профилей только потребления и с выделенными профилями рабочей нагрузки только основные контейнеры могут использовать управляемую идентичность. В условиях профиля нагрузки потребления init-контейнеры могут по умолчанию использовать управляемую идентификацию. С версией API 2024-02-02-preview или более поздней можно identitySettings ограничить идентификатор для Init, Main, None или All.
403 сохраняется после исправления роли или членства в группе Данные авторизации управляемого удостоверения могут кэшироваться для каждого URI ресурса примерно в течение 24 часов. Принудительное обновление токена не поддерживается. Ждите истечения срока действия кэша и избегайте использования изменений членства в группах с управляемой идентификацией для чувствительного ко времени доступа.

Tip

Используйте Azure Identity SDK с DefaultAzureCredential вместо прямого вызова конечной точки REST для управляемого идентификатора. SDK обеспечивает единообразное взаимодействие в разных средах.

Запросы завершаются с ошибкой или ведут себя неожиданно

Используйте этот раздел, когда приложение работает нормально, но HTTP-запросы возвращают ошибки, такие как 404, 502 или 403, либо ответ отсутствует. Проблема, скорее всего, связана с конфигурацией ingress или маршрутизацией трафика.

Проверьте конфигурацию ingress

В портале Azure перейдите в Container App>Configure>Networking>Ingress. Убедитесь, что ingress включён, целевой порт совпадает с вашим приложением и FQDN назначен. Вы также можете искать "ingress" в Диагностика и решение проблем для автоматического анализа.

# Check ingress configuration and traffic split
az containerapp show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> \
  --query "{ingress:properties.configuration.ingress, latestReady:properties.latestReadyRevisionName}" -o json

Проверьте FQDN и разделение трафика

В портале Azure перейдите в Container AppНастройкаДополнительноРедакции и реплики. Убедитесь, что трафик направляется к правильной версии и что она работоспособна.

# Verify the FQDN
az containerapp show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --query "properties.configuration.ingress.fqdn" -o tsv

# Check traffic split
az containerapp ingress traffic show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> -o table

Проверьте HTTP-логи

В портале Azure перейдите в рабочее пространство Log Analytics и выполните запрос к таблице ContainerAppHTTPLogs. Проверьте запросы с ошибкой и поле ResponseCodeDetails, чтобы определить, исходит ли ошибка от вашего приложения или от платформы.

# Query HTTP logs in Log Analytics. This command requires HTTP logs enabled through diagnostic settings.
az monitor log-analytics query -w <LOG_ANALYTICS_WORKSPACE_ID> \
  --analytics-query "ContainerAppHTTPLogs | where TimeGenerated > ago(1h) | where StatusCode >= 400 | project TimeGenerated, Method, Path, StatusCode, ResponseCodeDetails | take 50"

Исправьте распространённые проблемы с запросом и ingress

Если вы видите это условие Выполните это действие
FQDN не назначен, и вы не можете получить доступ к приложению Включите Ingress, запустив az containerapp ingress enable -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --type external --target-port 8080 --transport auto.
502 — Недопустимый шлюз Задайте для targetPort значение, соответствующее порту, который прослушивает приложение.
Старая версия обслуживает трафик вместо последней версии Обновите распределение трафика, запустив az containerapp ingress traffic set -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --revision-weight latest=100.
403 Запрещено Проверьте ограничения безопасности IP-адресов в параметрах входящего трафика.
Ошибки подключения Убедитесь, что тип входящего транспорта соответствует протоколу вашего приложения — HTTP или TCP.

Используйте рабочий процесс диагностики CLI

Используйте этот рабочий процесс, когда шаги по разделу не решают проблему или нужно собрать больше деталей.

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

  1. Выполните команду az containerapp show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> -o json. Проверьте provisioningState, provisioningError и latestRevisionName.

  2. Выполните команду az containerapp revision list -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> -o table. Если список пустой, сбой связан с загрузкой образа или валидацией шаблона. См. Сбой развёртывания до создания ревизии. Если есть ревизия, переходите к следующему этапу.

  3. Выполните команду az containerapp revision show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --revision <REVISION_NAME> -o json. Проверьте healthState, runningState, runningStateDetails и provisioningError.

  4. Запустите az containerapp logs show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --type system --tail 50 для просмотра событий на уровне платформы, таких как сбои зонда, ошибки идентификации и проблемы с секретной синхронизацией.

  5. Запустите az containerapp logs show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --tail 100, чтобы просмотреть stdout и stderr приложения, включая трассировки стека, ошибки конфигурации и сбои соединения. Используйте имя реплики в этих логах, чтобы отнести проблемы к конкретному экземпляру.

  6. Запустите az containerapp identity show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> для проверки конфигурации удостоверения личности, если ошибки, связанные с аутентификацией, появились на предыдущих этапах.

Запрос Log Analytics для более глубокого изучения

Используйте Log Analytics, если выводы CLI и диагностика портала не дают достаточно деталей.

Поиск сбоев на уровне системы

В этом запросе показаны ошибки извлечения изображений, ошибки пробы, ошибки подготовки и другие события платформы.

ContainerAppSystemLogs_CL
| where RevisionName_s == "<REVISION_NAME>"
| where Log_s contains "BackOff" or Log_s contains "Failed" or Log_s contains "Error"
  or Reason_s == "Unhealthy"
| project TimeGenerated, Reason_s, Log_s
| order by TimeGenerated desc
| take 50

Найдите ошибки в консольных логах по реплике

Этот запрос возвращает ошибки консольного журнала и включает имя реплики.

ContainerAppConsoleLogs_CL
| where RevisionName_s == "<REVISION_NAME>"
| where Log_s contains "error" or Log_s contains "Exception" or Log_s contains "fatal"
| project TimeGenerated, ContainerGroupName_s, Log_s
| order by TimeGenerated desc
| take 50

Поле ContainerGroupName_s — это имя реплики в ContainerAppConsoleLogs_CL. Используйте его, чтобы локализовать ошибки в конкретном экземпляре. В таблице, специфичной ContainerAppConsoleLogs для ресурса, используйте ContainerGroupName.

Найти ошибки HTTP

Включите HTTP-логи через диагностические настройки Azure Monitor в управляемой среде Container Apps. После их включения ContainerAppHTTPLogs таблица появится в Log Analytics. Это может занять несколько минут.

ContainerAppHTTPLogs
| where TimeGenerated > ago(1h)
| where StatusCode >= 400
| project TimeGenerated, ContainerAppName, RevisionName, ReplicaName, Method, Path,
  StatusCode, ResponseCodeDetails, RequestDuration, RequestId
| order by TimeGenerated desc
| take 100

Поле ResponseCodeDetails указывает, была ли ошибка вызвана вашим контейнером, например via_upstream, или платформой, например route_not_found или upstream_per_try_timeout.

Дополнительные запросы, включая анализ медленных запросов, частоту ошибок по ревизиям, трассировку отдельных запросов и конечные точки с наибольшим числом сбоев, см. в статье Мониторинг журналов в Контейнеры приложений Azure с помощью Log Analytics.

Дальнейшие действия

Если проблема не решена:

Связанная документация по устранению неполадок:

Сопутствующая документация:

  • Последнее обновление: