Graphite 是处理可视化和指标数据的优秀开源工具。它有强大的查询 API 和相当丰富的插件功能设置。事实上,Graphite 指标协议(metrics protocol)是许多指标收集工具的事实标准格式。然而,Graphite 并不总是一个可以简单部署和使用的工具。由于设计方面的原因,加上它使用过程中涉及大量的小 I/O 操作,在规模化应用中会遇到一些问题,而且部署起来可能有点麻烦。
Graphite是一个Github项目,没有自己的独立域名网站,文档也host在专门存放文档的网站上。
Graphite基于Python,由三部分组成:
- Carbon:基于Twist的TCP Server,负责接收数据,用简单到死的文本协议,因为够简单,所以Yammer Codahale Metrics、Netflix Servo、StatsD、Collectd、Logstash,人人都有一个到Graphite的插件。
- Whisper:类库,将数据存储成RRD(round-robin-databas)文件,数据粒度随时间递减,可以存储更长时间的其据。其继承者是Ceres,不再固定文件大小。
- Graphite-Web:基于Django的Web应用,支持Restful的URL获取图片或JSON数据,URL里可以带各种有用的函数。
基于Python的单点性能可能不高,但Graphite有Cache、HA、Scalable方面的专门设计。
虽然 Graphite 包含三个组件可能会导致一些实施的问题,但也有积极的成果。每一个模块都是一个独立的单元,这样你就可以按照实际的需要混合和匹配使用三个组件中的哪一个。同时意味着您可以为自己构建一个完全定制化的 Graphite 部署方案。
对于 Graphite 的每一个组成部分来说,都可以是一个 Graphite 的方案或者是非 Graphite 的替代品。
目录
指标采集器:Dropwizard Metrics, StatsD
Graphite 部署方案中的第一个步骤根本不是 Graphite 的组成部分。这是因为 Graphite 自身并不支持采集任何指标;Graphite 需要有人将指标数据发送给它。这通常不是一个特别大的限制,因为大多数指标采集器都支持以 Graphite 格式提供指标数据,但仍然有一些东西需要注意。我们可选的不同指标采集器可以列一个庞大的列表,但是没有一个工具是包含在基础 Graphite 中的。
选择你的指标采集器 – Graphite 文档中提供了一个工具列表,包括流行的选择像 CollectD 和 Diamond,但它很少更新,所以你还可以考虑以下两个方案:
- Dropwizard Metrics是一个 Java 库,通过一系列指标为你提供生产环境的可视化。它有一个 Graphite Reporter,可以将所有的指标数据发送到 Graphite 实例。对于需要在 Java 生态中使用 Graphite 的场景来说,它是一个不错的选择。
- StatsD是一个基于js 运行的网络守护进程,来自 Etsy (网络电商平台)。它可以监听一系列统计、指标数据,并将它们聚集到像 Graphite 这样的工具中。StatsD 也可以和很多其他的可视化、指标采集工具一起工作。
Graphite 不和特定的指标采集器捆绑。然而,Graphite 指标协议是非常常见的,因此不难找到一个或多个与您的应用程序一起工作的协议。既然有这么多的指标采集器和 Graphite 配合良好,你不需要只选择一个,你可以选择从多个数据源发送指标。
监听器:Carbon, graphite-ng, and Riemann
Graphite 的另一部分是用于监听发送的指标数据并将其写入磁盘的组件:Carbon。Carbon 是由守护进程组成的,在工作方式方面有一些内置的灵活性。在基本的小规模部署中, Carbon 守护程序会监听指标数据并将它们报告给 Whisper 存储数据库。然而,随着规模的增长可以添加一个聚合元素(Aggregation),它在一段时间内缓冲指标数据,然后将它们发送给一个大块中的 Whisper。你也可以使用 Carbon 传递指标副本到多个 Carbon 后台。当你达到更高的规模、需要多个 Carbon 后台程序来处理传入的指标数据时,这一点特别有用。缺点和潜在的问题:人们通常遇到的问题通常跟规模相关。就规模应用而言,Carbon 有以下几个缺点 :
- 一个单独的 Carbon 守护程序处理能力有限,因为它是用 Python 语言设计的。本机代码不支持一次多个线程同时运行( Multiple threads),所以可能出现 Carbon 守护程序刚刚启动时丢弃指标数据的情况。
- Carbon 有一个它一次能处理负载数量的阈值,但这个阈值并没有传达给你。
- Carbon 并没有持续打开 Whisper 的文件句柄,所以存储每个指标都需要多步的完整读/写序列。
基于标准的 Graphite 部署实例中,这些情况的解决方法是将工作划分为中继器( Carbon relays) 和 缓存(Carbon caches )。尽管如此,您仍然需要注意负载,因为超过了 Carbon 的负荷会导致数据丢失。如果这个后果对你来说无法接受,可以看看 Carbon 的替代解决方案。
Carbon 替代方案:
- graphite-ng,本质上是基于 Go 语言重写了一遍 Carbon ,以解决上面提到的几个问题。迄今为止,该项目的重点是改进 Carbon 的中继和聚合功能。如果你喜欢 Carbon 的功能,但是又想要绕过一些性能方面的限制,这是一个不错的选择。
- Reimann,基于 Clojure 语言实现(属于 LISP 编程语言家族),Reimann 是用来聚集和处理“事件流(event streams)”。事件和流都是相当简单的概念,Riemann 能代替 Carbon 把它们发送到 Graphite 实例。它在这个过程增加了一些提供了额外的好处,例如告警功能。如果你想设计一个远离 Carbon 的架构,这是一个很好的选择,还能加入一些涉及告警方面的能力。
存储数据库:Whisper, InfluxDB, Cyanite
您需要选择的下一个组件是存储数据库。在 Graphite 体系结构中称之为 Whisper。Whisper 是一种固定大小的数据库,用于存储时间序列数据,在保存和取样方面提供了相当的精确度。在标准的 Graphite 部署中,Carbon 将指标值写入 Whisper 存储,用于在 Graphite-web 组件中实现可视化。
缺点和潜在问题:Whisper 基于 RRD(Round- Robin Database),但写入操作的时候有一些关键性的差异,例如回填项目历史数据和处理不规则数据的能力。这里有一些指标和可视化工具的有用特性,但它们的实现都是基于某种折衷。
- 因为 Whisper 是用Python编写的,所以相对来说性能较慢;
- 按照 Whisper 的设计,它会遇到一些存储空间的问题,因为每个指标都需要一个文件,并且都是单个实例。这是一种有意的权衡,以实现前面提到的一些好处,但不可否认,Whisper 对磁盘空间的利用效率较低。
- 由于 Carbon 和 Whisper 在设计方面的原因,它们最终都涉及到大量的 IO 请求。当你超越小型部署时,磁盘 IO 的伸缩能力会成为摆在面前的一个问题。
Whisper 替代方案:
- Influxdata(InfluxDB)是一个基于 LevelDB、用 Go 语言编写的时间序列数据库。influxdata 能够解决一些磁盘 IO 写优化问题,同时不要求 one metric = one file 。influxdata 支持 Carbon 使用的协议,使它能够悄悄置换 Whisper,实现类似 SQL的查询语言。甚至已经有一些项目设计用来使 influxdata 的置换更简便易行,例如 graphite-influxdb 项目 ,使得可以和 Graphite 的 API 无缝衔接。influxdata 属于非常有前途的新兴项目,可以在广泛的范围内与其他工具一起工作。
- 基于 Cassandra 的存储数据库。得益于graphite-cyanite项目的工作,基于Cyanite 数据库可以很容易实现这一目的。Cyanite的开发规划目标就是在 Graphite 体系结构中替换 Whisper,这意味着它可以和 Carbon、Graphite-web 一起工作(需要少量的一些依赖)。使用 Cyanite 有助于解决 Whisper 在大规模部署场景中存在的性能和高可用问题。
Graphite 体系结构中,数据存储组件是 Whisper 。在大规模应用中,除非你在硬件方面大量投入、把它分解成复杂的手动集群模式,否则将悄悄地会遇到一些性能和可用性问题。如果你需要关注这些问题,可以使用数据库的替代选项来提高性能和可用性。
可视化组件:Graphite-Web 和 Grafana
一旦你收集并存储了指标数据,就下来的步骤就是可视化它们。Graphite-web 的角色就是提供可视化。 Graphite-web 是一种基于 Django 的 Web 应用程序,提供指标数据可视化和交互能力。它在数据的处理方面提供了相当多的能力,但可视化组件并不十分美观(也就是说 “土”、“丑”)。Graphite-web 作为前端组件,我们将着重讨论用户体验的相关内容。
Graphite-web 替代方案:
归功于卓越的 Graphite API ,目前有一系列第三方仪表盘工具可以支持 Graphite 。因为有如此众多的可视化选项,它们的优劣其实主要取决于个人品味,再次不作过多扩展,但我确实想特别指出其中的一个。也许最具潜力的 Graphite 可视化替代方案, 或至少是人们谈论最多的是 Grafana。
Grafana 是一个开源的仪表盘工具,可以兼容 Graphite 和 InfluxDB 。Grafana 曾经只是一个基于 Elasticsearch 存储的前端仪表盘工具,从 V2.0 版本开始,它拥有了一个支持用户自定义的后端存储组件。Grafana 在设计之初即考虑到支持 Graphite 创建更加优美的可视化组件,因此它非常适合替换默认的 Graphite-web 。Grafana 功能相当丰富,性能稳定。Grafana 拥有一个后端组件,如果你也可以找到纯粹的前端工具,Graphite 文档中提供了工具列表。
如果你觉得 Graphite 提供的默认可视化效果过于基础和乏味,有大量的可视化替代方案可以选择。其中一些是纯粹客户端,有的包含一个存储你建立的仪表盘后端组件。不管你要什么,你都能在这里找到东西。
代码级指标– Trends
OverOps 发布了一个新的功能,可以让你把代码级指标从 JVM 应用程序中的错误、与变量状态在一起发送到 Graphite。详细:https://www.overops.com
总结
所有针对 Graphite 的投诉都集中于(它的工作性能不够稳定,仪表盘丑陋!规模化部署是硬伤!),但不妨碍它成为一个很流行的工具。如果你想要一个开源的指标和可视化工具,为许多企业级工具提供支持,那么 Graphite 值得一试。其中最重要的一点是,你可以自定义数据内容。Graphite 并不是由完全特定的组件一起工作,其中的乐趣何在 ?经过一些尝试和错误,您可以在您自己的环境中构建一个完全定制化的、非常有用 Graphite (或类似 Graphite 的)部署方案。
参考链接: