如何利用Graphite、StatsD与CollectD实现数据追踪与统计

如何利用Graphite、StatsD与CollectD实现数据追踪与统计

提供：ZStack社区

系列教程

本教程为《在服务器上追踪统计结果》系列四篇中的第一篇。

内容简介

出于各种理由，我们经常需要收集与服务器、应用程序以及流量相关的状态数据。收集并整理这些数据能够帮助我们制定出更加行之有效的规模伸缩及故障排查决策，同时对现有配置中的痛点进行追踪。

我们可以利用多种工具对设备上的各项指标加以追踪，而且其通常只需要占用特定进程中的一小部分资源。我们也可以将这些工具加以结合，从而创建出一套对结果进行收集、记录与显示的完整系统。

在本次教程中，我们将了解几种能够切实对服务器及应用程序数据进行收集、存储与可视化处理的技术方案。

具体来讲，此次了解的对象包括Graphite——一套由多种组件构建的图形库，可用于对特定时间段内的数据进行视觉渲染与显示。另外还有CollectD，其属于系统统计守护进程，能够以近实时方式收集与当前服务器相关之信息。最后是StatsD，一款灵活的数据聚合器，能够收集并整理任意数据。

在接下来的内容中，我们将共同了解如何立足于Ubuntu 14.04服务器安装并配置这些功能组件。

为什么要追踪数据？

首先需要明确的是，我们为什么要对服务器或者应用程序环境下的数据进行追踪。

其核心理由非常简单：我们掌握的数据越多，那么了解特定时间段内整套业务体系的运作状态也就越简单。通过这种方式，我们能够轻松利用客观数据支撑自己的决策，并在实际结果出现之前预测某项变更是否指向正确的组件。对状态的追踪还能帮助我们了解更多应用程序日志无法提供的重要信息。

大部分（但并非全部）日志记录系统都无法对来自多种应用的数据进行关联，或者将事件与特定系统状态联系起来，这是因为它们往往只能代表独立的应用运行输出结果。有鉴于此，我们将很难围绕单一事件构建面向整体系统的完整审视结论。

可以想见，假设我们遭遇数据库服务器的意外宕机。在阅读日志记录时，大家可能会发现在15：35：28时间点上，MySQL服务由于OOM（内存不足）错误而被关闭。现在我们意识到内存使用量正是问题的根源，但对于一台始终运行稳定的服务器，我们很难快速发现造成这种内存使用峰值的理由所在。

如果对服务器以及应用程序数据进行追踪，我们就能够将系统数据片段整合起来，从而了解问题发生时运行环境的整体状态。我们可能会发现当时的内存使用量激增源自内存泄漏。如果拥有应用层级的内存使用量信息，我们亦能够判断哪款程序是导致问题的元凶。另外，我们可能还会发现一些不同寻常的资源需求峰值，这意味着问题也许存在其它可能性。

再设想另一种场景，我们可以查看系统在部署前与部署后的具体状态。如果新代码会引发某些意外状态，我们能够确切掌握其对其它组件的影响，并将其性能与上版本代码进行比对。我们还可以了解新代码在哪些方面实现了改进，并对其中可能存在问题的部分加以修复。

有了这种良好的数据收集能力，我们可以将系统真正视为一套完整体系，而不再是过去那种松散且缺乏关联性的组件集合。

Graphite组件

这里我们首先关注Graphite，随后介绍几款能够帮助Graphite获取数据的软件。

Graphite是一套图形库，负责对数据进行保存以及视觉显示渲染。这意味着Graphite需要借助其它应用进行数据点收集与转换。

Graphite项目本身亦由多个组件构建而成，其中每个组件都有独特的作用取向。

Graphite Web应用

Graphite安装包中最具可视性与动态性的组件当数Graphite Web应用。

我们也将在这里对收集到的数据进行图形设计：

