Мониторинг работоспособности рабочих процессов уровня "Стандартный" в Azure Logic Apps с помощью проверки работоспособности (предварительная версия)

Область применения: Azure Logic Apps (стандартная версия)

Примечание.

Эта возможность входит в предварительную версию, и на нее распространяются Дополнительные условия использования предварительных версий Microsoft Azure.

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

• Упреждающий мониторинг, чтобы найти и устранить проблемы, прежде чем они влияют на клиентов.

• Повышение доступности путем удаления неработоспособных экземпляров из подсистемы балансировки нагрузки в Azure.

• Автоматическое восстановление путем замены неработоспособных экземпляров.

Как работает проверка работоспособности в Azure Logic Apps?

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

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

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

После удаления неработоспособного экземпляра функция продолжает проверять связь с экземпляром. Если экземпляр отвечает с кодом работоспособного состояния, включительно от 200 до 299, проверка работоспособности возвращает экземпляр подсистеме балансировки нагрузки. Однако если экземпляр остается неработоспособным в течение одного часа, проверка работоспособности заменяет экземпляр новым. Дополнительные сведения см. в разделе "Что Служба приложений делает с проверками работоспособности".

Необходимые компоненты

• Учетная запись и подписка Azure. Если у вас нет ее, вы можете зарегистрироваться для получения бесплатной учетной записи Azure.

• Ресурс приложения логики уровня "Стандартный" со следующими атрибутами:

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

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

    • Начинается с триггера запроса с именем "При получении HTTP-запроса".

    • Включает действие запроса с именем Response. Задайте это действие для возврата кода состояния включительно от 200 до 299.

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

Ограничения

• Указанная длина пути должна содержать менее 65 символов.

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

• Проверка работоспособности не следует перенаправлениям для кода состояния 302 Так, избегайте перенаправлений и не забудьте выбрать допустимый путь, который существует в приложении.

Настройка проверки работоспособности

1. В портал Azure перейдите к ресурсу приложения логики "Стандартный".

2. В меню приложения логики выберите " Диагностика и решение проблем".

3. На странице "Диагностика и решение проблем" в поле поиска найдите и выберите функцию проверки работоспособности.

   

4. В разделе "Проверка работоспособности" выберите "Просмотреть решение".

5. На открывающейся панели выберите "Настроить" и включить функцию проверки работоспособности.

6. На вкладке "Проверка работоспособности" рядом с флажок "Работоспособность" нажмите кнопку "Включить".

7. В поле "Путь" в поле "Работоспособность" введите допустимый путь URL-адреса для рабочего процесса, например:

   /api/{workflow-name}/triggers/{request-trigger-name}/invoke?api-version=2022-05-01

8. Сохранение изменений. На панели инструментов нажмите кнопку Сохранить.

9. В ресурсе приложения логики обновите файл host.json , выполнив следующие действия:

   1. В меню приложения логики в разделе "Средства разработки" выберите "Дополнительные инструменты> Go".

   2. На панели инструментов KuduPlus в меню консоли отладки выберите CMD.

   3. Перейдите к папке site/wwwroot и рядом с файлом host.json нажмите кнопку "Изменить".

   4. В редакторе файлов host.json добавьте свойство Workflows.HealthCheckWorkflowName и имя рабочего процесса работоспособности, чтобы включить проверку работоспособности и авторизацию, например:

      "extensions": {
          "workflow": {
              "settings": {
                  "Workflows.HealthCheckWorkflowName" : "{workflow-name}"
              }
          }
      }
      

   5. По завершении нажмите кнопку Сохранить.

Устранение неполадок

После установки пути работоспособности рабочий процесс работоспособности не активируется.

1. В меню приложения логики выберите " Диагностика и решение проблем".

2. В разделе "Устранение неполадок" выберите "Доступность и производительность".

   

3. Найдите и просмотрите раздел кода состояния.

   Если код состояния равен 401, проверьте следующие элементы:

   • Убедитесь, что свойство Workflows.HealthCheckWorkflowName и имя рабочего процесса работоспособности отображаются правильно.

   • Убедитесь, что указанный путь соответствует имени триггера рабочего процесса и запроса .

Распространенные проблемы со работоспособностью

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

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

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

1. Проверьте, может ли ресурс получить доступ к связанной учетной записи хранения.

   Например, у учетной записи хранения есть параметр сети, который блокирует доступ? У вас есть политика сетевого брандмауэра, которая блокирует доступ?

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

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

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

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

Мой рабочий процесс периодически останавливает обработку сообщений в течение нескольких часов, но работает хорошо чаще всего.

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

1. В портал Azure найдите и откройте приложение логики, если оно еще не открыто.

2. В меню приложения логики в разделе Параметры выберите Настройка.

3. На вкладке "Параметры среды выполнения рабочего процесса" рядом с мониторингом масштабирования среды выполнения нажмите кнопку "Вкл.".

4. На панели инструментов страницы "Конфигурация" нажмите кнопку "Сохранить".

5. В меню приложения логики в разделе "Параметры" выберите "Горизонтальное масштабирование" (Служба приложений план).

6. В разделе "Масштабирование приложений" убедитесь, что значение Always Ready Instances не имеет значения 0.

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

• Мониторинг и сбор диагностических данных для рабочих процессов
• Включение и просмотр расширенной телеметрии для стандартных рабочих процессов
• Просмотр метрик работоспособности и производительности