企业官网建设流程全解析

1. 给交换机防火墙开一个SNMP“窗口”，再谈WGCLOUD监控

先说个背景。我手上管着一批分布在不同机房的交换机和防火墙，以前要确认设备状况，全靠一台台telnet/ssh登上去敲命令，来回折腾半小时下来，人先晕了。后来我把WGCLOUD部署到内网，把核心交换机、汇聚交换机、出口防火墙全部通过SNMP接入，这才算把“设备状态黑盒”的局面打开了。

WGCLOUD是一个开源的运维监控系统，本身基于Java Spring Boot，部署很轻，社区活跃。它不仅能监控普通服务器主机（Linux、Windows都能装agent采集），也能通过SNMP协议监控网络设备——也就是交换机、路由器、防火墙这一类没有“agent”可装，只能靠协议去读的设备。把WGCLOUD用起来之后，我在一个Web页面上就能看到每台交换机的CPU/内存占用、接口流量、光模块光衰，甚至是防火墙的会话数趋势，不用再满屏SSH窗口来回切了。

这篇文章适合谁看？如果你手头正好有华为、H3C或者锐捷交换机/防火墙，又想低成本搭一套内网监控中心，或者刚接触SNMP监控、搞不清楚“团体字”“OID”“接口流量怎么算”这些概念，那这篇指南可以帮你省不少弯路。我会从设备侧准备、SNMP配置、WGCLOUD接入、指标解读，一直写到告警和排障，全部按我自己实际踩过的步骤来。

1.1 为什么监控网络设备要走SNMP，而不是装agent

先说个最常见的误区：有人以为监控交换机和监控服务器是一回事，给每台交换机“装个agent”就行。实际完全不是这样。服务器上可以跑agent程序，主动把CPU、内存、磁盘数据上报给监控服务端；但交换机和防火墙大多跑的是厂商私有的网络操作系统，你没法在上面随便装一个第三方agent程序，除非买那种支持OpenFlow或者带管理槽位的设备，大多数场景都行不通。

网络设备普遍支持的“体检窗口”是SNMP。你可以把它理解成一个公立体检中心的服务台：设备本身就是体检中心，它知道自己跑了多少流量、温度多高、光模块收光功率多少，但不会主动告诉外人。SNMP里有个角色叫Manager，也就是监控端，比如WGCLOUD；设备上是Agent角色，负责按Manager的要求把数据从MIB库的各个节点里拿出去。这里又有个概念叫OID，它像设备的“体检项目编号”，比如1.3.6.1.2.1.1.1.0是系统描述、1.3.6.1.2.1.2.2.1.10是接口入方向字节计数，各项目都挂在一棵树状结构下。

WGCLOUD在监控网络设备时，扮演的就是Manager角色，而华为、H3C、锐捷这些交换机防火墙，只要你在命令行里把SNMP服务打开，配好“只读团体字”，WGCLOUD就能过来读取数据。生活里最常见的类比就是门禁卡：团体字相当于门禁密码，监控系统拿着一张只读门禁卡，获得查看设备的权限，但不能改写配置；所以只要团体字本身足够复杂，安全性还是可控的。

1.2 设备清单、管理VLAN和团体字，先规划再动手

如果你打算把一批网络设备都纳管进WGCLOUD，我强烈建议在动手改配置之前，先把规划表格做出来。别小看这一步，我见过有人一次性把十几台交换机都开了SNMP，结果团体字五花八门、管理IP还不在一个网段，最后全乱成一锅粥，只好逐个回滚。

先确认三件事：

一是设备型号和SNMP支持版本。现在绝大多数华为、H3C、锐捷设备都支持SNMP v1/v2c/v3。监控网络设备我建议优先用v2c，因为v1太老、很多MIB取不全；v3虽然能认证加密更安全，但配置复杂度高，设备型号差异大，后期WGCLOUD侧参数也容易填错。只要监控网络是在内网隔离环境，v2c加一个长随机团体字，防护级别是足够的。

二是管理网段。给WGCLOUD服务器、交换机的管理VLAN规划一个独立网段，让WGCLOUD只通过管理网段访问设备。比如管理VLAN是192.168.10.0/24，服务器占用一个固定IP，交换机/防火墙的管理地址也都放在这个网段下面，机房内其他的业务VLAN则跟SNMP流量彻底隔离。这样即使有人拿到了团体字，也只能从管理网段发起访问，风险面小很多。

