本文聚焦Azure Stack Hub 的监控核心理念、告警生成机制、健康资源提供程序HRP、Dell 硬件生命周期主机HLH、管理员门户可见性这五大基础设施层 ——不直接展开 ITSM 集成方案、不展开补丁与更新流程那两个主题分别由本系列中篇和下篇承接。系列预告本篇为Azure Stack Hub 监控与更新三篇系列 · 监控与更新第 1 篇监控理念与告警篇第 1 篇本文监控理念与告警机制 —— 一体机设计原则、ALERTS、HRP、Dell HLH、管理员门户告警。第 2 篇中篇监控和集成 —— ITSM 集成SCOM / Nagios / SNMP / BMC、运维场景、租户订阅监控。第 3 篇下篇补丁与更新 —— 服务策略、Microsoft 更新类型、版本控制、Portal / PowerShell 操作、上传 / 安装 / 恢复 / 日志、Dell PU 工具。版本基础本文基于azs-1901 至当前主流 azs 版本的 Azure Stack Hub Operator 文档整理。不同 OEM 集成系统以及不同 azs 版本之间可能存在差异当版本与本文表述不一致时以当期版本 Azure Stack Hub Operator 文档 当期 OEM Support Matrix 为准。修订说明:本篇为Azure Stack Hub 监控与更新三篇系列 · 监控理念与告警篇首发版基于内训演示材料《Azure Stack Hub 监控与更新》中监控概览章节整理按四层原则做工程化改写。目录监控问题空间为什么不能加指标就完事告警是一体机的核心交互入口一体机设计原则监控与操作的核心约束监控组件全景谁负责发告警、谁负责接告警健康资源提供程序 HRP告警的中央调度Dell 硬件生命周期主机HLH硬件侧的运维跳板Dell-MGMTVMHLH 上的 OEM 管理中枢管理员门户告警的可视化层HRP 编程入口REST API PowerShell告警处理示例三类典型告警的 SOP三个常见误判信号上篇小结监控理念的工程化整合1. 监控问题空间为什么不能加指标就完事Azure Stack Hub 是一套集成系统一体机由多台服务器与交换机组成的。很多首次接触它的工程师会用管普通 Hyper-V 集群 / 管普通 Azure VM的思路去理解它的监控 —— 但这种思路会丢掉三个关键差异1.1 三层复杂性Azure Stack Hub 监控的对象一台一体机不是多台机器 ┌────────────────────────────────────────────────────┐ │ 应用 / 租户 VM 运行状况Hyper-V 子层 │ ├────────────────────────────────────────────────────┤ │ Azure Stack Hub 软件栈HRP / NRP / ACS / ... │ ├────────────────────────────────────────────────────┤ │ 物理硬件节点 / JBOD / 网络交换机 / 电源 │ └────────────────────────────────────────────────────┘这三层的监控责任分属不同主体应用 / 租户 VM 层—— 由租户自己负责Azure Stack Hub 软件栈层—— 由微软 HRP 负责发告警物理硬件层—— 由 OEMDell / HPE / Lenovo / Cisco BMC带外管理负责这三层之间不是简单的上层用下层 API而是有清晰边界的责任切分云管理员拿到的告警绝大多数来源于 HRP 与 OEM 监控工具而不是直接对着 VM 取指标任何我去 VM 里拉指标看健康的做法 —— 都会漏掉节点下线、JBD 故障、交换机端口 down等最常见的一体机故障信号。1.2 健康 ≠ 指标加和L1 微软核心原则Azure Stack Hub 的运行状况不是其各部分指标之和。一个集群可能所有磁盘 SMART 都健康、所有 CPU 都在跑、所有网络端口都up——但仍然可能处于不健康状态。比如 S2D 复制链路降级、HRP 与节点控制面通信中断、Software Load Balancer MUX 处于 degraded 状态 ——都不会在传统指标 阈值模型里被捕捉。这就是为什么 Azure Stack Hub 的监控模型是告警驱动alert-driven而不是指标聚合metric-aggregated每个组件定义自己的健康语义对外只暴露有 / 没有告警这两个状态而不是一堆 raw metric。1.3 告警与运行状况的关系L1 微软硬要求Azure Stack Hub 的告警严格遵循组件健康 ↔ 告警一一对应原则如果某个组件是 healthy 的就不应该有任何未清告警如果有告警对应的组件必然处于 unhealthy 状态。这条原则意味着告警不是额外的可选项而是一体机的状态镜像。从这个角度反推下一节的一体化设计原则就自然理解了。2. 告警是一体机的核心交互入口Azure Stack Hub 的设计目标是让云管理员对它的绝大部分交互都从告警开始。这句话听上去激进但拆开看是合理的。2.1 一体机的核心交互模式L1 微软硬要求管理员行为触发源是否合规主动登入管理员门户逐项检查指标管理员本人⚠ 不推荐 — 应由告警驱动收到基础结构角色无响应告警 → 进入修复流程告警 → HRP✅ 合规路径没有任何告警 → 主动重启 ERCS01管理员本人❌ 不合规 — 这类变更应由告警触发收到物理磁盘出现故障告警 → 走磁盘更换流程告警 → HRP✅ 合规路径核心判断在没有告警的情况下管理员不需要、也不应该主动变更系统状态。这是 Azure Stack Hub 一体机设计与公有云运维的最大差异 —— 公有云鼓励工程师主动建 / 拆资源一体机则严禁无目的变更。2.2 无告警 不动原则的工程意义这条原则带来三个工程意义减少误操作管理员手抖改坏一个配置的概率被显著降低 —— 一切变更都有理据可查哪条告警驱动的变更可追溯HRP 的告警→管理员动作流程天然形成审计链故障定位更收敛当故障发生时告警会成为已经发生了什么的明牌避免管理员再去挨个组件排查 ——告警告诉你该看哪里。2.3 但这不是消极运维这条原则不是说管理员等告警即可 —— 而是主动管理不等于盲目变更计划维护补丁、固件升级有专门流程下篇会展开不是告警驱动容量扩容在容量阈值告警触发后按下篇流程执行租户 / 自助服务请求由租户门户处理与管理员告警流程相互独立。3. 一体机设计原则监控与操作的核心约束L1 微软硬要求Azure Stack Hub 监控与操作的设计原则全部围绕一体化这个根本目标。以下是 PPT 列出的几条核心原则3.1 告警的语义约束每条告警必须满足三个特征缺一不可特征含义反例不合格告警易于理解的影响和后续步骤告警描述里能直接告诉管理员发生了什么 该做什么节点异常没说怎么影响 怎么修使用常见管理员操作模式可以解决告警的修复流程必须走管理员门户 / PEP / PowerShell 标配路径请联系 OEM 工程师这不是默认路径特定于 Azure Stack Hub告警是 Azure Stack Hub 这一体机特有的不是 Windows Server / Hyper-V 的通用告警直接转发Windows 事件日志 12345没解释对一体机的具体含义3.2 设计原则的工程含义这三条特征本质上把告警的可用性做了强约束告警必须有前因后果——管理员读了就知道现在该怎么办修复流程必须是通常路径——避免出现只有 OEM 工程师能处理的告警告警必须体现一体机的特殊性——避免 Windows Server 通用告警淹没一体机特有告警。4. 监控组件全景谁负责发告警、谁负责接告警Azure Stack Hub 的告警由多个来源并发生成由HRP 统一调度通过管理员门户、PowerShell、REST API 暴露给管理员。同时硬件侧的告警由OEM 监控工具Dell OpenManage 等独立暴露由 HLH 上的 Dell-MGMTVM 调度。4.1 监控组件全景图┌────────────────────────────────────────────────────────────────────┐ │ Azure Stack Hub 一体机 │ │ ┌──────────────────────────────────────────────────────────────┐ │ │ │ Azure Stack Hub 软件栈 │ │ │ │ ┌────────────────────────────────────────────────────────┐ │ │ │ │ │ 各组件内置健康服务ECE / RP / FC / ACS / ... │ │ │ │ │ │ ↓ 暴露告警 / 运行状况 │ │ │ │ │ │ HRPHealth Resource Provider │ │ │ │ │ │ ↓ 统一调度 │ │ │ │ │ └────────────────────────────────────────────────────────┘ │ │ │ │ │ │ │ │ ACSAzure Consistent Storage / S2D / Tenant VM / etc. │ │ │ └──────────────────────────────────────────────────────────────┘ │ │ │ │ ┌──────────────────────────────────────────────────────────────┐ │ │ │ 物理硬件节点 / JBOD / 网络交换机 │ │ │ │ ↓ BMC / SNMP 暴露 │ │ │ │ HLH 上的 Dell-MGMTVMOEM 监控 Support Gateway 调度 │ │ │ └──────────────────────────────────────────────────────────────┘ │ └────────────────────────────────────────────────────────────────────┘ │ ┌──────────────────────┼──────────────────────────┐ ▼ ▼ ▼ 管理员门户 REST API / PowerShell OEM 监控工具 (Alert-Driven UX) (HRP 编程入口) (独立运维链)4.2 三类监控责任主体主体监控对象暴露方式责任团队HRPHealth Resource ProviderAzure Stack Hub 软件栈所有组件管理员门户告警 / REST API / PowerShell微软HRP 是微软组件Dell HLH 上的 Dell-MGMTVM物理硬件节点 / JBOD / 交换机SCOM / Nagios / Secure Connect GatewayOEMDell—— 与系统级告警流程并行SNMP独立通道网络交换机ToR / BMCSNMP trap网络运维团队按 SNMP 标准4.3 为什么需要两个并行而不是一个大统一这是设计选择问题不是技术不能HRP 不能直接读硬件传感器—— 微软的组件不能假定知道Dell 节点 iDRAC 的最新 API。这部分是 OEM 的实现领域。硬件监控需要 OEM 的领域知识—— 同一型号节点可能因 firmware / BIOS 版本差异产生不同的传感器数据OEM 才是真正的知情人。冗余是设计意图—— 软件栈故障时硬件监控链路独立工作硬件故障时HRP 仍能上报软件层状态。5. 健康资源提供程序 HRP告警的中央调度L0 版本事实HRPHealth Resource Provider是 Azure Stack Hub 的唯一对外告警出口。所有微软组件的健康信号最终都会经 HRP 收敛后通过管理员门户、REST API、PowerShell 暴露。5.1 HRP 的核心职责接收组件级健康信号HRP 从 ECEEmergency Console Endpoint/ 各 RP / FCFailover Cluster/ ACS 等组件订阅健康信号去重与合并多个组件报告同一问题时HRP 合并为单一告警丰富语义HRP 给每条告警附加影响描述 修复步骤 —— 这就是 §3.1 提到的易于理解特征的来源稳定暴露HRP 持续暴露告警直到管理员确认resolve / acknowledge。5.2 HRP 的告警生命周期L2 微软实现告警在 HRP 里有清晰的几种状态状态含义管理员动作Active当前告警已发出对应组件仍 unhealthy排查 修复Acknowledged管理员已确认收到告警但未完成修复进入修复流程Resolved告警自动消失组件已恢复关闭告警 / 复盘注意Acknowledged ≠ Resolved。管理员可以先 ack 告警、晚点修但只要组件还没真正修复告警的 underlying condition 还存在。5.3 告警命名与标签每条 HRP 告警都带有结构化字段name告警标识机器可读severity严重性Critical / Warning / 等affectedResourceId受影响的资源 IDstate状态Active / Acknowledged / Resolveddescription人类可读描述remediation修复步骤链接L1 微软硬要求管理员不能手动写入或删除 HRP 告警 —— HRP 的告警生成与状态完全由内部组件状态驱动。这是 §3 提到告警 组件健康镜像的具体实现保证。6. Dell 硬件生命周期主机HLH硬件侧的运维跳板L2 OEM 实现HLHHardware Lifecycle Host是 Azure Stack Hub 一体机之外、由 OEM 提供的独立管理服务器。它不属于 Azure Stack Hub 一体机本身但承担了硬件侧的运维责任。6.1 HLH 的两个核心角色角色用途OEM 硬件监控的中枢HLH 上跑 OEM 监控工具订阅 BMC / SNMP 信号发硬件告警故障日志归档故障排查期间HLH 可用于存储从 Azure Stack Hub 一体机中拉取的日志PEP 收集的日志落到 HLH 上做二次分析OEM Update 调度机OEM 扩展包硬件固件 / 驱动 / HLH OS 更新由 HLH 上的 OEM 工具发起并记录6.2 HLH 的 Hyper-V 角色L2 Dell 实现HLH 本身是一台带 Hyper-V 角色的物理服务器。上面运行多个来宾 VM其中最关键的是Dell-MGMTVM下一节展开。HLH 与 Azure Stack Hub 一体机的关系网络隔离HLH 通常位于 Azure Stack Hub 一体机的带外管理网络OOB与一体机的租户网络 / 控制面网络相互隔离访问控制HLH 的访问通常由 OEM / 客户运维团队控制微软云管理员通常不直接登录 HLH数据流HLH 通过带外网络读取 BMC / SNMP 信号通过 OEM 工具把数据写回 Dell 后台由 Dell-MGMTVM 上的 Secure Connect Gateway 调度。6.3 HLH 与一体机的责任边界L3 最佳实践HLH 是 OEM 的责任面—— 它的故障、更新、补丁通常由 OEM Support 团队主导微软云管理员不能也不应该直接修改 HLH 上的配置即使是 OEM 也不能直接修改 Azure Stack Hub 一体机内部HLH 的硬件告警独立于 HRP与一体机的软件告警并行流入监控仪表盘。7. Dell-MGMTVMHLH 上的 OEM 管理中枢L2 Dell 实现Dell-MGMTVM是 HLH 上运行的关键来宾 VM承担 OEM 侧的硬件管理责任。7.1 Dell-MGMTVM 的三个职责职责说明失败影响托管 Dell Secure Connect GatewaySCG 是 Dell 的远程支持通道负责自动创建硬件告警支持案例硬件故障时无法自动开 Dell case需手工报修OEM 扩展包安装的硬件管理器OEM 更新包固件 / 驱动由 MGMTVM 调度扩展包更新无法自动执行需 OEM 现场支持硬件清单 监控聚合通过 BMC 拉硬件清单、聚合传感器数据给 SCOM / Nagios硬件监控能力下降7.2 SCGSecure Connect Gateway的运维含义L2 OEM 实现SCG 是 Dell 的远程支持组件它自动把硬件告警特别是 Critical升级为 Dell Support Case通过加密通道回传硬件日志依赖HTTPS 出栈到 Dell 后台—— 在气隙 / 离线环境里需要配置替代通道详见本系列下篇 I.7。L3 最佳实践SCG 的连通性是 HLH 健康度的关键信号 —— 客户运维通常会在 SCOM / 自建监控里单独 ping SCG 心跳作为Dell 后台链路是否通的指标。8. 管理员门户告警的可视化层L0 版本事实Azure Stack Hub 管理员门户区别于用户门户是告警集中呈现的界面。它把 HRP、OEM 监控工具的告警按统一格式呈现让管理员在一个屏幕里看清整个一体机的健康状态。8.1 管理员门户的告警视图管理员门户里的告警区域通常呈现以下信息当前 active 告警—— 列出现有所有未解决告警告警严重性—— 用颜色 / 图标区分Critical / Warning / Informational告警组件—— 指向 HRP 中的具体资源基础结构角色 / 物理磁盘 / 内存容量 ...建议修复链接—— 管理员点告警可以看到完整修复步骤。8.2 管理员门户的角色边界L1 微软硬要求入口角色不能做的管理员门户微软云管理员不能改物理硬件 / OEM 配置HLH 上的 Dell-MGMTVMOEM / 客户运维不能动 Azure Stack Hub 一体机内部OEM SCOM / NagiosOEM / 网络运维通过 HRP REST API 集成但不能绕过 HRP 直接改告警8.3 告警驱动 vs 自助运维的两条路径L3 最佳实践管理员门户里通常不应该主动触发以下操作重启 ERCS VM除非收到对应告警重启基础结构角色除非告警显示该角色 unhealthy切换网络交换机端口除非网络监控告警。这些都是先告警再操作的典型场景。管理员主动执行可能造成状态污染 —— 即使看起来成功了HRP 上仍会显示 unhealthy因为组件没有走正常恢复路径。9. HRP 编程入口REST API PowerShellL0 版本事实HRP 对外暴露REST API与PowerShell cmdlet允许以编程方式访问告警与组件健康状态。9.1 REST API 入口速查HRP 的 REST API 与管理员门户同源 —— 同一份数据、两种展现GET {endpoint}/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.AzureStackHCI/.../health GET {endpoint}/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.AzureStackHCI/.../alerts POST {endpoint}/.../alerts/{alertId}/acknowledge POST {endpoint}/.../alerts/{alertId}/resolveL2 微软实现GET是只读的获取告警列表 / 单条告警详情POST acknowledge / resolve是可写的但这些操作不能直接消除 underlying 故障只是标记管理员对告警的处理进度。9.2 PowerShell cmdlet 速查与 REST API 对应的 PowerShell cmdlet通常位于 Az PowerShell 模块或 Azure Stack Hub 专用模块Cmdlet用途Get-AzsAlert列出告警Get-AzsAlertDetail看单条告警详情Set-AzsAlert标记告警状态acknowledge / resolveGet-AzsRegionHealth看一体机区域级健康摘要L3 最佳实践REST API 与 PowerShell 的主要使用者是 OEM 监控工具SCOM / Nagios的集成适配器微软云管理员通常从管理员门户操作即可。但当管理员门户不可用时REST API PowerShell 是唯一可走的兜底路径。10. 告警处理示例三类典型告警的 SOPL1 微软硬要求以 PPT 给出的三类典型告警为例说明告警→修复的标准流程。10.1 基础结构角色无响应Critical字段值告警名称基础结构角色无响应严重性Critical组件计算控制器含义HRP 探测计算控制器基础结构角色时未收到响应修复步骤1. 导航到计算控制器基础结构角色并重新启动该角色br2. 如果问题仍然存在请与支持人员联系L3 最佳实践步骤 1 重启基础结构角色应当用管理员门户的标准重新启动基础结构角色流程不要直接Stop-VMStart-VM重启动作本身会产生审计事件。10.2 Azure Stack Hub 区域中的内存容量不足Warning字段值告警名称Azure Stack Hub 区域中的内存容量不足严重性Warning组件容量管理含义一体机区域可用内存低于阈值修复步骤1. 使用容量管理管理边栏选项卡将节点添加到缩放单元L3 最佳实践内存容量告警的修复路径是扩容而非重启服务——重启通常无法释放结构性内存压力。10.3 物理磁盘出现故障Warning字段值告警名称物理磁盘出现故障严重性Warning组件容量管理含义位于某位置的物理磁盘出现故障修复存储虚拟磁盘的过程已启动修复步骤1. 更换物理磁盘以确保全部容量和复原能力br2. 单击此按钮以了解有关执行磁盘更换过程的更多信息自动响应已自动启动存储虚拟磁盘修复流程L3 最佳实践磁盘告警通常是已经自动处理 提醒管理员换盘的复合告警。修复存储虚拟磁盘的过程已启动说明 S2D 已经为重建预留容量 —— 这意味着即使管理员不立即换盘数据有暂时保障但应当尽快换盘以重建冗余。10.4 三类告警的组合反应实际生产里多个告警可能同时出现节点断电 → 基础结构角色无响应Critical 物理磁盘出现故障Warning因 I/O 卡死触发 内存容量下降Warning因可用节点减少管理员应按 Critical → Warning 排序处理但不局限于按报警时间顺序 ——优先级以严重性为第一维度。11. 三个常见误判信号实操里最常见的假象——管理员初次接触 Azure Stack Hub 告警时容易误判。下面补充三条 L3 最佳实践层面的常见误判补足11.1 HLH 关机 ≠ 一体机故障HLH 是独立于Azure Stack Hub 一体机的硬件侧设备。HLH 暂时失联或关机不影响一体机租户 VM 的运行——但会影响硬件告警能力。管理员看到 HLH 关闭信号时不应立即怀疑一体机故障应分开诊断。11.2 管理员门户短暂空白 ≠ 状态丢失管理员门户在重负载或后台任务运行时偶发短暂空白数秒。这种空白不代表 HRP 状态丢失底层告警正常累积管理员可以做主动等待 刷新不要因为短暂空白就触发一系列应急操作。11.3 节点重启属正常恢复路径单节点重启属于 Azure Stack Hub 的正常恢复路径如自动 failover 或维护模式操作。管理员看到节点重启事件时应先看是否伴随告警——若没有 Critical / Warning 告警伴随通常不需要任何处置。12. 上篇小结监控理念的工程化整合本文围绕 PPT 中监控概览章节slide 1-11展开了Azure Stack Hub 一体机监控的核心设计原则与告警机制§1-3阐述监控的复杂性来源、告警驱动模型、一体机设计的三大原则§4-5拆解 HRP 与监控组件全景明确 HRP 作为告警唯一对外出口的角色§6-7拆解 Dell HLH 与 Dell-MGMTVM明确硬件侧独立监控链与一体机软件侧的关系§8-9阐述管理员门户与编程入口REST API PowerShell让管理员从可视化与自动化两个维度访问告警§10给三类典型告警的 SOP 样本§11补充三条实操常见误判信号。与本系列中篇衔接本文聚焦HRP 与告警机制没有展开ITSM 集成SCOM / Nagios / SNMP / BMC 如何把告警接入现有运维体系、没有展开租户订阅健康监测等监控集成话题。这些由中篇《Azure Stack Hub 监控与集成从 ITSM 到运维场景》承接。与本系列下篇衔接本文没有展开补丁与更新流程。Microsoft 更新 / Dell 扩展包 / 上传 / 安装 / 恢复 / 日志 / Dell PU 工具等内容统一在下篇《Azure Stack Hub 补丁与更新从服务策略到日志分析》中展开。参考与延伸阅读微软 AzureStack-Tools - Infrastructurehttps://github.com/Azure/AzureStack-Tools/tree/master/InfrastructureAzure Stack Hub Operator 文档当期 azs 版本为准