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

Ez a cikk az Azure Portal állapotellenőrzésével figyeli az App Service-példányokat. 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 választott webalkalmazás elérési útját.

Vegye figyelembe, hogy az /api/health csak illusztrációs célokra hozzáadott példa. Alapértelmezés szerint nem hozunk létre állapot-ellenőrzési útvonalat. Győződjön meg arról, hogy a kiválasztott elérési út érvényes elérési út, amely az alkalmazásban létezik

Mit végez az App Service az állapotellenőrzésekkel?

• Ha egy elérési utat adott meg az alkalmazásban, az állapotellenőrzés 1 perces időközönként pingeli ezt 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–299 közötti állapotkóddal (beleértve) az állapotkódot, az App Service megállapítja, hogy az 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ó.
• Az eltávolítás után az állapot-ellenőrzés továbbra is pingeli a nem kifogástalan állapotú példányt. 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.

Feljegyzés

• Az állapot-ellenőrzés nem követi a 302 átirányítást.
• Legfeljebb egy példány lesz lecserélve óránként, app service-csomagonként naponta legfeljebb három példányra.
• Ha az állapot-ellenőrzés állapotot Waiting for health check response ad meg, akkor az ellenőrzés valószínűleg egy 307-es HTTP-állapotkód miatt meghiúsul, ami akkor fordulhat elő, ha engedélyezve van a HTTPS-átirányítás, de le van HTTPS Only tiltva.

Á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ásban, például /health vagy /api/health.
4. Válassza a Mentés parancsot.

Feljegyzés

• Az Állapotellenőrzés teljes körű használatához az App Service-csomagot két vagy több példányra kell skálázni.
• Az állapot-ellenőrzési útvonalnak ellenőriznie kell az alkalmazás kritikus összetevőit. Ha például az alkalmazás egy adatbázistól és egy üzenetkezelő rendszertől függ, az állapot-ellenőrzési végpontnak csatlakoznia kell ezekhez az összetevőkhöz. Ha az alkalmazás nem tud csatlakozni egy kritikus összetevőhöz, az elérési útnak egy 500 szintű válaszkódot kell visszaadnia, amely jelzi, hogy az alkalmazás nem megfelelő állapotú. Ha az elérési út 1 percen belül nem ad vissza választ, az állapot-ellenőrzési ping nem megfelelőnek minősül.
• Az állapot-ellenőrzési útvonal kiválasztásakor győződjön meg arról, hogy olyan elérési utat választ, amely 200 állapotkódot ad vissza, csak akkor, ha az alkalmazás teljesen be van melegítve.
• Ahhoz, hogy állapotellenőrzést használhasson a függvényalkalmazásban, prémium szintű vagy dedikált üzemeltetési csomagot kell használnia.
• A függvényalkalmazások állapot-ellenőrzésének részletei itt találhatók: Függvényalkalmazások monitorozása állapotellenőrzéssel.

Figyelemfelhívás

Az állapot-ellenőrzés konfigurációs módosításai újraindítják az alkalmazást. Az éles alkalmazásokra gyakorolt hatás minimalizálása érdekében javasoljuk az előkészítési pontok konfigurálását és az élesre való váltást.

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:

Alkalmazásbeállítás neve	Megengedett értékek	Leírás
WEBSITE_HEALTHCHECK_MAXPINGFAILURES	2 - 10	A példány nem megfelelőnek ítélt és a terheléselosztóból eltávolított sikertelen kérések szükséges száma. Ha például be van 2állítva, a rendszer a sikertelen pingelések után 2 eltávolítja a példányokat. (Alapértelmezett érték: 10)
WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENT	1 - 100	Alapértelmezés szerint a példányok legfeljebb fele lesz kizárva egyszerre a terheléselosztóból, hogy ne terhelje túl a többi kifogástalan példányt. Ha például egy App Service-csomag négy példányra van skálázva, és három nem megfelelő állapotú, kettő ki lesz zárva. A másik két példány (egy kifogástalan és egy nem megfelelő) továbbra is fogad kéréseket. A legrosszabb esetben, amikor az összes példány kifogástalan állapotú, egyik sem kizárt. Ennek a viselkedésnek a felülbírálásához állítsa be az alkalmazásbeállítást az és 100a közötti 1 értékre. A magasabb érték azt jelenti, hogy a rendszer több nem kifogástalan példányt távolít el (az alapértelmezett érték az 50).

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 védelméhez először olyan funkciókat kell használnia, mint az IP-korlátozások, az ügyféltanúsítványok vagy a virtuális hálózat az alkalmazás hozzáférésének korlátozásához. Miután helyben megkapta ezeket a funkciókat, hitelesítheti az állapot-ellenőrzési kérést a fejléc vizsgálatával, és ellenőrizheti, x-ms-auth-internal-tokenhogy az megfelel-e a környezeti változó WEBSITE_AUTH_ENCRYPTION_KEYSHA256 kivonatának. Ha megegyeznek, akkor az állapot-ellenőrzési kérelem érvényes, és az App Service-ből származik.

