Állapot végponti monitorozását végző minta

Annak ellenőrzéséhez, hogy az alkalmazások és szolgáltatások megfelelően teljesítenek-e, használhatja az állapotvégpont monitorozási mintáját. Ez a minta a funkcionális ellenőrzések alkalmazását határozza meg egy alkalmazásban. A külső eszközök rendszeres időközönként hozzáférhetnek ezekhez az ellenőrzésekhez a közzétett végpontokon keresztül.

Kontextus és probléma

Ajánlott webalkalmazások és háttérszolgáltatások monitorozása. A monitorozással biztosítható, hogy az alkalmazások és szolgáltatások elérhetők és megfelelően teljesíthessenek. Az üzleti követelmények gyakran magukban foglalják a monitorozást.

Néha nehezebb a felhőalapú szolgáltatások monitorozása, mint a helyszíni szolgáltatások. Ennek egyik oka, hogy nem rendelkezik teljes körű vezérléssel az üzemeltetési környezet felett. A másik az, hogy a szolgáltatások általában más szolgáltatásoktól függnek, amelyeket a platform szállítói és mások nyújtanak.

Számos tényező befolyásolja a felhőben üzemeltetett alkalmazásokat. Ilyen például a hálózati késés, a mögöttes számítási és tárolási rendszerek teljesítménye és rendelkezésre állása, valamint a köztük lévő hálózati sávszélesség. A szolgáltatás teljes egészében vagy részben meghiúsulhat ezen tényezők bármelyike miatt. A szükséges rendelkezésre állás biztosításához rendszeres időközönként ellenőriznie kell, hogy a szolgáltatás megfelelően működik-e. A szolgáltatásiszint-szerződés (SLA) megadhatja a teljesítendő szintet.

Megoldás

Az állapotmonitorozást úgy valósíthatja meg, hogy kéréseket küld az alkalmazás egyik végpontjára. Az alkalmazásnak végre kell hajtania a szükséges ellenőrzéseket, majd vissza kell adnia az állapotának jelzését.

Az állapotmonitorozási ellenőrzés általában két tényezőt ötvöz:

• Az alkalmazás vagy szolgáltatás által az állapot-ellenőrzési végpontra irányuló kérésre adott válaszként végrehajtott ellenőrzések (ha vannak ilyenek)
• Az állapot-ellenőrzési ellenőrzést végző eszköz vagy keretrendszer eredményeinek elemzése

A válaszkód az alkalmazás állapotát jelzi. A válaszkód opcionálisan az alkalmazás által használt összetevők és szolgáltatások állapotát is megadja. A monitorozási eszköz vagy keretrendszer elvégzi a késési vagy válaszidő-ellenőrzést.

Az alábbi ábra áttekintést nyújt a mintáról.

Az alkalmazás állapotmonitorozási kódja más ellenőrzéseket is futtathat a következő meghatározásához:

• A felhőbeli tárolók vagy adatbázisok rendelkezésre állási és válaszideje.
• Az alkalmazás által használt egyéb erőforrások vagy szolgáltatások állapota. Ezek az erőforrások és szolgáltatások lehetnek az alkalmazásban vagy azon kívül.

Olyan szolgáltatások és eszközök érhetők el, amelyek a webalkalmazásokat úgy figyelik, hogy egy kérést egy konfigurálható végpontkészletbe küldenek. Ezek a szolgáltatások és eszközök ezután konfigurálható szabályok alapján értékelik ki az eredményeket. Viszonylag könnyű létrehozni egy szolgáltatásvégpontot egyetlen célra, hogy funkcionális teszteket hajthasson végre egy rendszeren.

A monitorozási eszközök által végrehajtott tipikus ellenőrzések a következők:

