3、監控系統需求討論
1.可監控經常使用系統服務、應用、網絡設備等mysql
網絡層
- 網絡質量
- 流量,丟包率、帶寬
系統層
- cpu
- disk
- ram
- load
- port
應用層
- mysql 鏈接數
- nginx 併發數
- cdn 命中率
- 頁面是否被篡改
業務邏輯層
- 每小時訂單數
- 當前在線用戶
2.一臺主機上可監控多個不一樣服務、不一樣服務的監控間隔可不一樣linux
服務A:
- cpu 30
- disk 90
- load 120
服務B:
- cpu 45
- ram 60
- mysql 20
3.同一個服務在不一樣主機上的監控間隔、報警閾值可不一樣ios
報警閥值:
- 重要的服務 cpu使用率超過80%就報警,要抄送給CTO
- 不重要重要的服務 cpu使用率超過100%報警,給運維工程師
4.能夠批量的給一批主機添加、刪除、修改要監控的服務nginx
監控模板redis
linuxservicessql
- cpu
- disk
- memory
5.告警級別:安全
-
不一樣的服務 由於業務重要程度不一樣,若是出了問題能夠設置不一樣的報警級別
- 重要的服務,cup使用率打到80%,就報警
- 普通的服務,cup使用百分之98%,報警
-
能夠指定特定的服務或告警級別的事件通知給特定的用戶
- 重要的服務,抄送給CTO
- 不重要的只發送給運維工程師
-
告警的升級設定
- 發送給底層運維工程師沒處理,就發送給運維經理
- 再過半個小時沒處理,就發送給cto
-
報警合併
有一個報警池,有一個腳本對池的分析服務器
6.歷史數據 的存儲和優化網絡
- 實現用最少的空間佔用量存儲最多的有效數據
- 如何作到1s中以內取出一臺主機上全部服務的5年的監控數據?
監控數據的處理
一、存下來,趨勢圖
大數據分析 ,視角越大,越失真


時間越長,越失真
二、報警處理
7. 數據可視化,如何作出簡潔美觀的用戶界面?
8.如何實現單機支持5000+機器監控需求?
- 列式存儲
- redis 支持集羣,數據量大加機器就能夠
9.採起何種通訊方式?主動、被動?
一、server 主動 監控 客戶端
- 好處:不用裝客戶端,使用全部的網絡設備,snmp,配置簡單
- 壞處:服務器壓力大,不適合大型網絡環境,不能監控複雜的指標
二、server 被動 接收 客戶端
- 好處:大型網絡環境、監控複雜的指標、擴展能力強
- 壞處:裝客戶端、網絡設備不適用、維護起來相對複雜一點
三、主流的:混合式
一、客戶端知道監控什麼指標?
客戶端主動去問服務器我要監控什麼
二、客戶端掃描本地全部服務,所有彙報給服務器
openfalcon把機器上全部能檢測到的都抓上[2014年自動檢測到(支持一千多項)]
4、如何實現監控服務器的水平擴展?
一、採用什麼架構?
•Mysql
- 數據量太大,mysql超過1千萬條查詢起來就特別慢,
- 我在看趨勢圖時前端要查好幾分鐘,爲何zabbix的那麼快?
- 他們是怎麼作的?zabbix優秀是在2000-3000臺還能夠,要是上萬臺就會太慢
- 不要把你的監控數據存到mysql,由於會存在不少的問題
•主動通訊? Snmp,wget…
server 主動 監控 客戶端
- 好處:不用裝客戶端,使用全部的網絡設備,snmp,配置簡單
- 壞處:服務器壓力大,不適合大型網絡環境,不能監控複雜的指標
•被動通訊?Agent ---how to communicate with the monitor server
server 被動 接收 客戶端
- 好處:大型網絡環境、監控複雜的指標、擴展能力強
- 壞處:裝客戶端、網絡設備不適用、維護起來相對複雜一點
總結:主流的的仍是混合模式好
•Socket server –> Sockect client
不能夠,不少坑
•可否用現成的c/s架構? Rabbit mq, redis 訂閱發佈, http ?
二、採用HTTP好處
1.接口設計簡單
2.容易水平擴展作分佈式
3.Socket穩定成熟,省去較多的通訊維護精力
三、Http特性:
1.短鏈接
2.無狀態
3.安全認證
4.被動通訊
5、監控系統架構設計