三是团体字密码。不要用public、private这类默认值，很容易被隔壁同网段的机器扫到。我的习惯是生成一串包含大小写字母和特殊字符的只读团体字，比如Wgcloud@2024#Net这种，WGCLOUD侧和交换机侧都填同一个，并且交换机上通过ACL限制只有WGCLOUD服务器IP能访问SNMP服务。规划完这些之后，再动手改设备配置，后面会顺畅很多。

2. 在华为/H3C/锐捷设备上开启SNMP的实操记录

这部分是我认为整个项目里最容易出错的环节。命令本身不复杂，但不同厂商的命令风格确实有差异，有些命令还分系统视图和接口视图，抄错了控制台直接提示未知命令。我按自己实际配置过的设备类型，把命令逐条拆开讲，并解释每条命令是干什么用的，这样你遇到不同型号时也能举一反三。

2.1 华为与H3C设备的SNMP配置（命令逐条解释）

先说华为交换机和H3C交换机，这两家的命令行风格很接近，都是Comware系或VRP系，下面这套命令在绝大多数框式/盒式设备上都能跑通。

system-view snmp-agent snmp-agent sys-info version v2c snmp-agent community read cipher Wgcloud@2024#Net snmp-agent target-host trap address udp-domain 192.168.10.50 params securityname Wgcloud@2024#Net v2c

第一行system-view是进入系统视图，后面所有全局配置都在这个视图下执行。snmp-agent是启动SNMP代理服务，有些型号默认是关闭的，不开这一条后面配什么都没用。snmp-agent sys-info version v2c是让设备接受SNMP v2c版本的请求，如果你设备上还有v1的老监控系统，这里可以写成v1 v2c，但为了安全我通常只开v2c。snmp-agent community read cipher是设置只读团体字，后面跟的cipher意思是配置里保存时是加密的，避免在配置文件里明文暴露，这一步非常重要。最后一条是配置Trap目标的，把告警Trap发到WGCLOUD服务器所在IP上，这样设备端口down、CPU过高等事件可以主动推给监控端。

配置完可以用display snmp-agent sys-info和display snmp-agent community验证，命令行会回显SNMP版本、团体字列表等信息。华为USG系列防火墙也一样，注意部分版本需要在安全策略里放行从服务器到设备的UDP 161端口，否则SNMP请求会被防火墙策略拦掉，后面连不上还以为设备没开SNMP。

2.2 锐捷设备的SNMP配置和ACL源IP限制

锐捷交换机/防火墙的命令是另一种风格，整体思路和华为类似，但关键字不同。我在锐捷RG-S交换机和锐捷防火墙上都配过，下面这套是常用配置。

enable configure terminal snmp-server community Wgcloud@2024#Net ro access-list 10 permit host 192.168.10.50 snmp-server community Wgcloud@2024#Net ro 10 snmp-server host 192.168.10.50 version 2c Wgcloud@2024#Net

enable进入特权模式，configure terminal进入全局配置模式。第一条snmp-server community设置只读团体字，ro表示只读，千万别写成rw，否则监控端就有权限改设备配置了。接着我建了一个编号为10的标准ACL，只允许WGCLOUD服务器IP访问SNMP，然后把这个ACL绑定到团体字上。这样即使团体字泄露，其他IP也无法用它访问设备。snmp-server host同样是把Trap指向WGCLOUD服务器。

这里有个经验：锐捷某些老型号的ACL如果只写了permit host而没写最后的deny any，隐式规则是匹配不到的默认拒绝，所以不用画蛇添足。另外在锐捷防火墙上，如果你打算监管控流量，同样需要去检查安全策略，允许管理网段的ICMP和UDP 161流量到防火墙自身接口。

2.3 上WGCLOUD前的“体检”：用snmpwalk验证连通性

设备侧SNMP开了之后，不要急着登陆WGCLOUD去配设备，先在WGCLOUD这台服务器上用命令行工具验证一下SNMP通不通。这个步骤能帮你把“设备没开SNMP”“网络不通”“团体字错”这几类问题快速分流，省得在Web界面里反复测试。

Linux服务器上先安装工具，CentOS系用yum install -y net-snmp-utils，Ubuntu/Debian系用apt install snmp。装好后执行：