• A válaszkód ellenőrzése. Például a 200-as (OK) kódú HTTP-válasz azt jelzi, hogy az alkalmazás hiba nélkül válaszolt. Elképzelhető, hogy a monitorozási rendszer más válaszkódokat is ellenőriz annak érdekében, hogy átfogóbb eredményeket adjon vissza.
• A válasz tartalmának ellenőrzése a hibák észleléséhez még akkor is, ha az állapotkód 200 (OK). A tartalom ellenőrzésével olyan hibákat észlelhet, amelyek a visszaadott weblap vagy szolgáltatás válaszának csak egy szakaszát érintik. Ellenőrizheti például egy lap címét, vagy megkereshet egy adott kifejezést, amely azt jelzi, hogy az alkalmazás a megfelelő lapot adja vissza.
• A válaszidő mérése. Az érték tartalmazza a hálózati késést és az alkalmazást a kérés kiállításához. A növekvő érték egy probléma megjelenését jelezheti az alkalmazásban vagy a hálózatban.
• Az alkalmazáson kívül található erőforrások vagy szolgáltatások ellenőrzése. Ilyen például egy tartalomkézbesítési hálózat, amelyet az alkalmazás a globális gyorsítótárakból származó tartalmak továbbítására használ.
• A TLS-tanúsítványok lejáratának ellenőrzése.
• Az alkalmazás URL-címére vonatkozó DNS-keresés válaszidejének mérése. Ez az ellenőrzés a DNS késését és a DNS-hibákat méri.
• A DNS-keresés által visszaadott URL-cím ellenőrzése. Az érvényesítéssel meggyőződhet arról, hogy a bejegyzések helyesek. Azt is megakadályozhatja, hogy rosszindulatú kérések átirányítása a DNS-kiszolgáló elleni támadás után következhet be.

Ahol lehetséges, célszerű ezeket az ellenőrzéseket különböző helyszíni vagy üzemeltetett helyekről futtatni, majd a válaszidőket összehasonlítani. Ideális esetben az ügyfelekhez közeli helyekről kell figyelnie az alkalmazásokat. Ezután minden helyről pontos képet kap a teljesítményről. Ez a gyakorlat robusztusabb ellenőrzési mechanizmust biztosít. Az eredmények a következő döntések meghozatalában is segíthetnek:

• Az alkalmazás üzembe helyezése
• Üzembe helyezés egynél több adatközpontban

Annak érdekében, hogy az alkalmazás megfelelően működjön minden ügyfél számára, futtassa a teszteket az ügyfelek által használt összes szolgáltatáspéldányon. Ha például az ügyféltároló több tárfiókra is kiterjed, a figyelési folyamatnak ellenőriznie kell az egyes fiókokat.

Problémák és megfontolandó szempontok

Vegye figyelembe a következő szempontokat, amikor úgy dönt, hogy hogyan valósítja meg ezt a mintát:

• Gondolja át, hogyan érvényesítheti a választ. Például állapítsa meg, hogy egy 200-ás (OK) állapotkód elegendő-e annak ellenőrzéséhez, hogy az alkalmazás megfelelően működik-e. Az állapotkód ellenőrzése a minta minimális implementációja. Az állapotkód az alkalmazás rendelkezésre állásának alapszintű mértékét biztosítja. A kód azonban kevés információt tartalmaz az alkalmazás műveleteiről, trendjeiről és lehetséges jövőbeli problémáiról.

• Határozza meg az alkalmazások számára közzéteendő végpontok számát. Az egyik módszer az, hogy legalább egy végpontot elérhetővé tesz az alkalmazás által használt alapvető szolgáltatásokhoz, egy másik pedig az alacsonyabb prioritású szolgáltatásokhoz. Ezzel a megközelítéssel különböző fontossági szinteket rendelhet az egyes monitorozási eredményekhez. Érdemes lehet további végpontokat is feltárni. A monitorozás részletességének növelése érdekében minden alapvető szolgáltatáshoz közzétehet egyet. Az állapot-ellenőrzés például ellenőrizheti az adatbázist, a tárterületet és egy külső geokódolási szolgáltatást, amelyet az alkalmazás használ. Mindegyikhez eltérő üzemidőre és válaszidőre lehet szükség. Előfordulhat, hogy a geokódolási szolgáltatás vagy más háttérfeladat néhány percig nem érhető el. Az alkalmazás azonban továbbra is kifogástalan állapotú lehet.

