服务器换机房后cacti监控不出图故障排查
环境介绍：
因为业务需要，公司在深圳机房的几台服务器搬迁到中山机房，由于监控服务器放在佛山，因此采用如下图的方式来对中山机房的机器进行监控：
佛山的监控系统采用cacti+nagios来监控，B服务器为windows机器，没有公网IP。因此cacti和nagios获取数据的时候需要通过A服务器(linux)的iptables来转发。如上图，cacti通过访问A服务器的11161端口来访问B服务器的snmp服务(snmp服务使用的端口为udp161端口)。在A服务器上添加了如下iptables规则来实现端口转发的目的：
# nagios的windows客户端NSClient的端口转发，nagios通过这个端口采集数据
/sbin/iptables -t nat -A PREROUTING-d 189.43.138.11 -p tcp -m tcp --dport 12489 -j DNAT --to-destination 172.16.100.82:12489
#windows中snmp的端口转发，cacti通过这个端口采集数据
/sbin/iptables -t nat -A PREROUTING-d 189.43.138.11 -p udp -m udp --dport 11161 -j DNAT --to-destination172.16.100.82:161
#将B服务器的IP地址进行伪装，使B服务器能正常上网
/sbin/iptables -t nat -A POSTROUTING-s 172.16.100.0/24 -j SNAT --to-source 189.43.138.11
机器迁移以后因为IP变了因此只对一些涉及到IP的配置做了变更，变更后网站访问以及ssh登录等都正常，nagios监控的也正常，唯独cacti没有数据。奇怪的是以前在深圳机房的时候也是采取的iptables规则来做端口转发的，能正常地获取数据。现在不同的只是将IP变更了一下就出现不能获取数据的问题，检查了windows下的防火墙以及杀毒软件没有阻塞对161端口的访问，不知道什么原因？
故障排查：
为了深入分析这个问题，首先在监控服务器上使用snmpwalk命令看看能否获取数据，命令如下：
snmpwalk -v2c -c public189.43.138.11: 11161
#返回如下内容
Timeout: No Response from189.43.138.11: 11161
发现没有内容返回，在监控服务器上ping 189.43.138.11没有问题。为了一探究竟在A服务器上使用tcpdump抓包
在A服务器使用如下命令抓包:
/usr/sbin/tcpdump -i eth1 port 11161 –vv
返回如下内容：
18:44:30.650302 IP (tos 0x0, ttl 58, id 0, offset 0, flags [DF], proto: UDP(17), length: 82) 121.9.203.157.13065 > 189.43.138.11.suncacao-snmp: [udpsum ok] UDP, length 54
18:44:31.651067 IP (tos 0x0, ttl 58, id 0, offset 0, flags [DF], proto: UDP(17), length: 82) 121.9.203.157.13065 > 189.43.138.11.suncacao-snmp: [udpsum ok] UDP, length 54
备注：由于后面几个包和这两个包一样，限于篇幅，省略了。
从抓取的包中我们可以看出数据顺利的到了189.43.138.11服务器，但是从189.43.138.11却没有数据返回。
于是在B服务器使用ethereal进行抓包分析。通过161端口进行过滤后发现如下内容：
发现返回的IP确实172.16.100.83的IP，也就是B服务器上另外一个IP，对于这个IP我们的防火墙上没有任何规则。至此真相大白！
故障原因：
从上面的分析中我们可以看出，我们的规则之是针对172.16.100.82这个IP，但是B服务器上snmp响应的IP确实172.16.100.83这个IP，因为A上的iptables只是针对172.16.100.82这个IP做了规则，因此导致数据返回监控服务器的时候出现问题。以前在深圳机房的时候只配置了一个IP，因此没有出现这个问题。
解决办法：
知道了问题的原因，就好解决了，只需要将防火墙规则指向172.16.100.83这个IP即可或者将172.16.100.83这个IP去掉，因为那个IP是同事配置的因此采用第一种解决办法，于是将snmp端口转发的规则调整如下：
#windows中snmp的端口转发，cacti通过这个端口采集数据
/sbin/iptables -t nat -A PREROUTING-d 189.43.138.11 -p udp -m udp --dport 11161 -j DNAT --to-destination172.16.100.83:161
再使用snmpwalk在监控服务器上获取一下数据看看:
snmpwalk -v2c -c public189.43.138.11:11161
SNMPv2-MIB::sysDescr.0 = STRING:Hardware: x86 Family 6 Model 26 Stepping 5 AT/AT COMPATIBLE - Software: WindowsVersion 5.2 (Build 3790 Multiprocessor Free)
SNMPv2-MIB::sysObjectID.0 = OID:SNMPv2-SMI::enterprises.311.1.1.3.1.2
DISMAN-EVENT-MIB::sysUpTimeInstance =Timeticks: (915656) 2:32:36.56
SNMPv2-MIB::sysContact.0 = STRING:
SNMPv2-MIB::sysName.0 = STRING: WEB2
哈哈，终于有数据了，再看看cacti中也开始有数据了。看来排查这种问题，还是需要通过抓包的方式来定位问题，比较快速！
故障总结：
对于我们IT人员来说掌握各个平台下的抓包工具的使用也是一项很重要的技能，有了这些技能我们才能在复杂的和高压力的IT工作环境中脱颖而出，达到事半功倍的效果。在工作当中如果遇到网络不通或者是获取不了数据的情况，采用抓包的方法来分析能快速的定位问题。因此，在这里也希望通过这个问题的总结让更多的人重视一些IT工具的积累和使用。