Отслеживайте экземпляры службы приложений с помощью проверки работоспособности.

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

Обратите внимание, что /api/health — это просто пример. По умолчанию не задан путь проверки состояния системы. Необходимо убедиться, что выбранный путь является допустимым путем, который существует в приложении.

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

• При указании пути в приложении, проверка работоспособности пингует путь на всех экземплярах приложения Службы приложений с интервалом в 1 минуту.
• Если веб-приложение, работающее в данном экземпляре, не отвечает коду состояния от 200 до 299 (включительно) после 10 запросов, Служба приложений определяет, что экземпляр неработоспособен и удаляет его из подсистемы балансировки нагрузки для веб-приложения. Требуемое количество неудачных запросов для экземпляра, которое считается неработоспособным, настраивается как минимум на два запроса.
• После удаления экземпляра проверка работоспособности продолжает пинговать его. Если экземпляр начинает реагировать на здоровый код состояния (200–299), экземпляр возвращается в подсистему балансировки нагрузки.
• Если веб-приложение, работающее на экземпляре, остается неработоспособным в течение одного часа, экземпляр заменяется новым.
• При горизонтальном масштабировании служба приложений проверяет путь проверки работоспособности, чтобы убедиться в готовности новых экземпляров.

Включение проверки работоспособности

1. Чтобы включить проверку работоспособности, перейдите на портал Azure и выберите приложение App Service.
2. В разделе Мониторинг выберите Проверка работоспособности.
3. Выберите "Включить" и укажите допустимый путь URL-адреса для приложения, например /health или /api/health.
4. Выберите Сохранить.

Настройка

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

Проверка подлинности и безопасность

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

Если вы используете собственную систему проверки подлинности, то путь проверки работоспособности системы должен разрешать анонимный доступ. Чтобы обеспечить безопасность конечной точки проверки работоспособности, сначала следует использовать такие функции, как ограничения IP-адресов, сертификаты клиента или виртуальная сеть, чтобы ограничить доступ к приложениям. После создания этих функций можно выполнить проверку подлинности запроса проверки работоспособности, проверив заголовок x-ms-auth-internal-token и убедившись, что он соответствует хэшу SHA256 переменной WEBSITE_AUTH_ENCRYPTION_KEYсреды. Если они соответствуют, запрос проверки работоспособности действителен и поступает из Службы приложений.

using System;
using System.Security.Cryptography;
using System.Text;

/// <summary>
/// Method <c>HeaderMatchesEnvVar</c> returns true if <c>headerValue</c> matches WEBSITE_AUTH_ENCRYPTION_KEY.
/// </summary>
public bool HeaderMatchesEnvVar(string headerValue)
{
    var sha = SHA256.Create();
    string envVar = Environment.GetEnvironmentVariable("WEBSITE_AUTH_ENCRYPTION_KEY");
    string hash = Convert.ToBase64String(sha.ComputeHash(Encoding.UTF8.GetBytes(envVar)));
    return string.Equals(hash, headerValue, StringComparison.Ordinal);
}

from hashlib import sha256
import base64
import os

def header_matches_env_var(header_value):
    """
    Returns true if SHA256 of header_value matches WEBSITE_AUTH_ENCRYPTION_KEY.
    
    :param header_value: Value of the x-ms-auth-internal-token header.
    """
    
    env_var = os.getenv('WEBSITE_AUTH_ENCRYPTION_KEY')
    hash = base64.b64encode(sha256(env_var.encode('utf-8')).digest()).decode('utf-8')
    return hash == header_value

import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
import java.util.Base64;
import java.nio.charset.StandardCharsets;

public static Boolean headerMatchesEnvVar(String headerValue) throws NoSuchAlgorithmException {
    MessageDigest digest = MessageDigest.getInstance("SHA-256");
    String envVar = System.getenv("WEBSITE_AUTH_ENCRYPTION_KEY");
    String hash = new String(Base64.getDecoder().decode(digest.digest(envVar.getBytes(StandardCharsets.UTF_8))));
    return hash.equals(headerValue);
}

var crypto = require('crypto');

function envVarMatchesHeader(headerValue) {
    let envVar = process.env.WEBSITE_AUTH_ENCRYPTION_KEY;
    let hash = crypto.createHash('sha256').update(envVar).digest('base64');
    return hash == headerValue;
}

Экземпляры

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

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

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

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

Сбор диагностических сведений

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

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

Наблюдение

После предоставления пути к проверке работоспособности приложения можно отслеживать работоспособность сайта с помощью службы Azure Monitor. В колонке проверки работоспособности на портале выберите метрики на верхней панели инструментов. Откроется новая панель, в которой можно просмотреть историю статусов проверки работоспособности сайта и создать новое правило оповещения. Метрика состояния проверки работоспособности агрегирует успешные проверки ping и отображает сбои, только если экземпляр считается неработоспособным на основе порогового значения балансировки нагрузки проверки работоспособности. По умолчанию это значение имеет значение 10 минут, поэтому для данного экземпляра требуется 10 последовательных оповечений (1 в минуту), и только затем он будет отражен на метрику. Для получения дополнительной информации о мониторинге ваших сайтов см. в статье квоты и оповещения службы Azure App Service.

Ограничения

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

Часто задаваемые вопросы

Что произойдет, если приложение работает в режиме одного экземпляра?

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

Почему запросы проверки состояния не отображаются в моих журналах веб-сервера?

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

Отправляются ли запросы проверки работоспособности по протоколу HTTP или HTTPS?

В службе приложений для Windows и Linux запросы проверки работоспособности отправляются по протоколу HTTPS, когда на сайте включен параметр Только HTTPS. В противном случае эти запросы отправляются по протоколу HTTP.

Выполняет ли проверка работоспособности настроенные перенаправления между доменом по умолчанию и личным доменом?

Нет, функция проверки работоспособности отправляет сигнал по пути домена по умолчанию веб-приложения. Если есть перенаправление с домена по умолчанию на пользовательский домен, то код состояния, возвращаемый проверкой состояния, не будет равен 200. Это будет перенаправление (301), которое помечает неработоспособную рабочую роль.

Что если у меня несколько приложений в одном плане службы приложений?

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

Пример

Представьте, что у вас есть два приложения (или одно приложение со слотом) с включенной проверкой работоспособности. Они называются приложением A и приложением B. Они находятся в том же плане службы приложений, и этот план масштабирован до четырех экземпляров. Если приложение A становится неработоспособным на двух экземплярах, подсистема балансировки нагрузки перестает отправлять запросы в App A в этих двух экземплярах. Запросы по-прежнему направляются на Приложение B на этих экземплярах, при условии, что Приложение B работает нормально. Если приложение A остается неработоспособным более часа на этих двух экземплярах, экземпляры заменяются только в том случае, если приложение B также неработоспособно для этих экземпляров. Если приложение B исправно, инстанции не заменяются.

Что если все мои экземпляры окажутся нездоровыми?

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

Что происходит во время переключения слотов?

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

Работает ли функция проверки состояния на App Service Environment?

Да, проверка работоспособности доступна для Среды служб приложений версии 3.

Следующие шаги

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