AzureDiagnostics

Artikel
10/15/2024

Lagrar resursloggar för Azure-tjänster som använder Azure Diagnostics-läge. Resursloggar beskriver den interna driften av Azure-resurser.

Resursloggen för varje enskild Azure-tjänst har en unik uppsättning kolumner. Tabellen AzureDiagnostics innehåller de vanligaste kolumnerna som används av Azure-tjänster. Om en resurslogg innehåller en kolumn som inte redan finns i tabellen AzureDiagnostics läggs den kolumnen till första gången data samlas in. Om det maximala antalet på 500 kolumner uppnås läggs data för ytterligare kolumner till i en dynamisk kolumn.

Azure-tjänster som använder resursspecifikt läge lagrar data i en tabell som är specifik för tjänsten och inte använder Tabellen AzureDiagnostics. Se Resurstyper nedan för de tjänster som använder varje metod. Mer information om skillnaderna finns i Azure-resursloggar.

Kommentar

Tabellen AzureDiagnostics är en anpassad loggtabell som skapats exklusivt av Azure Monitor-pipelinen första gången en Azure-resurs börjar skicka loggar i Azure Diagnostics-läge. Till skillnad från andra tabeller kan inte AzureDiagnostics-tabellen skapas via en ARM-mall eller ett API för tabeller. Därför går det inte att ändra tabellens standardvärden för kvarhållning innan den skapas.

Kolumnen AdditionalFields

Till skillnad från andra tabeller är AzureDiagnostics mycket mer känsligt för att överskrida den 500 kolumngräns som införts för en tabell på en Log Analytics-arbetsyta på grund av det breda utbudet av Azure-resurser som kan skicka data till den här tabellen. För att säkerställa att inga data går förlorade på grund av att antalet aktiva kolumner överskrider den här kolumngränsen på 500 hanteras skapande av AzureDiagnostics-kolumner på ett annat sätt än andra tabeller.

AzureDiagnostics-tabellen på varje arbetsyta innehåller minst samma 200 kolumner. För arbetsytor som skapades före den 19 januari 2021 innehåller tabellen även alla kolumner som redan fanns före detta datum. När data skickas till en kolumn som inte redan finns:

Om det totala antalet kolumner i AzureDiagnostics på den aktuella arbetsytan inte överstiger 500 skapas en ny kolumn precis som med andra tabeller.
Om det totala antalet kolumner är på eller över 500 läggs överskottsdata till i en dynamisk egenskapsuppsättningskolumn med namnet AdditionalFields som egenskap.

Exempel

För att illustrera det här beteendet kan du tänka dig att från och med (distributionsdatum) ser AzureDiagnostics-tabellen i vårt workpsace ut på följande sätt:

Kolumn 1	Kolumn 2	Kolumn 3	...	Kolumn 498
abc	def	123	...	456
...	...	...	...	...

En resurs som skickar data till AzureDiagnostics lägger sedan till en ny dimension till sina data som de kallar NewInfo1. Eftersom tabellen fortfarande har färre än 500 kolumner lägger första gången en händelse inträffar som innehåller data för den nya dimensionen till en ny kolumn i tabellen:

Kolumn 1	Kolumn 2	Kolumn 3	...	Kolumn 498	NewInfo1_s
abc	def	123	...	456	xyz
...	...	...	...	...	...

Du kan returnera dessa nya data i en enkel fråga:

AzureDiagnostics | where NewInfo1_s == "xyz"

Vid ett senare tillfälle skickar en annan resurs data till AzureDiagnostics som lägger till nya dimensioner som kallas NewInfo2 och NewInfo3. Eftersom tabellen har nått 500 kolumner på den här arbetsytan hamnar de nya data i kolumnen AdditionalFields :

Kolumn 1	Kolumn 2	Kolumn 3	...	Kolumn 498	NewInfo1_s	AdditionalFields
abc	def	123	...	456	xyz	{"NewInfo2":"789","NewInfo3":"qwerty"}
...	...	...	...	...	...	...

Du kan fortfarande fråga efter dessa data, men du måste extrahera dem från egenskapsuppsättningen med någon av de dynamiska egenskapsoperatorerna i KQL:

AzureDiagnostics
| where AdditionalFields.NewInfo2 == "789" and AdditionalFields.NewInfo3 == "qwerty"

Tips om hur du `AdditionalFields` använder kolumnen

Även om allmänna metodtips för frågor, till exempel att alltid filtrera efter tid som den första satsen i frågan, bör följas, finns det några andra rekommendationer som du bör överväga när du arbetar med AdditionalFields:

Du måste typecast-data innan du utför ytterligare åtgärder på den. Om det till exempel finns en kolumn med namnet Perf1Sec_i samt en egenskap i AdditionalFields med namnet Perf2Sec, och du vill beräkna total perf genom att lägga till båda värdena, använder du något som: AzureDiagnostics | extend TotalPerfSec = Perf1Sec_i + toint(AdditionalFields.Perf2Sec) | .... .
Använd where-satser för att minska datavolymen så mycket som möjligt innan du skriver någon komplex logik för att avsevärt förbättra prestandan. TimeGenerated är en kolumn som alltid bör reduceras till minsta möjliga fönster. När det gäller AzureDiagnostics bör ytterligare ett filter alltid inkluderas överst i frågan kring de resurstyper som efterfrågas med hjälp av kolumnen ResourceType .
När du kör frågor mot mycket stora datavolymer är det ibland mer effektivt att göra ett filter på AdditionalFields som helhet i stället för att parsa dem. För stora datavolymer AzureDiagnostics | where AdditionalFields has "Perf2Sec" är det till exempel ofta effektivare än AzureDiagnostics | where isnotnull(toint(AdditionalFields.Perf2Sec)).