Graphite为我们提供一套灵活的界面以进行图形设计。大家可以在这里结合多种不同指标类型、控制标签、字体、颜色以及线条属性，并根据需要对数据进行大小调整及修改。

这里的核心思路在于，Graphite基于接收到及指向的数据点渲染图形。其不会输出图形并同时释放数据内容。大家可以随时根据需要进行数据渲染。

这款Web应用还允许大家保存图形属性与布局，这意味着我们可以生成包含全部所需设定的监控界面。大家还可以根据喜好设计仪表板视图，从而为每台设备或者每款应用构建独立的仪表板。如果大家需要跨设备或应用进行数据关联，将各图形直接拖拽并结合即可。

不过其灵活性还不仅如此。Graphite允许大家将图形渲染为裸URL，并将其嵌入至其它界面当中。大家也可以利用JSON或者CSV等非图形化格式进行数据导出，或者利用SCG格式以嵌入数据信息。

现在大家已经了解了收集数据的意义所在，接下来要探讨的为Graphite中的各具体组件。

Carbon

Carbon是一套面向Graphite配置的存储后端。单一Graphite配置中将包含一个或者多个Carbon守护进程，其负责由其它进程收集并传输的统计数据（Graphite当中并不包含收集器）。

Carbon守护进程的类型多种多样，每一种都以独特的方式实现数据处理。其中最基本的一种名为carbon-cache.py。该守护进程非常直观，能够监听特定端口之数据并将其高效写入至目标磁盘。

它会在数据输入时加以保存，而后根据预定时间周期将其更新至磁盘。更重要的是，该Carbon组件能够处理数据接收与更新流程。它并不处理具体存储机制，这部分工作由whisper组件负责承担，我们将在稍后提到。

carbon-cache.py守护进程需要了解需要处理的具体格式、协议以及端口。另外，我们还需要告知其用于实现数据存储的数据保留策略。这些都由whisper负责实现。对于大多数基本配置，单一carbon-cache.py实例即可顺利完成数据复制。

随着设置规模的提升，其亦可同时运行多个实例，而具体负载均衡工作则由carbon-relay.py或者carbon-aggregator.py处理。

carbon-relay.py守护进程可被用于向全部后端守护进程发送请求以实现冗余。其也能够在多个不同carbon-cache.py实例之间进行数据共享，从而跨越多个存储位置分散读取负载。

carbon-aggregator.py守护进程则能够缓冲数据，并在一段时间后将其传输至carbon-cache.py。通过这种方式，我们能够削减状态处理给系统性能带来的影响。

Whisper

Whisper是一套数据库库，Graphite利用它存储其发送的信息。

它具备出色的灵活性，且能够以非常详尽的方式存储时间序列数据。它能够立足于不同细节层级创建不同归档副本，从而满足特定使用需求，并在特定信息超出保留时间阈值后降低其详尽程度。

举例来说，大家可以针对特定指标进行每秒一次数据点存储，同时将whisper的详尽数据存储周期设定为5小时。与此同时，我们需要保留的归档数据在详尽程度上应该相对较低。其可能只需要每分钟保存一次，但保留周期则延长至6个月。

低详尽度归档点会根据以高详尽度方式存储的数据进行计算。大家可以同时利用多种详尽度水平保存不同的归档副本，且详尽度指标可随意设定。我们亦能够根据所追踪的指标为whisper设置不同详尽度的具体计算方式。

举例来说，某项指标可能代表短时间帧内某事件的发生次数总和。要创建一个详尽度较低但时间段更长的保存点，大家可以引入高详尽度数据点以汇总更长时间段内的数据值。

Whisper还能够根据指标的不同特性采用其它低详尽度计算方式。例如，部分数据属于平均取值，另一些则需要追踪其最大值。对于平均值数据，whisper会根据高详尽度数据点计算低详尽度值。而对于最大值数据，whisper则保留其最大值并舍弃其余值，从而保持平均计算结果的正确性。

