在 Azure Monitor 中执行跨资源日志查询Perform cross-resource log queries in Azure Monitor

以前,使用 Azure Monitor 只能分析来自当前工作区内的数据,这限制了跨订阅中定义的多个工作区查询数据的能力。Previously with Azure Monitor, you could only analyze data from within the current workspace, and it limited your ability to query across multiple workspaces defined in your subscription. 此外,之前只能直接在 Application Insights 中或从 Visual Studio 中使用 Application Insights 搜索通过基于 web 的应用程序收集的遥测数据项。Additionally, you could only search telemetry items collected from your web-based application with Application Insights directly in Application Insights or from Visual Studio. 这还使得难以采用本机方式将操作数据和应用程序数据一起分析。This also made it a challenge to natively analyze operational and application data together.

现在不但可以跨多个 Log Analytics 工作区进行查询,而且还可以查询同一资源组、另一资源组或另一订阅中特定 Application Insights 应用的数据。Now you can query not only across multiple Log Analytics workspaces, but also data from a specific Application Insights app in the same resource group, another resource group, or another subscription. 这可以提供数据的系统级视图。This provides you with a system-wide view of your data. 你只能在 Log Analytics 中执行这些类型的查询。You can only perform these types of queries in Log Analytics.

跨资源查询限制Cross-resource query limits

  • 可以在单个查询中包含的 Application Insights 资源和 Log Analytics 工作区的数量限制为 100。The number of Application Insights resources and Log Analytics workspaces that you can include in a single query is limited to 100.
  • 视图设计器不支持跨资源查询。Cross-resource query is not supported in View Designer. 可以在 Log Analytics 中创作一个查询,将其固定到 Azure 仪表板,以将日志查询可视化You can Author a query in Log Analytics and pin it to Azure dashboard to visualize a log query.
  • 新的 scheduledQueryRules API 支持日志警报中的跨资源查询。Cross-resource query in log alerts is supported in the new scheduledQueryRules API. 默认情况下,Azure Monitor 使用旧版 Log Analytics 警报 API 从 Azure 门户创建新的日志警报规则。By default, Azure Monitor uses the legacy Log Analytics Alert API for creating new log alert rules from Azure portal. 切换之后,新的 API 成为 Azure 门户中新警报规则的默认设置,借助它可以创建跨资源查询日志警报规则。After the switch, the new API becomes the default for new alert rules in Azure portal and it lets you create cross-resource query log alerts rules. 可以使用 scheduledQueryRules API 的 Azure 资源管理器模板创建跨资源查询日志警报规则,而无需进行切换。但是,此警报规则可通过 scheduledQueryRules API 进行管理,而不可通过 Azure 门户进行管理。You can create cross-resource query log alert rules without making the switch by using the Azure Resource Manager template for scheduledQueryRules API - but this alert rule is manageable though scheduledQueryRules API and not from Azure portal.

跨 Log Analytics 工作区以及从 Application Insights 进行查询Querying across Log Analytics workspaces and from Application Insights

若要在查询中引用另一个工作区,请使用 workspace 标识符,对于 Application Insights 中的应用,请使用 app 标识符。To reference another workspace in your query, use the workspace identifier, and for an app from Application Insights, use the app identifier.

标识工作区资源Identifying workspace resources

以下示例演示了跨 Log Analytics 工作区进行查询以从名为 contosoretail-it 的工作区的 Update 表中返回记录的汇总计数。The following examples demonstrate queries across Log Analytics workspaces to return summarized counts of logs from the Update table on a workspace named contosoretail-it.

可以通过以下任一方式来标识工作区:Identifying a workspace can be accomplished one of several ways:

  • 资源名称 - 用户可读的工作区名称,有时称为“组件名称”。Resource name - is a human-readable name of the workspace, sometimes referred to as component name.

    workspace("contosoretail-it").Update | count

  • 限定名称 - 工作区的“全名”,由订阅名称、资源组和组件名称组成,并采用以下格式:subscriptionName/resourceGroup/componentNameQualified name - is the “full name” of the workspace, composed of the subscription name, resource group, and component name in this format: subscriptionName/resourceGroup/componentName.

    workspace('contoso/contosoretail/contosoretail-it').Update | count

    备注

    因为 Azure 订阅名称不唯一,所以此标识符可能不明确。Because Azure subscription names are not unique, this identifier might be ambiguous.

  • 工作区 ID - 工作区 ID 是分配给每个工作区的唯一不可变标识符,表示为全局唯一标识符 (GUID)。Workspace ID - A workspace ID is the unique, immutable, identifier assigned to each workspace represented as a globally unique identifier (GUID).

    workspace("b459b4u5-912x-46d5-9cb1-p43069212nb4").Update | count

  • Azure 资源 ID - Azure 定义的工作区唯一标识。Azure Resource ID - the Azure-defined unique identity of the workspace. 当资源名称不明确时需使用资源 ID。You use the Resource ID when the resource name is ambiguous. 对于工作区,此格式为:/subscriptions/subscriptionId/resourcegroups/resourceGroup/providers/microsoft.OperationalInsights/workspaces/componentName。For workspaces, the format is: /subscriptions/subscriptionId/resourcegroups/resourceGroup/providers/microsoft.OperationalInsights/workspaces/componentName.

    例如:For example:

    workspace("/subscriptions/e427519-5645-8x4e-1v67-3b84b59a1985/resourcegroups/ContosoAzureHQ/providers/Microsoft.OperationalInsights/workspaces/contosoretail-it").Update | count
    

标识应用程序Identifying an application

以下示例返回针对 Application Insights 中名为 fabrikamapp 的应用发出的请求的汇总计数。The following examples return a summarized count of requests made against an app named fabrikamapp in Application Insights.

