在互聯網業務蒸蒸日上的今時今日，系統架構日漸復雜，隨著軟件產品和工程團隊的變革，許多開源的監控工具應運而生，其中有一些相當出名，比如 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 等幾乎所有語言的客戶端。
　　Etsy 使用 Statsd 監控系統
　　Etsy 曾寫 blog 介紹自己怎樣使用 Statsd 以及為什么使用它：Measure Anything， Measure Everything，文章介紹 Etsy 以圖表的方式追蹤自己服務器，應用，網絡三者的變化，而三者中尤以應用的數據最為復雜，為了做出的圖表讓與三者相關的人都能夠讀懂，決定統一收集數據，根據時間軸畫出圖表，使得所有的指標都能夠被可視化和衡量。
　　Statsd 采用了計數器，用于收集數字。計時器的一大好處在于，你可以得到平均值、總值、計數值和上下限值。Etsy 在使用時發現追蹤的事件非常頻繁，而 Statsd 沒有任何緩沖的數據，這樣在兩者間調用時保持簡單，如果有大數據量的操作時，可以在數據發送到 Statsd 時加入樣本數據，即只發送一定比例的數據。Statsd 后臺守護進程會監聽所有應用庫的 UDP 流量，通過時間流收集數據并在后臺于所需時間間隔內更新數據。例如，聚合功能調用計時器可以每 10 秒收集一次數據，并分析出這些數據的最大值，最小值，平均值，中間值，90 值和 95 值。
　　
　　Etsy 也將 StatsD 開源，介紹了簡單的使用方式 基于基本線路協議預期發送的指標格式：
　?。?|
　　如果你在本地運行 StatsD 和默認的 UDP 服務器，在命令行最簡單的發送指標方式：
　　echo “foo:1|c” | nc -u -w0 127.0.0.1 8125
　　collectd
　　collectd 其實也是一個守護（daemon）進程，用來收集系統性能數據和提供各種存儲方式來存儲不同值的機制。具體可以參考Collectd 的官方網站。

普通下載普通下載

相關電子資料下載