• Döntse el, hogy ugyanazt a végpontot használja-e a figyeléshez és az általános hozzáféréshez. Ugyanazt a végpontot használhatja mindkettőhöz, de az állapot-ellenőrzéshez egy adott elérési utat tervezhet. Használhatja például az /health parancsot az általános hozzáférési végponton. Ezzel a módszerrel a monitorozási eszközök funkcionális teszteket futtathatnak az alkalmazásban. Ilyen például egy új felhasználó regisztrálása, a bejelentkezés és a tesztrendelés leadása. Ugyanakkor azt is ellenőrizheti, hogy az általános hozzáférési végpont elérhető-e.

• Határozza meg a szolgáltatásban gyűjtendő információk típusát a figyelési kérelmekre válaszul. Azt is meg kell határoznia, hogyan adja vissza ezeket az információkat. A legtöbb meglévő eszköz és keretrendszer csak a végpont által visszaadott HTTP-állapotkódot figyeli. További információk visszaadásához és érvényesítéséhez elképzelhető, hogy létre kell hoznia egy egyéni monitorozási segédprogramot vagy szolgáltatást.

• Megtudhatja, hogy mennyi információt kell összegyűjteni. A túlzott feldolgozás az ellenőrzés során túlterhelheti az alkalmazást, és hatással lehet más felhasználókra. A feldolgozási idő túllépheti a figyelési rendszer időtúllépését is. Ennek eredményeképpen előfordulhat, hogy a rendszer elérhetetlenként jelöli meg az alkalmazást. A legtöbb alkalmazás olyan rendszerállapotokat tartalmaz, mint a hibakezelők és a teljesítményszámlálók. Ezek az eszközök naplózhatják a teljesítményt és részletes hibainformációkat, ami elegendő lehet. Fontolja meg, hogy ezeket az adatokat használja az állapot-ellenőrzési ellenőrzésből származó további információk visszaadása helyett.

• Fontolja meg a végpont állapotának gyorsítótárazását. Az állapot-ellenőrzés gyakori futtatása költséges lehet. Ha például egy irányítópulton keresztül jelenti az állapotot, nem szeretné, hogy az irányítópultra irányuló minden kérés állapot-ellenőrzést aktiváljon. Ehelyett rendszeresen ellenőrizze a rendszer állapotát, és gyorsítótárazza az állapotot. Tegyen elérhetővé egy végpontot, amely visszaadja a gyorsítótárazott állapotot.

• Tervezze meg, hogyan konfigurálhatja a monitorozási végpontok biztonságát. A biztonság konfigurálásával megvédheti a végpontokat a nyilvános hozzáféréstől, ami a következő lehet:

  • Tegye elérhetővé az alkalmazást rosszindulatú támadásoknak.
  • Bizalmas információk expozíciójának kockázata.
  • Szolgáltatásmegtagadási (DoS-) támadások vonzása.

  Általában az alkalmazáskonfigurációban konfigurálja a biztonságot. Ezután egyszerűen frissítheti a beállításokat az alkalmazás újraindítása nélkül. Fontolja meg az alábbi módszerek alkalmazását:

  • Tegye biztonságossá a végpontot azáltal, hogy kötelezővé teszi a hitelesítést. Ha a monitorozási szolgáltatás vagy eszköz támogatja a hitelesítést, használhat egy hitelesítési biztonsági kulcsot a kérelem fejlécében. Hitelesítő adatokat is átadhat a kéréssel. Ha hitelesítést használ, fontolja meg, hogyan érheti el az állapot-ellenőrzési végpontokat. Például a Azure-alkalmazás Szolgáltatás beépített állapotellenőrzéssel rendelkezik, amely integrálható az App Service hitelesítési és engedélyezési funkcióival.

  • Használjon rejtett végpontot. Tegyük fel például, hogy a végpontot az alapértelmezett alkalmazás URL-címétől eltérő IP-címen teszi elérhetővé. Konfigurálja a végpontot egy nem szabványos HTTP-porton. Emellett fontolja meg a tesztoldal összetett elérési útját is. Az alkalmazáskonfigurációban általában megadhat további végpontcímeket és portokat. Szükség esetén hozzáadhat bejegyzéseket ezekhez a végpontokhoz a DNS-kiszolgálóhoz. Ezután nem kell közvetlenül megadnia az IP-címet.

  • Tegyen elérhetővé olyan metódusokat a végpontokon, amelyek olyan paramétereket fogadnak el, mint a kulcsértékek vagy a működési mód értékei. Amikor egy kérés érkezik, a kód bizonyos teszteket futtathat, amelyek a paraméter értékétől függenek. A kód 404(nem található) hibát adhat vissza, ha nem ismeri fel a paraméter értékét. Lehetővé teszi paraméterértékek megadását az alkalmazáskonfigurációban.

  • Használjon egy különálló végpontot, amely alapszintű funkcionális teszteket végez anélkül, hogy veszélyeztetné az alkalmazás működését. Ezzel a módszerrel csökkentheti a DoS-támadások hatását. Ha lehetséges, ne használjon olyan teszteket, amelyek kiszivárogtathatnak bizalmas információkat. Néha olyan információkat kell visszaadnia, amelyek hasznosak lehetnek a támadók számára. Ebben az esetben fontolja meg, hogyan védheti meg a végpontot és az adatokat a jogosulatlan hozzáféréstől. A homályra hagyatkozás nem elég. Fontolja meg a HTTPS-kapcsolat használatát és a bizalmas adatok titkosítását is, bár ez a módszer növeli a kiszolgáló terhelését.

