Cacti流量突发性异常增高,求高手解答

变老头互叫绰号

最近发觉个问题,cacti流量会偶尔突发性增高.见下图



以下是查询RRD文件的结果,3:35确实有一次突高的流量异常.cacti日志未见异常
# rrdtool fetch /home/cacti_cdn/rra/4006/52370.rrd MAX |perl -pe 's/(\d+)/localtime($1)/e' |grep "Mon Feb 13 03"
Mon Feb 13 03:00:00 2012: 4.2653944067e+07 3.5335684176e+08
Mon Feb 13 03:05:00 2012: 1.3647735409e+07 3.0865663074e+08
Mon Feb 13 03:10:00 2012: 2.7241653076e+07 3.3003119603e+08
Mon Feb 13 03:15:00 2012: 1.5947054371e+07 3.0372552823e+08
Mon Feb 13 03:20:00 2012: 4.2861031231e+07 3.1239286072e+08
Mon Feb 13 03:25:00 2012: 1.3749976087e+07 2.8083058488e+08
Mon Feb 13 03:30:00 2012: 2.0107414627e+07 3.0366636460e+08
Mon Feb 13 03:35:00 2012: 1.1852795652e+07 3.7901828920e+09
Mon Feb 13 03:40:00 2012: 1.8938599306e+07 4.4277497049e+08
Mon Feb 13 03:45:00 2012: 1.3075963631e+07 2.6957868917e+08
Mon Feb 13 03:50:00 2012: 2.1487742920e+07 2.8746931546e+08
Mon Feb 13 03:55:00 2012: 9.9184675917e+06 2.5168575700e+08

变老头互叫绰号

补充一下，该交换机端口模块仅10G

zxh19871028

会不会是攻击？

变老头互叫绰号

攻击突增的应该是inbound流量吧，而现在是outbound突然增高，系统日志均正常，应该可以排除被攻击的可能

baroquesoul

采集的数据出错也是有可能的，看你的rrd里面取的是均值还是最大值。
对于关键的端口，5分钟的采集间隔还是太长了点，1分钟一次，或者更短一点，能更好的发现问题。
10G的网络，5分钟，能传多少数据啊。

变老头互叫绰号

rrd 取的是最大值 ，取值命令如下：rrdtool fetch /home/cacti_cdn/rra/4006/52370.rrd MAX
因为采集点过多，大约2900个采集点，采集信息约20000多条，rrd造成的IO压力很大，所以只能使用5分钟采集一次。

baroquesoul

2900个采集点啊，确实很多。我有个疑问？我之前做过几个网络监控的项目，通常对网络节点的监控，主要是监控重要的几个点。比如说办公环境，每个办公人员的端口是不需要监控的，只需要监控交换机的上联端口即可。毕竟大家上上网，传传东西，没有监控的必要。因此只要监控这些交换机的上联端口即可，对于服务器，确实需要每个端口都监控到。
如果楼主真的有上千台服务器，那么就不能用一台监控服务器来做了，资源肯定是不够的。可以考虑多布几个采集点，然后再统一展示。

对于上面那种情况，可以分两种情况考虑：一是无效数据，我之前遇到过，偶尔采集到的值很奇怪，完全超过正常范围，遇到这种情况，只要不是频繁发生的，可以在采集时做一个过滤，对于超过合理范围的数据进行修改。当然最好做个记录。
第二种，就是有效数据了。那么看一下发生的时间，最好能根据链路，看一下相关端口的记录，服务器的记录，最好能搞清数据流向。
如果正的什么问题也没找到，那就以后多注意这个点，可以考虑调整一下监控频率，观察一段时间。。

如果是办公环境，没准就是谁在传文件玩；生产环境的话，就要联系业务人员，看有没有大规模的上传、下载数据；如果是对外提供公共服务的服务器，估计就得小心了，Outband那么高，不会被偷了吧。

以上是我平时运维的处理方法，不知道是否对楼主有帮助，如果说的有问题，还请指正。

变老头互叫绰号

Cacti方面没有做过分布式，Nagios倒是搞过。
从nagios分布这个项目中，我觉得分布式会把维护变得复杂化，电信端check后返回到BGP的center机上显示报警，但是这样会有2个问题，check周期变长，电信分布机到中心机的网络必须完全畅通。
我目前还是考虑将RRD文件移到 tmpfs下，读写在内存里，这样缓和了瓶颈问题，而且维护也不会变得很复杂。2W个RRD文件大约7～8G吧。差不多16G内存的服务器就可以处理了。

目前是以脚本做判断，高于上一个周期数据5倍以上，则视为无效数据。改为NAN
从被监控端的服务器网卡上看，应该属于cacti抓取的错误数据。
转了很多地方，有人说是SPINE的漏洞，具体就不得而知了。

还是非常感谢baroquesoul给予的意见。