Az Azure-ban kritikus fontosságú számítási feladatok állapotmodellezése és megfigyelhetősége

Az állapotmodellezés és a megfigyelhetőség alapvető fogalmak a megbízhatóság maximalizálásához, amely a robusztus és környezetfüggő kialakításra és monitorozásra összpontosít. Ezek a fogalmak kritikus betekintést nyújtanak az alkalmazás állapotába, elősegítve a problémák gyors azonosítását és megoldását.

A legtöbb kritikus fontosságú alkalmazás mérete és összetettsége szempontjából is jelentős, ezért nagy mennyiségű operatív adatot generál, ami megnehezíti az optimális működési műveletek kiértékelését és meghatározását. Az állapotmodellezés végső soron arra törekszik, hogy maximalizálja a megfigyelhetőséget azáltal, hogy kibővíti a nyers monitorozási naplókat és metrikákat az alkalmazás állapotának számszerűsítéséhez szükséges kulcsfontosságú üzleti követelményekkel, ami az állapotok automatikus kiértékelését biztosítja a konzisztens és gyorsított műveletek eléréséhez.

Ez a tervezési terület egy robusztus állapotmodell meghatározásának folyamatára összpontosít, amely a megfigyelhetőség és a működési szerkezetek révén megfelelteti a számszerűsített alkalmazásállapotokat a működési érettség elérése érdekében.

Fontos

Ez a cikk az Azure Well-Architected kritikus fontosságú számítási feladatok sorozatának része. Ha nem ismeri ezt a sorozatot, javasoljuk, hogy kezdje a kritikus fontosságú számítási feladatokkal?

A megbízhatóság maximalizálása érdekében a működési érettségnek három fő szintje van.

1. Észlelje és válaszolja meg a problémákat.
2. Diagnosztizálja a felmerült vagy már bekövetkezett problémákat.
3. Előre jelezheti és megelőzheti a problémákat, mielőtt azok sorra kerülnének.

Videó: Állapotmodell definiálása a kritikus fontosságú számítási feladatokhoz

Rétegzett alkalmazás állapota

Állapotmodell létrehozásához először határozza meg az alkalmazás állapotát a kulcsfontosságú üzleti követelmények kontextusában az "kifogástalan" és a "nem kifogástalan" állapotok rétegzett és mérhető formátumban történő számszerűsítésével. Ezután minden alkalmazás-összetevő esetében finomítsa a definíciót egy állandó futási állapot kontextusában, és összesíti az alkalmazás felhasználói folyamatai szerint. A teljesítményre és a rendelkezésre állásra vonatkozó fő nem funkcionális üzleti követelményekkel együtt. Végül összesítse az egyes felhasználói folyamatok állapotállapotait, hogy elfogadható módon ábrázolja az alkalmazás teljes állapotát. A létrehozást követően ezeket a rétegzett állapotdefiníciókat arra kell használni, hogy az összes rendszerösszetevő kritikus monitorozási metrikáit tájékoztassák, és érvényesítsék az operációs alrendszer összetételét.

Fontos

A "nem kifogástalan" állapotok meghatározásakor az alkalmazás minden szintjén meg kell jelölni. Fontos különbséget tenni az átmeneti és a nem átmeneti hibaállapotok között, hogy az elérhetetlenséghez képest minősítse a szolgáltatás romlását.

Kialakítási szempontok

• Az állapot modellezésének folyamata egy felülről lefelé mutató tervezési tevékenység, amely egy architekturális gyakorlattal kezdődik, amely meghatározza az összes felhasználói folyamatot, és leképezi a funkcionális és logikai összetevők közötti függőségeket, így implicit módon megfelelteti az Azure-erőforrások közötti függőségeket.

• Az állapotmodellek teljes mértékben az általa képviselt megoldás környezetétől függenek, ezért nem oldhatók meg "házon kívül", mert "egy méret nem fér el az összeshez".

  • Az alkalmazások összetétele és függőségei eltérőek lesznek
  • Az erőforrások metrikáit és metrikaküszöbeit is finoman kell hangolni annak megfelelően, hogy milyen értékek jelölik az kifogástalan és nem kifogástalan állapotokat, amelyeket az alkalmazás funkciói és a nem funkcionális követelmények nagymértékben befolyásolnak.

• A rétegzett állapotmodell lehetővé teszi az alkalmazásállapot alacsonyabb szintű függőségekre való visszakövetkeztetését, ami segít a szolgáltatás romlásának gyors kiváltó okában.

• Az egyes összetevők állapotállapotainak rögzítéséhez az összetevő különböző működési jellemzőit olyan állandó állapotban kell értelmezni, amely tükrözi az éles terhelést. A teljesítménytesztelés ezért kulcsfontosságú képesség az alkalmazás állapotának meghatározására és folyamatos értékelésére.

• Előfordulhat, hogy a felhőmegoldáson belüli hibák nem elszigetelten fordulnak elő. Egy összetevő kimaradása több képesség vagy további összetevők elérhetetlenné válásához vezethet.

  • Előfordulhat, hogy az ilyen hibák nem lesznek azonnal megfigyelhetők.

Tervezési javaslatok

• Meghatározhat egy mérhető állapotmodellt prioritásként a teljes alkalmazás egyértelmű működési megértésének biztosítása érdekében.

  • Az állapotmodellnek rétegzettnek kell lennie, és tükröznie kell az alkalmazás struktúráját.
  • Az alapvető rétegnek figyelembe kell vennie az egyes alkalmazás-összetevőket, például az Azure-erőforrásokat.
  • Az alapvető összetevőket a fő nem funkcionális követelmények mellett összesíteni kell, hogy az üzleti kontextusba helyezett objektívet a rendszerfolyamatok állapotába építsék.
  • A rendszerfolyamatokat megfelelő súlyokkal kell összesíteni az üzleti kritikusság alapján, hogy az alkalmazás általános állapotának értelmes definícióját lehessen létrehozni. A pénzügyileg jelentős vagy ügyféloldali felhasználói folyamatokat előnyben kell részesíteni.
  • Az állapotmodell minden rétegének rögzítenie kell, hogy mit jelentenek az "kifogástalan" és a "nem kifogástalan" állapotok.
  • Győződjön meg arról, hogy a hőmodell képes megkülönböztetni az átmeneti és a nem átmeneti nem kifogástalan állapotokat, hogy elkülönítse a szolgáltatás romlását az elérhetetlenségtől.

