採集TCP連線狀態（實戰專案）
精確分析tcp連線狀態，可以精準得知伺服器的連結情況，確保web伺服器的健康
1. 命令獲取tcp的狀態
[root@web-7 ~]#
# -a 顯示所有socket、-t顯示tcp協議連線 -n 只顯示ip
[root@web-7 ~]#netstat -ant
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:10050 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN
tcp 0 0 10.0.0.7:10050 10.0.0.61:59054 TIME_WAIT
tcp 0 0 10.0.0.7:10050 10.0.0.61:58996 TIME_WAIT
2.提取精準的狀態資料
# -c 統計行數
[root@web-7 ~]#netstat -ant |grep -c TIME_WAIT
34
# 有6個tcp已經確認建立了連線
[root@web-7 ~]#netstat -ant |grep -c LISTEN
6
3. 修改自定義監控項的配置檔案，按照zabbix-agent的規則，參考寫一個。
[root@web-7 ~]#cat /etc/zabbix/zabbix_agentd.d/userparameter_mysql.conf
使用引數，自定義監控的命令
UserParameter=mysql.version,mysql -V
UserParameter=監控項名稱,監控項獲取值的命令
因此寫法如下，這裡採集LISTEN、TIME_WAIT、ESTABLISHED幾個狀態
cat >/etc/zabbix/zabbix_agentd.d/tcp_status.conf <<'EOF'
UserParameter=LISTEN,netstat -ant|grep -c LISTEN
UserParameter=TIME_WAIT,netstat -ant|grep -c TIME_WAIT
UserParameter=ESTABLISHED,netstat -ant|grep -c ESTABLISHED
EOF
重啟agent
[root@web-7 ~]#systemctl restart zabbix-agent
4.測試自定義的監控項是否可用
[root@m-61 ~]#zabbix_get -s 10.0.0.7 -k LISTEN
6
[root@m-61 ~]#zabbix_get -s 10.0.0.7 -k TIME_WAIT
38
[root@m-61 ~]#zabbix_get -s 10.0.0.7 -k ESTABLISHED
2
# nice，就這麼簡單，可以用了。
5.上述的配置檔案，也支援高階寫法，以傳參的形式動態採集值
cat > /etc/zabbix/zabbix_agentd.d/tcp_status.conf <<'EOF'
UserParameter=tcp_status[*],netstat -ant|grep -c $1
EOF
[root@web-7 ~]#systemctl restart zabbix-agent
zabbix-UI新增
建立監控項
自定義監控項的屬性
檢視最新的web7監控資料
TCP所有的連線狀態
CLOSED: 表示初始狀態。
LISTEN: 表示伺服器端的某個SOCKET處於監聽狀態，可以接受連線。
SYN_SENT:在服務端監聽後，客戶端SOCKET執行CONNECT連線時，客戶端傳送SYN報文，此時客戶端就進入
SYN_SENT狀態，等待服務端的確認
SYN_RCVD: 表示服務端接受到了SYN報文，在正常情況下，這個狀態是伺服器端的SOCKET在建立TCP連線時的三
次握手會話過程中的一箇中間狀態，很短暫，基本上用netstat你是很難看到這種狀態的，除非你特意寫了一
個客戶端測試程式，故意將三次TCP握手過程中最後一個ACK報文不予傳送。因此這種狀態時，當收到客戶端的
ACK報文後，它會進入到ESTABLISHED狀態。
ESTABLISHED：表示連線已經建立了。
FIN_WAIT_1: 這個是已經建立連線之後，其中一方請求終止連線，等待對方的FIN報文。FIN_WAIT_1狀態是當
SOCKET在ESTABLISHED狀態時，它想主動關閉連線，向對方傳送了FIN報文，此時該SOCKET即進入到FIN_WAIT_1
狀態。而當對方回應ACK報文後，則進入到FIN_WAIT_2狀態，當然在實際的正常情況下，無論對方何種情況下
，都應該馬上回應ACK報文，所以FIN_WAIT_1狀態一般是比較難見到的，而FIN_WAIT_2狀態還有時常常可以用
netstat看到。
FIN_WAIT_2：實際上FIN_WAIT_2狀態下的SOCKET，表示半連線，也即有一方要求close連線，但另外還告訴對
方，我暫時還有點資料需要傳送給你，稍後再關閉連線。
TIME_WAIT: 表示收到了對方的FIN報文，併傳送出了ACK報文，就等2MSL後即可回到CLOSED可用狀態了。如果
FIN_WAIT_1狀態下，收到了對方同時帶FIN標誌和ACK標誌的報文時，可以直接進入到TIME_WAIT狀態，而無須
經過FIN_WAIT_2狀態。
CLOSING: 這種狀態比較特殊，實際情況中應該是很少見，屬於一種比較罕見的例外狀態。正常情況下，當你
傳送FIN報文後，按理來說是應該先收到(或同時收到)對方的ACK報文，再收到對方的FIN報文。但是CLOSING狀
態表示你傳送FIN報文後，並沒有收到對方的ACK報文，反而卻也收到了對方的FIN報文。什麼情況下會出現此
種情況呢？其實細想一下，也不難得出結論：那就是如果雙方几乎在同時close一個SOCKET的話，那麼就出現
了雙方同時傳送FIN報文的情況，也即會出現CLOSING狀態，表示雙方都正在關閉SOCKET連線。
CLOSE_WAIT: 這種狀態的含義其實是表示在等待關閉。怎麼理解呢？當對方close一個SOCKET後傳送FIN報文給
自己，你係統毫無疑問地會回應一個ACK報文給對方，此時則進入到CLOSE_WAIT狀態。接下來呢，實際上你真
正需要考慮的事情是察看你是否還有資料傳送給對方，如果沒有的話，那麼你也就可以close這個SOCKET，發
送FIN報文給對方，也即關閉連線。所以你在CLOSE_WAIT狀態下，需要完成的事情是等待你去關閉連線。
LAST_ACK: 這個狀態還是比較容易好理解的，它是被動關閉一方在傳送FIN報文後，最後等待對方的ACK報文。
當收到ACK報文後，也即可以進入到CLOSED可用狀態了。
新增圖形
自定義觸發器
配置 > 主機 > 觸發器 > 建立觸發器
