Megosztás a következőn keresztül:

Az Azure Well-Architected Framework perspektívája a Log Analyticsről

  • Cikk

Well-Architected Keretrendszer számítási feladatainak működését és teljesítményét különböző módokon és különböző okokból kell figyelni. Az Azure Monitor Log Analytics-munkaterületek a monitorozási adatok nagy részének elsődleges napló- és metrikagyűjtői. A munkaterületek az Azure Monitor több funkcióját támogatják, beleértve az alkalmi lekérdezéseket, a vizualizációkat és a riasztásokat. Az általános monitorozási alapelvekért lásd: Monitorozási és diagnosztikai útmutató. Az útmutató általános monitorozási alapelveket mutat be. Azonosítja a különböző adattípusokat. Azonosítja az Azure Monitor által támogatott szükséges elemzéseket, és azonosítja az elemzést lehetővé tevő munkaterületen tárolt adatokat is.

Ez a cikk feltételezi, hogy ismeri a rendszertervezés alapelveit. Szüksége van a Log Analytics-munkaterületek és az Azure Monitor azon funkcióinak működő ismeretére is, amelyek feltöltik az üzemeltetési számítási feladatok adatait. További információ: Log Analytics-munkaterület áttekintése.

Fontos

Az útmutató használata

Minden szakasz rendelkezik egy tervezési ellenőrzőlistával , amely az architekturális területeket mutatja be, valamint a technológiai hatókörre honosított tervezési stratégiákat.

Ezek közé tartoznak a technológiai képességekre vagy az üzembe helyezési topológiákra vonatkozó javaslatok is, amelyek segíthetnek ezeknek a stratégiáknak a megvalósulásában. A javaslatok nem jelentik a Log Analytics-munkaterületek és a kapcsolódó Azure Monitor-erőforrások összes konfigurációjának teljes listáját. Ehelyett felsorolják a tervezési szempontokra leképezett legfontosabb javaslatokat. A javaslatok segítségével elkészítheti a megvalósíthatósági vizsgálatot, megtervezheti a számítási feladatok monitorozási környezetét, vagy optimalizálhatja a meglévő számítási feladatok monitorozási megoldását.

Technológiai hatókör

Ez az útmutató az alábbi Azure-erőforrásokhoz tartozó, egymással összefüggő döntésekre összpontosít.

  • Log Analytics-munkaterületek
  • Számítási feladat működési naplójának adatai
  • Diagnosztikai beállítások az Azure-erőforrásokon a számítási feladatban

Megbízhatóság

A megbízhatósági pillér célja, hogy folyamatos funkcionalitást biztosítson a megfelelő rugalmasság és a hibákból való gyors helyreállítás képessége révén.

A megbízhatósági tervezési alapelvek magas szintű tervezési stratégiát biztosítanak, amely az egyes összetevőkre, rendszerfolyamatokra és a rendszer egészére vonatkozik.

A Log Analytics-munkaterületek megbízhatósági helyzetei a következők:

  • A munkaterület rendelkezésre állása.
  • Az összegyűjtött adatok védelme az Azure-adatközpontok vagy -régiók ritka meghibásodása esetén.

A különböző régiókban lévő munkaterületek közötti feladatátvételnek jelenleg nincs szabványos funkciója, de vannak olyan stratégiák, amelyeket akkor érdemes használni, ha a rendelkezésre állásra vagy a megfelelőségre vonatkozó konkrét követelményekkel rendelkezik.

Tervezési ellenőrzőlista a megbízhatósághoz

Indítsa el a tervezési stratégiát a Megbízhatóság tervezési felülvizsgálati ellenőrzőlistája alapján, és állapítsa meg annak üzleti követelményeihez való relevanciáját, és tartsa szem előtt a virtuális gépek termékváltozatait és funkcióit, valamint azok függőségeit. Bővítse ki a stratégiát, hogy szükség esetén további megközelítéseket is tartalmazzon.

  • Tekintse át a Log Analytics-munkaterületek szolgáltatási korlátait. A szolgáltatáskorlátok szakasz segít megérteni az adatgyűjtésre és adatmegőrzésre vonatkozó korlátozásokat, valamint a szolgáltatás egyéb aspektusait. Ezek a korlátok segítenek meghatározni, hogyan tervezheti meg megfelelően a számítási feladatok megfigyelhetőségi stratégiáját. Mindenképpen tekintse át az Azure Monitor szolgáltatáskorlátait , mivel az itt tárgyalt függvények, például a lekérdezések, a Log Analytics-munkaterületek használata kéz a kézben működnek.
  • Tervezze meg a munkaterület rugalmasságát és helyreállítását. A Log Analytics-munkaterületek regionálisak, és nem támogatják a régiók közötti redundanciát vagy replikációt. A rendelkezésre állási zóna redundanciára vonatkozó lehetőségei is korlátozottak. Ezért meg kell határoznia a munkaterületek megbízhatósági követelményeit, és rétegeznie kell, hogy megfeleljen ezeknek a céloknak. A követelmények előírhatják, hogy a munkaterületnek rugalmasnak kell lennie az adatközpont hibáival vagy regionális hibáival szemben, vagy előírhatják, hogy az adatokat egy feladatátvételi régió új munkaterületére kell helyreállítani. Ezen forgatókönyvek mindegyike további erőforrásokat és folyamatokat igényel a sikeres működéshez, ezért a megbízhatósági célokat a költségekkel és az összetettséggel kell egyensúlyba helyezni.
  • Válassza ki a megbízhatósági követelményeknek megfelelő üzembehelyezési régiókat. Helyezze üzembe a Log Analytics-munkaterületet és az adatgyűjtési végpontokat (DCE-ket) a működési adatokat kibocsátó számításifeladat-összetevőkkel együtt. A munkaterület és a DCE-k üzembe helyezéséhez választott régiót a számítási feladat üzembe helyezésének helye határozza meg. Előfordulhat, hogy mérlegelnie kell bizonyos Log Analytics-funkciók, például a dedikált fürtök regionális rendelkezésre állását a számítási feladat megbízhatóságára, költségére és teljesítményére vonatkozó egyéb tényezőkkel szemben.
  • Győződjön meg arról, hogy a megfigyelhetőségi rendszerek kifogástalan állapotban vannak. A számítási feladat bármely más összetevőjéhez hasonlóan győződjön meg arról, hogy a monitorozási és naplózási rendszerek megfelelően működnek. Ehhez engedélyezze azokat a funkciókat, amelyek állapotadat-jeleket küldenek az üzemeltetési csapatoknak. Állítson be a Log Analytics-munkaterületekre és a kapcsolódó erőforrásokra vonatkozó állapotadat-jeleket.

Konfigurációs javaslatok a megbízhatósághoz