Whisper会在其接收到数据的同时计算并记录低详尽度数据（在收集到必要值后立即进行）。它能够对收集到的数据点执行必要数据聚集操作（包括取平均值、取最大值等等），而后进行写入。

Graphite将使用包含有所需时间帧信息的高详尽度归档作为数据基础，从而实现进一步图形渲染。

状态收集与交付

正如之前所提到，Graphite本身并不具备数据收集功能。相反，它依赖于其它服务实现数据供应。这不仅使得该项目的关注范围更加集中，同时也使其以模块化方式同其它多种输入服务进行交互。

接下来，我们将探讨Graphite所使用的各类协议，之后则是两款主流收集选项——CollectD与StatsD，大家可以利用其将数据传递至Carbon以完成处理。

协议

大家可以利用三种不同协议向Graphite发送数据。

首先，Graphite能够接收并识别普通文本。这种格式最为灵活，因为几乎每一种应用或者服务都能够生成文本输出结果，且这种结果能够供Graphite以及其它中间工具使用。

纯文本消息中包含的信息有指标名称、所赋值以及该值时间戳等。这些消息可通过指定的纯文本端口被直接发送至Carbon，而无需额外的格式化处理。

由于Craphite由Python编写而成，因此其同时也能够接收“pickle”数据序列格式。这种Python标准允许我们对单一事务内的多时间值进行缓冲与发送。

Graphite还能够接收AMQP消息格式。这样我们就可以更为细致地处理大型数据负载。大家能够供应大量状态数据并应对远程主机之间的网络连接中断状况，而不必担心此类配置方式产生数据丢失问题。

CollectD

收集服务器详尽信息的最便携方案之一正是使用CollectD守护进程。

CollectD能够收集与服务器环境下大量不同组件相关的统计信息。它允许我们轻松追踪各类常见指标，包括内存使用量、CPU负载以及网络流量等等。在此基础上，大家将能够轻松将事件同系统状态关联起来。

除了收集标准系统信息之外，CollectD还具备一套插件系统以扩展自身功能。这意味着大家可以轻松追踪Apache、Nginx、iptables、memcache、MySQL、PostgreSQL、OpenVPN以及其它常见软件。

CollectD还提供一种简便方式，能够从服务器上的内置应用与其它常见服务处获取数据。大家可以借此对基础设施以及相关服务的行为进行追踪。

StatsD

StatsD是一款非常简单的守护进程，大家可以利用它将其它数据发送至Graphite。这种方式的优势在于，我们能够轻松将状态追踪机制纳入正在构建的应用程序及系统当中。

StatsD会监听某一接口的简单UDP数据包，并将其作为单一数据点。这意味着它能够以无连接方式接收大量信息。在此之后，它会将接收到的值进行汇聚并发送至Graphite。

这套系统允许我们大量发送状态，而不必担心因此增加应用程序延迟。StatsD服务将对全部输入数据进行收集、汇聚而后作为经过汇总的数据点根据预设时间帧发送至Graphite。

由于具备上述优势，StatsD成为将任意类型数据发送至Graphite的理想中继选项。不过其主要用途仍是监控我们的应用程序及所创建的工具。

StatsD之所以精于处理这类任务，是因为其核心作用就是接收UDP流量。目前有多种利用不同编程语言编写的客户端库能够将数据直接发送至StatsD实例。这意味着我们正在构建的应用程序通常可以轻松发送数据并实现追踪。

总结

到这里，大家应该已经了解了这些统计与图形工具集，相信它们会在未来的工作中帮助各位更全面地了解自己的业务环境。

在下一篇教程中，我们将探讨 如何在Ubuntu 14.04服务器上安装Graphite。在此之后，我们将把 collectd and StatsD与Graphite对接以实现状态监控。

本文来源自DigitalOcean Community。英文原文：An Introduction to Tracking Statistics with Graphite, StatsD, and CollectD By Justin Ellingwood

翻译：diradw