在互联网业务蒸蒸日上的今时今日，系统架构日渐复杂，随着软件产品和工程团队的变革，许多开源的监控工具应运而生，其中有一些相当出名，比如 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 开源，介绍了简单的使用方式 基于基本线路协议预期发送的指标格式：
<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，也是基于同样的思路，提供系统监控的服务。Cloud Insight 采用 StatsD 的采集技术，对接 MySQL、Redis、MongoDB，以及 CentOS、RedHat 操作系统，在 HBase 存储之上，使用了 OpenTSDB 来对性能指标进行聚合、分组、过滤。通过 StatsD 的生态环境的研究，整合不同的工具为用户提供一体化解决方案。
今年年初 Datadog 获得 C 轮融资，融资金额为 3100 万美元。而其客户名单从 Facebook 到 Airbnb，成绩斐然。孕育 Cloud Insight 的公司 OneAPM 同样在不久前也获得 C 轮1.65亿的融资，被业界普遍看好。
结语
诚然，StatsD 作为新世代的系统监控的核心，目前还处于技术累计过程。我们相信，未来会有越来越多的开源项目加入到它的怀抱中，也有越来越多的公司，在此基础之上加入了研发的资源，或者在与之相关的其他领域中投入成本。
基于该技术的 Datadog 公司，凭借其在该技术的投入和实打实的计算能力，获得了不错的成绩。而国内的 Cloud Insight 这个产品线，基于相同的思路也加入到 StatsD 阵营中。最终 StatsD 是否有可能取代 Zabbix 或 Nagios 成为系统监控的新标准，让我们拭目以待吧！