Szöveges adatok elemzése az Azure Monitor-naplókban

Az Azure Monitor által gyűjtött naplóadatok egy adott tulajdonságban több információt is tartalmaznak. Az adatok több tulajdonságba való elemzése megkönnyíti a lekérdezésekben való használatot. Gyakori példa egy egyéni napló , amely egy teljes naplóbejegyzést gyűjt össze több értékkel egyetlen tulajdonságban. Ha külön tulajdonságokat hoz létre a különböző értékekhez, mindegyikben kereshet és összesíthet.

Ez a cikk a naplóadatok Azure Monitorban való elemzésének különböző lehetőségeit ismerteti az adatok betöltésekor és lekérdezésben való lekérésekor, összehasonlítva az egyes adatok relatív előnyeit.

A szükséges engedélyek

• Az adatok gyűjtési időben történő elemzéséhez például a Log Analytics-közreműködő beépített szerepköre által biztosított engedélyekre van szükségMicrosoft.Insights/dataCollectionRuleAssociations/*.
• Az adatok lekérdezési időpontban történő elemzéséhez például a Log Analytics-olvasó beépített szerepköre által biztosított engedélyekre van szükségMicrosoft.OperationalInsights/workspaces/query/*/read.

Elemzési módszerek

Elemezheti az adatokat a betöltési időpontban, amikor az adatokat összegyűjtik, vagy amikor lekérdezéssel elemzi az adatokat. Minden stratégia egyedi előnyökkel rendelkezik.

Adatok elemzése a gyűjtési időpontban

Átalakításokkal elemezheti az adatokat a gyűjtési időpontban, és meghatározhatja, hogy mely oszlopokba küldje az elemezt adatokat.

Előnyök:

• Egyszerűbb az összegyűjtött adatok lekérdezése, mert nem kell elemzési parancsokat belefoglalnia a lekérdezésbe.
• Jobb lekérdezési teljesítmény, mert a lekérdezésnek nem kell elemzést végeznie.

Hátrányok:

• Előre meg kell határozni. A már összegyűjtött adatokat nem lehet belefoglalni.
• Ha módosítja az elemzési logikát, az csak az új adatokra vonatkozik.
• Növeli az adatgyűjtés késési idejét.
• A hibákat nehéz lehet kezelni.

Adatok elemzése lekérdezéskor

Amikor lekérdezéskor elemzi az adatokat, a lekérdezésbe belefoglalja a logikát az adatok több mezőbe való elemzéséhez. Maga a tényleges tábla nem módosul.

Előnyök:

• Minden olyan adatra vonatkozik, beleértve a már összegyűjtött adatokat is.
• A logika változásai azonnal alkalmazhatók az összes adatra.
• Rugalmas elemzési lehetőségek, beleértve bizonyos adatstruktúrák előre definiált logikáját.

Hátrányok:

• Összetettebb lekérdezéseket igényel. Ez a hátrány egy tábla szimulálására szolgáló függvényekkel csökkenthető.
• Több lekérdezésben kell replikálnia az elemzési logikát. Megoszthat néhány logikát a függvényeken keresztül.
• Többletterhelést okozhat, ha összetett logikát futtat nagyon nagy rekordhalmazokon (több milliárd rekordon).

Adatok elemzése az összegyűjtött adatok alapján

Az adatok összegyűjtése során történő elemzésével kapcsolatos további információkért tekintse meg az Azure Monitor átalakításának struktúráját. Ez a módszer egyéni tulajdonságokat hoz létre a táblában, amelyeket a lekérdezések bármely más tulajdonsághoz hasonlóan használhatnak.

Adatok elemzése lekérdezésben minták használatával

Ha az elemezni kívánt adatok rekordokat ismétlődő mintával azonosíthatók, a Kusto lekérdezésnyelv különböző operátorai segítségével kinyerheti az adott adatrészt egy vagy több új tulajdonságba.

Egyszerű szövegminták

A lekérdezés elemzési operátorával létrehozhat egy vagy több olyan egyéni tulajdonságot, amely kinyerhető egy sztringkifejezésből. Itt adhatja meg az azonosítandó mintát és a létrehozandó tulajdonságok nevét. Ez a módszer olyan adatok esetében hasznos, amelyek kulcs-érték sztringjeihez key=valuehasonló űrlapot tartalmaz.

Fontolja meg az alábbi formátumú adatokat tartalmazó egyéni naplót:

Time=2018-03-10 01:34:36 Event Code=207 Status=Success Message=Client 05a26a97-272a-4bc9-8f64-269d154b0e39 connected
Time=2018-03-10 01:33:33 Event Code=208 Status=Warning Message=Client ec53d95c-1c88-41ae-8174-92104212de5d disconnected
Time=2018-03-10 01:35:44 Event Code=209 Status=Success Message=Transaction 10d65890-b003-48f8-9cfc-9c74b51189c8 succeeded
Time=2018-03-10 01:38:22 Event Code=302 Status=Error Message=Application could not connect to database
Time=2018-03-10 01:31:34 Event Code=303 Status=Error Message=Application lost connection to database

Az alábbi lekérdezés ezeket az adatokat egyéni tulajdonságokba elemzi. A hozzáfűzendő project sor csak a számított tulajdonságokat adja vissza, nem RawDatapedig az egyéni napló teljes bejegyzését tartalmazó egyetlen tulajdonságot.

MyCustomLog_CL
| parse RawData with * "Time=" EventTime " Event Code=" Code " Status=" Status " Message=" Message
| project EventTime, Code, Status, Message

Ez a példa egy UPN felhasználónevét bontja ki a AzureActivity táblában.

AzureActivity
| parse  Caller with UPNUserPart "@" * 
| where UPNUserPart != "" //Remove non UPN callers (apps, SPNs, etc)
| distinct UPNUserPart, Caller

