Monitorowanie wystąpień usługi App Service przy użyciu kontroli kondycji

Uwaga

Od 1 czerwca 2024 r. wszystkie nowo utworzone aplikacje usługi App Service będą miały możliwość wygenerowania unikatowej domyślnej nazwy hosta przy użyciu konwencji <app-name>-<random-hash>.<region>.azurewebsites.netnazewnictwa . Istniejące nazwy aplikacji pozostaną niezmienione.

Przykład: myapp-ds27dh7271aah175.westus-01.azurewebsites.net

Aby uzyskać więcej informacji, zapoznaj się z unikatową domyślną nazwą hosta zasobu usługi App Service.

W tym artykule opisano sposób używania kontroli kondycji w witrynie Azure Portal do monitorowania wystąpień usługi App Service. Kontrola kondycji zwiększa dostępność aplikacji, przekierowując żądania z dala od wystąpień w złej kondycji i zastępując wystąpienia, jeśli pozostają w złej kondycji. Robi to, wysyłając polecenie ping do aplikacji internetowej co minutę za pomocą wybranej ścieżki.

Należy pamiętać, że /api/health jest tylko przykładem. Nie ma domyślnej ścieżki sprawdzania kondycji. Upewnij się, że wybrana ścieżka jest prawidłową ścieżką, która istnieje w aplikacji.

Jak działa sprawdzanie kondycji

• Po podaniu ścieżki w aplikacji sprawdź, czy kondycja wysyła polecenie ping do ścieżki we wszystkich wystąpieniach aplikacji usługi App Service w odstępach 1-minutowych.
• Jeśli aplikacja internetowa uruchomiona w danym wystąpieniu nie odpowiada za pomocą kodu stanu z zakresu od 200 do 299 (włącznie) po 10 żądaniach, usługa App Service określa, że wystąpienie jest w złej kondycji i usuwa je z modułu równoważenia obciążenia dla aplikacji internetowej. Wymagana liczba żądań zakończonych niepowodzeniem dla wystąpienia, które ma zostać uznane za w złej kondycji, można skonfigurować do co najmniej dwóch żądań.
• Po usunięciu wystąpienia sprawdzanie kondycji będzie nadal wysyłać polecenie ping. Jeśli wystąpienie zacznie odpowiadać kodem stanu w dobrej kondycji (200–299), wystąpienie zostanie zwrócone do modułu równoważenia obciążenia.
• Jeśli aplikacja internetowa uruchomiona w wystąpieniu pozostaje w złej kondycji przez jedną godzinę, wystąpienie zostanie zastąpione nowym.
• Podczas skalowania w górę usługa App Service wysyła polecenie ping do ścieżki sprawdzania kondycji, aby upewnić się, że nowe wystąpienia są gotowe.

Uwaga

• Sprawdzanie kondycji nie jest zgodne z 302 przekierowaniami.
• Co najwyżej jedno wystąpienie zostanie zastąpione na godzinę z maksymalnie trzema wystąpieniami dziennie na plan usługi App Service.
• Jeśli sprawdzanie kondycji wysyła stan Waiting for health check response, sprawdzanie prawdopodobnie kończy się niepowodzeniem z powodu kodu stanu HTTP 307, co może się zdarzyć, jeśli masz włączone przekierowanie HTTPS, ale zostało HTTPS Only wyłączone.

Włącz kontrolę kondycji

1. Aby włączyć kontrolę kondycji, przejdź do witryny Azure Portal i wybierz aplikację usługi App Service.
2. W obszarze Monitorowanie wybierz pozycję Sprawdzanie kondycji.
3. Wybierz pozycję Włącz i podaj prawidłową ścieżkę adresu URL dla aplikacji, na przykład /health lub /api/health.
4. Wybierz pozycję Zapisz.

Uwaga

• Plan usługi App Service powinien być skalowany do co najmniej dwóch wystąpień, aby w pełni wykorzystać kontrolę kondycji.
• Ścieżka sprawdzania kondycji powinna sprawdzać krytyczne składniki aplikacji. Jeśli na przykład aplikacja zależy od bazy danych i systemu obsługi komunikatów, punkt końcowy sprawdzania kondycji powinien połączyć się z tymi składnikami. Jeśli aplikacja nie może nawiązać połączenia ze składnikiem krytycznym, ścieżka powinna zwrócić kod odpowiedzi na poziomie 500, aby wskazać, że aplikacja jest w złej kondycji. Ponadto jeśli ścieżka nie zwróci odpowiedzi w ciągu jednej minuty, polecenie ping sprawdzania kondycji jest uznawane za w złej kondycji.
• Podczas wybierania ścieżki sprawdzania kondycji upewnij się, że wybierasz ścieżkę zwracającą kod stanu 200 tylko wtedy, gdy aplikacja jest w pełni rozgrzana.
• Aby można było korzystać z kontroli kondycji w aplikacji funkcji, należy użyć planu hostingu w warstwie Premium lub dedykowanej.
• Szczegółowe informacje na temat sprawdzania kondycji aplikacji funkcji można znaleźć tutaj: Monitorowanie aplikacji funkcji przy użyciu kontroli kondycji.

