轉載：https://blog.csdn.net/weixin_71429844/article/details/127518984?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522167996728616800217282571%2522%252C%2522scm%2522%253A%252220140713.130102334..%2522%257D&request_id=167996728616800217282571&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~all~top_positive~default-1-127518984-null-null.142^v76^insert_down38,201^v4^add_ask,239^v2^insert_chatgpt&utm_term=prometheus&spm=1018.2226.3001.4449
引言
一、Prometheus 概述
1、什麼是Prometheus
2、Zabbix和Prometheus區別
3、Prometheus的特點
二、運維監控平臺設計思路
三、Prometheus監控體系
1、系統層監控（需要監控的數據）
2、中間件及基礎設施類監控
2.1 redis監控內容
3、應用層監控
4、業務層監控
四、prometheus時間序列數據
1、數據來源
2、收集數據
3、prometheus(獲取方式)
五、prometheus生態組件
1、Prometheus Server
2、Client Library
3、Push Gateway
4、Exporters
5、Alertmanager
6、Service Discovery
7、grafana
六、prometheus工作原理
1、prometheus工作模式
2、prometheus工作流程
3、prometheus的侷限性
總結
1、prometheus如何收集k8s/服務的–三種方式收集
2 、如何防止告警信息轟炸
3、prometheus監控什麼
4、常見的時間序列數據庫
引言
zabbix是傳統的監控系統，出現比雲原生早，使用的是SQL關係型數據庫；而Prometheus基於谷歌的borgemon使用go語言開發，使用TSDB數據庫，所以支持雲原生。zabbix最新發布的6.0版本，知道自己處於生死存亡時刻，也支持了Prometheus使用的TSDB數據庫。
一、Prometheus 概述
1、什麼是Prometheus
Prometheus 是一個開源的服務監控系統和時序數據庫，其提供了通用的數據模型和快捷數據採集、存儲和查詢接口。它的核心組件Prometheus server會定期從靜態配置的監控目標或者基於服務發現自動配置的自標中進行拉取數據，當新拉取到的數據大於配置的內存緩存區時，數據就會持久化到存儲設備當中。
1.每個被監控的主機都可以通過專用的exporter 程序提供輸出監控數據的接口，它會在目標處收集監控數據，並暴露出一個HTTP接口供Prometheus server查詢，Prometheus通過基於HTTP的pull的方式來週期性的採集數據。
2.任何被監控的目標都需要事先納入到監控系統中才能進行時序數據採集、存儲、告警和展示，監控目標可以通過配置信息以靜態形式指定，也可以讓Prometheus通過服務發現的機制進行動態管理。
3.Prometheus 能夠直接把API Server作爲服務發現系統使用，進而動態發現和監控集羣中的所有可被監控的對象。
2、Zabbix和Prometheus區別
1.和Zabbix類似，Prometheus也是一個近年比較火的開源監控框架，和Zabbix不同之處在於Prometheus相對更靈活點，模塊間比較解耦，比如告警模塊、代理模塊等等都可以選擇性配置。服務端和客戶端都是開箱即用，不需要進行安裝。zabbix則是一套安裝把所有東西都弄好，很龐大也很繁雜。
2.zabbix的客戶端 agent 可以比較方便的通過腳本來讀取機器內數據庫、日誌等文件來做上報。而 Prometheus 的上報客戶端則分爲不同語言的SDK和不同用途的 exporter 兩種，比如如果你要監控機器狀態、mysql性能等，有大量已經成熟的 exporter 來直接開箱使用，通過http 通信來對服務端提供信息上報（server去pull信息）；而如果你想要監控自己的業務狀態，那麼針對各種語言都有官方或其他人寫好的 sdk供你使用，都比較方便，不需要先把數據存入數據庫或日誌再供zabbix-agent採集。
3.zabbix的客戶端更多是隻做上報的事情，push模式。而Prometheus則是客戶端本地也會存儲監控數據，服務端定時來拉取想要的數據。
4.界面來說zabbix比較陳舊，而prometheus比較新且非常簡潔，簡潔到只能算一個測試和配置平臺。要想獲得良好的監控體驗，搭配Grafana還是二者的必走之路。
3、Prometheus的特點
多維數據模型：由度量名稱和鍵值對標識的時間序列數據
時序數據，是在一段時間內通過重複測量（measurement）而獲得的觀測值的集合；將這些觀測值繪製於圖形之上，它會有一個數據軸和一個時間軸；
服務器指標數據、應用程序性能監控數據、網絡數據等也都是時序數據；
1.內置時間序列（pime series）數據庫：Prometheus；外置的遠端存儲通常會用：InfluxDB、openTsDB等
2.promQL一種靈活的查詢語言，可以利用多維數據完成複雜查詢
3.基於HTTP的pull（拉取）方式採集時間序列數據
4.同時支持PushGateway組件收集數據
5.通過服務發現或者靜態配置，來發現目標服務對象
6.支持作爲數據源接入Grafana
二、運維監控平臺設計思路
① 數據收集模塊
② 數據提取模塊(prometheus-TSDB,查詢語言是promQL)
③ 監控告警模塊（布爾值表達式判斷是否需要告警，不成立是健康狀態）
可以細化爲6層
第六層:用戶展示管理層 同一用戶管理、集中監控、集中維護
第五層:告警事件生成層 實時記錄告警事件、形成分析圖表（趨勢分析、可視化)
第四層:告警規則配置層 告警規則設置、告警伐值設置（定義布爾值表達式，篩選異常狀態）
第三層:數據提取層 定時採集數據到監控模塊
第二層:數據展示層 數據生成曲線圖展示（對時序數據的動態展示)
第一層:數據收集層 多渠道監控數據（網絡，硬件，應用，數據，物理環境）
三、Prometheus監控體系
1、系統層監控（需要監控的數據）
1.CPU、Load、Memory、swap、disk、I/O、process等
2.網絡監控：網絡設備、工作負載、網絡延遲、丟包率等
2、中間件及基礎設施類監控
1.消息中間件：kafka、RocketMQ、等消息代理（redis 中間件）
2.WEB服務容器：tomcat、weblogic、apache、php、spring系列
3.數據庫/緩存數據庫：Mysql、Postgresql、MongoDB、es、redis
2.1 redis監控內容
① redis的服務狀態
② redis所在服務器的系統層監控
③ RDB和AOF日誌監控
日誌--->如果是哨兵模式--->哨兵共享集羣信息，產生的日誌--->直接包含的其他節點哨兵信息及mysql信息
3、應用層監控
用於衡量應用程序代碼狀態和性能
監控的分類：
白盒監控：自省指標，等待被下載（cadvisor）
黑盒監控：基於探針（snmp）的監控方式，不會主動干預、影響數據
4、業務層監控
用於衡量應用程序的價值，如電商業務的銷售量，ops、dau日活、轉化率等，
業務接口：登入數量，註冊數、訂單量、搜索量和支付量
四、prometheus時間序列數據
時序數據，是在一段時間內通過重複測量(measurement）而獲得的觀測值的集合將這些觀測值繪製於圖形之上，它會有一個數據軸和一個時間軸，服務器指標數據、應用程序性能監控數據、網絡數據等也都是時序數據
1、數據來源
prometheus基於HTTP call (http/https請求），從配置文件中指定的網絡端點(endpoint/IP:端口）上週期性獲取指標數據。
很多環境、被監控對象，本身是沒有直接響應/處理http請求的功能，prometheus-exporter則可以在被監控端收集所需的數據，收集過來之後，還會做標準化，把這些數據轉化爲prometheus可識別，可使用的數據（兼容格式）
2、收集數據
監控概念:白盒監控、黑盒監控
白盒監控:自省方式，被監控端內部，可以自己生成指標，只要等待監控系統來採集時提供出去即可
黑盒監控:對於被監控系統沒有侵入性，對其沒有直接"影響"，這種類似於基於探針機制進行監控（snmp協議）
Prometheus支持通過三種類型的途徑從目標上"抓取（Scrape)"指標數據（基於白盒監控);
Exporters ——>工作在被監控端，週期性的抓取數據並轉換爲pro兼容格式等待prometheus來收集，自己並不推送
Instrumentation ——>指被監控對象內部自身有數據收集、監控的功能，只需要prometheus直接去獲取
Pushgateway ——>短週期5s—10s的數據收集
3、prometheus(獲取方式)
Prometheus同其它TSDB相比有一個非常典型的特性:它主動從各Target上拉取(pull)數據，而非等待被監控端的推送(push)
兩個獲取方式各有優劣，其中，Pull模型的優勢在於:
集中控制:有利於將配置集在Prometheus server上完成，包括指標及採取速率等;
Prometheus的根本目標在於收集在rarget上預先完成聚合的聚合型數據，而非一款由事件驅動的存儲系統
通過targets（標識的是具體的被監控端）
比如配置文件中的 targets:['localhost:9090']
五、prometheus生態組件
1、Prometheus Server
收集和儲存時間序列數據
Prometheus server：服務核心組件，採用pull方式收集監控數據，通過http協議傳輸。並存儲時間序列數據。Prometheus server 由三個部分組成：Retrival，Storage，PromQL
Retrieval：負責在活躍的target 主機上抓取監控指標數據。
Storage：存儲，主要是把採集到的數據存儲到磁盤中。默認爲15天（可修改）。
PromQL：是Prometheus提供的查詢語言模塊。
2、Client Library
client Library：客戶端庫，目的在於爲那些期望原生提供 Instrumentation 功能的應用程序提供便捷的開發途徑，用於基於應用程序內建的測量系統。
3、Push Gateway
Pushgateway：類似一箇中轉站，Prometheus的server端只會使用pull方式拉取數據，但是某些節點因爲某些原因只能使用push方式推送數據，那麼它就是用來接收push而來的數據並暴露給Prometheus的server拉取的中轉站。可以理解成目標主機可以上報短期任務的數據到Pushgateway，然後Prometheus server 統一從Pushgateway拉取數據。
4、Exporters
用於暴露現有應用程序或服務（不支持Instrumentation)的指標給Prometheus Server
而pro內建了數據樣本採集器，可以通過配置文件定義，告訴prometheus到那個監控對象中採集指標數據，prometheus 採集過後，會存儲在自己內建的TSDB數據庫中，提供了promQL 支持查詢和過濾操作，同時支持自定義規則來作爲告警規則，持續分析一場指標，一旦發生，通知給alerter來發送告警信息，還支持對接外置的UI工具（grafana）來展示數據
採集、抓取數據是其自身的功能，但一般被抓去的數據一般來自於:
export/instrumentation （指標數據暴露器） 來完成的，或者是應用程序自身內建的測量系統（汽車儀表盤之類的，測量、展示）來完成
5、Alertmanager
Alertmanager：是一個獨立的告警模塊，從Prometheus server端接收到“告警通知”後，會進行去重、分組，並路由到相應的接收方，發出報警，常見的接收方式有：電子郵件、釘釘、企業微信等。
1.Prometheus Server 僅負責生成告警指示，具體的告警行爲由另一個獨立的應用程序AlertManager負責；
2.告警指示由 Prometheus Server基於用戶提供的告警規則週期性計算生成，Alertmanager 接收到Prometheus Server發來的告警指示後，基於用戶定義的告警路由向告警接收人發送告警信息。
6、Service Discovery
Service Discovery：服務發現，用於動態發現待監控的Target，Prometheus支持多種服務發現機制：文件、DNS、Consul、Kubernetes等等。
服務發現可通過第三方提供的接口，Prometheus查詢到需要監控的Target列表，然後輪詢這些Target 獲取監控數據。該組件目前由Prometheus Server內建支持
7、grafana
Grafana：是一個跨平臺的開源的度量分析和可視化工具，可以將採集的數據可視化的展示，並及時通知給告警接收方。其官方庫中具有豐富的儀表盤插件。
Prometheus 數據流向
① Prometheus server 定期從配置好的 jobs 或者 exporters 中拉取 metrics，或者接收來自 Pushgateway 發送過來的metrics，或者從其它的Prometheus server中拉取 metrics。
② Prometheus server在本地存儲收集到的 metrics，並運行定義好的 alerts.rules，記錄新 的時間序列或者向Alert manager推送警報。
③ Alertmanager 根據配置文件，對接收到的警報進行處理，發出告警。
④ 在圖形界面中，可視化採集數據。
六、prometheus工作原理
1、prometheus工作模式
1. Prometheus Server 基於服務發現（Service Discovery）機制或靜態配置獲取要監視的目標（Target），並通過每個目標上的指標 exporter來採集（Scrape）指標數據；
2. Prometheus Server 內置了一個基於文件的時間序列存儲來持久存儲指標數據，用戶可使用PromQL接口來檢索數據，也能夠按需將告警需求發往Altermanager完成告警內容發送；
3. 一些短期運行的作業的生命週期過短，難以有效地將必要的指標數據供給到Server端，它們一般會採用推送（Push）方式輸出指標數據，Prometheus藉助於Pushgateway 接收這些推送的數據，進而由server端進行抓取
2、prometheus工作流程
① Prometheus以prometheus Server 爲核心，用於收集和存儲時間序列數據。Prometheus Server從監控目標中通過pull方式拉取指標數據，或通過pushgateway 把採集的數據拉取到Prometheus server中。
② Prometheus server 把採集到的監控指標數據通過 TSDB存儲到本地HDD/ssD中。
③ Prometheus 採集的監控指標數據按時間序列存儲，通過配置報警規則，把觸發的報警發 送到Alertmanager。
④ Alertmanager 通過配置報警接收方，發送報警到郵件、釘釘或者企業微信等。
⑤ Prometheus 自帶的Web UI 界面提供 PromQL 查詢語言，可查詢監控數據。
⑥ Grafana 可接入Prometheus 數據源，把監控數據以圖形化形式展示出。
ps:告警數據採集、告警信息提取、告警通知
① 首先，需要採集監控數據，pro會週期性的pull或被push指標數據，數據採集的方式主要包括exporters、instrumentation、pushgateway 3種方式，前兩者爲pull方式獲取，pushgateway藉助於push方式推送給prometheus。
② 根據prometheus配置文件中（K8S-configmap的配置種），獲取被監控端的數據之後，保存在TSDB中，我們可以藉助Grafana或者告警平臺來展示數據，grafana的展示是通過PromQL來獲取數據。
③ prometheus通過rule配置來藉助於PromQL來定義布爾值表達式，產生告警信息
④ 一旦出現告警，prometheus產生告警信息，發送給altermanager,altermanager根據自定義的告警路由，來進行告警通知，對接第三方平臺，例如告警平臺、郵件、釘釘。
3、prometheus的侷限性
1. Prometheus是一款指際監控系統，不適合存儲事件及日誌等；它更多地展示的是趨勢性的監控，而非精準數據；
2. Prometheus認爲只有最近的監控數據纔有查詢的需要，其本地存儲的設計初衷只是保存短期（例如一個月）數據，因而不支持針對大量的歷史數據進行存儲；若需要存儲長期的歷史數據，建議基於遠端存儲機制將數據保存於InfluxDB或openTsDB等系統中；
3. Prometheus的集羣機制成熟度不高，可基於Thanos（和滅霸是一個單詞）實現Prometheus集羣的高可用及聯邦集羣
總結
1、prometheus如何收集k8s/服務的–三種方式收集
Exporters（指標暴露器）：收集節點的信息、將數據格式化或轉化爲 promtheus 可識別的http這種轉化方式/鏡像拉取方式
Instrumentation （應用內置的指標暴露器）： 收集有內置指標暴露器的信息
Pushgateway ： 收集短週期的數據
2 、如何防止告警信息轟炸
alertmanagr: prometheus可以生成告警信息，但是不能直接提供告警，需要使用一個外置的組件alertmanager來進行告警，emailetctif優勢在於，收斂、支持靜默、去重、可以防止告警信息的轟炸
把這條告警規則中的支持靜默開啓，讓它必須，配置文件裏直接改alertmanager改一個單詞
3、prometheus監控什麼
級別 監控什麼 exporter
網絡
網絡協議：http、dns、tcp、icmp;
網路硬件：路由器、交換機等
BlockBox Exporter;SNMP Exporter
主機 資源用量 node exporter
容器 資源用量 cadvisor
應用（包括Library） 延遲、錯誤，QPS,內部狀態 代碼集中集成Prometheus Client
中間件狀態 資源用量，以及服務狀態 代碼集中集成Prometheus Client
編排工具 集羣資源用量，調度等 Kubernetes Components
4、常見的時間序列數據庫
TSDB項目 官網
influxDB InfluxDB: Open Source Time Series Database | InfluxData
RRDtool RRDtool - About RRDtool
Graphite Graphite
OpenTSDB OpenTSDB - A Distributed, Scalable Monitoring System
Kdb+ KX: The Leading Provider of Time-Series Database Technology
Druid Druid | Database for modern analytics applications
KairosDB KairosDB
Prometheus Prometheus - Monitoring system & time series database