Tekstgegevens parseren in Azure Monitor-logboeken

  • Artikel

Sommige logboekgegevens die door Azure Monitor worden verzameld, bevatten meerdere gegevens in één eigenschap. Door deze gegevens in meerdere eigenschappen te parseren, is deze eenvoudiger te gebruiken in query's. Een veelvoorkomend voorbeeld is een aangepast logboek waarmee een volledige logboekvermelding met meerdere waarden in één eigenschap wordt verzameld. Door afzonderlijke eigenschappen voor de verschillende waarden te maken, kunt u op elke waarde zoeken en aggregeren.

In dit artikel worden verschillende opties beschreven voor het parseren van logboekgegevens in Azure Monitor wanneer de gegevens worden opgenomen en wanneer deze worden opgehaald in een query, waarbij de relatieve voordelen voor elk van beide worden vergeleken.

Machtigingen vereist

  • Als u gegevens tijdens het verzamelen wilt parseren, hebt u machtigingen nodig Microsoft.Insights/dataCollectionRuleAssociations/* , zoals bijvoorbeeld de ingebouwde rol Inzender voor Log Analytics.
  • Als u gegevens tijdens query's wilt parseren, hebt u machtigingen nodig Microsoft.OperationalInsights/workspaces/query/*/read , zoals opgegeven door de ingebouwde rol Log Analytics-lezer.

Parseringsmethoden

U kunt gegevens parseren op het moment van opname wanneer de gegevens worden verzameld of tijdens de query wanneer u de gegevens met een query analyseert. Elke strategie heeft unieke voordelen.

Gegevens parseren tijdens het verzamelen

Gebruik transformaties om gegevens tijdens het verzamelen te parseren en te definiëren naar welke kolommen de geparseerde gegevens moeten worden verzonden.

Voordelen:

  • U kunt eenvoudiger query's uitvoeren op de verzamelde gegevens omdat u geen parseeropdrachten in de query hoeft op te nemen.
  • Betere queryprestaties omdat de query geen parsering hoeft uit te voeren.

Nadelen:

  • Moet vooraf worden gedefinieerd. Kan geen gegevens bevatten die al zijn verzameld.
  • Als u de parseringslogica wijzigt, is deze alleen van toepassing op nieuwe gegevens.
  • Verhoogt de latentietijd voor het verzamelen van gegevens.
  • Fouten kunnen moeilijk te verwerken zijn.

Gegevens parseren tijdens querytijd

Wanneer u gegevens tijdens query's parseert, neemt u logica op in uw query om gegevens in meerdere velden te parseren. De werkelijke tabel zelf wordt niet gewijzigd.

Voordelen:

  • Is van toepassing op alle gegevens, inclusief gegevens die al zijn verzameld.
  • Wijzigingen in logica kunnen onmiddellijk worden toegepast op alle gegevens.
  • Flexibele parseringsopties, inclusief vooraf gedefinieerde logica voor bepaalde gegevensstructuren.

Nadelen:

  • Vereist complexere query's. Dit nadeel kan worden verzacht door functies te gebruiken om een tabel te simuleren.
  • De parseringslogica moet in meerdere query's worden gerepliceerd. Kan bepaalde logica delen via functies.
  • Kan overhead creëren wanneer u complexe logica uitvoert voor zeer grote recordsets (miljarden records).

Gegevens parseren terwijl deze worden verzameld

Zie Structuur van transformatie in Azure Monitor voor meer informatie over het parseren van gegevens terwijl deze worden verzameld. Met deze benadering worden aangepaste eigenschappen in de tabel gemaakt die kunnen worden gebruikt door query's zoals elke andere eigenschap.

Gegevens in een query parseren met behulp van patronen

Wanneer de gegevens die u wilt parseren, kunnen worden geïdentificeerd aan de hand van een patroon dat in records wordt herhaald, kunt u verschillende operatoren in de Kusto-querytaal gebruiken om het specifieke stukje gegevens op te halen in een of meer nieuwe eigenschappen.

Eenvoudige tekstpatronen

Gebruik de parseeroperator in uw query om een of meer aangepaste eigenschappen te maken die kunnen worden geëxtraheerd uit een tekenreeksexpressie. U geeft het patroon op dat moet worden geïdentificeerd en de namen van de eigenschappen die moeten worden gemaakt. Deze benadering is handig voor gegevens met sleutel-waardetekenreeksen met een formulier dat key=valuevergelijkbaar is met .

Overweeg een aangepast logboek met gegevens in de volgende indeling:

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