Feljegyzés

Kifejezetten az Azure Functions-hitelesítéshez az állapot-ellenőrzési végpontként szolgáló függvénynek engedélyeznie kell a névtelen hozzáférést.

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

Feljegyzés

A x-ms-auth-internal-token fejléc csak a Windows App Service-ben érhető el.

példányszám

Ha az állapot-ellenőrzés engedélyezve van, a példányok lapon újraindulhat és monitorozhatja az alkalmazáspéldányok állapotát. A Példányok lapon látható a példány neve, az alkalmazás példányának állapota, és lehetővé teszi a példány manuális újraindítását.

Ha az alkalmazáspéldány állapota nem megfelelő, 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 1 példány cserélhető le). Ez hatással lesz az ugyanazon App Service-csomagot használó alkalmazásokra is.

A Windows-alkalmazások a Folyamatkezelőn keresztül is megtekinthetik a folyamatokat. 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 egy kijelölt tárfiókba menti. 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 vagy kiválaszthat egy meglévő tárfiókot 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 ki a metrikákat a felső eszköztáron. Ekkor megnyílik egy új panel, ahol megtekintheti a webhely korábbi állapotának állapotát, és új riasztási szabályt hozhat létre. Az állapot-ellenőrzési metrikák csak akkor összesítik a sikeres pingeléseket és megjelenítési hibákat, ha a példányt az állapot-ellenőrzési konfiguráció alapján nem megfelelőnek ítélték. A webhelyek monitorozásával kapcsolatos további információkért tekintse meg az Azure Monitor útmutatóját.

Korlátozások

• Az állapot-ellenőrzés engedélyezhető az ingyenes és a megosztott App Service-csomagok esetében, így metrikákat kaphat a webhely állapot- és beállítási riasztásaihoz, de mivel az ingyenes és a megosztott webhelyek nem méretezhetők fel, a nem megfelelő példányok nem lesznek lecserélve. Fel kell skáláznia az alapszintre vagy magasabb szintre, hogy 2 vagy több példányra skálázhassa fel a skálázást, és kihasználhassa az állapot-ellenőrzés teljes előnyét. 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-csomag óránként legfeljebb egy nem kifogástalan példányt cserélhet le, és legfeljebb naponta három példányt.
• A skálázási egységenként az á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ójá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üldik az állapot-ellenőrzési kérelmeket?

A Windows App Service-ben az állapot-ellenőrzési kérelmek HTTPS-en keresztül lesznek elküldve, ha a https csak a webhelyen engedélyezve van. Ellenkező esetben a rendszer HTTP-en keresztül küldi el őket. Linux App Service-ben az állapot-ellenőrzési kérelmeket a rendszer csak HTTP-n keresztül küldi el, és jelenleg nem küldhető el HTTPS-n keresztül.

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

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

Mi a teendő, 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 több mint egy órán át nem megfelelő állapotú marad, a példány csak akkor lesz lecserélve, ha az állapot-ellenőrzéssel rendelkező többi alkalmazás is sérült. 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, az "A" és a "B" alkalmazás. 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 azokon a példányokon, feltéve, hogy a B alkalmazás állapota kifogástalan. Ha az A alkalmazás több mint egy órán át nem megfelelő állapotban marad ezen a két példányon, a rendszer csak akkor cseréli le ezeket a példányokat, 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ány nem lesz lecserélve.

Feljegyzés

Ha a terv (C hely) állapotellenőrzése nélkül egy másik hely vagy pont lenne engedélyezve, akkor a példány cseréjénél nem veszi figyelembe.

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

Abban az esetben, ha az alkalmazás összes példánya nem megfelelő, 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ányok cseréjét azonban továbbra is tiszteletben tartjuk.

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, de az 1. vagy 2. verzióhoz nem. Ha az App Service-környezet régebbi verzióit használja, az áttelepítési funkcióval migrálhatja az App Service-környezetet a 3. verzióra.

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