01 . Prometheus簡介及安裝配置Grafana

Promethus簡介

Prometheus受啓發於Google的Brogmon監控系統（類似的Kubernetes是從Google的Brog系統演變而來），從2012年開始由前Google工程師在Soundcloud以開源軟件的形式進行研發，而且於2015年早期對外發布早期版本。2016年5月繼Kubernetes以後成爲第二個正式加入CNCF基金會的項目，同年6月正式發佈1.0版本。2017年末發佈了基於全新存儲層的2.0版本，能更好地與容器平臺、雲平臺配合。

• Prometheus做爲新一代的雲原生監控系統，目前已經有超過650+位貢獻者參與到Prometheus的研發工做上，而且超過120+項的第三方集成。

監控的目標

在《SRE: Google運維解密》一書中指出，監控系統須要可以有效的支持白盒監控和黑盒監控。經過白盒可以瞭解其內部的實際運行狀態，經過對監控指標的觀察可以預判可能出現的問題，從而對潛在的不肯定因素進行優化。而黑盒監控，常見的如HTTP探針，TCP探針等，能夠在系統或者服務在發生故障時可以快速通知相關的人員進行處理。經過創建完善的監控體系，從而達到如下目的：

1 . 長期趨勢分析：經過對監控樣本數據的持續收集和統計，對監控指標進行長期趨勢分析。例如，經過對磁盤空間增加率的判斷，咱們能夠提早預測在將來什麼時間節點上須要對資源進行擴容。

2 . 對照分析：兩個版本的系統運行資源使用狀況的差別如何？在不一樣容量狀況下系統的併發和負載變化如何？經過監控可以方便的對系統進行跟蹤和比較。

3 . 告警：當系統出現或者即將出現故障時，監控系統須要迅速反應並通知管理員，從而可以對問題進行快速的處理或者提早預防問題的發生，避免出現對業務的影響。

4 . 故障分析與定位：當問題發生後，須要對問題進行調查和處理。經過對不一樣監控監控以及歷史數據的分析，可以找到並解決根源問題。

5 . 數據可視化：經過可視化儀表盤可以直接獲取系統的運行狀態、資源使用狀況、以及服務運行狀態等直觀的信息。

與常見監控系統比較

• 對於常見的監控系統，如Nagios、Zabbix的用戶而言，每每並不能很好的解決上述問題。這裏以Nagios爲例，以下圖所示是Nagios監控系統的基本架構:

• Nagios的主要功能是監控服務和主機。Nagios軟件須要安裝在一臺獨立的服務器上運行，該服務器稱爲監控中心,每一臺被監控的硬件主機或者服務都須要運行一個與監控中心服務器進行通訊的Nagios軟件後臺程序，能夠理解爲Agent或者插件。

• 首先對於Nagios而言，大部分的監控能力都是圍繞系統的一些邊緣性的問題，主要針對系統服務和資源的狀態以及應用程序的可用性。 例如：Nagios經過check_disk插件能夠用於檢查磁盤空間，check_load用於檢查CPU負載等。這些插件會返回4種Nagios可識別的狀態，0(OK)表示正常，1(WARNING)表示警告，2(CRITTCAL)表示錯誤，3(UNKNOWN)表示未知錯誤，並經過Web UI顯示出來。
  對於Nagios這類系統而言，其核心是採用了測試和告警(check&alert)的監控系統模型。 對於基於這類模型的監控系統而言每每存在如下問題：

1. 與業務脫離的監控：監控系統獲取到的監控指標與業務自己也是一種分離的關係。比如客戶可能關注的是服務的可用性、服務的SLA等級，而監控系統卻只能根據系統負載去產生告警；
2. 運維管理難度大：Nagios這一類監控系統自己運維管理難度就比較大，須要有專業的人員進行安裝，配置和管理，並且過程並不簡單；
3. 可擴展性低： 監控系統自身難以擴展，以適應監控規模的變化；
4. 問題定位難度大：當問題產生以後（好比主機負載異常增長）對於用戶而言，他們看到的依然是一個黑盒，他們沒法瞭解主機上服務真正的運行狀況，所以當故障發生後，這些告警信息並不能有效的支持用戶對於故障根源問題的分析和定位。

