监控工具StatsD介绍

luoyjx · 2016-12-08 11:15 · 517次阅读

背景

在互联网业务蒸蒸日上的今时今日,系统架构日渐复杂,随着软件产品和工程团队的变革,许多开源的监控工具应运而生,其中有一些相当出名,比如 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 等几乎所有语言的客户端。
收藏

暂无评论

登录后可以进行评论。没有账号?马上注册