Javaslatok monitorozási rendszer tervezéséhez és létrehozásához

Az Azure Well-Architected Framework működési kiválósági ellenőrzőlistájára vonatkozó javaslatra vonatkozik:

OE:07	Tervezzen és implementáljon egy monitorozási rendszert, amely érvényesíti a tervezési döntéseket, és tájékoztatja a jövőbeli tervezési és üzleti döntéseket. Ez a rendszer rögzíti és elérhetővé teszi a számítási feladat infrastruktúrájából és kódjából származó operatív telemetriát, metrikákat és naplókat.

Kapcsolódó útmutató: Javaslatok alkalmazás kialakításához

Ez az útmutató a figyelési rendszerek tervezésére és létrehozására vonatkozó javaslatokat ismerteti. Ahhoz, hogy hatékonyan monitorozza a számítási feladatokat a biztonság, a teljesítmény és a megbízhatóság szempontjából, szüksége van egy olyan átfogó rendszerre, amely saját vermével biztosítja az összes figyelési, észlelési és riasztási funkció alapját.

Definíciók

Időszak	Definíció
Naplók	Rendszeresemények rögzítése. A naplók különböző típusú adatokat tartalmazhatnak strukturált vagy szabad formátumú szöveges formátumban. Időbélyeget tartalmaznak.
Mérőszámok	Rendszeres időközönként gyűjtött numerikus értékek. A metrikák a rendszer bizonyos aspektusait írják le egy adott időpontban.

Kulcsfontosságú tervezési stratégiák

A számítási feladatok átfogó monitorozási rendszerének kialakításához kövesse az alábbi alapvető feltételeket:

• Amikor gyakorlatias, használja ki a platform által biztosított monitorozási eszközöket, amelyek általában nagyon kevés konfigurációt igényelnek, és mély betekintést nyújtanak a számítási feladatokba, amelyek egyébként nehezen valósíthatók meg.

• Naplókat és metrikákat gyűjthet a teljes számításifeladat-veremből. Minden infrastruktúra-erőforrást és alkalmazásfüggvényt szabványos, jelentéssel bíró adatok előállítására kell konfigurálni, és ezeket az adatokat össze kell gyűjteni.

• Az összegyűjtött adatokat egy szabványosított, megbízható és biztonságos tárolási megoldásban tárolhatja.

• Feldolgozhatja a tárolt adatokat, hogy azok elemzési és vizualizációs megoldásokkal kezelhetők legyenek.

• Elemezze a feldolgozott adatokat a számítási feladat állapotának pontos meghatározásához.

• A számítási feladat állapotának megjelenítése jelentéssel bíró irányítópultokon vagy jelentésekben a számítási feladatokért felelős csapatok és más érdekelt felek számára.

• Konfigurálhat végrehajtható riasztásokat és más automatikus válaszokat az intelligensen definiált küszöbértékekre, hogy a számítási feladatokért foglalkozó csapatok értesítést küldhessenek a problémák felmerüléséről.

• A figyelési és riasztási rendszerek belefoglalása az általános számítási feladatok tesztelési gyakorlataiba.

• Győződjön meg arról, hogy a monitorozási és riasztási rendszerek a folyamatos fejlesztés hatókörébe tartoznak. Az alkalmazások és az infrastruktúra éles környezetben való viselkedése folyamatos tanulási lehetőségeket biztosít. Ezeket a tanulságokat beépíti a figyelési és riasztási tervekbe.

• Kösse össze az összegyűjtött és elemezni kívánt monitorozási adatokat a rendszerhez és a felhasználói folyamatokhoz , hogy a számítási feladat általános állapota mellett korrelálja a folyamatok állapotát az adatokkal. Az adatok folyamatok szempontjából történő elemzése segít összehangolni a megfigyelhetőségi stratégiát az állapotmodellel.

A monitorozási rendszer minden funkcióját a lehető legnagyobb mértékben automatizálnia kell, és mindegyiknek folyamatosan, egész nap, minden nap futnia kell.

Ez a munkafolyamat-folyamat a figyelési rendszert mutatja be:

Gyűjtemény

Megjegyzés

