App Service-példányok monitorozása állapotellenőrzéssel

Ez a cikk azt ismerteti, hogyan használható az Állapotellenőrzés az Azure Portalon az App Service-példányok figyelésére. Az állapot-ellenőrzés növeli az alkalmazás rendelkezésre állását azáltal, hogy átirányítja a kéréseket a nem megfelelő állapotú példányoktól, és lecseréli a példányokat, ha azok nem megfelelőek. Ezt úgy teszi, hogy percenként pingeli a webalkalmazást egy ön által választott útvonalon.

Vegye figyelembe, hogy az /api/health csak egy példa. Nincs alapértelmezett állapotellenőrzési útvonal. Győződjön meg arról, hogy a választott elérési út egy érvényes elérési út, amely az alkalmazásban létezik.

Az állapot-ellenőrzés működése

• Ha egy elérési utat adott meg az alkalmazásban, az állapotellenőrzés 1 perces időközönként pingeli az elérési utat az App Service-alkalmazás összes példányán.
• Ha egy adott példányon futó webalkalmazás 10 kérés után nem válaszol 200 és 299 közötti állapotkóddal (beleértve a kódot), az App Service megállapítja, hogy a példány nem megfelelő, és eltávolítja a webalkalmazás terheléselosztójából. A nem megfelelőnek ítélt példányok sikertelen kéréseinek szükséges száma legalább két kérelemre konfigurálható.
• A példány eltávolítása után az állapot-ellenőrzés továbbra is pingeli azt. Ha a példány egy kifogástalan állapotkóddal (200-299) kezd válaszolni, a rendszer visszaadja a példányt a terheléselosztónak.
• Ha a példányon futó webalkalmazás egy órán át nem kifogástalan állapotban van, a példányt egy újra cseréli.
• A horizontális felskálázáskor az App Service pingeli az állapot-ellenőrzési útvonalat, hogy az új példányok készen legyenek.

Állapot-ellenőrzés engedélyezése

1. Az állapot-ellenőrzés engedélyezéséhez keresse meg az Azure Portalt, és válassza ki az App Service-alkalmazást.
2. A Figyelés csoportban válassza az Állapot-ellenőrzés lehetőséget.
3. Válassza az Engedélyezés lehetőséget , és adjon meg érvényes URL-címet az alkalmazáshoz, például /health vagy /api/health.
4. Válassza a Mentés parancsot.

Konfiguráció

Az állapot-ellenőrzési beállítások konfigurálása mellett az alábbi alkalmazásbeállításokat is konfigurálhatja:

Hitelesítés és biztonság

Az állapot-ellenőrzés integrálva van az App Service hitelesítési és engedélyezési funkcióival. Nincs szükség más beállításokra, ha ezek a biztonsági funkciók engedélyezve vannak.

Ha saját hitelesítési rendszert használ, az állapot-ellenőrzési útvonalnak engedélyeznie kell a névtelen hozzáférést. Az állapot-ellenőrzési végpont biztonságának biztosításához először olyan funkciókat kell használnia, mint az IP-korlátozások, az ügyféltanúsítványok vagy egy virtuális hálózat az alkalmazás hozzáférésének korlátozásához. Ha már rendelkezik ezekkel a funkciókkal, hitelesítheti az állapot-ellenőrzési kérést a fejléc x-ms-auth-internal-token vizsgálatával, és ellenőrizheti, hogy az megfelel-e a környezeti változó WEBSITE_AUTH_ENCRYPTION_KEYSHA256 kivonatának. Ha egyeznek, akkor az állapot-ellenőrzési kérelem érvényes, és az App Service-ből származik.

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

példányszám

Ha az állapot-ellenőrzés engedélyezve van, újraindíthatja és figyelheti az alkalmazáspéldányok állapotát a példányok lapon. A Példányok lapon látható a példány neve és az alkalmazás példányának állapota. A lapról manuálisan is újraindíthatja a példányt.

Ha az alkalmazáspéldány állapota "nem kifogástalan", manuálisan is újraindíthatja a példányt a tábla újraindítási gombjának használatával. Ne feledje, hogy a példánysal azonos App Service-csomagban üzemeltetett egyéb alkalmazásokat is érinti az újraindítás. Ha más alkalmazások is ugyanazt az App Service-csomagot használják, mint a példány, az újraindítás gomb nyitó paneljén jelennek meg.