OpenTSDB是基於Hadoop/HBase的，擴展性不錯，但太重，且對於Ops的要求比較高.

InfluxDB至關不錯，但其殺手鐗功能相似於集羣化之類的，都是付費版本纔有的，且其維護基於單一的商業公司（言下之意，若是你不用商業版，其實InfluxDB也沒有什麼特別大的優點，並且仍是單一公司維護有風險,）

Graphite和Prometheus比起來，Prometheus功能更豐富強大.

Prometheus的缺點

Prometheus是一個開源的完整監控解決方案，其對傳統監控系統的測試和告警模型進行了完全的顛覆，造成了基於中央化的規則計算、統一分析和告警的新模型。 相比於傳統監控系統Prometheus具備如下優勢以下:

缺點

# 1. 總體的集羣龐大到必定程度以後(全局的監控需求)
# 2. 單個服務的集羣擴展到必定程度(單服務的監控需求)
# 3. 跨機房監控需求(單個機房單個Prometheus服務器，但須要有一個跳脫實例機房的節點進行overview)

在這些狀況下，單個節點的Prometheus可能就沒法勝任了，這時候必然就須要進行水平擴展或者引入分佈式集羣概念:

聯邦集羣

# 1. 聯邦集羣中的Prometheus節點是分層級的
# 2. 下級的Prometheus節點採集應用數據
# 3. 上級的Prometheus節點從下級的Prometheus節點上採集數據.

Prometheus並不存在高可用的解決方案

官方如今的設計是將單節點的Prometheus作好，並提供聯邦集羣這個解決方案讓用戶本身去組件本身的監控拓撲網絡，這在規模比較小的時候還能對付，規模一大就容易出錯了，維護者必須很清楚聯邦集羣每個節點負責的業務是什麼,而後各層級節點如何對應聚集數據，這很是考驗整個拓撲結構的搭建者的功力，以及維護的流程和工具

Prometheus的優勢

易於管理

Prometheus核心部分只有一個單獨的二進制文件，不存在任何的第三方依賴(數據庫，緩存等等)。惟一須要的就是本地磁盤，所以不會有潛在級聯故障的風險。

Prometheus基於Pull模型的架構方式，能夠在任何地方（本地電腦，開發環境，測試環境）搭建咱們的監控系統。對於一些複雜的狀況，還可使用 Prometheus服務發現(Service Discovery)的能力動態管理監控目標。

監控服務內部運行狀態

• Pometheus鼓勵用戶監控服務的內部狀態，基於Prometheus豐富的Client庫，用戶能夠輕鬆的在應用程序中添加對Prometheus的支持，從而讓用戶能夠獲取服務和應用內部真正的運行狀態。

好比在 Kubernetes 的 Pod 中的 docker 實例，多是內部 IP 地址，對外可見 IP 地址是 Pod 地址；
另外一方面，docker 容器應用生命週期可能會比較短，VM 上的應用是重部署，docker 則是銷燬重建，對監控系統可能會有一些新的影響。

強大的數據模型

• 全部採集的監控數據均以指標(metric)的形式保存在內置的時間序列數據庫當中(TSDB)。全部的樣本除了基本的指標名稱之外，還包含一組用於描述該樣本特徵的標籤。

以下所示:
http_request_status{code='200',content_path='/api/path', environment='produment'} => [value1@timestamp1,value2@timestamp2...]
http_request_status{code='200',content_path='/api/path2', environment='produment'} => [value1@timestamp1,value2@timestamp2...]

• 每一條時間序列由指標名稱(Metrics Name)以及一組標籤(Labels)惟一標識。每條時間序列按照時間的前後順序存儲一系列的樣本值。
• 表示維度的標籤可能來源於你的監控對象的狀態，好比code=404或者content_path=/api/path。也可能來源於的你的環境定義，好比environment=produment。基於這些Labels咱們能夠方便地對監控數據進行聚合，過濾，裁剪。

強大的查詢語言PromQL

• Prometheus內置了一個強大的數據查詢語言PromQL。

