一、常用監控簡介
Cacti(英文含義為仙人掌〉是一套基於 PHP、MysQL、SNMP和 RRDtool開發的網絡流量監測圖形分析工具。
它通過snmpget來獲取數據，使用RRD"ocl繪圖，但使用者無須了解RDPocl復雜的參數。它提供了非常強大的數據和用戶管理功能，可以指定每一個用戶能查看樹狀結構、主機設備以及任何一張圖，還可以與LDAP
結合進行用戶認證，同時也能自定義模板，在歷史數據的展示監控方面，其功能相當不錯。Cacti
通過添加模板，使不同設備的監控添加具有可復用性，並且具備可自定義繪圖的功能，具有強大的運算能力（數據的疊加功能)
2、Nagios
Nagios是一款開源的免費網絡監視工具，能有效監控windows、Linux和Unix的主機狀態，交換機路由器等網絡設置打印機等。在系統或服務狀態異灞時發出郵件或短信報警第一時間通知網站運維人員，在狀態恢復后發出正常的郵件或短信通知。
nagios主要的特征是監控告警，最強大的就是告警功能，缺點是沒有強大的數據收集機制，並且數據出圖也很簡陋，當監控的主機越來越多時，添加主機也非常麻煩，配置文件都是基於文本配置的，不支持web方式管理和配置，這樣很容易出錯，不宜維護。
3、Zabbix
zabbix是一個基於wBB界面的提供分布式系統監視以及網絡監視功能的企業級的開源解決方案。zabbix能監視各種網絡參數，保證服務器系統的安全運營;並提供強大的通知機制以讓系統運維人員快速定位/解決存在的各種問題。
zabbix由2部分構成，zabbix server與可選組件zabbix agent。zabbix server可以通過SNMP，zabbix
agent，ping，端口監視等方法提供對遠程服務器/網絡狀態的監視，數據收集等功能，它可以運行在Linux， Solaris，H-UX，AIX，Free BSD,OpenBSD,os x等平台上。
zabbix解決了cacti沒有告警的不足，也解決了nagios不能通過web配置的缺點，同時還支持分布式部署，這使得它迅速流行起來，zabyix也成為目前中小企業監控最流行的運維監控平台。
當然，zabbix也有不足之處，它消耗的資源比較多，如果監控的主機非常多時（服務器數量超過500台)，可能會出現監控超時、告警超時、告警系統單點故障等現象，不過也有很多解決辦法，比如提高硬件性能、改變zabbix監控模式、多套zabbix等
agent代理。專門的代理服務方式進行監控，專屬的協議，裝有zabix-agent的主機就可以被zabbix-server監控，主動或被動的方式，把數據給到srver進行處理。
ssh/telent: linux主機支持ssh/telent協議
snmp;網絡設備路由器、交換機不能安裝第三方程序(agent)，使用簡單網絡協議。大多數的路由器設備支持snmp協議
ipmi通過ipmi接口進行監控，我們可以通過標准的ipmi硬件接口，監控被監控對象的物理特征，比如電/壓，溫度，風扇狀態電源情況，被廣泛使用服務監控中，包括采集cpu溫度，風扇轉遞，主板溫度，及遠程開關機等等，而且ipmi獨立於硬件和操作系統，無論是cpu， bios還是ost出t現故障，都不會影響ipmi的工作，因為ipmi的硬件設備BNCc (bashboard management controller）是獨立的板卡，獨立供電
zabbix核心組件介紹
zabbix
Server: zabbix軟件實現監控的核心和序，主要功能是與zabbixproxies和Agents進行交互、觸發器計算、發送告警通知;並將數據集中保存。與prontheus的類似可以保存收集到的數據，但是prometheus告警需要使用alter manager組件
Database storage:存儲配置信恩以及收集到的數據
web Interface: Zabbix的GUI接口，通常與server運行在同一台機器上
Proxy:可選組件，常用於分布式監控環境中，一個幫助zabbix Server收集數據，分擔zabbix Server的負載的程序Agent:部署在被監控主機上，負責收集數據發送給server
4、PrometheusIborg. kubernetes
borgmon(監控系統)對應克隆的版本:prometheus(go語言)所以prometheus特別適合K8S 的架構上
而作為一個數據監控解決方案，它由一個大型社區支持，有來自700多家公司的6300個貢獻者，13500個代碼提交和7200個拉取請求
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層
第六層:用戶展示管理層同一用戶管理、集中監控、集中維護
第五層:告警事件生成層―實時記錄告警事件、形成分析圖表（趨勢分析、可視化)
第四層:告警規則配置層告警規則設置、告警伐值設置
第三層:數據提取層定時采集數據到監控模塊
第二層:數據展示層―數據生成曲線圖展示（對時序數據的動態展示)第一層:數據收集層多渠道監控數據
三、prometheus監控體系(一)監控體系:
系統層監控(需要監控的數據)
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數據模型（什么是標簽、什么是指標、什么是樣本)-概述
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個或多個時間序列上在給定時間范圍內的各自的一組樣本(范圍向量選擇器無法用於繪圖)
九、prometheus連接節點小實驗
(一）准備工作
關閉防火牆及安全機制，修改主機名
hostnamectl set-hostname prometheus
#其他主機分別設置server1.2.3
systemctl stop firewalld
systemctl disable firewalld
setenforce 0
vim /etc/selinux /config
SELINUX=disabled
vim /etc/reslove.conf
nameserver 114.114.114.114
#時間同步
ntpdate ntp1.aliyun . com
第一步准備（加時間同步）
第二步解壓
第三步執行
第四步去瀏覽器查看
第五步工作節點部署
第六步執行
第七步加入節點，再次執行
第八步查看界面是否添加節點
表達式瀏覽器常規使用
在prometheusUI控制台上可以進行數據過濾####簡單的用法:
#CPU使用總量
node cpu_seconds_total r#進階1:
計算過去5分鍾內的cPU使用速率
PromQL: irate (node_cpu_seconds_total {mode="idle" } [ 5m])解析:
irate:速率計算數(靈敏度非常高的)
node_cpu_seconds_total:node節點cPU使用總量mode="idle"空閑指標
5m:過去的5分鍾內，所有cPU空閑數的樣本值，每個數值做速率運算#進階2:
每台主機CPU在5分組內的平均使用率
PromQL: (1- avg (irate (node_cpu_seconds_total{mode='idle' } [5m] ) ) by (instance) )* 100
解析avg :平均值
avg (irate (node_cpu_seconds total{mode='idle' } [5m] ):可以理解為cPt空閑量的百分比by (instance):表示的是所有節點
(1- avg (irate (node_cpu_seconds_total{mode='idle' } [5m] ) ) by (instance))* 100:CPI
5分鍾內的平均使用率
其他常用的指標:
1、查詢1分鍾平均負載超過主機cPu數量兩倍的時間序列
node_load1 > on (instance) 2 * count (node_cpu_seconds_total{mode=' idle' }) by(instance)
2、內存使用率
node_ memory_MemTotal_bytes
node_ memory_MemFree_bytes
node_memory_Buffers _bytes
node memory_cached_bytes
計算使用率:
可用空間:以上后三個指標之和
己用空間:總空間減去可用空間
使用率:己用空間除以總空間
十、部署service discovery服務發現(一)相關概念
1、Prometheus指標抓取的生命周期
發現->配置-> relabel(配置定義/服務自身執行）->指標數據抓取->metrics relabel(自定義)Prometheus的服務發現
#默認: static_config :靜態配置形式的服務發現
基於文件的服務'發現;
基於DNS的服務發現;
基於API的服務發現:Kubernetes、Consul、Azure、重新標記target重新打標
metric重新打標基於K8S的服務發現
2、prometheus 服務發現機制
Prometheus server的數據抓取工作於Pull模型，因而，它必需要事先知道各Target的位置，然后才能從相應的Exporter或Instrumentation中抓取數據
對於小型的系統環境來說，通過static_configs指定各Target便能解決問題，這也是最簡單的配置方法;每個Targets用一個網絡端點(ip:port）進行標識;
對於中大型的系統環境或具有較強動態性的雲計算環境來說，靜態配置顯然難以適用;
因此，Prometheus為此專門設計了一組服務發現機制，以便於能夠基於服務注冊中心（服務總線）自動發現、檢測、分類可被監控的各rarget，以更新發生了變動的Target指標抓取的生命周期
在每個scrape_interval期間，Prometheus都會檢查執行的作業(Job) ;這些作業首先會根據Job上指定的發現配置生成target列表，此即服務發現過程;服務發現會返回一個Target列表
其中包含一組稱為元數據的標簽，這些標簽都以"meta_"為前綴;
2、prometheus 服務發現制（小加分項)
1.Prometheus Server的數據抓取工作於Pull模型，因而，它必需要事先知道各Targets
的位置，然后才能從相應的Exporter或Instrumentation中抓取數據
2.對於小型的系統環境來說，通過static_configs指定各Target便能解決問題，這也是最簡單的配置方法;每個Targets用一個網絡端點(ip:port）進行標識;
3.對於中大型的系統環境或具有較強動態性的雲計算環境來說，靜態配置顯然難以適用;
因此，Prometheus為此專門設計了一組服務發現機制，以便於能夠基於服務注冊中心（服務總線）自動發現、檢測、分類可被監控的備rarget，以及更新發生了變動的Target指標抓取的生命周期
4.在每個scrape_interval期間，Prometheus都會檢查執行的作業(Job) ;這些作業首先會根據
Job上指定的發現配置生成target列表，此即服務發現過程;服務發現會返回一個Target列表，其中包含一組稱為元數據的標簽，這些標簽都以*meta_"為前綴;
5.服務發現還會根據目標配置來設置其它標簽，這些標簽帶有""前綴和后綴，b包括"scheme"、 "address"和" metrics path_"，分別保存有target支持使用協議(http或https，默認為http) 、 target的地址及指標的URI路徑（默認為/metrics) ;
6.若URI路徑中存在任何參數，則它們的前綴會設置為" param"這些目標列表和標簽會返回給Prometheus，其中的一些標簽也可以配置中被覆蓋;
配置標簽會在抓取的生命周期中被重復利用以生成其他標簽，例如，指標上的instance標簽的默認值就來自於address標簽的值;
7.對於發現的各目標，Prometheus提供了可以重新標記（relabel)目標的機會，它定義在job配置段的relabel_config配置中，常用於實現如下功能
以上.的7條—》詳細版的prometheus 工作的生命周期
###將來自服務發現的元數據標簽中的信息附加到指標的標簽上
###過濾目標
動態發現
①基於文件服務發現
192.168.153.10
基於文件的服務發現僅僅略優於靜態配置的服務發現方式，它不依賴於任何平台或第三方服務，因而也是最為簡單和通用的實現方式。prometheus server定期從文件中加載target信息(pro-server pull指標發現機制-job_name
獲取我要pull的對象target)文件可以只用json和yaml格式，它含有定義的target列表，以及可選的標簽信息，以下第一配置，能夠將prometheus默認的靜態配置轉換為基於文件的服務發現時所需的配置;（rometheus會周期性的讀取、重載此文件中的配置，從而達到動態發現、更新的操作)
[root@prometheus files_sd]# cat prometheus.yml
# my global config
# Author: MageEdu <mage@magedu.com>
# Repo: http://gitlab.magedu.com/MageEdu/prometheus-configs/
global:
scrape_interval: 15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
# scrape_timeout is set to the global default (10s).
# Alertmanager configuration
alerting:
alertmanagers:
- static_configs:
- targets:
# - alertmanager:9093
# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
# - "first_rules.yml"
# - "second_rules.yml"
# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
# The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
- job_name: 'prometheus'
# metrics_path defaults to '/metrics'
# scheme defaults to 'http'.
file_sd_configs:
- files:
- targets/prometheus_*.yaml
refresh_interval: 2m
# All nodes
- job_name: 'nodes'
file_sd_configs:
- files:
- targets/nodes_*.yaml
refresh_interval: 2m
[root@prometheus targets]# cat nodes_centos.yaml
- targets:
- 192.168.153.20:9100
- 192.168.153.30:9100
labels:
app: node-exporter
job: node
[root@prometheus targets]# cat prometheus_server.yaml
- targets:
- 192.168.153.10:9090
labels:
app: prometheus
job: prometheus
指定yml文件啟動
[root@prometheus prometheus-2.27.1.linux-amd64]# ./prometheus --config.file=./files_sd/prometheus.yml
總結
1.指標類型
計數器：單調遞增
儀表盤：起伏特征
直方圖：平均數或分位值
sumamary(統計數據)
2.作業job和實例targets/instance
①job：能夠接收prometheus server數據scrape ；兩種job：“mysql_nodes" “mysql_master_slave”，每一種job會分開進行拉取數據以及展示數據
②指標（配置文件/promql) : targets 與 instance區別：都代表了被監控端可以吐出監控數據的被監控端這個對象，tagers偏向於表示一個集合，instance偏向於表示具體的一個可提供監控數據的對象
PromQL : 指標 {標簽1=標簽值1，......標簽N=標簽值N} 樣本（值）
3.prometheusQL兩種向量
①即時向量：表示的是一個時間刻度
②時間范圍向量：表示的是一組時間區間
③即時向量選擇器：在指定的時間戳上的數值（稱之為即時向量樣本）
④范圍向量選擇器：在一組時間區間內的0或1或多個數值（范圍向量樣本）
支持多種即時向量組合形式，不支持多種時間范圍向量組合形式
4.prometheus的配置文件
①global：全局配置 ②altermanager ：告警模塊 ③rules ④scrape（服務發現）
5.prometheus架構模型（工作流程）
scrape收集數據方式：①exporter ②自建/內建指標 ③pushgateway
服務發現：①基於fd文件 ②基於DNS——>SRV記錄 ③基於consul——>自動發現，同時利用prometheus的自身周期掃描配置文件更新項並加載的特性，實現動態更新 ④基於k8s服務發現