Ajánlás Előny
Ne foglalja bele a Log Analytics-munkaterületeket a számítási feladat kritikus útvonalára. A munkaterületek fontosak a jól működő megfigyelhetőségi rendszer számára, de a számítási feladatok működése nem függhet tőlük. Ha a munkaterületeket és a kapcsolódó függvényeket a számítási feladat kritikus útvonalán kívül tartja, minimálisra csökkenti annak kockázatát, hogy a megfigyelhető rendszert érintő problémák ne befolyásolják a számítási feladat futásidejének végrehajtását.
A munkaterületi adatok magas tartósságának támogatásához helyezzen üzembe Log Analytics-munkaterületeket egy olyan régióban , amely támogatja az adatrugalmasságot. Az adatrugalmasság csak akkor lehetséges, ha a munkaterületet egy, ugyanabban a régióban lévő dedikált fürthöz kapcsolja. Ha dedikált fürtöt használ, az lehetővé teszi a társított munkaterületek rendelkezésre állási zónák közötti elosztását, amely védelmet nyújt az adatközpont-kimaradások ellen. Ha most nem gyűjt elegendő adatot egy dedikált fürt igazolásához, ez a megelőző regionális választás támogatja a jövőbeli növekedést.
Válassza ki a munkaterület üzembe helyezését a számítási feladathoz való közelség alapján.

Használjon adatgyűjtési végpontokat (DCE) ugyanabban a régióban, mint a Log Analytics-munkaterület.		 Helyezze üzembe a munkaterületet ugyanabban a régióban, mint a számítási feladat példányai. Ha a munkaterület és a DCE-k ugyanabban a régióban vannak, mint a számítási feladat, a többi régióban csökkenti a kimaradások által gyakorolt hatás kockázatát.

A DCE-ket az Azure Monitor-ügynök és a Logs Ingestion API használja a számítási feladatok műveleti adatainak Log Analytics-munkaterületre való küldéséhez. Előfordulhat, hogy több tartományvezérlőre van szüksége, annak ellenére, hogy az üzemelő példánynak csak egyetlen munkaterülete van. A DCE-k adott környezethez való konfigurálásával kapcsolatos további információkért lásd: Adatgyűjtési végpontok beállítása az üzemelő példány alapján.<Br
Ha a számítási feladat aktív-aktív kialakításban van üzembe helyezve, fontolja meg több munkaterület és DCE használatát a számítási feladat üzembe helyezésének régióiban.

A munkaterületek több régióban való üzembe helyezése összetettebbé teszi a környezetet. Egyensúlyozza ki a Log Analytics-munkaterület architektúrájának tervezése a rendelkezésre állási követelményekkel című szakaszban részletezett feltételeket.
Ha azt szeretné, hogy a munkaterület elérhető legyen régióhiba esetén, vagy ha nem gyűjt elég adatot egy dedikált fürthöz, konfigurálja az adatgyűjtést úgy, hogy kritikus fontosságú adatokat küldjön több különböző régióban lévő munkaterületnek. Ezt a gyakorlatot napló csoportos küldésnek is nevezik.

Konfigurálja például a DCR-eket több munkaterülethez a virtuális gépeken futó Azure Monitor-ügynökhöz. Több diagnosztikai beállítás konfigurálásával erőforrásnaplókat gyűjthet az Azure-erőforrásokból, és több munkaterületre is elküldheti a naplókat.
Így a számítási feladatok működési adatai regionális hiba esetén elérhetők az alternatív munkaterületen. Tudnia kell azonban, hogy az adatokra, például riasztásokra és munkafüzetekre támaszkodó erőforrások nem lesznek automatikusan replikálva a többi régióba. Fontolja meg az Azure Resource Manager -sablonok (ARM) tárolását a kritikus fontosságú riasztási erőforrásokhoz az alternatív munkaterület konfigurációjával, vagy helyezze üzembe őket minden régióban, de tiltsa le őket a redundáns riasztások megelőzése érdekében. Mindkét lehetőség támogatja a gyors engedélyezést regionális hiba esetén.

Kompromisszum: Ez a konfiguráció duplikált betöltési és adatmegőrzési díjakat eredményez, ezért csak kritikus adatokhoz használja.
Ha egy adatközpontban vagy régióban lévő adatok védelmére van szükség, konfigurálja az adatexportálást a munkaterületről, hogy az adatokat egy másik helyre mentse.

Ez a beállítás hasonló az adatok különböző munkaterületekre történő csoportos küldésének előző beállításához. Ez a lehetőség azonban kevesebbe kerül, mert a további adatok a tárolóba lesznek írva.

Használja az Azure Storage redundanciabeállításait, beleértve a georedundáns tárolást (GRS) és a geo-zónaredundáns tárolást (GZRS) az adatok más régiókba történő további replikálásához.

Az adatexportálás nem biztosít rugalmasságot a regionális betöltési folyamatot befolyásoló incidensekkel szemben.		 Bár előfordulhat, hogy az előzményműveleti naplóadatok nem lesznek könnyen lekérdezhetők az exportált állapotban, ez biztosítja, hogy az adatok hosszabb regionális kimaradást túlélhessenek, és hosszabb ideig elérhetők és megőrizhetők legyenek.

Ha adatexportálással nem támogatott táblák exportálására van szükség, az adatok védelméhez más módszereket is használhat az adatok exportálására, beleértve a Logic Appst is.

Ahhoz, hogy ez a stratégia működőképes helyreállítási tervként működjön, olyan folyamatokkal kell rendelkeznie, amelyekkel újrakonfigurálhatja az Azure-beli erőforrások diagnosztikai beállításait, valamint minden olyan ügynököt, amely adatokat szolgáltat. Azt is meg kell terveznie, hogy manuálisan rehidratálja az exportált adatokat egy új munkaterületre. A korábban ismertetett beállításhoz hasonlóan azokhoz az erőforrásokhoz is definiálnia kell folyamatokat, amelyek az adatokra, például riasztásokra és munkafüzetekre támaszkodnak.
A magas rendelkezésre állást igénylő kritikus fontosságú számítási feladatok esetében érdemes lehet olyan összevont munkaterületi modellt implementálni, amely több munkaterületet használ a magas rendelkezésre állás biztosításához regionális hiba esetén. A kritikus fontosságú előíró ajánlott eljárásokkal kapcsolatos útmutatást nyújt az Azure-ban rendkívül megbízható alkalmazások tervezéséhez. A tervezési módszertan tartalmaz egy összevont munkaterület-modellt több Log Analytics-munkaterülettel, hogy magas rendelkezésre állást biztosítson, ha több hiba történik, beleértve egy Azure-régió meghibásodását is.

Ez a stratégia kiküszöböli a régiók közötti kimenő forgalom költségeit, és régióhiba esetén is működőképes marad. Azonban összetettebbé kell tennie az Azure-beli kritikus fontosságú számítási feladatok állapotmodellezésével és megfigyelhetőségével foglalkozó cikkben leírt konfigurációkat és folyamatokat.
Használja az infrastruktúrát kódként (IaC) a munkaterületek és a kapcsolódó függvények üzembe helyezéséhez és kezeléséhez. Ha a lehető legtöbb üzembe helyezést automatizálja, valamint a rugalmasságot és a helyreállítást szolgáló mechanizmusokat, az biztosítja, hogy ezek a műveletek megbízhatóak legyenek. Kritikus időt takaríthat meg a műveleti folyamatokban, és minimalizálhatja az emberi hibák kockázatát.

