柴少的官方网站-zabbix示例之监控TCP状态（八）

2017年11月08日 22:49:45

zabbix示例之监控TCP状态（八）

前面已经对zabbix进行了系统的介绍，感觉例子还是少一点，这里呢再写一些监控示例完善一下。

一、zabbix监控TCP状态

1.1 Shell端的操作

这个tcp的连接状态，一般在排查问题的时候会提高很好的参考依据，所以这个一般是要监控上的。

#netstat -an |awk '/(^tcp)/{++state[$NF]}END{for(key in state)print key"\t"state[key]}'

TIME_WAIT       38922
CLOSE_WAIT      14
FIN_WAIT1       25
FIN_WAIT2       3
ESTABLISHED     52
SYN_RECV        19
LISTEN  10

#可能首先会想到netstat这个我们经常使用的命令，当然一般服务器的连接量级不会太大，你可能感觉不到明显的区别。但是当你的服务器连接数好几万的时候，不仅这个统计时间会比较久而且CPU会占用特别狠，如果你又统计的很频繁如一分钟统计一次，你就会发现这并不是一个很好的方案了。netstat是遍历/proc下面每个PID目录，ss直接读/proc/net下面的统计信息。所以ss执行的时候消耗资源以及消耗的时间都比netstat少很多。

#ss -ant | awk 'NR>1 {++s[$1]} END {for(k in s) print k,s[k]}' #用ss可以解决上面提到的问题

LAST-ACK 1
SYN-RECV 17
ESTAB 64
FIN-WAIT-1 28
FIN-WAIT-2 10
TIME-WAIT 54540
CLOSE-WAIT 13
LISTEN 10

#当然可以对比下时间：

#time netstat -an |awk '/(^tcp)/{++state[$NF]}END{for(key in state)print key"\t"state[key]}'   #当然时间这么长也跟cpu有点少有关系，如果cpu核数多的话会比这个1分多快好多的
TIME_WAIT       35368
CLOSE_WAIT      16
FIN_WAIT1       18
ESTABLISHED     37
FIN_WAIT2       4
SYN_RECV        28
LISTEN  10

real    1m8.908s
user    0m0.871s
sys     0m41.140s

#time ss -ant | awk 'NR>1 {++s[$1]} END {for(k in s) print k,s[k]}'   #可以看到在连接数比较大cpu核数不是太多的情况下，ss速度更多更精确
SYN-RECV 23
ESTAB 48
FIN-WAIT-1 38
FIN-WAIT-2 1
TIME-WAIT 54213
CLOSE-WAIT 18
LISTEN 10

real    0m0.298s
user    0m0.252s
sys     0m0.081s

#从上面的对比结果来看效率上面相差太多了。

#而ss它利用到了TCP协议栈中tcp_diag。tcp_diag是一个用于分析统计的模块，可以获得Linux内核中第一手的信息，这就确保了ss的快捷高效。

编写shell脚本：

#vim /etc/zabbix/scripts/tcp_status.sh #先编写一个获取tcp状态的脚本文件

#!/bin/bash
[ $# -ne 1 ] && echo "Usage:CLOSE-WAIT|CLOSED|CLOSING|ESTAB|FIN-WAIT-1|FIN-WAIT-2|LAST-ACK|LISTEN|SYN-RECV SYN-SENT|TIME-WAIT" && exit 1
ss_file=/home/zabbix/tmp/ss.txt
tcp_status_fun(){
    [ $1 == "ESTABLISHED" ] && TCP_STAT="ESTAB" || TCP_STAT=$1    #可能大家习惯了看ESTABLISHED，所以我做了个小小的转换。
        ss -ant | awk 'NR>1 {++s[$1]} END {for(k in s) print k,s[k]}' > $ss_file
        TCP_STAT_VALUE=$(grep ${TCP_STAT} $ss_file|awk {'print $NF'})
        if [ -z "$TCP_STAT_VALUE" ];then
           TCP_STAT_VALUE=0
        fi
        echo $TCP_STAT_VALUE
}
tcp_status_fun $1

#mkdir /home/zabbix/tmp/

#chown zabbix:zabbix /home/zabbix/tmp/

#chmod +x /etc/zabbix/scripts/tcp_status.sh

#chown zabbix:zabbix /etc/zabbix/scripts/tcp_status.sh

创建一个自定义的key：

#vim /etc/zabbix/zabbix_agentd.conf.d/tcp_status.conf #创建一个tcp_status的key

UserParameter=tcp_status[*],/etc/zabbix/scripts/tcp_status.sh $1

#chown zabbix:zabbix /etc/zabbix/zabbix_agentd.conf.d/tcp_status.conf

#/etc/init.d/zabbix_agentd restart #重启agent客户端

在proxy端或者服务端做抓取数据测试：

#因为我都是做的通过proxy代理，然后让客户端主动发送数据的形式，所以我在proxy节点上面抓取数据。

#/usr/local/zabbix/bin/zabbix_get -s 192.168.1.28 -p 10050 -k tcp_status[LISTEN] #LISTEN就作为$1传参到脚本里面去了

博文来自：www.51niux.com

1.2 zabbix服务端的web操作

创建tcp连接模板：

#创建一个叫做：TCP Connection Status的模板

创建应用集：

创建监控项：

#监控项创建起来还是很快的，因为你创建完一个之后，就可以采取点进去克隆的方式，然后就是复制$1要传递的TCP状态去覆盖然后一点添加就可以了。

创建图形：

#然后我是做了下微调，我把ESTABLISHED、LISTEN、TIME-WAIT这种会比较关注而且基本经常数值是变动的状态值放到了图形的最下面，然后用比较深的颜色标注了出来，把基本没啥数的状态丢到了上面的一坨。

主机关联模板：

所有主机批量关联模板和单个主机单独添加关联模板这个就不说了，前面也介绍过了，把这个TCP链接的模板关联上就可以了。

最后查看一下效果图：

#关于触发器，个人觉得还是要在模板里面加入宏的概念，比如你定了个连接数1000就报警，但是有的机器连接数就是要上万的，对于那些连接数就是上万的机器呢，你都引用模板了触发器的阀值又没办法单独更改，所以引用宏变量是一个不错的解决方案。

#简单的TCP状态的检测模板，没有做触发器，直接导入就可以用了，触发器可以根据自己的需求来搞。

#TCP状态检测模板：

zbx_export_templates.xml