• Az állapotokat az egyes alkalmazásösszetevők részletes állapotpontszámával és minden felhasználói folyamattal ábrázolja a leképezett függő összetevők állapotpontszámainak összesítésével, együtthatóként figyelembe véve a fő nem funkcionális követelményeket.

  • A felhasználói folyamatok állapotpontszámát az összes megfeleltetett összetevő legalacsonyabb pontszámának kell ábrázolnia, figyelembe kell vennie a felhasználói folyamat nem funkcionális követelményeihez viszonyított relatív teljesítményt.
  • Az állapotpontszám kiszámításához használt modellnek konzisztensen tükröznie kell a működési állapotot, és ha nem, akkor a modellt módosítani kell, és újra üzembe kell helyezni az új tanulásoknak megfelelően.
  • Az állapotérték-küszöbértékek definiálása az állapotnak megfelelően.

• Az állapotpontszámot automatikusan ki kell számítani az alapul szolgáló metrikák alapján, amelyek megfigyelhetőségi mintákon keresztül jeleníthetők meg, és automatizált üzemeltetési eljárásokon keresztül kezelhetők.

  • Az állapotpontszámnak alapvetőnek kell lennie a monitorozási megoldásban, így az üzemeltetési csapatoknak már nem kell értelmezniük és leképeznie a működési adatokat az alkalmazás állapotára.

• Az állapotmodell használatával kiszámíthatja a rendelkezésre állási szolgáltatásiszint-célkitűzés (SLO) elérését a nyers rendelkezésre állás helyett, így a szolgáltatás romlása és az elérhetetlenség közötti elhatárolás különálló SLO-kként jelenik meg.

• Használja az állapotmodellt a CI/CD-folyamatokban és a tesztelési ciklusokban annak ellenőrzéséhez, hogy az alkalmazás állapota a kód- és konfigurációfrissítések után is megmarad-e.

  • Az állapotmodellt a CI/CD-folyamatok részeként a terheléstesztelés és a káoszteszt során az állapot megfigyelésére és ellenőrzésére kell használni.

• Az állapotmodell létrehozása és fenntartása iteratív folyamat, és a mérnöki beruházásokat a folyamatos fejlesztésekhez kell igazítani.

  • Definiáljon egy folyamatot, amely folyamatosan kiértékeli és finomhangolja a modell pontosságát, és fontolóra veszi a gépi tanulási modellekbe való befektetést a modell további betanítása érdekében.

Példa – Rétegzett állapotmodell

Ez egy rétegzett alkalmazásállapot-modell egyszerűsített ábrázolása szemléltetés céljából. Az Mission-Critical referenciaimplementációk átfogó és környezetfüggő állapotmodellt biztosítanak:

• Kritikus online
• Kritikus fontosságú csatlakoztatott

Az állapotmodellek implementálásakor fontos az egyes összetevők állapotának meghatározása a fő erőforrásszintű metrikák összesítésével és értelmezésével. Az erőforrásmetrikák felhasználási módjára az alábbi kép mutat példát:

Ezt az állapotdefiníciót később egy KQL-lekérdezés is megjelenítheti, ahogy azt az alábbi példalekérdezés is mutatja, amely összesíti az InsightsMetrics (Container Insights) és az AzureMetrics (AKS-fürt diagnosztikai beállítása) értékét, és összehasonlítja (belső illesztés) a modellezett állapot küszöbértékeit.

// ClusterHealthStatus
let Thresholds=datatable(MetricName: string, YellowThreshold: double, RedThreshold: double) [
    // Disk Usage:
    "used_percent", 50, 80,
    // Average node cpu usage %:
    "node_cpu_usage_percentage", 60, 90,
    // Average node disk usage %:
    "node_disk_usage_percentage", 60, 80,
    // Average node memory usage %:
    "node_memory_rss_percentage", 60, 80
    ];
InsightsMetrics
| summarize arg_max(TimeGenerated, *) by Computer, Name
| project TimeGenerated,Computer, Namespace, MetricName = Name, Value=Val
| extend NodeName = extract("([a-z0-9-]*)(-)([a-z0-9]*)$", 3, Computer)
| union (
    AzureMetrics
    | extend ResourceType = extract("(PROVIDERS/MICROSOFT.)([A-Z]*/[A-Z]*)", 2, ResourceId)
    | where ResourceType == "CONTAINERSERVICE/MANAGEDCLUSTERS"
    | summarize arg_max(TimeGenerated, *) by MetricName
    | project TimeGenerated, MetricName, Namespace = "AzureMetrics", Value=Average
    )
| lookup kind=inner Thresholds on MetricName
| extend IsYellow = iff(Value > YellowThreshold and Value < RedThreshold, 1, 0)
| extend IsRed = iff(Value > RedThreshold, 1, 0)
| project NodeName, MetricName, Value, YellowThreshold, IsYellow, RedThreshold, IsRed

Az eredményül kapott táblakimenet ezután állapotponttá alakítható az állapotmodell magasabb szintjein történő egyszerűbb összesítés érdekében.

// ClusterHealthScore
ClusterHealthStatus
| summarize YellowScore = max(IsYellow), RedScore = max(IsRed)
| extend HealthScore = 1-(YellowScore*0.25)-(RedScore*0.5)

Ezek az összesített pontszámok később függőségi diagramként is megjeleníthetők az állapotmodell szemléltetésére szolgáló vizualizációs eszközökkel, például a Grafanával.

Ez a kép egy, az Azure Mission-Critical online referencia-implementációból származó példaszintű állapotmodellt mutat be, és bemutatja, hogy az alapvető összetevők állapotának változása hogyan hathat kaszkádoltan a felhasználói folyamatokra és az alkalmazás általános állapotára (a példaértékek az előző képen látható táblázatnak felelnek meg).

Bemutató videó: Monitorozás és állapotmodellezés bemutatója

Egyesített adatfogaló korrelált elemzéshez