snmpwalk -v2c -c 'Wgcloud@2024#Net' 192.168.10.1 .1.3.6.1.2.1.1.1.0

这条命令的意思是向192.168.10.1发起SNMP v2c请求，团体字用Wgcloud@2024#Net，读取系统描述OID。正常回显是一串类似于SNMPv2-MIB::sysDescr.0 = STRING: H3C Comware Platform Software, Version ...的文本，看到这个就说明设备SNMP已经通了，团体字和网络都没问题。

如果看到Timeout: No Response from 192.168.10.1，基本是网络不通、UDP 161被防火墙拦了，或者设备没开SNMP。如果看到Authentication failure，那是团体字不对，尤其是首字母大小写、特殊字符输错这种低级问题。验证通过之后，再去WGCLOUD里“网络设备”页面添加设备，基本一次就能成功。

3. WGCLOUD接入网络设备的完整流程与指标解读

WGCLOUD接入网络设备这块，我要先提醒一句：网络设备不用安装agent，别被“agent”两个字带偏。WGCLOUD里的agent是给Windows/Linux服务器主机用的，交换机和防火墙这类设备通过SNMP走“网络设备”管理入口登记即可。理解了这一点，配置起来就清楚多了。

3.1 服务端部署和agent的角色（网络设备不装agent）

WGCLOUD服务端部署其实不复杂，最常规的方式是准备一台内网Linux服务器，装好JDK 1.8或更高版本，再装一个MySQL数据库（或者用内置的。看版本而定），然后解压服务端war包，修改配置文件里的数据库连接信息，用java -jar wgcloud-server.war启动服务，浏览器访问管理页面。这台服务器配置不用太高，2核4G跑几十台设备的监控完全够用。

接着说道agent。如果你还要监控交换机防火墙之外的主机服务器，那就在对应的服务器上装个小agent，它负责采集CPU/内存/磁盘等数据并上报给server端。但网络设备本身不装agent，WGCLOUD服务端会直接通过网络去轮询交换机的SNMP服务。所以你的工作重心不是去下载什么网络设备agent，而是确保前面第2章的那些设备侧SNMP配置做完、管理IP能通。

这里有一个规划建议：WGCLOUD服务端尽量单独分配一台或一台虚拟机，不要跟核心业务服务抢资源。因为SNMP轮询虽然不重，但服务端本身要开MySQL、跑Spring Boot进程，如果设备数量多、监控频率高，磁盘写入频繁，放在低配机器上可能影响采集稳定性。

3.2 “网络设备”页面怎么填：SNMP版本、团体字、轮询周期

登录WGCLOUD管理页后，找到“网络设备”模块，点击新增设备。这里要填的信息大概是：设备名称、管理IP、SNMP版本（v1/v2c/v3）、团体字（或v3的认证参数）、SNMP端口，以及轮询周期。部分版本还会让你勾选监控哪些指标，比如接口流量、CPU、内存、在线状态等，按需勾选即可。

我实际配置时的建议是：

• 设备名称写清楚机柜位置和用途，比如“核心交换机-机房A-01”，不要只写IP。等设备多了以后，告警列表里一眼能看出是哪个节点。
• SNMP版本统一选v2c，团体字填设备侧配置的那串，注意大小写、特殊字符完全一致。WGCLOUD对团体字的解析是严格按字符串匹配的，多一个空格都会失败。
• 轮询周期我一般选5分钟。1分钟虽然数据曲线更细腻，但对于一台几十个接口的交换机，一分钟一次SNMP遍历会明显增加设备CPU负担，尤其老设备容易报警。日常监控5分钟足够，故障时刻还能临时下调。
• 端口默认161，一般不用改。如果设备侧改过SNMP端口，这里就填对应的端口号。

填完信息后别急着保存，先点一下界面上的“测试连接”按钮。如果SNMP通，页面会提示连接成功；如果失败，就回头去看snmpwalk那一步能不能通、团体字对不对，基本能排除85%的问题。

3.3 华为/H3C查光口光衰命令的结果参数解释，以及WGCLOUD里的光模块监控

