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

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

  • Cikk

Az Azure Monitor által gyűjtött naplóadatok egy tulajdonságban több információt is tartalmaznak. Az adatok több tulajdonságba való elemzése megkönnyíti a lekérdezések használatát. Gyakori példa egy egyéni napló , amely egy teljes naplóbejegyzést gyűjt több értékkel egyetlen tulajdonságba. 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

Elemzési módszerek

Elemezheti az adatokat a betöltéskor, 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őnye:

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

Hátrányai:

  • 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 lesz érvényes.
  • 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 olyan logikát is belefoglal, amely több mezőbe elemzi az adatokat. Maga a tényleges tábla nincs módosítva.

Előnye:

  • Minden 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 az adott adatstruktúrák előre definiált logikáját.

Hátrányai:

  • Összetettebb lekérdezéseket igényel. Ez a hátrány a táblák szimulálására szolgáló függvények használatával 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 gyűjtése során történő elemzésével kapcsolatos további információkért lásd: Átalakítás struktúrája az Azure Monitorban. 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ésekben minták használatával

Ha az elemezni kívánt adatok rekordonként 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 kulcs-érték sztringekkel rendelkező adatok esetében hasznos, amelyek űrlapja hasonló a következőhöz key=value: .

Fontolja meg a következő 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 elemezné. A sor hozzá project van adva, hogy csak a számított tulajdonságokat adja vissza, nem RawDatapedig a értéket, amely az egyéni napló teljes bejegyzését tartalmazó egyetlen tulajdonság.

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

Ez a példa egy egyszerű felhasználónév 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ól AzureActivity , 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 közös karakterrel rendelkező mezőket, például a CSV-fájlok vesszőit. A felosztási függvénnyel a megadott elválasztó használatával elemezheti a tagolt adatokat. Ezzel a megközelítéssel a extend operátorral az adatok összes mezőjét visszaadhatja, vagy megadhatja a kimenetbe felvenni kívánt egyes mezőket.

Megjegyzés

Mivel a felosztás dinamikus objektumot ad vissza, előfordulhat, hogy az eredményeket explicit módon adattípusokra kell leadni, például az operátorokban és szűrőkben használandó sztringre.

Fontolja meg a következő 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

A következő lekérdezés elemzi ezeket az adatokat, és két számított tulajdonsággal összegzi az adatokat. Az első sor a RawData tulajdonságot sztringtömbre osztja. A következő sorok mindegyike nevet ad az egyes tulajdonságoknak, és 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 jelennek meg, a Kusto lekérdezésnyelv egyik függvényét használhatja az előre definiált struktúrák elemzéséhez:

Az alábbi példa lekérdezés elemzi a PropertiesAzureActivity tábla JSON-ban strukturált mezőjét. Az eredményeket egy nevű dinamikus tulajdonságba parsedPropmenti, amely magában foglalja 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. Ehhez a mezőhöz nincs szükség más adatokra. 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éssel is rendelkezik, amelyek egy adott tábla ugyanazt az elemzést hajtják végre. Ebben az esetben hozzon létre egy függvényt , amely az elemezt adatokat adja vissza ahelyett, hogy az elemzési logikát replikálja az egyes lekérdezésekben. Ezután használhatja a függvény aliasát az eredeti tábla helyett más lekérdezésekben.

Vegyük az előző vesszőből tagolt egyéni napló példát. Ha több lekérdezésben szeretné használni az elemezt 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

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