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

系统指标和来宾 OS 性能计数器的 PromQL

本文提供了在 Azure Monitor 中使用 PromQL 查询 OpenTelemetry 系统指标以及来宾操作系统性能计数器的指导。 这包括 Azure Monitor 代理或 OpenTelemetry 收集器收集系统级遥测数据的情况。

小窍门

系统指标查询在以工作区为范围的模式和以资源为范围的模式中都起作用。 使用资源范围的查询时,应筛选并分组"Microsoft.resourceid",而不是使用泛型标识符如instancehost.name,以确保准确限定到您的资源。

先决条件

系统指标概述

OpenTelemetry 系统指标通过标准化的指标名称和语义约定,提供对客户操作系统性能的全面洞察。

核心系统指标类别

类别 OpenTelemetry 指标 传统等效项
中央处理器 system.cpu.utilization 处理器时间百分比
Memory system.memory.usagesystem.memory.utilization 可用内存、内存使用情况
磁盘 system.disk.io.bytessystem.disk.operations 磁盘字节数/秒、磁盘作数/秒
Network system.network.io.bytessystem.network.packets 网络字节数/秒、数据包数/秒
过程 process.cpu.utilizationprocess.memory.usage 特定于进程的计数器

CPU

# Dashboarding CPU utilization when query is scoped to a single VM resource
100 * (1 - avg ({"system.cpu.utilization", state="idle"}))

# Dashboarding to identify CPU hotspots across a fleet of VMs, scoped to an AMW, subscription or resource group
topk (5, 100 * (1 - avg by ("Microsoft.resourceid") ({"system.cpu.utilization", state="idle"})))

# Alerting on high CPU utilization, scoped to a single VM
avg_over_time({"system.cpu.utilization"}[5m]) > 0.8

# Dashboarding to identify top 5 CPU-consuming processes by command, scoped to a single VM.
topk(5, sum by ("process.command") ({"process.cpu.utilization"}))

# Identify CPU-bound processes, scoped to a single VM
{"process.cpu.utilization"} > 0.5

内存

# Dashboarding available MB, scoped to a single VM
(sum ({"system.memory.limit"}) - sum ({"system.memory.usage", state="used"})) / (1024 * 1024)

# Alerting on high memory utilization
{"system.memory.utilization", state="used"} > 0.9

磁盘输入输出

# Dashboarding disk total throughput (Bytes/sec), scoped to a single VM. Can be filtered to Read or Write.
sum by (device, direction) rate({"system.disk.io"}[5m]) 

# Dashboarding disk total operations per second, scoped to a single VM. Can be filtered to Read or Write.
sum by (device, direction) rate({"system.disk.operations"}[5m]) 

# Dashboarding top 5 processes by disk operations (read and write), scoped to an AMW, subscription or resource group.
topk(5, sum by ("process.command", direction) (rate({"process.disk.operations"}[5m])))

# Alerting on high disk activity detection, scoped to a single VM.
rate({"system.disk.operations"}[5m]) > 1000

从 KQL 迁移到 PromQL

本部分提供针对系统性能计数器及其 PromQL 等效项的常见 KQL 查询的并行比较。 每个示例都包括一对一迁移和针对 Prometheus 优化的推荐方法。

重要

所有 PromQL 查询都使用 Prometheus 3.0 中引入的 UTF-8 转义语法。 包含点的标签名称(如 Microsoft.resourceid)和指标名称必须用引号括起来并移入大括号,如 Prometheus 3.0 版本中所述。

KQL:每 15 分钟平均 CPU 使用率百分比

Perf 
| where CounterName == "% Processor Time"
| where ObjectName == "Processor"
| summarize avg(CounterValue) by bin(TimeGenerated, 15m), Computer, _ResourceId

PromQL:类似迁移

此查询通过以下方法计算 CPU 利用率,以复制 KQL 的行为:

100 * (
  1 -
  (
    sum by ("Microsoft.resourceid") (rate({"system.cpu.time", state="idle"}[15m])) /
    sum by ("Microsoft.resourceid") (rate({"system.cpu.time"}[15m]))
  )
)

查询参数:

  • 步骤: 15m (匹配 KQL 箱大小)

理由: 复制 Windows 的计算方法,并使用相同的时间箱大小,以便直接进行比较。

100 * (1 - avg by ("Microsoft.resourceid") ({"system.cpu.utilization", state="idle"})) 

查询参数:

  • 步: 1m

