## 上帝之火 本系列講述的是開源實時監控告警解決方案`Prometheus`，這個單詞很牛逼。每次我都能聯想到帶來上帝之火的希臘之神，普羅米修斯。而這個開源的logo也是火，個人挺喜歡這個logo的設計。 本系列著重介紹`Prometheus`以及如何用它和其周邊的生態來搭建一套屬於自己的實時監控告警平臺。 本系列受眾物件為初次接觸`Prometheus`的使用者，大神勿噴，偏重於操作和實戰，但是重要的概念也會精煉出提及下。系列主要分為以下幾塊 * **`Prometheus`各個概念介紹和搭建，如何抓取資料（本次分享內容）** * 如何推送資料至`Prometheus`，推送和拉取分別用於什麼樣的場景 * `Prometheus`資料的結構以及查詢語言`PromQL`的使用 * Java應用如何和`Prometheus`整合，如何啟用服務發現，如果自定義業務指標 * `Prometheus`如何和`Grafana`視覺化套件進行整合和設定告警 * 教你如何手寫一個集成了監控Dubbo各個指標的java套件 * 實際案例分享，如何做各個業務端和系統端的監控大盤 ## Prometheus以及時序資料庫的基本概念 `Prometheus`現在在`Github`有3w多的star，基本上過萬星的開源工具，可以認為是社群裡絕對的主流，社群也相當活躍，可以有大量的經驗可以借鑑。在企業級系統中，可以放心的使用。  `Prometheus` 是由 `SoundCloud `開發的開源監控報警系統和時序列資料庫。從字面上理解，`Prometheus `由兩個部分組成，**一個是監控報警系統，另一個是自帶的時序資料庫（TSDB）**。 關於**時序資料庫(TSDB)**這裡要說下，我們可以簡單的理解為一個優化後用來處理時間序列資料的資料庫，並且資料中的陣列是由**時間**進行索引的。相比於傳統的結構化資料庫主要有幾個好處： * **時間序列資料專注於海量資料的快速攝取**。時序資料庫視資料的每一次變化為一條新的資料，從而可以去衡量變化：分析過去的變化，監測現在的變化，以及預測未來將如何變化，傳統結構化資料在資料量小的時候能做到，在資料量大的時候就需要花費大量的成本。 * **高精度資料儲存時間較短，中等或更低精度的摘要資料保留時間較長**。對於實時監控來說，不一定需要每一個精準的資料，而是固定時間段時間資料的摘要。這對於結構化資料庫來說就意味著要進行篩選，在保證大量的寫入同時還要進行帥選，這是一個超出結構化資料庫設計來處理的工作量。 * **資料庫本身必須連續計算來自高精度資料的摘要以進行長期儲存**。這些計算既包括一些簡單的聚合，同時也有一些複雜計算。傳統資料庫無法承受那麼大量的計算。因為必須去實時統計這些聚合和複雜運算。 ## 開始搭建Prometheus > https://prometheus.io/ 在`Prometheue`官網Download標籤頁進行下載，這裡以`linux`版本為例：  下載好之後，解壓，執行 ```shell nohup /data/prometheus/prometheus --web.listen-address=0.0.0.0:9090 --config.file=/data/prometheus/prometheus.yml --web.enable-lifecycle --storage.tsdb.path=/data/prometheus/data --storage.tsdb.retention.time=15d & ``` 這樣，就簡單的搭建起來`Prometheus`服務端了。這時候，我們可以在web上訪問 > http://127.0.0.1:9090 就可以訪問到管理頁面  介面上幾個標籤說明下： `Alert`：用來配置告警規則。之後我們會用`Grafana`自身的告警介面配置來代替這個。 `Graph`：用來執行PromQL語句的一個控制檯，並且可以把執行出來的語句用用圖形化進行展示，此塊我們後面章節會介紹到。 `Status`：包含系統資訊，系統狀態，配置資訊，目標節點的狀態，服務發現狀態等元資訊的檢視。 ## Prometheus整體架構以及生態  這張圖是官方的整體架構圖。米黃色部分是`Prometheus`自己的元件，綠色的為第三方的中介軟體和應用。 簡單介紹下整個`Prometheus`的生態架構： 1. `Prometheus`獲取資料的方式只有一種，就是`scrape`，也稱作`pull`，意為拉取。`Prometheus`每隔一段時間會從目標(`target`)這裡以`Http`協議拉取指標(`metrics`)，這些目標可以是應用，也可以是代理，快取中介軟體，資料庫等等一些中介軟體。 2. 拉取出來的資料`Prometheus`會存到自己的TSDB資料庫。自己的WebUI控制檯以及`Grafana`可以對其資料進行時間範圍內的不斷查詢，繪製成實時圖表工展現。 3. `Prometheus` 支援例如`zookeeper`,`consul`之類的服務發現中介軟體，用以對目標(`target`)的自動發現。而不用一個個去配置`target`了。 4. `alertManager`元件支援自定義告警規則，告警渠道也支援很多種 ## 拉取資料 `Prometheus`主要是通過拉取的方式獲取資料，說簡單點，就是每隔固定時間去訪問配置的`target`，`target`就是一個獲取資料的url。 現在我們就來模擬一個數據源，並讓`prometheus`去拉取。 新建一個`springboot`的web專案，pom依賴加上 ```xml ``` `application.properties`里加上 ``` server.port=8080 anagement.endpoints.web.exposure.include=* ``` 啟動完畢後，我們就可以在頁面上訪問如下地址： > http://127.0.0.1:8080/actuator/prometheus 得到如下資料：  ***關於`actuator`如何監控應用指標以及自定義指標我會在之後的系列裡單獨分析，這裡只要理解成我們啟動了一個服務，提供了一個url能列出一些kv形式的指標就行了。*** 例如`jvm_memory_max_bytes{area="heap",id="PS Old Gen",} 2.863661056E9`這個指標，前面是key，後面為value。 其中key上又分`key name`和`key labels，`key name`就是``jvm_memory_max_bytes`，`key labels`有2個。 這個指標提供了jvm的最大記憶體，其中`area`為`heap`，表明這是堆記憶體區域，`id`為`PS Old Gen`，表明這是老年代。綜合起來看，這個指標就是jvm中老年代的最大值。數值型別是byte，換算下來大概是286M左右。 我們有指標的資料來源後，再在`prometheus` 的根目錄下編輯`prometheus.yml`檔案，新增如下配置： ```yml - job_name: 'test' scrape_interval: 5s metrics_path: '/actuator/prometheus' static_configs: - targets: ['localhost:8080'] labels: instance: demo ``` 這個配置表示：`prometheue`每隔5秒鐘從`http://localhost:8080/actuator/prometheus`這個url拉取指標，並且為每個指標新增`instance`這個標籤。 新增完畢後，重啟`prometheus`。進入web頁面中的`targets`頁面。如果前面步驟沒問題的話，會看到：  狀態為`UP`表明`prometheue`已經成功獲取到了這個`target` 的資料。 在查詢頁面上輸入剛才那個指標的key：  這裡每個value都是`prometheus`最近一次抓取的資料。你每執行一次，資料都會變。 這裡為什麼會有多條資料呢，是因為每個指標他們的標籤不一樣。完全一樣的標籤會被歸為一種指標。 點`Graph`這標籤可以看到在時間序列下，某個指標的變化趨勢  上圖展示了系統cpu指標的變化圖。 ## 最後 如今微服務盛行，小規模的企業的微服務節點也快上百了，`Prometheus`生態能夠用最小的代價使所有的資料實時視覺化。這對於開發和運維來說，意義在於，所有的資料不再是黑盒了，至少我個人覺得所有的資料能夠被觀測和分析，是具有安全感的。 這個系列旨在利用實戰操作教你一步步搭建自己系統和業務監控大盤。後面會繼續更新。下一個章節將分析：搭建`pushgateway`去push資料到`prometheus`，以及2種不同的資料獲取方式分別用於什麼樣的場景。 ## 聯絡作者 歡迎微信公眾號關注 「**元人部落**」 **關注後回覆 "資料" 免費獲取50G的技術資料，包含一整套企業級微服務課程以及一套秒殺課程** ![file](https://img2020.cnblogs.com/other/268224/202007/268224-20200722190025193-647412