Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Область применения: Azure Logic Apps (Consumption + Standard)
После запуска рабочего процесса приложения логики можно проверить состояние выполнения рабочего процесса, журнал триггеров, журнал выполнения рабочего процесса и производительность.
В этом руководстве показано, как выполнить следующие задачи:
- Просмотрите историю триггеров.
- Просмотрите журнал выполнения рабочего процесса.
- Настройка оповещений для получения уведомлений о сбоях или других возможных проблемах. Например, можно создать оповещение, которое срабатывает, когда более пяти запусков не удаются в течение часа.
Для мониторинга событий в режиме реального времени и более глубокого отладки можно настроить ведение журнала диагностики для рабочего процесса приложения логики с помощью журналов Azure Monitor. Эта служба Azure помогает контролировать облачные и локальные инфраструктуры, чтобы вы могли более эффективно поддерживать их доступность и производительность. Можно искать и просматривать события, такие как события триггеров, события выполнения и события действий. Сохраняя эти сведения в журналах Azure Monitor, можно создавать запросы лога, которые помогут вам найти и проанализировать эти сведения. Эти диагностические данные также можно использовать с другими службами Azure, такими как Azure Storage и Azure Event Hubs. Дополнительные сведения см. в разделе Мониторинг логических приложений с помощью Azure Monitor.
Просмотр журнала триггера
Каждый запуск рабочего процесса начинается с триггера, который активируется по расписанию либо ожидает входящего запроса или события. Журнал триггеров содержит все попытки триггера, выполненные вашим рабочим процессом, а также информацию о входных и выходных данных для каждой из них.
В Azure portal откройте ресурс вашего логического приложения Consumption и его рабочий процесс в конструкторе.
В меню приложения логики выберите Обзор. На странице обзора выберите историю триггеров.
В журнале триггеров отображаются все попытки срабатывания триггера. Каждый раз, когда триггер успешно запускается, Azure Logic Apps создает отдельный экземпляр рабочего процесса и запускает этот экземпляр. По умолчанию все экземпляры выполняются параллельно, чтобы ни один рабочий процесс не ожидал запуска. Если рабочий процесс активируется одновременно для нескольких событий или элементов, для каждого элемента появляется запись триггера с одинаковыми значениями даты и времени.
В таблице ниже перечислены возможные состояния триггера.
Состояние триггера Описание Неудачно Произошла ошибка. Чтобы просмотреть все созданные сообщения об ошибках для неудачного триггера, выберите попытку триггера и выберите выходные данные. Например, вы можете обнаружить недопустимые входные данные. Пропущено Триггер проверил конечную точку, но не нашел данных, удовлетворяющих указанным критериям. Успешно Триггер проверил конечную точку и нашел доступные данные. Как правило, рядом с этим состоянием также отображается состояние Сработал. В противном случае, определение триггера может содержать условие, которое не было выполнено, или свойство splitOnустановлено на определённое значение.
Это состояние может применяться к запускаемому вручную триггеру, а также повторяющему или опрашивающему триггеру. Триггер может быть успешно запущен, но сам запуск по-прежнему может завершиться ошибкой, если действия порождают необработанные ошибки.Совет
Триггер можно проверить, не дожидаясь следующего повторения. На панели инструментов "Обзор" или на панели инструментов конструктора выберите "Выполнить", "Выполнить".
Чтобы просмотреть сведения о конкретной попытке срабатывания триггера, выберите событие триггера.
Если список содержит много попыток триггера и найти нужную запись не удается, попытайтесь отфильтровать список. Если вы не нашли ожидаемые данные, попробуйте щелкнуть Обновить на панели инструментов.
Теперь можно просмотреть сведения о выбранном событии триггера, например:
Просмотр журнала выполнения рабочих процессов
Каждый раз, когда триггер успешно запускается, Azure Logic Apps создает экземпляр рабочего процесса и запускает этот экземпляр. По умолчанию все экземпляры выполняются параллельно, чтобы ни один рабочий процесс не ожидал запуска. Вы можете посмотреть, что произошло во время этого выполнения, включая состояние, а также входные и выходные данные для каждого шага в рабочем процессе.
В Azure portal откройте ресурс вашего логического приложения Consumption и его рабочий процесс в конструкторе.
В меню приложения логики выберите Обзор. На странице "Обзор" выберите историю запусков.
В разделе Журнал выполнения отображаются все прошлые, текущие и ожидающие выполнения запуски. Если триггер срабатывает одновременно для нескольких событий или элементов, для каждого элемента появляется запись с одинаковыми значениями даты и времени.
Совет
Если состояние выполнения не отображается, попробуйте обновить страницу обзора , нажав кнопку "Обновить". Запуск не происходит для триггера, который пропускается из-за неудовлетворённых критериев или отсутствия данных.
В таблице ниже перечислены возможные статусы выполнения.
Состояние выполнения Описание Прервано Выполнение остановлено или не завершено из-за внешних проблем, например, сбоя системы или истекшей подписки Azure. Отменено Выполнение было активировано и запущено, но затем поступил запрос на отмену. Неудачно В процессе выполнения не удалось завершить как минимум одно действие. В рабочем процессе не настроены последующие действия для обработки подобного сбоя. Запуск Запуск был инициирован и находится в процессе выполнения. Однако это состояние также может отображаться для выполнения, которое регулируется из-за ограничений на действия или текущего плана ценообразования.
Совет. Если настроено ведение журнала диагностики, то можно получить из него информацию о любых происходящих событиях регулирования.Успешно Выполнение прошло успешно. Если какое-либо действие завершилось сбоем, последующее действие в рабочем процессе обработало этот сбой. Истекло время ожидания Тайм-аут выполнения произошел, так как текущая длительность превышает установленное ограничение длительности выполнения, которое контролируется параметром под названием Сохранение истории выполнения в днях. Длительность выполнения вычисляется с помощью времени начала выполнения и ограничения длительности выполнения в это время.
Примечание. Если длительность выполнения также превышает текущий предел хранения журнала выполнения, который также управляется параметром хранения журнала выполнения в днях, выполнение удаляется из журнала выполнения ежедневным заданием очистки. Независимо от того, завершилось ли выполнение или время выполнения истекло, период хранения всегда вычисляется с учетом времени начала выполнения и текущего лимита хранения. Таким образом, если уменьшить ограничение длительности для запуска во время полета, время ожидания истекает. Однако выполнение либо остается, либо удаляется из журнала выполнения в зависимости от того, превышает ли длительность выполнения ограничение хранения.Ожидание Запуск еще не начался или приостановлен, например, из-за более раннего экземпляра рабочего процесса, который все еще выполняется. Чтобы проверить шаги и другие сведения для конкретного выполнения, выберите это выполнение в разделе Журнал выполнений. Если в списке много записей о выполнениях, и вы не можете найти нужную запись, попробуйте отфильтровать список.
Откроется страница журнала выполнения и отображается состояние каждого шага в выбранном выполнении, например:
В таблице ниже показаны возможные состояния в каждом действии рабочего процесса, которые отображаются на портале.
Состояние действия Значок Описание Прервано
Действие остановлено или не завершено из-за внешних проблем, например, сбой системы или сбой Azure подписки. Отменено
Действие было в процессе выполнения, но поступил запрос на его отмену. Неудачно
Выполнить действие не удалось. Запуск
Действие выполняется. Пропущено
Действие было пропущено, так как его условия runAfter не были выполнены, например, предыдущее действие завершилось ошибкой. Каждое действие имеет объект runAfter, где можно настроить условия, которые должны быть соблюдены перед выполнением текущего действия.Успешно
Действие успешно выполнено. Выполнено после повторных попыток
Действие было завершено, но только после одной или нескольких повторных попыток. Чтобы просмотреть журнал повторных попыток, на странице журнала выполнения выберите это действие, чтобы просмотреть входные и выходные данные. Истекло время ожидания
Действие остановлено из-за ограничения времени ожидания, указанного параметрами этого действия. Ожидание
Применяется к действию вебхука, которое ожидает входящего запроса от инициатора. Чтобы просмотреть сведения в формате списка, на панели инструментов истории выполнения выберите Сведения о выполнении.
В панели сведений о выполнении приложения Logic App перечислены все шаги, их состояние и другие сведения.
Например, можно получить свойство идентификатор корреляции выполнения, которое может понадобиться при использовании REST API для Logic Apps.
Чтобы получить дополнительные сведения о конкретном шаге, выберите любой из следующих вариантов:
На странице журнала выполнения выберите шаг, чтобы открыть панель, отображающую входные данные, выходные данные и все ошибки, которые произошли на этом шаге.
Например, предположим, что у вас есть рабочий процесс с неудачным шагом. Вы хотите просмотреть входные данные, которые могли привести к сбою шага.
В этом случае сбой был вызван недопустимым или отсутствующим подключением к учетной записи электронной почты, которая используется для отправки сообщения электронной почты.
На панели инструментов на странице журнала выполнения выберите Детали выполнения. В открывающейся области сведений о запуске приложения логики выберите нужный шаг, например:
Примечание.
Все сведения и события среды выполнения шифруются в Azure Logic Apps и расшифровываются только в том случае, если пользователь запрашивает просмотр данных. Вы можете скрыть входные и выходные данные в истории выполнения рабочего процесса или управлять доступом пользователей с помощью ролевой модели доступа в Azure (Azure RBAC).
Повторное выполнение рабочего процесса с теми же входными данными
Вы можете повторно запустить ранее завершенный рабочий процесс с теми же входными данными, что и рабочий процесс, используемый ранее, следующим образом:
Повторно выполните весь рабочий процесс.
Повторно выполните рабочий процесс, начиная с определенного действия. Повторно отправленное действие и все последующие действия работают как обычно.
Выполнение этой задачи создает и добавляет новый рабочий процесс в журнал выполнения рабочего процесса.
Рекомендации и ограничения
По умолчанию поддерживаются только рабочие процессы потребления и стандартные рабочие процессы с отслеживанием состояния, которые записывают и хранят журнал выполнения. Чтобы использовать эти возможности с рабочим процессом без отслеживания состояния "Стандартный", включите режим с отслеживанием состояния. Для получения дополнительной информации см. Включение истории выполнения для бессостояточных рабочих процессов и Включение управляемого состояния для бессостояточных соединителей.
Повторная отправка выполняет ту же версию рабочего процесса, что и исходная, даже если вы обновили определение рабочего процесса.
Можно повторно запустить только действия из последовательных рабочих процессов. Рабочие процессы с параллельными путями в настоящее время не поддерживаются.
Рабочий процесс должен иметь завершенное состояние, например "Успешно", "Сбой" или "Отменено".
Рабочий процесс должен иметь 40 или меньше действий, чтобы вы могли перезапустить его с определенного действия.
Если рабочий процесс имеет такие операции, как создание или удаление, повторная отправка может создать дублирующиеся данные или попытаться удалить данные, которые больше не существуют, что приведет к ошибке.
В настоящее время эти возможности недоступны с помощью кода Visual Studio или Azure CLI.
Повторное выполнение всего рабочего процесса
В Azure portal откройте ресурс вашего логического приложения Consumption и его рабочий процесс в конструкторе.
В меню приложения логики выберите Обзор. На странице "Обзор" выберите историю запусков.
В разделе Журнал выполнения отображаются все прошлые, текущие и ожидающие выполнения запуски. Если триггер срабатывает одновременно для нескольких событий или элементов, для каждого элемента появляется запись с одинаковыми значениями даты и времени.
На странице "Журнал запусков" выберите выполнение, которое нужно выполнить повторно, а затем нажмите кнопку "Повторная отправка".
Вкладка Журнал запусков добавляет повторно отправленный запуск в список запусков.
Совет
Если повторно отправленный запуск не отображается, на панели инструментов страницы Журнал запусков нажмите Обновить. Запуск не происходит для триггера, который пропускается из-за неудовлетворённых критериев или отсутствия данных.
Чтобы просмотреть входные и выходные данные после завершения повторного выполнения, на вкладке "Журнал запусков" выберите этот запуск.
Повторное выполнение с определенного действия
Возможность повторного запуска доступна для большинства действий, за исключением несовершенных рабочих процессов, сложных сценариев параллелизма и следующих ограничений:
| Действия | Повторная отправка доступности и ограничений |
|---|---|
| Действие условия и действия в путях True и False | — Да для действия 'Условие' — Нет для действий в путях True и False |
| Для каждого действия, а также для всех действий внутри цикла и после него | Нет для всех действий |
| Действие переключения и все действия в пути по умолчанию и пути варианта | — Да для действия переключения — Нет действий в пути по умолчанию и пути к регистру |
| оператор Until плюс все действия внутри цикла и после цикла | Нет для всех действий |
В Azure portal откройте ресурс приложения логики потребления.
В меню ресурсов приложения логики выберите Обзор. На странице "Обзор" выберите "Журнал запусков", в котором отображается журнал выполнения для рабочего процесса.
На вкладке "Журнал запусков" выберите запуск, из которого вы хотите повторно запустить рабочий процесс.
Откроется страница журнала выполнения и отображается состояние каждого шага в выбранном выполнении.
Чтобы повторно запустить рабочий процесс, начиная с определенного действия, выберите любой из следующих вариантов:
Найдите действие, из которого нужно запустить рабочий процесс, откройте контекстное меню и выберите " Отправить" из этого действия.
Выберите действие, из которого нужно начать повторное выполнение рабочего процесса. В открывающейся области под именем действия выберите "Отправить" из этого действия.
Страница истории выполнения обновляется и показывает повторный запуск. Все операции, предшествующие повторно введенному действию, отображают значок состояния светлого цвета, представляющий повторно использованные входные и выходные данные. Повторная отправка действия и последующие действия отображают цветные значки состояния. Дополнительные сведения см. в разделе "Просмотр журнала выполнения рабочего процесса".
Совет
Если повторная отправка не завершается полностью, на панели инструментов результатов выполнения нажмите Обновить.
Настройка оповещений мониторинга
Чтобы получать оповещения на основе определенных метрик или превышения пороговых значений в рабочем процессе, настройте ресурс приложения логики с помощью alerts в Azure Monitor. Дополнительные сведения см. в разделе Метрики в Azure.
Чтобы настроить оповещения без использования Azure Monitor, выполните следующие действия, которые применимы как к ресурсам Consumption, так и к стандартным ресурсам логических приложений.
В меню ресурсов приложения логики в разделе "Мониторинг" выберите "Оповещения". На панели инструментов выберите Создать>Правило генерации оповещений.
На странице создания правила генерации оповещений в списке имен сигнала выберите сигнал, для которого требуется получить оповещение.
Примечание.
Сигналы оповещений отличаются между приложениями логики "Потребление" и "Стандартный". Например, приложения логики потребления имеют множество сигналов, связанных с триггерами, таких как триггеры завершены и триггеры сбоем, в то время как стандартные рабочие процессы имеют сигналы о количестве завершенных триггеров рабочих процессов и о частоте сбоев триггеров рабочих процессов.
Например, чтобы отправить оповещение, когда триггер не срабатывает в потребительском рабочем процессе, выполните следующие действия:
В списке имен сигнала выберите сигнал "Сбой триггеров".
В логике генерации оповещений настройте условие, например:
Свойство Пример значения Threshold статически. Тип агрегирования Численность Оператор Больше или равно Единица измерения Численность Пороговое значение 1 В разделе "Предварительный просмотр" теперь показано условие, которое вы настроили, например:
Когда количество сбоев триггеров больше или равно 1
В разделе "Когда необходимо оценить", настройте расписание для проверки условия:
Свойство Пример значения Проверьте каждый 1 минута Период ретроспективного анализа 5 минут. Например, готовое условие выглядит примерно так, как показано в следующем примере, и на странице "Создание правила генерации оповещений" теперь отображается стоимость выполнения этого оповещения:
Когда вы будете готовы, выберите Просмотр и создание.
Общие сведения см. в разделе Создание правила оповещения из конкретного ресурса — Azure Monitor.
Устранение неполадок
Экспортированные журналы отсутствуют или удаляются
Если журналы, экспортированные с помощью параметров диагностики, отсутствуют или удаляются, проверьте, имеет ли имя триггера, действия или рабочего процесса символы Юникода, которые не разрешены.
Связанный контент
- приложения логики Monitor с Azure Monitor