Számos operatív adatkészletet kell összegyűjteni az összes rendszerösszetevőből, hogy pontosan képviseljen egy meghatározott hőmodellt, figyelembe véve az alkalmazás-összetevőkből és a mögöttes Azure-erőforrásokból származó naplókat és metrikákat. Ezt a hatalmas mennyiségű adatot végső soron olyan formátumban kell tárolni, amely lehetővé teszi a közel valós idejű értelmezést a gyors működés elősegítése érdekében. Emellett az összes adathalmazra kiterjedő korrelációra van szükség a hatékony elemzés kötetlenségének biztosításához, ami lehetővé teszi az állapot rétegzett ábrázolását.

Egységes adatfogalóra van szükség annak biztosításához, hogy az összes operatív adat gyorsan legyen tárolva és elérhetővé téve a korrelált elemzéshez az alkalmazásállapot egyetlen paneles ábrázolásának létrehozásához. Az Azure számos különböző üzemeltetési technológiát biztosít az Azure Monitor égisze alatt, és a Log Analytics-munkaterület szolgál az azure-natív adatok alapvető fogadójaként a működési adatok tárolásához és elemzéséhez.

Kialakítási szempontok

Azure Monitor

• Az Azure Monitor alapértelmezés szerint minden Azure-előfizetéshez engedélyezve van, de az Azure Monitor-naplókat (Log Analytics-munkaterületet) és az Application Insights-erőforrásokat az adatgyűjtési és lekérdezési képességek beépítésére kell üzembe helyezni és konfigurálni.

• Az Azure Monitor háromféle megfigyelhetőségi adatot támogat: naplókat, metrikákat és elosztott nyomkövetéseket.

  • A naplókat a Log Analytics-munkaterületek tárolják, amelyek az Azure Data Explorer alapulnak. A napló lekérdezések olyan lekérdezési csomagokban vannak tárolva, amelyek megoszthatók az előfizetések között, és a megfigyelhető összetevők, például irányítópultok, munkafüzetek vagy más jelentéskészítési és vizualizációs eszközök megvalósításához használhatók.
  • A metrikákat egy belső idősor-adatbázis tárolja. A legtöbb Azure-erőforrás esetében a metrikák gyűjtése és megőrzése 93 napig automatikusan megtörténik. A metrikaadatok a Log Analytics-munkaterületre is elküldhetők az erőforrás diagnosztikai beállításával .

• Minden Azure-erőforrás elérhetővé teszi a naplókat és a metrikákat, de az erőforrásokat megfelelően kell konfigurálni a diagnosztikai adatok a kívánt adatfogyóhoz való irányításához.

Tipp

Az Azure különböző beépített szabályzatokat biztosít, amelyek segítségével biztosítható, hogy az üzembe helyezett erőforrások úgy legyenek konfigurálva, hogy naplókat és metrikákat küldjenek egy Log Analytics-munkaterületre.

• Nem ritka, hogy a szabályozási szabályozások megkövetelik, hogy a működési adatok az eredeti földrajzi helyeken vagy országokban/régiókban maradnak. A szabályozási követelmények hosszabb ideig előírhatják a kritikus adattípusok megőrzését. A szabályozott bankok esetében például a könyvvizsgálati adatokat legalább hét évig meg kell őrizni.

• A különböző működési adattípusok különböző megőrzési időtartamokat igényelhetnek. Előfordulhat például, hogy a biztonsági naplókat hosszú ideig kell megőrizni, míg a teljesítményadatok nem feltétlenül igényelnek hosszú távú megőrzést az AIOps környezetén kívül.

• Az adatok archiválhatók vagy exportálhatók a Log Analytics-munkaterületekről hosszú távú megőrzés és/vagy naplózás céljából.

• A dedikált fürtök olyan üzembe helyezési lehetőséget biztosítanak, amely lehetővé teszi Availability Zones a támogatott Azure-régiók zónaszintű hibáival szembeni védelemhez. A dedikált fürtök minimális napi adatbetöltési kötelezettségvállalást igényelnek.

• A Log Analytics-munkaterületek egy adott Azure-régióban vannak üzembe helyezve.

• A Log Analytics-munkaterületek elérhetetlensége elleni védelem érdekében az erőforrások több diagnosztikai beállítással is konfigurálhatók. Minden diagnosztikai beállítás képes metrikákat és naplókat küldeni egy külön Log Analytics-munkaterületre.

  • Az egyes további Log Analytics-munkaterületek számára küldött adatok többletköltségeket vonnak maga után.
  • A redundáns Log Analytics-munkaterület ugyanabban az Azure-régióban vagy különálló Azure-régiókban helyezhető üzembe további regionális redundancia érdekében.
  • Ha naplókat és metrikákat küld egy Azure-erőforrásból egy másik régióban lévő Log Analytics-munkaterületre, régióközi adatforgalommal jár.
  • Egyes Azure-erőforrásokhoz egy Log Analytics-munkaterületre van szükség ugyanazon a régión belül, mint maga az erőforrás.
  • A Log Analytics-munkaterület további rendelkezésre állási lehetőségeiért tekintse meg az Azure Monitor-naplók ajánlott eljárásait .

• A Log Analytics-munkaterület adatai folyamatos, ütemezett vagy egyszeri módon exportálhatók az Azure Storage-ba vagy Azure Event Hubs.

  • Az adatexportálás lehetővé teszi a hosszú távú adatarchiválást, és védelmet nyújt az elérhetetlenség miatt esetlegesen bekövetkező működési adatvesztésekkel szemben.
  • Az elérhető exportálási célhelyek az Azure Storage vagy Azure Event Hubs. Az Azure Storage különböző redundanciaszintekhez konfigurálható, beleértve a zónaszintű vagy regionális szinteket is. Az Azure Storage-ba irányuló adatexportálás .json-fájlokban tárolja az adatokat.
  • Az adatexportálási célhelyeknek ugyanabban az Azure-régióban kell lenniük, mint a Log Analytics-munkaterület. Az eseményközpont adatexportálási célhelye a Log Analytics-munkaterületével azonos régióban található. Azure Event Hubs georedundáns vészhelyreállítás erre a forgatókönyvre nem alkalmazható.
  • Számos adatexportálási korlátozás van érvényben. Az adatexportáláshoz csak a munkaterület adott táblái támogatottak .
  • Az archiválással az adatok Log Analytics-munkaterületen tárolhatók hosszú távú megőrzés céljából, csökkentett költséggel, exportálás nélkül.

