你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

使用 Azure Monitor 监视虚拟机:收集数据

本文是指南在 Azure Monitor 中监视虚拟机及其工作负载的一部分。 它介绍在将 Azure Monitor 代理部署到 Azure Monitor 中的 Azure 和混合虚拟机后如何配置数据收集。

本文提供有关从虚拟机收集最常见类型的遥测的指南。 选择的确切配置由计算机上运行的工作负载决定。 每个部分中都包含可用于该数据的示例日志搜索警报。

注意

本方案描述如何实现对 Azure 和混合虚拟机环境的完整监视。 若要开始监视您的第一台 Azure 虚拟机,请参阅监视 Azure 虚拟机

数据收集规则

通过 Azure Monitor 代理进行的数据收集由一个或多个数据收集规则 (DCR) 定义,这些规则存储在 Azure 订阅中的,并且与虚拟机相关联。

对于虚拟机,DCR 会定义要收集的数据(例如事件和性能计数器),并指定应将数据发送到的 Log Analytics 工作区。 DCR 还可以使用转换来筛选出不需要的数据并添加计算列。 一台计算机可以与多个 DCR 相关联,一个 DCR 可以与多台计算机相关联。 DCR 将传递到与其关联的任何计算机,Azure Monitor 代理将在这里处理这些规则。

查看数据收集规则

可访问 Azure 门户中的“监视”菜单,在“数据收集规则”中查看 Azure 订阅中的 DCR。 DCR 支持 Azure Monitor 中的其他数据收集方案,因此并非所有 DCR 都一定适用于虚拟机。

显示 Azure 门户中的 DCR 的屏幕截图。

创建数据收集规则

有多种方法来创建 DCR,具体取决于数据收集方案。 在某些情况下,Azure 门户将引导你完成配置。 其他方案要求直接编辑 DCR。 配置 VM 见解时,它会自动创建预配置的 DCR。 以下部分说明要收集的常见数据,并介绍如何配置数据收集。

在某些情况下,可能需要编辑现有的 DCR 才能添加功能。 例如,可使用 Azure 门户来创建收集 Windows 或 Syslog 事件的 DCR。 然后,需要为该 DCR 添加转换,以筛选出不想收集的事件中的列。

随着环境的成熟和复杂性增加,你应该实施一种策略来组织 DCR 以帮助管理这些规则。 有关不同策略的指南,请参阅 Azure Monitor 中数据收集规则创建和管理的最佳做法

控制成本

由于 Azure Monitor 的成本取决于你收集的数据量,请确保收集的数据不超过满足监视要求所需的数据。 配置就是在你的预算与你想要了解虚拟机操作的程度之间取得平衡。

提示

有关降低 Azure Monitor 成本的策略,请参阅成本优化和 Azure Monitor

一个典型的虚拟机每个月会生成 1 GB 到 3 GB 的数据。 这个数据大小取决于计算机的配置、在该计算机上运行的工作负载以及 DCR 的配置。 在整个虚拟机环境中配置数据收集之前,请先在某些代表性计算机上收集数据,以便更好地预测在整个环境中部署时的预期成本。 使用 Log Analytics 工作区见解按计算机的数据量中的日志查询来确定为每台计算机收集的可计费数据量,并相应地进行调整。

评估收集的数据并筛选出满足以下条件的任何数据,以降低成本。 你收集的每个数据源可能具有不同的方法来筛选出不需要的数据。 有关每个常见数据源的详细信息,请参阅以下部分。

  • 不用于警报。
  • 没有已知的取证或诊断值。
  • 非监管机构所必需。
  • 不在任何仪表板或工作簿中使用。

你还可以使用转换实现更精细的筛选,以及从价值不大的列筛选数据。 例如,你可能有一个对警报很有价值的 Windows 事件,但它包含具有冗余或过多数据的列。 可以创建一个允许收集事件但删除过多数据的转换。

在将数据发送到 Azure Monitor 之前,请尽可能多地筛选数据,以避免因使用转换筛选太多数据而产生潜在费用。 使用转换通过复杂逻辑筛选记录,以及筛选包含不需要的数据的列。

默认数据收集

Azure Monitor 会自动执行以下数据收集,无需任何其他配置。

