Graphite 是一个高度可扩展的实时图形系统。作为用户，您可以编写一个应用程序来收集您感兴趣的数值时间序列数据，并将其发送到Graphite 的处理后端Carbon，后者将数据存储在Graphite 的专用数据库中。然后可以通过Graphite 的网络界面将数据可视化。

Graphite 是一个高度可扩展的实时图形系统。作为用户，您可以编写一个应用程序来收集您感兴趣的数值时间序列数据，并将其发送到Graphite 的处理后端Carbon，后者将数据存储在Graphite 的专用数据库中。然后可以通过Graphite 的网络界面将数据可视化。

常见问题

谁应该使用石墨？

任何想要跟踪一段时间内任何数值的人。如果您的数字可能会随着时间的推移而变化，并且您可能希望绘制该值随时间变化的图表，那么Graphite 可能会满足您的需求。

具体来说，Graphite 旨在处理数字时间序列数据。例如，Graphite 非常适合绘制股票价格图表，因为它们是随时间变化的数字。无论是几个数据点，还是来自数千台服务器的数十个性能指标，Graphite 都适合您。作为奖励，您不必提前知道这些东西的名称（谁想要维护如此庞大的配置？）；您只需发送一个指标名称、一个时间戳和一个值，Graphite 就会处理其余的事情。

石墨的可扩展性如何？

从CPU 的角度来看，Graphite 在前端和后端都可以水平扩展，这意味着您只需添加更多机器即可获得更多吞吐量。它还具有容错能力，即丢失后端计算机会导致最小的数据丢失（无论该计算机在内存中缓存什么），并且如果您有足够的剩余容量来处理负载，则不会破坏系统。

从I/O 角度来看，在负载下，Graphite 会非常快速地对许多不同的文件执行许多微小的I/O 操作。这是因为发送到Graphite 的每个不同指标都存储在自己的数据库文件中，类似于构建在RRD 之上的许多工具（drraw、Cacti、Centreon 等）的工作原理。事实上，Graphite 最初确实使用RRD 进行存储，直到出现需要新存储引擎的基本限制。

高容量（每分钟更新数千个不同的指标）几乎需要良好的RAID 阵列和/或SSD。如果磁盘无法跟上发生的大量小型写入（每个数据点只有几个字节，但大多数标准磁盘每秒无法处理超过几千个I/O 操作，即使它们很小），Graphite的后端传入的数据会被缓存。当这种情况发生时，Graphite 的数据库引擎会允许Carbon 一次写入多个数据点，从而提高整体吞吐量，但代价是将多余的数据缓存在内存中直到可以写入。

Graphite 还支持替代存储后端，可以显着改变这些功能。

图表的实时性如何？

非常实时。即使在重负载下，当每个时间间隔传入的指标数量远大于存储系统可以执行I/O 操作的速度，并且大量数据点缓存在存储管道中时（参见前面的问题解释） ），Graphite仍然可以绘制实时图形。诀窍在于，当Graphite Web 应用程序收到绘制图表的请求时，它会从磁盘以及预存储缓存（如果您有多个后端服务器，缓存可能是分布式的）中检索数据，并将两个数据源组合起来创建实时图表。

谁已经在使用Graphite？

Graphite 由Orbitz 内部开发，用于可视化各种关键运营数据，包括应用程序指标、数据库指标、销售等。截至撰写本文时，Orbitz 的生产系统每分钟可以处理大约160,000 个不同的指标，在高速SAN 上的两台niagra-2 Sun 服务器上运行。

Graphite 是用什么写的？

Graphite Web 应用程序基于Django Web 框架构建，并使用ExtJS javascript GUI 工具包。图形渲染是使用Cairo 图形库完成的。后端和数据库是用纯Python编写的。

谁来编写和维护Graphite？

Graphite 最初是由Orbitz 的Chris Davis 开发的。 Orbitz 长期以来一直是开源社区的一部分，并发布了许多其他内部开发的产品。

Graphite 目前由Graphite-Project GitHub 组织下的一组志愿者开发。