核心要点
- 监控工具经历三个世代：SNMP 探针型 → 可观测性栈 → AIOps 平台，市面上主流产品分属不同世代。
- 评估采集架构：既要 SNMP 底座稳，也要数据模型向 OpenTelemetry 收敛。
- 云原生环境的核心挑战是资产动态化：工具的发现与建模能力比监控项数量重要。
- 验证 AI 能力要看机制与可回放性，警惕把规则引擎包装成 AIOps 的宣传。
一、监控工具的三个世代
把市面上的工具按技术代际摆一摆，选型思路会清晰很多。第一世代是 SNMP 探针型，Nagios、Zabbix 的底子都在这一代——周期性轮询设备 OID，状态变了就告警，能力上限取决于使用者。第二世代是可观测性栈，以 Prometheus 加 Grafana 为代表，标签化的多维数据模型让监控第一次有了"查询语言"。第三世代是 AIOps 平台，OpManager、SolarWinds 这类商业产品正在往这个方向演进：自动发现、拓扑建模、告警收敛、根因推理，试图把人从告警海洋里捞出来。
三个世代不是替代关系。现实中大部分企业是三代并存：网络设备靠 SNMP 工具，容器层靠 Prometheus，告警治理靠平台能力。选型真正要回答的问题是：你买的这个工具，在它的世代里做到了头部吗？以及，它有没有向下一代演进的路。
二、评估工具的四个技术看点
采集架构。设备层 SNMP 是绕不开的底座，IETF RFC 3411 定义的管理框架是行业公共标准，谈不上差异化。要看的是采集之外：流量分析（NetFlow/sFlow）是不是原生集成，时序数据能不能进 Prometheus 生态，数据模型是否向 OpenTelemetry 收敛——最后这条决定五年内你做任何架构调整的成本。
发现与建模。云原生环境资产是动态的，pod 存活以小时计，传统"扫网段建清单"的模式跟不上。要看工具的发现机制是定期扫描还是事件驱动，拓扑是静态图纸还是随变更自动更新。验证方法：往环境里扔个新东西，掐表看多久被识别、拓扑会不会自己长出来。
告警管道。这一层最容易被营销话术糊弄。真 AIOps 的告警治理是基于依赖关系和历史模式做收敛与根因推理；假 AIOps 是把阈值规则引擎换个名字。验证方法也很直接：让它用你们过去一个月的真实告警数据做回放，看降噪率是不是像宣传的那么高。
开放性。API 能不能把告警、拓扑、性能数据完整拉出来？历史数据能不能批量导出？这两个问题决定工具是融入你的体系，还是成为新的孤岛。开放性差的工具，越用越难走。
三、云原生环境的特殊考量
三个容易踩的坑。其一，别用静态思维选工具：环境里虚拟机、容器、Serverless 混跑，工具对短生命周期资产的监控支持必须验证。其二，别指望一款工具管所有层：网络设备层交给专业工具，容器层交给云原生栈，中间用标准协议做桥，比追求"一体化大而全"务实得多。其三，混合云场景下要确认工具对多云 API 的支持深度，很多工具的"多云支持"只是各自装个 agent，视图和告警并不统一。补充一个实操建议：混合云环境做选型验证时，把云上云下的告警链路各跑一遍全流程——从设备故障到值班手机收到通知，两端都要测。很多工具在单侧表现良好，跨云的那一跳才是真实力的试金石。
FAQ
AIOps 是不是营销噱头？
方向是真的，落地参差。真实的 AIOps 在告警降噪、根因定位上已经有可量化的效果；噱头的是拿规则引擎改名。判断标准就一条：能不能用你的历史数据回放验证效果，不能回放的都不用聊。
OpenTelemetry 会取代 SNMP 吗？
不会取代，是分层。OTel 主要解决应用与中间件的遥测统一，网络设备层的 SNMP 因为存量巨大仍会长期存在。理想状态是两者在数据湖层汇合，选型时看工具能不能同时吃下这两类数据。
云厂商自带的监控和自建监控怎么分工？
云上资产用云监控兜底（至少网络与计算的基础指标是全的），跨云和本地 IDC 的部分用第三方工具统一管。分工的边界画在"资产归属"上，别试图让云监控管云外的东西。
工具必须支持 K8s 才算合格吗？
取决于你的环境。有容器的环境，工具至少要能发现集群并采集基础指标；纯虚拟机环境则不必为此付费。为用不上的能力买单，是选型里最常见的浪费。
怎么向领导汇报监控工具的价值？
别讲功能，讲三个数：平均故障发现时间（MTTD）的变化、告警噪音下降的比例、运维人力在监控维护上的投入变化。监控是成本项，价值要用故障损失 avoided 来说话。
本文基于公开技术资料整理，聚焦工程实践视角，不含推广内容。