Prometheus是一個時序數據庫，（全部保存在Proetheus裏的數據都是按時間戳和值的序列順序存放的，稱爲Vector（向量）），由於是NoSQL，相比關係型數據庫Mysql能很好支持大量數據寫入.
從最新測試結果看，在硬件資源知足狀況下，Prometheus單實例每秒採集10萬條

# 每一次數據採集或獲得的即一個Sample(樣本)，其由三部分組成:
    # Metrics(指標): 包含了Metrics name以及Labels.
    # Timestamp(時間戳): 當前採樣的時間，精確到毫秒.
    # Value(採樣值): 其類型爲float64浮點數.

# 經過PromQL能夠實現對監控數據的查詢、聚合。同時PromQL也被應用於數據可視化(如Grafana)以及告警當中。
# 經過PromQL能夠輕鬆回答相似於如下問題：
    # 在過去一段時間中95%應用延遲時間的分佈範圍？
    # 預測在4小時後，磁盤空間佔用大體會是什麼狀況？
    # CPU佔用率前5位的服務有哪些？(過濾)

高效

• 對於監控系統而言，大量的監控任務必然致使有大量的數據產生。而Prometheus能夠高效地處理這些數據，對於單一Prometheus Server實例而言它能夠處理：

* 數以百萬的監控指標
* 每秒處理數十萬的數據點。

可擴展

• Prometheus是如此簡單，所以你能夠在每一個數據中心、每一個團隊運行獨立的Prometheus Sevrer。Prometheus對於聯邦集羣的支持，可讓多個Prometheus實例產生一個邏輯集羣，當單實例Prometheus Server處理的任務量過大時，經過使用功能分區(sharding)+聯邦集羣(federation)能夠對其進行擴展。

易於集成

• 使用Prometheus能夠快速搭建監控服務，而且能夠很是方便地在應用程序中進行集成。目前支持： Java， JMX， Python， Go，Ruby， .Net， Node.js等等語言的客戶端SDK，基於這些SDK能夠快速讓應用程序歸入到Prometheus的監控當中，或者開發本身的監控數據收集程序。同時這些客戶端收集的監控數據，不只僅支持Prometheus，還能支持Graphite這些其餘的監控工具。
• 同時Prometheus還支持與其餘的監控系統進行集成：Graphite， Statsd， Collected， Scollector， muini， Nagios等。
• Prometheus社區還提供了大量第三方實現的監控數據採集支持：JMX， CloudWatch， EC2， MySQL， PostgresSQL， Haskell， Bash， SNMP， Consul， Haproxy， Mesos， Bind， CouchDB， Django， Memcached， RabbitMQ， Redis， RethinkDB， Rsyslog等等。

可視化

• Prometheus Server中自帶了一個Prometheus UI，經過這個UI能夠方便地直接對數據進行查詢，而且支持直接以圖形化的形式展現數據。同時Prometheus還提供了一個獨立的基於Ruby On Rails的Dashboard解決方案Promdash。最新的Grafana可視化工具也已經提供了完整的Prometheus支持，基於Grafana能夠建立更加精美的監控圖標。基於Prometheus提供的API還能夠實現本身的監控可視化UI。

開放性

• 一般來講當咱們須要監控一個應用程序時，通常須要該應用程序提供對相應監控系統協議的支持。所以應用程序會與所選擇的監控系統進行綁定。爲了減小這種綁定所帶來的限制。對於決策者而言要麼你就直接在應用中集成該監控系統的支持，要麼就在外部建立單獨的服務來適配不一樣的監控系統。
• 而對於Prometheus來講，使用Prometheus的client library的輸出格式不止支持Prometheus的格式化數據，也能夠輸出支持其它監控系統的格式化數據，好比Graphite。
• 所以你甚至能夠在不使用Prometheus的狀況下，採用Prometheus的client library來讓你的應用程序支持監控數據採集。

相比關係型數據庫它使用了時間序列數據庫

