Мониторинг экземпляров Служба приложений с помощью проверки работоспособности

Примечание.

Начиная с 1 июня 2024 г. все созданные Служба приложений приложения будут иметь возможность создать уникальное имя узла по умолчанию с помощью соглашения <app-name>-<random-hash>.<region>.azurewebsites.netоб именовании. Существующие имена приложений останутся неизменными.

Пример: myapp-ds27dh7271aah175.westus-01.azurewebsites.net

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

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

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

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

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

Примечание.

• Проверка работоспособности не соответствует 302 перенаправлениям.
• По крайней мере один экземпляр будет заменен в час с не более чем тремя экземплярами в день на Служба приложений план.
• Если проверка работоспособности отправляет состояние Waiting for health check response, то проверка, скорее всего, завершается ошибкой из-за кода состояния HTTP 307, который может произойти, если у вас включена перенаправления HTTPS, но отключена HTTPS Only .

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

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

Примечание.

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

Внимание

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

Настройка

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

Имя параметра приложения	Допустимые значения	Description
WEBSITE_HEALTHCHECK_MAXPINGFAILURES	2 — 10	Требуемое число неудачных запросов для экземпляра, который будет считаться неработоспособным и удален из подсистемы балансировки нагрузки. Например, если это задано 2, экземпляры удаляются после 2 неудачных оповещение. (Значение по умолчанию — 10.)
WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENT	1 - 100	По умолчанию, чтобы избежать подавляющего числа оставшихся работоспособных экземпляров, не более половины экземпляров будут исключены из подсистемы балансировки нагрузки одновременно. Например, если план Служба приложений масштабируется до четырех экземпляров и три являются неработоспособными, два из них исключены. Остальные два экземпляра (один работоспособный и один неработоспособный) продолжают получать запросы. В сценарии, когда все экземпляры неработоспособны, ни один из них не исключается. Чтобы переопределить это поведение, задайте для этого параметра значение между 1 и 100. Более высокое значение означает, что удаляются более неработоспособные экземпляры. (Значение по умолчанию — 50.).

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

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

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

Примечание.

Для проверки подлинности Функции Azure функция, которая служит конечной точкой проверки работоспособности, должна разрешить анонимный доступ.

.NET

using System;
using System.Text;

/// <summary>
/// Method <c>HeaderMatchesEnvVar</c> returns true if <c>headerValue</c> matches WEBSITE_AUTH_ENCRYPTION_KEY.
/// </summary>
public Boolean HeaderMatchesEnvVar(string headerValue) {
    var sha = System.Security.Cryptography.SHA256.Create();
    String envVar = Environment.GetEnvironmentVariable("WEBSITE_AUTH_ENCRYPTION_KEY");
    String hash = System.Convert.ToBase64String(sha.ComputeHash(Encoding.UTF8.GetBytes(envVar)));
    return hash == headerValue;
}

Python

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

Java

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);
}

Node.js

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;
}

Примечание.

Заголовок x-ms-auth-internal-token доступен только в Служба приложений для Windows.

Экземпляры

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

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

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

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

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

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

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

Наблюдение

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

Ограничения

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

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

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

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

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

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

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

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

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

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

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

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

Пример

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

Примечание.

Если был другой сайт или слот плана (App C) без включения проверки работоспособности, он не будет учитываться для замены экземпляра.

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

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

Работает ли проверка работоспособности на Среда службы приложений?

Да, проверка работоспособности доступна для Среда службы приложений версии 3, но не для версий 1 или 2. Если вы используете более старые версии Среда службы приложений, вы можете использовать функцию миграции для переноса Среда службы приложений на версию 3.

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

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