平台指标

Azure 虚拟机的平台指标包括 CPU、网络和磁盘利用率等重要主机指标。 可以是:

活动日志

活动日志是自动收集的。 其中包括计算机的最近活动,例如任何配置更改以及停止和启动时间。 可在 Azure 门户中查看为每个虚拟主机收集的平台指标和活动日志。

可查看一台计算机或订阅中所有资源的活动日志创建诊断设置来将此数据发送到 Azure Monitor 代理使用的同一 Log Analytics 工作区,将其与为虚拟机收集的其他监视数据一起分析。 引入和保留活动日志数据不会产生费用。

Azure Resource Graph 中的虚拟机可用性信息

借助 Azure Resource Graph,可使用日志查询中所用的相同 KQL 查询语言,通过按资源属性进行复杂筛选、分组和排序来大规模地查询 Azure 资源。 可使用 Resource Graph 的 VM 运行状况注释进行详细的失败归因和故障时间分析。

若要了解收集哪些数据和如何查看数据,请参阅使用 Azure Monitor 监视虚拟机:分析监视数据

VM 见解

启用 VM 见解后,它将创建一个 DCR,其中包含收集以下信息的 MSVMI- 前缀。 可以将同一 DCR 用于其他虚拟机,而不是为每个 VM 创建新的 DCR。

  • 客户端操作系统的常见性能计数器将发送到 Log Analytics 工作区中的 InsightsMetrics 表。 计数器名称会被规范化来使用相同的公用名,而不考虑操作系统类型。

  • 如果指定了要收集的进程和依赖项,则会填充下表:

为了节省数据引入成本,默认情况下,VM 见解不会启用进程和依赖项的收集。 此数据是映射功能所必需的,它还会将依赖项代理部署到计算机。 如果要使用此功能,请启用此收集

收集 Windows 和 Syslog 事件

虚拟机中的操作系统和应用程序通常会写入 Windows 事件日志或 Syslog。 可在找到单个事件后立即创建警报,或者在特定时间范围内等待一系列匹配事件。 还可收集事件供以后进行分析,例如识别一段时间内的特定趋势,或者用于在出现问题后执行故障排除。

有关如何创建 DCR 来收集 Windows 和 Syslog 事件的指南,请参阅使用 Azure Monitor 代理收集数据。 你可按事件级别进行最常见的 Windows 事件日志和 Syslog 设施筛选来快速创建 DCR。

若要按事件 ID 等条件进行更精细的筛选,可使用 XPath 查询创建自定义筛选器。 可通过编辑 DCR 来添加转换,以进一步筛选收集的数据。

建议使用以下指南开始了解事件收集。 修改 DCR 设置来筛选不需要的事件,并根据要求添加其他事件。

策略
Windows 事件 至少收集系统和应用程序日志的关键、错误和警告事件,以支持触发警报。 添加信息事件以分析趋势并为故障排除提供支持。 详细事件很少有用,通常不应收集。
Syslog 事件 至少收集每个设施的 LOG_WARNING 事件以支持触发警报。 添加信息事件以分析趋势并为故障排除提供支持。 LOG_DEBUG 事件很少有用,通常不应收集。

示例日志查询:Windows 事件

查询 说明
Event 所有 Windows 事件
Event | where EventLevelName == "Error" 所有 Windows 事件和错误严重性
Event | summarize count() by Source 按源进行的 Windows 事件计数
Event | where EventLevelName == "Error" | summarize count() by Source 按源进行的 Windows 错误事件计数

示例日志查询:Syslog 事件

查询 说明
Syslog 所有 Syslog
Syslog | where SeverityLevel == "error" 严重级别为“错误”的所有 Syslog 记录
Syslog | summarize AggregatedValue = count() by Computer 按计算机计算的 Syslog 记录数目
Syslog | summarize AggregatedValue = count() by Facility 按设施计算的 Syslog 记录数目

收集性能计数器

来自客户端的性能数据可发送到 Azure Monitor 指标Azure Monitor 日志,通常会将这些数据发送到这两个目标。 如果启用了 VM 见解,则会在日志中收集一组常见的性能计数器,以支持其性能图表。 无法修改这组计数器,但可以创建其他 DCR 来收集其他计数器并将其发送到不同的目标。