• Az Azure Monitor-naplók felhasználói lekérdezésszabályozási korlátokat tartalmazhatnak, amelyek az ügyfelek számára korlátozott rendelkezésre állásként jelenhetnek meg, például megfigyelhetőségi irányítópultokként.

  • Felhasználónként öt egyidejű lekérdezés: ha öt lekérdezés már fut, a rendszer további lekérdezéseket helyez el egy felhasználónkénti egyidejűségi várólistán, amíg egy futó lekérdezés véget nem ér.
  • Egyidejűségi várólistán töltött idő: ha egy lekérdezés több mint három percig ül az egyidejűségi várólistán, a rendszer leáll, és 429-re vonatkozó hibakódot ad vissza.
  • Egyidejűségi várólista mélységi korlátja: az egyidejűségi üzenetsor legfeljebb 200 lekérdezésre korlátozódik, és a további lekérdezéseket a rendszer 429 hibakóddal elutasítja.
  • Lekérdezési sebességkorlát: felhasználónként 200 lekérdezés 30 másodpercre van korlátozva az összes munkaterületen.

• A lekérdezéscsomagok Azure-Resource Manager-erőforrások, amelyek a napló lekérdezéseinek védelmére és helyreállítására használhatók, ha a Log Analytics-munkaterület nem érhető el.

  • A lekérdezéscsomagok JSON-ként tartalmaznak lekérdezéseket, és az Azure-on kívül is tárolhatók, hasonlóan más infrastruktúra-kódként használt eszközökhöz.
    • Üzembe helyezhető a Microsoft.Insights REST API-val.
    • Ha újra létre kell hozni egy Log Analytics-munkaterületet, a lekérdezési csomag újra üzembe helyezhető egy külsőleg tárolt definícióból.

• Az Application Insights egy munkaterület-alapú üzembehelyezési modellben helyezhető üzembe, amelyet egy Log Analytics-munkaterület támogat, ahol az összes adat tárolása történik.

• A mintavételezés engedélyezhető az Application Insightsban az elküldött telemetriai adatok mennyiségének csökkentése és az adatbetöltési költségek optimalizálása érdekében.

• Az Azure Monitor által gyűjtött összes adat, beleértve az Application Insightst is, a betöltött adatok mennyisége és az adatok megőrzésének időtartama alapján történik .

  • A Log Analytics-munkaterületre betöltött adatok legfeljebb az első 31 napig (a Sentinel engedélyezése esetén 90 napig) díjmentesen megőrizhetők.
  • A munkaterület-alapú Application Insightsba betöltött adatok az első 90 napban díjmentesen megmaradnak.

• A Log Analytics kötelezettségvállalási szint díjszabási modellje alacsonyabb költséget és kiszámítható megközelítést biztosít az adatbetöltési díjakhoz.

  • A foglalási szint feletti használatok számlázása az aktuális szinttel megegyező áron történik.

• A Log Analytics, az Application Insights és az Azure Data Explorer használja a Kusto lekérdezésnyelv (KQL).

• A Log Analytics-lekérdezések függvényként lesznek mentve a Log Analytics-munkaterületen (savedSearches).

Tervezési javaslatok

• A Log Analytics-munkaterületet egyesített adatgyűjtőként használva minden operatív adatkészletben egyetlen panelt biztosíthat.

  • A Log Analytics-munkaterületek decentralizáltsá alakítása az összes használt üzembehelyezési régióban. Minden alkalmazástelepítéssel rendelkező Azure-régiónak figyelembe kell vennie egy Log Analytics-munkaterületet, hogy összegyűjtse az adott régióból származó összes működési adatot. Minden globális erőforrásnak külön dedikált Log Analytics-munkaterületet kell használnia, amelyet egy elsődleges üzembehelyezési régióban kell üzembe helyezni.
    • Az összes működési adat egyetlen Log Analytics-munkaterületre való elküldése egyetlen hibapontot eredményezne.
    • Az adattárolási követelmények tilthatják az adatokat a kiinduló régióból, és az összevont munkaterületek alapértelmezés szerint megoldják ezt a követelményt.
    • A naplók és metrikák régiók közötti átviteléhez jelentős kimenő költségek társulnak.
  • Az ugyanazon a régión belüli üzembehelyezési bélyegek ugyanazt a regionális Log Analytics-munkaterületet használhatják.

• Érdemes lehet több diagnosztikai beállítással rendelkező erőforrásokat konfigurálni, amelyek különböző Log Analytics-munkaterületekre mutatnak, hogy megvédjék az Azure Monitor elérhetetlenségét a kevesebb regionális üzembehelyezési bélyeggel rendelkező alkalmazások esetében.

• Az Application Insights egységes alkalmazásteljesítmény-monitorozási (APM-) eszközként használható az összes alkalmazásösszetevőben az alkalmazásnaplók, metrikák és nyomkövetések gyűjtéséhez.

  • Az Application Insights üzembe helyezése munkaterület-alapú konfigurációban annak biztosítása érdekében, hogy minden regionális Log Analytics-munkaterület tartalmazza az alkalmazás összetevőiből és a mögöttes Azure-erőforrásokból származó naplókat és metrikákat.

• Munkaterületek közötti lekérdezések használatával egységes "egyetlen ablaktáblát" tarthat fenn a különböző munkaterületeken.

• Lekérdezéscsomagok használatával védheti a napló lekérdezéseit, ha a munkaterület elérhetetlenné válik.

  • A lekérdezéscsomagokat az alkalmazás git-adattárában tárolja infrastruktúra-kódként.

• Minden Log Analytics-munkaterületet olyan hosszú ideig futó erőforrásként kell kezelni, amelyek életciklusa eltér az alkalmazáserőforrásoktól egy regionális üzembehelyezési bélyegen belül.

• Exportálja a kritikus fontosságú operatív adatokat a Log Analytics-munkaterületről a hosszú távú megőrzés és elemzés érdekében, hogy megkönnyítse az AIOps és a speciális elemzések elvégzését az alapul szolgáló állapotmodell finomítása és a prediktív műveletek tájékoztatása érdekében.

• Gondosan értékelje ki, hogy melyik adattárat kell használni a hosszú távú megőrzéshez; nem minden adatot kell tárolni egy gyakori elérésű és lekérdezhető adattárban.

  • Erősen ajánlott az Azure Storage használata GRS-konfigurációban a hosszú távú operatív adattároláshoz.
    • A Log Analytics-munkaterület exportálási funkciójának használatával exportálhatja az összes elérhető adatforrást az Azure Storage-ba.