Reguláris kifejezések

Ha az adatok egy reguláris kifejezéssel azonosíthatók, az egyes értékek kinyeréséhez használhat reguláris kifejezéseket használó függvényeket . Az alábbi példa kivonat használatával bontja ki a mezőt a UPN rekordokbólAzureActivity, majd különböző felhasználókat ad vissza.

AzureActivity
| extend UPNUserPart = extract("([a-z.]*)@", 1, Caller) 
| distinct UPNUserPart, Caller

A nagy léptékű hatékony elemzés érdekében az Azure Monitor a Reguláris kifejezések re2 verzióját használja, amely hasonló, de nem azonos a többi reguláris kifejezésvariánssal. További információ: re2 kifejezés szintaxisa.

Tagolt adatok elemzése egy lekérdezésben

A tagolt adatok elválasztják a mezőket egy közös karakterrel, például egy CSV-fájl vesszőjével. A felosztási függvénnyel elemezheti az elhatárolt adatokat egy ön által megadott elválasztó használatával. Ezzel a módszerrel a kiterjesztő operátorral visszaadhatja az adatok összes mezőjét, vagy megadhatja a kimenetbe felvenni kívánt egyes mezőket.

Fontolja meg az alábbi CSV formátumú adatokat tartalmazó egyéni naplót:

2018-03-10 01:34:36, 207,Success,Client 05a26a97-272a-4bc9-8f64-269d154b0e39 connected
2018-03-10 01:33:33, 208,Warning,Client ec53d95c-1c88-41ae-8174-92104212de5d disconnected
2018-03-10 01:35:44, 209,Success,Transaction 10d65890-b003-48f8-9cfc-9c74b51189c8 succeeded
2018-03-10 01:38:22, 302,Error,Application could not connect to database
2018-03-10 01:31:34, 303,Error,Application lost connection to database

Az alábbi lekérdezés elemzi ezeket az adatokat, és két számított tulajdonsággal összesítené az adatokat. Az első sor sztringtömbre osztja a RawData tulajdonságot. A következő sorok mindegyike nevet ad az egyes tulajdonságoknak, és a függvények használatával hozzáadja őket a kimenethez, hogy a megfelelő adattípusra konvertálja őket.

MyCustomCSVLog_CL
| extend CSVFields  = split(RawData, ',')
| extend EventTime  = todatetime(CSVFields[0])
| extend Code       = toint(CSVFields[1]) 
| extend Status     = tostring(CSVFields[2]) 
| extend Message    = tostring(CSVFields[3]) 
| where getyear(EventTime) == 2018
| summarize count() by Status,Code

Előre definiált struktúrák elemzése egy lekérdezésben

Ha az adatok egy ismert struktúrában formázva lesznek, a Kusto lekérdezésnyelv egyik függvényét használhatja az előre definiált struktúrák elemzéséhez:

• JSON
• XML
• IPv4
• URL-cím
• URL-lekérdezés
• Elérési út
• Felhasználói ügynök
• Verziósztring

Az alábbi példa lekérdezés elemzi a Properties AzureActivity tábla JSON-ban strukturált mezőjét. Az eredményeket egy dinamikus, úgynevezett parsedProptulajdonságba menti, amely tartalmazza a JSON-ban szereplő egyedi elnevezett értéket. Ezek az értékek a lekérdezés eredményeinek szűrésére és összegzésére szolgálnak.

AzureActivity
| extend parsedProp = parse_json(Properties) 
| where parsedProp.isComplianceCheck == "True" 
| summarize count() by ResourceGroup, tostring(parsedProp.tags.businessowner)

Ezek az elemzési függvények processzorigényesek lehetnek. Csak akkor használja őket, ha a lekérdezés több tulajdonságot használ a formázott adatokból. Ellenkező esetben az egyszerű mintaegyeztetés gyorsabb feldolgozást eredményez.

Az alábbi példa a tartományvezérlő TGT Preauth típusának lebontását mutatja be. A típus csak a EventData mezőben létezik, amely egy XML-sztring. Nincs szükség más adatokra ebből a mezőből. Ebben az esetben az elemzés a szükséges adatrész kiválasztására szolgál.

SecurityEvent
| where EventID == 4768
| parse EventData with * 'PreAuthType">' PreAuthType '</Data>' * 
| summarize count() by PreAuthType

Tábla szimulálása függvény használatával

Előfordulhat, hogy több lekérdezés is rendelkezik, amelyek egy adott tábla azonos elemzését hajtják végre. Ebben az esetben hozzon létre egy függvényt, amely az elemzési adatokat adja vissza ahelyett, hogy az elemzési logikát replikálja az egyes lekérdezésekben. Ezután más lekérdezésekben az eredeti tábla helyett használhatja a függvény aliasát.

Vegye figyelembe az előző vessző által tagolt egyéni napló példát. Ha több lekérdezésben szeretné használni az elemzési adatokat, hozzon létre egy függvényt az alábbi lekérdezéssel, és mentse az aliassal MyCustomCSVLog.

MyCustomCSVLog_CL
| extend CSVFields = split(RawData, ',')
| extend DateTime  = tostring(CSVFields[0])
| extend Code      = toint(CSVFields[1]) 
| extend Status    = tostring(CSVFields[2]) 
| extend Message   = tostring(CSVFields[3]) 

Most már használhatja az aliast MyCustomCSVLog a tényleges táblanév helyett a lekérdezésekben, például az alábbi példában:

MyCustomCSVLog
| summarize count() by Status,Code

Következő lépések

Megismerheti a napló lekérdezéseket az adatforrásokból és megoldásokból gyűjtött adatok elemzéséhez.