A naplózás engedélyezéséhez eszközre kell állítania az alkalmazást. További információkért tekintse meg a kialakítási útmutatót.

A telemetriai adatok és/vagy események, például naplók és metrikák rögzítéséhez konfigurálnia kell az összes számításifeladat-összetevőt, legyen szó infrastruktúra-erőforrásokról vagy alkalmazásfüggvényekről.

A naplók elsősorban az anomáliák észleléséhez és vizsgálatához hasznosak. A naplókat általában a számítási feladat összetevő hozza létre, majd elküldi a figyelési platformnak, vagy a monitorozási platform az automatizáláson keresztül kéri le.

A metrikák elsősorban egy állapotmodell létrehozásához és a számítási feladatok teljesítményével és megbízhatóságával kapcsolatos trendek azonosításához hasznosak. A metrikák az ügyfelek használati viselkedésének trendjeinek azonosítására is hasznosak. Ezek a trendek segíthetnek az ügyfelek szempontjából a fejlesztésekkel kapcsolatos döntések meghozatalában. A metrikák általában a monitorozási platformon vannak definiálva, a monitorozási platform és más eszközök pedig lekérdezik a számítási feladatot a metrikák rögzítéséhez.

Alkalmazásadatok

Az alkalmazások esetében a gyűjtőszolgáltatás lehet egy alkalmazásteljesítmény-kezelő (APM) eszköz, amely önállóan futtatható a rendszerállapot-adatokat létrehozó alkalmazásból. Az APM engedélyezése után egyértelmű betekintést nyújt a fontos metrikákba valós időben és előzményként. Használjon megfelelő naplózási szintet. A részletes naplózás jelentős költségekkel jár. Állítsa be a naplószinteket a környezetnek megfelelően. Az alacsonyabb környezetekhez például nincs szükség az éles környezettel azonos részletességi szintre.

Az alkalmazásnaplók támogatják az alkalmazások teljes életciklusát. A naplózás alapvető fontosságú annak megértéséhez, hogy az alkalmazás hogyan működik különböző környezetekben, milyen események történnek, és milyen feltételek mellett történnek.

Javasoljuk, hogy gyűjtse össze az alkalmazásnaplókat és az eseményeket az összes nagyobb környezetben. A környezetek közötti adatelválasztókat a lehető legnagyobb mértékben különítse el az egyes környezetek különböző adattárainak használatával, ha ez gyakorlatias. Szűrők használatával győződjön meg arról, hogy a nem kritikus környezetek nem bonyolítják az éles naplók értelmezését. Végül az alkalmazás megfelelő naplóbejegyzéseinek rögzíteniük kell a megfelelő tranzakciók korrelációs azonosítóját.

Az alkalmazáseseményeket strukturált adattípusokban, géppel olvasható adatpontokkal kell rögzíteni a strukturálatlan sztringtípusok helyett. Egy jól ismert sémát használó strukturált formátum megkönnyítheti a naplók elemzését és elemzését. Emellett a strukturált adatok egyszerűen indexelhetők és kereshetők, és a jelentéskészítés jelentősen leegyszerűsíthető.

Az adatoknak a gép, az operációs rendszer vagy a hálózati protokolltól független, agnosztikus formátumban kell lenniük. Például az ETL/ETW helyett önleíró formátumban, például JSON, MessagePack vagy Protobuf formátumban bocsáthat ki információkat. A szabványos formátum lehetővé teszi, hogy a rendszer feldolgozási folyamatokat hozzon létre. A szabványos formátumban adatokat olvasó, átalakító és küldő összetevők könnyen integrálhatók.

Infrastruktúraadatok

A számítási feladatban található infrastruktúra-erőforrások esetében győződjön meg arról, hogy naplókat és metrikákat is gyűjt. Szolgáltatott infrastruktúra (IaaS) rendszerek esetén rögzítse az operációs rendszert, az alkalmazásréteget és a diagnosztikai naplókat a számítási feladatok állapotával kapcsolatos metrikák mellett. A szolgáltatásként nyújtott platform (PaaS) erőforrásai esetében előfordulhat, hogy korlátozottan képes rögzíteni az alapul szolgáló infrastruktúrához kapcsolódó naplókat, de győződjön meg arról, hogy a számítási feladatok állapotával kapcsolatos metrikák mellett diagnosztikai naplókat is rögzíthet.

