1. 程式人生 > 其它 >輕鬆入門普羅米修斯

輕鬆入門普羅米修斯

輕鬆入門普羅米修斯

Prometheus(由go語言(golang)開發)是一開源的監控&報警&時間序列資料庫的組合。 適合監控docker容器。因為kubernetes(俗稱k8s)的流行帶動了 prometheus的發展。

普羅原理架構圖:

Prometheus具有以下特性: 1.多維的資料模型(基於時間序列的Key、 value鍵值對) 2.靈活的查詢和聚合語言PromQL 3.提供本地儲存和分散式儲存 4.通過基於HTTP和HTTPs的Pull模型採集時間序列資料(pull資料的推送,時間序列:每段時間點的資料值指標,持續性的產生。橫軸標識時間,縱軸為資料值,一段時間內數值的動態變化,所有的點連線形成大盤式的折線圖) 5.可利用Pushgateway (Prometheus的可選中介軟體)實現Push模式 6.可通過動態服務發現或靜態配置發現目標機器(通過consul自動發現和收縮)支援多種圖表和資料大盤 *補充: open-Falcaon是小米開源的企業級監控工具,用co語言開發,包括小米、滴滴、美團等在內的網際網路公司都在使用它,是一款靈活、可拓展並且高效能的監控方案。

運維監控平臺設計思路:

1.資料收集模組 2.資料提取模組(prometheus-TSDB 查詢語言是PromQL) 3.監控告警模組―(布林值表示式判斷是否需要告警Promg (cPu使用率)>80%) 町以細化為6層 第六層:使用者展示管理層同一使用者管理、集中監控、集中維護 第五層:告警事件生成層―實時記錄告警事件、形成分析圖表(趨勢分析、視覺化) 第四層:告警規則配置層告警規則設定、告警伐值設定 第三層:資料提取層定時採集資料到監控模組 第二層:資料展示層―資料生成曲線圖展示(對時序資料的動態展示)第一層:資料收集層多渠道監控資料

普羅監控體系:

系統層監控(需要監控的資料) 1.cPU、Load、Memory、swap、disk i/o、process等 2.網路監控:網路裝置、工作負載、網路延遲、丟包率等 中介軟體及基礎設施類監控
1.訊息中介軟體:kafka、RocketMQ、等訊息代理 2.wEB伺服器容器: tomcat 3.資料庫/快取資料庫:MySQI、PostgresQL、MogoDB、es、 redisredis監控內容: redis所在伺服器的系統層監控redis 服務狀態 RDB AOF日誌監控 日誌—>如果是哨兵模式—>哨兵共享叢集資訊,產生的日誌—>直接包含的其他節點哨兵資訊及redis資訊 key的數量 key被命中的資料/次數 最大連線數——》redis 和系統:系統: ulimit -a redis:redis-cli登陸—》config get maxclients檢視最大連線 應用層監控
用於衡量應用程式程式碼狀態和效能#監控的分類#:黑盒監控,白盒監控PS: 白盒監控,自省指標,等待被下載 黑盒指標:基於探針的監控方式,不會主動干預、影響資料 業務層監控 用於衡量應用程式的價值,如電商業務的銷售量,ops、dau日活、轉化率等,業務介面:登入數量,註冊數、訂單量、搜尋量和支付量

prometheus使用場景

