详解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 等几乎所有语言的客户端。
　　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 的官方网站。