Uwaga

Zmiany konfiguracji kontroli kondycji ponownie uruchamiają aplikację. Aby zminimalizować wpływ na aplikacje produkcyjne, zalecamy skonfigurowanie miejsc przejściowych i zamianę na środowisko produkcyjne.

Konfigurowanie

Oprócz konfigurowania opcji kontroli kondycji można również skonfigurować następujące ustawienia aplikacji:

Nazwa ustawienia aplikacji	Dozwolone wartości	opis
WEBSITE_HEALTHCHECK_MAXPINGFAILURES	2 - 10	Wymagana liczba żądań zakończonych niepowodzeniem dla wystąpienia, które mają zostać uznane za w złej kondycji i usunięte z modułu równoważenia obciążenia. Na przykład po ustawieniu 2tego ustawienia na , wystąpienia zostaną usunięte po 2 nieudanych poleceniach ping. (Wartość domyślna to 10.)
WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENT	1 - 100	Domyślnie, aby uniknąć przeciążenia pozostałych wystąpień w dobrej kondycji, nie więcej niż połowa wystąpień zostanie wykluczona z modułu równoważenia obciążenia jednocześnie. Jeśli na przykład plan usługi App Service jest skalowany do czterech wystąpień, a trzy są w złej kondycji, dwa są wykluczone. Pozostałe dwa wystąpienia (jedna w dobrej kondycji i jedna w złej kondycji) nadal odbierają żądania. W scenariuszu, w którym wszystkie wystąpienia są w złej kondycji, żaden z nich nie jest wykluczony. Aby zastąpić to zachowanie, ustaw to ustawienie aplikacji na wartość między 1 i 100. Wyższa wartość oznacza, że usunięto więcej wystąpień w złej kondycji. (Wartość domyślna to 50.).

Uwierzytelnianie i zabezpieczenia

Kontrola kondycji integruje się z funkcjami uwierzytelniania i autoryzacji usługi App Service. Jeśli te funkcje zabezpieczeń nie są włączone, nie są wymagane żadne inne ustawienia.

Jeśli używasz własnego systemu uwierzytelniania, ścieżka sprawdzania kondycji musi zezwalać na dostęp anonimowy. Aby zapewnić bezpieczeństwo punktu końcowego kontroli kondycji, należy najpierw użyć funkcji, takich jak ograniczenia adresów IP, certyfikaty klienta lub sieć wirtualna, aby ograniczyć dostęp do aplikacji. Po wprowadzeniu tych funkcji można uwierzytelnić żądanie sprawdzania kondycji, sprawdzając nagłówek x-ms-auth-internal-token i sprawdzając, czy jest on zgodny ze skrótem SHA256 zmiennej środowiskowej WEBSITE_AUTH_ENCRYPTION_KEY. Jeśli są one zgodne, żądanie sprawdzania kondycji jest prawidłowe i pochodzi z usługi App Service.

Uwaga

W przypadku uwierzytelniania usługi Azure Functions funkcja, która służy jako punkt końcowy kontroli kondycji, musi zezwalać na dostęp anonimowy.

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

Uwaga

Nagłówek x-ms-auth-internal-token jest dostępny tylko w usłudze App Service dla systemu Windows.

Wystąpienia

Po włączeniu sprawdzania kondycji można ponownie uruchomić i monitorować stan wystąpień aplikacji na karcie wystąpienia. Karta Wystąpienia zawiera nazwę wystąpienia i stan wystąpienia tej aplikacji. Możesz również ręcznie ponownie uruchomić wystąpienie na tej karcie.

Jeśli stan wystąpienia aplikacji jest "w złej kondycji", możesz uruchomić ponownie wystąpienie ręcznie, używając przycisku ponownego uruchamiania w tabeli. Należy pamiętać, że wszystkie inne aplikacje hostowane w tym samym planie usługi App Service co wystąpienie również będą miały wpływ na ponowne uruchomienie. Jeśli istnieją inne aplikacje korzystające z tego samego planu usługi App Service co wystąpienie, są one wyświetlane w bloku otwierania z przycisku ponownego uruchamiania.