• Döntse el, hogyan győződjön meg arról, hogy a monitorozási ügynök megfelelően működik. Az egyik módszer egy olyan végpont felfedése, amely az alkalmazáskonfigurációból származó értéket vagy egy véletlenszerű értéket ad vissza, amelyet az ügynök teszteléséhez használhat. Győződjön meg arról is, hogy a monitorozási rendszer önmagában végez ellenőrzéseket. Önteszt vagy beépített teszt használatával megakadályozhatja, hogy a monitorozási rendszer hamis pozitív eredményeket adjon ki.

Mikor érdemes ezt a mintát használni?

Ez a minta az alábbi esetekben hasznos:

• Webhelyek és webalkalmazások monitorozása a rendelkezésre állás ellenőrzése érdekében.
• Webhelyek és webalkalmazások monitorozása a megfelelő működés ellenőrzése érdekében.
• A középső rétegbeli vagy megosztott szolgáltatások monitorozása a más alkalmazásokat megzavaró hibák észlelésére és elkülönítésére.
• A meglévő alkalmazás kiegészítése például teljesítményszámlálókkal és hibakezelőkkel. Az állapot-ellenőrzés nem helyettesíti a naplózásra és naplózásra vonatkozó alkalmazáskövetelményeket. A rendszerállapot-megfigyelés értékes információkkal szolgálhat egy meglévő keretrendszerre vonatkozóan, amely monitorozza a számlálókat és a hibanaplókat a hibák vagy más problémák észlelése érdekében. A rendszerállapot azonban nem tud információt szolgáltatni, ha egy alkalmazás nem érhető el.

Számítási feladatok tervezése

Az tervezőnek értékelnie kell, hogyan használható az állapotvégpont-monitorozási minta a számítási feladat kialakításában az Azure Well-Architected Framework pilléreiben foglalt célok és alapelvek kezelésére. Példa:

Mint minden tervezési döntésnél, fontolja meg az ezzel a mintával bevezethető többi pillér céljaival szembeni kompromisszumokat.

Példa

Az ASP.NET állapot-ellenőrző köztes szoftvereket és kódtárakat használhatja az alkalmazásinfrastruktúra-összetevők állapotának jelentéséhez. Ez a keretrendszer lehetővé teszi az állapot-ellenőrzések egységes jelentését. A cikk által leírt számos gyakorlatot implementálja. Az ASP.NET állapotellenőrzései közé tartoznak például a külső ellenőrzések, például az adatbázis-kapcsolat, valamint az olyan konkrét fogalmak, mint az élőképesség- és készültségi mintavételek.

