发送 Azure Monitor 活动日志数据

Azure Monitor 活动日志是一种平台日志，它提供对订阅级事件的见解。 活动日志包括何时修改了资源或何时启动了虚拟机等信息。 可以在 Azure 门户中查看活动日志，或在 PowerShell 和 Azure CLI 中检索条目。 本文介绍了如何查看活动日志并将其发送到不同的目标。

创建诊断设置以将活动日志发送到以下一个或多个位置：

• Log Analytics 工作区，用于更复杂的查询和警报
• Azure 事件中心，用于转发 Azure 外部的日志。
• Azure 存储，用于实现更便宜的长期存档。

有关创建诊断设置的详细信息，请参阅创建诊断设置以将平台日志和指标发送到不同的目标。

发送到 Log Analytics 工作区

将活动日志发送到 Log Analytics 工作区以启用 Azure Monitor 日志功能，使用此功能可以：

• 将活动日志数据与 Azure Monitor 收集的其他监视数据相关联。
• 将来自多个 Azure 订阅和租户的活动日志合并到同一位置一起进行分析。
• 使用日志查询来执行复杂分析，并深入了解活动日志条目。
• 将日志搜索警报与活动条目配合使用，以实现更复杂的警报逻辑。
• 活动日志项的存储时间需要长于活动日志保留期。
• Log Analytics 工作区中存储的活动日志数据不会产生数据引入或保留费用。
• Log Analytics 中的默认保留期为 90 天

选择“导出活动日志”以将活动日志发送到 Log Analytics 工作区。

可以将任一订阅中的活动日志发送到最多五个工作区。

Log Analytics 工作区中的活动日志数据存储在名为 AzureActivity 的表中，可以在 Log Analytics 中使用日志查询来检索该表。 此表的结构因日志条目类别而异。 有关表属性的说明，请参阅 Azure Monitor 数据参考。

例如，若要查看每个类别的活动日志记录计数，请使用以下查询：

AzureActivity
| summarize count() by CategoryValue

若要检索管理类别中的所有记录，请使用以下查询：

AzureActivity
| where CategoryValue == "Administrative"

发送到 Azure 事件中心

将活动日志发送到 Azure 事件中心可将条目发送到 Azure 外部，例如，发送到第三方 SIEM 或其他日志分析解决方案。 来自事件中心的活动日志事件以 JSON 格式使用，其中的 records 元素包含每个有效负载中的记录。 架构取决于类别，Azure 活动日志事件架构中对此做了介绍。

下面是来自事件中心的活动日志输出数据示例：

{
    "records": [
        {
            "time": "2019-01-21T22:14:26.9792776Z",
            "resourceId": "/subscriptions/s1/resourceGroups/MSSupportGroup/providers/microsoft.support/supporttickets/115012112305841",
            "operationName": "microsoft.support/supporttickets/write",
            "category": "Write",
            "resultType": "Success",
            "resultSignature": "Succeeded.Created",
            "durationMs": 2826,
            "callerIpAddress": "111.111.111.11",
            "correlationId": "c776f9f4-36e5-4e0e-809b-c9b3c3fb62a8",
            "identity": {
                "authorization": {
                    "scope": "/subscriptions/s1/resourceGroups/MSSupportGroup/providers/microsoft.support/supporttickets/115012112305841",
                    "action": "microsoft.support/supporttickets/write",
                    "evidence": {
                        "role": "Subscription Admin"
                    }
                },
                "claims": {
                    "aud": "https://management.core.chinacloudapi.cn/",
                    "iss": "https://sts.chinacloudapi.cn/72f988bf-86f1-41af-91ab-2d7cd011db47/",
                    "iat": "1421876371",
                    "nbf": "1421876371",
                    "exp": "1421880271",
                    "ver": "1.0",
                    "http://schemas.microsoft.com/identity/claims/tenantid": "00000000-0000-0000-0000-000000000000",
                    "http://schemas.microsoft.com/claims/authnmethodsreferences": "pwd",
                    "http://schemas.microsoft.com/identity/claims/objectidentifier": "2468adf0-8211-44e3-95xq-85137af64708",
                    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn": "admin@contoso.com",
                    "puid": "20030000801A118C",
                    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier": "9vckmEGF7zDKk1YzIY8k0t1_EAPaXoeHyPRn6f413zM",
                    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname": "John",
                    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname": "Smith",
                    "name": "John Smith",
                    "groups": "cacfe77c-e058-4712-83qw-f9b08849fd60,7f71d11d-4c41-4b23-99d2-d32ce7aa621c,31522864-0578-4ea0-9gdc-e66cc564d18c",
                    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name": " admin@contoso.com",
                    "appid": "c44b4083-3bq0-49c1-b47d-974e53cbdf3c",
                    "appidacr": "2",
                    "http://schemas.microsoft.com/identity/claims/scope": "user_impersonation",
                    "http://schemas.microsoft.com/claims/authnclassreference": "1"
                }
            },
            "level": "Information",
            "location": "global",
            "properties": {
                "statusCode": "Created",
                "serviceRequestId": "50d5cddb-8ca0-47ad-9b80-6cde2207f97c"
            }
        }
    ]
}