A lehető legnagyobb mértékben gyűjtsön naplókat a felhőplatformról. Előfordulhat, hogy képes lesz tevékenységnaplókat gyűjteni az előfizetéshez és a diagnosztikai naplókhoz a felügyeleti síkon.

Gyűjtési stratégiák

Kerülje a telemetriai adatok manuális beolvasását minden összetevőből. Helyezze át az adatokat egy központi helyre, és ott összesítse azokat. Többrégiós megoldás esetén azt javasoljuk, hogy először régiónként gyűjtse össze, összesítse és tárolja az adatokat, majd összesítse a regionális adatokat egyetlen központi rendszerben.

Kompromisszum: Vegye figyelembe, hogy a regionális és központosított adattárak költségvonzatokkal járnak.

A sávszélesség használatának optimalizálásához rangsoroljon az adatok fontossága alapján. Kötegekben kevésbé sürgős adatokat is átvihet. Ezeket az adatokat azonban nem szabad határozatlan ideig késleltetni, különösen akkor, ha időérzékeny információkat tartalmaznak.

A gyűjtési szolgáltatás két elsődleges modellt használhat a rendszerállapot-adatok gyűjtésére:

• Lekéréses modell: Aktívan lekéri az adatokat a különböző naplókból és más forrásokból az alkalmazás minden példányához.

• Leküldéses modell: Passzívan megvárja, amíg az adatok az alkalmazás egyes példányait alkotó összetevőkből lesznek elküldve.

Figyelési ügynökök

A lekéréses modellben használhat figyelési ügynököket. Az ügynökök helyileg, az alkalmazás minden példányával külön folyamatban futnak, rendszeres időközönként adatokat kérnek le, és az adatokat közvetlenül az alkalmazás összes példánya által megosztott közös tárolóba írják.

Megjegyzés

A monitorozási ügynökök ideális megoldást jelentenek az adatforrásokból magától értetődően lekért rendszerállapot-adatok rögzítéséhez. Megfelelő egy kis léptékű alkalmazáshoz, amely korlátozott számú csomóponton fut egyetlen helyen. Ilyenek például SQL Server dinamikus felügyeleti nézetek adatai, vagy egy Azure Service Bus-üzenetsor hossza.

A teljesítménnyel kapcsolatos megfontolások

Egy összetett és nagy mértékben skálázható alkalmazás hatalmas mennyiségű adatot generálhat. Az adatok mennyisége könnyen túlterhelheti az egyetlen központi helyen elérhető I/O-sávszélességet. A telemetriai megoldás nem működhet szűk keresztmetszetként, és a rendszer bővülése során méretezhetőnek kell lennie. Ideális esetben a megoldásnak olyan mértékű redundanciát kell tartalmaznia, amely csökkenti a fontos figyelési információk (például a naplózás vagy a számlázási adatok) elvesztésének kockázatát, ha a rendszer egy része meghibásodik.

A rendszerállapot-adatok pufferelésének egyik módja az üzenetsor-kezelés használata:

Ebben az architektúrában az adatgyűjtési szolgáltatás egy üzenetsorba küld adatokat. Az üzenetsor azért megfelelő, mert "legalább egyszer" szemantikát biztosít, amely biztosítja, hogy az üzenetsorba helyezett adatok ne vesszenek el a közzététel után. A tárolóírási szolgáltatást egy külön feldolgozói szerepkörrel valósíthatja meg. Ezt az architektúrát a Prioritási üzenetsor minta használatával valósíthatja meg.

A méretezhetőség érdekében a tárolóírási szolgáltatás több példányát is futtathatja. Ha nagy mennyiségű eseményt vagy sok adatpontot figyel, a Azure Event Hubs használatával elküldheti az adatokat egy másik számítási példányra feldolgozás és tárolás céljából.

Konszolidációs stratégiák

Az alkalmazás egyetlen példányából gyűjtött adatok honosított nézetet biztosítanak a példány állapotáról és teljesítményéről. A rendszer általános állapotának felméréséhez össze kell vonnia a helyi nézetekből származó adatok néhány aspektusát. Ezt az adatok tárolása után is megteheti, de bizonyos esetekben az adatok gyűjtésekor is megteheti.

