StatsD！次世代系統(tǒng)監(jiān)控的核心

發(fā)表于2015-12-11 11:15| 1360次閱讀| 來源CSDN| 3 條評論| 作者張璐

開源運維StatsD width="22" height="16" src="http://hits.sinajs.cn/A1/weiboshare.html?url=http%3A%2F%2Fwww.csdn.net%2Farticle%2F2015-12-10%2F2826438&type=3&count=&appkey=&title=%E7%AE%80%E5%8D%95%E6%9D%A5%E8%AE%B2%EF%BC%8CStatsD%20%E5%B0%B1%E6%98%AF%E4%B8%80%E4%B8%AA%E7%AE%80%E5%8D%95%E7%9A%84%E7%BD%91%E7%BB%9C%E5%AE%88%E6%8A%A4%E8%BF%9B%E7%A8%8B%EF%BC%8C%E5%9F%BA%E4%BA%8E%20Node.js%20%E5%B9%B3%E5%8F%B0%EF%BC%8C%E9%80%9A%E8%BF%87%20UDP%20%E6%88%96%E8%80%85%20TCP%20%E6%96%B9%E5%BC%8F%E4%BE%A6%E5%90%AC%E5%90%84%E7%A7%8D%E7%BB%9F%E8%AE%A1%E4%BF%A1%E6%81%AF%EF%BC%8C%E5%8C%85%E6%8B%AC%E8%AE%A1%E6%95%B0%E5%99%A8%E5%92%8C%E5%AE%9A%E6%97%B6%E5%99%A8%EF%BC%8C%E5%B9%B6%E5%8F%91%E9%80%81%E8%81%9A%E5%90%88%E4%BF%A1%E6%81%AF%E5%88%B0%E5%90%8E%E7%AB%AF%E6%9C%8D%E5%8A%A1%EF%BC%8C%E5%A6%82%20Graphite%E3%80%82&pic=&ralateUid=&language=zh_cn&rnd=1449997155316" frameborder="0" scrolling="no" allowtransparency="true">摘要：簡單來講，StatsD 就是一個簡單的網(wǎng)絡(luò)守護進程，基于 Node.js 平臺，通過 UDP 或者 TCP 方式偵聽各種統(tǒng)計信息，包括計數(shù)器和定時器，并發(fā)送聚合信息到后端服務(wù)，如 Graphite。

在互聯(lián)網(wǎng)業(yè)務(wù)蒸蒸日上的今時今日，系統(tǒng)架構(gòu)日漸復(fù)雜，隨著軟件產(chǎn)品和工程團隊的變革，許多開源的監(jiān)控工具應(yīng)運而生，其中有一些相當(dāng)出名，比如 Zabbix、Nagios 還有 StatsD。也有一些問題被大家不斷討論，例如，監(jiān)控領(lǐng)域的開源工具 Zabbix 和 Nagios 哪個更好？StatsD 是否有可能取代 Zabbix 或 Nagios 成為系統(tǒng)監(jiān)控的新標(biāo)準(zhǔn)？

StatsD 的誕生

作為一個大型的手工藝成品在線市場平臺，Etsy 曾被紐約時報拿來和 eBay，Amazon 等比較。早在2009年，Etsy 正在奮力向外擴展。但是網(wǎng)站的可靠性卻表現(xiàn)的差強人意。其原因主要與架構(gòu)有關(guān)，Esty 的架構(gòu)起源于 DevOps 之前的文化，即開發(fā)人員，DBAs 和系統(tǒng)管理人員都專注于自己的筒倉，且開發(fā)人員無法接觸產(chǎn)品。在當(dāng)時，這就是開發(fā)和運營 Web 網(wǎng)站最常見的方式。

Kellan Elliott-McCrea 在 Etsy 擔(dān)任工程部副總裁和首席技術(shù)官的五年內(nèi)，軟件產(chǎn)品和工程團隊都經(jīng)歷了翻天覆地的變革。工程團隊變化最明顯的方面是———展示。這種變革帶來了許多開源工具，其中有一些相當(dāng)出名，比如 StatsD，一個從日志文件中生成指標(biāo)，抓取數(shù)據(jù)的聚合器。在過去幾年中，StatsD 幾乎可以說是最流行且實用的 DevOps 工具。

StatsD 簡介