A GitHubon számos példa implementáció érhető el, amelyek ASP.NET állapotellenőrzést használnak.

Végpontok monitorozása az Azure által üzemeltetett alkalmazásokban

Az Azure-alkalmazások végpontjai monitorozásának lehetőségei a következők:

• Használja az Azure beépített monitorozási funkcióit, például az Azure Monitort.
• Használjon külső szolgáltatást vagy keretrendszert, például a Microsoft System Center Operations Managert.
• Hozzon létre egy egyéni segédprogramot vagy szolgáltatást, amely a saját kiszolgálóján vagy egy üzemeltetett kiszolgálón fut.

Annak ellenére, hogy az Azure átfogó monitorozási lehetőségeket biztosít, további szolgáltatásokat és eszközöket is használhat további információk biztosításához. A Monitor egyik funkciója, az Application Insights fejlesztői csapatok számára készült. Ez a funkció segít megérteni, hogyan működik az alkalmazás, és hogyan használják. Az Application Insights figyeli a kérések sebességét, a válaszidőket, a hibaarányokat és a függőségi arányokat. Segítségével megállapíthatja, hogy a külső szolgáltatások lelassítják-e a szolgáltatásokat.

A monitorozás feltételei az alkalmazáshoz választott üzemeltetési mechanizmustól függenek. A szakasz összes lehetősége támogatja a riasztási szabályokat. A riasztási szabályok a szolgáltatás beállításaiban megadott webes végpontot használják. Ennek a végpontnak időben kell válaszolnia, hogy a riasztási rendszer észlelhesse, hogy az alkalmazás megfelelően működik. További információ: Új riasztási szabály létrehozása.

Ha jelentős leállás áll fenn, az ügyfélforgalomnak olyan alkalmazástelepítésre kell irányulnia, amely más régiókban vagy zónákban érhető el. Ez a helyzet jó eset a helyszíni kapcsolatok és a globális terheléselosztás esetében. A választás attól függ, hogy az alkalmazás belső vagy külső elérésű-e. Az olyan szolgáltatások, mint az Azure Front Door, az Azure Traffic Manager vagy a tartalomkézbesítési hálózatok, az állapottesztek által biztosított adatok alapján irányíthatják a régiók közötti forgalmat.

A Traffic Manager egy útválasztási és terheléselosztási szolgáltatás. Számos szabály és beállítás használatával terjesztheti a kérelmeket az alkalmazás adott példányai között. Az útválasztási kérelmek mellett a Traffic Manager rendszeresen pingel egy URL-címet, portot és relatív útvonalat. Megadhatja a pingelési célokat annak meghatározásához, hogy az alkalmazás mely példányai aktívak, és válaszoljanak a kérelmekre. Ha a Traffic Manager egy 200-as (OK) állapotkódot észlel, az elérhetőként jelöli meg az alkalmazást. A Traffic Manager minden más állapotkód esetén offline állapotúként jelöli az alkalmazást. A Traffic Manager-konzol megjeleníti az egyes alkalmazások állapotát. Minden szabályt konfigurálhat úgy, hogy a kéréseket átirányítsa a válaszoló alkalmazás más példányaihoz.

A Traffic Manager egy bizonyos ideig várakozik, amíg választ kap a figyelési URL-címről. Győződjön meg arról, hogy az állapot-ellenőrzési kód ebben az időben fut. Engedélyezze a hálózati késést a Traffic Managerből az alkalmazásba és visszafelé tartó oda-vissza utazáshoz.

Következő lépések

Az alábbi útmutató hasznos a minta implementálásához:

• Állapotfigyelési útmutató mikroszolgáltatás-alapú alkalmazásokban
• Az alkalmazás állapotának monitorozása a megbízhatóság érdekében, az Azure Well-Architected Framework része
• Új riasztási szabály létrehozása

Kapcsolódó erőforrások

• Külső konfigurációs tár mintája
• Áramkör-megszakító minta
• Átjáró-útválasztási minta
• Gatekeeper-minta