Jeśli uruchomisz ponownie wystąpienie i proces ponownego uruchamiania zakończy się niepowodzeniem, otrzymasz opcję zastąpienia procesu roboczego. (Tylko jedno wystąpienie można zamienić na godzinę). Będzie to również miało wpływ na wszystkie aplikacje korzystające z tego samego planu usługi App Service.

W przypadku aplikacji systemu Windows można również wyświetlać procesy za pośrednictwem Eksploratora procesów. Zapewnia to dalsze szczegółowe informacje na temat procesów wystąpienia, w tym liczby wątków, pamięci prywatnej i łącznego czasu procesora CPU.

Zbieranie informacji diagnostycznych

W przypadku aplikacji systemu Windows możesz zbierać informacje diagnostyczne na karcie Kontrola kondycji. Włączenie zbierania danych diagnostycznych dodaje regułę automatycznego naprawy, która tworzy zrzuty pamięci dla wystąpień w złej kondycji i zapisuje je na wyznaczonym koncie magazynu. Włączenie tej opcji powoduje zmianę konfiguracji automatycznego naprawy. Jeśli istnieją reguły automatycznego naprawy, zalecamy skonfigurowanie tej opcji za pomocą diagnostyki usługi App Service.

Po włączeniu zbierania danych diagnostycznych możesz utworzyć konto magazynu lub wybrać istniejące dla plików. Możesz wybrać tylko konta magazynu w tym samym regionie co aplikacja. Pamiętaj, że zapisywanie ponownie uruchamia aplikację. Po zapisaniu, jeśli wystąpienia witryny są w złej kondycji po ciągłych poleceniach ping, możesz przejść do zasobu konta magazynu i wyświetlić zrzuty pamięci.

Monitorowanie

Po podaniu ścieżki sprawdzania kondycji aplikacji możesz monitorować kondycję witryny przy użyciu usługi Azure Monitor. W bloku Sprawdzanie kondycji w portalu wybierz pozycję Metryki na górnym pasku narzędzi. Spowoduje to otwarcie nowego bloku, w którym można wyświetlić historię stanu kondycji witryny i utworzyć nową regułę alertu. Metryki kontroli kondycji agregują pomyślne polecenia ping i wyświetlają błędy tylko wtedy, gdy wystąpienie zostało uznane za w złej kondycji na podstawie konfiguracji sprawdzania kondycji. Aby uzyskać więcej informacji na temat monitorowania witryn, zobacz aplikacja systemu Azure Service quotas and alerts (Limity przydziału i alerty usługi aplikacja systemu Azure Service).

Ograniczenia

• Sprawdzanie kondycji można włączyć dla bezpłatnych i udostępnionych planów usługi App Service, dzięki czemu można mieć metryki dotyczące kondycji witryny i konfigurować alerty. Jednak ponieważ witryny bezpłatne i udostępnione nie mogą skalować w poziomie, wystąpienia w złej kondycji nie zostaną zastąpione. Należy skalować w górę do warstwy Podstawowa lub wyższą, aby można było skalować w poziomie do co najmniej dwóch wystąpień i uzyskać pełną korzyść z kontroli kondycji. Jest to zalecane w przypadku aplikacji przeznaczonych dla środowiska produkcyjnego, ponieważ zwiększa dostępność i wydajność aplikacji.
• Plan usługi App Service może mieć maksymalnie jedno wystąpienie w złej kondycji zastąpione na godzinę i co najwyżej trzy wystąpienia dziennie.
• Istnieje niekonfigurowalny limit całkowitej liczby wystąpień zastąpionych przez kontrolę kondycji na jednostkę skalowania. Jeśli ten limit zostanie osiągnięty, nie zostaną zastąpione żadne wystąpienia w złej kondycji. Ta wartość jest resetowany co 12 godzin.

Często zadawane pytania

Co się dzieje, jeśli moja aplikacja jest uruchomiona w jednym wystąpieniu?

Jeśli aplikacja jest skalowana tylko do jednego wystąpienia i staje się w złej kondycji, nie zostanie usunięta z modułu równoważenia obciążenia, ponieważ spowoduje to całkowite usunięcie aplikacji. Jednak po upływie jednej godziny ciągłych poleceń ping w złej kondycji wystąpienie zostanie zastąpione. Skalowanie w poziomie do co najmniej dwóch wystąpień w celu uzyskania korzyści z przekierowania kontroli kondycji. Jeśli aplikacja jest uruchomiona w jednym wystąpieniu, nadal możesz użyć funkcji monitorowania kontroli kondycji, aby śledzić kondycję aplikacji.

