4. 指标资源管理器与指标警报

Azure Monitor 的指标数据是生产诊断中最“便宜”也最“快”的一类信号：它以固定时间间隔采集、保留期长、查询延迟低，并且天然支持聚合与切片。指标资源管理器（Metrics Explorer）就是消费这些指标的入口，而指标警报则把“人去看图”变成“系统主动通知”。本节围绕这两件事展开：先用 Metrics Explorer 把平台指标和自定义指标画出来、切出来、算出来，再把同一套指标查询固化成静态或动态警报，并挂上操作组完成通知与自动化。

一、Metrics Explorer 的查询模型：命名空间—指标—聚合—筛选—拆分

Metrics Explorer 的每一次绘图，本质上都是一次指标查询。它由五个要素构成，理解这五个要素，比记住界面按钮更重要：

• 命名空间（Namespace）：指标所属的资源提供程序或自定义命名空间，例如 Microsoft.Compute/virtualMachines、Microsoft.Web/sites，自定义指标常用 customMetrics 或应用自定义命名空间。
• 指标（Metric）：具体的时间序列名称，如 Percentage CPU、Available Memory Bytes、Http5xx、Requests。
• 聚合（Aggregation）：把采样点压缩成一个数值，常见有 Avg、Min、Max、Sum、Count。选择错误会直接导致误判，例如用 Avg 看 CPU 会掩盖短时尖峰，用 Max 看请求数会失去总量含义。
• 筛选（Filter）：按维度值缩小范围，例如只保留 StatusCode = 500 或 Instance = vm-01。
• 拆分（Split）：按某个维度把一条线拆成多条线，例如按 Instance 拆分查看每台实例的 CPU，或按 ApiName 拆分查看各接口延迟。

时间范围与时间粒度同样关键。粒度（Time grain）决定每个数据点覆盖多长时间，通常应满足“粒度 × 数据点数 ≤ 时间范围”，并尽量让粒度与指标原始采样间隔对齐。若原始间隔是 1 分钟，却把粒度设为 5 分钟，聚合会把 5 个点合并，短时抖动会被平滑掉。

二、平台指标与自定义指标的实际探索

平台指标由 Azure 资源提供程序自动发出，无需埋点。以一台 Linux 虚拟机为例，常见可用指标包括 Percentage CPU、Available Memory Bytes、Disk Read Operations/Sec、Network In Total。在 Metrics Explorer 中，选择该 VM 资源，命名空间选 Microsoft.Compute/virtualMachines，指标选 Percentage CPU，聚合选 Avg，时间范围选“最近 1 小时”，粒度 1 分钟，即可得到一条 CPU 曲线。若把聚合改为 Max，同一时间范围内曲线会整体抬高，因为每个粒度窗口取的是峰值——这正是“聚合改变语义”的直接体现。

自定义指标需要应用侧主动上报。常见方式有两种：一是通过 Application Insights SDK 的 TrackMetric 或 GetMetric 上报；二是通过 Azure Monitor 指标 REST API 向资源的 customMetrics 命名空间写入。例如一个订单服务可以上报 OrderProcessingLatencyMs，并携带维度 Region 和 PaymentMethod。上报后，在 Metrics Explorer 中把命名空间切到该资源的自定义命名空间，就能像平台指标一样筛选、拆分和聚合。自定义指标的价值在于把业务语义带进监控，例如“支付成功率”比“HTTP 5xx 数量”更贴近业务结果。

三、静态指标警报：固定阈值与评估窗口

静态警报使用固定阈值。创建时需明确五个参数：目标资源与指标、聚合类型、阈值与比较符、评估频率、回看窗口。以 VM CPU 为例，一个合理的示例配置是：指标 Percentage CPU，聚合 Avg，比较符“大于”，阈值 80，评估频率 1 分钟，回看窗口 5 分钟。这意味着每 1 分钟评估一次，检查过去 5 分钟内所有 1 分钟数据点的平均值是否超过 80；若超过则触发。回看窗口大于评估频率，可以避免单点抖动造成误报。

