數據可視化（七）Graphite 體系結構詳解頂原薦

Josh Dreyfuss: Graphite vs. Grafana: Build the Best Monitoring Architecture for Your Application

Graphite 是處理可視化和指標數據的優秀開源工具。它有強大的查詢 API 和相當豐富的插件功能設置。事實上，Graphite 指標協議（metrics protocol）是許多指標收集工具的事實標準格式。然而，Graphite 並不總是一個可以簡單部署和使用的工具。由於設計方面的原因，加上它使用過程中涉及大量的小 I/O 操作，在規模化應用中會遇到一些問題，而且部署起來可能有點麻煩。

Graphite 部署痛苦的部分原因是，它是由三個不同的元素組成（當然，如果包括指標採集就是四個），這些取決於你的環境，只有其中一個或多個默認元素可能不能滿足你的需要。

雖然 Graphite 包含三個組件可能會導致一些實施的問題，但也有積極的成果。每一個模塊塊都是一個獨立的單元，這樣你就可以按照實際的需要混合和匹配使用三個組件中的哪一個。同時意味着您可以爲自己構建一個完全定製化的 Graphite 部署方案。

讓我們逐一來看看你需要做些什麼，對於 Graphite 的每一個組成部分來說，都可以是一個 Graphite 的方案或者是非 Graphite 的替代品。

1. 指標採集器 - Dropwizard Metrics, StatsD

Graphite 部署方案中的的第一個步驟根本不是 Graphite 的組成部分。這是因爲 Graphite 自身並不支持採集任何指標；Graphite 需要有人將指標數據發送給它。這通常不是一個特別大的限制，因爲大多數指標採集器都支持以 Graphite 格式提供指標數據，但仍然有一些東西需要注意。我們可選的不同指標採集器可以列一個龐大的列表，但是沒有一個工具是包含在基礎 Graphite 中的。

選擇你的指標採集器 – Graphite 文檔中提供了一個工具列表，包括流行的選擇像 CollectD 和 Diamond ，但它很少更新，所以你還可以考慮以下兩個方案：

Dropwizard Metrics – [Metrics](Metrics is a Java library which gives you unparalleled insight into what your code does in production.) 是一個 Java 庫，通過一系列指標爲你提供生產環境的可視化。它有一個 Graphite Reporter，可以將所有的指標數據發送到 Graphite 實例。對於需要在 Java 生態中使用 Graphite 的場景來說，它是一個不錯的選擇。

StatsD – StatsD 是一個基於 Node.js 運行的網絡守護進程，來自 Etsy (網絡電商平臺)。它可以監聽一系列統計、指標數據，並將它們聚集到像 Graphite 這樣的工具中。StatsD 也可以和很多其他的可視化、指標採集工具一起工作。

小結： Graphite 不和特定的指標採集器捆綁。然而， Graphite 指標協議是非常常見的，因此不難找到一個或多個與您的應用程序一起工作的協議。既然有這麼多的指標採集器和 Graphite 配合良好，你不需要只選擇一個，你可以選擇從多個數據源發送指標。

2. 監聽器 - Carbon, graphite-ng, and Riemann

Graphite 的另一部分是用於監聽發送的指標數據並將其寫入磁盤的組件 —— Carbon （原意：碳）。Carbon 是由守護進程組成的，在工作方式方面有一些內置的靈活性。

在基本的小規模部署中， Carbon 守護程序會監聽指標數據並將它們報告給 Whisper 存儲數據庫。然而，隨着規模的增長可以添加一個聚合元素（A ggregation），它在一段時間內緩衝指標數據，然後將它們發送給一個大塊中的 Whisper 。你也可以使用 Carbon 傳遞指標副本到多個 Carbon 後臺。當你達到更高的規模、需要多個 Carbon 後臺程序來處理傳入的指標數據時，這一點特別有用。

缺點和潛在的問題 —— 人們通常遇到的問題通常跟規模相關。就規模應用而言，Carbon 有以下幾個缺點：

