時間是我們最大的敵人 --奇異博士
云計算一個難點在于保障系統的高可用，當在發生故障的時候，能夠盡快的恢復（參考最近的gitlab和亞馬遜s3故障教訓）。如同奇異博士所說，工程師是在和時間作斗爭。監控和報警是工作的重中之重。一般來說，我們肯定會做好宿主機層面和服務層面的監控報警，否則系統形如裸奔。
然而，某些場景中，宿主機和服務運行正常，但是上面的虛擬機被異常關機或者重啟，抑或網絡連通性出現問題（包括私有網，外網，以及不帶外網的情況下通過L3訪問外網等），上述情況下現有的監控覆蓋不到，不能及時發現問題；另外，每次線上更新主機和網絡的服務，需要觀察升級對已有云主機的影響。基于上述問題，從用戶角度出發，有了這個線上打樁監控的方案，切實提升系統可用性和服務SLA。
背景
由于目前的環境部署中，部分線上以及線下環境存在較大的配置和環境差異，導致部分問題線下測試中不存在，無法提前發現，但是上線以后卻會對線上的業務運行造成影響；
為了可以更好的進行線上環境升級過程中虛擬機網絡連通性，以及升級以后的業務正確性檢查，考慮通過線上預埋部分打樁虛擬機，并在虛擬機內部部署自動化測試腳本的方式來實現；在發現問題以后，可以通過郵件或IM報警的方式及時進行日志推送，及時發現問題和風險，更好的保障線上的穩定性和對外版本質量。
實現思路概述
線上所有節點部署一臺虛擬機，虛擬機內部部署測試工具進行線上業務的網絡監控，主要實現的功能包括：
1）同用戶私有網互聯，所有節點之間，虛擬機的私有網采用固定ip的形式
2）機房網互連，部分節點間進行，包括同用戶和跨用戶均包含（跨租戶主要進行acl的功能檢查）
3）私有網訪問外網連通性/dns解析功能，部分節點中的部分虛擬機（dns-server功能驗證、L3功能檢查）
4）外網訪問外網連通性/dns解析功能，部分節點中的部分虛擬機（外網檢查、dns-server功能驗證）
5）公共服務訪問/優先路由驗證（虛擬機路由推送功能驗證）
其中，網絡連通性方面通過ping進行檢查，時間間隔為0.2s，結果方式采用如下的形式進行記錄：
[date] [src_ip] [dst_ip] [state] 例如：07/14/15---15:39:43 10.180.164.230 10.180.164.231 ok
網絡方面無異常出現的情況不做任何推送操作，僅打印日志記錄；在網絡出現異常后，打印日志，同時通過IM或郵件的形式進行實施告警推送。
此部分為了應對一些維護場景導致的網絡異常出現，實現中可配置業務開關來設置是否推送告警，如確定為維護操作或其他已知人為操作導致的異常，可關閉開關停止告警；并且可以在業務恢復后打開開發繼續進行監控。
由于實現中，需要在每個節點進行虛擬機的預埋，所以會占用部分線上的資源，使用中會選取最小的規格（1v1e,512M內存）來進行驗證，盡量少的占用系統資源。
實現
主要通過python fabric模塊，進行打樁機腳本與配置文件的下發和服務的部署。
另外需要考慮到日志回滾，進程守護等問題。進行好logrotate，和supervisor配置文件的準備。
配置說明
- 本程序是通過讀取 private_network.list 進入對應的云主機（用root登錄）
- 另外需要準備這些 云主機 root 賬戶的ssh私鑰。并在 remote_test.py 中進行配置
- 在 /config 目錄下的 global.conf 進行全局配置。包括郵件報警是否開啟，收件人，測試的環境等
ip_list 目錄下，各個需要 check 的 ip list 準備好
- 私有網
- 機房網
- 外網ip
- dns 連通性測試ip
運行
執行一次，在命令行下看連通性結果。
fab -f network_check.py dry_run
拉起所有節點云主機測試連通性服務。
fab -f network_check.py start
停止所有節點測試連通性服務。
fab -f network_check.py stop
抓回所有節點的日志。
fab -f network_check.py get_log
并行執行,可以加上 -P 參數。
fab -f network_check.py start -P
實現效果展示
報警消息
登錄到哨兵監控節點看一下日志，果然在10:40左右10.173.32.77網絡連通性異常。
通過私有網ip反查對應宿主機所在節點。
查看宿主機對應的監控，果然在該段時間內有異常產生。
結論
通過在物理機上部署打樁的云主機，進行網絡連通性檢測，能夠更早的發現某些異常場景，為問題排查與服務恢復爭取更多時間。
