Swcollector
基于小米运维开源的open-falcon，交换机专用agent。
感谢小米运维同学的杰出工作、开源、良好的文档和热心。
感谢来炜的宝贵建议。
简介
采集的metric列表：
- CPU利用率
- 内存利用率
- Ping延时（正常返回延时，超时返回 -1，可以用于存活告警）
- IfHCInOctets
- IfHCOutOctets
- IfHCInUcastPkts
- IfHCOutUcastPkts
- IfHCInBroadcastPkts
- IfHCOutBroadcastPkts
- IfHCInMulticastPkts
- IfHCOutMulticastPkts
- IfInDiscards
- IfOutDiscards
- IfInErrors
- IfOutErros
- IfInUnknownProtos
- IfOutQLen
- IfSpeed
- IfSpeedPercent
- IfOperStatus(接口状态，1 up, 2 down, 3 testing, 4 unknown, 5 dormant, 6 notPresent, 7 lowerLayerDown)
CPU和内存的OID私有，根据设备厂家和OS版本可能不同。目前测试过的设备：
- Cisco IOS(Version 12)
- Cisco NX-OS(Version 6)
- Cisco IOS XR(Version 5)
- Cisco IOS XE(Version 15)
- Cisco ASA (Version 9)
- Ruijie 10G Routing Switch
- Huawei VRP(Version 8)
- Huawei VRP(Version 5.20)
- Huawei VRP(Version 5.120)
- Huawei VRP(Version 5.130)
- Huawei VRP(Version 5.70)
- Juniper JUNOS(Version 10)
- H3C(Version 3.1)
- H3C(Version 5)
- H3C(Version 5.20)
- H3C(Version 7)
- DELL
- Linux
二进制安装
从这里 下载编译好的最新二进制版本即可。注意：这些二进制只能跑在64位Linux上
源码安装
依赖$GOPATH/src/github.com/gaochao1/sw
cd $GOPATH/src/github.com/gaochao1/swcollector
go get ./...
chmod +x control
./control build
./control pack
最后一步会pack出一个tar.gz的安装包，拿着这个包去部署服务即可。
升级时，确保先更新sw
cd $GOPATH/src/github.com/gaochao1/sw
git pull
部署说明
swcollector需要部署到有交换机SNMP访问权限的服务器上。
使用Go原生的ICMP协议进行Ping探测，swcollector需要root权限运行。
支持使用 Gosnmp 或 snmpwalk 进行数据采集，如果使用 snmpwalk 模式，需要在监控探针服务器上安装个snmpwalk命令
配置说明
配置文件请参照cfg.example.json，修改该文件名为cfg.json，将该文件里的IP换成实际使用的IP。
配置说明：
{
"debug": true,
"debugmetric":{ # 在日志中 debug 具体的指标
"endpoints":["192.168.56.101","192.168.56.102"], # 必填
"metrics":["switch.if.In","switch.if.Out"], # 必填
"tags":"ifName=Fa0/1" # 有则匹配 tag,如为 "" 则打印该 metric 的全部信息
},
"switch":{
"enabled": true,
"ipRange":[ #交换机IP地址段，对该网段有效IP，先发Ping包探测，对存活IP发SNMP请求
"192.168.56.101/32",
"192.168.56.102-192.168.56.120",#现在支持这样的配置方式，对区域内的ip进行ping探测，对存活ip发起snmp请求。
"172.16.114.233"
],
"gosnmp":true, #是否使用 gosnmp 采集, false 则使用 snmpwalk
"index_tag":false, #去掉 index tag 以在 n9e 上获得更好体验
"pingTimeout":300, #Ping超时时间，单位毫秒
"pingRetry":4, #Ping探测重试次数
"community":"public", #SNMP认证字符串
"snmpTimeout":1000, #SNMP超时时间，单位毫秒
"snmpRetry":5, #SNMP重试次数
"ignoreIface": ["Nu","NU","Vlan","Vl"], #忽略的接口，如Nu匹配ifName为*Nu*的接口
"ignoreOperStatus": true, #不采集IfOperStatus
"speedlimit":0, #流量的上限，如果采集计算出的流量超过这个数值，则抛弃不上报。如果填0，则以接口的速率（ifSpeed)作为上限计算。注意 interface vlan 这样的虚接口是没有 ifSpeed 的，因此不进行最大值的比较。
"ignorePkt": true, #不采集IfHCInUcastPkts和IfHCOutUcastPkts
"pktlimit": 0, #pkt的上限，如果采集计算出的包速率超过这个数值，则抛弃不上报。如果填0，则不进行最大值比较。
"ignoreBroadcastPkt": true, #不采集IfHCInBroadcastPkts和IfHCOutBroadcastPkts
"broadcastPktlimit": 0, #broadcastPkt的上限，如果采集计算出的包速率超过这个数值，则抛弃不上报。如果填0，则不进行最大值比较。
"ignoreMulticastPkt": true, #不采集IfHCInMulticastPkts和IfHCOutMulticastPkts
"multicastPktlimit": 0, #multicastPkt的上限，如果采集计算出的包速率超过这个数值，则抛弃不上报。如果填0，则不进行最大值比较。
"ignoreDiscards": true, #不采集IfInDiscards和IfOutDiscards
"discardsPktlimit": 0, #discardsPkt的上限，如果采集计算出的包速率超过这个数值，则抛弃不上报。如果填0，则不进行最大值比较。
"ignoreErrors": true, #不采集IfInErrors和IfOutErros
"errorsPktlimit": 0, #errorsPkt的上限，如果采集计算出的包速率超过这个数值，则抛弃不上报。如果填0，则不进行最大值比较。
"ignoreUnknownProtos":true, #不采集IfInUnknownProtos
"unknownProtosPktlimit": 0, #unknownProtosPkt的上限，如果采集计算出的包速率超过这个数值，则抛弃不上报。如果填0，则不进行最大值比较。
"ignoreOutQLen":true, #不采集IfOutQLen
"outQLenPktlimit": 0, #outQLenPkt的上限，如果采集计算出的包速率超过这个数值，则抛弃不上报。如果填0，则不进行最大值比较。
"fastPingMode": true,
"limitConcur": 1000, #交换机采集的并发限制
"limitCon": 4 #对于单台交换机上，多个指标采集的并发限制
},
"ecmc":{ # 从 ecmc，即夜莺的商业版上获取待监控的 ip 列表，此时 switch 中配置的 ipRange 会被忽略，当 ecmc 和 n9e 同时配置时，ecmc 优先，n9e 的配置忽略
"enabled":false, # true 即开启
"addr":"http://ecmc.example.com", # ecmc 的地址
"token":"x-user-token", # ecmc 供 api 调用的 token,在个人设置-密钥管理中配置
"nodes":[1,2,3,4] # 监控 ip 所在的 node id 列表，鼠标点在 node 上能看到节点 id
},
"n9e":{ # 从 n9e ，即夜莺的开源版上获取待监控的 ip 列表，此时 switch 中配置的 ipRange 会被忽略。
"enabled":false, # true 即开启
"addr":"http://n9e.example.com", # n9e 的地址
"user":"root", # 用户名
"pass":"1234", # 密码
"nodes":[1,2,3,4] # 监控 ip 所在的 node id 列表，可以先通过 curl -u root:1234 http://n9e.example.com/api/portal/tree 看下自己节点的 id 号
},
"n9e_v3":{ # 从 n9e ，即夜莺的开源版上获取待监控的 ip 列表，此时 switch 中配置的 ipRange 会被忽略。
"enabled":true, # true 即开启
"addr":"http://n9ev3.example.com", # n9e 的地址
"token":"x-user-token", # n9ev3 供 api 调用的 token,在个人设置-密钥管理中配置
"nodes":[4] # 监控 ip 所在的 node id 列表，鼠标点在 node 上能看到节点 id
},
"switchhosts":{
"enabled":false,
"hosts":"./hosts.json" #自定义的host与Ip地址对应表，如果配置，则上报时会用这里的host替换ip地址
},
"customMetrics":{
"enabled":false,
"template":"./custom.json" #自定义的metric列表，如果配置，会根据这个配置文件，采集额外的自定义metric
},
"transfer": {
"enabled": true,
"n9eMode":true, # 标为 true 时，将以 msgpack 方式发送数据，这样可以支持 n9e。注意将 addr 替换为 n9e 的地址和端口, n9e transfer msg接收默认端口是5811。
"addr": "127.0.0.1:8009",
"interval": 300,
"timeout": 1000
},
"http": {
"enabled": false,
"listen": ":1989",
"trustIps":["192.168.0.1","192.168.0.2"]
}
}
自定义 host 配置说明
{
"hosts":
{
"192.168.160":"test1",
"192.168.88.161":"test2",
"192.168.33.2":"test3",
"192.168.31.51":"test4"
}
}
自定义 oid 配置说明
{
"metrics":
[
{
"ipRange":[
"192.168.0.1-192.168.0.2", #使用该自定义 oid 采集的地址
"192.168.1.1"
],
"metric":"switch.AnyconnectSession", #自定义的 metric
"tag":"", #自定义的 tag
"type":"GAUGE",
"oid":"1.3.6.1.4.1.9.9.392.1.3.35.0" #自定义的 oid
},
#自定义的 oid 只支持 snmp get 方式采集，因此务必填写完整，建议先通过 snmpwalk 验证一下。
#这是 cisco asa 上 anyconnect 的在线数量
{
"ipRange":[
"192.168.1.160-192.168.1.161"
],
"metric":"switch.ConnectionStat",
"tag":"",
"type":"GAUGE",
"oid":"1.3.6.1.4.1.9.9.147.1.2.2.2.1.5.40.6"
},
#这是 cisco asa 上的防火墙连接数
{
"ipRange":[
"192.168.33.2"
],
"metric":"switch.TempStatus",
"tag":"",
"type":"GAUGE",
"oid":"1.3.6.1.4.1.9.9.13.1.3.1.3.1004"
}
#这是 cisco 交换机的温度，注意通用的 oid 是 "1.3.6.1.4.1.9.9.13.1.3.1.3"，这里 1004 是硬件 index。框式交换机可能会有多个温度（多块线卡），请根据实际需要填具体的 oid 值和相应的 tag
]
}
配置的热重载
4.0.6.2 版本起，支持配置的热重载。修改配置后无需重启 swcollector 了。 开启配置热重载需要开启 swcollector 的 http 模块。然后使用以下接口重载配置。
# curl http://127.0.0.1:1990/config/reload
注意对于 transfer 的 interval 修改，热重载无效，还是需要重启 swcollector
同时也可以使用下列接口来查看 swcollector 的相关信息（类似于 Open-Falcon 的官方的 agent)
# curl http://127.0.0.1:1990/ips
查看当前 trustIp 的列表
# curl http://127.0.0.1:1990/workdir
查看当前的工作目录
# curl http://127.0.0.1:1990/exit
远程退出进程
# curl http://127.0.0.1:1990/health
查看当前状态
# curl http://127.0.0.1:1990/version
查看当前版本
部署说明
由于是并发采集，因此每个周期的采集耗时，主要取决于被采集的交换机中，最慢的那个。 因此我们可以在 debug 模式下观察每个交换机的采集耗时。
2016/08/16 21:31:24 swifstat.go:121: IP: 192.168.10.1 PingResult: true len_list: 440 UsedTime: 5
2016/08/16 21:31:24 swifstat.go:121: IP: 192.168.10.252 PingResult: true len_list: 97 UsedTime: 2
2016/08/16 21:31:24 swifstat.go:121: IP: 192.168.13.1 PingResult: true len_list: 24 UsedTime: 1
2016/08/16 21:31:24 swifstat.go:121: IP: 192.168.14.1 PingResult: true len_list: 23 UsedTime: 1
2016/08/16 21:31:24 swifstat.go:121: IP: 192.168.23.1 PingResult: true len_list: 61 UsedTime: 2
2016/08/16 21:31:24 swifstat.go:121: IP: 192.168.12.1 PingResult: true len_list: 55 UsedTime: 1
2016/08/16 21:31:24 swifstat.go:121: IP: 192.168.12.5 PingResult: true len_list: 26 UsedTime: 2
2016/08/16 21:31:24 swifstat.go:121: IP: 192.168.12.6 PingResult: true len_list: 26 UsedTime: 2
2016/08/16 21:31:24 swifstat.go:121: IP: 192.168.12.11 PingResult: true len_list: 26 UsedTime: 2
2016/08/16 21:31:24 swifstat.go:121: IP: 192.168.12.12 PingResult: true len_list: 26 UsedTime: 2
2016/08/16 21:31:24 swifstat.go:121: IP: 192.168.12.13 PingResult: true len_list: 26 UsedTime: 2
2016/08/16 21:31:24 swifstat.go:121: IP: 192.168.12.14 PingResult: true len_list: 26 UsedTime: 2
2016/08/16 21:31:24 swifstat.go:121: IP: 192.168.12.15 PingResult: true len_list: 26 UsedTime: 2
2016/08/16 21:31:24 swifstat.go:121: IP: 192.168.12.16 PingResult: true len_list: 26 UsedTime: 2
2016/08/16 21:31:24 swifstat.go:121: IP: 192.168.12.17 PingResult: true len_list: 26 UsedTime: 2
2016/08/16 21:31:24 swifstat.go:121: IP: 192.168.12.18 PingResult: true len_list: 26 UsedTime: 2
2016/08/16 21:31:24 swifstat.go:121: IP: 192.168.12.19 PingResult: true len_list: 26 UsedTime: 2
2016/08/16 21:31:24 swifstat.go:121: IP: 192.168.12.20 PingResult: true len_list: 26 UsedTime: 2
2016/08/16 21:31:24 swifstat.go:121: IP: 192.168.12.21 PingResult: true len_list: 26 UsedTime: 2
2016/08/16 21:31:24 swifstat.go:121: IP: 192.168.12.22 PingResult: true len_list: 26 UsedTime: 2
2016/08/16 21:31:24 swifstat.go:121: IP: 192.168.12.23 PingResult: true len_list: 26 UsedTime: 2
2016/08/16 21:31:24 swifstat.go:121: IP: 192.168.12.24 PingResult: true len_list: 26 UsedTime: 2
2016/08/16 21:31:24 swifstat.go:121: IP: 192.168.12.25 PingResult: true len_list: 26 UsedTime: 2
2016/08/16 21:31:29 swifstat.go:121: IP: 192.168.11.2 PingResult: true len_list: 348 UsedTime: 10
2016/08/16 21:31:29 swifstat.go:177: UpdateIfStats complete. Process time 10.700895998s.
如下所示，我们可以发现 192.168.11.2 这个交换机的采集耗时最长，用掉了 10 秒钟，这个占用了采集周期大部分的耗时。
我们可以根据这些信息将交换机做一下分类，snmp 响应快的放在一起用一个 swcollector 采集，snmp 的超时时间可以设置的短一些，采集周期也可以设的小一点，比如30秒 响应慢的放在一起，用另外一个 swcollector 采集，snmp 的超时时间可以设置的长一点，采集周期也可以适当的放久一点，比如5分钟。
snmp 报文的响应需要消耗 cpu，因此交换机多少都对 snmp 报文的响应有速率限制，在 CPU 过高时，还可能会丢弃 snmp,icmp等优先级不高的请求。 不同品牌的对此的限定都有不同，有些型号可以通过配置修改。如果允许的话，也可以通过放开其对 snmp 的限速控制，来加快交换机对 snmp 报文的响应速度。
如此，在我们调节了 *“木桶” *中 “木板” 的长度后，选择了合适的采集周期后，swcollector 的单个实例可以很轻松的带起上百台乃至更多的交换机。
v3-v4 升级说明（重要！！！！）
由于 v4 版本的 swcollector 修改了接口数据的上报格式，从Counter修改为GAUGE。因此如果同一个 endpoint，使用升级后的 swcollector 采集时，graph 内原有数据会全部丢失！ 因此建议在升级时，开启自定义 host 功能，将交换机的 ip 地址通过 host 自定义为新的 endpoint，例如原先采集的 ip 为
"ipRange":[
"192.168.0.1-192.168.0.2",
"192.168.1.1"
],
开启 switchhosts.enabled = true，然后配置 hosts.json
{
"hosts":
{
"192.168.0.1":"sw-192.168.0.1",
"192.168.0.2":"sw-192.168.0.1",
"192.168.1.1":"sw-192.168.1.1"
}
}
这样他会以新的 "sw-192.168.x.x" 作为 endpoint 上报，原有的 192.168.x.x 依然继续保留，历史纪录不会丢失。