Győződjön meg arról, hogy a mentett napló lekérdezésekhez hasonló függvények is definiálva vannak az IaC-ben, hogy helyreállítsa őket egy új régióba, ha helyreállításra van szükség.
Egyetlen felelősségi elv alapján tervezzen DCR-eket, hogy a DCR-szabályok egyszerűek maradjanak.

Bár egy DCR betölthető a forrásrendszerek összes bemenetével, szabmánnyal és célhelyével, célszerű szűken szűrt szabályokat tervezni, amelyek kevesebb adatforrásra támaszkodnak. A logikai cél kívánt megfigyelhetőségi hatókörének eléréséhez használja a szabály-hozzárendelések összetételét.

Emellett minimalizálja az átalakítást a DCR-ben		 A szűken szűrt DCR-ek használata esetén minimálisra csökkenti annak kockázatát, hogy egy szabály helytelen konfigurációja szélesebb körű hatással legyen. Csak arra a hatókörre korlátozza a hatást, amelyhez a DCR készült. További információ: Ajánlott eljárások adatgyűjtési szabályok létrehozásához és kezeléséhez az Azure Monitorban.

Bár az átalakítás bizonyos helyzetekben hatékony és szükséges lehet, kihívást jelenthet a kulcsszólekérdezés nyelvének (KQL) tesztelése és hibaelhárítása. Ha lehetséges, minimalizálja az adatvesztés kockázatát úgy, hogy nyersen betölti az adatokat, és a lekérdezési időpontban kezeli az átalakításokat.
Napi korlát vagy adatmegőrzési szabályzat beállításakor győződjön meg arról, hogy a szükséges naplók betöltésével és megőrzésével tartja fenn a megbízhatósági követelményeket. A napi korlát egy adott mennyiség elérése után leállítja a munkaterületek adatainak gyűjtését, ami segít a betöltési mennyiség szabályozásának fenntartásában. De csak gondos tervezés után használja ezt a funkciót. Győződjön meg arról, hogy a napi korlátot nem éri rendszeresség. Ha ez történik, a korlát túl szigorúan van beállítva. Újra kell konfigurálnia a napi korlátot, hogy ne maradjon le a számítási feladatból érkező kritikus jelekről.

Hasonlóképpen, körültekintően és figyelmesen közelítse meg az adatmegőrzési szabályzat csökkentésének megközelítését, hogy ne veszítse el véletlenül a kritikus adatokat.
A Log Analytics-munkaterületi elemzések segítségével nyomon követheti a betöltési kötetet, a betöltött adatokat és az adatkorlátot, a nem válaszoló naplóforrásokat és a sikertelen lekérdezéseket más adatok között. Állapotriasztásokat hozhat létre, hogy proaktívan értesítse Önt arról, ha egy munkaterület adatközpont vagy regionális hiba miatt elérhetetlenné válik. Ez a stratégia biztosítja, hogy sikeresen monitorozza a munkaterületek állapotát, és proaktívan cselekedjen, ha az állapot romlásának veszélye áll fenn. A számítási feladatok bármely más összetevőjéhez hasonlóan fontos, hogy tisztában legyen az állapotmetrikákkal, és azonosítani tudja a trendeket a megbízhatóság időbeli javítása érdekében.

Azure Policy

Az Azure nem kínál a Log Analytics-munkaterületek megbízhatóságával kapcsolatos szabályzatokat. Létrehozhat egyéni szabályzatokat, amelyek megfelelőségi védőkorlátokat hoznak létre a munkaterület üzemelő példányai köré, például biztosíthatja, hogy a munkaterületek egy dedikált fürthöz legyenek társítva.

Bár nem kapcsolódik közvetlenül a Log Analytics-munkaterületek megbízhatóságához, szinte minden elérhető szolgáltatáshoz vannak Azure-szabályzatok. A szabályzatok biztosítják, hogy a diagnosztikai beállítások engedélyezve legyenek az adott szolgáltatáshoz, és ellenőrizze, hogy a szolgáltatás naplóadatai egy Log Analytics-munkaterületre áramlanak-e. A számítási feladatok architektúrájában minden szolgáltatásnak el kell küldenie a naplóadatokat egy Log Analytics-munkaterületre a saját megbízhatósági igényeiknek megfelelően, és a szabályzatok segíthetnek kikényszeríteni őket. Hasonlóképpen, a szabályzatok biztosítják, hogy az ügynökalapú platformok, például a virtuális gépek és a Kubernetes telepítve legyenek az ügynökkel.

Azure Advisor

Az Azure nem kínál Azure Advisor-javaslatokat a Log Analytics-munkaterületek megbízhatóságával kapcsolatban.

Biztonság

A biztonsági pillér célja, hogy bizalmassági, integritási és rendelkezésre állási garanciákat biztosítson a számítási feladat számára.

A biztonsági tervezési alapelvek magas szintű tervezési stratégiát biztosítanak e célok eléréséhez azáltal, hogy megközelítéseket alkalmaznak a monitorozási és naplózási megoldás műszaki tervezésére.

Biztonsági ellenőrzőlista tervezése