• Válassza ki a megfelelő megőrzési időtartamokat a log analyticsen belüli operatív adattípusokhoz, és konfigurálja a hosszabb megőrzési időtartamokat azon a munkaterületen, ahol a "gyakori" megfigyelhetőségi követelmények léteznek.

• A Azure Policy használatával győződjön meg arról, hogy minden regionális erőforrás a megfelelő Log Analytics-munkaterületre irányítja a működési adatokat.

Megjegyzés

Az Azure-beli célzónába való üzembe helyezéskor, ha az operatív adatok központosított tárolására van szükség, a példányosításkor elágaztathatja az adatokat, így azokat a központi eszközökbe és az alkalmazáshoz dedikált Log Analytics-munkaterületekre is betöltheti. Másik lehetőségként elérhetővé teheti az alkalmazás Log Analytics-munkaterületekhez való hozzáférést, hogy a központi csapatok lekérdezhessék az alkalmazásadatokat. Végső soron kritikus fontosságú, hogy a megoldásból származó operatív adatok elérhetők az alkalmazásnak dedikált Log Analytics-munkaterületeken.

Ha SIEM-integrációra van szükség, ne küldjön nyers naplóbejegyzéseket, hanem küldjön kritikus riasztásokat.

• Csak akkor konfigurálja a mintavételezést az Application Insightsban, ha a teljesítmény optimalizálásához szükséges, vagy ha nem, a mintavételezés költsége tiltóvá válik.

  • A túlzott mintavételezés téves vagy pontatlan működési jelekhez vezethet.

• Használjon korrelációs azonosítókat az összes nyomkövetési eseményhez és naplóüzenethez, hogy összekapcsolja őket egy adott kéréssel.

  • Korrelációs azonosítókat ad vissza a hívónak az összes híváshoz, nem csak a sikertelen kérésekhez.

• Győződjön meg arról, hogy az alkalmazáskód megfelelő kialakítást és naplózást tartalmaz, hogy tájékoztassa az állapotmodellt, és szükség esetén megkönnyítse az ezt követő hibaelhárítást vagy a kiváltó okok elemzését.

  • Az alkalmazáskódnak az Application Insights használatával kell megkönnyítenie az elosztott nyomkövetést azáltal, hogy egy átfogó hibaüzenetet ad a hívónak, amely tartalmaz egy korrelációs azonosítót meghibásodás esetén.

• Strukturált naplózás használata az összes naplóüzenethez.

• Adjon hozzá értelmes állapotteszteket az összes alkalmazásösszetevőhöz.

  • Az AKS használatakor konfigurálja az egyes üzemelő példányok (podok) állapotvégpontjait, hogy a Kubernetes helyesen tudja meghatározni, hogy a pod kifogástalan vagy nem kifogástalan állapotú-e.
  • A Azure App Service használatakor úgy konfigurálja az Állapot-ellenőrzéseket, hogy a vertikális felskálázási műveletek ne okozzanak hibákat, ha a még nem kész példányokra küldi a forgalmat, és gondoskodik arról, hogy a nem kifogástalan állapotú példányok gyorsan újrafeldolgozhatók legyenek.

Ha az alkalmazás előfizetett a Microsoft Mission-Critical-támogatásra, fontolja meg a kulcsállapot-mintavételek Microsoft ügyfélszolgálata való felfedését, hogy az alkalmazás állapota pontosabban modellezhető legyen Microsoft ügyfélszolgálata.

• Naplózza a sikeres állapot-ellenőrzési kéréseket, hacsak a megnövekedett adatmennyiségek nem tolerálhatók az alkalmazás teljesítményének kontextusában, mivel további elemzési megállapításokat nyújtanak az elemzési modellezéshez.

• Ne konfigurálja az éles Log Analytics-munkaterületeket napi korlát alkalmazására, ami korlátozza a működési adatok napi betöltését, mivel ez kritikus működési adatok elvesztéséhez vezethet.

  • Alacsonyabb környezetekben, például a fejlesztésben és a tesztelésben a napi korlát választható költségmegtakarítási mechanizmusnak tekinthető.

• Feltéve, hogy a működési adatok betöltési kötetei megfelelnek a minimális szint küszöbértékének, konfigurálja a Log Analytics-munkaterületeket úgy, hogy a kötelezettségvállalási szintalapú díjszabást használják a költséghatékonyságok eléréséhez a használatalapú fizetéses díjszabási modellhez képest.

• Erősen ajánlott a Log Analytics-lekérdezéseket forrásvezérléssel tárolni, és CI/CD automation használatával üzembe helyezni őket a releváns Log Analytics-munkaterületpéldányokon.

Vizualizáció

Az állapotmodell kritikus működési adatokkal való vizuális ábrázolása elengedhetetlen a hatékony műveletek eléréséhez és a megbízhatóság maximalizálásához. Az irányítópultokat végső soron úgy kell használni, hogy közel valós idejű elemzéseket nyújtsanak az alkalmazás állapotáról a DevOps-csapatok számára, megkönnyítve az állandó állapottól való eltérések gyors diagnosztizálását.

A Microsoft számos adatvizualizációs technológiát kínál, köztük az Azure Irányítópultokat, a Power BI-t és az Azure Managed Grafana -t (jelenleg előzetes verzióban). Az Azure Dashboards úgy van elhelyezve, hogy szorosan integrált, beépített vizualizációs megoldást biztosítson az Azure Monitoron belüli operatív adatokhoz. Ezért alapvető szerepet játszik a műveleti adatok és az alkalmazásállapot vizuális ábrázolásában egy kritikus fontosságú számítási feladat esetében. Az Azure-irányítópultok holisztikus megfigyelhetőségi platformként való elhelyezése azonban több korlátozást is magában foglal, ezért figyelembe kell venni a piacvezető megfigyelhetőségi megoldások, például a Grafana kiegészítő használatát, amely az Azure-ban felügyelt megoldásként is elérhető.

Ez a szakasz az Azure-irányítópultok és a Grafana használatával olyan robusztus irányítópult-kezelő felületet hoz létre, amely képes műszaki és üzleti objektíveket biztosítani az alkalmazás állapotához, lehetővé téve a DevOps-csapatokat és a hatékony működést. A robusztus irányítópultok elengedhetetlenek a már bekövetkezett problémák diagnosztizálásához, és támogatják az operatív csapatokat a problémák észlelésében és megválaszolásában.

