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

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

Обратите внимание, что /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, чтобы указать, что приложение неработоспособно. Кроме того, если путь не возвращает ответ в течение 1 минуты, работоспособность проверка связи считается неработоспособной.
• При выборе пути работоспособности проверка убедитесь, что вы выбираете путь, возвращающий код состояния 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.

Экземпляры

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

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

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

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

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

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

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

Наблюдение

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

Ограничения

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

Вопросы и ответы

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

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

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

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

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

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

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

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

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

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

Пример

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

Примечание.

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

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

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

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

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

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

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