很多网管第一次在命令行里看光模块光衰，都是从H3C交换机的display transceiver diagnosis-information命令开始的。这条命令会输出所有光模块的实时诊断参数，输出结果一般包含光模块温度（Temp）、电压（Voltage）、偏置电流（Bias Current）、发送光功率（Tx Power）、接收光功率（Rx Power）这几项，单位分别是摄氏度、伏、毫安、dBm。很多人拿到输出后不知道怎么看，我用一句话总结：重点关注Tx Power和Rx Power，只要接收光功率低于模块的接收灵敏度，或者比正常值低好几个dBm，基本就是光链路衰减严重了，优先检查法兰盘、尾纤接口是否脏污，以及光纤是否有折弯或断裂。

这里要说明一下：光模块诊断信息在命令行里能看，不代表通过SNMP一定能拿到。厂家通常把这些数据放在私有MIB节点里，比如华为/H3C的hh3cTransceiverDiagnosticInfoTable或类似私有树上，而且不同设备型号、不同软件版本的OID不完全一致。我第一次找这个OID时，直接拿snmpwalk把整台设备所有MIB都拉了一遍，再用“transceiver”“temperature”“power”这些关键字在输出里grep，最后才定位到对应的节点。

在WGCLOUD里监控光模块光衰，有两种常见的做法。如果WGCLOUD版本支持自定义SNMP OID监控项，直接填你找到的OID，采集频率设成5分钟一次，就能把光模块收发光功率画成折线图；如果不支持自定义OID，那就退而求其次，用命令行定期导出光衰数据存档，配合人工巡检。我的体会是：光衰数据最值钱的地方不是“现在多少”，而是“趋势在变差”，所以哪怕暂时没有自动监控，也一定要保留历史快照，否则光模块故障发生前没有依据。

3.4 接口流量怎么算：ifHCInOctets累计计数器速算公式

WGCLOUD界面上显示的“接口入方向流量”“出方向流量”，很多新手会误以为设备直接返回了“当前速率”，其实SNMP采集到的原始值是一个累计计数器。最简单的例子是ifHCInOctets，它记录的是这个接口从启动以来累计收到的字节数，你可以把它想象成汽车的里程表，一直在涨，不会归零（除非重启或计数器回绕）。

WGCLOUD会自己计算并显示成直观的速率值，但你理解这层关系之后，排障会快很多。比如你在WGCLOUD里看到某个端口速率突然飙到几百Mbps，而业务上又解释不通，就可以去设备上执行display interface看累计计数器的增长趋势，判断是不是真有那么大流量，还是采集间隔太短导致计算波动。

如果自己用工具算，公式也很简单：速率(bps) = (本次数值 - 上次数值) × 8 / 采样间隔(秒)。这里用乘以8，是因为SNMP返回的是字节数，网络速率单位是bit。举个例子，两台采集间隔300秒，接口入方向累计字节数从1000000000涨到1200000000，那么速率就是 (1200000000-1000000000)×8÷300 = 5333333 bps，约5.3Mbps。这个公式我建议直接抄进自己的值班手册里，排查流量类告警时很实用。

4. 防火墙数据怎么用：会话数、黑白名单与策略命中

交换机的监控相对简单，无非是接口、CPU、内存、光模块；但防火墙的监控要复杂一些，因为防火墙的价值在于“会话”和“策略”。这一章我聊聊怎么把防火墙的数据真正用起来，而不是停留在“能出图”的表面。

4.1 会话数是防火墙的“心电图”

如果你统计过防火墙的会话数（Session）趋势，会发现它比端口流量更像“心电图”。正常情况下，会话数会在一个区间内平稳波动，跟随上班时段、业务高峰变化；一旦出现异常，比如被扫描、病毒爆发、或者某个服务器被大量外部连接轰炸，会话数往往会突然陡增，紧接着CPU也会拉高。所以我在WGCLOUD里给防火墙专门加了一个自定义SNMP监控项，指向设备的会话数OID，再配上告警阈值。

不过这里有个坑：会话数的OID不是标准MIB里的通用节点，依赖设备厂商实现。比如华为USG防火墙通常可以通过系统私有MIB节点读取，或者你在命令行里使用display firewall session table能看到统计汇总，但SNMP侧不一定开了对应节点。我的做法是先snmpwalk统计所有包含session关键字的OID，逐个取出来跟命令行输出对一下，确认哪个OID对应当前会话总数，再填进WGCLOUD自定义监控项里。

有了会话数这个指标之后，很多问题能提前发现。记得有一次一个核心系统突然对外大量重连，端口流量还没看出明显异常，但防火墙会话数先翻了一倍，WGCLOUD告警提前发出来，我们才赶在故障扩大之前找到源头。这类“提前量”价值极高，建议所有防火墙都配上。