Indítsa el a tervezési stratégiát a Biztonság tervezési felülvizsgálati ellenőrzőlistája alapján, és azonosítsa a biztonsági réseket és vezérlőket a biztonsági helyzet javítása érdekében. Bővítse ki a stratégiát, hogy szükség esetén további megközelítéseket is tartalmazzon.

  • Tekintse át az Azure Monitor biztonsági alapkonfigurációit és a Log Analytics-munkaterületekhez való hozzáférés kezelése témakört . Ezek a témakörök útmutatást nyújtanak a biztonsági ajánlott eljárásokhoz.
  • Helyezze üzembe a munkaterületeket szegmentálással, mint alapvető alapelvet. Szegmentálás implementálása a hálózatkezelés, az adatok és a hozzáférési szinteken. A szegmentálás segít biztosítani, hogy a munkaterületek a megfelelő mértékben el legyenek különítve, és a lehető legnagyobb mértékben védve legyenek a jogosulatlan hozzáféréstől, miközben továbbra is megfelelnek a megbízhatóságra, a költségoptimalizálásra, a működési kiválóságra és a teljesítményhatékonyságra vonatkozó üzleti követelményeknek.
  • Győződjön meg arról, hogy naplózhatja a munkaterület olvasási és írási tevékenységeit és a kapcsolódó identitásokat. A támadók kihasználhatják az operatív naplók megtekintését. A feltört identitás naplóinjektálási támadásokhoz vezethet. A műveletek naplózásának engedélyezése az Azure Portalon vagy API-interakciókon és a kapcsolódó felhasználókon keresztül. Ha nincs beállítva a munkaterület naplózására, előfordulhat, hogy a szervezetet a megfelelőségi követelmények megsértésének veszélye fenyegeti.
  • Hatékony hálózati vezérlők implementálása. Hálózatelkülönítési és tűzfalfunkciókkal biztosítja a munkaterülethez és a naplókhoz való hálózati hozzáférést. A nem megfelelően konfigurált hálózati vezérlők veszélyeztethetik a jogosulatlan vagy rosszindulatú szereplők hozzáférését.
  • Határozza meg, hogy milyen típusú adatokra van szükség megváltoztathatatlanságra vagy hosszú távú megőrzésre. A naplóadatokat ugyanolyan szigorúsággal kell kezelni, mint a számítási feladatok adatait az éles rendszereken belül. Adja meg a naplóadatokat az adatbesorolási eljárásokban, hogy a bizalmas naplóadatokat a megfelelőségi követelményeknek megfelelően sikeresen tárolja.
  • Inaktív naplóadatok védelme titkosítással. A szegmentálás önmagában nem védi teljesen a naplóadatok bizalmasságát. Ha jogosulatlan nyers hozzáférés történik, a naplóadatok inaktív állapotban történő titkosítása megakadályozza, hogy a rossz szereplők az adatokat a munkaterületen kívül használják.
  • Bizalmas naplóadatok védelme elrejtéssel. Az éles rendszerekben található számítási feladatok adataihoz hasonlóan további intézkedéseket kell tennie annak biztosítása érdekében, hogy a bizalmas adatok megőrizve legyenek az operatív naplókban szándékosan vagy véletlenül jelen lévő bizalmas adatok esetében. Ha obfuscation metódusokat használ, az segít elrejteni a bizalmas naplóadatokat a jogosulatlan szemek elől.

Konfigurációs javaslatok a biztonsághoz

Ajánlás Előny
Ha saját titkosítási kulcsra van szüksége a munkaterületeken tárolt adatok és mentett lekérdezések védelméhez, használja az ügyfél által kezelt kulcsokat.

Az Azure Monitor biztosítja, hogy az adatok és a mentett lekérdezések a Microsoft által felügyelt kulcsok (MMK) használatával inaktív állapotban legyenek titkosítva. Ha saját titkosítási kulcsra van szüksége, és elegendő adatot gyűjt egy dedikált fürthöz, használja az ügyfél által felügyelt kulcsot. Az adatokat az Azure Key Vault saját kulcsával titkosíthatja, szabályozhatja a kulcs életciklusát, és visszavonhatja az adatokhoz való hozzáférést.

Ha a Microsoft Sentinelt használja, győződjön meg arról, hogy ismeri a Microsoft Sentinel ügyfél által felügyelt kulcsának beállításával kapcsolatos szempontokat.		 Ez a stratégia lehetővé teszi az adatok titkosítását az Azure Key Vault saját kulcsával, a kulcs életciklusának szabályozásához és az adatokhoz való hozzáférés visszavonásának képességével.
Konfigurálja a napló-lekérdezések naplózását annak nyomon követéséhez, hogy mely felhasználók futtatnak lekérdezéseket.

Konfigurálja az egyes munkaterületek naplóit úgy, hogy elküldsék a helyi munkaterületnek, vagy konszolidálja őket egy dedikált biztonsági munkaterületen, ha elkülöníti a működési és biztonsági adatokat. A Log Analytics-munkaterület elemzéseinek használatával rendszeresen áttekintheti ezeket az adatokat. Érdemes lehet napló lekérdezési riasztási szabályokat létrehozni, hogy proaktívan értesítse Önt, ha jogosulatlan felhasználók próbálnak lekérdezéseket futtatni.		 A napló lekérdezésnaplózása rögzíti a munkaterületen futtatott egyes lekérdezések adatait. Kezelje ezeket az auditadatokat biztonsági adatokként, és gondoskodjon a LAQueryLogs tábla megfelelő védelméről. Ez a stratégia megerősíti a biztonsági helyzetét azáltal, hogy segít biztosítani, hogy a jogosulatlan hozzáférés azonnal le legyen fogott, ha valaha is megtörténik.
A munkaterület védelme privát hálózatkezeléssel és szegmentálási mértékekkel.

A privát kapcsolat funkcióval a naplóforrások és a munkaterületek közötti kommunikációt privát hálózatkezelésre korlátozhatja.		 Privát kapcsolat használata esetén azt is szabályozhatja, hogy mely virtuális hálózatok férhetnek hozzá egy adott munkaterülethez, tovább erősítve a biztonságot szegmentálással.
Az API-kulcsok helyett Microsoft Entra ID használata a munkaterületi API-hozzáféréshez, ahol elérhető. A lekérdezési API-khoz való API-kulcsalapú hozzáférés nem hagy ügyfélenkénti auditnaplót. Megfelelő hatókörű Entra ID-alapú hozzáférést használjon, hogy megfelelően naplózhassa a programozott hozzáférést.
Konfigurálja a különböző típusú adatokhoz való hozzáférést a munkaterületen, amely a szervezet különböző szerepköreihez szükséges.

Állítsa be a munkaterület hozzáférés-vezérlési módjáterőforrás- vagy munkaterület-engedélyek használata beállításra. Ez a hozzáférés-vezérlés lehetővé teszi, hogy az erőforrás-környezetek tulajdonosai anélkül férhessenek hozzá az adataikhoz, hogy explicit hozzáférést kapnak a munkaterülethez.

Táblaszintű RBAC használata olyan felhasználók számára, akiknek több erőforrás tábláihoz is hozzáférésre van szükségük.		 Ez a beállítás leegyszerűsíti a munkaterület konfigurációját, és segít biztosítani, hogy a felhasználók ne férhessenek hozzá a nem kívánt működési adatokhoz.

Rendelje hozzá a megfelelő beépített szerepkört, hogy munkaterületi engedélyeket adjon a rendszergazdáknak az előfizetés, az erőforráscsoport vagy a munkaterület szintjén a felelősségi körüktől függően.

A táblaengedélyekkel rendelkező felhasználók az erőforrás-engedélyüktől függetlenül hozzáférhetnek a tábla összes adatához.

A Log Analytics-munkaterületekhez való hozzáférés kezelése című témakörben talál részletes információkat a munkaterületen lévő adatokhoz való hozzáférés különböző lehetőségeiről.
Olyan naplók exportálása, amelyek hosszú távú megőrzést vagy megváltoztathatatlanságot igényelnek.

Az adatexportálással adatokat küldhet egy Azure Storage-fiókba módosíthatatlansági szabályzatokkal az adatok illetéktelen módosításával szembeni védelem érdekében. Nem minden naplótípusnak van ugyanolyan jelentősége a megfelelőség, a naplózás vagy a biztonság szempontjából, ezért határozza meg az exportálandó adattípusokat.		 Előfordulhat, hogy olyan naplózási adatokat gyűjt a munkaterületen, amelyek a hosszú távú megőrzést igénylő szabályozások hatálya alá tartoznak. A Log Analytics-munkaterületen lévő adatok nem módosíthatók, de törölhetők. A működési adatok másolatának megőrzési célból történő exportálásával olyan megoldást hozhat létre, amely megfelel a megfelelőségi követelményeknek.
Határozza meg a munkaterület bizalmas adatainak szűrésére vagy elrejtésére vonatkozó stratégiát.

