Criteo 使用 Cassandra 存储后端实现 Graphite 的规模化

  • Hrishikesh Barua
  • 盖磊

2018 年 3 月 20 日

话题:DevOps语言 & 开发

看新闻很累?看技术新闻更累?试试下载 InfoQ 手机客户端,每天上下班路上听新闻,有趣还有料!

Criteo公司 SRE 团队的一位成员在上个月召开的 FOSDEM 大会上做了一个演讲,介绍了他们如何使用 Cassandra 作为存储后端实现 Graphite 产品的规模化安装。为实现容错和弹性扩展,Criteo 工程团队编写了一个称为“BigGraphite”的 Graphite 用户化插件,替代了 Cassandra 默认使用的 WhisperDB。

Criteo 需要解决容错和弹性扩展问题,这是已被分布式数据库解决的问题。Criteo 团队决定使用 Graphite 的插件架构,编写支持使用Cassandra为存储后端的定制插件。该插件作为“BigGraphite”项目开源。项目在设计中考虑了支持多种后端,但是目前只提供对 Cassandra 的支持。

Whisper 是 Graphite 推出的默认数据库,它采用固定大小的文件存储数据。文件的大小固定,因为 Graphite 在存储数据时指定了一个预先配置的保留期限,通常更旧的数据以更低的采集频率存储。Criteo 的度量采集横跨具有超过两万台服务器的六个数据中心,每秒写入 80 万个数据点。团队维护了两千多个仪表盘,以及一千多种报警,每隔五分钟做一次度量评估。Graphite 的默认配置(包括存储后端)并不能满足这样配置的需求。据报告介绍,除了“每种度量对应一个文件”模型存在大量浪费的问题之外,Graphite 的集群并非十分稳健,也不是“真正可弹性扩展的”。此外,Whisper 中操作数据模型所用的命令行工具运行速度慢,性能脆弱。

图片来源:演讲中使用的幻灯片

在 BigGraphite 架构中,有一个 Carbon 中继,它将来自于数据中心的事件发送给写入 Cassandra 的 Carbon 缓存过程。Carbon 中继也实现复制功能,并通过将数据推送给多个 Carbon 缓存过程实现分片功能,度量数据由 Carbon 缓存过程写入到磁盘。转移到 BigGraphite 架构还包括改为使用 Graphite Web UI。

演讲中还介绍了 Cassandra 的时序模式,但是并未详细介绍如何存储或查询给定度量的标签。Cassandra 表中的每行数据都包括度量名称和开始时间戳,并以此作为主键,列键使用与开始时间戳的偏移量。Graphite 根据数据所处的保留阶段存储度量数据,例如,为期七天并且每分钟采集一次的数据、为期六个月并且每天采集一次的数据,诸如此类。更早期的度量数据使用聚合函数计算,这反映在 Criteo 团队对 Cassandra 表的设计中。对于一个给定的度量,实现有多个表,其中每个表用于一个给定的保留阶段,即对于一个给定的时期,应存储何种采集频率的数据点。

除了 Cassandra 之外,团队还测评了多种时序数据存储,包括OpenTSDBCyaniteKairosDBInfluxDB。Criteo 团队并未采用 OpenTSDB,因为 OpenTSDB 采用 HBase 为后端,但是团队已经为其它用途使用了 HBase 集群,难以在该集群之外再建立一个 HBase 集群。其它选项在完成测评时尚未具备部分所需的特性,因此同样未得到采用。

当前 Criteo 的 Cassandra 集群运行有 20 个节点。团队正致力于引入Prometheus,并构建各个系统间的联系纽带

查看英文原文: Scaling Graphite at Criteo Using a Cassandra Backend

DevOps语言 & 开发