Kialakítási szempontok

• Az állapotmodell napló lekérdezésekkel való megjelenítésekor vegye figyelembe, hogy az egyidejű és várólistás lekérdezésekre, valamint az általános lekérdezési arányra vonatkozó Log Analytics-korlátozások vannak érvényben, és az ezt követő lekérdezések várólistára kerülnek és szabályozva vannak.

• Az állapotpontértékek kiszámításához és megjelenítéséhez használt működési adatok lekérésére szolgáló lekérdezések a Log Analyticsben vagy az Azure Data Explorer-ben írhatók és hajthatók végre.

  • A mintalekérdezések itt érhetők el.

• A Log Analytics számos lekérdezési korlátot ír elő, amelyeket az operatív irányítópultok tervezésekor kell megtervezni.

• A nyers erőforrás-metrikák, például a processzorhasználat vagy a hálózati átviteli sebesség vizualizációja manuális kiértékelést igényel az üzemeltetési csapatoktól az állapotra gyakorolt hatások meghatározásához, és ez kihívást jelenthet egy aktív incidens során.

• Ha több felhasználó használ irányítópultokat egy olyan eszközben, mint a Grafana, a Log Analyticsnek küldött lekérdezések száma gyorsan megsokszorozódik.

  • Ha eléri az egyidejű lekérdezési korlátot a Log Analyticsben, a további lekérdezések várólistára kerülnek, így az irányítópult felülete "lassúnak" tűnik.

Tervezési javaslatok

• Gyűjtse össze és mutassa be az összes regionális Log Analytics-munkaterület és a globális Log Analytics-munkaterület lekérdezett kimeneteit az alkalmazásállapot egységes nézetének létrehozásához.

Megjegyzés

Ha azure-beli célzónába helyez üzembe, fontolja meg a központi platform Log Analytics-munkaterületének lekérdezését, ha a platformerőforrásoktól vannak fő függőségek, például az ExpressRoute a helyszíni kommunikációhoz.

• A "közlekedési lámpa" modellel vizuálisan meg kell jelölni az "egészséges" és a "nem kifogástalan" állapotokat, zöld színnel, amely azt szemlélteti, hogy a legfontosabb nem funkcionális követelmények teljes mértékben teljesülnek, és az erőforrások optimálisan vannak kihasználva. A "Zöld", az "Amber és a Red" kifejezéssel jelölheti az "Egészséges", a "Degraded" és a "Nem érhető el" állapotokat.

• Az Azure-irányítópultok használatával működési objektíveket hozhat létre a globális erőforrásokhoz és a regionális üzembehelyezési bélyegekhez, amelyek olyan kulcsfontosságú metrikákat képviselnek, mint az Azure Front Door kéréseinek száma, az Azure Cosmos DB kiszolgálóoldali késése, az Event Hubs bejövő/kimenő üzenetei, valamint az AKS cpu-kihasználtsága vagy üzembehelyezési állapota. Az irányítópultokat a működési hatékonyság növelése érdekében kell testre szabni, és be kell vezetni a meghibásodási forgatókönyvekből származó tanulságokat annak érdekében, hogy a DevOps-csapatok közvetlenül átláthassák a főbb metrikákat.

• Ha az Azure-irányítópultok nem használhatók az állapotmodell és a szükséges üzleti követelmények pontos ábrázolására, akkor erősen ajánlott alternatív vizualizációs megoldásként tekinteni a Grafana-ra, amely piacvezető képességeket és kiterjedt nyílt forráskódú beépülő modul-ökoszisztémát biztosít. Értékelje ki a felügyelt Grafana előzetes verziós ajánlatát, hogy elkerülje a Grafana-infrastruktúra kezelésének működési összetettségét.

• A saját üzemeltetésű Grafana üzembe helyezésekor magas rendelkezésre állású és földrajzilag elosztott kialakítást használjon, hogy a kritikus fontosságú operatív irányítópultok rugalmasak legyenek a regionális platformhibákkal és kaszkádolt hibaforgatókönyvekkel szemben.

  • A konfigurációs állapotot különítse el egy külső adattárban, például az Azure Database for Postgresben vagy a MySQL-ben, hogy a Grafana-alkalmazáscsomópontok állapot nélküliek maradjanak.

    • Adatbázis-replikáció konfigurálása üzembehelyezési régiók között.

  • Helyezzen üzembe Grafana-csomópontokat az App Servicesben egy magas rendelkezésre állású konfigurációban egy régión belül, tárolóalapú üzemelő példányok használatával.

    • Helyezzen üzembe App Service példányokat a figyelembe vett üzembehelyezési régiókban.

    Az App Services alacsony súrlódású tárolóplatformot biztosít, amely ideális az olyan alacsony léptékű forgatókönyvekhez, mint az operatív irányítópultok, és a Grafana AKS-ből való elkülönítése egyértelműen elkülöníti az elsődleges alkalmazásplatformot és az adott platform működési reprezentációit. További konfigurációs javaslatokért tekintse meg az Alkalmazásplatform deign területét.

  • Az Azure Storage használata GRS-konfigurációban egyéni vizualizációk és beépülő modulok üzemeltetéséhez és kezeléséhez.

  • App Service- és adatbázis-olvasási replika Grafana-összetevők üzembe helyezése legalább két üzembehelyezési régióban, és fontolja meg egy olyan modell alkalmazását, amelyben a Grafana az összes üzembe helyezési régióban üzembe van helyezve.

A 99,99%-os SLO-t megcélzó >forgatókönyvek esetében a Grafanát legalább 3 üzembehelyezési régióban kell üzembe helyezni, hogy a lehető legnagyobb megbízhatóságot biztosíthassa a kulcsfontosságú operatív irányítópultok esetében.

• Csökkentse a Log Analytics lekérdezési korlátait úgy, hogy a lekérdezéseket egyetlen vagy kis számú lekérdezésbe összesíti, például a KQL "union" operátor használatával, és beállítja a megfelelő frissítési sebességet az irányítópulton.

  • A megfelelő maximális frissítési arány az irányítópult-lekérdezések számától és összetettségétől függ; a végrehajtott lekérdezések elemzése szükséges.