簡單來講，StatsD 就是一個簡單的網(wǎng)絡(luò)守護進程，基于 Node.js 平臺，通過 UDP 或者 TCP 方式偵聽各種統(tǒng)計信息，包括計數(shù)器和定時器，并發(fā)送聚合信息到后端服務(wù)，如 Graphite。

StatsD 最初是由 Etsy 的 Erik Kastner 寫的提供 Graphite/Carbon 指標(biāo)的前端代理，初衷是為了匯總和分析應(yīng)用指標(biāo)。它基于兩大功能：計數(shù)和計時。最開始使用 Node，后來也實現(xiàn)了其他語言。通過 Statsd ，能通過特定語言的客戶端檢測應(yīng)用程序的指標(biāo)。基于個性化需求，可以通過 Statsd 收集任何想要的數(shù)據(jù)。Statsd 通過發(fā)送 UDP 數(shù)據(jù)包來調(diào)用每個 Statsd 服務(wù)器，下面我們來了解一下為什么選擇 UDP 而不是 TCP。

為什么使用 UDP?

前面也說了, StatsD 是通過 UDP 傳輸數(shù)據(jù)的，那么有人會問為什么選 UDP 而不選 TCP 呢? 首先，它速度很快。任何人都不想為了追蹤應(yīng)用的表現(xiàn)而減慢其速度。此外，UDP 包遵循「fire-and-forget」機制。所以要么 StatsD 接收了這個包，要么沒有。應(yīng)用不會在意 StatsD 是運行、宕機還是著火了，它單純地相信一切運行正常。也就是說我們不用在意后臺 StatsD 服務(wù)器是不是崩了，就算崩了也不會影響前臺應(yīng)用。（當(dāng)然，我們可以通過圖表追蹤 UDP 包接收失敗的情況。）

StatsD 的一些概念

為了更加了解 StatsD，我們先來了解幾個 StatsD 概念：buckets、values、flush interval。

Buckets

當(dāng)一個 Whisper 文件被創(chuàng)建，它會有一個不會改變的固定大小。在這個文件中可能有多個 buckets 對應(yīng)于不同分辨率的數(shù)據(jù)點，每個 bucket 也有一個保留屬性指明數(shù)據(jù)點應(yīng)該在 bucket 中應(yīng)該被保留的時間長度，Whisper 執(zhí)行一些簡單的數(shù)學(xué)計算來計算出多少數(shù)據(jù)點會被實際保存在每個 bucket 中。

Values

每個 stat 都有一個 value，該值的解釋方式依賴于 modifier。通常，values 應(yīng)該是整數(shù)。

Flush Interval

在 flush interval (沖洗間隔，通常為10秒) 超時之后，stats 會聚集起來，傳送到上游的后端服務(wù)。

追蹤所有事件是提高效率的關(guān)鍵。有了 StatsD，工程師們可以輕松追蹤他們需要關(guān)注的事務(wù)，而無需費時地修改配置等。

StatsD 的延伸

收集和可視化數(shù)據(jù)是對服務(wù)器和應(yīng)用做出明智決定的重要方式，StatsD 具有以下優(yōu)點：

• 簡單——非常容易獲取的應(yīng)用程序，StatsD 協(xié)議是基于文本的，可以直接寫入和讀取。
• 低耦合性——基于后臺程序運行的應(yīng)用程序，采取 UDP 這種「fire-and-forget」的協(xié)議，收集指標(biāo)和應(yīng)用程序本身之間沒有依賴。
• 占用空間小——StatsD 客戶端非常輕便的，不帶任何狀態(tài)，不需要的線程。
• 普遍及支持多種語言——有基于 Ruby，Python, Java, erlang, Node, Scala, Go, haskell 等幾乎所有語言的客戶端。

Etsy 使用 Statsd 監(jiān)控系統(tǒng)

Etsy 曾寫 blog 介紹自己怎樣使用 Statsd 以及為什么使用它：Measure Anything, Measure Everything，文章介紹 Etsy 以圖表的方式追蹤自己服務(wù)器，應(yīng)用，網(wǎng)絡(luò)三者的變化，而三者中尤以應(yīng)用的數(shù)據(jù)最為復(fù)雜，為了做出的圖表讓與三者相關(guān)的人都能夠讀懂，決定統(tǒng)一收集數(shù)據(jù)，根據(jù)時間軸畫出圖表，使得所有的指標(biāo)都能夠被可視化和衡量。