需要创建 DCR 来收集来宾性能的原因有多种:

  • 未使用 VM 见解,因此尚未收集客户端性能数据。
  • 收集 VM 见解未收集的其他性能计数器。
  • 从客户端上运行的其他工作负载收集性能计数器。
  • 将性能数据发送到 Azure Monitor 指标,可在其中将其与指标资源管理器和指标警报配合使用。

有关创建 DCR 来收集性能计数器的指南,请参阅使用 Azure Monitor 代理从虚拟机收集事件和性能计数器。 可使用最常见的计数器来快速创建 DCR。 若要按事件 ID 等条件进行更精细的筛选,可使用 XPath 查询创建自定义筛选器。

注意

可选择在同一 DCR 中将性能和事件收集相结合。

目标 说明
指标 主机指标会自动发送到 Azure Monitor 指标。 可使用 DCR 来收集客户端指标,这样就能使用指标资源管理器一并分析这些指标,或者将它们与指标警报一起使用。 此数据将存储 93 天。
日志 Azure Monitor 日志中存储的性能数据可以长时间存储。 可将日志查询Log Analytics日志搜索警报一起使用,来将此数据与事件数据一并分析。 还可跨多个计算机、区域和订阅使用复杂的逻辑来关联数据。

性能数据将发送到下表:
- VM 见解:InsightsMetrics
- 其他性能数据:Perf

示例日志查询

以下示例使用包含自定义性能数据的 Perf 表。

查询 说明
Perf 所有性能数据
Perf | where Computer == "MyComputer" 特定计算机中的所有性能数据
Perf | where CounterName == "Current Disk Queue Length" 特定计数器的所有性能数据
Perf | where ObjectName == "Processor" and CounterName == "% Processor Time" and InstanceName == "_Total" | summarize AVGCPU = avg(CounterValue) by Computer 所有计算机的平均 CPU 使用率
Perf | where CounterName == "% Processor Time" | summarize AggregatedValue = max(CounterValue) by Computer 所有计算机的最大 CPU 使用率
Perf | where ObjectName == "LogicalDisk" and CounterName == "Current Disk Queue Length" and Computer == "MyComputerName" | summarize AggregatedValue = avg(CounterValue) by InstanceName 指定计算机的所有实例上的当前磁盘队列平均长度
Perf | where CounterName == "Disk Transfers/sec" | summarize AggregatedValue = percentile(CounterValue, 95) by Computer 每秒所有计算机上磁盘传输的第 95 百分位数
Perf | where CounterName == "% Processor Time" and InstanceName == "_Total" | summarize AggregatedValue = avg(CounterValue) by bin(TimeGenerated, 1h), Computer 每小时所有计算机 CPU 使用率的平均值
Perf | where Computer == "MyComputer" and CounterName startswith_cs "%" and InstanceName == "_Total" | summarize AggregatedValue = percentile(CounterValue, 70) by bin(TimeGenerated, 1h), CounterName 每小时特定计算机的每个 % 百分比计数器的第 70 百分位数
Perf | where CounterName == "% Processor Time" and InstanceName == "_Total" and Computer == "MyComputer" | summarize ["min(CounterValue)"] = min(CounterValue), ["avg(CounterValue)"] = avg(CounterValue), ["percentile75(CounterValue)"] = percentile(CounterValue, 75), ["max(CounterValue)"] = max(CounterValue) by bin(TimeGenerated, 1h), Computer 每小时特定计算机的 CPU 使用率的平均值、最小值、最大值和第 75 百分位数
Perf | where ObjectName == "MSSQL$INST2:Databases" and InstanceName == "master" 所有性能数据来自命名 SQL Server 实例 INST2 的 master 数据库的数据库性能对象。
Perf | where TimeGenerated >ago(5m) | where ObjectName == "Process" and InstanceName != "_Total" and InstanceName != "Idle" | where CounterName == "% Processor Time" | summarize cpuVal=avg(CounterValue) by Computer,InstanceName | join (Perf| where TimeGenerated >ago(5m)| where ObjectName == "Process" and CounterName == "ID Process" | summarize arg_max(TimeGenerated,*) by ProcID=CounterValue ) on Computer,InstanceName | sort by TimeGenerated desc | summarize AvgCPU = avg(cpuVal) by InstanceName,ProcID 每个进程 ID 过去 5 分钟的 CPU 平均值。

