使用 Azure Monitor 代理从虚拟机收集事件和性能计数器
本文介绍如何使用 Azure Monitor 代理从虚拟机收集事件和性能计数器。
先决条件
如果要完成此过程，需要：
- Log Analytics 工作区，你在其中至少拥有参与者权限。
- 在工作区中创建数据收集规则对象的权限。
- 将数据收集规则关联到特定虚拟机。
创建数据收集规则
可以定义数据收集规则，以将数据从多台计算机发送到多个 Log Analytics 工作区，包括不同区域或租户中的工作区。 在 Log Analytics 工作区所在的同一区域中创建数据收集规则。 只能将 Windows 事件和 Syslog 数据发送到 Azure Monitor 日志。 可以将性能计数器发送到 Azure Monitor 指标和 Azure Monitor 日志。
注意
目前，无法在指标资源管理器中查看 Microsoft.HybridCompute（已启用 Azure Arc 的服务器）资源（Azure 门户 UX），但可以通过指标 REST API（指标命名空间 - 列表、指标定义 - 列表和指标 - 列表）获取这些资源。
注意
若要跨租户发送数据，必须先启用 Azure Lighthouse。
在的“监视”菜单中，选择“数据收集规则”。
选择“创建”，创建新的数据收集规则和关联。
输入“规则名称”并指定“订阅”、“资源组”、“区域”和“平台类型”：
- “区域”指定将在其中创建 DCR 的位置。 虚拟机及其关联可以处于租户中的任何订阅或资源组中。
- “平台类型”指定此规则可应用到的资源类型。 “自定义”选项允许 Windows 和 Linux 两种类型。
在“资源”选项卡上：
-
选择“+ 添加资源”并将资源关联到数据收集规则。 资源可以是虚拟机、虚拟机规模集和 Azure Arc for servers。 Azure 门户将在尚未安装 Azure Monitor 代理的资源上安装 Azure Monitor 代理。
重要
门户可以在目标资源上启用系统分配的托管标识，还包括现有的用户分配的标识（如有）。 对于现有应用程序，除非在请求中指定用户分配的标识，否则计算机将默认使用系统分配的标识。
如果需要使用专用链接进行网络隔离，请为相应资源选择同一区域的现有终结点，或创建新的终结点。
选择“数据收集终结点”，此为可选字段，除非你计划使用 Azure Monitor 专用链接，否则无需设置该字段。 如果需要该字段，请指定用于收集数据的数据收集终结点。 此数据收集终结点必须与 Log Analytics 工作区位于同一区域。 有关详细信息，请参阅如何根据部署设置数据收集终结点。
为与数据收集规则关联的每个资源选择数据收集终结点。
在“收集和传递”选项卡上，选择“添加数据源”以添加数据源并设置目标。
选择“数据源类型”。
选择要收集的数据。 对于性能计数器，可以从一组预定义对象及其采样速率中进行选择。 对于事件，可以从一组日志和严重性级别中进行选择。
选择“自定义”以收集当前不支持的数据源的日志和性能计数器，或使用 XPath 查询筛选事件。 然后，可以指定 XPath 来收集任何特定值。
若要收集默认不可用的性能计数器，请使用
\PerfObject(ParentInstance/ObjectInstance#InstanceIndex)\Counter格式。 如果计数器名称包含与符号 (&)，请将其替换为&。 例如\Memory\Free & Zero Page List Bytes。如需 DCR 示例，请参阅 Azure Monitor 中的示例数据收集规则 (DCR)。
在“目标”选项卡上，为数据源添加一个或多个目标。 你可以选择多个相同或不同类型的目标。 例如，你可以选择多个 Log Analytics 工作区，这也称为多宿主。
只能将 Windows 事件和 Syslog 数据源发送到 Azure Monitor 日志。 可以将性能计数器发送到 Azure Monitor 指标和 Azure Monitor 日志。 目前，混合计算 (Arc for Server) 资源不支持 Azure Monitor 指标（预览版）目标。
依次选择“添加数据源”，然后选择“查看 + 创建”，查看数据收集规则的详细信息以及与虚拟机集的关联。
选择“创建”，创建数据收集规则。
参数文件
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"vmName": {
"value": "my-azure-vm"
},
"associationName": {
"value": "my-windows-vm-my-dcr"
},
"dataCollectionRuleId": {
"value": "/subscriptions/00000000-0000-0000-0000-000000000000/resourcegroups/my-resource-group/providers/microsoft.insights/datacollectionrules/my-dcr"
}
}
}
注意
创建数据收集规则后，可能需要最多 5 分钟的时间来将数据发送到目标。
使用 XPath 查询筛选事件
需要为在 Log Analytics 工作区中收集的任何数据支付费用。 因此，你应该只收集需要的事件数据。 Azure 门户中的基本配置提供的筛选事件的权力有限。
提示
有关降低 Azure Monitor 成本的策略，请参阅成本优化和 Azure Monitor。
若要指定更多筛选器，请使用自定义配置，并指定用于筛选出不需要的事件的 XPath。 XPath 条目以 LogName!XPathQuery 形式进行编写。 例如，你可能只希望从应用程序事件日志中返回事件 ID 为 1035 的事件。 这些事件的 XPathQuery 将为 *[System[EventID=1035]]。 由于要从应用程序事件日志中检索事件，因此 XPath 为 Application!*[System[EventID=1035]]
从 Windows 事件查看器提取 XPath 查询
在 Windows 中，可使用事件查看器提取 XPath 查询，如屏幕截图中所示。
将 XPath 查询粘贴到“添加数据源”屏幕上的字段中时（如第 5 步中所示），必须附加日志类型类别，后跟感叹号 (!)。
提示
你也可以将 PowerShell cmdlet Get-WinEvent 与 FilterXPath 参数配合使用，先在计算机本地测试 XPath 查询的有效性。 有关详细信息，请参阅 Windows 基于代理的连接说明中提供的提示。 Get-WinEvent PowerShell cmdlet 最多支持 23 个表达式。 Azure Monitor 数据收集规则最多支持 20 个。 以下脚本显示了一个示例：
$XPath = '*[System[EventID=1035]]'
Get-WinEvent -LogName 'Application' -FilterXPath $XPath
- 在前面的 cmdlet 中，
-LogName参数的值是 XPath 查询的初始部分，直到感叹号 (!)。 XPath 查询的其余部分将进入$XPath参数。 - 如果脚本返回事件，则查询有效。
- 如果收到消息“找不到任何与指定的选择条件匹配的事件。”，则查询可能有效，但在本地计算机上没有匹配的事件。
- 如果收到消息“指定的查询无效”，则查询语法无效。
使用自定义 XPath 筛选事件的示例：
| 说明 | XPath |
|---|---|
| 仅收集事件 ID = 4648 的系统事件 | System!*[System[EventID=4648]] |
| 收集事件 ID = 4648 且进程名称为 consent.exe 的安全日志事件 | Security!*[System[(EventID=4648)]] and *[EventData[Data[@Name='ProcessName']='C:\Windows\System32\consent.exe']] |
| 从系统事件日志中收集所有严重、错误、警告和信息事件，事件 ID 6（驱动程序已加载）除外 | System!*[System[(Level=1 or Level=2 or Level=3) and (EventID != 6)]] |
| 收集所有成功和失败安全事件，事件 ID 4624（成功登录）除外 | Security!*[System[(band(Keywords,13510798882111488)) and (EventID != 4624)]] |
注意
要了解 Windows 事件日志支持的 XPath 中的限制列表，请参阅 XPath 1.0 限制。
例如，可以在查询中使用“position”、“Band”和“timediff”函数，但目前不支持“starts-with”和“contains”等其他函数。
常见问题
本部分提供常见问题的解答。
如何使用 Azure Monitor Agent 收集 Windows 安全事件？
发送到 Log Analytics 工作区时，可通过两种方法使用新代理收集安全事件：
- 与其他 Windows 事件一样，可以使用 Azure Monitor Agent 以本机方式收集安全事件。 这些事件将流向 Log Analytics 工作区中的“Event”表。
- 如果在工作区上启用了 Microsoft Sentinel，则安全事件会改为通过 Azure Monitor 代理流向
SecurityEvent表（与使用 Log Analytics 代理相同）。 此方案始终要求首先启用解决方案。
如果在同一台计算机上使用 Azure Monitor 代理和 Log Analytics 代理，是否会重复事件？
如果用两个代理收集相同的事件，则会发生重复。 这种重复可能是由于旧代理从数据收集规则收集的工作区配置数据中收集冗余数据。 或者，你可能在使用旧版代理收集安全事件，并在 Microsoft Sentinel 中使用 Azure Monitor 代理连接器启用 Windows 安全事件。
将重复事件限制在仅当从一个代理过渡到另一个代理时发生。 完全测试数据收集规则并验证其数据收集后，请禁用工作区的收集并断开任何 Microsoft Monitoring Agent 数据连接器。
除了 Xpath 查询和指定性能计数器之外，Azure Monitor Agent 是否还提供更精细的事件筛选选项？
对于 Linux 上的 Syslog 事件，可以为每个设施选择设施和日志级别。
如果我创建了包含相同事件 ID 的数据收集规则并将其关联到相同的 VM，事件是否会重复？
是的。 为了避免重复，请确保在数据收集规则中进行的事件选择不包含重复事件。
后续步骤
- 使用 Azure Monitor 代理收集文本日志。
- 详细了解 Azure Monitor 代理。
- 详细了解数据收集规则。