4.2 黑白名单和安全策略命中率的联动监控思路

说到防火墙，很多人第一时间想到黑白名单和安全策略，会问WGCLOUD能不能直接监控“黑名单命中次数”。实话实说，SNMP对这类信息覆盖很有限。黑白名单本质上是防火墙的策略配置和命中统计，命中次数通常要通过防火墙日志或syslog/Trap才能拿到，单靠WGCLOUD的SNMP拉取，往往只能拿到设备自身的CPU、内存、会话数等基础健康数据。

我实际落地时的方案是双轨制：WGCLOUD管设备健康指标，防火墙日志交给内部日志平台或syslog服务器管。WGCLOUD的重点是监控防火墙“有没有快被打满”“会话数是否异常”“接口流量是否突变”，一旦异常，它通过Webhook把告警推到钉钉/微信工作群；日志平台则负责分析黑白名单匹配、策略命中次数，定期出一份报告。两边的数据结合着看，既可以知道防火墙在什么时候压力大，也能解释压力趋势背后的策略原因。

如果你暂时没有日志平台，还有一个轻量办法：在WGCLOUD所在服务器上写一个定时脚本，通过SSH去防火墙上拉取display firewall session table或策略命中计数器的输出，存成历史文本，再用WGCLOUD的自定义监控脚本功能把这些数据作为指标采集。我不太推荐小团队一上来就投入重资产搭大数据平台，先把手上的命令行输出管好，照样能完成日常监控。

5. 告警阈值、通知渠道和数据保留，别踩这些坑

设备都接入、指标都能看之后，很多人会卡在“不知道阈值设多少”这一步。阈值设太松，设备冒烟了都没人理；设太紧，一天几百条告警，同事直接把通知渠道屏蔽。这一章是我的实战心得，把这些坑一个个说清楚。

5.1 告警规则怎么配才不“狼来了”

WGCLOUD支持为每个监控指标设置告警阈值，并选择连续几次触发才真正告警。这里的关键是“连续确认”，我强烈建议用上，默认连续2次或3次再触发。比如CPU瞬时冲到95%可能只是某个进程抖动了一下，持续三个周期都超过85%才是真问题。没有这个机制，设备告警会频繁抖动，几次下来大家就不当回事了。

阈值设置我按设备类型分了几档：核心交换机CPU持续大于80%、内存使用率大于90%比较合理；出口防火墙会话数超过日常均值的150%或固定阈值（比如5万变成10万）要重点关注；接口带宽利用率按端口类型区分，普通业务端口长时间超过60%就可能影响体验，上联口和出口可以放宽到80%，但最好按业务高峰曲线来定，而不是拍脑袋选一个数。

通知渠道方面，WGCLOUD支持邮件、钉钉/微信机器人Webhook等，我通常每个告警同时推给两个渠道：邮件给值班邮箱留底，Webhook推到值班群置顶。这里有个小技巧：告警推送内容里一定要带上设备名称和当前数值，否则群消息只有“设备告警”四个字，值班同事还得去后台翻是哪个设备，效率非常低。

5.2 数据保留、巡检报表与备份

监控系统上线初期没人关心数据量，跑三个月后会发现MySQL的某个表已经占了好几十GB。WGCLOUD把监控数据存在MySQL里，历史数据积累速度取决于监控设备数量和轮询频率。我建议从一开始就规划好数据保留策略，比如接口流量这类高频数据只保留90天，设备状态数据保留更长一些；定期清理历史数据或者归档到备份表，避免磁盘被默默塞满。

巡检报表也很实用。WGCLOUD里可以配置定时生成报表，每周发一份excel或图片摘要，列出本周哪些设备发生过告警、平均CPU/内存水位、接口流量TOP10。这张表不只是给自己看，也能在周会上向上汇报网络运行情况。很多网络运维项目里，这一步做没做，直接决定了监控系统的使用价值。

还有一件事容易被忽略，就是WGCLOUD自身的备份。至少每周备份一次MySQL数据库和服务端配置，出问题时才能快速恢复。我见过有人辛苦配了上百条监控规则，结果服务器磁盘故障，监控系统整个重来，所有自定义OID和告警阈值都得重新填。配置和数据库都在，恢复也就是一小时的事；没有备份，那就是返工一周的事。