发送到 Azure 存储

如果要将日志数据保留超过 90 天以进行审核、静态分析或备份，请将活动日志发送到 Azure 存储帐户。 如果只需将事件保留 90 天或更短时间，则无需设置为存档到存储帐户。 活动日志事件将在 Azure 平台中保留 90 天。

将活动日志发送到 Azure 时，一旦发生事件，就会在存储帐户中创建一个存储容器。 容器中的 blob 使用以下命名约定：

insights-activity-logs/resourceId=/SUBSCRIPTIONS/{subscription ID}/y={four-digit numeric year}/m={two-digit numeric month}/d={two-digit numeric day}/h={two-digit 24-hour clock hour}/m=00/PT1H.json

例如，特定 Blob 的名称可能类似于：

insights-activity-logs/resourceId=/SUBSCRIPTIONS/00000000-0000-0000-0000-000000000000/y=2020/m=06/d=08/h=18/m=00/PT1H.json

每个 PT1H.json blob 都包含一个 JSON 对象，其中包含在 Blob URL 中指定的小时内收到的日志文件中的事件。 在当前小时内，无论事件在何时生成，都将追加到 PT1H.json 文件中。 URL m=00 中的分钟值始终为 00，因为每小时创建一次 Blob。

每个事件使用以下格式存储在 PT1H.json 文件中。 此格式使用通用顶级架构，但其他方面对于每个类别都是唯一的，如活动日志架构中所述。

{ "time": "2020-06-12T13:07:46.766Z", "resourceId": "/SUBSCRIPTIONS/00000000-0000-0000-0000-000000000000/RESOURCEGROUPS/MY-RESOURCE-GROUP/PROVIDERS/MICROSOFT.COMPUTE/VIRTUALMACHINES/MV-VM-01", "correlationId": "0f0cb6b4-804b-4129-b893-70aeeb63997e", "operationName": "Microsoft.Resourcehealth/healthevent/Updated/action", "level": "Information", "resultType": "Updated", "category": "ResourceHealth", "properties": {"eventCategory":"ResourceHealth","eventProperties":{"title":"This virtual machine is starting as requested by an authorized user or process. It will be online shortly.","details":"VirtualMachineStartInitiatedByControlPlane","currentHealthStatus":"Unknown","previousHealthStatus":"Unknown","type":"Downtime","cause":"UserInitiated"}}}

检索活动日志事件的其他方法

还可以使用以下方法来访问活动日志事件：

• 在 PowerShell 中使用 Get-AzLog cmdlet 检索活动日志。 请参阅 Azure Monitor PowerShell 示例。
• 在 CLI 中使用 az monitor activity-log 检索活动日志。 请参阅 Azure 监视器 CLI 示例。
• 在 REST 客户端中使用 Azure Monitor REST API 检索活动日志。

旧式收集方法

如果使用旧式收集方法收集活动日志，我们建议你将活动日志导出到 Log Analytics 工作区并使用数据源 - 删除 API 禁用旧式收集，如下所示：

1. 使用数据源 - 按工作区 API 列出连接到工作区的所有数据源，并通过设置 kind eq 'AzureActivityLog' 来筛选出活动日志。

   

2. 从 API 响应中复制要禁用的连接的名称。

   

3. 使用数据源 - 删除 API 停止收集特定资源的活动日志。

   

管理旧版日志配置文件 - 即将停用

日志配置文件是用于将活动日志发送到存储或事件中心的旧方法。 如果使用此方法，请转换到诊断设置，这可以提供更好的功能并与资源日志的保持一致。

# Settings needed for the new log profile
$logProfileName = "default"
$locations = (Get-AzLocation).Location
$locations += "global"
$subscriptionId = "<your Azure subscription Id>"
$resourceGroupName = "<resource group name your Event Hub belongs to>"
$eventHubNamespace = "<Event Hub namespace>"

# Build the service bus rule Id from the settings above
$serviceBusRuleId = "/subscriptions/$subscriptionId/resourceGroups/$resourceGroupName/providers/Microsoft.EventHub/namespaces/$eventHubNamespace/authorizationrules/RootManageSharedAccessKey"

# Build the Storage Account Id from the settings above
$storageAccountId = "/subscriptions/$subscriptionId/resourceGroups/$resourceGroupName/providers/Microsoft.Storage/storageAccounts/$storageAccountName"

Add-AzLogProfile -Name $logProfileName -Location $locations -StorageAccountId  $storageAccountId -ServiceBusRuleId $serviceBusRuleId

数据结构更改

导出活动日志体验，与用于发送活动日志的旧版方法发送的数据是相同的，但 AzureActivity 表的结构存在一些更改。

更新后的架构中弃用了下表中的列。 这些列仍存在于 AzureActivity 中，但不会包含任何数据。 这些列的替换项并不是新的，而是包含了与已弃用列相同的数据。 它们采用了一种不同的格式，所以你可能需要对使用它们的日志查询进行修改。

以下列已添加到更新后架构的 AzureActivity 中：

• Authorization_d
• Claims_d
• Properties_d

后续步骤

了解有关以下方面的详细信息：

• 平台日志
• 活动日志事件架构
• 活动日志见解