1.Prometheus特點: 自定義多維資料模型(時序列資料由metric名和一組key/value標籤組成) 非常高效的儲存平均一個取樣資料佔大約3.5bytes左右,320萬的時間序列,每30秒取樣,保持60天,消耗磁碟大概228G 在多維上靈活且強大的查詢語句( PromQL) 不依賴分散式儲存,支援單主節點工作通過基於HTTP的pull方式採集時序資料 可以通過push gateway進行時序列資料庫推送(pushing>可以通過服務發現或靜態配置去獲取要採集的目標伺服器多種視覺化圖表及儀表盤支援 2.使用場景 Prometheus可以很好地記錄任何純數字時間序列。它既適用於以機器為中心的監視,也適用於高度動態的面向服務的體系結構的監視。在微服務世界中,它對多維資料收集和查詢的支援是一種特別的優勢。(k8s) Prometheus是為可靠性而設計的,它是您在中斷期間要使用的系統,可讓您快速診斷問題。每個Prometheus伺服器都是獨立的,而不依賴於網路儲存或其他遠端服務。當基礎結構的其他部分損壞時,您可以依靠它,並且無需設定廣泛的基礎結構即可使用它 3.不適合的場景 普羅米修斯重視可靠性。即使在故障情況下,您始終可以檢視有關係統的可用統計資訊。如果您需要100 %的準確性(例如按請求計費),則Pprometheus並不是一個不錯的選擇,因為所收集的資料可能不會足夠詳細和完整。在這種情況下,最好使用其他系統來收集和分析資料以進行計費,並使用erometheus進行其餘的監視。

prometheus時序資料

時序資料,是在一段時間內通過重複測量(measurement》而獲得的觀測值的集合將這些觀測值繪製於圖形之上,它會有一個數據軸和一個時間軸,伺服器指標資料、應用程式效能監控資料、網路資料等也都是時序資料; 1.資料來源: prometheus基於HrTP call (http/https請求),從配置檔案中指定的網路端點(endpoint/TP;:埠)上週期性獲取指標資料。 很多環境、被監控物件,本身是沒有直接響應/處理http請求的功能,prometheus-exporter則可以在被監控端收集所需的資料,收集過來之後,還會做標準化,把這些資料轉化為prometheus可識別,可使用的資料(相容格式) 2.收集資料: 監控概念:白盒監控、黑盒監控 白盒監控:自省方式,被監控端內部,可以自己生成指標,只要等待監控系統來採集時提供出去即可 黑盒監控:對於被監控系統沒有侵入性,對其沒有直接"影響",這種類似於基於探針機制進行監控(snmp協議) Prometheus支援通過三種類型的途徑從目標上"抓取(Scrape)"指標資料(基於白盒監控); Exporters—>工作在被監控端,週期性的抓取資料並轉換為pro相容格式等待prometheus來收集,自己並不推送 Instrumentation—>指被監控物件內部自身有資料收集、監控的功能,只需要prometheus直接去獲取 Pushgateway ——>短週期5s—10s的資料收集 3.prometheus(獲取方式) Prometheus同其它rsDB相比有一個非常典型的特性:它主動從各Target.上拉取(pull)資料,而非等待被監控端的推送(push) 兩個獲取方式各有優劣,其中,Pull模型的優勢在於: 集中控制:有利於將配置集在Prometheus server上完成,包括指標及採取速率等; Prometheus的根本目標在於收集在rarget上預先完成聚合的聚合型資料,而非一款由事件驅動的儲存系統通過targets (標識的是具體的被監控端) 比如配置檔案中的targets: [ 'localhost : 9090'] exporter收集了200行數括cpu使用率{ code='cpu0'}cpu使用率{ code='cpul'}cpu使用率{ code='cpu2' }##### schme { "http" } HOST { "192.168.226.128"}Port { "9100"} PATH{ " / usr / local/ nginx/"} 需求是輸出完整的URL _sdhme_host_port_path { "http://192.168.226.128:9100/usr/local/nginx" }

prometheus生態元件:

prometheus生態圈中包含了多個元件,其中部分元件可選 1.prometheus-server: retrieval(獲取資料pull/discover) ,TSDB儲存,HTPserver 控制檯介面,內建了資料樣本採集器,可以通過配置檔案定義,告訴prometheus到那個監控物件中採集指標資料,prome theus採集過後,會儲存在自己內建的rSDB資料庫中(預設為2個月時間1),提供了promgL支援查詢和過濾操作,同時支援自定義規則來作為告警規則,持續分析一場指標,一旦發生,通知給alerter來發送告警資訊,還支援對接外接的UI工具 (grafana)來展示資料 2.pushgateway (短期週期任務) 允許短暫和批量作業將其指標暴露給普羅米修斯,由於這些型別的作業可能存在時間不足而被刪除,因此他們可以將其指標推送到pushgateway,然後pushgateway將這些指標暴露給Prometheus-server端,主要用於業務資料彙報 3.exporters (常規任務-守護程序) 專門採集一些web服務,nginx, mysql服務。因為不適合直接通過attp的方式採集資料,所以需要通過exporter採集資料(下載mysql_exporter,採集mysql資料指標) cadvisor: docker資料收集工具(docker也有自己內建的監控收集方式 exporter和instrumtations,負責專門服務資料的收集然後暴露出來等待promtheus收集 4.service discovery:原生支援k8s的服務發現,支援consul、DNS等 5.prometheus內建TSDB資料庫作為儲存(時序資料的儲存,promtheus的TSDB資料庫預設儲存15天,可以自行調整) ps:時間序列資料庫(時序資料庫)主要用於指處理代表籤(按照時間的順序變化,既時間序列化)的資料,帶時間標籤的資料也成為時間序列資料,這是一種特殊型別的資料庫,一般不會儲存長時間的資料(與mysql相比)。 資料儲存時間storge.tsdb.retention=90d引數中修改即可(或啟動時間指定) 6.alertmanagr: prometheus可以生成告警資訊,但是不能直接提供告警,需要使用一個外接的元件altermanager來進行告警,emailteor代t勢在於,收斂、支援靜默、去重、可以防止告警資訊的轟炸 7.data visualization: prometheus web ui (prometheus-server內建),也可以便用grafana 8.PrmoQL (告警規則編寫),通常告警規則的檔案指定輸出到展示介面(grafana) 9.ui表示式瀏覽器(除錯)

部署:

prometheus資料模型(什麼是標籤、什麼是指標、什麼是樣本)-概述

prometheus僅用鍵值方式儲存時序式的聚合資料,他不支援文字資訊 其中的""鍵"成為指標(metric),通常意味著cpu速率、記憶體使用率或分割槽空閒比例等 向一指標可能適配到多個目標或裝置、因而它使用"標籤"作為元資料,從而為metric新增更多的資訊描述維度例如三臺裝置,在同一時刻,都會產生例如1分組cPu負載的資料,他們都公使用相同的指標(metric),而此時一個指標,如何表示時間序列? 比如:三個node節點都公有相同的指標(例如cpu0的負載那麼就公使用相同的指標名稱) 使用指標:標籤=標籤值的格式來表樂,例如: local1 (host=node1, host=node2 ) metric icpu指標): 示例: cpu_usage{ core-" 1 ',ip-"192.168.226.128" 14.04 key cpu0 labels (元資料) 樣本 1 2 prometheus每一份樣本資料都包含了: 時序列標識:key+lables 當前時間序列的樣本值value這些標籤可以作為過濾器進行指標過濾及聚合運算,如何從上萬的資料過濾出關鍵有限的時間序列,同時從有限的時間序列在特定範圍的樣本那就需要手動編寫出時間序列的樣本表示式來過濾出我們需求的樣本資料 (一)指標型別 預設都是以雙精度浮點型資料(服務端無資料量型別資料) counter :計數器單調遞增 gauge :儀表盤:有起伏特徵的histogram:直方圖: 在一段時間範圍內對資料取樣的相關結果,並記入配置的bucket中,他可以儲存更多的資料,包括樣本值分佈在每個bucket的數量,從而prometheus就可以使用內建函式進行計算: 計算樣本平均值:以值得綜合除以值的數量 計算樣本分位值:分位數有助於瞭解符合特定標準的資料個數,例如評估響應時間超過1秒的請求比例,若超過20%則進行告警等 summary,摘要,histogram的擴充套件型別,它是直接由監控端自行聚合計算出分位數,同時 將計算結果響應給prometheus server的樣本採集請求,因而,其分位數計算是由監控端完成 (二)作業job和例項targets/instance job:能夠接收prometheus server資料scrape targets每一個可以被監控的系統,成為targets多個相同的targets的集合(類)稱為jobinstance:例項與targets (類似) 與target相比,instance更趨近於一個具體可以提供監控資料的例項,而targets則更像一個物件、目標性質 (三) prometheusQL(資料查詢語言也是時序資料庫使用語言)支援兩種向量,同時內建提供了一組用於資料處理的函式 o即時向量:最近以此時間戳上跟蹤的資料指標(一個時間點上的資料) 即時向量選擇器:返回0個1個或者多個時間序列上在給定時間戳上的各自的一個樣本該樣本成為即時樣本 時間範圍向量:指定時間範圍內所有時間戳上的資料指標 範圍向量選擇器:返回0個1個或多個時間序列上在給定時間範圍內的各自的一組樣本(範圍向量選擇器無法用於繪圖) 自古英雄多磨難