可以使用 app(Identifier) 表达式标识 Application Insights 中的应用程序。Identifying an application in Application Insights can be accomplished with the app(Identifier) expression. Identifier 参数使用下列项之一来指定应用:The Identifier argument specifies the app using one of the following:

  • 资源名称 - 人类可读的应用名称,有时称为“组件名称”。Resource name - is a human readable name of the app, sometimes referred to as the component name.

    app("fabrikamapp")

    备注

    按名称标识应用程序会假设它在所有可访问的订阅中是唯一的。Identifying an application by name assumes uniqueness across all accessible subscriptions. 如果具有多个采用指定名称的应用程序,查询将因多义性而失败。If you have multiple applications with the specified name, the query fails because of the ambiguity. 在这种情况下,必须使用其他标识符之一。In this case, you must use one of the other identifiers.

  • 限定名称 - 应用的“全名”,由订阅名称、资源组和组件名称组成,并采用以下格式:subscriptionName/resourceGroup/componentNameQualified name - is the “full name” of the app, composed of the subscription name, resource group, and component name in this format: subscriptionName/resourceGroup/componentName.

    app("AI-Prototype/Fabrikam/fabrikamapp").requests | count

    备注

    因为 Azure 订阅名称不唯一,所以此标识符可能不明确。Because Azure subscription names are not unique, this identifier might be ambiguous.

  • ID - 应用程序的应用 GUID。ID - the app GUID of the application.

    app("b459b4f6-912x-46d5-9cb1-b43069212ab4").requests | count

  • Azure 资源 ID - Azure 定义的应用唯一标识。Azure Resource ID - the Azure-defined unique identity of the app. 当资源名称不明确时需使用资源 ID。You use the Resource ID when the resource name is ambiguous. 格式为: /subscriptions/subscriptionId/resourcegroups/resourceGroup/providers/microsoft.OperationalInsights/components/componentNameThe format is: /subscriptions/subscriptionId/resourcegroups/resourceGroup/providers/microsoft.OperationalInsights/components/componentName.

    例如:For example:

    app("/subscriptions/b459b4f6-912x-46d5-9cb1-b43069212ab4/resourcegroups/Fabrikam/providers/microsoft.insights/components/fabrikamapp").requests | count
    

跨多个资源执行查询Performing a query across multiple resources

可以从任何资源实例查询多个资源,这些资源实例可以是工作区和应用程序的组合。You can query multiple resources from any of your resource instances, these can be workspaces and apps combined.

跨两个工作区进行查询的示例:Example for query across two workspaces:

union Update, workspace("contosoretail-it").Update, workspace("b459b4u5-912x-46d5-9cb1-p43069212nb4").Update
| where TimeGenerated >= ago(1h)
| where UpdateState == "Needed"
| summarize dcount(Computer) by Classification

针对多个资源使用跨资源查询Using cross-resource query for multiple resources

使用跨资源查询来关联来自多个 Log Analytics 工作区和 Application Insights 资源的数据时,查询可能变得复杂且难以维护。When using cross-resource queries to correlate data from multiple Log Analytics workspaces and Application Insights resources, the query can become complex and difficult to maintain. 应利用 Azure Monitor 日志查询中的函数将查询逻辑与查询资源的范围分开,这样可以简化查询结构。You should leverage functions in Azure Monitor log queries to separate the query logic from the scoping of the query resources, which simplifies the query structure. 以下示例演示了如何监视多个 Application Insights 资源,并按应用程序名称显示失败请求的计数。The following example demonstrates how you can monitor multiple Application Insights resources and visualize the count of failed requests by application name.

创建如下所示的引用 Application Insights 资源范围的查询。Create a query like the following that references the scope of Application Insights resources. withsource= SourceApp 命令可添加用于指定发送日志的应用程序名称的列。The withsource= SourceApp command adds a column that designates the application name that sent the log. 使用别名 applicationsScoping 将查询另存为函数 Save the query as function with the alias applicationsScoping.

// crossResource function that scopes my Application Insights resources
union withsource= SourceApp
app('Contoso-app1').requests, 
app('Contoso-app2').requests,
app('Contoso-app3').requests,
app('Contoso-app4').requests,
app('Contoso-app5').requests

现可在跨资源查询中使用此函数,如下所示。You can now use this function in a cross-resource query like the following. 函数别名 applicationsScoping 返回来自所有已定义应用程序的请求表的并集。The function alias applicationsScoping returns the union of the requests table from all the defined applications. 然后,查询筛选失败的请求,并按应用程序显示趋势。The query then filters for failed requests and visualizes the trends by application. 在此示例中,分析运算符是可选的。The parse operator is optional in this example. 该运算符从 SourceApp 属性中提取应用程序名称。It extracts the application name from SourceApp property.

applicationsScoping 
| where timestamp > ago(12h)
| where success == 'False'
| parse SourceApp with * '(' applicationName ')' * 
| summarize count() by applicationName, bin(timestamp, 1h) 
| render timechart

备注

此方法不能用于日志警报,因为警报规则资源(包括工作区和应用程序)的访问验证是在警报创建时执行的。This method can’t be used with log alerts because the access validation of the alert rule resources, including workspaces and applications, is performed at alert creation time. 不支持在创建警报后将新资源添加到该函数。Adding new resources to the function after the alert creation isn’t supported. 若要使用函数在日志警报中限定资源范围,则需要在门户中或使用资源管理器模板来编辑警报规则,以更新范围内资源。If you prefer to use function for resource scoping in log alerts, you need to edit the alert rule in the portal or with a Resource Manager template to update the scoped resources. 此外,也可以在日志警报查询中添加资源列表。Alternatively, you can include the list of resources in the log alert query.

时间表

后续步骤Next steps