Statsd 采用了計數(shù)器，用于收集數(shù)字。計時器的一大好處在于，你可以得到平均值、總值、計數(shù)值和上下限值。Etsy 在使用時發(fā)現(xiàn)追蹤的事件非常頻繁，而 Statsd 沒有任何緩沖的數(shù)據(jù)，這樣在兩者間調(diào)用時保持簡單，如果有大數(shù)據(jù)量的操作時，可以在數(shù)據(jù)發(fā)送到 Statsd 時加入樣本數(shù)據(jù)，即只發(fā)送一定比例的數(shù)據(jù)。Statsd 后臺守護進程會監(jiān)聽所有應(yīng)用庫的 UDP 流量，通過時間流收集數(shù)據(jù)并在后臺于所需時間間隔內(nèi)更新數(shù)據(jù)。例如，聚合功能調(diào)用計時器可以每 10 秒收集一次數(shù)據(jù)，并分析出這些數(shù)據(jù)的最大值，最小值，平均值，中間值，90 值和 95 值。

Etsy 也將 StatsD 開源，介紹了簡單的使用方式 基于基本線路協(xié)議預(yù)期發(fā)送的指標(biāo)格式：

<metricname> : <value> | <type>

如果你在本地運行 StatsD 和默認(rèn)的 UDP 服務(wù)器，在命令行最簡單的發(fā)送指標(biāo)方式：

echo "foo:1|c" | nc -u -w0 127.0.0.1 8125 &nbsp;

collectd

collectd 其實也是一個守護(daemon)進程，用來收集系統(tǒng)性能數(shù)據(jù)和提供各種存儲方式來存儲不同值的機制。具體可以參考Collectd 的官方網(wǎng)站。

collectd 不僅僅是收集性能數(shù)據(jù)，還根據(jù)這些數(shù)據(jù)周期性統(tǒng)計系統(tǒng)的相關(guān)信息，以這些統(tǒng)計信息為依準(zhǔn)，檢查當(dāng)前服務(wù)器性能和預(yù)測系統(tǒng)未來，但它本身不能生成圖形——雖然它能寫 RRD 文件，但是不能從這些文件生成圖形——所以一般需要結(jié)合一個數(shù)據(jù)繪圖工具 Graphite 。像 VPSee 就是選用 collectd 來收集機器的各個性能參數(shù)。

相對于其他收集系統(tǒng)性能指標(biāo)的項目，collectd 有一定的優(yōu)點，比如嵌入式系統(tǒng)，C 語言開發(fā)（高效）、無需系統(tǒng) cron 支持（獨立）、簡單易用等，此外他還包含超過70多種插件以及文檔支持。

StatsD 和 Graphite

我們篤信圖表對數(shù)據(jù)呈現(xiàn)的意義，Ian Malpass 在 Code as Craft 發(fā)表的文章中這么描述：只要是變化的事件，我們就去追蹤。我們通常關(guān)注網(wǎng)絡(luò)、設(shè)備和應(yīng)用的數(shù)據(jù)，而其中應(yīng)用性能數(shù)據(jù)往往是這三者中最難測量、但又最重要的，它們與你的業(yè)務(wù)息息相關(guān)。那么是否可以將工程師可能測量或計時的指標(biāo)以最簡便的方式做成圖表呢？

大家都知道，StatsD 經(jīng)常與 Graphite 一起出現(xiàn)在工程師的視野中，眾所周知，StatsD 負(fù)責(zé)收集并聚合測量值，之后，它會將數(shù)據(jù)傳給 Graphite，后者以時間序列為依據(jù)存儲數(shù)據(jù)，并繪制圖表。意即 StatsD 負(fù)責(zé)數(shù)據(jù)的初步處理，Graphite 負(fù)責(zé)數(shù)據(jù)展現(xiàn),相得益彰。

我們中意 Graphite 的原因很多：它使用簡便，畫圖和數(shù)據(jù)操縱的能力強大。我們可以結(jié)合來自 StatsD 和其他指標(biāo)收集系統(tǒng)的數(shù)據(jù)。最重要的是，對于 StatsD 來說，只要將測量指標(biāo)的數(shù)據(jù)推送給 Graphite, 它就會創(chuàng)建新的測量指標(biāo)。這意味著，工程師們在追蹤新的指標(biāo)時無需擔(dān)心管理成本，他只要告訴 StatsD 「我想要追蹤?grue.dinners」該指標(biāo)就會自動出現(xiàn)在 Graphite 中。此外，向 Graphite 推送數(shù)據(jù)的頻率為10秒，因此，StatsD 的測量指標(biāo)展現(xiàn)近乎實時。

