Azure Stack Hub 监控与集成：从 ITSM 工具链到运维实操（中篇）

本文承接上篇《Azure Stack Hub 监控理念与告警机制：从一体化运行状况到告警处理》中"HRP 是告警唯一对外出口"的结论，重点展开"ITSM 集成方案、跨监控栈的接入模式、运维场景示例" ------ 把一体机告警能力与企业现有监控体系融合。

版本基础 ：与上篇一致，基于 azs-1901 至当前主流 azs 版本 的 Azure Stack Hub Operator 文档整理。不同 OEM 集成系统 以及不同 azs 版本 之间可能存在差异；当版本与本文表述不一致时，以当期版本 Azure Stack Hub Operator 文档 + 当期 OEM Support Matrix 为准。

修订说明:

本篇为 Azure Stack Hub 监控与更新三篇系列 · 监控与集成篇首发版，基于内训材料《Azure Stack Hub 监控与更新》中"监控和集成"章节整理，按四层原则做工程化改写。

[ITSM 集成的总原则：复用现有管道](#ITSM 集成的总原则：复用现有管道)
[监控集成矩阵：四类对象 × 四类工具](#监控集成矩阵：四类对象 × 四类工具)
[网络设备：SNMP 接入](#网络设备：SNMP 接入)
[Azure Stack Hub 软件：REST API + 管理包](#Azure Stack Hub 软件：REST API + 管理包)
[物理服务器：BMC + OEM 管理包](#物理服务器：BMC + OEM 管理包)
租户订阅健康监测：与一体机告警的差别
[Microsoft 提供的集成资产](#Microsoft 提供的集成资产)
[运维场景 1：节点主板损坏维修的完整闭环](#运维场景 1：节点主板损坏维修的完整闭环)
[运维场景 2：Portal / ARM / RP 异常的应急路径](#运维场景 2：Portal / ARM / RP 异常的应急路径)
四个常见误判信号
三条集成场景红线
中篇小结：监控集成的工程化整合

1. ITSM 集成的总原则：复用现有管道

L1 微软硬要求

Azure Stack Hub 在设计层面对 ITSM 集成的态度非常清晰：不发明新轮子 。客户已有的监控工具链、企业已有的 ITSM 工单系统，都不应该被"一体机"覆盖或绕过，而应该是被复用：

1.1 三项核心原则

原则	含义	工程落地
使用现有数据中心监控工具	不强制要求客户购买新的监控软件	选 SCOM / Nagios / Zabbix / OpenObserve 等任一已有栈
使用从监控到工单的现有连接	不强制要求客户定义新的工单通道	现有 ServiceNow / Jira / 自研工单系统对接保留
不重新发明 SCOM / Nagios 适配器	微软只提供标准 REST API + 官方管理包	企业按标准接入，不需要"为 Azure Stack Hub 适配"

1.2 这条原则的工程意义

这条原则带来三个直接好处：

降低学习成本 ------ 企业 SOC 团队不需要为 Azure Stack Hub 单独培训；用既有 SCOM / Nagios 经验即可；
保持监控仪表盘一致性 ------ 一体机的告警与企业其他基础设施告警在同一个屏幕里；
避免"一体机孤岛" ------ 一体机成为企业监控平面里的普通一类资源，而不是单独的特殊栈。

1.3 与 §1 总原则的偏差

与上篇 §3 的"告警驱动"原则相对，本篇的"集成采用现有管道"是互补而不冲突：

告警驱动管一体机内部的修复路径；
集成采用现有管道管一体机的告警怎么流到企业栈。

这两条原则是不同维度，不矛盾也不重叠。

2. 监控集成矩阵：四类对象 × 四类工具

L2 OEM 实现 + L0 官方行为

集成对象为四类：网络设备、Azure Stack Hub 软件、物理服务器、租户订阅。每类对象有特定的接入工具。

2.1 集成矩阵速查

集成对象	主要接入工具	输出格式	责任团队
网络设备（ToR / BMC）	SNMP	SNMP trap / 标准 MIB	网络运维
Azure Stack Hub 软件	REST API（HRP）	JSON / OData	SCOM / Nagios 适配器
物理服务器	BMC（iDRAC / iLO 等）	Redfish / IPMI / OEM 私有协议	OEM 监控
租户订阅	REST API（Azure 公有云风格）	ARM 风格 JSON	SCOM / Nagios / 自研监控

2.2 四类对象在告警维度上的差异

维度	网络设备	Azure Stack Hub 软件	物理服务器	租户订阅
告警语义	端口 up/down / 丢包率	组件健康（HRP）	传感器阈值（OEM）	订阅状态 / 配额
告警频率	高（每分钟级）	低（事件驱动）	中（阈值驱动）	低（事件驱动）
生命期	短暂故障 / 收敛	中长（直到修复）	中（直到恢复）	中（直到解决）
响应路径	SNMP 标准	HRP API	OEM 管理包	ServiceNow / Jira

L3 最佳实践 ：四类对象应进入不同的监控仪表盘视图。把它们硬合在一个 SCOM 视图里会模糊责任分工。

3. 网络设备：SNMP 接入

L2 网络协议

SNMP 是网络设备的标准接入协议。Azure Stack Hub 的 ToR / Spine / BMC（带外管理网络）通常都启用 SNMP。

3.1 SNMP 接入的三类解决方案

解决方案	适用场景	关键特征
System Center Operations Manager（SCOM）网络设备发现	已部署 SCOM 的企业	统一管理平面
Nagios Switch 插件	已部署 Nagios 的企业	开源 + 插件丰富
其他 OEM 支持的监控解决方案	自研监控 / 第三方监控	按 OEM 协议

3.2 SNMP 接入的常见配置

L3 最佳实践

复制代码

SNMP v2c / v3 配置示例（不同 OEM 有差异）
  community: <企业内定义>
  v3 auth:  SHA / AES
  trap destination: <监控服务器 IP>
  poll interval: 5min (企业惯例)

L1 微软硬要求 ：Azure Stack Hub 不独立维护 VPN / 设备兼容清单------SNMP 设备兼容性清单与 Azure 公有云共用。

4. Azure Stack Hub 软件：REST API + 管理包

L0 版本事实

REST API（HRP）是对接 SCOM / Nagios / 自研监控栈的主要通道 。同时微软官方提供 SCOM 管理包 与 Nagios 插件。

4.1 三种接入路径

路径	适用场景	关键资产
SCOM 管理包（Azure Stack Hub Management Pack）	已部署 SCOM	`MicrosoftAzureStackHub.Views` / `MicrosoftAzureStackHub.AlertRules`
Nagios 插件（开源版 + Enterprise 版）	已部署 Nagios	`check_azurestack_*.pl`（开源）
REST API + 自定义集成	已部署 Zabbix / 自研监控	微软提供 GitHub 示例

4.2 开源 Nagios 插件的位置

L0 版本事实

微软官方提供 Azure Stack Hub 开源 Nagios 插件包（包括 alert / health / resource provider 三类插件）：

项目地址：https://github.com/Azure/AzureStack-Tools/tree/master/Infrastructure
文档地址：http://aka.ms/masnagios

4.3 SCOM 管理包部署建议

L3 最佳实践

SCOM 管理包部署的关键步骤（按发布顺序）：

导入管理包------把 Azure Stack Hub Management Pack 文件导入 SCOM；
订阅 HRP------配置管理包指向 Azure Stack Hub PEP / 管理员门户；
调整仪表盘------按团队分工设置视图（计算 / 网络 / 存储 / 容量）；
测试告警流------故意触发一个 Warning / Critical，确认 SCOM 收到。

L1 微软硬要求 ：SCOM 管理包的"严重性"映射应严格按 HRP 输出 ------ 不要在 SCOM 侧二次降级。

5. 物理服务器：BMC + OEM 管理包

L2 OEM 实现

BMC（Baseboard Management Controller） 是服务器的带外管理控制器 ------ Dell 叫 iDRAC，HPE 叫 iLO，Lenovo 叫 XClarity。BMC 提供对物理硬件的独立监控能力（即使服务器关机也能访问）。

5.1 BMC 接入的三种解决方案

解决方案	适用场景	关键特征
SCOM - 硬件供应商管理包	已部署 SCOM + 单一 OEM 监控	厂商原生适配
硬件供应商 Nagios 插件	已部署 Nagios + 单一 OEM 监控	厂商原生
其他 OEM 支持的监控解决方案	多 OEM / 自研监控	按 OEM 协议

5.2 物理硬件告警的两条路径

物理硬件告警可由两条独立路径产生：

复制代码

路径 A：HRP 路径（一体机内部）
   物理磁盘 → ACS / S2D → HRP → 管理员门户告警
   【Azure Stack Hub 原生告警】

路径 B：OEM 监控路径（外部工具）
   物理磁盘 → BMC → OEM 管理包 → SCOM / Nagios
   【OEM 监控告警】

L3 最佳实践 ：两条路径都应保留作为冗余。在 HRP 路径阻塞时，OEM 路径仍是最后一道保险；同样在 OEM 工具不可用时，HRP 仍能上报警告。

5.3 网络交换机监控的独立通道

L2 网络协议

网络交换机 （ToR / Spine）通常独立于 BMC 通道 ，通过 SNMP 接入：

端口 up/down；
端口流量 / 丢包率；
交换机自身温度 / 风扇 / 电源。

6. 租户订阅健康监测：与一体机告警的差别

L0 版本事实

租户订阅健康监测 不是一体机告警的"延伸"，而是独立的监控维度 。它的对象是租户的业务可用性 ，而不是一体机自身的健康。

6.1 三类接入工具

工具	路径
SCOM - Azure Management Pack	通过 Azure 公有云风格的 ARM API 订阅租户资源
运营管理套件（OMS）/ Log Analytics	通过 Log Analytics 工作区聚合租户监控数据
REST API + 自研	自建 SCOM / Zabbix 适配器

6.2 租户订阅监控维度

维度	含义
订阅状态	订阅是否 active / suspended
资源配额	vCore / 存储 / 公共 IP 等配额是否耗尽
资源健康	租户 VM / VMSS / 应用网关等的运行状态
一致性指标	跨可用区的资源同步状态

L3 最佳实践 ：租户订阅监控与一体机告警应放在不同的 SCOM 视图。理由：

责任团队不同 ------ 租户监控属于业务团队，一体机告警属于云管理员；

告警语义不同 ------ 租户资源 "unhealthy" 不等于一体机 "unhealthy"；

响应路径不同 ------ 租户告警通常引导租户自查 / 报修，一体机告警引导管理员处置。

7. Microsoft 提供的集成资产

L0 版本事实

微软在 GitHub 上提供两套核心集成资产，企业级集成可以直接复用：

7.1 AzureStack-Tools - Infrastructure

项目地址 ：https://github.com/Azure/AzureStack-Tools/tree/master/Infrastructure
内容：PowerShell 模块 + 示例 + 工具集，覆盖 HRP / 监控 / 更新等领域。

7.2 三类资源

资源	用途	适用对象
GitHub 示例	REST API 集成示例（PowerShell）	自研 / SCOM 适配器开发者
SCOM Management Pack	SCOM 专用管理包	已部署 SCOM 的企业
开源 Nagios 插件	Nagios 专用插件	已部署 Nagios 的企业

7.3 三类资产的复用模式

L3 最佳实践

已有 SCOM 的企业：直接用 SCOM 管理包；
已有 Nagios 的企业：直接用开源 Nagios 插件；
已有 Zabbix / 自研监控的企业：参考 GitHub 示例，调用 HRP REST API 自研适配器。

8. 运维场景 1：节点主板损坏维修的完整闭环

L2 OEM 实现

典型运维场景 ：缩放单元节点由于主板损坏而无法响应 。这是一个节点级故障，需要走完整的"诊断 → 进入维护模式 → 修复 → 恢复"四段流程。

8.1 四段式流程

复制代码

[1. 告警触发]                                  [2. 诊断]
HRP 发出"基础结构角色无响应"（Critical）         ├─ 管理员门户定位告警
   或 "节点无响应"                                   └─ 确认是主板损坏（非临时故障）
[FRU = Field Replacement Unit]

[3. 进入维护模式（drain）]                       [4. 修复]
├─ 把节点标记为 "维护模式"                          ├─ OEM 现场更换主板
├─ S2D / ACS 进入降级状态                            └─ 节点重新加入集群
└─ 停止向该节点调度新 VM

[5. 检查告警是否已解决]                            [6. 禁用维护模式（恢复）]
├─ HRP 是否清除了告警？                                ├─ 节点恢复正常状态
└─ 若仍有告警，重走 §4.6 流程                         └─ S2D / ACS 重新平衡

[7. 关机 → 开机]
└─ 通常由 OEM 在更换主板时执行

8.2 每一步的判断标准

步骤	进入条件	退出条件
进入维护模式	确认是硬件级故障，节点需要离线维修	S2D / ACS 已完成数据降级
修复（更换主板）	维护模式已激活，OEM 工程师到位	主板更换完成，节点重启
禁用维护模式	节点已恢复健康，HRP 无新告警	ACS / S2D 完成数据再平衡
关机 → 开机	OEM 在维修过程中执行	节点能正常 POST 并加入集群

8.3 关键点：告警已解决 ≠ 维护模式已退出

L3 最佳实践

进入维护模式时，HRP 通常会抑制与该节点相关的告警 （避免告警风暴）；但禁用维护模式之后，可能会有残余告警 （如 S2D rebalance 警告）------ 管理员应在禁用维护模式后再观察 1-2 小时，确认无新告警才能下"闭环"判断。

9. 运维场景 2：Portal / ARM / RP 异常的应急路径

L2 微软实现

第二个典型运维场景 ：Portal、ARM、结构资源提供程序、目录服务或存储处于脱机状态 。在这种"管理面 + 部分控制面不可用"的情况下，管理员门户完全无法工作 ，必须依赖 PEP（Privileged Endpoint）。

9.1 应急路径：PEP 是"服务器故障恢复控制台"

L1 微软硬要求

这种场景下，PEP 是唯一可走的"服务器故障恢复控制台"路径 ------ 类似 Windows Server 的"故障恢复控制台"：

复制代码

[客户运维团队]
   ↓
[运维计算机（HLH / OAW）]
   ↓
[PS only]    [JEA（Just Enough Administration）]
   ↓             ↓
[Privileged Endpoint（PEP）]
   ↓
[基础结构角色实例]
[GMSA Domain Admin Account]

9.2 应急路径的标准流程

L1 微软硬要求

应急路径的四个步骤（注意：当管理员门户不可用时才走这个流程）：

步骤	动作	工程含义
1	创建诊断包	用 PEP 的 `Get-AzureStackLog` 收集诊断日志
2	开始解锁过程	确认问题不能从管理员门户解决
3	从支持部门接收第二阶段密钥	微软 / OEM Support 提供的 Token
4	进行所有的输入活动	用 PEP PowerShell Session 执行诊断 / 修复

9.3 走 PEP 之前要确认的事项

L3 最佳实践

在走 PEP 应急路径之前，先确认是否真的走投无路：

管理员门户只是短暂空白 ------ 等 30-60 秒后刷新再试，不要立刻走 PEP；
管理员门户完全白屏 ------ 检查 HLH、DNS、adminportal vm 状态；
PEP 也不可用 ------ 联系 OEM / 微软 Support 请求 Token + 现场支持。

L1 微软硬要求 ：PEP 不可被租户使用 ------ 它是 Microsoft / OEM / 客户云管理员专用的应急通道。

9.4 PEP 与管理员门户的角色分担

L3 最佳实践

维度	管理员门户	PEP
入口	浏览器	PowerShell Remoting
凭据	Cloud Admin	Cloud Admin + 必要时 Token
使用频率	日常 / 频繁	应急 / 偶发
可做的操作	大多数运维	全部运维（含管理员门户不能做的）

10. 四个常见误判信号

实操里最常见的假象------管理员初次接触 ITSM 集成时容易误判。下面补充四条 L3 最佳实践层面的常见误判补足：

10.1 OEM 管理包版本过旧 ≠ 应跳过更新

OEM SCOM 管理包版本过旧时，不应跳过更新。管理包版本与 OEM 固件 / 驱动版本联动；跳过管理包更新会导致 SCOM 监控的硬件维度与 HRP 不一致。

10.2 Nagios 插件找不到 Azure Stack Hub 节点 ≠ 节点掉线

Nagios 插件找不到节点时，先确认 Nagios 服务器到 HLH 的网络可达性。可能是 Nagios 插件自身的连接问题，而不是节点真的掉线。

10.3 SCOM 监控不到租户订阅 ≠ 订阅正常

SCOM 对租户订阅的"看不到"可能是管理包作用域（scope）配错，而不是订阅丢失。管理员应检查 SCOM 管理包的 subscription 配置。

10.4 HLH 上的 VM 重启属正常维护

HLH 上的 Dell-MGMTVM 重启通常属正常维护（OEM 扩展包 / Secure Connect Gateway 心跳恢复），管理员不应误判为"硬件故障"。

11. 三条集成场景红线

L3 最佳实践 + L1 微软硬要求

集成场景的"绝对不能这么做的"红线：

11.1 红线 1：不要擅自修改 OEM 验证的 SCOM / Nagios 连接参数

OEM 已经验证过的连接参数是测试过的稳定性基线 。客户不应擅自修改 timeout / poll interval / 协议版本 ------ 这些参数可能会破坏生产稳定性。

11.2 红线 2：不要越过 OEM Support 团队直接动 HLH 上的 VM

HLH 上的 VM 是 OEM 的责任面。客户不应（技术上也不应该可以）越过 OEM 直接修改 MGMTVM / HLH Hyper-V 配置。

11.3 红线 3：不要把租户订阅监控与一体机告警混在一个仪表盘

两种监控责任团队不同、告警语义不同、响应路径不同 。把它们硬合在一个 SCOM 视图里会模糊责任分工，反而降低响应效率。

12. 中篇小结：监控集成的工程化整合

本文围绕 "监控和集成"章节，展开了 ITSM 集成方案、监控矩阵、租户订阅监控、运维场景：

§1 阐述 ITSM 集成的总原则------复用现有管道，不发明新轮子；
§2-7 拆解四类对象 × 四类工具的集成矩阵，以及 Microsoft 提供的三类集成资产；
§6 单独展开租户订阅健康监测，与一体机告警对照；
§8-9 给两个运维场景示例的完整 SOP；
§10-11 补充四条常见误判信号与三条集成场景红线。

与本系列下篇衔接 ：本文展开了"告警怎么流入企业栈"------但没有展开 "在告警触发后，管理员如何把一体机补丁到更新版本"。这正是下篇《Azure Stack Hub 补丁与更新：从服务策略到日志分析》要解决的问题 ------ 服务策略、Microsoft 更新类型、版本控制、Portal / PowerShell 操作、上传 / 安装 / 恢复 / 日志、Dell P&U 工具等内容。

参考与延伸阅读：

微软 AzureStack-Tools - Infrastructure：https://github.com/Azure/AzureStack-Tools/tree/master/Infrastructure
Azure Stack Hub 开源 Nagios 插件：http://aka.ms/masnagios
Azure Stack Hub Operator 文档（当期 azs 版本为准）