6. 常见问题与排查技巧实录

最后这部分，我把自己运行WGCLOUD监控交换机防火墙过程中遇到最多的几个问题整理成速查清单，每一个都是我实际搜过文档、翻过日志、对比过设备输出后总结出来的方法。

6.1 设备SNMP连不上，但snmpwalk又是正常的？

这个问题看起来很矛盾，但其实很多人都遇到。你在服务器上敲snmpwalk明明能取到数据，在WGCLOUD界面上测试设备却失败，或者添加后一直显示离线。最常见的原因有三个：

一是WGCLOUD服务端所在服务器和浏览器客户端所在机器不是同一台，你测试时用的命令是在服务器上跑的，WGCLOUD也是在这台服务器上跑的，两者网络路径不同，所以排查时要确认服务器本身的防火墙有没有放行UDP 161出方向请求，以及设备侧的ACL是否把WGCLOUD服务器IP漏掉了。

二是团体字里含有特殊字符，比如#、@、空格。命令行里用单引号包起来没问题，但WGCLOUD表单里填的时候，某些版本在保存或传递过程中可能有字符转义问题，导致实际发出的SNMP请求用的团体字和配置不一致。这种时候把团体字换成纯字母数字组合再试一次，往往就好了。

三是设备同时被多个监控系统以不同版本SNMP轮询，比如Zabbix在按v2c读，WGCLOUD又按v2c读，正常不会冲突，但有些老设备SNMP处理器很弱，并发请求一多，部分请求就超时。解决方案是错开轮询时间，或者把WGCLOUD轮询周期从1分钟调到5分钟。

6.2 监控图表突然断点、指标变成0？

图表断点最常见的原因是网络设备重启。设备重启后，SNMP的接口索引可能发生变化，比如原来的GigabitEthernet1/0/1在设备重新枚举后索引从101变成了102，WGCLOUD某个版本如果不重新扫描，接口流量数据就会突然取不到，表现为图表断线或数值为0。解决办法是在WGCLOUD里重新同步一次设备接口列表。

指标变成0的另一种常见情况是数据源本身返回0。比如光模块收光功率在某些设备上，模块没有插好或光路断开时会返回0dBm或空值，WGCLOUD如实采集后显示为0。遇到这种要先去设备命令行确认光模块状态，再回到监控侧看是不是采集问题，不要只看监控图就下结论。

还有私有MIB导致的兼容性问题。不同设备厂商、不同软件版本，对同一指标的实现方式可能不一样。你用华为H3C那套OID去监控锐捷设备，大概率取不到值或取到错误值。遇到这种，我建议先用snmpwalk把目标设备可以取的OID全量导出，保存成文件，再针对性地找OID填进WGCLOUD，别直接套用网上其他设备的配置。

6.3 监控几十台设备，注意别把设备CPU“打满”

这个问题最容易发生在老设备上。SNMP轮询看似轻量，但如果WGCLOUD把每台设备的全量接口、全量CPU、全量内存指标都以1分钟间隔去采集，几十台设备并发请求，老款交换机的CPU就可能明显升高，严重时甚至影响正常转发。我踩过一次坑：把整个机房的接入交换机全部加进WGCLOUD，间隔设成1分钟，第二天就有两台老交换机SNMP agent无响应，登录一看CPU一直99%。

从那以后我控制了几个原则：普通接入交换机只监控在线状态和接口流量，不做深度数据采集；汇聚和核心交换机才监控CPU、内存和全部接口；轮询周期统一5分钟，只在故障排查时才临时调短。另外，绝对不要在业务高峰时段用snmpwalk全量拉取整台设备的MIB树，这个操作对设备压力很大，相当于让设备把库存清单全部打印一遍，可能把老设备直接拖垮。

最后再说一句我的经验：监控交换机防火墙，一步到位不现实。第一阶段先把所有在线设备跑起来，只监控CPU、内存、端口流量、在线状态四件套；第二阶段再逐步加上光模块光衰、防火墙会话数这些自定义OID；第三阶段才做告警、报表和联动。先拿这个框架跑两周，把基线数据攒起来，后面所有阈值和规则都有据可依。我自己就是从这样一个一个设备加出来的，WGCLOUD这套体系越用越顺，现在基本不需要每天都登录设备看状态了。