A rendszerállapot-adatok egy külön adatösszesítési szolgáltatáson keresztül haladhatnak át, amely egyesíti az adatokat, és szűrési és tisztítási folyamatként működik. Összeolvaszthatja például azokat a rendszerállapot-adatokat, amelyek ugyanazokat a korrelációs információkat tartalmazzák, például egy tevékenységazonosítót. (Előfordulhat, hogy egy felhasználó üzleti műveletet indít el az egyik csomóponton, majd átkerül egy másik csomópontra, ha az első csomópont meghibásodik, vagy a terheléselosztás konfigurálása miatt.) Ez a folyamat a duplikált adatokat is képes észlelni és eltávolítani. (Duplikálás akkor fordulhat elő, ha a telemetriai szolgáltatás üzenetsorokkal küldi le a rendszerállapot-adatokat a tárolóba.)

Tárolás

A tárolási megoldás kiválasztásakor vegye figyelembe az adatok típusát, felhasználási módját, és hogy milyen sürgős szükség van rá.

Megjegyzés

Használjon különálló tárolási megoldásokat nem éles és éles környezetekhez, hogy az egyes környezetekből származó adatok könnyen azonosíthatók és kezelhetők legyenek.

Tárolási technológiák

Fontolja meg a többplatformos adatmegőrzési megközelítést, ahol a különböző típusú információk tárolása olyan technológiákban történik, amelyek leginkább megfelelnek az egyes típusok használati módjának.

A Azure Blob Storage és az Azure Table Storage például hasonló módon érhető el. A rajtuk végrehajtható műveletek azonban eltérnek, ahogy az általuk tárolt adatok részletessége is. Ha további elemzési műveleteket kell végrehajtania, vagy teljes szöveges keresési képességekre van szüksége az adatok vonatkozásában, jobb megoldás lehet a különféle lekérdezés- és adathozzáférés-típusokra optimalizált képességeket biztosító adattárakat használni. Például:

• A teljesítményszámlálók adatainak SQL-adatbázisban való tárolása lehetővé teszi az ad hoc elemzést.

• Érdemesebb lehet nyomkövetési naplókat tárolni az Azure Monitor-naplókban vagy az Azure Data Explorer.

• A biztonsági információkat egy HDFS-megoldásban tárolhatja.

Ugyanazok a rendszerállapot-adatok több célból is szükségesek lehetnek. A teljesítményszámlálók használatával például előzményként tekintheti meg a rendszer teljesítményét az idő függvényében. Ezeket az információkat más használati adatokkal egyesítve létrehozhatók az ügyfélre vonatkozó számlázási információk. Ezekben az esetekben ugyanazok az adatok több célhelyre is elküldhetők, például egy dokumentum-adatbázisba, amely hosszú távú tároló lehet a számlázási adatok tárolására, valamint egy többdimenziós tárolóba az összetett teljesítményelemzés kezeléséhez.

Győződjön meg arról, hogy olyan funkciókat biztosít, amelyek megvédik az adatokat a véletlen törléstől, például az erőforrás-zárolásoktól és a helyreállítható törléstől.

Győződjön meg arról is, hogy a szerepköralapú hozzáférés-vezérléssel biztonságossá teszi a tárterülethez való hozzáférést, hogy csak az adatokhoz hozzáférő személyek érhessék el.

Konszolidációs szolgáltatás

Implementálhat egy másik szolgáltatást, amely rendszeres időközönként lekéri az adatokat a megosztott tárolóból, particionálja és szűri azokat a rendeltetésének megfelelően, majd a megfelelő adattárakba írja azokat.

Egy másik megközelítés ezen funkció belefoglalása a konszolidálási és tisztítási folyamatba, és az adatoknak közvetlenül ezen tárolókba, nem pedig egy közbenső megosztott tárterületre való írása a lekérésüket követően.

