監控發展的曆程
早期企業
⽆監控，全部都是⼈⼯盯着 伺服器 作業系統 軟體 ⽹絡 等等。
中前期企業
半⾃動腳本監控，利⽤shell腳本這種類似的形式，做最簡單的監控腳本，循環登陸機器 檢視⼀些狀态 之後⼈⼯記錄，⽆報警 ⽆⾃動化 ⽆監控圖形。
中期企業
⾃動化程式/腳本/軟體/監控，腳本更新換代 開始使⽤各種開源⾮開源軟體 程式 進⾏監控的搭建和開發，監控形成圖形化，加⼊報警系統 ，有⼀定的監控本⾝⾃動化實作，這個階段監控開始逐漸成型 但是仍然缺乏精确度和穩定程度 報警的精細度。
中後期企業
叢集式監控 各種外援監控⽅案。
監控開始⾃成體系 加⼊各種⾃動化。除去⾃⾝開發和搭建監控系統外，還會⼤量使⽤各種外圍監控 （各種商品監控 例如雲計算監控 監控寶 友盟等等）
監控發展出 内監控+ 外監控（内監控是企業⾃⼰搭建的⾃⽤監控， 外監控是 使⽤外援的商業監控産品 往往對産品的最外層接⼜和⽤戶⾏為進⾏更宏觀的監控）
目前和未來監控
根據⽬前的發展狀況
未來的監控 主要會在⼏個⽅⾯ 不斷的提⾼
- 監控準确性 真實性
- 監控⾼度內建⾃動化 ⽆⼈值守
- 監控成本的⽇益降低
- 監控和CMDB的內建化以及⾃愈系統的發展
随着企業智能運維的不斷建設，CMDB作為運維資料治理的重要手段日益重要。傳統配置管理存在資料品質差、消費場景單一、無法支撐業務等問題。配置管理(CMDB)産品管理企業IT運維的中繼資料并確定資料的正确，以可配置、可維護的資料支撐力量促進運維監控、服務管理、運維自動化以及營運分析相關的資料消費場景落地實施。
企業目前實用的技術和工具
-
腳本監控（目前依然使⽤最原始的 腳本運⾏的形式 采集和監控的公司 依然不在少數 很多時候是
為了節約成本）
- 開源/⾮開源⼯具監控 如：Nagios / Cacti / icinga / Zabbix / Ntop / prometheus / 等等。
- 報警系統 ：Pagerduty / ⾃建語⾳報警系統 / ⾃建郵件系統/ ⾃建短信通知 / 各種商業報警産品
監控目前面臨的一些問題
- 監控⾃動化依然不夠
- 很少能和CMDB完善的結合起來
- 監控依然需要⼤量的⼈⼯
- 監控的準确性和真實性 提⾼的緩慢
- 監控⼯具和⽅案的制定 較為潦草
- 對監控本⾝的重視程度 依然有待提⾼
未來理想化的監控
- 完整⾃愈式監控體系
監控和報警 總歸還是隻能發現問題。出現問題之後的處理 依然需要⼈⼯的⼤量⼲預。
未來當⾃愈系統完善之後，各種層級的問題 都會被各種⾃動化 持續內建 ⼈⼯智能 災備 系統緩沖 等等技術⾃⾏修複。
- 真實鍊路式監控
監控和報警的準确性 真實性 發展到最終級的⼀個理想化模型。
舉個例⼦：當系統發出報警資訊後，往往是各個層級的報警 ⼀⼤堆⼀起發出 把真實引起問題的地⽅掩蓋住，⾮常不利于我們即時的發現和處理問題。
例如：真實發⽣的問題 是在于 資料庫的⼀個新的聯合查詢 對系統資源消耗太⼤，造成各個⽅⾯的資源被⼤量消耗 間接的就引起各種鍊路的問題。
于是乎 各個層⾯的報警 接踵⽽⾄， ⽇志在報警，慢查詢在報警，資料庫CPU 記憶體報警， 程式層TCP連結堆積報警， HTTP傳回碼5xx 499報警。
所有系統CPU 緩存報警， 企業級監控⽤戶流量下降報警。
種種⼀堆⼀堆被連帶出來的報警 全都暴露出來了，結果真正的背後原因 這⼀個禍根的DB查詢反⽽沒有被監控發現 或者說發現了 但是被徹底淹沒了。
最終理想的未來報警系統 可以把所有⽆關的報警全部忽略掉，以鍊路的⽅式 對問題⼀查到底 把最終引起問題的地⽅ 報警出來 讓運維和開發 即時做出響應和處理。
Prometheus監控報警系統
三豐，公衆号：soft張三豐Prometheus監控報警系統
prometheus最終獲得的metrics資料以K/V形式展示，根據key值我們可以查詢到對應的vlaue，但是我們需要通過對資料的計算得到我們想要的一個系統（應用）性能的監控項，再設定相應門檻值形成報警
以cpu的使用率為例
node_cpu是node_exporter傳回的一個key，可用來統計cpu使用率
這個key代表linux中底層的cpu時間片累積數值
cpu時間：從系統開啟CPU就開始工作了，它會記錄自己在工作中總共使用的時間的累積量，儲存在系統中
而累積的cpu使用時間還會分成幾個重要的狀态類型
cpu time分成user time（使用者态使用時間） /sys time（核心态使用時間） /nice time（nice值配置設定使用時間） /idle time（空閑時間）/irq（中斷時間）等
cpu使用率：cpu除idle（空閑）狀态外，其他所有cpu狀态的總和/總cpu時間，即cpu使用率=100%-idle/total
node_cpu代表的是cpu每核，每個狀态下的使用時間累積數值
prometheus的數字查詢指令行我們提供了非常豐富的計算函數
increase()：用來針對counter這種持續增長的數值，截取其中一段時間的增量，如increase(node_cpu[1m])代表總cpu時間在一分鐘内的增量
實際工作中的cpu為多核，采集到的資料也是為每一個核的cpu時間
sum()：起到加合的作用
sum( increase(node_cpu[1m]) )即表示所有核下的cpu時間一分鐘内的增量
通過标簽過濾得到空閑狀态下cpu使用時間node_cpu{mode=“idel”}
sum( increase(node_cpu{mode=“idel”}[1m]) )即表示空閑狀态下所有核的CPU時間一分鐘内的增量
但是在表達式浏覽器查詢的是所有監控主機的資料，使用sum()函數意味着把所有用戶端的cpu都加入總和了
by()：把sum加合到一起的數值按照指定的方式進行一層的拆分
by(instance)代表着區分不同的機器
sum( increase(node_cpu{mode=“idel”}[1m]) )by(instance)表示單台機器的空閑狀态下所有核的CPU時間一分鐘内的增量
sum( increase(node_cpu[1m]) )by(instance)表示單台機器的所有狀态下所有核的CPU時間一分鐘内的增量
1-sum( increase(node_cpu{mode=“idel”}[1m]) )by(instance)/sum( increase(node_cpu[1m]) )by(instance)*100表示單台機器的所有核cpu的使用率
Counter類型的資料，在使用時，需要結合increase()或rate()函數，資料才有意義
Guage類型的資料相較于Counter類型的資料，簡單很多，得到的監控資料直接輸出（不需要increase()，rate()之類的函數修飾，取得機關時間内的增量輸入，才能得到使用者期望的有意義的圖）
一、資料過濾
1.标簽過濾
（Prometheus圖表下方的文字注釋）
通過顔色區分不同的采集資料，可通過單擊來選擇要展示的資料
格式為key{label1=“value1”, label2=“value2”, … }，label來自采集資料時，exporters預設提供或者使用者自定義（如，查詢node_cpu_seconds_total，下方顯示node_cpu_seconds_total{cpu="1",instance="localhost:9100",job="agent",mode="user"}）
可在查詢的時候，指定label：
精确比對=：node_cpu_seconds_total{mode="idle"}
模糊比對~=：node_cpu_seconds_total{mode=~".*"}
模糊不比對!=：node_cpu_seconds_total{mode!="idle.*"}
2.數值過濾
例：node_cpu_seconds_total{mode=~".*"} > 6000
node_exporter
1 監控cpu使用率
(1).Prometheus對linux cpu的采集并不是直接傳回一個現成的cpu百分比，而是傳回linux系統中底層的cpu時間片的累積數值；而不是通過top或uptime指令這種簡單的方式檢視cpu使用率。
(2).cpu時間：linux系統開啟後，CPU開始進入工作狀态，cpu記錄其在工作中總共使用的“時間”的累積量并儲存在作業系統中，每一個不同狀态的CPU使用時間，都從0開始累計，而node_exporter會抓取常用的8種cpu狀态的累計時間數值：
cpu user time：cpu使用者态使用時間
sys time：系統/核心态使用時間
nice time：nice值配置設定使用時間
idle time：空閑時間
irq：中斷時間
… 等等
(3).而cpu使用率是指，cpu的各種狀态，除了idle以外的其他所有狀态的總和除以cpu的總時間：node_cpu_seconds_total即為CPU從開機到目前，所使用的CPU的總時間；故cpu使用率算法：(1 - sum(increase(node_cpu_seconds_total{mode="idle"}[1m])) by(instance) / sum(increase(node_cpu_seconds_total{}[1m])) by(instance)) * 100
公式解釋：
假設，系統開機運作30分鐘（暫時忽略核數，假設為1核），在這段時間中，CPU的使用如下：使用者态 8分鐘 + 核心态 15分鐘 + IO等待态 0.5分鐘 + 空閑狀态 20分鐘 + 其他狀态 0分鐘；則CPU使用率 = (所有非空閑狀态的CPU使用時間總和) / (所有狀态CPU時間總和)，即(user(8m) + sys(1.5m) + iowa(0.5m) + 0)/(30m))= ((30m) - idle(20m) / (30m))=33.3%，這30分鐘的CPU平均使用率為30%。
(4).Prometheus底層的資料采集，通過精密的算法形成的監控，更加準确、可信
(5).CPU使用率計算公式拆分
從整體來看，是通過(1-idle/total)*100%的方法擷取CPU使用率：
(1 - sum(increase(node_cpu_seconds_total{mode="idle"}[1m])) by(instance) / sum(increase(node_cpu_seconds_total{}[1m])) by(instance)) * 100
1)選擇使用的key
node_cpu_seconds_total：此時在prometheus的Console中輸入執行結果會有很多的持續增長的各種狀态的CPU使用時間
2)過濾空閑CPU時間及總CPU時間
node_cpu_seconds_total{mode="idle"}：此時在prometheus的Console中輸入執行結果各個CPU核在過濾後的持續增長的空閑CPU使用時間
node_cpu_seconds_total{}：此時在prometheus的Console中輸入執行結果各個CPU核在過濾後的持續增長的總CPU使用時間
3)擷取空閑CPU時間在一分鐘内的增量及總CPU時間在一分鐘内的增量
increase(node_cpu_seconds_total{mode="idle"}[1m])，此時在prometheus的Console中輸入執行結果各個CPU核在過濾後的空閑使用時間在一分鐘内的增量
increase(node_cpu_seconds_total{}[1m])，此時在prometheus的Console中輸入執行結果各個CPU核在過濾後總的CPU使用時間在一分鐘内的增量
4)将所有CPU核的CPU空閑時間在一分鐘内的增量求和及所有CPU核總時間在一分鐘内的增量求和
sum(increase(node_cpu_seconds_total{mode="idle"}[1m]))，此時在prometheus的Console中輸入執行結果是所有被監控的伺服器各個CPU核在過濾後的空閑CPU使用時間在一分鐘内的增量的總和
sum(increase(node_cpu_seconds_total{}[1m]))，此時在prometheus的Console中輸入執行結果是所有被監控的伺服器各個CPU核在過濾後總CPU使用時間在一分鐘内的增量的總和
5)将求和後的空閑CPU使用時間和總CPU使用時間按伺服器區分
sum(increase(node_cpu_seconds_total{mode="idle"}[1m])) by(instance)，此時在prometheus的Console中輸入執行結果是每個伺服器的各個CPU核在過濾後的空閑CPU使用時間在一分鐘内的增量的總和
sum(increase(node_cpu_seconds_total{}[1m])) by(instance)，此時在prometheus的Console中輸入執行結果是每個伺服器的各個CPU核在過濾後總CPU使用時間在一分鐘内的增量的總和
6)根據(1-idle/total)*100%公式，進行計算：
(1 - sum(increase(node_cpu_seconds_total{mode="idle"}[1m])) by(instance) / sum(increase(node_cpu_seconds_total{}[1m])) by(instance)) * 100
(6).同理，求其他狀态CPU使用率
us：(sum(increase(node_cpu_seconds_total{mode="user"}[1m])) by(instance) / sum(increase(node_cpu_seconds_total{}[1m])) by(instance)) * 100
sy：(sum(increase(node_cpu_seconds_total{mode="system"}[1m])) by(instance) / sum(increase(node_cpu_seconds_total{}[1m])) by(instance)) * 100
ni：(sum(increase(node_cpu_seconds_total{mode="nice"}[1m])) by(instance) / sum(increase(node_cpu_seconds_total{}[1m])) by(instance)) * 100
id：(sum(increase(node_cpu_seconds_total{mode="idle"}[1m])) by(instance) / sum(increase(node_cpu_seconds_total{}[1m])) by(instance)) * 100
wa：(sum(increase(node_cpu_seconds_total{mode="iowait"}[1m])) by(instance) / sum(increase(node_cpu_seconds_total{}[1m])) by(instance)) * 100
hi：(sum(increase(node_cpu_seconds_total{mode="irq"}[1m])) by(instance) / sum(increase(node_cpu_seconds_total{}[1m])) by(instance)) * 100
si：(sum(increase(node_cpu_seconds_total{mode="softirq"}[1m])) by(instance) / sum(increase(node_cpu_seconds_total{}[1m])) by(instance)) * 100
st：(sum(increase(node_cpu_seconds_total{mode="steal"}[1m])) by(instance) / sum(increase(node_cpu_seconds_total{}[1m])) by(instance)) * 100
即，通過top指令查詢到的cpu使用率：
(7).在生産環境中，一般70-80%以上的CPU使用率高是由于使用者态userCPU高導緻的。使用者态CPU使用率更應用程式的運作密切相關，當伺服器上運作大量程序并行處理任務，程序之間頻繁上下頁切換是，對使用者态CPU消耗最大。
監控時，一般不單獨列出user%的使用率，因為除去iowait造成的CPU高以及少數的system%核心态使用率高之外，大部分情況都是user%造成的。
很多情況下，當伺服器硬碟IO占用過大時，CPU會等待IO的傳回進入interuptable類型的CPU等待時間，是以CPU的iowait監控也是必要的。
user：(sum(increase(node_cpu_seconds_total{mode="user"}[1m])) by(instance) / sum(increase(node_cpu_seconds_total{}[1m])) by(instance)) * 100
iowait：(sum(increase(node_cpu_seconds_total{mode="iowait"}[1m])) by(instance) / sum(increase(node_cpu_seconds_total{}[1m])) by(instance)) * 100
CPU監控的門檻值，設定在99%或100%：一般情況下，CPU使用率在80%-90%狀态下的伺服器仍然可以處理請求，但是速度會變慢；一旦CPU使用率在98%-100%，那麼整個伺服器幾乎失去了可用性。（針對linux系統的優化非常重要，通過各種核心參數、軟體參數來控制伺服器，盡量不要讓CPU堆到99%-100%）