Ha újraindítja a példányt, és az újraindítási folyamat meghiúsul, lehetősége lesz lecserélni a feldolgozót. (Óránként csak egy példány cserélhető le.) Ez hatással lesz az ugyanazon App Service-csomagot használó alkalmazásokra is.

Windows-alkalmazások esetén a folyamatokat a Folyamatkezelőn keresztül is megtekintheti. Ez további betekintést nyújt a példány folyamatába, beleértve a szálak számát, a magánmemóriát és a teljes CPU-időt.

Diagnosztikai információgyűjtemény

Windows-alkalmazások esetén lehetősége van diagnosztikai adatok gyűjtésére az Állapotellenőrzés lapon. A diagnosztikai gyűjtemény engedélyezése automatikus javítási szabályt ad hozzá, amely memóriaképeket hoz létre a nem megfelelő állapotú példányokhoz, és menti őket egy kijelölt tárfiókba. Ennek a beállításnak az engedélyezése módosítja az automatikus javítás konfigurációit. Ha léteznek automatikus javítási szabályok, javasoljuk, hogy ezt az App Service-diagnosztika segítségével állítsa be.

A diagnosztikai gyűjtemény engedélyezése után létrehozhat egy tárfiókot, vagy választhat egy meglévőt a fájlokhoz. Csak az alkalmazással azonos régióban választhat tárfiókokat. Ne feledje, hogy a mentés újraindítja az alkalmazást. A mentés után, ha a webhelypéldányok állapota a folyamatos pingelések után nem megfelelő, a tárfiók erőforrásához léphet, és megtekintheti a memóriaképeket.

Figyelés

Az alkalmazás állapot-ellenőrzési útvonalának megadása után az Azure Monitor használatával monitorozhatja a webhely állapotát. A portál Állapotellenőrzés paneljén válassza a Metrikák lehetőséget a felső eszköztáron. Ekkor megnyílik egy új panel, ahol megtekintheti a webhely állapot-ellenőrzési állapotelőzményeit, és létrehozhat egy új riasztási szabályt. Az állapot-ellenőrzési állapotmetrika csak akkor összesíti a sikeres pingeléseket és a hibák megjelenítését, ha a példányt a konfigurált állapot-ellenőrzés terheléselosztási küszöbértéke alapján nem megfelelőnek ítélték. Alapértelmezés szerint ez az érték 10 percre van állítva, ezért egy adott példány esetében 10 egymást követő pingelés (percenként 1) szükséges ahhoz, hogy egy adott példány kifogástalannak minősüljön, és csak ezután jelenik meg a metrika. A webhelyek monitorozásával kapcsolatos további információkért lásd Azure-alkalmazás szolgáltatáskvótákat és riasztásokat.

Korlátozások

• Az állapot-ellenőrzés engedélyezhető az ingyenes és a megosztott App Service-csomagok esetében, így metrikák is lehetnek a webhely állapotában, és riasztásokat állíthat be. Mivel azonban az ingyenes és a megosztott webhelyek nem méretezhetők fel, a nem megfelelő állapotú példányok nem lesznek lecserélve. Fel kell skáláznia az alapszintre vagy magasabb szintre, hogy felskálázhassa a két vagy több példányt, és kihasználhassa az állapot-ellenőrzés előnyeit. Ez az éles környezetben futó alkalmazások esetében ajánlott, mivel növeli az alkalmazás rendelkezésre állását és teljesítményét.
• Az App Service-csomagok óránként legfeljebb egy nem kifogástalan példányt cserélhetnek le, és legfeljebb naponta három példányt.
• A skálázási egységenkénti állapot-ellenőrzés által lecserélt példányok teljes száma nem konfigurálható. Ha eléri ezt a korlátot, a rendszer nem cseréli le a nem megfelelő állapotú példányokat. Ezt az értéket 12 óránként alaphelyzetbe állítja a rendszer.

Gyakori kérdések

Mi történik, ha az alkalmazásom egyetlen példányon fut?

Ha az alkalmazás csak egy példányra van skálázva, és nem megfelelő állapotúvá válik, akkor az nem lesz eltávolítva a terheléselosztóból, mert az teljesen le fogja venni az alkalmazást. Egy órányi folyamatos, nem kifogástalan pingelés után azonban a rendszer lecseréli a példányt. Vertikális felskálázás két vagy több példányra az állapot-ellenőrzés átirányítási előnyének eléréséhez. Ha az alkalmazás egyetlen példányon fut, továbbra is használhatja az Állapotellenőrzés monitorozási funkciót az alkalmazás állapotának nyomon követéséhez.