Mindegyik megközelítésnek vannak előnyei és hátrányai. Egy különálló particionálási szolgáltatás implementálása csökkenti az összesítési és tisztítási szolgáltatás terhelését, és lehetővé teszi legalább néhány particionált adat újragenerálását, ha szükséges (attól függően, hogy mennyi adatot őriznek meg a megosztott tárolóban). Ez a megközelítés azonban további erőforrásokat használ fel. Emellett elképzelhető, hogy a rendszerállapot-adatok később érkeznek meg az egyes alkalmazáspéldányokról, és később történik a gyakorlatban használható információkká való átalakításuk.

Lekérdezési szempontok

Gondolja át, milyen sürgős adatra van szükség. A riasztásokat generáló adatokat gyorsan el kell érni, ezért gyors adattárban kell tárolni őket, és indexeltnek vagy strukturáltnak kell lenniük a riasztási rendszer által végrehajtott lekérdezések optimalizálása érdekében. Bizonyos esetekben szükség lehet arra, hogy a gyűjtési szolgáltatás helyileg formázza és mentse az adatokat, hogy a riasztási rendszer helyi példánya gyorsan küldjön értesítéseket. Ugyanezek az adatok elirányíthatók az előző ábrákon látható tárolóírási szolgáltatásnak, és központilag tárolhatók, ha más célokból is szükség lenne rájuk.

Adatmegőrzési szempontok

Bizonyos esetekben az adatok feldolgozása és átvitele után eltávolíthatja a helyileg tárolt eredeti nyers forrásadatokat. Más esetekben szükséges vagy hasznos lehet a nyers információk mentése. Előfordulhat például, hogy a hibakereséshez létrehozott adatokat a nyers formájukban szeretné megőrizni, majd a hibák megoldása után gyorsan elvetni őket.

A teljesítményadatok élettartama gyakran hosszabb, így a teljesítménytrendek észlelése és a kapacitástervezés során is felhasználhatók. Az ilyen adatok konszolidált nézeteit szokás a gyorsabb elérés érdekében határozott ideig online megőrizni. Ezt követően archiválhatók vagy elvethetők.

Az előzményadatokat célszerű menteni a hosszú távú trendek felismerése érdekében. Ahelyett, hogy a régi adatokat teljes egészében mentené, előfordulhat, hogy a felbontás csökkentése és a tárolási költségek csökkentése érdekében le tudja venni a mintát az adatokból. A percenkénti teljesítménymutatók mentése helyett például összevonhatja az egy hónapnál régebbi adatokat, hogy óránkénti nézetet alakítsanak ki.

A mérési és számlázási célból gyűjtött adatokat néha határozatlan ideig meg kell őrizni. Emellett szabályozási követelmények is előírják, hogy a naplózáshoz és a biztonsághoz gyűjtött adatokat archiválni és menteni kell. Ezek az adatok bizalmasak is, és emiatt előfordulhat, hogy titkosítani vagy más módon védeni kell azokat az illetéktelen hozzáférés ellen. Soha ne rögzítsen felhasználói jelszavakat vagy más olyan adatokat, amelyek felhasználhatók az identitással kapcsolatos csalások elkövetésére. Ezeket a részleteket a tárolás előtt érdemes kimosni az adatokból.

Annak érdekében, hogy megfeleljen a törvényeknek és előírásoknak, minimalizálja az azonosítható információk tárolását. Ha azonosításra alkalmas adatokat kell tárolnia, ügyeljen arra, hogy a megoldás tervezésekor vegye figyelembe azokat a követelményeket, amelyek lehetővé teszik az egyének számára az adataik törlését.

Elemzés

Miután különböző adatforrásokból gyűjtött adatokat, elemezze azokat a rendszer általános jólétének felméréséhez. Ehhez az elemzéshez tisztában kell legyen a következővel:

• Adatok strukturálása az Ön által meghatározott KPI-k és teljesítménymetrikák alapján.

• A különböző metrikákban és naplófájlokban rögzített adatok korrelálása. Ez a korreláció akkor fontos, ha események sorozatát követi nyomon, és segíthet a problémák diagnosztizálásában.

A legtöbb esetben az architektúra minden összetevőjének adatait helyileg rögzíti a rendszer, majd pontosan kombinálja őket más összetevők által létrehozott adatokkal.

Egy háromszintű alkalmazás például a következővel rendelkezhet:

• Egy bemutatóréteg, amely lehetővé teszi, hogy a felhasználó kapcsolódjon egy webhelyhez.

• Egy középső réteg, amely az üzleti logikát feldolgozó mikroszolgáltatások készletét üzemelteti.

• Egy adatbázisszint, amely a művelethez társított adatokat tárolja.

Egy üzleti művelet használati adatai mindhárom szintre kiterjedhetnek. Ezeket az információkat korrelálni kell ahhoz, hogy átfogó képet lehessen adni az erőforrásról és a művelet használati adatainak feldolgozásáról. A korreláció magában foglalhatja az adatok előfeldolgozását és szűrését az adatbázis szintjén. A középső rétegben az összesítés és a formázás gyakori feladat.

Javaslatok

• Az alkalmazásszintű és az erőforrásszintű naplók korrelálása. Értékelje ki mindkét szinten az adatokat a problémák észlelésének és elhárításának optimalizálásához. Összesítheti az adatokat egyetlen adatgyűjtőben, vagy kihasználhatja az eseményeket mindkét szinten lekérdező módszereket. Az alkalmazásszintű és erőforrásszintű naplók összesítéséhez és lekérdezéséhez egységes megoldást, például az Azure Log Analyticset javasoljuk.

• A ritka elérésű elemzéshez definiáljon egyértelmű megőrzési időt a tárterületen. Javasoljuk ezt a gyakorlatot, hogy lehetővé tegye az előzményelemzést egy adott időszakban. Emellett segíthet a tárolási költségek szabályozásában is. Olyan folyamatok implementálása, amelyek biztosítják, hogy az adatok archiválva legyenek olcsóbb tárolásra és összesített adatokra a hosszú távú trendelemzéshez.

• Hosszú távú trendek elemzése a működési problémák előrejelzéséhez. Értékelje ki a hosszú távú adatokat, hogy operatív stratégiákat alakítson ki, valamint előre jelezhesse, hogy milyen működési problémák várhatók, és mikor. Megfigyelheti például, hogy az átlagos válaszidők idővel lassan növekednek, és megközelítik a maximális célt.

A javaslatokkal kapcsolatos részletes útmutatásért lásd: Monitorozási adatok elemzése felhőalkalmazásokhoz.

Vizualizáció

Irányítópultok

Az adatok megjelenítésének leggyakoribb módja, ha olyan irányítópultokat használ, amelyek diagramok vagy grafikonok sorozataként vagy más vizualizációs formában képesek megjeleníteni az információkat. Ezek az elemek paraméterezhetők, és az elemzők kiválaszthatják a fontos paramétereket, például az időszakot, bármilyen konkrét helyzetben.

Igazítsa az irányítópultokat az állapotmodellhez , hogy jelezzék, ha a számítási feladat vagy a számítási feladat összetevői kifogástalan állapotban vannak, csökkent teljesítményűek vagy nem megfelelőek.

Ahhoz, hogy egy irányítópult-rendszer hatékonyan működjön, annak értelmesnek kell lennie a számítási feladatokat kezelő csapat számára. Megjeleníthet olyan információkat, amelyek a számítási feladatok állapotára vonatkoznak, és amelyek szintén végrehajthatók. Ha a számítási feladat vagy egy összetevő csökkent vagy nem megfelelő állapotú, a számítási feladatért felelős csapat tagjainak könnyen meg kell tudniuk állapítani, hogy a számítási feladat honnan származik, és el kell kezdeniük a korrekciós műveleteket vagy vizsgálatokat. Ezzel szemben, ha olyan információkat is tartalmaz, amelyek nem alkalmazhatók, vagy amelyek nem kapcsolódnak a számítási feladatok állapotához, az irányítópult szükségtelenül összetetté és frusztrálóvá teheti azokat a csapattagokat, akik megpróbálják észlelni a háttérzajt a végrehajtható adatokból.