# 時序數據庫特色:
# 1.大部分時間都是寫入操做。
# 2.寫入操做幾乎是順序添加，大多數時候數據到達後都以時間排序。
# 3.寫操做不多寫入好久以前的數據，也不多更新數據。大多數狀況在數據被採集到數秒或者數分鐘後就會被寫入數據庫。
# 4.刪除操做通常爲區塊刪除，選定開始的歷史時間並指定後續的區塊。不多單獨刪除某個時間或者分開的隨機時間的數據。
# 5.基本數據大，通常超過內存大小。通常選取的只是其一小部分且沒有規律，緩存幾乎不起任何做用。
# 6.讀操做是十分典型的升序或者降序的順序讀。
# 7.高併發的讀操做十分常見。
# InfluxDB,OpenTSDB使用的也是時序數據庫.

Prometheus組件

• 上圖爲Prometheus的基本架構以及生態中的一些組件做用:
• Prometheus的基本原理是經過HTTP協議週期性抓取被監控組件的狀態，任意組件只要提供對應的HTTP接口就能夠接入監控。不須要任何SDK或者其餘的集成過程。這樣作很是適合作虛擬化環境監控系統，好比VM、Docker、Kubernetes等。輸出被監控組件信息的HTTP接口被叫作exporter 。目前互聯網公司經常使用的組件大部分都有exporter能夠直接使用，好比Varnish、Haproxy、Nginx、MySQL、Linux系統信息(包括磁盤、內存、CPU、網絡等等).

Prometheus服務過程

• Prometheus服務過程大概是這樣:

Prometheus Daemon負責定時去目標上抓取metrics(指標)數據，每一個抓取目標須要暴露一個http服務的接口給它定時抓取。Prometheus支持經過配置文件、文本文件、Zookeeper、Consul、DNS SRV Lookup等方式指定抓取目標。Prometheus採用PULL的方式進行監控，即服務器能夠直接經過目標PULL數據或者間接地經過中間網關來Push數據。

Prometheus在本地存儲抓取的全部數據，並經過必定規則進行清理和整理數據，並把獲得的結果存儲到新的時間序列中。

Prometheus經過PromQL和其餘API可視化地展現收集的數據。Prometheus支持不少方式的圖表可視化，例如Grafana、自帶的Promdash以及自身提供的模版引擎等等。Prometheus還提供HTTP API的查詢方式，自定義所須要的輸出。

PushGateway支持Client主動推送metrics到PushGateway，而Prometheus只是定時去Gateway上抓取數據。

Alertmanager是獨立於Prometheus的一個組件，能夠支持Prometheus的查詢語句，提供十分靈活的報警方式。

Prometheus使用場景

• Prometheus適用場景

Prometheus在記錄純數字時間序列方面表現很是好。它既適用於面向服務器等硬件指標的監控，也適用於高動態的面向服務架構的監控。對於如今流行的微服務，Prometheus的多維度數據收集和數據篩選查詢語言也是很是的強大。Prometheus是爲服務的可靠性而設計的，當服務出現故障時，它可使你快速定位和診斷問題。它的搭建過程對硬件和服務沒有很強的依賴關係。

• Prometheus不適用場景

Prometheus它的價值在於可靠性，甚至在很惡劣的環境下，你均可以隨時訪問它和查看系統服務各類指標的統計信息。 若是你對統計數據須要100%的精確，它並不適用，例如：它不適用於實時計費系統。

Prometheus Server

• Prometheus Server是Prometheus組件中的核心部分，負責實現對監控數據的獲取，存儲以及查詢。 Prometheus Server能夠經過靜態配置管理監控目標，也能夠配合使用Service Discovery的方式動態管理監控目標，並從這些監控目標中獲取數據。其次Prometheus Server須要對採集到的監控數據進行存儲，Prometheus Server自己就是一個時序數據庫，將採集到的監控數據按照時間序列的方式存儲在本地磁盤當中。最後Prometheus Server對外提供了自定義的PromQL語言，實現對數據的查詢以及分析。
• Prometheus Server內置的Express Browser UI，經過這個UI能夠直接經過PromQL實現數據的查詢以及可視化。
• Prometheus Server的聯邦集羣能力可使其從其餘的Prometheus Server實例中獲取數據，所以在大規模監控的狀況下，能夠經過聯邦集羣以及功能分區的方式對Prometheus Server進行擴展。