Dlaczego żądania sprawdzania kondycji nie są wyświetlane w dziennikach serwera internetowego?

Żądania kontroli kondycji są wysyłane wewnętrznie do witryny, więc żądanie nie będzie wyświetlane w dziennikach serwera internetowego. Instrukcje dziennika można dodać w kodzie sprawdzania kondycji, aby zachować dzienniki po wysłaniu polecenia ping do ścieżki sprawdzania kondycji.

Czy żądania kontroli kondycji są wysyłane za pośrednictwem protokołu HTTP lub HTTPS?

W usłudze App Service dla systemów Windows i Linux żądania sprawdzania kondycji są wysyłane za pośrednictwem protokołu HTTPS, gdy w witrynie jest włączony tylko protokół HTTPS. W przeciwnym razie są one wysyłane za pośrednictwem protokołu HTTP.

Czy sprawdzanie kondycji jest zgodne ze skonfigurowanym kodem aplikacji przekierowania między domeną domyślną a domeną niestandardową?

Nie, funkcja sprawdzania kondycji wysyła polecenie ping do ścieżki domyślnej domeny aplikacji internetowej. Jeśli istnieje przekierowanie z domeny domyślnej do domeny niestandardowej, kod stanu zwracany przez sprawdzanie kondycji nie będzie 200. Będzie to przekierowanie (301), które oznacza złą kondycję procesu roboczego.

Co zrobić, jeśli mam wiele aplikacji w tym samym planie usługi App Service?

Wystąpienia w złej kondycji będą zawsze usuwane z rotacji modułu równoważenia obciążenia niezależnie od innych aplikacji w planie usługi App Service (do wartości procentowej określonej w WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENTelemencie ). Jeśli aplikacja w wystąpieniu pozostaje w złej kondycji przez więcej niż godzinę, wystąpienie zostanie zastąpione tylko wtedy, gdy wszystkie inne aplikacje, dla których włączono kontrolę kondycji, również będą w złej kondycji. Aplikacje, które nie mają włączonej kontroli kondycji, nie będą uwzględniane.

Przykład

Załóżmy, że masz dwie aplikacje (lub jedną aplikację z miejscem) z włączonym sprawdzaniem kondycji. Są one nazywane aplikacjami A i App B. Są one w tym samym planie usługi App Service, a plan jest skalowany w poziomie do czterech wystąpień. Jeśli aplikacja A stanie się w złej kondycji w dwóch wystąpieniach, moduł równoważenia obciążenia przestanie wysyłać żądania do aplikacji A w tych dwóch wystąpieniach. Żądania są nadal kierowane do aplikacji B w tych wystąpieniach, przy założeniu, że aplikacja B jest w dobrej kondycji. Jeśli aplikacja A pozostaje w złej kondycji przez ponad godzinę w tych dwóch wystąpieniach, wystąpienia są zastępowane tylko wtedy, gdy aplikacja B jest również w złej kondycji dla tych wystąpień. Jeśli aplikacja B jest w dobrej kondycji, wystąpienia nie są zastępowane.

Uwaga

Jeśli w planie (App C) nie włączono innej lokacji lub miejsca, nie zostanie ona uwzględniona w zamian wystąpienia.

Co zrobić, jeśli wszystkie moje wystąpienia są w złej kondycji?

Jeśli wszystkie wystąpienia aplikacji są w złej kondycji, usługa App Service nie usunie wystąpień z modułu równoważenia obciążenia. W tym scenariuszu usunięcie wszystkich wystąpień aplikacji w złej kondycji z rotacji modułu równoważenia obciążenia spowodowałoby awarię aplikacji. Jednak zastąpienie wystąpienia będzie nadal występować.

Czy kontrola kondycji działa w środowiskach App Service Environment?

Tak, sprawdzanie kondycji jest dostępne dla środowiska App Service Environment w wersji 3, ale nie dla wersji 1 lub 2. Jeśli używasz starszych wersji środowiska App Service Environment, możesz użyć funkcji migracji, aby przeprowadzić migrację środowiska App Service Environment do wersji 3.

Następne kroki

• Tworzenie alertu dziennika aktywności w celu monitorowania wszystkich operacji aparatu skalowania automatycznego w ramach subskrypcji
• Utwórz alert dziennika aktywności, aby monitorować wszystkie nieudane operacje skalowania automatycznego w poziomie/skalowania w poziomie w ramach subskrypcji
• Dokumentacja zmiennych środowiskowych i ustawień aplikacji