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

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

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

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

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

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

1. Чтобы включить проверку работоспособности, перейдите на портал Azure и выберите приложение службы приложений.
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".

Ограничения

• Проверка работоспособности может быть включена для бесплатных и общих планов службы приложений, чтобы вы могли иметь метрики работоспособности сайта и настроить оповещения. Тем не менее, так как бесплатные и общие сайты не поддерживают горизонтальное масштабирование, неработоспособные экземпляры не будут заменены автоматически. Необходимо увеличить масштаб до уровня "Базовый" или выше, чтобы масштабировать до двух или более экземпляров и в полной мере воспользоваться преимуществами проверки работоспособности. Мы рекомендуем эту конфигурацию для рабочих приложений, так как она повышает доступность и производительность приложения.
• В плане службы приложений за один час может быть заменен не более одного неработоспособного экземпляра, и не более трех экземпляров в день.
• Существует неконфигурируемое ограничение на общее количество экземпляров, заменяемых проверкой состояния для каждой единицы масштабирования. Если достигнуто это ограничение, неисправные экземпляры не будут заменены. Это значение сбрасывается каждые 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 исправно, инстанции не заменяются.

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

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

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

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

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

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

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

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