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.
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 will contain at a minimum the same 200 columns. For workspaces created before January 19, 2021, the table will 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 will be 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.
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|
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 will add a new column to the table:
|Column 1||Column 2||Column 3||...||Column 498||NewInfo1_s|
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 will go into the AdditionalFields column:
|Column 1||Column 2||Column 3||...||Column 498||NewInfo1_s||AdditionalFields|
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 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 will need 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)).
- Azure Resources
Azure Diagnostics mode
The following services use Azure diagnostics mode for their resource logs and send data to the Azure Diagnostics table.
- Analysis Services
- Application Gateways
- Automation Accounts
- Azure Database for MariaDB servers
- Azure Database for MySQL servers
- Azure Database for PostgreSQL servers
- Azure Database for PostgreSQL servers v2
- Batch accounts
- CDN profiles
- Cognitive Services
- Data Lake Analytics
- DataLake Storage Gen1
- Device Provisioning Services
- Digital Twins
- Event Grid Topics
- Event Hubs
- ExpressRoute circuits
- Front Doors
- Integration accounts
- Key Vault
- Kubernetes services
- Load balancers
- Logic Apps
- Media services
- Network interfaces
- Network Security Groups
- P2S VPN Gateways
- Power BI Embedded
- Public IP addresses
- Recovery Services vaults(Site Recovery)
- Search services
- Service Bus
- SQL databases
- SQL managed Instances
- SQL servers
- Stream Analytics jobs
- Traffic Manager profiles
- Virtual networks
- Virtual network gateways
- VPN Gateways
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 their configuration. When they use resource-specific mode, they do not send data to the AzureDiagnostics table. See Azure resource logs for details on this configuration.
- API Management Services
- Cosmos DB
- Data factories (V2)
- IoT Hub
- Recovery Services vaults(Backup)
|_ResourceId||String||A unique identifier for the resource that the record is associated with|