在阿里云上谈网络监控能力清单，要多一层混合环境的校准：被监控对象横跨本地数据中心、虚拟化平台与云上实例，同时"总部 + 大量分支"的场景很常见。这套清单在云上要逐项重新校准。
核心要点
- 本地设备靠 SNMP／邻居协议发现，云上资源要靠云 API 拉取，两边必须合并进同一份资产库与同一个拓扑视图。
- 轮询间隔必须分档，云上还要考虑管理流量的计费路径。
- 告警治理四件套不变：动态基线、分级、渠道路由、级联抑制；多云环境要额外统一时区。
- CPU 监控四层次依然适用，且要区分实例层与宿主机层两个视角。
- 数据留存策略直接关系云存储成本，聚合规则要先设计再上线。
一、六项能力的云上校准
1. 自动发现
本地设备基于 SNMP、ICMP、邻居发现协议扫描识别；云上实例与连接则通过云 API 拉取清单。评估要点是：两边发现出来的资源能否合并进同一份资产库、同一个拓扑视图，而不是两套各管各的。
# 云侧资源清单（通用 CLI 风格示意） cloudcli cvm describe-instances --output json > cvm.json cloudcli vpc describe-vpcs --output json > vpc.json # 本地侧 SNMP 连通性自检 snmpwalk -v2c -c public 10.20.30.40 1.3.6.1.2.1.1
2. 性能监控与轮询分档
覆盖 CPU、内存、磁盘、网卡、进程。云上两个特殊性：实例数量动态变化（自动发现要跟上新建与销毁），管理流量本身计费——跨可用区、跨地域的轮询流量是成本项，分档策略直接关系账单。建议核心实例分钟级、次要 5-15 分钟、长尾半小时以上，触发告警的临时加密采样。
3. 告警治理
四件套：动态基线（按时段计算正常水位，偏离若干倍标准差才告警）、分级机制（严重／警告／信息）、多渠道路由、级联抑制（核心节点故障时抑制下游重复告警）。混合环境下额外注意时区统一——云监控日志与本地系统的时区不一致，是"数据分家"最常见的隐蔽形态。
4. 报表与容量规划
云上容量问题会转化为成本问题：CPU 长期低位的实例应降配，长期高位的应扩容或迁移。趋势报表直接对接成本优化，留存至少覆盖一个完整业务周期。
5. 根因分析与自动化
把告警按依赖关系串成因果链、疑似根因置顶。云上自动化要区分实例内（重启服务、清日志）与实例外（扩缩容、切换流量）两类，后者通常走云 API，凭证权限要单独管控——自动化脚本的凭证泄露是真实的安全风险。
6. 多云与混合支持
统一资产标识 + 统一时间轴是底线。验证方法：拿一次真实故障，看本地与云侧数据能否在同一条时间轴上对齐。
二、CPU 监控的云上视角
四个层次（利用率 → 多核分布 → 进程归因 → 趋势预测）在云主机上依然成立，但要多看一层——区分实例层与宿主机层：
- 实例层：实例 CPU 利用率，注意虚拟化超分带来的毛刺。
- 宿主机层：宿主超售会影响实际性能，单看实例指标看不出邻居干扰，要结合同规格实例的性能基线对比。
# 实例内基础自检 mpstat -P ALL 1 5 # 多核分布 ps aux --sort=-%cpu | head -8 # 进程归因 # 云上补充：看 steal 时间（宿主超售信号） vmstat 1 5 # st 列持续 > 5% 说明宿主超售明显，考虑更换实例规格
经验阈值不变：核心实例 CPU 持续高于 85% 触发紧急告警，看趋势而非瞬间值。
三、数据留存与成本
云上存储按量计费，留存策略要提前设计而不是上线后补救：
- 原始高精度样本：留 7 至 30 日，用于排障回溯。
- 分钟级聚合数据：保留一个完整业务周期（季度到一年），用于容量与成本评审。
- 小时级汇总：可长期保留，用于跨年趋势。
评估工具时问清默认留存时长与扩容计费方式，别到账单出来才发现留存策略没设计。
四、分支场景的额外要求
"总部 + 大量分支"的链路特征是数量多、单条带宽小、现场无人值守，这带来三项额外要求：
- 轮询与探测频率必须分档。几百个门店统一高频轮询，管理流量本身就很可观。核心门店高频、普通中频、长尾低频，被告警触发的临时加密。
- 要能区分链路问题与门店内网问题。门店侧常见的"系统卡"，可能是内网交换机也可能是出口链路。出口内外各放一个探测点，两侧数据一比就能分开。
- 要能批量看、也能单点下钻。合理视图是"健康度总表"，按异常程度排序，点进去再看该门店的详情。
五、成本与留存
成本三笔账：采购价只是第一笔，第二笔是部署对接的人力，第三笔是扩容成本——云上还包括管理流量与留存的存储费用。只比采购价必然算错总账。
留存策略先设计再上线：原始高精度样本保留一周到一个月，分钟级聚合保留一个完整业务周期，小时级汇总长期保留。云存储按量计费，这笔钱要算进总账。
部署形态：分支多、人力少的场景云版本运维负担更低，但要先确认数据出网是否被允许、有没有等保相关要求，约束明确后再倒推可选形态。
六、FAQ
Q1：云上和本地监控能共用一套吗？
可以，但要确认三点：云侧资源通过 API 自动纳管、资产标识统一、时间轴一致。做不到就宁可分开，否则归因必扯皮。
Q2：实例 CPU 不高但业务慢？
先看多核分布（平均值会骗人），再看 steal 时间（宿主超售信号），最后看瓶颈是否在链路或存储。单看 CPU 平均值永远定位不了。
Q3：几千台实例轮询间隔怎么定？
按影响面分档，并考虑管理流量的计费路径——跨地域轮询是成本项，能就近就就近。
Q4：预测性维护值得上吗？
有前置条件：至少一个完整业务周期的历史数据加稳定基线。没有地基的预测就是拿噪声当规律。
Q5：告警太多怎么办？
动态基线、级联抑制、分级路由，三件套。上线三个月没人看告警，等于没有告警。
参考来源
- IETF RFC 2790——主机资源 MIB（CPU／内存监控的标准数据模型），RFC 编号 2790，可在 IETF RFC 编辑器站点检索
- IETF RFC 3418——SNMP MIB-II（网络设备基础管理信息库），RFC 编号 3418，可在 IETF RFC 编辑器站点检索
- 厂商实现文档（仅作技术对照，非推荐）：OpManager 帮助文档（可自行搜索官方文档站点）
一句话总结
阿里云上谈网络监控能力清单，关键是混合环境校准：发现覆盖云 API、轮询考虑计费路径、告警统一时区、CPU 监控区分实例与宿主两层视角、留存策略对接存储成本。