Exporters

​ Exporter將監控數據採集的端點經過HTTP服務的形式暴露給Prometheus Server，Prometheus Server經過訪問該Exporter提供的Endpoint端點，便可獲取到須要採集的監控數據。

通常來講能夠將Exporter分爲2類：

1. 直接採集：這一類Exporter直接內置了對Prometheus監控的支持，好比cAdvisor，Kubernetes，Etcd，Gokit等，都直接內置了用於向Prometheus暴露監控數據的端點。
2. 間接採集：間接採集，原有監控目標並不直接支持Prometheus，所以咱們須要經過Prometheus提供的Client Library編寫該監控目標的監控採集程序。例如： Mysql Exporter，JMX Exporter，Consul Exporter等。

AlertManager

在Prometheus Server中支持基於PromQL建立告警規則，若是知足PromQL定義的規則，則會產生一條告警，而告警的後續處理流程則由AlertManager進行管理。在AlertManager中咱們能夠與郵件，Slack等等內置的通知方式進行集成，也能夠經過Webhook自定義告警處理方式。AlertManager即Prometheus體系中的告警處理中心。

PushGateway

​ 因爲Prometheus數據採集基於Pull模型進行設計，所以在網絡環境的配置上必需要讓Prometheus Server可以直接與Exporter進行通訊。 當這種網絡需求沒法直接知足時，就能夠利用PushGateway來進行中轉。能夠經過PushGateway將內部網絡的監控數據主動Push到Gateway當中。而Prometheus Server則能夠採用一樣Pull的方式從PushGateway中獲取到監控數據。

安裝Prometheus並配置Grafana

Prometheus基於Golang編寫，編譯後的軟件包，不須要依賴第三方依賴，用戶只須要下載對應平臺的二進制包，解壓而且添加基本的配置便可正常啓動Prometeus Server。

二進制安裝Prometheus

下載二進制包並解壓

wget https://github.com/prometheus/prometheus/releases/download/v2.13.0/prometheus-2.13.0.linux-amd64.tar.gz

tar xvf prometheus-2.13.0.linux-amd64.tar.gz -C /usr/local/
cd /usr/local/
ln -s prometheus-2.13.0.linux-amd64/ prometheus

修改配置文件

vim prometheus.yml
# 全局配置global:
  scrape_interval:     15s             # 設置抓取間隔，每15s採集一次數據，默認爲1分鐘
  evaluation_interval: 15s             # 估算規則的默認週期，每15秒計算一次規則。默認1分鐘
  # scrape_timeout                     # 默認抓取超時，默認爲10s

# Alertmanager相關配置
alerting:
  alertmanagers:
  - static_configs:
    - targets:
      # - alertmanager:9093

# 規則文件列表，使用'evaluation_interval' 參數去抓取
rule_files:				# rule_files指定加載的告警規則文件.通常在單獨的文件定義，
# 在prometheus.yml中引用.這個規則文件格式請看後面報警示例.
  # - "first_rules.yml"
  # - "second_rules.yml"

#  抓取配置列表
scrape_configs: # 指定prometheus要監控的目標.在scrape_config中每一個監控目標是一個job，但job類型有不少種,
# 能夠是最簡單的static_config,即靜態地指定每個目標
  - job_name: 'prometheus'		# 
    static_configs:
    - targets: ['localhost:9090'] # 這裏定義了一個job的名稱: job_name:'prometheus',而後定義監控節點

# 下面的內容不用寫到配置文件裏面，不然影響後面服務的啓動,只是作一個示例:
    static_config:
    - targets: ['server01:9100','IP:9100','nginxserver:9100','web006:9100','redis:9100',\
'logserver:9100','redis1:9100']
# 能夠看到target能夠並列寫入多個節點，用逗號隔開，機器名+端口號，端口號主要是exporters的端口，
# 這裏9100實際上是node_exporter的默認端口，配置完成後,prometheus就能夠經過配置文件識別監控的節點,
# 持續開始採集數據，prometheus基礎配置也就搭建好了.

