上帝之火 本系列講述的是開源實時監控告警解決方案Prometheus,這個單詞很牛逼。每次我都能聯想到帶來上帝之火的希臘之神,普羅米修斯。而這個開源的logo也是火,個人挺喜歡這個logo的設計。 本系列著重介紹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
在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上訪問
就可以訪問到管理頁面
界面上幾個標簽說明下:
Alert
:用來配置告警規則。之後我們會用Grafana
自身的告警界面配置來代替這個。
Graph
:用來運行PromQL語句的一個控制台,並且可以把運行出來的語句用用圖形化進行展示,此塊我們後面章節會介紹到。
Status
:包含系統信息,系統狀態,配置信息,目標節點的狀態,服務發現狀態等元信息的查看。
Prometheus整體架構以及生態
這張圖是官方的整體架構圖。米黃色部分是Prometheus
自己的組件,綠色的為第三方的中間件和應用。
簡單介紹下整個Prometheus
的生態架構:
Prometheus
獲取數據的方式只有一種,就是scrape
,也稱作pull
,意為拉取。Prometheus
每隔一段時間會從目標(target
)這裡以Http
協議拉取指標(metrics
),這些目標可以是應用,也可以是代理,緩存中間件,資料庫等等一些中間件。- 拉取出來的數據
Prometheus
會存到自己的TSDB資料庫。自己的WebUI控制台以及Grafana
可以對其數據進行時間範圍內的不斷查詢,繪製成實時圖表工展現。 Prometheus
支持例如zookeeper
,consul
之類的服務發現中間件,用以對目標(target
)的自動發現。而不用一個個去配置target
了。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=*
啟動完畢後,我們就可以在頁面上訪問如下地址:
得到如下數據:
關於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的技術資料,包含一整套企業級微服務課程以及一套秒殺課程