Előfordulhat, hogy bizalmas adatokat tartalmazó adatokat gyűjt. Szűrje azokat a rekordokat, amelyeket nem érdemes összegyűjteni az adott adatforrás konfigurációjának használatával. Akkor használjon átalakítást , ha csak az adatok adott oszlopait kell eltávolítani vagy elfedni.

Ha olyan szabványokkal rendelkezik, amelyek megkövetelik az eredeti adatok nem módosíthatók, a KQL-lekérdezések "h" literálját használva elrejtheti a munkafüzetekben megjelenő lekérdezési eredményeket.		 A munkaterület bizalmas adatainak elfedése vagy kiszűrése segít biztosítani a bizalmas adatok bizalmasságát. A megfelelőségi követelmények sok esetben meghatározzák a bizalmas adatok kezelésére vonatkozó módszereket. Ez a stratégia segít proaktívan megfelelni a követelményeknek.

Azure Policy

Az Azure a Log Analytics-munkaterületek biztonságával kapcsolatos szabályzatokat kínál a kívánt biztonsági helyzet kikényszerítéséhez. Ilyen szabályzatok például a következők:

Az Azure számos szabályzatot is kínál a privát kapcsolat konfigurálásának kikényszerítéséhez, például a Log Analytics-munkaterületeknek blokkolnia kell a naplóbetöltést és a nyilvános hálózatokról való lekérdezést, vagy akár DINE-szabályzatokkal is konfigurálhatja a megoldást, például az Azure Monitor Private Link Hatókör konfigurálása privát DNS-zónák használatára.

Azure Advisor

Az Azure nem kínál Azure Advisor-javaslatokat a Log Analytics-munkaterületek biztonságával kapcsolatban.

Költségoptimalizálás

A költségoptimalizálás középpontjában a költségminták észlelése, a kritikus területeken lévő befektetések rangsorolása, valamint a szervezet költségvetésének megfelelő optimalizálás áll, miközben megfelel az üzleti követelményeknek.

A Költségoptimalizálás tervezési alapelvei magas szintű tervezési stratégiát biztosítanak ezen üzleti célok eléréséhez. Emellett segítséget nyújtanak a monitorozási és naplózási megoldáshoz kapcsolódó műszaki tervezésben is, ha szükséges.

A Log Analytics-munkaterületek díjainak kiszámításáról az Azure Monitor Naplók költségszámításai és beállításai című témakörben talál további információt.

Tervezési ellenőrzőlista a költségoptimalizáláshoz

Indítsa el a tervezési stratégiát a beruházások költségoptimalizálási ellenőrzőlistája alapján, és finomhangolja a tervet, hogy a számítási feladat igazodjon a számítási feladathoz lefoglalt költségvetéshez. A tervezésnek a megfelelő Azure-képességeket kell használnia, figyelnie kell a befektetéseket, és meg kell találnia az idő múlásával optimalizálandó lehetőségeket.

  • Költségmodellezési gyakorlatok végrehajtása. Ezek az exercize-ek segítenek megérteni a munkaterület aktuális költségeit, és előrejelezni a költségeket a munkaterület növekedéséhez képest. Elemezze a számítási feladat növekedési trendjeit, és győződjön meg arról, hogy tisztában van a számítási feladatok bővítésének terveit a jövőbeli üzemeltetési naplózási költségek megfelelő előrejelzéséhez.
  • Válassza ki a megfelelő számlázási modellt. A költségmodell használatával állapítsa meg a forgatókönyvéhez legmegfelelőbb számlázási modellt . A munkaterületek jelenlegi használata és a használatuk megtervezése a számítási feladatok fejlődésével meghatározza, hogy a használatalapú fizetéses vagy a kötelezettségvállalási szintű modell a legmegfelelőbb-e a forgatókönyvhöz.

    Ne feledje, hogy az egyes munkaterületekhez különböző számlázási modelleket választhat, és bizonyos esetekben kombinálhatja a munkaterület költségeit, így részletes elemzést és döntéshozatalt végezhet.
  • Gyűjtse össze a megfelelő mennyiségű naplóadatokat. Rendszeresen ütemezett elemzést végezhet az erőforrások diagnosztikai beállításairól, az adatgyűjtési szabály konfigurációjáról és az egyéni alkalmazáskód-naplózásról, hogy ne gyűjtsön felesleges naplóadatokat.
  • A nem termelési környezetek kezelése másként, mint az éles környezetben. Tekintse át a nem éles környezeteket, és győződjön meg arról, hogy megfelelően konfigurálta a diagnosztikai beállításokat és a megőrzési szabályzatokat. Ezek gyakran lényegesen kevésbé robusztusak, mint az éles környezetek, különösen fejlesztési/tesztelési vagy tesztkörnyezetekben.

Konfigurációs javaslatok a költségoptimalizáláshoz

Ajánlás Előny
Konfigurálja a tarifacsomagot az egyes Log Analytics-munkaterületek által általában gyűjtött adatok mennyiségéhez. Alapértelmezés szerint a Log Analytics-munkaterületek használatalapú fizetéses díjszabást használnak, minimális adatmennyiség nélkül. Ha elegendő adatot gyűjt, jelentősen csökkentheti költségeit egy kötelezettségvállalási szint használatával, amely lehetővé teszi, hogy alacsonyabb díjért cserébe napi minimális mennyiségű adatot gyűjtsön. Ha elegendő adatot gyűjt egyetlen régióban lévő munkaterületek között, összekapcsolhatja őket egy dedikált fürthöz , és a fürt díjszabásának használatával kombinálhatja az összegyűjtött kötetet.