静态警报的优点是行为可预测、易于解释；缺点是阈值需要人工设定，且难以适应业务周期性。对于有明显昼夜波动的指标（如白天请求量高、夜间低），固定阈值要么白天频繁误报，要么夜间漏报。

四、动态指标警报：让基线随数据自适应

动态警报使用机器学习自动学习指标的历史模式，包括趋势、周期性和波动范围，然后根据当前值与预测基线的偏离程度判断异常。创建时不再填固定阈值，而是设置敏感度（Low / Medium / High）和违反次数（即连续多少个评估窗口异常才触发）。敏感度越高，越容易触发，误报也越多；违反次数越多，越能过滤瞬时抖动，但响应会变慢。

动态警报适合具有周期性、但难以手工设定阈值的指标，例如每日请求量、夜间批处理耗时、缓存命中率。它不适合数据量极少或模式不稳定的指标，因为模型无法建立可靠基线。实践中建议先用 Metrics Explorer 观察至少一周的曲线，确认存在可学习的周期后再启用动态警报。

五、关联操作组：从“知道”到“行动”

警报本身只产生状态变化，真正让值班人收到通知、让系统自动响应的是操作组。操作组是一组可复用的通知与动作集合，常见成员包括：邮件、短信、语音、移动推送、Webhook、Logic Apps、Automation Runbook、Azure Function、ITSM 连接器。创建警报规则时，在“操作”页签选择已有操作组，或新建一个。建议按“通知对象”和“响应动作”拆分操作组，例如 ag-oncall-dba 负责通知数据库值班人，ag-auto-restart 负责调用 Runbook 重启服务，避免把所有动作塞进一个操作组导致职责混乱。

六、一个可复用的配置示例

下面给出一个静态警报的 ARM 模板片段，用于对 VM 平均 CPU 超过 80% 持续 5 分钟时触发，并关联一个已存在的操作组。示例中的资源 ID 和操作组 ID 为占位符，实际使用时替换为真实值。

{
  "type": "Microsoft.Insights/metricAlerts",
  "apiVersion": "2018-03-01",
  "name": "alert-vm-cpu-high",
  "location": "global",
  "properties": {
    "description": "VM 平均 CPU 连续 5 分钟超过 80%",
    "severity": 2,
    "enabled": true,
    "scopes": [
      "/subscriptions/<sub-id>/resourceGroups/rg-prod/providers/Microsoft.Compute/virtualMachines/vm-01"
    ],
    "evaluationFrequency": "PT1M",
    "windowSize": "PT5M",
    "criteria": {
      "odata.type": "Microsoft.Azure.Monitor.SingleResourceMultipleMetricCriteria",
      "allOf": [
        {
          "name": "cpu-high",
          "metricNamespace": "Microsoft.Compute/virtualMachines",
          "metricName": "Percentage CPU",
          "operator": "GreaterThan",
          "threshold": 80,
          "timeAggregation": "Average",
          "criterionType": "StaticThresholdCriterion"
        }
      ]
    },
    "actions": [
      {
        "actionGroupId": "/subscriptions/<sub-id>/resourceGroups/rg-ops/providers/Microsoft.Insights/actionGroups/ag-oncall"
      }
    ]
  }
}

部署后，可在 Azure Monitor 的“警报”页面查看规则状态、触发历史与已解决实例。判断警报是否合理，重点看三个信号：触发频率是否与真实故障相关、是否存在大量“已解决”但无人处理的噪声、以及从触发到通知的延迟是否满足响应要求。若噪声过多，优先调整回看窗口、违反次数或改用动态警报，而不是简单调高阈值掩盖问题。

把 Metrics Explorer 的查询与警报规则对齐，是这套机制的关键：图上看到的曲线形态、聚合方式和拆分维度，应当与警报使用的指标、聚合和窗口一致。否则会出现“图上正常、警报却响”或“图上已经异常、警报没反应”的割裂。建议在创建警报前，先在 Metrics Explorer 中固定好查询并保存到仪表板，再以同一查询为蓝本创建警报，形成从探索到告警的一致闭环。