Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В Azure Monitor Log Analytics запросы обычно выполняются в контексте рабочей области. Рабочая область может содержать данные для множества ресурсов, что усложняет их изоляцию для определенного ресурса. Ресурсы могут дополнительно отправлять данные в несколько рабочих областей. Чтобы упростить этот процесс, REST API позволяет выполнять запросы напрямую к журналам ресурсов Azure.
Форматы URL-адресов
Формат запроса
Рассмотрим следующий пример, чтобы понять формат запроса:
| Часть запроса | Синтаксис |
|---|---|
| Полностью квалифицированный идентификатор ресурса Azure | /subscriptions/<sid>/resourceGroups/<rg>/providers/<providerName>/<resourceType>/<resourceName> |
| Формат запроса для журналов этого ресурса на прямой конечной точке API | https://api.loganalytics.azure.com/v1/subscriptions/<sid>/resourceGroups/<rg>/providers/<providerName>/<resourceType>/<resourceName>/query |
Формат ответа
Запросы ресурсов Azure формируют ту же форму ответа, что и запросы для рабочей области Log Analytics.
Доступ к таблицам и RBAC
Лучший способ управления доступом на уровне таблицы — реализовать детализированный RBAC.
Контроль доступа к рабочей области
Запросы ресурсов Azure проверяют рабочие области Log Analytics как возможные источники данных. Однако администраторы могут ограничить доступ к рабочей области с помощью ролей и ограничить доступ к таблицам с детализацией RBAC. По умолчанию API возвращает результаты только из рабочих областей и таблиц, к которым пользователь имеет разрешения на доступ. Чтобы убедиться, что запросы ресурсов соответствуют требованиям RBAC в контексте рабочей области и таблицы, см. сведения, описанные в подробном руководстве по RBAC.
Устранение неполадок
Ниже приведен краткий список распространенных сценариев сбоя при запросе ресурсов 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 описывает попытку выполнить запрос к двум виртуальным машинам. Машина VM1 отправляет данные в рабочую область WS1, а VM2 — в две рабочие области: WS2 и WS3. Кроме того, у пользователя нет разрешения выполнять запросы таблиц SecurityEvent или SecurityBaseline для этого ресурса.
Полезная нагрузка dataSources отфильтровывает результаты, описывая, какие рабочие пространства пользователь может запрашивать. Здесь у пользователя нет разрешений на запрос WS3, а другая таблица отфильтровывается из WS1.
При рассмотрении элементов управления доступом для данных запрос возвращает следующее:
- Журналы для VM1 в рабочей области WS1, за исключением
Tables.Custom. - Журналы для VM2, кроме
SecurityEventиSecurityBaseline, в WS2.