• Ha eléri a Log Analytics egyidejű lekérdezési korlátját, fontolja meg a lekérési minta optimalizálását úgy, hogy (ideiglenesen) az irányítópulthoz szükséges adatokat egy nagy teljesítményű adattárban, például Azure SQL tárolja.

Automatizált incidenskezelés

Bár az alkalmazás állapotának vizuális ábrázolása felbecsülhetetlen értékű működési és üzleti elemzéseket biztosít a problémák észlelésének és diagnosztizálásának támogatásához, az operatív csapatok felkészültségére és értelmezésére, valamint az ezt követő, ember által aktivált válaszok hatékonyságára támaszkodik. Ezért a megbízhatóság maximalizálása érdekében átfogó riasztásokat kell implementálni a proaktív észlelés és a problémák közel valós idejű megválaszolása érdekében.

Az Azure Monitor egy átfogó riasztási keretrendszert biztosít az operatív jelek észleléséhez, kategorizálásához és a műveleti jelekre való reagáláshoz műveletcsoportokon keresztül. Ez a szakasz ezért az Azure Monitor-riasztások használatával hajtja végre az automatizált műveleteket az alkalmazás állapotától való aktuális vagy lehetséges eltérésekre reagálva.

Fontos

A riasztások és az automatizált műveletek kritikus fontosságúak ahhoz, hogy hatékonyan észleljék és gyorsan reagáljanak a problémákra, mielőtt nagyobb negatív hatás következne be. A riasztás egy mechanizmust is biztosít a bejövő jelek értelmezésére és a problémák megelőzésére azok bekövetkezése előtt.

Kialakítási szempontok

• A riasztási szabályok akkor aktiválódnak, ha teljesülnek a bejövő jelekre vonatkozó feltételes feltételek, amelyek különböző adatforrásokat, például metrikákat, napló lekérdezéseket vagy rendelkezésreállási teszteket tartalmazhatnak.

• A riasztások definiálhatók a Log Analyticsben vagy az Azure Monitorban az adott erőforráson.

• Egyes metrikák csak az Azure Monitoron belül kérdezhetők le, mivel nem minden diagnosztikai adatpont érhető el a Log Analyticsben.

• Az Azure Monitor Alerts API használható az aktív és az előzményalapú riasztások lekérésére.

• A riasztásokhoz és a műveletcsoportokhoz kapcsolódó előfizetési korlátokat a következő célokra kell tervezni:

  • A konfigurálható riasztási szabályok száma korlátozott.
  • A Alerts API szabályozási korlátozásokkal rendelkezik, amelyeket figyelembe kell venni szélsőséges használati forgatókönyvek esetén.
  • A műveletcsoportoknak számos korlátozásuk van a konfigurálható válaszok számára, amelyeket meg kell tervezni.
    • Minden választípus legfeljebb 10 műveletből áll, az e-mailen kívül, amely 1000 műveletből áll.

• A riasztások integrálhatók egy rétegzett állapotmodellbe, ha létrehoznak egy riasztási szabályt a modell "gyökér" pontozófüggvényéből mentett naplókeresési lekérdezéshez. Például a "WebsiteHealthScore" használata és a riasztás egy "Nem kifogástalan" állapotot képviselő numerikus értéken.

Tervezési javaslatok

• Erőforrás-központú riasztások esetén hozzon létre riasztási szabályokat az Azure Monitoron belül, hogy minden diagnosztikai adat elérhető legyen a riasztási szabály feltételeihez.

• Az automatizált műveletek összevonása minimális számú műveletcsoporton belül, a szolgáltatáscsapatokkal összhangban a DevOps-megközelítés támogatásához.

• Reagálhat a túlzott erőforrás-kihasználtságra az automatizált skálázási műveleteken keresztül, ahol lehetséges, az Azure natív automatikus skálázási képességeinek használatával. Ha a beépített automatikus skálázási funkció nem alkalmazható, az összetevő állapotpontszámával modellezheti a jeleket, és meghatározhatja, hogy mikor kell automatikus skálázási műveletekkel reagálni. Győződjön meg arról, hogy az automatizált skálázási műveletek kapacitásmodell szerint vannak definiálva, amely számszerűsíti az összetevők közötti skálázási kapcsolatokat, így a skálázási válaszok olyan összetevőket is magukban foglalnak, amelyeket más összetevőkhöz képest kell skálázni.

• Modellműveletek a rangsoroláshoz, amelyet az üzleti hatásnak kell meghatároznia.

• Az Azure Monitor Alerts API-val előzményalapú riasztásokat gyűjthet, amelyek a "ritka" működésű tárolóba ágyazva speciális elemzéseket biztosítanak.

• A kritikus meghibásodási forgatókönyvek esetében, amelyek nem teljesíthetők automatikus válaszokkal, győződjön meg arról, hogy a működési "runbook-automatizálás" a helyén van a gyors és konzisztens művelet érdekében, miután a manuális értelmezés és kijelentkezés biztosított. Riasztási értesítések használata a manuális értelmezést igénylő problémák gyors azonosításához

• Hozzon létre kibocsátási egységeket a mérnöki futamokban, hogy a riasztások növekményes javulását eredményezhesse, hogy a korábban nem tekintett új meghibásodási forgatókönyvek teljes mértékben elférjenek az új automatizált műveletekben.

• A CI/CD-folyamatok részeként működési készültségi teszteket végezhet az üzembehelyezési frissítések fő riasztási szabályainak ellenőrzéséhez.

Prediktív művelet és AI-műveletek (AIOps)

A gépi tanulási modellek alkalmazhatók a működési adatok korrelációjához és rangsorolásához, segítve a túlzott riasztások "zajának" szűrésével és a problémák előrejelzésével kapcsolatos kritikus megállapítások gyűjtését, mielőtt azok hatással lennének, valamint felgyorsítják az incidensekre adott reagálást.