Előfordulhat, hogy az érdekelt felek vagy fejlesztők irányítópultjai úgy vannak testre szabva, hogy csak az általuk relevánsnak talált számítási feladat adatai jelenjenek meg. Győződjön meg arról, hogy a számítási feladatért felelős csapat tisztában van azokkal az adatponttípusokkal, amelyeket más csapatok is szeretnének látni és előnézetben látni az irányítópultokon, mielőtt megosztaná őket az egyértelműség ellenőrzése érdekében. Ha irányítópultokat biztosít a számítási feladatokról az érdekelt feleknek, jó módszer arra, hogy a számítási feladatok állapotáról értesüljenek, de fennáll annak a veszélye, hogy az érintettek nem értik egyértelműen a látott adatokat.

A jó irányítópultok nem csak az információkat jelenítik meg. Emellett lehetővé teszi az elemzők számára, hogy rögtönzött kérdéseket tehessenek fel ezzel az információval kapcsolatban. Egyes rendszerek olyan felügyeleti eszközöket biztosítanak, amelyekkel egy operátor elvégezheti ezeket a feladatokat, és megismerheti a mögöttes adatokat. Ehelyett az adatok tárolására használt adattártól függően lehetséges lehet közvetlenül lekérdezni az adatokat, vagy importálni azokat olyan eszközökbe, mint az Excel, további elemzés és jelentéskészítés céljából.

Megjegyzés

Az irányítópultok hozzáférésének korlátozása a jogosult személyzet számára. Az irányítópultokra vonatkozó információk üzleti szempontból érzékenyek lehetnek. A mögöttes adatokat is védenie kell, hogy a felhasználók ne módosíthassak őket.

Jelentéskészítés

A jelentéskészítés segítségével egy általános áttekintés készíthető a rendszerről. Előfordulhat, hogy előzményadatokat és aktuális információkat tartalmaz. A jelentéskészítési követelmények két átfogó kategóriába sorolhatók: operatív jelentéskészítés és biztonsági jelentéskészítés.

A működési jelentés általában a következőket tartalmazza:

• Statisztikai adatok összesítése, amelyek segítségével megismerheti a teljes rendszer vagy a megadott alrendszerek erőforrás-kihasználtságát egy adott időszakban.

• A teljes rendszer vagy a meghatározott alrendszerek erőforrás-használati trendjeinek azonosítása egy adott időszakban.

• Figyelési kivételek, amelyek a rendszer egészében vagy meghatározott alrendszerekben történtek egy adott időszakban.

• Az alkalmazás hatékonyságának meghatározása az üzembe helyezett erőforrások esetében, és annak megértése, hogy az erőforrások mennyisége és a hozzájuk kapcsolódó költségek csökkenthetők-e anélkül, hogy szükségtelenül befolyásolnák a teljesítményt.

A biztonsági jelentés nyomon követi a rendszer ügyfél általi használatát. Az alábbiakra terjedhetnek ki:

• A felhasználói műveletek naplózása. Ehhez a feladathoz rögzíteni kell az egyes felhasználók által teljesített kéréseket, dátumokkal és időpontokkal együtt. Az adatokat úgy kell strukturálni, hogy a rendszergazdák gyorsan rekonstruálhassák a felhasználó által egy adott időszakban végrehajtott műveletek sorrendjét.

• Az erőforrások a felhasználók általi használatának nyomon követése. Ehhez a feladathoz rögzíteni kell, hogy egy felhasználó kérései hogyan férnek hozzá a rendszert alkotó különböző erőforrásokhoz, és mennyi ideig. A rendszergazdák felhasználhatják ezeket az adatokat egy felhasználó által egy adott időszakra vonatkozó használati jelentés létrehozására, esetleg számlázás céljából.

Sok esetben kötegelt folyamatok is létrehozhatnak jelentéseket egy meghatározott ütemezés szerint. A késés általában nem probléma. Olyan kötegelt folyamatokkal is rendelkeznie kell, amelyek szükség szerint spontán módon hozhatnak létre jelentéseket. Ha például egy relációs adatbázisban, például Azure SQL Database-ben tárol adatokat, egy SQL Server Reporting Services-hez hasonló eszközzel kinyerheti és formázhatja az adatokat, és jelentések halmazaként jelenítheti meg azokat.

Riasztások