A kötelezettségvállalási szintekről és a használati szintnek leginkább megfelelő adatok meghatározásáról az Azure Monitor-naplók költségszámításai és lehetőségei című témakörben talál további információt. A használat becsült költségeinek különböző tarifacsomagokban való megtekintéséhez lásd: Használat és becsült költségek.
Adatmegőrzés és archiválás konfigurálása. A Log Analytics-munkaterületen az alapértelmezett 31 napon túli adatok megőrzéséért díjat számítunk fel. 90 nap, ha a Microsoft Sentinel engedélyezve van a munkaterületen, és 90 nap az Application Insights-adatok esetében. Vegye figyelembe, hogy az adatok könnyen elérhetők a napló lekérdezésekhez. Az archivált naplók konfigurálásával jelentősen csökkentheti a költségeket. Az archivált naplók segítségével akár hét évig is megőrizheti az adatokat, és alkalmanként továbbra is hozzáférhet azokhoz. Az adatokat keresési feladatok használatával vagy egy adatkészlet munkaterületre való visszaállításával érheti el.
Ha a Microsoft Sentinelt használja a biztonsági naplók elemzéséhez, fontolja meg egy külön munkaterület használatát a naplók tárolásához. Ha dedikált munkaterületet használ a SIEM által használt naplóadatokhoz, az segíthet a költségek szabályozásában. A Microsoft Sentinel által használt munkaterületekre a Microsoft Sentinel díjszabása vonatkozik. A biztonsági követelmények határozzák meg, hogy milyen típusú naplókra van szükség a SIEM-megoldásban. Előfordulhat, hogy ki tudja zárni a működési naplókat, amelyeket a standard Log Analytics díjszabása terhelne meg, ha külön munkaterületen vannak.
A hibakereséshez, hibaelhárításhoz és naplózáshoz használt táblákat alapszintű naplókként konfigurálhatja. Az alapszintű naplókhoz konfigurált Log Analytics-munkaterületek táblái alacsonyabb betöltési költséggel rendelkeznek a korlátozott funkciókért és a napló lekérdezésekért járó díjért cserébe. Ha ritkán kérdezi le ezeket a táblákat, és nem használja őket riasztáshoz, ez a lekérdezési költség több lehet, mint a csökkentett betöltési költség.
A munkaterület adatforrásaiból történő adatgyűjtés korlátozása. Az Azure Monitor költségeinek elsődleges tényezője a Log Analytics-munkaterületen gyűjtött adatok mennyisége. Győződjön meg arról, hogy nem gyűjt több adatot, mint amennyi a szolgáltatások és alkalmazások állapotának és teljesítményének felméréséhez szükséges. Minden erőforráshoz válassza ki a megfelelő kategóriákat a konfigurált diagnosztikai beállításokhoz, hogy megadja a szükséges működési adatok mennyiségét. Segít a számítási feladatok sikeres kezelésében, és nem kezeli a figyelmen kívül hagyott adatokat.

Előfordulhat, hogy a költségek és a monitorozási követelmények között kompromisszum van. Előfordulhat például, hogy a magas mintasebességgel gyorsabban észleli a teljesítményproblémát, de alacsonyabb mintaarányt szeretne a költségek megtakarításához. A legtöbb környezet több különböző típusú gyűjtéssel rendelkező adatforrással rendelkezik, ezért az egyes környezetekre vonatkozó költségcélokkal kell egyensúlyba hoznia az adott követelményeket. A különböző adatforrások gyűjtésének konfigurálásával kapcsolatos javaslatokért lásd: Költségoptimalizálás az Azure Monitorban .
Rendszeresen elemezze a munkaterület használati adatait a trendek és anomáliák azonosításához.

A Log Analytics-munkaterület megállapításainak használatával rendszeresen áttekintheti a munkaterületen gyűjtött adatok mennyiségét. Az adatgyűjtés további elemzése a Log Analytics-munkaterület használatelemzési módszereivel annak megállapításához, hogy vannak-e olyan egyéb konfigurációk, amelyek tovább csökkenthetik a használatot.		 Azáltal, hogy segít megérteni a különböző források által gyűjtött adatok mennyiségét, azonosítja az adatgyűjtés olyan rendellenességeit és növekvő trendjeit, amelyek többletköltséget eredményezhetnek. Ez a szempont akkor fontos, ha új adatforrás-készletet ad hozzá a számítási feladathoz. Ha például új virtuálisgép-készletet ad hozzá, engedélyezze az új Azure diagnosztikai beállításokat egy szolgáltatásban, vagy módosítsa az alkalmazás naplószintjeit.
Riasztás létrehozása magas adatgyűjtés esetén. A váratlan számlák elkerülése érdekében proaktívan értesítenie kell, amikor túlzott használatot tapasztal. Az értesítés lehetővé teszi, hogy a számlázási időszak vége előtt elhárítsa az esetleges rendellenességeket.
A napi korlátot érdemes megelőző intézkedésként figyelembe venni annak biztosítása érdekében, hogy ne lépje túl az adott költségvetést. A napi korlát letiltja az adatgyűjtést egy Log Analytics-munkaterületen a konfigurált korlát elérését követő nap hátralévő részében. Ne használja ezt a gyakorlatot módszerként a költségek csökkentésére a Mikor használjon napi korlátot című cikkben leírtak szerint, hanem a helytelen konfiguráció vagy visszaélés miatti elszabadult betöltés megakadályozása érdekében.

Ha napi korlátot állít be, hozzon létre egy riasztást a korlát elérésekor. Mindenképpen hozzon létre riasztási szabályt is, ha eléri a százalékos arányt. Beállíthat például egy riasztási szabályt arra az esetre, ha eléri a 90%-os kapacitást. Ez a riasztás lehetőséget ad a megnövekedett adatok okának kivizsgálására és kezelésére, mielőtt a korlát bezárja a kritikus adatgyűjtést a számítási feladatból.

Azure Policy

Az Azure nem kínál a Log Analytics-munkaterületek költségoptimalizálásával kapcsolatos szabályzatokat. Egyéni szabályzatokat hozhat létre, amelyekkel megfelelőségi védőkorlátokat hozhat létre a munkaterület üzemelő példányai köré, például gondoskodhat arról, hogy a munkaterületek a megfelelő adatmegőrzési beállításokat tartalmazzák.

Azure Advisor

Az Azure Advisor javaslatokat tesz arra, hogy a munkaterület adott tábláit helyezze át az alacsony költségű alapszintű naplóadat-csomagba olyan táblák esetében, amelyek viszonylag nagy betöltési mennyiséget kapnak. A korlátozások megértéséhez használja az alapszintű naplókat a váltás előtt. További információ: Mikor érdemes alapszintű naplókat használni? című témakört. Az Azure Advisor azt is javasolhatja, hogy módosítsa a tarifacsomagot a teljes munkaterületen a teljes használati mennyiség alapján.

Működésbeli kiválóság

Az operatív kiválóság elsősorban a fejlesztési eljárásokra, a megfigyelhetőségre és a kiadáskezelésre vonatkozó eljárásokra összpontosít.

Az operatív kiválóság tervezési alapelvei magas szintű tervezési stratégiát biztosítanak e célok eléréséhez a számítási feladat üzemeltetési követelményeinek megfelelően.

Az operatív kiválóság tervezési ellenőrzőlistája