# cat first_rules.yml
groups:
- name: example
  rules:
  - alert:  InstanceDown
    expr: up == 0
    for: 1m
    labels:
      severity: critical
    annotations:
      summary: Instance has been down for more than 5 minutes

建立prometheus的用戶及數據存儲目錄

# 爲了安全，咱們使用普通用戶來啓動prometheus服務，
# 做爲一個時序型數據庫產品，prometheus的數據默認會存放在應用目錄下，咱們需修改成/data/prometheus下
useradd -s /sbin/nologin -M prometheus
mkdir -p /data/prometheus
chown -R prometheus:prometheus /usr/local/prometheus
chown -R prometheus:prometheus /data/prometheus/

建立Systemd服務啓動prometheus

# prometheus的啓動很簡單，只須要從新啓動解壓目錄的二進制文件prometheus便可，
# 可是爲了更加方便的對prometheus進行管理，這裏使用systemd來啓停prometheus。
vim /usr/lib/systemd/system/prometheus.service
[Unit]
Description=Prometheus
Documentation=https://prometheus.io/
After=network.target
[Service]
Type=simple
User=prometheus
ExecStart=/usr/local/prometheus/prometheus --config.file=/usr/local/prometheus/prometheus.yml --storage.tsdb.path=/data/prometheus
Restart=on-failure
[Install]
WantedBy=multi-user.target
# 在此配置文件裏面，定義了啓動的命令，定義了數據存儲在/data/prometheus路徑下，
# 不然默認會在prometheus二進制目錄的data下.
systemctl start prometheus
systemctl status prometheus
systemctl enable prometheus

容器安裝Prometheus

對於Docker用戶，直接使用Prometheus的鏡像便可啓動Prometheus Server：

docker run -p 9090:9090 -v /etc/prometheus/prometheus.yml:/etc/prometheus/prometheus.yml prom/prometheus

瀏覽器訪問IP:9090

安裝Node Exporter採集主機數據

爲了方便看出效果，咱們到另一臺機器安裝node exporter

• 與傳統的監控zabbix來對比的話，prometheus-server就像是mysql，負責存儲數據。只不過這是時序數據庫而不是關係型的數據庫。數據的收集還須要其餘的客戶端，在prometheus中叫作exporter。針對不一樣的服務，有各類各樣的exporter，就比如zabbix的zabbix-agent同樣。

• 這裏爲了可以採集到主機的運行指標如CPU, 內存，磁盤等信息。咱們可使用Node Exporter。Node Exporter一樣採用Golang編寫，而且不存在任何的第三方依賴，只須要下載，解壓便可運行。

下載地址:

wget https://github.com/prometheus/node_exporter/releases/download/v0.18.1/node_exporter-0.18.1.linux-amd64.tar.gz

解壓node_exporter

tar xvf node_exporter-0.18.1.linux-amd64.tar.gz -C /usr/local/

# 新建一個目錄專門安裝各類exporter
mkdir -p /usr/local/prometheus_exporter
cd /usr/local
mv node_exporter-0.18.1.linux-amd64/ /usr/local/prometheus_exporter/
cd /usr/local/prometheus_exporter/
ln -s node_exporter-0.18.1.linux-amd64/ node_exporter

啓動node_exporter

#直接打開node_exporter的可執行文件便可啓動 node export，默認會啓動9100端口。建議使用nohup來啓動
/usr/local/prometheus_exporter/node_exporter/node_exporter
#建議使用nohup
nohup /usr/local/prometheus_exporter/node_exporter/node_exporter >/dev/null 2>&1 &
# 或者直接
cp /usr/local/prometheus_exporter/node_exporter-0.18.1.linux-amd64/node_exporter /usr/local/bin/
node_exporter
# 可是這些侷限性都很強，咱們能夠跟prometheus同樣，加入到系統服務，使用systemd管理

添加Node_exporter到系統服務

vim  /usr/lib/systemd/system/node_exporter.service
[Unit]
Description=node_exporter
Documentation=https://prometheus.io/
After=network.target

