Диагностика и устранение сбоев рабочих процессов в Azure Logic Apps

Область применения: Azure Logic Apps (Потребление + Стандартный)

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

Проверка журнала триггеров

Каждый запуск рабочего процесса начинается с триггера, который активируется по расписанию либо ожидает входящего запроса или события. Журнал триггеров содержит все попытки триггера для рабочего процесса, а также сведения о входных и выходных данных для каждой попытки триггера. Если триггер не активируется, выполните описанные ниже действия.

Потребление

1. Чтобы проверить состояние триггера в приложении логики категории "Потребление", изучите журнал триггеров. Чтобы просмотреть дополнительные сведения о попытке активации, выберите событие триггера, например:

   

2. Проверьте входные данные триггера, чтобы убедиться, что они отображаются должным образом. На панели Журнал в разделе Ссылка на входные данные выберите ссылку, чтобы отобразилась область Входные данные.

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

   

3. Проверьте выходные данные триггеров (если они есть), чтобы убедиться, что они отображаются должным образом. На панели Журнал в разделе Ссылка на выходные данные выберите ссылку, чтобы отобразилась область Выходные данные.

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

   Например, сообщение об ошибке, в котором указано, что RSS-канал не найден:

   

   Совет

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

Стандартный

1. Чтобы проверить состояние триггера в приложении логики категории "Стандартный", изучите журнал триггеров. Чтобы просмотреть дополнительные сведения о попытке активации, выберите событие триггера, например:

   

2. Проверьте входные данные триггера, чтобы убедиться, что они отображаются должным образом. На панели Журнал в разделе Ссылка на входные данные выберите ссылку, чтобы отобразилась область Входные данные.

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

   

3. Проверьте выходные данные триггеров (если они есть), чтобы убедиться, что они отображаются должным образом. На панели Журнал в разделе Ссылка на выходные данные выберите ссылку, чтобы отобразилась область Выходные данные.

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

   Например, сообщение об ошибке, в котором указано, что RSS-канал не найден:

   

   Совет

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

Проверка журнала выполнения рабочих процессов

При каждом срабатывании триггера Azure Logic Apps создает экземпляр рабочего процесса и запускает этот экземпляр. Если выполнение завершается сбоем, попробуйте выполнить описанные ниже действия, чтобы узнать, что произошло во время выполнения. Вы можете посмотреть состояние, а также входные и выходные данные для каждого шага в рабочем процессе.

Потребление

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

   

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

   

3. Просмотрите входные и выходные данные и все сообщения об ошибках для шага с ошибкой.

   

   Например, выходные данные для действия RSS, в котором произошел сбой, показаны на снимке экрана ниже.

   

Стандартный

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

   

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

   

3. Просмотрите входные и выходные данные и все сообщения об ошибках для шага с ошибкой.

   

   Например, выходные данные для действия RSS, в котором произошел сбой, показаны на снимке экрана ниже.

   

Отладка времени выполнения

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

1. В браузере перейдите на сайт Webhook Tester и скопируйте созданный уникальный URL-адрес.

2. Добавьте в приложение логики действие HTTP POST с текстом запроса, который необходимо протестировать (например, выражение, выходные данные другого шага и т. д.).

3. Вставьте URL-адрес из службы Webhook Tester в действие HTTP POST.

4. Чтобы просмотреть, как Azure Logic Apps создает и формирует запрос, запустите рабочий процесс приложения логики. Затем можно вернуться на сайт Webhook Tester для получения дополнительных сведений.

Часто задаваемые вопросы о производительности

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

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

Обычно мой рабочий процесс выполняется в течение 10 секунд. Но иногда завершение может занять гораздо больше времени. Как сделать так, чтобы рабочий процесс всегда завершался в течение 10 секунд?

• Соглашение об уровне обслуживания не распространяется на задержку.

• Рабочие процессы уровня "Потребление" выполняются в мультитенантных экземплярах Azure Logic Apps, поэтому рабочие нагрузки других клиентов могут негативно влиять на производительность рабочего процесса.

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

Время ожидания моего действия истекает через 2 минуты. Как увеличить значение времени ожидания?

Значение времени ожидания действия нельзя изменить, оно фиксировано и составляет 2 минуты. Если вы используете действие HTTP и владеете службой, вызванной действием HTTP, можно изменить службу, чтобы избежать 2-минутного времени ожидания с помощью асинхронного шаблона. Дополнительные сведения см. в разделе Обработка длительно выполняемых задач с помощью модели действия опроса.