Indítsa el a tervezési stratégiát a Log Analytics-munkaterületekhez kapcsolódó megfigyelhetőségi, tesztelési és üzembe helyezési folyamatok meghatározásához az Operational Excellence tervezési felülvizsgálati ellenőrzőlistája alapján.

  • Használja az infrastruktúrát kódként (IaC) a számítási feladat Log Analytics-munkaterületeivel kapcsolatos összes függvényhez. Minimalizálja a naplógyűjteményi, betöltési, tárolási és lekérdezési függvények ( beleértve a mentett lekérdezéseket és a lekérdezési csomagokat is) manuális felügyeletével és üzemeltetésével járó emberi hibák kockázatát, a lehető legtöbb függvény kódon keresztüli automatizálásával. Emellett olyan riasztásokat is tartalmazzon, amelyek állapotváltozásokat jelentenek, valamint az IaC-kódban naplókat küldő erőforrások diagnosztikai beállításainak konfigurációját. Adja meg a kódot a többi számítási feladathoz kapcsolódó kóddal, hogy biztosítsa a munkaterületek felügyeletéhez szükséges biztonságos üzembehelyezési eljárásokat.
  • Győződjön meg arról, hogy a munkaterületek kifogástalan állapotban vannak, és értesítést kap, ha problémák merülnek fel. A számítási feladat bármely más összetevőjéhez hasonlóan a munkaterületek is problémákba ütközhetnek. A problémák értékes időt és erőforrásokat jelenthetnek a hibaelhárításhoz és a megoldáshoz, és előfordulhat, hogy a csapat nem tud az éles számítási feladatok állapotáról. A munkaterületek proaktív monitorozásának és a lehetséges problémák elhárításának lehetővé tették, hogy az üzemeltetési csapatok minimalizálják a hibaelhárítással és a hibák elhárításával töltött időt.
  • Válassza el az éles üzemet a nem éles számítási feladatoktól. Kerülje a szükségtelen összetettséget, amely többletmunkát okozhat az üzemeltetési csapat számára azáltal, hogy az éles környezetben eltérő munkaterületeket használ, mint a nem éles környezetek. A beérkező adatok zavart okozhatnak, mivel a tesztelési tevékenységek éles környezetben lévő eseményeknek tűnhetnek.
  • A beépített eszközök és függvények előnyben részesítve a nem Microsoft-megoldásokat Beépített eszközökkel bővítheti a monitorozási és naplózási rendszerek funkcióit. Előfordulhat, hogy további konfigurációkat kell létrehoznia, hogy támogassa az olyan követelményeket, mint a helyreállíthatóság vagy az adatelkülönülés, amelyek nem érhetők el a Log Analytics-munkaterületekkel. Ezekben az esetekben, amikor gyakorlatias, használjon natív Azure- vagy Microsoft-eszközöket a szervezet által támogatott eszközök számának minimális szinten tartásához.
  • A munkaterületek kezelése statikusként, nem pedig rövid élettartamú összetevőkként Más típusú adattárakhoz hasonlóan a munkaterületeket sem szabad figyelembe venni a számítási feladat rövid élettartamú összetevői között. A Well-Architected-keretrendszer általában a nem módosítható infrastruktúrát részesíti előnyben, valamint azt a képességet, hogy az üzemelő példányok részeként gyorsan és egyszerűen cserélje le az erőforrásokat a számítási feladaton belül. A munkaterület adatainak elvesztése azonban katasztrofális és visszafordíthatatlan lehet. Ezért hagyja ki a munkaterületeket azokról az üzembehelyezési csomagokról, amelyek a frissítések során lecserélik az infrastruktúrát, és csak helyben végezze el a frissítéseket a munkaterületeken.
  • Győződjön meg arról, hogy az operatív személyzet be van tanítva Kusto lekérdezésnyelv Az alkalmazottak betanítása lekérdezések létrehozásához vagy módosításához, ha szükséges. Ha az operátorok nem tudnak lekérdezéseket írni vagy módosítani, az lelassíthatja a kritikus hibaelhárítást vagy más funkciókat, mivel az operátoroknak más csapatokra kell támaszkodniuk, hogy elvégezzék a feladatukat.

Konfigurációs javaslatok az operatív kiválósághoz

Ajánlás Előny
Tervezzen meg egy munkaterület-stratégiát az üzleti követelményeknek megfelelően.

A Log Analytics-munkaterületek stratégiájának megtervezésével kapcsolatos útmutatásért lásd: Log Analytics-munkaterületi architektúra tervezése . Adja meg, hogy hányat hozzon létre, és hol helyezze el őket.

Ha a számítási feladatnak egy központosított platformcsapat-ajánlat használatára volt szüksége, győződjön meg arról, hogy minden szükséges operatív hozzáférést beállított. Emellett hozzon létre riasztásokat, hogy a számítási feladatok megfigyelhetőségi igényei teljesüljenek.		 Egy vagy legalább minimális számú munkaterület maximalizálja a számítási feladat működési hatékonyságát. Korlátozza a működési és biztonsági adatok eloszlását, növeli a lehetséges problémák láthatóságát, megkönnyíti a minták azonosítását, és minimalizálja a karbantartási követelményeket.

Előfordulhat, hogy több munkaterületre, például több bérlőre vonatkozó követelményekkel rendelkezik, vagy több régióban lévő munkaterületekre lehet szüksége a rendelkezésre állási követelmények támogatásához. Ezért győződjön meg arról, hogy megfelelő folyamatokkal rendelkezik a megnövekedett összetettség kezeléséhez.
Használja az infrastruktúrát kódként (IaC) a munkaterületek és a kapcsolódó függvények üzembe helyezéséhez és kezeléséhez. Az infrastruktúra kódként (IaC) használatával meghatározhatja a munkaterületek részleteit ARM-sablonokban, az Azure BICEP-ben vagy a Terraformban. Lehetővé teszi a meglévő DevOps-folyamatok használatát új munkaterületek üzembe helyezéséhez és Azure Policy konfigurálásuk kényszerítéséhez.

Ha az összes IaC-kódot az alkalmazáskóddal együtt helyezi el, azzal biztosíthatja, hogy a biztonságos üzembehelyezési eljárások minden üzemelő példány esetében megmaradnak.
A Log Analytics-munkaterületek elemzéseivel nyomon követheti a Log Analytics-munkaterületek állapotát és teljesítményét, és értelmes és végrehajtható riasztásokat hozhat létre a működési problémák proaktív értesítéséhez.

A Log Analytics-munkaterület-elemzések egységes nézetet biztosítanak a használatról, a teljesítményről, az állapotról, az ügynökökről, a lekérdezésekről és a változásnaplókról az összes munkaterületen.

Minden munkaterület rendelkezik egy műveleti táblával , amely naplózza a munkaterületet érintő fontos tevékenységeket.		 Tekintse át azokat az információkat, amelyeket a Log Analytics insights rendszeresen biztosít az egyes munkaterületek állapotának és működésének nyomon követéséhez. Ha ezeket az információkat használja, könnyen érthető vizualizációkat hozhat létre, például irányítópultokat vagy jelentéseket, amelyekkel a műveletek és az érdekelt felek nyomon követhetik a munkaterületek állapotát.

Hozzon létre riasztási szabályokat ezen a táblán alapulva, hogy proaktívan értesüljön a működési probléma bekövetkezésekor. A munkaterülethez ajánlott riasztásokkal egyszerűsítheti a legkritikusabb riasztási szabályok létrehozását.
Gyakorolja a folyamatos fejlesztést, ha gyakran újra megismétli az Azure diagnosztikai beállításait az erőforrásokon, az adatgyűjtési szabályokon és az alkalmazásnapló részletességén.

