Prometheus監控報警系統
三豐，公衆号：soft張三豐Prometheus監控報警系統
監控分類可以參考這篇文章下半部分
三豐，公衆号：soft張三豐Prometheus監控（2）
監控系統搭建
• 單點服務端的搭建(prometheus)
• 單點用戶端的部署
• 單點用戶端伺服器測試
• 采集程式單點部署
• 采集程式批量部署
• 監控服務端HA / cloud (⾃⼰定制)
• 監控資料圖形化搭建（Grafana）
• 報警規則測試
• 監控+報警聯合測試
• 可選⽤腳本作為資料采集途徑
例如： shell / python / awk / lua （Nginx 安全控制，功能分類） / php / perl/ go 等等
shell ：運維的⼊門腳本，任何和性能/背景/界⾯⽆關的邏輯 都可以實作最快速的開發
（shell 是在運維領域⾥ 開發速度最快 難度最低的）
python: 各種擴充功能 擴充庫 功能豐富 ，伴随各種程式的展⽰+開發架構（如django）等 可以
實作快速的中⾼檔次的平台邏輯開發. ⽬前在運維屆 除去shell這個所有⼈必須會的腳本之外，⽕爆程度就屬python了
awk: 本⾝是⼀個實⽤指令 也是⼀門龐⼤的程式設計語⾔. 結合shell腳本 或者獨⽴ 都可以使⽤。
在⽂本和标準輸出處理上 有很⼤的優勢
lua: 多⽤于nginx的子產品結合 是⽐較新型的⼀個語⾔
php：⽼牌⼦的開發語⾔，在⼤型互聯⽹開發中，⽬前有退潮的趨勢 （PHP語⾔， php-fpm）不過在運維中⼯具開發還是很依賴PHP
perl: 傳說中 對⽂本處理最快的腳本語⾔ （但是代碼可讀性不強）
go: 新型的語⾔ ⽬前在開發和運維中 炒的很熱 ⼯資也⾼ C語⾔ 在各種後端服務邏輯的編寫上 開發速度快 成⾏早
作為監控資料采集， ⾸推 shell + python ， 如果說資料采集選取的模式對性能/背景/界⾯不依賴，那麼shell速度最快 成本最低（公司往往喜歡快的）。
采集形式分類
⼀次性采集
例如我們使⽤⽐較簡單的 shell ./monitor.sh (ps -ef | grep, netstats -an | wc )+ crontab的形式
按10秒 / 30秒 / ⼀分鐘 這樣的頻率去 單詞采集
-
優點 ⼀次性采集的模式 穩定性較好 不容易出現各種錯誤 和性能瓶頸，且開發邏輯簡單 實
現快速
- 缺點 ⼀次性采集 對于有些采集項⽬ 實作起來不夠智能 也不夠到位 例如 ⽇志的實時采集
（使⽤⼀次性采集 ⽇志⽂件 200/5xx diff grep 也可以實作 但是很low 不夠準确 不夠直覺）
背景式采集
采集程式以守護程序運⾏在Linux背景，持續不斷的采集資料：pormetheus exporter 例如
python/go開發的daemon程式 背景持續不斷的采集
- 優點：背景采集程式 資料準确性⾼ 采集密度精細 管理⽅便
- 缺點：背景采集程式 如果開發過程不夠仔細 可能會出現各種 記憶體洩漏 僵⼫程序 性能瓶頸的問題， 且開發周期較長
橋接式采集
本⾝以背景程序運⾏ 但是采集不能獨⽴ 依然跟伺服器關聯 以橋接⽅式收集采集資料
例如：NRPE for nagios
NRPE是Nagios Remote Plugin Executor的簡稱，它是nagios的一個擴充工具，用在被監控主機上。通過它可以向nagios監控伺服器提供該主機的一些本地資訊。例如：cpu負載、記憶體使用情況、磁盤容量、登陸使用者數、總程序數、僵屍程序數、swap分區使用情況等等。
注意：NRPE方式的監控，隻能監控主機本地的資訊，并不能監控資料庫。
Prometheus監控（1）
三豐，公衆号：soft張三豐Prometheus監控（1）
Prometheus監控（2）
三豐，公衆号：soft張三豐Prometheus監控（2）
微服務核心之服務編排
三豐，公衆号：soft張三豐服務編排
了解service mesh
三豐，公衆号：soft張三豐一文看懂service mesh
微服務之劃分原則
三豐，公衆号：soft張三豐微服務之劃分原則