Javaslatok monitorozási rendszer tervezésére és létrehozására
Az Azure Well-Architected Framework operatív kiválósági ellenőrzőlistájára vonatkozó javaslat:
| OE:07 | Tervezzen és implementáljon egy monitorozási rendszert, amely ellenőrzi 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 kibocsátott működési telemetriákat, metrikákat és naplókat. |
|---|
Kapcsolódó útmutató: Javaslatok az alkalmazások rendszerezéséhez
Ez az útmutató a figyelési rendszer 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, olyan átfogó rendszerre van szüksége, amely saját vermet tartalmaz, amely minden monitorozási, észlelési és riasztási funkció alapjait biztosítja.
Meghatározások
| 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. |
Főbb 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ő alapelveket:
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, amelyeket egyébként nehéz lehet elvégezni.
Naplók és metrikák gyűjtése a teljes számítási feladat veremből. Minden infrastruktúra-erőforrást és alkalmazásfüggvényt szabványosított, értelmes adatok előállítására kell konfigurálni, és ezeket az adatokat gyűjteni kell.
Az összegyűjtött adatokat 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 vizualizációja a számítási feladatokért felelős csapatok és más érdekelt felek számára készült hasznos irányítópultokon vagy jelentésekben.
Az intelligensen definiált küszöbértékekre vonatkozó végrehajtható riasztások és egyéb automatikus válaszok konfigurálása a számítási feladatokat végző csapatok értesítésére a problémák felmerülése esetén.
A figyelési és riasztási rendszerek belefoglalása az általános számítási feladatok tesztelési eljárásaiba.
Győződjön meg arról, hogy a monitorozási és riasztási rendszerek folyamatos fejlesztésre szorulnak. Az éles környezetben történő alkalmazás- és infrastruktúra-viselkedés folyamatos tanulási lehetőségeket biztosít. Ezeket a tanulságokat beépíti a figyelési és riasztási tervekbe.
Az összegyűjtött és elemezni kívánt monitorozási adatok összekapcsolása 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 az összesnek folyamatosan, egész nap, minden nap futnia kell.
Ez a munkafolyamat a figyelési rendszert mutatja be:
Rendszerállapot-adatok gyűjtése
Feljegyzés
A naplózás engedélyezéséhez eszközként kell beállítania az alkalmazást. További információkért tekintse meg a rendszerállapot-útmutatót.
Az összes számítási feladat összetevőjét konfigurálnia kell, legyen szó infrastruktúra-erőforrásokról vagy alkalmazásfüggvényekről, a telemetriai adatok és/vagy események, például naplók és metrikák rögzítéséhez.
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 automatizálással kéri le a figyelési platform.
A metrikák elsősorban egy állapotmodell készítéséhez é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ához is hasznosak. Ezek a trendek segíthetnek az ügyfelek szempontjából a fejlesztésekkel kapcsolatos döntések meghozatalában. A metrikákat általában a monitorozási platform határozza meg, 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
Alkalmazások esetében a gyűjtőszolgáltatás lehet egy alkalmazásteljesítmény-kezelési (APM) eszköz, amely a rendszerállapot-adatokat létrehozó alkalmazásból önállóan futtatható. Az APM engedélyezése után egyértelmű láthatóságot biztosít a fontos metrikákhoz 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örnyezetek esetében például nincs szükség az éles környezettel azonos részletességre.
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 a különböző környezetekben, milyen események történnek, és milyen feltételek mellett történik.
Javasoljuk, hogy gyűjtse össze az alkalmazásnaplókat és az eseményeket minden nagyobb környezetben. A környezetek közötti adatokat a lehető legnagyobb mértékben különítse el egymástól, ha különböző adattárakat használ az egyes környezetekhez, ha ez gyakorlatias. Szűrőkkel biztosíthatja, hogy a nem kritikus környezetek ne bonyolíthassá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.
Strukturálatlan sztringtípusok helyett géppel olvasható adatpontokkal kell rögzítenie az alkalmazáseseményeket strukturált adattípusokban. 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 a JSON, a MessagePack vagy a Protobuf helyett az ETL/ETW helyett önleíró 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. Az adatokat szabványos formátumban olvasó, átalakító és küldő összetevők könnyen integrálhatók.
Infrastruktúra-adatok
A számítási feladatban lévő infrastruktúra-erőforrások esetében győződjön meg arról, hogy naplókat és metrikákat is gyűjt. Szolgáltatásként nyújtott infrastruktúra (IaaS) rendszerek esetén az operációs rendszer, az alkalmazásréteg és a diagnosztikai naplók rögzítése a számítási feladatok állapotával kapcsolatos metrikák mellett. Szolgáltatásként nyújtott platform (PaaS) erőforrások 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 a felügyeleti síkhoz tartozó előfizetéshez és diagnosztikai naplókhoz is gyűjthet tevékenységnaplókat.
Gyűjtési stratégiák
Ne kelljen manuálisan beolvasni a telemetriai adatokat minden összetevőből. Helyezze át az adatokat egy központi helyre, és konszolidálja azokat. Többrégiós megoldás esetén 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 rendszerbe.
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. A 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 tartalmaz.
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 a rendszer elküldi az adatokat az alkalmazás egyes példányait alkotó összetevőktől.
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, rendszeresen leküldik az adatokat, és közvetlenül az alkalmazás összes példánya által megosztott közös tárolóba írják az adatokat.
Feljegyzé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 méretű alkalmazáshoz, amely csak korlátozott számú csomóponton fut egyetlen helyen. Ilyenek például az SQL Server dinamikus felügyeleti nézetei vagy az Azure Service Bus-üzenetsor hossza.
Teljesítménnyel kapcsolatos szempontok
Egy összetett és nagy mértékben méretezhető alkalmazás hatalmas mennyiségű adatot hozhat létre. 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 méretezhetőnek kell lennie a rendszer bővülése során. Ideális esetben a megoldásnak olyan mértékű redundanciát kell tartalmaznia, amely csökkenti a fontos monitorozási adatok (például a naplózási vagy 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 a sorba állítás használata:
Ebben az architektúrában az adatgyűjtési szolgáltatás adatokat küld egy üzenetsorba. Az üzenetsor azért megfelelő, mert "legalább egyszer" szemantikát biztosít, amely segít biztosítani, hogy az üzenetsorba helyezett adatok ne vesszenek el a közzététel után. A tárolóírási szolgáltatást külön feldolgozói szerepkörrel implementálhatja. Ezt az architektúrát a Prioritási üzenetsor minta használatával implementálhatja.
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 nagy számú adatpontot figyel, az Azure Event Hubs használatával egy másik számítási példányba is elküldheti az adatokat 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 lokalizált 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 egyesítenie az adatok bizonyos aspektusait a helyi nézetekből. 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 adatkonszolidálá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 adatokat tartalmazzák, mint például egy tevékenységazonosítót. (Egy felhasználó elindíthat egy üzleti műveletet az egyik csomóponton, majd átkerülhet egy másik csomópontra, ha az első csomópont meghibásodik, vagy a terheléselosztás konfigurálása miatt.) Ez a folyamat képes észlelni és eltávolítani a duplikált adatokat is. (Duplikáció akkor fordulhat elő, ha a telemetriai szolgáltatás üzenetsorokkal küldi le a rendszerállapot-adatokat a tárolóba.)
Adatok tárolása lekérdezéshez és elemzéshez
A tárolási megoldás kiválasztásakor vegye figyelembe az adatok típusát, a használat módját és azt, hogy milyen sürgős szükség van rá.
Feljegyzés
A nem éles és éles környezetekhez külön tárolási megoldásokat használva biztosíthatja, 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 felhasználási módjának.
Az Azure Blob Storage és az Azure Table Storage például hasonló módon érhető el. A rajtuk elvégezhető 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élda:
A teljesítményszámlálók adatainak SQL-adatbázisban való tárolása lehetővé teszi az ad hoc elemzést.
Jobb lehet a nyomkövetési naplókat az Azure Monitor-naplókban vagy az Azure Data Explorerben tárolni.
Biztonsági információkat tárolhat egy HDFS-megoldásban.
Ugyanazok a rendszerállapot-adatok több célból is szükségesek lehetnek. A teljesítményszámlálókkal 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 dokumentumadatbázisba, amely hosszú távú tároló lehet a számlázási adatok tárolásához, valamint egy többdimenziós tárolóba az összetett teljesítményelemzés kezeléséhez.
Mindenképpen engedélyezze a funkciót, hogy megvédje 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á teheti a tárterülethez való hozzáférést, hogy csak azok a személyek férjenek hozzá az adatokhoz, akiknek hozzá kell férni.
Konszolidációs szolgáltatás
Implementálhat egy másik szolgáltatást, amely rendszeresen lekéri az adatokat a megosztott tárolóból, particionálja és szűri azokat a célnak megfelelően, majd a megfelelő adattárakba írja.
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 particionálási szolgáltatás implementálása csökkenti a konszolidálási és tisztítási szolgáltatás terhelését, és lehetővé teszi a particionált adatok legalább egy részének újragenerálását, ha szükséges (attól függően, hogy mennyi adat marad 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, és indexelni vagy strukturálni kell 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 meg szeretné őrizni a hibakereséshez létrehozott adatokat a nyers formában, de a hibák megoldása után gyorsan elvetheti őket.
A teljesítményadatok élettartama gyakran hosszabb, így a teljesítmény trendjeinek é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 le tudja venni az adatok mintáját a felbontás csökkentése és a tárolási költségek megtakarítása érdekében. 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 a szabályozási követelmények azt 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 jegyezze fel a felhasználói jelszavakat vagy az identitáscsalás elkövetésére használható egyéb adatokat. 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ítható 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, hogy kérjék adataik törlését.
Adatok elemzése a számítási feladatok állapotának megértéséhez
Miután adatokat gyűjtött különböző adatforrásokból, elemezze azokat a rendszer általános jólétének felméréséhez. Ehhez az elemzéshez világos ismereteket kell tudnia a következőről:
Adatok strukturálása az Ön által definiált 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ációja. Ez a korreláció fontos az események sorozatának nyomon követésekor, é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 a többi összetevő által létrehozott adatokkal.
Egy háromszintű alkalmazás például a következővel rendelkezhet:
Egy bemutatószint, amely lehetővé teszi a felhasználók számára, hogy egy webhelyhez csatlakozzanak.
Egy olyan középső réteg, amely üzleti logikát feldolgozó mikroszolgáltatások készletét üzemelteti.
Egy adatbázisszint, amely a művelethez társított adatokat tárolja.
Az egyetlen ü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 a művelet erőforrásáról és feldolgozási használatáról. A korreláció magában foglalhatja az adatok előfeldolgozását és szűrését az adatbázisszinten. A középső szinten az összesítés és a formázás gyakori feladat.
Ajánlások
Az alkalmazásszintű és az erőforrásszintű naplók korrelációja. Mindkét szinten értékelje ki az adatokat a problémák észlelésének és hibaelhá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ódszerek előnyeit. Az alkalmazásszintű és erőforrásszintű naplók összesítéséhez és lekérdezéséhez egy egységes megoldást, például az Azure Log Analyticset javasoljuk.
Adjon meg egyértelmű megőrzési időt a tárolón a hideg elemzéshez. Javasoljuk ezt a gyakorlatot, hogy lehetővé tegye a történelmi elemzést egy adott időszakban. Emellett a tárolási költségek szabályozásában is segíthet. Olyan folyamatok implementálása, amelyek biztosítják, hogy az adatok archiválva legyenek olcsóbb tárolási és összesített adatokkal 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 működési stratégiákat alakítson ki, valamint előrejelezhesse, 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 elérik a maximális célt.
Ezekről a javaslatokról részletes útmutatást a felhőalkalmazások monitorozási adatainak elemzése című témakörben talál.
Számítási feladatok állapotjelentéseinek vizualizációja
Irányítópultok
Az adatok vizualizációjának leggyakoribb módja az, ha olyan irányítópultokat használ, amelyek diagramok vagy grafikonok sorozataként vagy más vizualizációs formában jeleníthetik meg 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őtartamot, bármilyen adott 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ástalanok, csökkentek vagy nem megfelelőek.
Ahhoz, hogy egy irányítópult-rendszer hatékonyan működjön, a számítási feladatokat kezelő csapat számára fontosnak kell lennie. Vizualizálja a számítási feladatok állapotára vonatkozó és az is végrehajtható információkat. Ha a számítási feladat vagy egy összetevő sérült vagy sérült, 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 ered, és megkezdhetik a korrekciós műveleteket vagy vizsgálatokat. Ezzel szemben a nem végrehajtható vagy a számítási feladatok állapotához nem kapcsolódó információk is szükségtelenül összetettsé és bosszantóvá tehetik az irányítópultot azoknak a csapattagoknak, akik a végrehajtható adatok háttérzaját próbálják felismerni.
Előfordulhat, hogy olyan irányítópultokkal rendelkezik az érdekelt felek vagy fejlesztők számára, amelyek úgy vannak testre szabva, hogy csak az általuk relevánsnak talált számítási feladat adatai jelenjenek meg. Mielőtt megosztaná őket, győződjön meg arról, hogy a számítási feladatokért felelős csapat tisztában van azoknak az adatpontoknak a típusaival, amelyeket más csapatok szeretnének látni és megtekinteni, mielőtt megosztaná őket az egyértelműség érdekében. Ha irányítópultokat biztosít a számítási feladatokról az érdekelt felek számára, az jó módszer arra, hogy a munkaterhelés állapotát értékelje, de azzal a kockázattal jár, hogy kontraproduktív, ha az érdekelt felek nem értik egyértelműen az általuk 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 az operátor elvégezheti ezeket a feladatokat, és feltárhatja az alapul szolgáló adatokat. Ehelyett az információk tárolásához 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, a további elemzéshez és jelentéskészítéshez.
Feljegyzés
Az irányítópult 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: a működési jelentéskészítés és a biztonsági jelentéskészítés.
A működési jelentések általában a következőket tartalmazzák:
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őablakban.
A teljes rendszer vagy meghatározott alrendszerek erőforrás-használati trendjeinek azonosítása egy adott időszakban.
A rendszer vagy a meghatározott alrendszerek során egy adott időszakban előforduló kivételek monitorozása.
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á 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, valamint a dátumokat és időpontokat. 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ó minden kérése hogyan fér hozzá a rendszert alkotó különböző erőforrásokhoz, és mennyi ideig. A rendszergazda felhasználhatja ezeket az adatokat egy felhasználó által megadott időszakra vonatkozó kihasználtsági 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 az Azure SQL Database-ben tárol adatokat, egy olyan eszközzel, mint az SQL Server Reporting Services, kinyerheti és formázhatja az adatokat, és jelentéseket jeleníthet meg.
Riasztások definiálása kulcseseményekhez
Annak érdekében, hogy a rendszer kifogástalan, rugalmas és biztonságos maradjon, állítson be riasztásokat, hogy az operátorok időben válaszolhassanak 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 öngyógyító mechanizmusok. A riasztások a költségtudatosságot is lehetővé teszik a költségvetések és a korlátok láthatóságának biztosításával.
Ajánlások
Adjon meg egy folyamatot a riasztási válaszhoz, 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 arra kötelezi a felhasználókat, hogy aktívan keressenek problémákat.
Riasztások használatával üzembe helyezi a szervizelési folyamatokat. Például automatikusan létrehozhat jegyeket a problémák és a megoldás nyomon követéséhez.
A felhőplatform-szolgáltatások állapotának nyomon követése a régiókban, a kimaradásokkal, a tervezett karbantartási tevékenységekkel és egyéb egészségügyi tanácsadásokkal kapcsolatos kommunikáció.
Küszöbértékek
Riasztások jönnek létre a küszöbértékek átlépésekor, a figyelési rendszer által észlelt módon. 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 feladatok szükséges módosításának végrehajtásához a leromlás vagy kimaradás elkerülése érdekében. Állítsa be például az automatikus skálázási küszöbértéket a skálázás elindítására, mielőtt a futó rendszerek bármelyike túlterhelné a csökkentett felhasználói élményt. 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 végzett teszteléssel.
A riasztási használati esetekről és egyéb szempontokról részletes útmutatást a megbízható figyelési és riasztási stratégia tervezése című témakörben talál.
Az Azure megkönnyítése
Az Azure Monitor egy átfogó monitorozási megoldás a felhőből és a helyszíni környezetekből származó adatok gyűjtésére, elemzésére és megválaszolására.
A Log Analytics egy eszköz az Azure Portalon, 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 az SAP-megoldásokhoz egy Azure monitorozási eszköz az Azure-ban futó SAP-környezetekhez.
Az 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
- Eszközállapot-útmutató
- Javaslatok megbízható monitorozási és riasztási stratégia kialakításához
- Javaslatok monitorozáshoz és fenyegetésészleléshez
- Javaslatok a 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ági ellenőrzőlista
Tekintse meg a javaslatok teljes készletét.