理由: 如果您的收集器发出更清洁的 system.cpu.utilization 指标,请使用它。 1 分钟的步骤提供更高分辨率的仪表板和更响应的警报。

KQL:磁盘每秒读取次数超过 5 分钟

Perf
| where ObjectName == "LogicalDisk" and CounterName == "Disk Reads/sec"
| summarize avg(CounterValue) by bin(TimeGenerated, 5m), Computer, _ResourceId

PromQL:类似对等迁移

sum by ("Microsoft.resourceid", device) (
  rate({"system.disk.operations", direction="read"}[5m])
)

查询参数:

  • 步: 5m

理由: 完全匹配 KQL bin(TimeGenerated, 5m) ,按资源和设备聚合。

sum by ("Microsoft.resourceid", device) (
  rate({"system.disk.operations", direction="read"}[1m])
)

查询参数:

  • 步: 1m

理由: 提高仪表板的响应能力指标,同时保持准确性。 1 分钟速率计算提供更流畅的可视化效果。

KQL:随时间变化的可用内存

// Virtual Machine available memory 
// Chart the VM's available memory over time. 
Perf
| where ObjectName == "Memory" and
    (CounterName == "Available MBytes Memory" or  // Linux records
     CounterName == "Available MBytes")            // Windows records
| summarize avg(CounterValue) by bin(TimeGenerated, 15m), Computer, _ResourceId
| render timechart

PromQL:同类迁移

此查询聚合多个内存状态,以计算 Linux 和 Windows 中的可用内存:

# Available MB, scoped to a single VM
(sum ({"system.memory.limit"}) - sum ({"system.memory.usage", state="used"})) / (1024 * 1024)

查询参数:

  • 步: 15m

理由: 聚合表示操作系统中可用内存的内存状态。 将字节转换为兆字节以匹配 KQL 计数器输出。 使用 15 分钟的步骤来匹配箱大小。

avg by ("Microsoft.resourceid") ({"system.memory.utilization"})

查询参数:

  • 步: 5m

理由: 警报和自动缩放方案受益于不需要昂贵的正则表达式筛选器或单元转换的利用率指标。

KQL:最低 10 个磁盘可用空间百分比

// Bottom 10 Free disk space % 
// Bottom 10 Free disk space % by computer, for the last 7 days. 
Perf
| where TimeGenerated > ago(7d)
| where (ObjectName == "Logical Disk" or ObjectName == "LogicalDisk") 
    and CounterName contains "%" 
    and InstanceName != "_Total" 
    and InstanceName != "HarddiskVolume1"
| project TimeGenerated, Computer, ObjectName, CounterName, InstanceName, CounterValue 
| summarize arg_max(TimeGenerated, *) by Computer
| top 10 by CounterValue desc

PromQL:一对一迁移

sum by ("Microsoft.resourceid", device, mountpoint, type) (
  {"system.filesystem.usage", state="free", type=~"ext4|xfs|btrfs|ntfs|vfat"}
) / (1024 * 1024)

查询参数:

  • 时间范围: 7d

理由: 将字节转换为兆字节以匹配 Windows 计数器输出。 使用正则表达式模式匹配筛选常见文件系统类型,并排除系统卷。

KQL 与 PromQL 语法比较

下表突出显示了从 KQL 迁移到 PromQL 时的关键语法差异:

概念 KQL 语法 PromQL 语法
时间分箱 bin(TimeGenerated, 15m) 在查询 API 中使用 step 参数(例如 step=15m
速率计算 CounterValue(已完成评级) rate(metric[5m]) 用于计数器指标
合并 summarize avg(CounterValue) by Computer avg(metric) by ("Microsoft.resourceid")
资源筛选 where _ResourceId == "..." {metric, "Microsoft.resourceid"="..."}
字符串匹配 where Name contains "pattern" {metric, name=~".*pattern.*"}
带点的标签 _ResourceId (下划线前缀) "Microsoft.resourceid" (引文)
带点的指标名称 N/A - 使用 table.column {"system.cpu.utilization"} (引文)
时间范围 where TimeGenerated > ago(7d) API 参数: startend
前 N 个结果 top 10 by CounterValue desc topk(10, metric)

小窍门

在 Azure Monitor 中使用 PromQL 时,始终为包含点(如 "Microsoft.resourceid")的标签名称和包含点(如 {"system.cpu.utilization"})的指标名称加引号。 Prometheus 3.0+ 中需要此 UTF-8 转义语法,以防止常见的解析错误。