查询 Azure 资源的日志

在 Azure Monitor Log Analytics 中，查询通常在工作区的上下文中执行。一个工作区可以包含许多资源的数据，因此很难隔离特定资源的数据。资源还可以将数据发送到多个工作区。为了简化这种体验，REST API 允许直接查询 Azure 资源以获取其日志。

URL 格式

请求格式

请考虑以下示例来了解请求格式：

请求部分	Syntax
具有完全限定标识符的 Azure 资源	`/subscriptions/<sid>/resourceGroups/<rg>/providers/<providerName>/<resourceType>/<resourceName>`
针对直接 API 终结点请求此资源的日志格式	`https://api.loganalytics.azure.cn/v1/subscriptions/<sid>/resourceGroups/<rg>/providers/<providerName>/<resourceType>/<resourceName>/query`

响应格式

Azure 资源查询会生成与针对 Log Analytics 工作区的查询相同的响应形状。

表访问和 RBAC

在表级别控制访问的最佳方式是实现细粒度 RBAC。

工作区访问控制

Azure 资源查询将检查 Log Analytics 工作区作为潜在的数据源。但是，管理员可以通过角色限制对工作区的访问，并限制对具有精细 RBAC 的表的访问。默认情况下，API 仅返回用户有权访问的工作区和表的结果。若要确保资源查询遵循工作区和表 RBAC，请参阅粒度 RBAC 常见问题解答中概述的详细信息。

Troubleshooting

下面简要列出了查询 Azure 资源时出现的常见失败情况以及症状行为的描述。

Azure 资源不存在

HTTP/1.1 404 Not Found 
{ 
    "error": { 
        "message": "The resource /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/test-rg/providers/microsoft.storage/storageaccounts/exampleResource was not found", 
        "code": "ResourceNotFoundError" 
    }
}

无权访问资源

HTTP/1.1 403 Forbidden 
{
    "error": { 
        "message": "The provided credentials have insufficient access to perform the requested operation", 
        "code": "InsufficientAccessError", 
        "innererror": { 
            "code": "AuthorizationFailedError",
            "message": "User '92eba38a-70da-42b0-ab83-ffe82cce658f' does not have access to read logs for this resource"
        }
    } 
}

资源中没有日志，或者对包含这些日志的工作区没有权限

根据数据和权限的精确组合，响应可能包含 200 而无结果数据，也可能引发语法错误（4xx 错误）。

部分访问权限

在某些情况下，用户可能对特定资源的日志拥有部分访问权限。如果用户缺少以下任一权限，则会发生这种情况：

对包含 Azure 资源日志的工作区的访问权限。
访问查询中引用的表。

默认情况下，这些方案会生成 HTTP 状态为 200 的成功响应，但用户无权访问的数据源会以无提示方式筛选掉。

若要查看有关用户对 Azure 资源、基础 Log Analytics 工作区和特定表的访问权限的详细信息，请在请求中包含以下标头：

请求标头	目的
`Prefer: include-permissions=true`	在响应中启用详细的访问权限信息

下面是包含该标头时响应附带的其他 JSON 部分的示例：

{ 
    "permissions": { 
        "resources": [ 
            { 
                "resourceId": "/subscriptions/<id>/resourceGroups<id>/providers/Microsoft.Compute/virtualMachines/VM1", 
                "dataSources": [ 
                    "/subscriptions/<id>/resourceGroups/<id>/providers/Microsoft.OperationalInsights/workspaces/WS1" 
                ] 
            }, 
            { 
                "resourceId": "/subscriptions/<id>/resourceGroups/<id>/providers/Microsoft.Compute/virtualMachines/VM2", 
                "denyTables": [ 
                    "SecurityEvent", 
                    "SecurityBaseline" 
                ], 
                "dataSources": [ 
                    "/subscriptions/<id>/resourceGroups/<id>/providers/Microsoft.OperationalInsights/workspaces/WS2",
                    "/subscriptions/<id>/resourceGroups/<id>/providers/Microsoft.OperationalInsights/workspaces/WS3" 
                ] 
            } 
        ], 
        "dataSources": [ 
            { 
                "resourceId": "/subscriptions/<id>/resourceGroups/<id>/providers/Microsoft.OperationalInsights/workspaces/WS1", 
                "denyTables": [ 
                    "Tables.Custom" 
                ] 
            }, 
            { 
                "resourceId": "/subscriptions/<id>/resourceGroups/<id>/providers/Microsoft.OperationalInsights/workspaces/WS2" 
            } 
        ] 
    } 
}

resources 有效负载描述查询两个 VM 的尝试。 VM1 将数据发送到工作区 WS1，而 VM2 将数据发送到两个工作区：WS2 和 WS3。此外，用户无权查询资源的 SecurityEvent 或 SecurityBaseline 表。

dataSources 有效负载通过描述用户可查询的工作区来进一步筛选结果。用户无权在此处查询 WS3，以及从 WS1 中筛选掉的另一个表。

当对数据考虑访问控制时，查询将返回以下内容：

WS1 中的 VM1 日志，不包括工作区中的 Tables.Custom。
WS2 中 VM2 的日志，不包括 SecurityEvent 和 SecurityBaseline。

Last updated on 2026-02-06

Condividi tramite