prometheus是由soundcloud開發的開源監控報警系統和時序列資料庫。從字面上理解，prometheus由兩個部分組成，乙個是監控報警系統，另乙個是自帶的時序資料庫（tsdb）
特點prometheus 的基本原理是通過 http 週期性抓取被監控元件的狀態,任意元件只要提供對應的 http 介面 並且符合 prometheus 定義的資料格式,就可以接入 prometheus 監控。
prometheus 資料結構和型別
指標格式分為兩個部分:乙份是指標名稱,另乙個是指標標籤。
標籤可體現指標的維度特徵,用於過濾和聚合。它通過標籤名(label name)和標籤值(label value) 這種鍵值對的形式,形成多種維度。
例如 , 對 於 指 標 http_request_total , 可 以 有 和 這兩個標籤。在需要分別獲取 get 和 post 返回 200 的請求時,可分別使用上述兩種指標; 在需要獲取所有返回 200 的請求時,可以通過 http_request_total完成資料的聚合,非常便捷 和通用。
指標型別有四種:
l counter(計數器):計數統計,累計多長或者累計多少次等。它的特點是只增不減,譬如 http 訪問總 量
l gauge(儀錶盤):資料是乙個瞬時值,如果當前記憶體用量,它隨著時間變化忽高忽低。
如果需要了解某個時間段內請求的響應時間,通常做法是使用平均響應時間,但這樣做無法體現資料的 長尾效應。例如,乙個 http 伺服器的正常響應時間是 30ms,但有很少幾次請求耗時 3s,通過平均響應時 間很難甄別長尾效應,
l histogram(直方圖):服務端分位,不同區間內樣本的個數,譬如班級成績,低於 60 分的 9 個,低於 70 分的 10 個,低於 80 分的 50 個
l summary(摘要):客戶端分位,直接在客戶端通過分位情況,還是用班級成績舉例:0.8 分位的是 80 分,0.9 分為 85 分,0.99 分為的是 98 分
prometheus 資料採集
prometheus 通過 http 介面的方式從各種客戶端獲取資料,這些客戶端必須符合 prometheus 監控數 據格式,通常由兩種方式,一直是侵入式埋點監控,通過在客戶端整合如果 kubernetes api 直接通過引入 prometheus go client,提供/metrics 介面查詢 kubernetes api 各種指標,另一種是通過 exporter 方式,在外部將原來各種中介軟體的監控支援轉化為 prometheus 的監控資料格式,如 redis exporter 將 reids 指標轉化為 prometheus 能夠識別的 http 請求。
prometheus 並沒有採用 json 的資料格式,而是採用 text/plain 純文字的方式 ,這是它的特殊之處。 http 返回 header 和 body 如上圖所示,指標前面兩行#是注釋,標識指標的含義和型別。指標和指標的值通過空格分割,開發者通常不需要自己拼接這種個數的資料, prometheus 提供了各種語言的 sdk 支援。
prometheus 資料儲存
prometheus 提供了兩種資料持久化方式:一種是本地儲存,通過 prometheus 自帶的 tsdb(時序資料 庫),將資料儲存到本地磁碟,為了效能考慮,建議使用 ssd。但本地儲存的容量畢竟有限,建議不要儲存 超過乙個月的資料。prometheus本地儲存經過多年改進,自prometheus2.0 後提供的v3版本tsdb效能已 經非常高,可以支援單機每秒 1000w 個指標的收集。
prometheus 本地資料儲存能力一直為大家詬病,但 prometheus 本地儲存設計的初衷就是為了監控數 據的查詢,facebook 發現 85%的查詢是針對 26 小時內的資料。所以 prometheus 本地時序資料庫的設計 更多考慮的是高效能而非分布式大容量。
另一種是遠端儲存,適用於大量歷史監控資料的儲存和查詢。通過中間層的介面卡的轉化,prometheus 將資料儲存到遠端儲存。介面卡實現 prometheus 儲存的 remote write 和 remote read 介面並把資料轉化為 遠端儲存支援的資料格式。目前,遠端儲存主要包括 opentsdb、influxdb、elasticsearch、m3db 等,其中 m3db 是目前非常受歡迎的後端儲存。
prometheus查詢語言 promql
prometheus 資料展現除了自帶的 webui 還可以通過 grafana,他們本質上都是通過 http + promql 的 方式查詢 prometheus 資料。
prometheus 提供了 http 查詢介面,當接收到請求引數後,通過 promql 引擎解析 promql,確定查 詢的資料序列和時間範圍,通過 tsdb 介面獲取對應資料塊(chunks),最後根據聚合函式處理監控資料並返回。
prometheus 告警
如果監控資料達到告警閾值 prometheus server 會通過 http 將告警傳送到告警模組 alertmanger。 prometheus 告警配置也是通過 yaml 檔案,核心是上面的 expr 表示式(告警規則)和查詢一樣也是乙個 promql 表示式。 for 代表持續時間,如果在 for 時間內持續觸發 prometheus 才發出告警
prometheus 聯邦
為了擴充套件單個 prometheus 的採集能力和儲存能力,prometheus 引入了「聯邦」的概念。多個 prometheus 節點組成兩層聯邦結構,如圖所示,上面一層是聯邦節點,負責定時從下面的 prometheus 節點獲取資料並 彙總,部署多個聯邦節點是為了實現高可用以及資料匯聚儲存。下層的 prometheus 節點又分別負責不同區域的資料採集,在多機房的事件部署中,下層的每個 prometheus 節點可以被部署到單獨的乙個機房,充當**。
prometheus動態發現kubernetes
如果 kubernetes 環境的動態發現,prometheus 通過 watch kubernetes api 動態獲取當前集群所有主機、 容器以及服務的變化情況。
cpu 利用率
rate(container_cpu_usage_seconds_total[5m])
記憶體用量(使用記憶體減去快取)
container_memory_usage_bytes -container_memory_cache
網路傳送速率
rate(container_network_transmit_bytes_total[5m])
網路接收速率
rate(container_network_receive_bytes_total[5m] )
prometheusoperator
Prometheus 監控節點
tar xf node exporter 0.18.1.linux amd64.tar.gz cd node exporter 0.18.1.linux amd64 cp node exporter usr local bin 檢視版本 root server03 media prometheus ...
Prometheus告警收斂
告警面臨的最大問題 就是告警訊息太多，很可能會導致運維人員遺漏重要的告警資訊，或者一些無關緊要的小警報太多，收件人很容易麻木，可能不再理會。如果遺漏關鍵警報沒有及時處理可能會對系統業務造成重大故障。在這個問題上，alertmanager的告警收斂配置就變得尤為重要了。合理的分組將類似的警報進行分類。...
prometheus入門介紹
參考blog，入門以prometheus為中心的服務監控系統的運作流程，包括警告管理系統alertmanager 視覺化介面 push gateway 臨時任務和批處理任務的推送處理方式。prometheus官方文件 自動抓取資料到 自動報警 視覺化展示效果 prometheus是乙個開源的服務監控...