收集文本日志

一些应用程序将事件写入存储在虚拟机上的文本日志中。 创建自定义表和 DCR 来收集此数据。 定义文本日志的位置及其详细配置,以及自定义表的架构。 在工作区中引入和保留此数据需要付费。

示例日志查询

此处使用的列名仅用作示例。 你的日志的列名很可能不同。

查询 说明
MyApp_CL | summarize count() by code 通过代码统计事件的数量。
MyApp_CL | where status == "Error" | summarize AggregatedValue = count() by Computer, bin(TimeGenerated, 15m) 对任何错误事件创建警报规则。

收集 IIS 日志

Windows 计算机上运行的 IIS 将日志写入文本文件。 通过使用 Azure Monitor 代理收集 IIS 日志来配置 IIS 日志收集。 在工作区中引入和保留此数据需要付费。

IIS 日志中的记录存储在 Log Analytics 工作区的 W3CIISLog 表中。 在工作区中引入和保留此数据需要付费。

示例日志查询

查询 说明
W3CIISLog | where csHost=="www.contoso.com" | summarize count() by csUriStem 按主机的 URL www.contoso.com 统计 IIS 日志项的数量。
W3CIISLog | summarize sum(csBytes) by Computer 查看每个 IIS 计算机接收的总字节数。

监视服务或守护程序

若要监视 Windows 服务或 Linux 守护程序的状态,请在 Azure 自动化中 启用 更改跟踪和清单解决 方案。

Azure Monitor 无法单独监视服务或守护程序的状态。 有一些方法或许能够使用,例如在 Windows 事件日志中查找事件,但此方法并不可靠。 还可以从 VM 见解填充的 VMProcess 表中查找与计算机上运行的服务关联的进程。 此表的更新频率仅为每小时一次,如果想要使用此数据触发警报,通常不能满足需求。

注意

“更改跟踪和分析”解决方案不同于 VM 见解中的“更改分析”功能。 此功能处于公共预览阶段,此方案中尚未包括此功能。

有关在虚拟机上启用“更改跟踪”解决方案的不同选项,请参阅启用更改跟踪和清单。 此解决方案包括用于大规模配置虚拟机的方法。 为了支持解决方案,必须创建一个 Azure 自动化帐户

启用“更改跟踪和清单”后,将在 Log Analytics 工作区中创建两个新的表。 将这些表用于日志查询和日志搜索警报规则。

说明
ConfigurationChange 对来宾内配置数据的更改
ConfigurationData 来宾内配置数据的上次报告状态

示例日志查询

  • 列出最近启动的所有服务和守护程序。

    ConfigurationChange
    | where ConfigChangeType == "Daemons" or ConfigChangeType == "WindowsServices"
    | where SvcState == "Running"
    | sort by Computer, SvcName
    
  • 特定服务停止时发出警报。 在日志搜索警报规则中使用此查询。

    ConfigurationData
    | where SvcName == "W3SVC" 
    | where SvcState == "Stopped"
    | where ConfigDataType == "WindowsServices"
    | where SvcStartupType == "Auto"
    | summarize AggregatedValue = count() by Computer, SvcName, SvcDisplayName, SvcState, bin(TimeGenerated, 15m)
    
  • 一组服务中某个服务停止时发出警报。 在日志搜索警报规则中使用此查询。

    let services = dynamic(["omskd","cshost","schedule","wuauserv","heathservice","efs","wsusservice","SrmSvc","CertSvc","wmsvc","vpxd","winmgmt","netman","smsexec","w3svc","sms_site_vss_writer","ccmexe","spooler","eventsystem","netlogon","kdc","ntds","lsmserv","gpsvc","dns","dfsr","dfs","dhcp","DNSCache","dmserver","messenger","w32time","plugplay","rpcss","lanmanserver","lmhosts","eventlog","lanmanworkstation","wnirm","mpssvc","dhcpserver","VSS","ClusSvc","MSExchangeTransport","MSExchangeIS"]);
    ConfigurationData
    | where ConfigDataType == "WindowsServices"
    | where SvcStartupType == "Auto"
    | where SvcName in (services)
    | where SvcState == "Stopped"
    | project TimeGenerated, Computer, SvcName, SvcDisplayName, SvcState
    | summarize AggregatedValue = count() by Computer, SvcName, SvcDisplayName, SvcState, bin(TimeGenerated, 15m)
    