Annak érdekében, hogy a rendszer kifogástalan, rugalmas és biztonságos maradjon, állítson be riasztásokat, hogy az operátorok időben reagálhassanak rájuk. A riasztások elegendő környezeti információt tartalmazhatnak ahhoz, hogy gyorsan hozzá tudjanak kezdeni a diagnosztikai tevékenységekhez. A riasztások olyan szervizelési függvények meghívására használhatók, mint az automatikus skálázás vagy más önjavító mechanizmusok. A riasztások költségtudatosságot is lehetővé tehetnek, ha áttekintik a költségvetéseket és a korlátokat.

Javaslatok

• Határozzon meg egy riasztási válaszfolyamatot, amely azonosítja a felelős tulajdonosokat és műveleteket.

• Konfigurálja a riasztásokat egy jól definiált hatókörhöz (erőforrástípusokhoz és erőforráscsoportokhoz), és állítsa be a részletességet a zaj minimalizálása érdekében.

• Használjon automatizált riasztási megoldást, például a Splunkot vagy az Azure Monitort, ahelyett, hogy aktívan kellene keresnie a problémákat.

• Riasztások használatával üzembe helyezhet szervizelési folyamatokat. Például automatikusan létrehozhat jegyeket a problémák és a megoldások nyomon követéséhez.

• Nyomon követheti a felhőplatform-szolgáltatások állapotát a régiókban, kommunikációt végez a kimaradásokról, a tervezett karbantartási tevékenységekről és egyéb egészségügyi tanácsadásokról.

Küszöbértékek

Riasztások jönnek létre a küszöbértékek átlépésekor, amint azt a figyelési rendszer észleli. Győződjön meg arról, hogy a beállított küszöbértékek általában elegendő időt biztosítanak a számítási feladat szükséges módosításainak végrehajtására a leromlás vagy a kimaradások elkerülése érdekében. Állítsa be például az automatikus skálázási küszöbértéket úgy, hogy a skálázást még azelőtt kezdeményezhesse, hogy a futó rendszerek túlterheltek legyenek a csökkentett felhasználói élményig. Alapozza az infrastruktúra kezelése során a korábbi tapasztalatok alapján hozzárendelt küszöbértékeket, és érvényesítse őket a tesztelési eljárások részeként elvégzett teszteléssel.

A riasztási használati esetekre és egyéb szempontokra vonatkozó részletes útmutatásért lásd: Megbízható figyelési és riasztási stratégia tervezése.

Azure-beli facilitálás

• Az Azure Monitor egy átfogó monitorozási megoldás a felhőből és a helyszíni környezetekből származó monitorozási adatok gyűjtésére, elemzésére és megválaszolására.

• A Log Analytics egy olyan eszköz a Azure Portal, amellyel napló lekérdezéseket szerkeszthet és futtathat a Log Analytics-munkaterület adatain.

  Ha több munkaterületet használ, az ajánlott eljárásokért tekintse meg a Log Analytics-munkaterület architektúrájának útmutatóját .

• Az Application Insights az Azure Monitor bővítménye. APM-funkciókat biztosít.

• Az Azure Monitor Insights speciális elemzési eszközök adott Azure-technológiákhoz (például virtuális gépekhez, alkalmazásszolgáltatásokhoz és tárolókhoz). Ezek az eszközök az Azure Monitor és a Log Analytics részét képezik.

• Az Azure Monitor for SAP-megoldások egy Azure-beli monitorozási eszköz az Azure-ban futó SAP-környezetekhez.

• Azure Policy segíthet a szervezeti szabványok betartatásában és a megfelelőség nagy léptékű értékelésében.

Kapcsolódó hivatkozások

• Kialakítási útmutató
• Javaslatok a megbízható figyelési és riasztási stratégia kialakításához
• Javaslatok monitorozásra és fenyegetésészlelésre
• Javaslatok teljesítményadatok gyűjtésére

Közösségi hivatkozások

• Az Azure Monitor Alapszintű riasztások (AMBA) a riasztásdefiníciók központi adattára, amellyel az ügyfelek és a partnerek az Azure Monitor használatával javíthatják megfigyelhetőségi élményüket.

Működési kiválóság ellenőrzőlista

Tekintse meg a javaslatok teljes készletét.

Működési kiválóság ellenőrzőlista