AzureDiagnostics

Article
11/01/2024

Stores resource logs for Azure services that use Azure Diagnostics mode. Resource logs describe the internal operation of Azure resources.

The resource log for each Azure service has a unique set of columns. The AzureDiagnostics table includes the most common columns used by Azure services. If a resource log includes a column that doesn't already exist in the AzureDiagnostics table, that column is added the first time that data is collected. If the maximum number of 500 columns is reached, data for any additional columns is added to a dynamic column.

Azure services that use resource-specific mode store data in a table specific to that service and do not use the AzureDiagnostics table. See Resource Types below for the services that use each method. See Azure resource logs for details on the differences.

Note

The AzureDiagnostics table is a custom log table created exclusively by the Azure Monitor pipeline the first time an Azure resource begins sending logs in Azure Diagnostics mode. Unlike other tables, the AzureDiagnostics table can't be created via an ARM template or tables API. Consequently, it's not possible to modifying the table's default retention values before its creation.

AdditionalFields column

Unlike other tables, AzureDiagnostics is much more susceptible to exceeding the 500 column limit imposed for any table in a Log Analytics workspace due to the wide assortment of Azure Resources capable of sending data to this table. To ensure that no data is lost due to the number of active columns exceeding this 500 column limit, AzureDiagnostics column creation is handled in a different manner to other tables.

The AzureDiagnostics table in every workspace contains at a minimum, the same 200 columns. For workspaces created before January 19, 2021, the table also contain any columns that were already in place prior to this date. When data is sent to a column not already in place:

If the total number of columns in AzureDiagnostics in the current workspace does not exceed 500, a new column is created just like with any other table.
If the total number of columns is at or above 500, the excess data is added to a dynamic property bag column called AdditionalFields as a property.

Example

To illustrate this behavior, imagine that as of (deployment date) the AzureDiagnostics table in our workpsace looks as follows:

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

A resource that sends data to AzureDiagnostics then adds a new dimension to their data that they call NewInfo1. Since the table still has less than 500 columns, the first time an event occurs that contains data for this new dimension adds a new column to the table:

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

You can return this new data in a simple query:

AzureDiagnostics | where NewInfo1_s == "xyz"

At a later date, another resource sends data to AzureDiagnostics that adds new dimensions called NewInfo2 and NewInfo3. Because the table has reached 500 columns in this workspace, the new data goes into the AdditionalFields column:

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

You can still query for this data,but you must extract it from the property bag using any of the dynamic property operators in KQL:

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

Tips on using the `AdditionalFields` column

While general query best practices such as always filtering by time as the first clause in the query should be followed, there are some other recommendations you should consider when working with AdditionalFields:

You must to typecast data prior to performing further operations on it. For example, if a column exists called Perf1Sec_i as well as a property in AdditionalFields called Perf2Sec, and you want to calculate total perf by adding both values, use something like: AzureDiagnostics | extend TotalPerfSec = Perf1Sec_i + toint(AdditionalFields.Perf2Sec) | .....
Use where clauses to reduce the data volume to the smallest possible prior to writing any complex logic to significantly improve performance. TimeGenerated is one column that should always be reduced to the smallest possible window. In the case of AzureDiagnostics, an additional filter should also always be included at the top of the query around the resource types that are being queried using the ResourceType column.
When querying very large volumes of data, it is sometimes more efficient to do a filter on AdditionalFields as a whole rather than parsing it. For example, for large volumes of data AzureDiagnostics | where AdditionalFields has "Perf2Sec" is often more efficient than AzureDiagnostics | where isnotnull(toint(AdditionalFields.Perf2Sec)).