一個單獨的 Carbon 守護程序處理能力有限，因爲它是用 Python 語言設計的。本機代碼不支持一次多個線程同時運行（ Multiple threads），所以可能出現 Carbon 守護程序剛剛啓動時丟棄指標數據的情況。
Carbon 有一個它一次能處理負載數量的閾值，但這個閾值並沒有傳達給你。
Carbon 並沒有持續打開 Whisper 的文件句柄，所以存儲每個指標都需要多步的完整讀/寫序列。

基於標準的 Graphite 部署實例中，這些情況的解決方法是將工作劃分爲中繼器（ Carbon relays）和緩存（Carbon caches ）。儘管如此，您仍然需要注意負載，因爲超過了 Carbon 的負荷會導致數據丟失。如果這個後果對你來說無法接受，可以看看 Carbon 的替代解決方案。

Carbon 替代方案 Carbon 的另一種替代方法是 graphite-ng，本質上是基於 Go 語言重寫了一遍 Carbon ，以解決上面提到的幾個問題。迄今爲止，該項目的重點是改進 Carbon 的中繼和聚合功能。如果你喜歡 Carbon 的功能，但是又想要繞過一些性能方面的限制，這是一個不錯的選擇。

另一個替代方案是 Reimann。基於 Clojure 語言實現（屬於 LISP 編程語言家族），Reimann 是用來聚集和處理“事件流（event streams）”。事件和流都是相當簡單的概念，Riemann 能代替 Carbon 把它們發送到 Graphite 實例。它在這個過程增加了一些提供了額外的好處，例如告警功能。如果你想設計一個遠離 Carbon 的架構，這是一個很好的選擇，還能加入一些涉及告警方面的能力。

爭議觀點

Cyanite does not only "work with carbon". Just like influxdb, it implements the graphite line receiver protocol and thus replaces carbon-cache.

Riemann can't send data to your graphite deployment "in place of carbon". It can act as a much more powerful carbon-aggregator, but it doesn't replace carbon-cache.

小結： Carbon 負責監聽指標數據並將它們寫入到您的存儲數據庫，但經常在規模化應用上遇到性能問題。有一些現成的替代方案可以解決這個問題。

3. 存儲數據庫 – Whisper, InfluxDB, Cyanite

您需要選擇的下一個組件是存儲數據庫。在 Graphite 體系結構中稱之爲 Whisper。Whisper 是一種固定大小的數據庫，用於存儲時間序列數據，在保存和取樣方面提供了相當的精確度。在標準的 Graphite 部署中，Carbon 將指標值寫入 Whisper 存儲，用於在 Graphite-web 組件中實現可視化。

缺點和潛在問題：Whisper 基於 RRD（Round- Robin Database），但寫入操作的時候有一些關鍵性的差異，例如回填項目歷史數據和處理不規則數據的能力。這裏有一些指標和可視化工具的有用特性，但它們的實現都是基於某種折衷。

因爲 Whisper 是用Python編寫的，所以相對來說性能較慢；
按照 Whisper 的設計，它會遇到一些存儲空間的問題，因爲每個指標都需要一個文件，並且都是單個實例。這是一種有意的權衡，以實現前面提到的一些好處，但不可否認，Whisper 對磁盤空間的利用效率較低。
由於 Carbon 和 Whisper 在設計方面的原因，它們最終都涉及到大量的 IO 請求。當你超越小型部署時，磁盤 IO 的伸縮能力會成爲擺在面前的一個問題。

Whisper 替代方案 你可以通過部署固態硬盤（SSD）或者其它一些設計解決 Whisper 的性能問題，但也只是點到爲止。如果數據庫部分正是你所需要的，那麼有幾個選擇可以考慮。

目前主要的一個選擇是 influxdata（InfluxDB）。influxdata 是一個基於 LevelDB、用 Go 語言編寫的時間序列數據庫。influxdata 能夠解決一些磁盤 IO 寫優化問題，同時不要求 one metric = one file 。

influxdata 支持 Carbon 使用的協議，使它能夠悄悄置換 Whisper，實現類似 SQL的查詢語言。甚至已經有一些項目設計用來使 influxdata 的置換更簡便易行，例如 graphite-influxdb 項目，使得可以和 Graphite 的 API 無縫銜接。influxdata 屬於非常有前途的新興項目，可以在廣泛的範圍內與其他工具一起工作。