Распространенные проблемы — приложения логики категории "Стандартный"

Недоступные артефакты в учетной записи хранения Azure

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

Расположение на портале Azure	Error
Панель "Обзор"	- System.private.corelib:Access to the path 'C:\home\site\wwwroot\hostj.son is denied (System.private.corelib: отказано в доступе к пути "C:\home\site\wwwroot\hostj.son") - Azure.Storage.Blobs: This request is not authorized to perform this operation (Azure.Storage.Blobs: этот запрос не авторизован для выполнения этой операции)
Область "Рабочие процессы".	- Cannot reach host runtime. Error details, Code: 'BadRequest', Message: 'Encountered an error (InternalServerError) from host runtime.' (Не удается связаться со средой выполнения узла. Сведения об ошибке, код: "BadRequest", сообщение: "Обнаружена ошибка (InternalServerError) из среды выполнения узла) - Cannot reach host runtime. Error details, Code: 'BadRequest', Message: 'Encountered an error (ServiceUnavailable) from host runtime.' (Не удается связаться со средой выполнения узла. Сведения об ошибке, код: "BadRequest", сообщение: "Обнаружена ошибка (ServiceUnavailable) из среды выполнения узла) - Cannot reach host runtime. Error details, Code: 'BadRequest', Message: 'Encountered an error (BadGateway) from host runtime.' (Не удается связаться со средой выполнения узла. Сведения об ошибке, код: "BadRequest", сообщение: "Обнаружена ошибка (BadGateway) из среды выполнения узла)
Во время создания и выполнения рабочего процесса	- Failed to save workflow (Рабочий процесс не сохранен) - Error in the designer: GetCallFailed. Failed fetching operations (Ошибка в конструкторе: GetCallFailed. Сбой операций получения) - ajaxExtended call failed (Сбой вызова ajaxExtended)

Варианты устранения неполадок

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

• Для общедоступной учетной записи хранения проверьте доступ к учетной записи хранения следующими способами:

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

  • В параметрах приложения ресурса приложения логики проверьте строку подключения учетной записи хранения AzureWebJobsStorage и WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. Дополнительные сведения см. в статье Настройка узла и приложения для приложений логики в одноклиентской службе Azure Logic Apps.

  В случае сбоя подключения проверьте, является ли ключ подписанного URL-адреса (SAS) в строке подключения актуальным.

• Для учетной записи хранения, которая находится за брандмауэром, проверьте доступ к учетной записи хранения следующими способами:

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

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

  При обнаружении проблем с подключением выполните следующие действия:

  1. В той же виртуальной сети, которая интегрирована с вашим приложением логики, создайте виртуальную машину Azure, которую можно поместить в другую подсеть.

  2. В командной строке выполните nslookup, чтобы убедиться, что службы хранилища BLOB-объектов, файлов, таблиц и очередей разрешаются на ожидаемые IP-адреса.

     Синтаксис: nslookup [StorageaccountHostName] [OptionalDNSServer]

     Большой двоичный объект: nslookup {StorageaccountName}.blob.core.windows.net

     Файл: nslookup {StorageaccountName}.file.core.windows.net

     Таблица: nslookup {StorageaccountName}.table.core.windows.net

     Очередь: nslookup {StorageaccountName}.queue.core.windows.net

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

     • Если служба хранилища имеет частную конечную точку, эта служба разрешается в соответствующие частные IP-адреса контроллера сетевого интерфейса (сетевой карты).

  3. Если предыдущие запросы сервера доменных имен (DNS) успешно разрешаются, выполните команды psping или tcpping, чтобы проверить возможность подключения к учетной записи хранения через порт 443:

     Синтаксис: psping [StorageaccountHostName] [Port] [OptionalDNSServer]

     Большой двоичный объект: psping {StorageaccountName}.blob.core.windows.net:443

     Файл: psping {StorageaccountName}.file.core.windows.net:443

     Таблица: psping {StorageaccountName}.table.core.windows.net:443

     Очередь: psping {StorageaccountName}.queue.core.windows.net:443

  4. Если каждая служба хранилища разрешается из виртуальной машины Azure, найдите DNS, используемую виртуальной машиной для разрешения.

     1. Задайте для параметра WEBSITE_DNS_SERVER приложения логики DNS и убедитесь, что этот DNS работает правильно.

     2. Убедитесь, что интеграция виртуальной сети настроена в соответствии с виртуальной сетью и подсетью в приложении логики категории "Стандартный".

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

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

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

• Мониторинг приложения логики