[Service]
Type=simple
ExecStart=/usr/local/prometheus_export/node_exporter-0.18.1.linux-amd64/node_exporter
Restart=on-failure

[Install]
WantedBy=multi-user.target

# 啓動服務
systemctl start node_exporter
systemctl daemon-reload
systemctl status node_exporter

加入開機自啓動

在 /etc/rc.local 加入上面的啓動命令便可

# 配置Prometheus,收集node exporter的數據
# 能夠看到node exporter啓動後也就是暴露了9100端口，並無把數據傳到prometheus，
# 咱們還須要在prometheus中配置，讓prometheus去pull這個接口的數據。
# 咱們去監控主機編輯prometheus.yml文件，修改最後幾行，而後重啓服務
vim /usr/local/prometheus/prometheus.yml
scrape_configs:
  - job_name: 'prometheus'
    static_configs:
    - targets: ['localhost:9090']
  - job_name: 'node'
    static_configs:
    - targets: ['172.19.0.51:9100']

# node節點的targets處的IP填寫你要監控的node的IP.        
systemctl restart prometheus
# 咱們登陸到Prometheus主機，看下這個節點是否是up狀態

• 接下來咱們能夠經過訪問node_exporter那個節點的IP:9100 訪問到如下頁面:
  

• 咱們能夠看到當前主機的全部監控數據.可是每個指標以前都有以下形式的信息

# HELP用於解釋當前指標的含義
# TYPE則說明當前指標的數據類型

從上面的例子中node_cpu的註釋代表當前指標是cpu0上idle進程佔用CPU的總時間，CPU佔用時間是一個只增不減的度量指標，從類型中也能夠看出node_cpu的數據類型是計數器(counter),與該指標的實際含義一致，又例如node_locad1該指標反映了當前主機再一分鐘之內的負載狀況，系統的負載狀況會隨着系統的資源使用而變化，所以node_load1反映的是當前狀態，數據可能增多也可能減小，從註釋中能夠看出當前指標類型爲儀表盤(gauge),與指標反映的實際含義一致.

# 除了這些之外，在當前頁面中根據物理主機系統的不一樣，你還可能看到以下監控指標：
* node_boot_time：系統啓動時間
* node_cpu：系統CPU使用量
* node_disk_*：磁盤IO
* node_filesystem_*：文件系統用量
* node_load1：系統負載
* node_memeory_*：內存使用量
* node_network_*：網絡帶寬
* node_time：當前系統時間
* go_*：node exporter中go相關指標
* process_*：node exporter自身進程相關運行指標

• 好比咱們使用PromQL表達式查詢特定監控指標的監控數據，以下所示，以下所示，查詢主機負載變化狀況，可使用關鍵字node_load1能夠查詢出Prometheus採集到的主機負載的樣本數據，這些樣本數據按照時間前後順序展現，造成了主機負載隨時間變化的趨勢圖表：
  

Grafana簡介

• Grafana是一個開源的度量分析與可視化套件。純 Javascript 開發的前端工具，經過訪問庫（如InfluxDB），展現自定義報表、顯示圖表等。大多使用在時序數據的監控方面，如同Kibana相似。Grafana的UI更加靈活，有豐富的插件，功能強大。
• Grafana支持許多不一樣的數據源。每一個數據源都有一個特定的查詢編輯器,該編輯器定製的特性和功能是公開的特定數據來源。
• 一個相似Kibana的東西，也是對後端的數據進行實時展現，那麼Grafana和Kibana有什麼區別？在我看來區別不大，不過在你們的平常使用中Kibana是跟着Logstash、ElasticSearch等組件一塊兒使用作日誌展現、索引、分析的，形成了一種假象就是Kibana就只有這種用法了，Kibana也能夠接入其餘數據源的，不過你們最長用的仍是展現日誌，Grafana是什麼呢？該項目你可能沒聽過，也比較年輕，他通常是和一些時間序列數據庫進行配合來展現數據的，例如：Graphite、OpenTSDB、InfluxDB等。下面看看官方是怎麼解釋Grafana的：
• grafana是用於可視化大型測量數據的開源程序，他提供了強大和優雅的方式去建立、共享、瀏覽數據。dashboard中顯示了你不一樣metric數據源中的數據。
• grafana最經常使用於因特網基礎設施和應用分析，但在其餘領域也有機會用到，好比：工業傳感器、家庭自動化、過程控制等等。
• grafana有熱插拔控制面板和可擴展的數據源，目前已經支持Graphite、InfluxDB、OpenTSDB、Elasticsearch。

