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

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

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

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

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

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

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

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

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

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

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

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

Prerequisites

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

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

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

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

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

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

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

Limitations

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

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

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

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

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

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

    Снимок экрана: портал Azure, страница проверки работоспособности и выбранный параметр для включения.

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

    /api/<workflow-name>/triggers/<request-trigger-name>/invoke?api-version=2022-05-01

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

  5. В ресурсе приложения логики обновите файл 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. В разделе "Устранение неполадок" выберите "Доступность и производительность".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. На портале Azure откройте приложение логики.

  2. На боковой панели приложения логики в разделе "Параметры" выберите "Конфигурация".

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

  4. На боковой панели приложения логики в разделе "План службы приложений" выберите "Горизонтальное масштабирование".

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

Если ваше приложение логики уровня "Стандарт" размещено в App Service Environment, убедитесь, что Всегда включено включено.

  1. На портале Azure найдите и откройте приложение логики.

  2. На боковой панели приложения логики в разделе "Параметры" выберите "Конфигурация".

  3. На вкладке "Общие параметры" выберите Always On , чтобы включить, а затем нажмите кнопку "Применить".

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

  • Last updated on