另一個選擇是使用基於 Cassandra 的存儲數據庫。得益於 graphite-cyanite 項目的工作，基於 Cyanite 數據庫可以很容易實現這一目的。 Cyanite 的開發規劃目標就是在 Graphite 體系結構中替換 Whisper ，這意味着它可以和 Carbon 、 Graphite-web 一起工作（需要少量的一些依賴）。使用 Cyanite 有助於解決 Whisper 在大規模部署場景中存在的性能和高可用問題。

小結： Graphite 體系結構中，數據存儲組件是 Whisper 。在大規模應用中，除非你在硬件方面大量投入、把它分解成複雜的手動集羣模式，否則將悄悄地會遇到一些性能和可用性問題。如果你需要關注這些問題，可以使用數據庫的替代選項來提高性能和可用性。

4. 可視化組件 – Graphite-Web 和 Grafana

一旦你收集並存儲了指標數據，就下來的步驟就是可視化它們。Graphite-web 的角色就是提供可視化。 Graphite-web 是一種基於 Django 的 Web 應用程序，提供指標數據可視化和交互能力。它在數據的處理方面提供了相當多的能力，但可視化組件並不十分美觀（也就是說 “土”、“醜”）。Graphite-web 作爲前端組件，我們將着重討論用戶體驗的相關內容。

Graphite-web 替代方案 歸功於卓越的 Graphite API ，目前有一系列第三方儀表盤工具可以支持 Graphite 。因爲有如此衆多的可視化選項，它們的優劣其實主要取決於個人品味，再次不作過多擴展，但我確實想特別指出其中的一個。也許最具潛力的 Graphite 可視化替代方案，或至少是人們談論最多的是 Grafana 。

Grafana 是一個開源的儀表盤工具，可以兼容 Graphite 和 InfluxDB 。Grafana 曾經只是一個基於 Elasticsearch 存儲的前端儀表盤工具，從 V2.0 版本開始，它擁有了一個支持用戶自定義的後端存儲組件。Grafana 在設計之初即考慮到支持 Graphite 創建更加優美的可視化組件，因此它非常適合替換默認的 Graphite-web 。Grafana 功能相當豐富，性能穩定。Grafana 擁有一個後端組件，如果你也可以找到純粹的前端工具，Graphite 文檔中提供了工具列表。

小結：如果你覺得 Graphite 提供的默認可視化效果過於基礎和乏味，有大量的可視化替代方案可以選擇。其中一些是純粹客戶端，有的包含一個存儲你建立的儀表盤後端組件。不管你要什麼，你都能在這裏找到東西。

5. 代碼級指標 – Trends

OverOps 發佈了一個新的功能，可以讓你把代碼級指標從 JVM 應用程序中的錯誤、與變量狀態在一起發送到 Graphite 。詳細：https://www.overops.com

{
 backends: [ "./backends/graphite" ]   // identify this backend as Graphite
 graphitePort: 2003,                   // port of Graphite server 
 graphiteHost: "graphite.example.com", // hostname or IP of Graphite server
 deleteCounters: true,
 graphite: {  // Graphite tweaks for Takipi
   prefixCounter: "",
   prefixGauge: "",
   globalPrefix: "",
   legacyNamespace: false
 }
}

總結

所有針對 Graphite 的投訴都集中於（它的工作性能不夠穩定，儀表盤醜陋！規模化部署是硬傷！），但不妨礙它成爲一個很流行的工具。如果你想要一個開源的指標和可視化工具，爲許多企業級工具提供支持，那麼 Graphite 值得一試。其中最重要的一點是，你可以自定義數據內容。Graphite 並不是由完全特定的組件一起工作，其中的樂趣何在？經過一些嘗試和錯誤，您可以在您自己的環境中構建一個完全定製化的、非常有用 Graphite （或類似 Graphite 的）部署方案。

擴展閱讀：數據可視化

更多精彩內容掃碼關注公衆號：RiboseYim's Blog