Analizowanie danych tekstowych w dziennikach usługi Azure Monitor

Niektóre dane dziennika zebrane przez usługę Azure Monitor będą zawierać wiele informacji w jednej właściwości. Analizowanie tych danych w wielu właściwościach ułatwia korzystanie z zapytań. Typowym przykładem jest dziennik niestandardowy, który zbiera cały wpis dziennika z wieloma wartościami w jednej właściwości. Tworząc oddzielne właściwości dla różnych wartości, można wyszukiwać i agregować na każdym z nich.

W tym artykule opisano różne opcje analizowania danych dziennika w usłudze Azure Monitor, gdy dane są pozyskiwane i kiedy są pobierane w zapytaniu, porównując względne korzyści dla każdego z nich.

Wymagane uprawnienia

• Aby analizować dane w czasie zbierania, potrzebne są Microsoft.Insights/dataCollectionRuleAssociations/* na przykład uprawnienia udostępniane przez wbudowaną rolę Współautor usługi Log Analytics.
• Aby analizować dane w czasie wykonywania zapytań, potrzebujesz Microsoft.OperationalInsights/workspaces/query/*/read uprawnień udostępnionych przez wbudowaną rolę czytelnika usługi Log Analytics, na przykład.

Metody analizowania

Dane można analizować w czasie pozyskiwania, gdy dane są zbierane lub w czasie wykonywania zapytań podczas analizowania danych za pomocą zapytania. Każda strategia ma unikatowe zalety.

Analizowanie danych w czasie zbierania

Użyj przekształceń , aby przeanalizować dane w czasie zbierania i zdefiniować kolumny, do których mają być wysyłane przeanalizowane dane.

Zalety:

• Łatwiejsze wykonywanie zapytań dotyczących zebranych danych, ponieważ nie trzeba uwzględniać poleceń analizy w zapytaniu.
• Lepsza wydajność zapytań, ponieważ zapytanie nie musi wykonywać analizy.

Wady:

• Należy zdefiniować z wyprzedzeniem. Nie można uwzględnić danych, które zostały już zebrane.
• Jeśli zmienisz logikę analizowania, będzie ona stosowana tylko do nowych danych.
• Zwiększa czas opóźnienia zbierania danych.
• Błędy mogą być trudne do obsługi.

Analizowanie danych w czasie wykonywania zapytania

Podczas analizowania danych w czasie wykonywania zapytań należy uwzględnić logikę w zapytaniu, aby przeanalizować dane w wielu polach. Rzeczywista tabela nie jest modyfikowana.

Zalety:

• Dotyczy wszystkich danych, w tym danych, które zostały już zebrane.
• Zmiany w logice można stosować natychmiast do wszystkich danych.
• Elastyczne opcje analizowania, w tym wstępnie zdefiniowana logika dla określonych struktur danych.

Wady:

• Wymaga bardziej złożonych zapytań. Tę wadę można wyeliminować za pomocą funkcji do symulowania tabeli.
• Musi replikować logikę analizowania w wielu zapytaniach. Może udostępniać logikę za pośrednictwem funkcji.
• Może tworzyć obciążenia podczas uruchamiania złożonej logiki względem bardzo dużych zestawów rekordów (miliardów rekordów).

Analizowanie danych podczas ich zbierania

Aby uzyskać więcej informacji na temat analizowania danych podczas ich zbierania, zobacz Struktura transformacji w usłudze Azure Monitor. To podejście tworzy właściwości niestandardowe w tabeli, które mogą być używane przez zapytania, takie jak każda inna właściwość.

Analizowanie danych w zapytaniu przy użyciu wzorców

Gdy dane, które chcesz przeanalizować, mogą być identyfikowane przez wzorzec powtarzany w rekordach, można użyć różnych operatorów w język zapytań Kusto, aby wyodrębnić konkretny fragment danych do co najmniej jednej nowej właściwości.

Proste wzorce tekstu

Użyj operatora analizy w zapytaniu, aby utworzyć co najmniej jedną niestandardową właściwości, którą można wyodrębnić z wyrażenia ciągu. Należy określić wzorzec, który ma zostać zidentyfikowany, oraz nazwy właściwości do utworzenia. Takie podejście jest przydatne w przypadku danych z ciągami klucz-wartość z formularzem podobnym do key=value.

Rozważ dziennik niestandardowy z danymi w następującym formacie:

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

