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

W tym artykule jest używana kontrola 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. Wykonuje to przez polecenie ping co minutę ścieżkę wybranej aplikacji internetowej.

Należy pamiętać, że /api/health jest tylko przykładem dodanym do celów ilustracyjnych. Domyślnie nie tworzymy ścieżki sprawdzania kondycji. Upewnij się, że wybrana ścieżka jest prawidłową ścieżką, która istnieje w aplikacji

Co usługa App Service robi z kontrolą kondycji

• Po podaniu ścieżki w aplikacji sprawdź kondycję, czy polecenie pinguje tę ścieżkę we wszystkich wystąpieniach aplikacji usługi App Service w 1-minutowych odstępach czasu.
• 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 jest w złej kondycji i usuwa ją z modułu równoważenia obciążenia dla tej 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 sprawdzanie kondycji nadal wysyła polecenie ping do wystąpienia w złej kondycji. 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.
• Zastępowane będzie maksymalnie jedno wystąpienie na godzinę, a maksymalnie trzy wystąpienia dziennie w ramach planu usługi App Service.
• Jeśli kontrola kondycji daje 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 w 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 1 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 wartości na 2, wystąpienia zostaną usunięte po 2 niepomyślnie wyświetlonych poleceniach ping. (Wartość domyślna to 10)
WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENT	1 - 100	Domyślnie nie więcej niż połowa wystąpień zostanie jednocześnie wykluczona z modułu równoważenia obciążenia, aby uniknąć przeciążenia pozostałych wystąpień w dobrej kondycji. 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 najgorszym scenariuszu, w którym wszystkie wystąpienia są w złej kondycji, żaden z nich nie jest wykluczony. Aby zastąpić to zachowanie, ustaw 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 zabezpieczyć punkt końcowy 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-tokeni sprawdzając, czy jest on zgodny ze skrótem SHA256 zmiennej środowiskowej WEBSITE_AUTH_ENCRYPTION_KEY. Jeśli są one zgodne, żądanie kontroli kondycji jest prawidłowe i pochodzi z usługi App Service.

Uwaga

W szczególności w przypadku uwierzytelniania usługi Azure Functions funkcja, która służy jako punkt końcowy sprawdzania 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 systemu Windows.

Wystąpienia

Po włączeniu sprawdzania kondycji można ponownie uruchomić i monitorować stan wystąpień aplikacji za pomocą karty wystąpienia. Na karcie Wystąpienia wyświetlana jest nazwa wystąpienia, stan wystąpienia aplikacji i można ręcznie ponownie uruchomić wystąpienie.

Jeśli stan wystąpienia aplikacji jest w złej kondycji, możesz uruchomić ponownie wystąpienie ręcznie przy użyciu 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 (można zamienić tylko 1 wystąpienie na godzinę). Będzie to również miało wpływ na wszystkie aplikacje korzystające z tego samego planu usługi App Service.

Aplikacje systemu Windows będą również miały możliwość wyświetlania procesów za pośrednictwem Eksploratora procesów. Zapewnia to dalsze 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 ją 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ć lub wybrać istniejące konto magazynu 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 będzie widoczny historyczny stan kondycji witryny i opcja utworzenia nowej reguły alertu. Metryki kontroli kondycji agregują pomyślne polecenia ping i błędy wyświetlania tylko wtedy, gdy wystąpienie zostało uznane za w złej kondycji na podstawie konfiguracji kontroli kondycji. Aby uzyskać więcej informacji na temat monitorowania witryn, zobacz przewodnik po usłudze Azure Monitor.

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 i konfiguracji witryny, ale ponieważbezpłatne i udostępnione witryny nie mogą skalować się w poziomie, żadne 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 2 lub większej liczby wystąpień i korzystać z pełnej korzyści z kontroli kondycji. Jest to zalecane w przypadku aplikacji przeznaczonych dla środowiska produkcyjnego, ponieważ zwiększy 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 niemożliwy do skonfigurowania 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 systemu Windows żą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. W usłudze App Service systemu Linux żądania kontroli kondycji są wysyłane tylko za pośrednictwem protokołu HTTP i nie można ich obecnie wysyłać za pośrednictwem protokołu HTTPS .

Czy sprawdzanie kondycji jest następujące po kodzie aplikacji skonfigurowanym 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, wówczas kod stanu zwracany przez sprawdzanie kondycji nie będzie adresem 200, ale przekierowaniem (301), który oznacza kondycję procesu roboczego w złej kondycji.

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 ). Gdy aplikacja w wystąpieniu pozostaje w złej kondycji przez ponad godzinę, wystąpienie zostanie zastąpione tylko wtedy, gdy wszystkie inne aplikacje z włączonym sprawdzaniem kondycji również są 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 o nazwie App A i App B. Znajdują się one w tym samym planie usługi App Service i że 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, te 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ąpienie nie zostanie zastąpione.

Uwaga

Jeśli w planie (lokacji C) nie włączono innej lokacji lub miejsca, nie należy brać pod uwagę zastąpienia wystąpienia.

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

W scenariuszu, w którym 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ąpień będzie nadal honorowane.

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