極簡監控報警系統
目標
將基礎指標（機器資源、API響應）的監控最大化的簡化部署與維護工作。
目標機器：
適用於20~30臺機器或者API進行監控。 其報警標準也適當簡化。
目前對於機器， 僅支援*NIX型別的機器。
因為小團隊， 可能管理的機器數量也並不大， 但是又需要監控。
目標使用者：
全棧開發團隊， 需要花費更多的時間與精力在業務開發， 對監控要求不高， 但是又有基礎的監控需求。
方案特點
1. 極簡部署與執行
通過docker的方式， 只需要一個命令就可以把這一套系統搭建執行起來。
2. 視覺化、傻瓜化的配置
無論是Zabbix 還是Prometheus， 運維人員都需要知道了解底層的配置，或者對應指標的名字。 對於Zabbix這種龐然大物， 瞭解如何配置指標就需要花費一定的學習時間。
此係統使用者無需瞭解底層配置檔案的結構， 直接在UI上視覺化傻瓜化的新增、減少機器或者API即可。
由程式對應的更新配置檔案。
做到對任何技術人員都能看懂並會用。
3. Agentless
無論是Zabbix還是Prometheus， 預設都需要在被監控機器上面安裝agent。
採用Agentless方案， 會極大減輕開發團隊的運維難度與複雜度。
4. （付費功能， 需要確認）擴充套件的AlertManager
原生AlertManager只支援郵件、Slack等國外的通知方式， 擴充套件之後支援微信、國內簡訊、國內電話等方式進行通知。
5. （付費功能）AI Intelligent Alert
AlertManager 需要進行配置， 需要業務人員對資料的值比較瞭解， 如何設定閾值一直都是問題。 AIOps讓運維人員自動發現指標出現異常情況。
maybe： 自動生成Grafana報表， 展示有異常的指標
6. （付費功能）資料推送
這種實施方案一般部署於內網， 通過SSH登入的方式監控外網機器。 如果使用者想直接在外網檢視報表， 就需要將內網的監控資料推送到外網對接的docker映象， 由外網的docker映象進行報表展示。
PS: 這裡就需要應用Promethus的push gateway
功能。
7. （付費功能， 需要確認） 使用者分組
如果需要監控的機器比較多， 不同的專案或者專案組共同使用一套系統， 對使用者按照專案組進行分組會是一個比較好的選擇。 （maybe原生的Prometheus已經自帶這個功能， 如果自帶就可以作為免費Feature提供）
8. （不確定）Agentless DB Agent
當前已經有SQL/">MySQL Exporter， 但是貌似是要在遠端機器上面安裝？ 如果目前限定於監控能遠端訪問的MySQL或者其他DB， 可以直接把對應的exportor放到docker映象之中。 方便配置的時候直接呼叫
9.（不確定,看起來可以作為付費功能）RecoverManager
我自己瞎扯出來的， 當目標資源出現異常之後， 自動採取恢復措施。（比如docker重啟， 服務重啟）。
10. （免費功能， 需要可行性研究）自動生成Grafana展示報表
當前專業的運維人員都要熟悉如何搭建、配置Grafana做展示。 其中還需要學習PromSQL語句。
如果能自動生成Grafana報表， 運維複雜度下降一個等級。
實施方案 （免費功能部分）
基於原生的Prometheus原生Docker映象進行擴充套件。 擴充套件項：
-
Flask-Portal
普通模式讓使用者可以視覺化的編輯配置檔案。
高階模式就是直接把yml檔案載入顯示出來。 直接編輯、儲存
-
remote_node_exporter
基於phuslu的
remote_node_exporter進行指標監控。 該exporter通過ssh登入的方式， 實現agentless監控 -
複用當前自帶的http_exporter
實現對於API的監控
-
直接安裝black_box exporter 跟 alert manager