Poniższe zapytanie analizuje te dane w poszczególnych właściwościach. Wiersz z project jest dodawany w celu zwrócenia tylko właściwości obliczeniowych, a nie RawData, która jest pojedynczą właściwością, która zawiera cały wpis z dziennika niestandardowego.

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

W tym przykładzie przedstawiono nazwę użytkownika nazwy UPN w AzureActivity tabeli.

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

Wyrażenia regularne

Jeśli dane można zidentyfikować za pomocą wyrażenia regularnego, możesz użyć funkcji, które używają wyrażeń regularnych do wyodrębniania poszczególnych wartości. W poniższym przykładzie użyto wyodrębnienia w celu podzielenia UPN pola z AzureActivity rekordów, a następnie zwrócenia unikatowych użytkowników.

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

Aby umożliwić wydajne analizowanie na dużą skalę, usługa Azure Monitor używa re2 wersji wyrażeń regularnych, która jest podobna, ale nie identyczna z niektórymi innymi wariantami wyrażeń regularnych. Aby uzyskać więcej informacji, zobacz składnię wyrażeń re2.

Analizowanie rozdzielonych danych w zapytaniu

Rozdzielane dane oddziela pola wspólnym znakiem, na przykład przecinkami w pliku CSV. Użyj funkcji split, aby przeanalizować rozdzielane dane przy użyciu określonego ogranicznika. Można użyć tego podejścia z operatorem rozszerzania , aby zwrócić wszystkie pola w danych lub określić poszczególne pola, które mają zostać uwzględnione w danych wyjściowych.

Uwaga

Ponieważ podział zwraca obiekt dynamiczny, może być konieczne jawne rzutowanie wyników na typy danych, takie jak ciąg do użycia w operatorach i filtrach.

Rozważ dziennik niestandardowy z danymi w następującym formacie CSV:

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

Poniższe zapytanie przeanalizuje te dane i podsumuje dwa właściwości obliczeniowe. Pierwszy wiersz dzieli RawData właściwość na tablicę ciągów. Każdy z następnych wierszy nadaje nazwę poszczególnym właściwościom i dodaje je do danych wyjściowych przy użyciu funkcji w celu przekonwertowania ich na odpowiedni typ danych.

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

Analizowanie wstępnie zdefiniowanych struktur w zapytaniu

Jeśli dane są sformatowane w znanej strukturze, możesz użyć jednej z funkcji w język zapytań Kusto do analizowania wstępnie zdefiniowanych struktur:

• JSON
• XML
• Protokół IPv4
• Adres URL
• Kwerenda adresu URL
• Ścieżka pliku
• Agent użytkownika
• Ciąg wersji

Poniższe przykładowe zapytanie analizuje pole AzureActivity tabeli, która jest ustrukturyzowana Properties w formacie JSON. Zapisuje wyniki we właściwości dynamicznej o nazwie parsedProp, która zawiera pojedynczą nazwaną wartość w formacie JSON. Te wartości są używane do filtrowania i podsumowywania wyników zapytania.

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

Te funkcje analizowania mogą być intensywnie korzystające z procesora. Używaj ich tylko wtedy, gdy zapytanie używa wielu właściwości z sformatowanych danych. W przeciwnym razie proste przetwarzanie dopasowywania wzorców jest szybsze.

W poniższym przykładzie przedstawiono podział typu kontrolera TGT Preauth domeny. Typ istnieje tylko w EventData polu, który jest ciągiem XML. Żadne inne dane z tego pola nie są potrzebne. W tym przypadku analiza jest używana do wybierania wymaganego elementu danych.

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

Symulowanie tabeli przy użyciu funkcji

Może istnieć wiele zapytań, które wykonują te same analizowanie określonej tabeli. W takim przypadku utwórz funkcję zwracającą przeanalizowane dane zamiast replikować logikę analizowania w każdym zapytaniu. Następnie można użyć aliasu funkcji zamiast oryginalnej tabeli w innych zapytaniach.

Rozważmy powyższy przykład dziennika niestandardowego rozdzielanego przecinkami. Aby użyć analizowanych danych w wielu zapytaniach, utwórz funkcję przy użyciu następującego zapytania i zapisz je za pomocą aliasu 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]) 

Teraz możesz użyć aliasu MyCustomCSVLog zamiast rzeczywistej nazwy tabeli w zapytaniach, takich jak w poniższym przykładzie:

MyCustomCSVLog
| summarize count() by Status,Code

Następne kroki

Dowiedz się więcej o zapytaniach dzienników w celu analizowania danych zebranych ze źródeł danych i rozwiązań.