Prometheus學習系列（三）之監控對比

時間 2019-12-08

標籤 prometheus 學習系列監控對比简体版

原文原文鏈接

1、Prometheus vs. Graphite

1.1 範圍

Graphite專一於查詢語言和圖表特徵的時間序列數據庫。其餘都須要依賴外部組件實現。html

Prometheus是一個基於時間序列數據的完整監控系統和趨勢系統，包括內置和主動抓取、存儲、查詢、圖表展現和報警功能。它懂得監控系統和趨勢系統應該是什麼樣的（哪些目標機應該存在，哪些時間序列模型存在問題等等），並積極地試着找出故障。ios

1.2 數據模型

Graphite和Prometheus同樣，存儲時間序列數值樣本。可是Prometheus的元數據模型更加豐富：Graphite的度量指標名稱是由"."分隔符，隱式地編碼多維度。而Prometheus度量指標是能夠自定義名稱的，並以key-value鍵值對的標籤形式，成爲度量指標的標籤屬性列表。並在此基礎上，使用Prometheus查詢語言能夠輕鬆地進行過濾，分組和匹配操做。git

進一步地，當Graphite與StatsD結合使用時，Graphite就只是對一個聚合數據的存儲系統了，而不是把目標實例做爲一個維度，並深刻分析目標實例出現的各類問題。github

例如：咱們用Graphite/StatsD統計HTTP請求api-server服務的數量，前置條件：返回碼是500，請求方法是POST，訪問URL爲/tracks , key以下所示：算法

stats.api-server.tracks.post.500 -> 93
複製代碼

可是在Prometheus中一樣的數據存儲可能像下面同樣(假設有三個api-server)：數據庫

api_server_http_requests_total{method="POST",handler="/tracks",status="500",instance="<sample1>"} -> 34
api_server_http_requests_total{method="POST",handler="/tracks",status="500",instance="<sample2>"} -> 28
api_server_http_requests_total{method="POST",handler="/tracks",status="500",instance="<sample3>"} -> 31
複製代碼

1.3 存儲

Graphite存儲以Whisper方式把時間序列數據存儲到本地磁盤，這種數據存儲格式是RRD格式數據庫，它指望樣本可以按期到達。任什麼時候間序列在一個單獨的文件中存儲，一段時間後新採集的樣本會覆蓋老數據。api

Prometheus也爲每個時間序列建立了一個本地文件，可是它容許時間序列以任意時間到達。新採集的樣本被簡單地追加到文件尾部，老數據能夠任意長的時間保留。Prometheus對於短生命週期、且常常變化的時間序列集也能夠表現得很好。bash

1.4 總結

Prometheus提供了一個豐富的數據模型和查詢語言，並且更加容易地運行和集成到你的環境中。若是你想要一個能夠長期保留歷史數據的集羣解決方案，Graphite多是一個更好的選擇。服務器

2、Prometheus vs. InfluxDB

InfluxDB是一個開源的時間序列數據庫，它的商業版本具備可擴展和集羣化的特性。在Prometheus剛剛開始開發時，InfluxDB項目已經發布了近一年時間。可是這兩款產品仍是有很大的不一樣之處，這兩個系統也有一些略有不一樣的應用小場景。架構

2.1 範圍

公平起見，咱們必須把InfluxDB和Kapacitor結合起來，與Prometheus和Prometheus的報警管理工具比較。

Graphite與Prometheus的範圍差別，一樣適用於InfluxDB自己。此外InfluxDB提供了連續查詢，和Prometheus的記錄規則同樣。

Kapacitor的做用範圍至關於，Prometheus的記錄規則、告警規則和警告通知功能的結合。Prometheus提供了一個更加豐富地用於圖表化和警告的查詢語言，Prometheus告警器還提供了分組、重複數據刪除和靜默功能(silencing functionality)。

2.2 數據模型/存儲

和Prometheus同樣，InfluxDB數據模型採用的標籤也是鍵值對形式，被稱爲tags。並且InfluxDB有第二級標籤，被稱爲fields，它被更多地限制使用。InfluxDB支持高達納秒級的時間戳，以及float6四、int6四、bool和string的數據類型。相反地，Prometheus僅僅支持float64的數據類型，strings和毫秒只能小範圍地支持。

InfluxDB使用變種的日誌結構合併樹結構來存儲預寫日誌，並按時間分片。這比Prometheus的文件追加更適合事件記錄 Logs and Metrics and Graphs, Oh My描述了事件日誌和度量指標記錄的不一樣

2.3 框架

Prometheus服務器彼此獨立運行，其核心功能僅依賴於本地存儲：抓取、規則處理和警報。influxDB的開源版本相似。

InfluxDB的商業版本具備存儲和查詢的分佈式版本,存儲和查詢由集羣中的節點同時處理。

這意味着商業版本的InfluxDB更加容易的水平擴展，同時也表示你必須從一開始就要管理分佈式存儲系統的複雜性。而Prometheus運行很是簡單，並且在某些時候，你須要在可擴展性邊界（如產品，服務，數據中心或者相似方面）明確分片服務器。單Prometheus服務也能夠爲您提供更好的可靠性和故障隔離。

Kapacitor對規則、警告和通知當前尚未內置/冗餘選項。相反地，經過運行Prometheus的冗餘副本和使用警告管理器的高可用模式提供了冗餘選項。Kapacitor經過用戶手動水平切分可以被縮放，這點相似於Prometheus> 自己

2.4 總結

在兩個系統之間有許多類似點。都使用標籤（tags/labels）有效地支持多維度量指標。都使用使用相同的壓縮算法。均可擴展集成。都容許使用第三方進行監控系統的擴展，如：統計分析工具、自動化操做

InfluxDB更好之處：

使用事件日誌
商業版本提供的集羣方案，對於長期的時間序列存儲是很是不錯的
複製的數據最終一致性

Prometheus更好之處：

主要作度量指標監控
更強大的查詢語言，警告和通知功能
圖表和警告的高可靠性和穩定性

InfluxDB是有一家商業公司按照開放核心模式運營，提供高級功能，如：集羣是閉源的，託管和支持。Prometheus是一個徹底開放和獨立的項目，有許多公司和我的維護，其中也提供一些商業服務和支持。

3、Prometheus vs. OpenTSDB

OpenTSDB是一個基於hadoop和Hbase的分佈式時間序列數據庫

3.1 範圍

和Graphite vs. Prometheus的範圍同樣

3.2 數據模型

OpenTSDB的數據模型幾乎和Prometheus同樣：時間序列由任意的tags鍵值對集合表示。全部的度量指標存放在一塊兒，並限制度量指標的總數量大小。Prometheus和OpenTSDB有一些細微的差異，例如：Prometheus容許任意的標籤字符，而OpenTSDB的tags命名有必定的限制.OpenTSDB缺少靈活的查詢語言支持，經過它提供的API只能簡單地進行聚合和數學計算。