倉庫作業機器監控系統設計與實現

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。

近期在參與一個倉庫作業機器監控項目。該項目的需求背景是：公司的電商業務在全國各地有多處或大或小的倉庫，倉庫的作業人員（沒有IT技術背景）經常反饋/投訴作業機器斷網、斷電、連不了服務等問題。實際情況經常與反饋的不一致，但營運側並沒有資料可以證明，所以才有了這個項目的需求。

該項目第一期的目標僅是收集、展示作業機器某些監控指標資料，以便在快速定位解決問題，或至少有資料可查。

為了避免大量監控資料上報影響到生產系統的網路服務，系統採用如下結構：

1. 實現一個agent用於在倉庫作業PC或作業PDA上擷取機器的監控資料；
2. 在倉庫本機伺服器上實現一個資料收集處理服務，提供API給agent上傳監控資料；資料收集處理服務會將接收到的資料持久化到資料庫，提供給倉庫本機伺服器上的webApp進行資料展示等；
3. 中心伺服器可以調用各個倉庫本機伺服器上的webApp提供的資料查詢介面（資料用於定位、發現問題）；定期按需對各個倉庫本機伺服器上的資料進行歸檔。

這樣，主要的工作都集中在作業機器上的agent和資料收集處理服務、webApp。這其中最關鍵的又是資料收集處理服務。考慮到需要多地部署營運倉庫本機伺服器，而且某些大倉庫作業機器的數目目前已多達800-1000，我們做了如下技術選型：

1. Golang實現agent、資料收集處理服務、webApp；
2. 以SQLite作為資料庫來儲存agent上報的所有資料；
3. 以NSQ作為非同步訊息佇列中介軟體；

選用Golang的理由是：可以靜態編譯，部署簡單，只需將變異好的可執行二進位程式丟到伺服器上跑起來就可以了。

選用SQLite的理由是：不必像MySQL那樣安裝server程式，無需額外部署維護。當然SQLite的檔案鎖會大大影響資料庫讀寫效能，我們通過儘可能拆分資料庫，將不同的指標資料存放區在不同的SQLite DB檔案中，甚至將每台作業機器每個指標的每天的資料分別儲存在不同的DB檔案中，來儘可能減小檔案鎖的效能影響，目前看來效果還不錯。

選擇NSQ的理由是：Golang實現、分布式、伸縮性好、效能高、支援HTTP/TCP協議、內建web管理介面等。

詳細的系統結構圖如下所示：

NSQ支援多topic（不同topic的資料不同），topic又可以有多個channel（同一個topic的所有channel中的資料相同，以多播的方式實現，每個channel在client中有一個對應的處理流程來處理channel中的資料）。我們將作業機器不同的監控指標資料作為不同topic傳入NSQ，多數指標資料只需持久化到資料庫以備後用，所以這些topic僅需一個channel。

webApp基於Beego架構實現，避免重複造輪子、工作量小。webApp中的資料展示採用HighCharts、Raphael實現，相容性好。

對於機器指標資料，其實不應該使用關係型資料庫來儲存，因為這種資料的特點是：寫入之後唯讀不改、時間序列的、幾乎沒有關係型的讀取操作、連續批量資料讀取，所以開源監控系統如Cacti、Ganglia等均使用RRDtool來讀寫指標資料。所以如上所述，我們將指標資料的儲存儘可能地拆分成多個檔案以提高讀寫效能而不會造成其他問題。

系統的工作流程如下所述：

1. 作業機器上的agent啟動後會先向NSQ的register topic發送一個註冊訊息，NSQ Client根據該註冊訊息在register資料表中將該作業機器的狀態改為“正常運行中”；
2. 然後，agent定期上報監控資料到NSQ，NSQ Client中各種資料的處理流程將資料持久化到SQLite資料庫檔案；
3. 使用者訪問/中心伺服器調用API時，webApp讀取SQLite資料庫；
4. 有一個Goroutine針對註冊過的作業機器定期檢測3分鐘以內是否收到過其上報的心跳資料，若未收到，則將機器狀態從“正常運行中”改成“運行異常”，若收到，則將“運行異常”改為“正常運行中”；
5. 作業機器在順利關機時會向NSQ的register topic發送一個順利關機的訊息，Client讀取到該訊息後，會將該機器在register資料表中的狀態改為“已順利關機”。

目前，系統工作良好。之後會對系統做壓測，如果出現瓶頸，估計可能還是資料存放區，這樣的話我們可能會嘗試RRDtool或InfluxDB。