AzureDiagnostics

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 don't use the AzureDiagnostics table. See Azure resource logs for details on the differences. See Resources using Azure Diagnostics mode for the services that use Azure Diagnostics.

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 contains any columns that were already in place before 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 doesn't 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 workspace looks as follows:

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

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:

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 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 typecast data before performing further operations on it. For example, if you have a column called Perf1Sec_i and a property in AdditionalFields called Perf2Sec, and you want to calculate total perf by adding both values, you can use the following: AzureDiagnostics | extend TotalPerfSec = Perf1Sec_i + toint(AdditionalFields.Perf2Sec) | .....
• Use where clauses to reduce the data volume to the smallest possible before 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 always be included at the top of the query around the resource types that are being queried using the ResourceType column.
• When querying large volumes of data, it's 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)).

Resources using Azure Diagnostics mode

The following services use Azure diagnostics mode for their resource logs and send data to the Azure Diagnostics table. See Azure resource logs for details on this configuration.

Azure Diagnostics mode or resource-specific mode

The following services use either Azure diagnostics mode or resource-specific mode for their resource logs depending on the diagnostics settings configuration. When using resource-specific mode, these resources don't send data to the AzureDiagnostics table. See Azure resource logs for details on this configuration.

AzureDiagnostics table columns