Pontosabban egy AIOps-módszertan alkalmazható a rendszer, a felhasználók és a DevOps-folyamatok viselkedésével kapcsolatos kritikus megállapításokra. Ezek az elemzések magukban foglalhatják a jelenleg előforduló probléma azonosítását (észlelését), a probléma okának számszerűsítését (diagnosztizálását), vagy a jövőbeli események jelzését (előrejelzés). Ezek az elemzések olyan műveletek ösztönzésére használhatók, amelyek az aktív vagy potenciális problémák kezeléséhez igazítják és optimalizálják az alkalmazást, a fő üzleti metrikák, a rendszerminőségi metrikák és a DevOps hatékonysági metrikáinak használatával az üzleti hatásnak megfelelően rangsorolhatók. A végrehajtott műveletek maguk is bejuttathatók a rendszerbe egy visszajelzési hurokon keresztül, amely tovább tanítja a mögöttes modellt, hogy további hatékonyságot teremtsen.

Az Azure-ban több elemzési technológia is létezik, például a Azure Synapse és az Azure Databricks, amelyekkel elemzési modellek hozhatók létre és taníthatók be az AIOpshoz. Ez a szakasz ezért arra összpontosít, hogy ezek a technológiák hogyan helyezhetők el az alkalmazástervezésben az AIOps és a prediktív működés hajtóerője érdekében, és a Azure Synapse összpontosítva, amelyek csökkentik a súrlódást azáltal, hogy az Azure adatszolgáltatásai közül a legjobbat egyesítik a hatékony új funkciókkal.

Az AIOps a prediktív cselekvés ösztönzésére, a tartós időszakban megfigyelt összetett műveleti jelek értelmezésére és korrelálására szolgál, hogy jobban reagáljon a problémákra, és megelőzze azok előfordulását.

Kialakítási szempontok

• Azure Synapse Analytics több Machine Learning- (ML-) képességet kínál.

  • Az ML-modellek betaníthatók és futtathatók a Synapse Spark-készletekben olyan kódtárakkal, mint az MLLib, a SparkML és az MMLSpark, valamint a népszerű nyílt forráskódú kódtárak, például a Scikit Learn.
  • Az ML-modellek olyan gyakori adatelemzési eszközökkel taníthatók be, mint a PySpark/Python, a Scala vagy a .NET.

• A Synapse Analytics integrálva van az Azure ML-vel Azure Synapse Notebooks használatával, amely lehetővé teszi az ML-modellek betanítása egy Azure ML-munkaterületen az automatizált gépi tanulás használatával.

• A Synapse Analytics az Azure Cognitive Servicest használó gépi tanulási képességeket is lehetővé teszi a különböző tartományok általános problémáinak, például az Anomáliadetektálásnak a megoldásához. A Cognitive Services Azure Synapse, az Azure Databricksben, valamint ügyfélalkalmazásokban SDK-k és REST API-k használatával használható.

• Azure Synapse natív módon integrálható Azure Data Factory eszközökkel az adatok vezénylési folyamatokban való kinyerésére, átalakítására és betöltésére (ETL) vagy betöltésére.

• Azure Synapse engedélyezi a külső adathalmaz-regisztrációt az Azure Blob Storage-ban vagy Azure Data Lake Storage tárolt adatokhoz.

  • A regisztrált adathalmazok a Synapse Spark-készlet adatelemzési feladataiban használhatók.

• Az Azure Databricks további Spark-képességek érdekében integrálható Azure Synapse Analytics-folyamatokba.

  • A Synapse vezényli az adatok olvasását és egy Databricks-fürtbe való elküldését, ahol átalakíthatók és előkészíthetők az ML-modell betanítására.

• A forrásadatokat általában elő kell készíteni elemzésre és gépi tanulásra.

  • A Synapse különböző eszközöket kínál az adatok előkészítéséhez, beleértve az Apache Sparkot, a Synapse Notebookokat és a kiszolgáló nélküli SQL-készleteket T-SQL-lel és beépített vizualizációkkal.

• A betanított, üzembe helyezett és üzembe helyezett ML-modellek kötegelt pontozáshoz használhatók a Synapse-ban.

  • Az AIOps-forgatókönyvek, például a regressziós vagy a teljesítménycsökkenési előrejelzések futtatása a CI/ CD-folyamatokban valós idejű pontozást igényelhetnek.

• A Azure Synapse előfizetési korlátai vannak, amelyeket teljes mértékben meg kell érteni az AIOps-módszertan kontextusában.

• Az AIOps teljes körű beépítéséhez közel valós idejű megfigyelhetőségi adatokat kell folyamatosan valós idejű ML-következtetési modellekbe táplálni.

  • Az olyan képességeket, mint az anomáliadetektálás, a megfigyelhetőségi adatfolyamon belül kell kiértékelni.

Tervezési javaslatok

• Győződjön meg arról, hogy az összes Azure-erőforrás és alkalmazásösszetevő teljes mértékben ki van alakítva, hogy az AIOps-modellek betanításához rendelkezésre álljon egy teljes operatív adatkészlet.

• A Log Analytics működési adatainak betöltése a globális és regionális Azure Storage-fiókokból Azure Synapse elemzés céljából.

• Az Azure Monitor Alerts API használatával lekérheti az előzményalapú riasztásokat, és tárolhatja azokat a ritka elérésű tárolóban, hogy a működési adatok később az ML-modellekben is felhasználhatók lesznek. Ha Log Analytics-adatexportálást használ, a korábbi riasztások adatait ugyanabban az Azure Storage-fiókban tárolja, mint az exportált Log Analytics-adatokat.

• Miután előkészítette az adatokat az ml-betanításhoz, írja vissza az Azure Storage-ba, hogy az elérhető legyen az ML-modell betanításához anélkül, hogy a Synapse-adatok előkészítéséhez számítási erőforrásokat kellene futtatnia.

• Győződjön meg arról, hogy az ML-modell üzembe helyezésével a kötegelt és a valós idejű pontozás is támogatott.

• Az AIOps-modellek létrehozásakor implementálja az MLOps-t, és DevOps-eljárásokat alkalmaz a gépi tanulási életciklus automatizálásához a betanítás, az üzembe helyezés, a pontozás és a folyamatos fejlesztés érdekében. Iteratív CI/CD-folyamat létrehozása AIOps ML-modellekhez.

• Értékelje ki az Azure Cognitive Servicest az alacsony adminisztrációs és integrációs többletterhelés miatt meghatározott prediktív forgatókönyvekhez. Az Anomáliadetektálás funkcióval gyorsan megjelölheti a megfigyelhető adatstreamek váratlan eltéréseit.

Következő lépés

Tekintse át az üzembe helyezéssel és teszteléssel kapcsolatos szempontokat.

Üzembe helyezés és tesztelés