StatsD！次世代系統監控的核心
在互聯網業務蒸蒸日上的今時今日，系統架構日漸復雜，隨著軟件產品和工程團隊的變革，許多開源的監控工具應運而生，其中有一些相當出名，比如 Zabbix、Nagios 還有 StatsD。也有一些問題被大家不斷討論，例如，監控領域的開源工具 Zabbix 和 Nagios 哪個更好？StatsD 是否有可能取代 Zabbix 或 Nagios 成為系統監控的新標準？
StatsD 的誕生
作 為一個大型的手工藝成品在線市場平臺，Etsy 曾被紐約時報拿來和 eBay，Amazon 等比較。早在2009年，Etsy 正在奮力向外擴展。但是網站的可靠性卻表現的差強人意。其原因主要與架構有關，Esty 的架構起源于 DevOps 之前的文化，即開發人員，DBAs 和系統管理人員都專注于自己的筒倉，且開發人員無法接觸產品。在當時，這就是開發和運營 Web 網站最常見的方式。
Kellan Elliott-McCrea 在 Etsy 擔任工程部副總裁和首席技術官的五年內，軟件產品和工程團隊都經歷了翻天覆地的變革。工程團隊變化最明顯的方面是———展示。這種變革帶來了許多開源工 具，其中有一些相當出名，比如 StatsD，一個從日志文件中生成指標，抓取數據的聚合器。在過去幾年中，StatsD 幾乎可以說是最流行且實用的 DevOps 工具。
StatsD 簡介
簡單來講，StatsD 就是一個簡單的網絡守護進程，基于 Node.js 平臺，通過 UDP 或者 TCP 方式偵聽各種統計信息，包括計數器和定時器，并發送聚合信息到后端服務，如 Graphite。
StatsD 最初是由 Etsy 的 Erik Kastner 寫的提供 Graphite/Carbon 指標的前端代理，初衷是為了匯總和分析應用指標。它基于兩大功能：計數和計時。最開始使用 Node，后來也實現了其他語言。通過 Statsd ，能通過特定語言的客戶端檢測應用程序的指標。基于個性化需求，可以通過 Statsd 收集任何想要的數據。Statsd 通過發送 UDP 數據包來調用每個 Statsd 服務器，下面我們來了解一下為什么選擇 UDP 而不是 TCP。
為什么使用 UDP?
前 面也說了, StatsD 是通過 UDP 傳輸數據的，那么有人會問為什么選 UDP 而不選 TCP 呢? 首先，它速度很快。任何人都不想為了追蹤應用的表現而減慢其速度。此外，UDP 包遵循「fire-and-forget」機制。所以要么 StatsD 接收了這個包，要么沒有。應用不會在意 StatsD 是運行、宕機還是著火了，它單純地相信一切運行正常。也就是說我們不用在意后臺 StatsD 服務器是不是崩了，就算崩了也不會影響前臺應用。（當然，我們可以通過圖表追蹤 UDP 包接收失敗的情況。）
StatsD 的一些概念
為了更加了解 StatsD，我們先來了解幾個 StatsD 概念：buckets、values、flush interval。
Buckets
當 一個 Whisper 文件被創建，它會有一個不會改變的固定大小。在這個文件中可能有多個 buckets 對應于不同分辨率的數據點，每個 bucket 也有一個保留屬性指明數據點應該在 bucket 中應該被保留的時間長度，Whisper 執行一些簡單的數學計算來計算出多少數據點會被實際保存在每個 bucket 中。
Values
每個 stat 都有一個 value，該值的解釋方式依賴于 modifier。通常，values 應該是整數。
Flush Interval
在 flush interval (沖洗間隔，通常為10秒) 超時之后，stats 會聚集起來，傳送到上游的后端服務。
追蹤所有事件是提高效率的關鍵。有了 StatsD，工程師們可以輕松追蹤他們需要關注的事務，而無需費時地修改配置等。
StatsD 的延伸
收集和可視化數據是對服務器和應用做出明智決定的重要方式，StatsD 具有以下優點：
- 簡單——非常容易獲取的應用程序，StatsD 協議是基于文本的，可以直接寫入和讀取。
- 低耦合性——基于后臺程序運行的應用程序，采取 UDP 這種「fire-and-forget」的協議，收集指標和應用程序本身之間沒有依賴。
- 占用空間小——StatsD 客戶端非常輕便的，不帶任何狀態，不需要的線程。
- 普遍及支持多種語言——有基于 Ruby，Python, Java, erlang, Node, Scala, Go, haskell 等幾乎所有語言的客戶端。 </ul> Etsy 使用 Statsd 監控系統
Etsy 曾寫 blog 介紹自己怎樣使用 Statsd 以及為什么使用它：Measure Anything, Measure Everything，文章介紹 Etsy 以圖表的方式追蹤自己服務器，應用，網絡三者的變化，而三者中尤以應用的數據最為復雜，為了做出的圖表讓與三者相關的人都能夠讀懂，決定統一收集數據，根據時間軸畫出圖表，使得所有的指標都能夠被可視化和衡量。
Statsd 采用了計數器，用于收集數字。計時器的一大好處在于，你可以得到平均值、總值、計數值和上下限值。Etsy 在使用時發現追蹤的事件非常頻繁，而 Statsd 沒有任何緩沖的數據，這樣在兩者間調用時保持簡單，如果有大數據量的操作時，可以在數據發送到 Statsd 時加入樣本數據，即只發送一定比例的數據。Statsd 后臺守護進程會監聽所有應用庫的 UDP 流量，通過時間流收集數據并在后臺于所需時間間隔內更新數據。例如，聚合功能調用計時器可以每 10 秒收集一次數據，并分析出這些數據的最大值，最小值，平均值，中間值，90 值和 95 值。
Etsy 也將 StatsD 開源，介紹了簡單的使用方式 基于基本線路協議預期發送的指標格式：
<metricname> : <value> | <type>
如果你在本地運行 StatsD 和默認的 UDP 服務器，在命令行最簡單的發送指標方式：
echo "foo:1|c" | nc -u -w0 127.0.0.1 8125
collectd
collectd 其實也是一個守護(daemon)進程，用來收集系統性能數據和提供各種存儲方式來存儲不同值的機制。具體可以參考Collectd 的官方網站。
collectd 不僅僅是收集性能數據，還根據這些數據周期性統計系統的相關信息，以這些統計信息為依準，檢查當前服務器性能和預測系統未來，但它本身不能生成圖形——雖 然它能寫 RRD 文件，但是不能從這些文件生成圖形——所以一般需要結合一個數據繪圖工具 Graphite 。像 VPSee 就是選用 collectd 來收集機器的各個性能參數。
相對于其他收集系統性能指標的項目，collectd 有一定的優點，比如嵌入式系統，C 語言開發（高效）、無需系統 cron 支持（獨立）、簡單易用等，此外他還包含超過70多種插件以及文檔支持。
StatsD 和 Graphite
我 們篤信圖表對數據呈現的意義，Ian Malpass 在 Code as Craft 發表的文章中這么描述：只要是變化的事件，我們就去追蹤。我們通常關注網絡、設備和應用的數據，而其中應用性能數據往往是這三者中最難測量、但又最重要 的，它們與你的業務息息相關。那么是否可以將工程師可能測量或計時的指標以最簡便的方式做成圖表呢？
大家都知道，StatsD 經常與 Graphite 一起出現在工程師的視野中，眾所周知，StatsD 負責收集并聚合測量值，之后，它會將數據傳給 Graphite，后者以時間序列為依據存儲數據，并繪制圖表。意即 StatsD 負責數據的初步處理，Graphite 負責數據展現,相得益彰。
我 們中意 Graphite 的原因很多：它使用簡便，畫圖和數據操縱的能力強大。我們可以結合來自 StatsD 和其他指標收集系統的數據。最重要的是，對于 StatsD 來說，只要將測量指標的數據推送給 Graphite, 它就會創建新的測量指標。這意味著，工程師們在追蹤新的指標時無需擔心管理成本，他只要告訴 StatsD 「我想要追蹤 grue.dinners」該指標就會自動出現在 Graphite 中。此外，向 Graphite 推送數據的頻率為10秒，因此，StatsD 的測量指標展現近乎實時。
該圖片簡單地描繪了 http 請求在一段時間內的 elapsed_time 值。
因此，有了 StatsD，抓取速率等測量值變得極為簡便，再加上 Graphite 對數據進行處理，查看、分析這些數據也就變得非常簡單。
StatsD 生態環境
在國外基于 StatsD 產生了一系列的工具，或者在成熟的項目基礎之上，開始兼容 StatsD。如果按照方向可以劃分為如圖的幾個方向。
Integrations
由于 StatsD 本身不負責定義指標的涵義，所以從數據庫或者操作系統中采集的工作，需要進行腳本的開發。其中在這方面做出突出貢獻的就是 Datadog。dd-agent 這個項目在 GitHub 多達 150 個貢獻者，兼容多達 60 多種操作系統、中間件、數據庫。
除此之外，Librato 和 App First 也加入到 StatsD 的陣營中。而基礎設施管理的解決方案：Puppet 和 Chef 也開始兼容將 StatsD 批量安裝到基礎設施中。
Visualization 和 Data Hosting
Graphite 作為一個可視化的控件，不僅包含可視化還自帶存儲的部分。但是單論可視化，Grafana 是做得最好的一家，其展現形式豐富，可配置項目巨細靡遺。Signal FX 后來居上，也參與到競爭中。
在數據可視化的基礎之上，也有服務開始從事可視化數據的托管服務。例如：Host Graphite。
時間序列數據庫和事件處理引擎
其實 StatsD 和時間序列數據庫的出現，是相輔相成的。在 OpenTSDB 和 InfluxDB 基礎之上，StatsD 的應用才日漸豐滿。
而事件處理引擎，如 Riemann 開始與時間序列數據庫，或者基于 StastD 的一體化解決方案對接，從而彌補除開展現之外的報警這個方向上的不足。
一體化解決方案
那 么，有沒有一體化的解決方案呢？國外除開這些細分的方向之外，也有廠商提供一體化的解決方案，通過輕量級的 StatsD 來達到更高的計算能力，來處理日益復雜的基礎設施架構。如：Datadog、Librato 等等。而國內的 Cloud Insight，也是基于同樣的思路，提供系統監控的服務。今年年初 Datadog 獲得 C 輪融資，融資金額為 3100 萬美元。而其客戶名單從 非死book 到 Airbnb，成績斐然。孕育 Cloud Insight 的公司 OneAPM 同樣在不久前也獲得 C 輪1.65億的融資，被業界普遍看好。
結語
誠然，StatsD 作為新世代的系統監控的核心，目前還處于技術累計過程。我們相信，未來會有越來越多的開源項目加入到它的懷抱中，也有越來越多的公司，在此基礎之上加入了 研發的資源，或者在與之相關的其他領域中投入成本。基于該技術的 Datadog 公司，憑借其在該技術的投入和實打實的計算能力，獲得了不錯的成績。而國內的 Cloud Insight 這個產品線，基于相同的思路也加入到 StatsD 陣營中。最終 StatsD 是否有可能取代 Zabbix 或 Nagios 成為系統監控的新標準，讓我們拭目以待吧！
關于作者：張璐，OneAPM軟件工程師。
來自：http://www.csdn.net/article/2015-12-10/2826438