AzureDiagnostics

存储使用 Azure 诊断模式的 Azure 服务的资源日志。 资源日志描述 Azure 资源的内部操作。

每个 Azure 服务的资源日志具有一组唯一的列。 AzureDiagnostics 表包含 Azure 服务最常用的列。 如果资源日志包含一列，但该列在 AzureDiagnostics 表中尚不存在，则会在第一次收集数据时添加该列。 如果达到 500 列的最大数量，则任何其他列的数据都会添加到动态列中。

使用特定资源模式的 Azure 服务会将数据存储在特定于该服务的表中，而不会使用 AzureDiagnostics 表。 有关差异的详细信息，请参阅 Azure 资源日志。 有关使用 Azure 诊断的服务，请参阅使用 Azure 诊断模式的资源。

与其他表不同的是，AzureDiagnostics 更容易超过日志分析工作区中任何表的 500 列限制，这是因为能够向该表发送数据的 Azure 资源种类繁多。 为确保数据不会因活动列数超过 500 列限制而丢失，AzureDiagnostics 列创建的处理方式与其他表有所不同。

每个工作区中的 AzureDiagnostics 表同样至少包含 200 列。 对于 2021 年 1 月 19 日之前创建的工作区，该表还包含在此日期之前已经存在的任何列。 当数据被发送到尚未就绪的列时：

• 如果当前工作区中 AzureDiagnostics 的列总数不超过 500，则会像创建其他表一样创建新列。
• 如果列的总数达到或超过 500，则多余的数据将作为属性添加到名为 AdditionalFields 的动态属性包列中。

为了说明这种行为，假设截至（部署日期），工作区中的 AzureDiagnostics 表如下所示：

向 AzureDiagnostics 发送数据的资源会在其数据中添加一个新维度，并将其称为 NewInfo1。 由于表中的列数仍少于 500 列，因此当包含新维度数据的事件首次发生时，就会在表中添加新的列：

可以通过简单的查询来返回这些新数据：

AzureDiagnostics | where NewInfo1_s == "xyz"

稍后，另一个资源会向 AzureDiagnostics 发送数据，添加名为 NewInfo2 和 NewInfo3 的新维度。 由于在此工作区中，表格的列数已达到 500 列，因此新数据将进入 AdditionalFields 列：

仍然可以查询这些数据，但必须使用 KQL 中的任何动态属性操作符从属性包中提取它们：

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

虽然应遵循查询最佳做法，如始终将时间作为查询中的第一个子句进行筛选，但在使用 AdditionalFields 时还应考虑一些其他建议：

• 在对数据执行进一步操作之前，必须对其进行强制转换。 例如，如果拥有一个名为 Perf1Sec_i 的列以及 AdditionalFields 中名为 Perf2Sec 的属性，并且想通过将这两个值相加来计算总性能，可以使用以下方法：AzureDiagnostics | extend TotalPerfSec = Perf1Sec_i + toint(AdditionalFields.Perf2Sec) | ....。
• 在编写任何复杂的逻辑之前，使用 where 子句尽可能减少数据量，以显著提高性能。 TimeGenerated 是一个应始终缩小到尽可能小的窗口的列。 在 AzureDiagnostics 的情况下，应在查询顶部使用 ResourceType 列围绕正在查询的资源类型添加额外的筛选器。
• 在查询大量数据时，有时对 AdditionalFields 整体进行筛选会比解析更为有效。 例如，对于大量数据，AzureDiagnostics | where AdditionalFields has "Perf2Sec" 通常比 AzureDiagnostics | where isnotnull(toint(AdditionalFields.Perf2Sec)) 更有效。

以下服务的资源日志使用 Azure 诊断模式，并会将数据发送到 Azure 诊断表。 有关此配置的详细信息，请参阅 Azure 资源日志。

以下服务的资源日志使用 Azure 诊断模式或特定资源模式，具体取决于诊断设置配置。 在使用特定资源模式时，这些资源不会向 AzureDiagnostics 表发送数据。 有关此配置的详细信息，请参阅 Azure 资源日志。