Miért nem jelennek meg az állapot-ellenőrzési kérelmek a webkiszolgálói naplókban?

Az állapot-ellenőrzési kérelmeket a rendszer belsőleg küldi el a webhelyre, így a kérés nem jelenik meg a webkiszolgáló naplóiban. Az állapot-ellenőrzési kódban naplómegjelenítéseket adhat hozzá, hogy megőrizze az állapot-ellenőrzési útvonal pingelésekor megadott naplókat.

HTTP-en vagy HTTPS-en keresztül küldött állapot-ellenőrzési kérelmek?

A Windowshoz és Linuxhoz készült App Service-ben a rendszer HTTPS-en keresztül küldi el az állapot-ellenőrzési kérelmeket, ha a https csak a webhelyen engedélyezve van. Ellenkező esetben a rendszer HTTP-en keresztül küldi el őket.

Az állapot-ellenőrzés követi az alkalmazáskód által konfigurált átirányításokat az alapértelmezett tartomány és az egyéni tartomány között?

Nem, az Állapotellenőrzés funkció pingeli a webalkalmazás alapértelmezett tartományának elérési útját. Ha az alapértelmezett tartományról egy egyéni tartományra van átirányítva, akkor az állapotellenőrzés által visszaadott állapotkód nem lesz 200. Ez egy átirányítás (301), amely a feldolgozót nem megfelelő állapotba jelöli.

Mi történik, ha több alkalmazásom is van ugyanazon az App Service-csomagon?

A nem kifogástalan példányok mindig törlődnek a terheléselosztó rotációjából, függetlenül az App Service-csomag többi alkalmazásától (a megadott WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENTszázalékig). Ha egy példányon lévő alkalmazás egy óránál hosszabb ideig nem kifogástalan állapotú marad, a példány csak akkor lesz lecserélve, ha az összes többi alkalmazás, amelyen az állapot-ellenőrzés engedélyezve van, szintén nem megfelelő állapotú. Az állapotellenőrzést nem engedélyező alkalmazásokat a rendszer nem veszi figyelembe.

Példa

Tegyük fel, hogy két alkalmazással (vagy egy ponttal rendelkező alkalmazással) rendelkezik, amelyeken engedélyezve van az állapot-ellenőrzés. Ezeket A és B alkalmazásnak hívják. Ugyanazon az App Service-csomagon vannak, és a csomag négy példányra van skálázva. Ha az A alkalmazás két példányon nem megfelelő állapotúvá válik, a terheléselosztó nem küld kéréseket az A alkalmazásnak ezen a két példányon. A kérelmek továbbra is a B alkalmazáshoz lesznek irányítva ezeken a példányokon, feltéve, hogy a B alkalmazás kifogástalan állapotú. Ha az A alkalmazás több mint egy órán át nem megfelelő állapotban marad ezen a két példányon, a példányok csak akkor lesznek lecserélve, ha a B alkalmazás is sérült ezeken a példányokon. Ha a B alkalmazás kifogástalan állapotú, a példányok nem lesznek lecserélve.

Mi a teendő, ha az összes példányom nem kifogástalan?

Ha az alkalmazás összes példánya sérült, az App Service nem távolítja el a példányokat a terheléselosztóból. Ebben a forgatókönyvben az összes nem kifogástalan alkalmazáspéldány terheléselosztó-rotációból való kivezetése hatékonyan kimaradáshoz vezetne az alkalmazás számára. A példány cseréje azonban továbbra is megtörténik.

Mi történik a pontcserék során?

Az állapot-ellenőrzési konfiguráció nem pontspecifikus, ezért a csere után a felcserélt pont állapot-ellenőrzési konfigurációja a célhelyre lesz alkalmazva, és fordítva. Ha például engedélyezve van az állapot-ellenőrzés az előkészítési ponton, a konfigurált végpont egy felcserélés után lesz alkalmazva az éles pontra.

Működik az állapot-ellenőrzés az App Service-környezeteken?

Igen, az állapot-ellenőrzés elérhető az App Service Environment 3-hoz.

Következő lépések

• Tevékenységnapló-riasztás létrehozása az előfizetés összes automatikus skálázási motorműveletének figyeléséhez
• Tevékenységnapló-riasztás létrehozása az előfizetésen belüli összes sikertelen automatikus méretezési/vertikális felskálázási művelet figyeléséhez
• Környezeti változók és alkalmazásbeállítások referenciája