一步步教你用Prometheus搭建實時監控系統系列(一)——上帝之火，普羅米修斯的崛起

上帝之火

本系列講述的是開源實時監控告警解決方案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版本爲例：

下載好以後，解壓，運行

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依賴加上

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-registry-prometheus</artifactId>
</dependency>

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文件，添加以下配置：

- 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的技術資料，包含一整套企業級微服務課程以及一套秒殺課程