Győződjön meg arról, hogy optimalizálja a naplógyűjtési stratégiát az erőforrás-beállítások gyakori áttekintésével. Működési szempontból úgy csökkentheti a naplók zaját, hogy azokra a naplókra összpontosít, amelyek hasznos információkat nyújtanak az erőforrások állapotáról.		 Az ilyen optimalizálással lehetővé teszi az operátorok számára, hogy kivizsgálják és elháríthassák a felmerülő problémákat, vagy egyéb rutinfeladatokat, rögtönzött vagy vészhelyzeti feladatokat hajtsanak végre.

Ha új diagnosztikai kategóriákat tesz elérhetővé egy erőforrástípushoz, tekintse át az ezzel a kategóriával kibocsátott naplótípusokat, és állapítsa meg, hogy ezek engedélyezése segíthet-e a gyűjtési stratégia optimalizálásában. Az új kategória például a rögzített tevékenységek nagyobb csoportjának részhalmaza lehet. Az új részhalmaz lehetővé teheti a naplók mennyiségének csökkentését azáltal, hogy a műveletek nyomon követéséhez fontos tevékenységekre összpontosít.

Azure Policy és az Azure Advisor

Az Azure nem kínál szabályzatokat, és nem tesz Azure Advisor-javaslatokat a Log Analytics-munkaterületek működési kiválóságával kapcsolatban.

Teljesítménybeli hatékonyság

A teljesítményhatékonyság a felhasználói élmény fenntartásáról szól, még akkor is, ha a kapacitás kezelése növeli a terhelést . A stratégia magában foglalja az erőforrások skálázását, a lehetséges szűk keresztmetszetek azonosítását és optimalizálását, valamint a csúcsteljesítmény optimalizálását.

A Teljesítményhatékonyság tervezési alapelvei magas szintű tervezési stratégiát biztosítanak e kapacitáscélok eléréséhez a várt használattal szemben.

A teljesítményhatékonyság tervezési ellenőrzőlistája

Indítsa el a tervezési stratégiát a Teljesítményhatékonyság tervezési felülvizsgálati ellenőrzőlistája alapján a Log Analytics-munkaterületek és a kapcsolódó függvények alapkonfigurációjának meghatározásához.

  • Ismerje meg a naplóadatok betöltési késésének alapjait az Azure Monitorban. A naplók munkaterületekre való betöltésekor több tényező is hozzájárul a késéshez. Ezen tényezők közül sok az Azure Monitor platform velejárója. A tényezők és a normál késési viselkedés megértése segíthet a megfelelő elvárások beállításában a számítási feladatok üzemeltetési csapatában.
  • Válassza el a nem éles és az éles számítási feladatokat. Az éles üzemre jellemző munkaterületek csökkentik a nem éles rendszerek által okozott többletterhelést. Ez csökkenti a munkaterületek teljes erőforrásigényét, és kevesebb erőforrást igényel a naplóadatok feldolgozásának kezeléséhez.
  • Válassza ki a megfelelő üzembehelyezési régiókat a teljesítménykövetelményeknek való megfeleléshez. Helyezze üzembe a Log Analytics-munkaterületet és az adatgyűjtési végpontokat (DCE-ket) a számítási feladathoz közel. A munkaterület és a DCE-k üzembe helyezéséhez választott régiót a számítási feladat üzembe helyezésének helye határozza meg. Előfordulhat, hogy mérlegelnie kell a munkaterületek és DCE-k a számítási feladattal azonos régióban történő üzembe helyezésének teljesítménybeli előnyeit a megbízhatósági követelményekkel összevetve, ha már üzembe helyezte a számítási feladatot egy olyan régióban, amely nem támogatja ezeket a követelményeket a naplóadatokhoz.

Konfigurációs javaslatok a teljesítményhatékonysághoz

Ajánlás Előny
Konfigurálja a napló lekérdezéseinek naplózását, és használja a Log Analytics-munkaterület megállapításokat a lassú és nem hatékony lekérdezések azonosításához.

A napló lekérdezési naplózása tárolja az egyes lekérdezések futtatásához szükséges számítási időt és az eredmények visszaadásának időpontját. A Log Analytics-munkaterület-elemzések ezen adatok alapján listáznak potenciálisan nem hatékony lekérdezéseket a munkaterületen. Fontolja meg a lekérdezések újraírását a teljesítmény javítása érdekében. A napló lekérdezéseinek optimalizálásával kapcsolatos útmutatásért tekintse meg a Napló lekérdezéseinek optimalizálása az Azure Monitorban című témakört.		 Az optimalizált lekérdezések gyorsabb eredményeket adnak vissza, és kevesebb erőforrást használnak a háttérrendszeren, ami hatékonyabbá teszi az ezekre a lekérdezésekre támaszkodó folyamatokat is.
A Log Analytics-munkaterületek szolgáltatási korlátainak ismertetése.

Bizonyos nagy forgalmú implementációkban előfordulhat, hogy olyan szolgáltatási korlátokba ütközik, amelyek hatással vannak a teljesítményre, valamint a munkaterület vagy a számítási feladatok kialakítására. A lekérdezési API például korlátozza a lekérdezés által visszaadott rekordok és adatmennyiségek számát. A Logs Ingestion API korlátozza az egyes API-hívások méretét.

Az Azure Monitor- és Log Analytics-munkaterületek korlátainak és korlátainak teljes listáját az Azure Monitor szolgáltatáskorlátai című témakörben találja.		 A munkaterület teljesítményét esetlegesen befolyásoló korlátok megismerése segít a megfelelő tervezésben azok mérséklése érdekében. Dönthet úgy, hogy több munkaterületet használ az egyetlen munkaterülethez társított korlátok elérésének elkerülése érdekében.

Mérlegelje a tervezési döntéseket, hogy mérsékelje a szolgáltatási korlátokat más pillérek követelményeihez és céljaihoz.
Egy vagy több meghatározott megfigyelhetőségi hatókörön belül hozzon létre az adatforrástípusokra jellemző DCR-eket. Hozzon létre külön DCR-eket a teljesítményhez és eseményekhez a háttérfeldolgozás számítási kihasználtságának optimalizálásához. Ha különálló DCR-eket használ a teljesítményhez és az eseményekhez, az segít enyhíteni a háttérerőforrás-kimerülést. A teljesítményeseményeket egyesítő DCR-ek minden társított virtuális gépet arra kényszerítenek, hogy olyan konfigurációkat helyezzenek át, dolgozzanak fel és futtassanak, amelyek esetleg nem alkalmazhatók a telepített szoftvernek megfelelően. Előfordulhat, hogy a számítási erőforrások túlzott felhasználása és a konfiguráció feldolgozása során felmerülő hibák miatt az Azure Monitor-ügynök (AMA) nem válaszol.

Azure Policy és az Azure Advisor

Az Azure nem kínál sem szabályzatokat, sem Azure Advisor-javaslatokat a Log Analytics-munkaterületek teljesítményével kapcsolatban.

Következő lépés