Grafana安裝

• 此處咱們拿prometheus作例子,雖說prometheus能展現一些圖表，但對比Grafana，那只是過家家，接下來咱們在同一個服務器安裝Grafana服務，用來展現prometheus收集到的數據

下載並解壓安裝包

wget https://dl.grafana.com/oss/release/grafana-6.4.2.linux-amd64.tar.gz
tar xvf grafana-6.4.2.linux-amd64.tar.gz -C /usr/local/
ln -s /usr/local/grafana-6.4.2/ /usr/local/grafana

建立grafana用戶及數據存放目錄

useradd -s /sbin/nologin -M grafana
mkdir /data/grafana
mkdir /data/grafana/plugins
mkdir /data/grafana/provisioning
mkdir /data/grafana/data
mkdir /data/grafana/log
chown -R grafana:grafana /usr/local/grafana/  
chown -R grafana:grafana  /data/grafana/

修改配置文件

vim /usr/local/grafana/conf/defaults.ini
data = /data/grafana/data
logs = /data/grafana/log
plugins = /data/grafana/plugins
provisioning = /data/grafana/conf/provisioning

把grafana-server添加到systemd中

vim /usr/lib/systemd/system/grafana-server.service
[Unit]
Description=Grafana
After=network.target
[Service]
User=grafana
Group=grafana
Type=notify
ExecStart=/usr/local/grafana/bin/grafana-server -homepath /usr/local/grafana
Restart=on-failure
[Install]
WantedBy=multi-user.target
# systemctl start grafana-server && systemctl enable graana-server

啓動服務，並用web訪問http://IP:3000，默認3000端口，admin/admin

添加數據源

* grafana雖然已經安裝好了，可是這個時候尚未數據，沒辦法做圖。
* 下面咱們把grafana和prometheus關聯起來，也就是在grafana中添加添加數據源。
* 在配置頁面點擊添加數據源，而後選擇prometheus，輸入prometheus服務的參數便可。

添加自帶的示例圖表

• 按照上面的指導添加數據源以後，咱們就能夠針對這些數據來繪製圖表了。grafana最人性化的一點就是擁有大量的圖表模板，咱們只須要導入模板便可，從而省去了大量的製做圖表的時間。
• 目前咱們的prometheus尚未什麼監控數據，只有prometheus自己的數據，咱們看下這些prometheus自己數據圖表是怎樣的。
• 在添加數據源的位置上，右邊的選項有個Dashboards的菜單選項，咱們點擊進去，而後導入prometheus2.0.
  
• 接下來咱們就能看到Grafana強大的圖形能力了
  

接下來咱們到grafana中添加對應的模板，能夠將以前那個模板刪掉，咱們去尋找適應的模板

• 導入 dashboard
• 從 grafana 官網下載相關 dashboaed 到本地，如: https://grafana.com/
• Grafana 首頁--> 頁面頂部-->Dashboards--> 頁面左邊 Filter by-選擇儀表盤 prometheus

若是有須要，咱們能夠安裝餅形插件

# 使用新的grafana-cli工具從命令行安裝piechart-panel：
grafana-cli plugins install grafana-piechart-panel 
該插件將安裝到您的grafana插件目錄中; 若是安裝了grafana軟件包，則默認在/var/lib/grafana/plugins
cd /var/lib/grafana/plugins/ 
可是由於咱們以前自定義了目錄，因此要將插件放到配置文件中定義的插件目錄位置
mv /var/lib/grafana/plugins/* /data/grafana/plugins/
#重啓grafana 
systemctl restart grafana-server 
這樣dashboard中的餅圖就能夠正常展現出來了，可能須要一點時間緩衝