場景：

最近從大公司離職後，現在帶領小團隊做後端開發，剛起步，手下有幾個弟兄（木有運維汪）……緊急的開發1.0版本的業務中……突然一天，運營小妹說客戶反映APP端下不了單了，排查之後，是因為線上主伺服器的php-fmp程序掛掉了……涉及到交易和錢的都是大事，運維刻不容緩……

分析：

1.在帝都立馬招一個運維團隊，對現在的小團隊既浪費又不現實……
2.只好選擇搭建個運維平臺……由於之前就是運維出身，zabbix和nagios都搞過，個人比較偏向zabbix,原因就不在這裡解釋，網上一搜一大把……但是問題又來了，zabbix必須得有專人維護，譬如新增報警，修改報警條件，還會設計寫python指令碼，得還招人，又走了1中的套路，感覺不可選（就當前的 人員結構不可取）……其實我的運維需求很簡單，就幾臺伺服器出現問題的時候給我發郵件通知就行，不涉及交換機，不涉及視訊寬頻什麼的……偶然讓我發現了cloudinsight,感覺這就是我想要的

zabbix: 上家公司在用，涉及到視訊和CDN等5萬臺伺服器，是監控利器，可以二次開發, 原始碼我也分析過，木有用框架寫，前後端是一起的，當時很尷尬，很蛋疼
cloudinsight: 一個指令碼命令就可以使用監控平臺，平臺圖比較直觀，對於小團隊來說，這些監控策略就夠了，報警郵件通知也就夠了

使用：

結合大公司的運維開發經驗，個人建議在cloudinsight設定以下幾類監控報警策略（具體引數自己設定）：

1. CPU使用率大於70%
2. 記憶體使用大於80%
3. 磁碟使用率大於80%
4. 伺服器Ping不可達
5. nginx（各類程序）程序停止
6. 80（各類埠）埠不可訪問
7. 5分鐘/15分鐘load負載大於3
8. 介面（API）URL相應狀態碼不為200
   9.磁碟分割槽發生改變