該圖片簡單地描繪了 http 請求在一段時間內(nèi)的 elapsed_time 值。

因此，有了 StatsD，抓取速率等測量值變得極為簡便，再加上 Graphite 對數(shù)據(jù)進行處理，查看、分析這些數(shù)據(jù)也就變得非常簡單。

StatsD 生態(tài)環(huán)境

在國外基于 StatsD 產(chǎn)生了一系列的工具，或者在成熟的項目基礎(chǔ)之上，開始兼容 StatsD。如果按照方向可以劃分為如圖的幾個方向。

Integrations

由于 StatsD 本身不負(fù)責(zé)定義指標(biāo)的涵義，所以從數(shù)據(jù)庫或者操作系統(tǒng)中采集的工作，需要進行腳本的開發(fā)。其中在這方面做出突出貢獻的就是 Datadog。

dd-agent 這個項目在 GitHub 多達 150 個貢獻者，兼容多達 60 多種操作系統(tǒng)、中間件、數(shù)據(jù)庫。

除此之外，Librato 和 App First 也加入到 StatsD 的陣營中。而基礎(chǔ)設(shè)施管理的解決方案：Puppet 和 Chef 也開始兼容將 StatsD 批量安裝到基礎(chǔ)設(shè)施中。

Visualization 和 Data Hosting

Graphite 作為一個可視化的控件，不僅包含可視化還自帶存儲的部分。但是單論可視化，Grafana 是做得最好的一家，其展現(xiàn)形式豐富，可配置項目巨細(xì)靡遺。Signal FX 后來居上，也參與到競爭中。

在數(shù)據(jù)可視化的基礎(chǔ)之上，也有服務(wù)開始從事可視化數(shù)據(jù)的托管服務(wù)。例如：Host Graphite。

時間序列數(shù)據(jù)庫和事件處理引擎

其實 StatsD 和時間序列數(shù)據(jù)庫的出現(xiàn)，是相輔相成的。在 OpenTSDB 和 InfluxDB 基礎(chǔ)之上，StatsD 的應(yīng)用才日漸豐滿。

而事件處理引擎，如 Riemann 開始與時間序列數(shù)據(jù)庫，或者基于 StastD 的一體化解決方案對接，從而彌補除開展現(xiàn)之外的報警這個方向上的不足。

一體化解決方案

那么，有沒有一體化的解決方案呢？國外除開這些細(xì)分的方向之外，也有廠商提供一體化的解決方案，通過輕量級的 StatsD 來達到更高的計算能力，來處理日益復(fù)雜的基礎(chǔ)設(shè)施架構(gòu)。如：Datadog、Librato 等等。而國內(nèi)的 Cloud Insight，也是基于同樣的思路，提供系統(tǒng)監(jiān)控的服務(wù)。今年年初 Datadog 獲得 C 輪融資，融資金額為 3100 萬美元。而其客戶名單從 Facebook 到 Airbnb，成績斐然。孕育 Cloud Insight 的公司 OneAPM 同樣在不久前也獲得 C 輪1.65億的融資，被業(yè)界普遍看好。

結(jié)語

誠然，StatsD 作為新世代的系統(tǒng)監(jiān)控的核心，目前還處于技術(shù)累計過程。我們相信，未來會有越來越多的開源項目加入到它的懷抱中，也有越來越多的公司，在此基礎(chǔ)之上加入了研發(fā)的資源，或者在與之相關(guān)的其他領(lǐng)域中投入成本。基于該技術(shù)的 Datadog 公司，憑借其在該技術(shù)的投入和實打?qū)嵉挠嬎隳芰?#xff0c;獲得了不錯的成績。而國內(nèi)的 Cloud Insight 這個產(chǎn)品線，基于相同的思路也加入到 StatsD 陣營中。最終 StatsD 是否有可能取代 Zabbix 或 Nagios 成為系統(tǒng)監(jiān)控的新標(biāo)準(zhǔn)，讓我們拭目以待吧！

總結(jié)

以上是生活随笔為你收集整理的StatsD！次世代系统监控的核心的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。