Met de volgende query worden deze gegevens geparseerd in afzonderlijke eigenschappen. De regel met project wordt toegevoegd om alleen de berekende eigenschappen te retourneren en niet RawData. Dit is de enige eigenschap die de volledige vermelding uit het aangepaste logboek bevat.

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

In dit voorbeeld wordt de gebruikersnaam van een UPN in de tabel uitgesplitsd AzureActivity .

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

Reguliere expressies

Als uw gegevens kunnen worden geïdentificeerd met een reguliere expressie, kunt u functies gebruiken die gebruikmaken van reguliere expressies om afzonderlijke waarden te extraheren. In het volgende voorbeeld wordt extraheren gebruikt om het UPN veld op te splitsen uit AzureActivity records en vervolgens afzonderlijke gebruikers te retourneren.

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

Om efficiënt parseren op grote schaal mogelijk te maken, gebruikt Azure Monitor de re2-versie van Reguliere expressies, die vergelijkbaar is, maar niet identiek is aan sommige van de andere reguliere expressievarianten. Zie de syntaxis van de re2-expressie voor meer informatie.

Door scheidingstekens gescheiden gegevens in een query parseren

Met gegevens met scheidingstekens worden velden gescheiden met een gemeenschappelijk teken, zoals een komma in een CSV-bestand. Gebruik de splitsfunctie om gegevens met scheidingstekens te parseren met behulp van een scheidingsteken dat u opgeeft. U kunt deze benadering met de operator uitbreiden gebruiken om alle velden in de gegevens te retourneren of om afzonderlijke velden op te geven die moeten worden opgenomen in de uitvoer.

Notitie

Omdat splitsen een dynamisch object retourneert, moeten de resultaten mogelijk expliciet worden gecast naar gegevenstypen, zoals tekenreeksen die moeten worden gebruikt in operators en filters.

Overweeg een aangepast logboek met gegevens in de volgende CSV-indeling:

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

Met de volgende query worden deze gegevens geparseerd en samengevat met twee van de berekende eigenschappen. De eerste regel splitst de RawData eigenschap in een tekenreeksmatrix. Elk van de volgende regels geeft een naam aan afzonderlijke eigenschappen en voegt deze toe aan de uitvoer door functies te gebruiken om ze te converteren naar het juiste gegevenstype.

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

Vooraf gedefinieerde structuren in een query parseren

Als uw gegevens zijn opgemaakt in een bekende structuur, kunt u mogelijk een van de functies in de Kusto-querytaal gebruiken voor het parseren van vooraf gedefinieerde structuren:

Met de volgende voorbeeldquery wordt het Properties veld van de AzureActivity tabel geparseerd, dat is gestructureerd in JSON. De resultaten worden opgeslagen in een dynamische eigenschap met de naam parsedProp, die de afzonderlijke benoemde waarde in de JSON bevat. Deze waarden worden gebruikt om de queryresultaten te filteren en samen te vatten.

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

Deze parseringsfuncties kunnen processorintensief zijn. Gebruik deze alleen wanneer uw query meerdere eigenschappen van de opgemaakte gegevens gebruikt. Anders is de verwerking van eenvoudige patroonovereenkomst sneller.

In het volgende voorbeeld ziet u de uitsplitsing van het type domeincontroller TGT Preauth . Het type bestaat alleen in het EventData veld, een XML-tekenreeks. Er zijn geen andere gegevens uit dit veld nodig. In dit geval wordt parse gebruikt om het vereiste stukje gegevens te selecteren.

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

Een functie gebruiken om een tabel te simuleren

Mogelijk hebt u meerdere query's die dezelfde parsering van een bepaalde tabel uitvoeren. In dit geval maakt u een functie die de geparseerde gegevens retourneert in plaats van de parseringslogica in elke query te repliceren. Vervolgens kunt u de functiealias gebruiken in plaats van de oorspronkelijke tabel in andere query's.

Bekijk het voorgaande voorbeeld van een door komma's gescheiden aangepast logboek. Als u de geparseerde gegevens in meerdere query's wilt gebruiken, maakt u een functie met behulp van de volgende query en slaat u deze op met de alias 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])

U kunt nu de alias MyCustomCSVLog gebruiken in plaats van de werkelijke tabelnaam in query's, zoals in het volgende voorbeeld:

MyCustomCSVLog
| summarize count() by Status,Code

Volgende stappen

Meer informatie over logboekquery's voor het analyseren van de gegevens die zijn verzameld uit gegevensbronnen en oplossingen.