监视端口

端口监视验证计算机是否正在侦听特定端口。 此处介绍了端口监视的两种潜在策略。

依赖项代理表

如果使用启用了进程和依赖项收集的 VM 见解,可使用 VMConnectionVMBoundPort 来分析计算机上的连接和端口。 VMBoundPort 表每分钟更新一次,其中包含计算机上运行的每个进程及其侦听的端口。 您可以创建类似于丢失检测信号警报的日志搜索警报,以查找已停止的进程,或在计算机未在侦听特定端口时发出警报。

  • 查看 VM 上打开的端口数,来评估哪些 VM 存在配置和安全漏洞。

    VMBoundPort
    | where Ip != "127.0.0.1"
    | summarize by Computer, Machine, Port, Protocol
    | summarize OpenPorts=count() by Computer, Machine
    | order by OpenPorts desc
    
  • 列出 VM 上绑定的端口,来评估哪些 VM 存在配置和安全漏洞。

    VMBoundPort
    | distinct Computer, Port, ProcessName
    
  • 按端口分析网络活动,确定应用程序或服务的配置方式。

    VMBoundPort
    | where Ip != "127.0.0.1"
    | summarize BytesSent=sum(BytesSent), BytesReceived=sum(BytesReceived), LinksEstablished=sum(LinksEstablished), LinksTerminated=sum(LinksTerminated), arg_max(TimeGenerated, LinksLive) by Machine, Computer, ProcessName, Ip, Port, IsWildcardBind
    | project-away TimeGenerated
    | order by Machine, Computer, Port, Ip, ProcessName
    
  • 查看 VM 的发送和接收字节数趋势。

    VMConnection
    | summarize sum(BytesSent), sum(BytesReceived) by bin(TimeGenerated,1hr), Computer
    | order by Computer desc
    | render timechart
    
  • 使用一段时间的连接故障数来确定故障率是稳定还是变化。

    VMConnection
    | where Computer == <replace this with a computer name, e.g. 'acme-demo'>
    | extend bythehour = datetime_part("hour", TimeGenerated)
    | project bythehour, LinksFailed
    | summarize failCount = count() by bythehour
    | sort by bythehour asc
    | render timechart
    
  • 链接状态趋势以分析计算机的行为和连接状态。

    VMConnection
    | where Computer == <replace this with a computer name, e.g. 'acme-demo'>
    | summarize  dcount(LinksEstablished), dcount(LinksLive), dcount(LinksFailed), dcount(LinksTerminated) by bin(TimeGenerated, 1h)
    | render timechart
    

连接管理器

网络观察程序连接监视器功能用于测试与虚拟机端口的连接。 测试验证计算机是否正在侦听端口,以及是否可通过网络访问。

连接管理器要求在启动测试的客户端计算机上安装网络观察程序扩展。 无需在要测试的计算机上安装。 有关详细信息,请参阅教程:使用 Azure 门户监视网络通信

需要额外付费才能使用连接管理器。 有关详细信息,请参阅网络观察程序定价

在本地计算机上运行进程

某些工作负荷的监视需要本地进程。 例如,在本地计算机上运行的 PowerShell 脚本可以连接到应用程序并收集或处理数据。 可以使用 Azure 自动化中包含的混合 Runbook 辅助角色来运行本地 PowerShell 脚本。 混合 Runbook 辅助角色本身是免费的,但它使用的每个 Runbook 并不免费。

Runbook 可以访问本地计算机上的任何资源来收集所需的数据。 Runbook 无法直接将数据发送到 Azure Monitor 或创建警报。 若要创建警报,请让 runbook 将条目写入自定义日志。 然后,将该日志配置为由 Azure Monitor 进行收集。 创建针对该日志条目触发的日志搜索警报规则。

后续步骤