规划用于大型 cassandra 集群监控的石墨组件答案

【问题标题】：planning for graphite components for big cassandra cluster monitoring规划用于大型 cassandra 集群监控的石墨组件
【发布时间】：2017-10-21 20:43:36
【问题描述】：

我计划设置一个 80 节点的 cassandra 集群（当前版本 2.1，但将来会升级到 3）。我浏览了http://graphite.readthedocs.io/en/latest/tools.html，其中列出了石墨支持的工具。

我想决定选择哪些工具作为侦听器和存储，以便它可以扩展。

作为听众，我应该使用默认碳还是应该选择石墨-ng？

但是作为存储组件，我很困惑默认的耳语是否足够？或者我应该看看其他选项（如 Influxdata、cynite 或一些 rdms db (postgres/mysql)）？

作为 gui 组件，我已最终确定使用 grafana 以获得更好的可视化效果。

我认为 datadog + grafana 可以正常工作，但 datadog 不是开源的。所以请建议一个可扩展至 100 个 cassandra 节点的开源替代方案。

【问题讨论】：

我们发现 prometheus + grafana 是一个很好的组合。 80 个节点是一个巨大的 cassandra 集群。为什么你有这么多？您正在监控多少数据？您需要永久保留这一切吗？
嗨..感谢您的回复。我们的计划是使用 50 个虚拟机 cassandra 节点进行横向扩展。我们还将对指标应用一些过滤器来监控以减少监控服务器的负载。

标签： cassandra monitoring graphite

【解决方案1】：

我有 35 个 Cassandra 节点（不同的集群）被监控，石墨 + 碳 + 耳语 + grafana 没有任何问题。但我不得不说，用耳语重新配置收集和聚合窗口是一种痛苦。

今天这项工作有很多替代方案，例如，您可以使用 influxdb (+ telegraf) 堆栈。

还有你不需要 grafana 的 datadog，它们也是一个可视化平台。我前段时间使用过它，但是他们在插件中的某些指标有一些误导性的名称，并且一些指标只是丢失了。作为该平台的专业人士，它非常易于安装和使用。

【讨论】：

您好，感谢您的回答。您的设置与我们相似。如果您再回答几个关于 35 个节点 cassandra 的查询，那就太好了：。 1. 如果您将其用作集群，您有多少个石墨节点？ 2. 您的石墨节点的磁盘空间和 i/o 容量是多少？ 3. 什么是你保留的保留率和分辨率？
1.作为单个节点运行。 2. 空间 - 大约 30gb/5 iops :)，但只保存相关指标。 3. 1m分辨率节省30天

【解决方案2】：

我们现在有一个包含 36 个节点的 cassandra 集群在生产中（我们有 51 个，但从那时起迁移了实例类型，因此我们现在需要更少的 C* 服务器），使用单个石墨服务器进行监控。我们还将数据保存 30 天，但分辨率为 60 秒。由于度量计数的缩放，我们排除了节点间度量（例如从 a 到 b 的打开连接），但保留所有其他度量。总计约 510k 指标，每个耳语文件大小约为 500kb => ~250GB。 iostat 告诉我，我们的写入峰值达到了约 70k 写入/秒。这一切都是在单个 AWS i3.2xlarge 实例上完成的，其中包括 1.9TB nvme 实例存储和 61GB RAM。为了充分利用这种磁盘类型的功能，我们增加了碳缓存的数量。 cpu 使用率非常低（

我想我们可以使用不那么强大的机器，但这为我们提供了很多扩展集群的空间，并且我们不断添加新服务器。对于监控：准备好 AWS 将比其他机器更频繁地终止这些机器，因此备份和恢复更有可能成为常规操作。

我希望这个小见解对你有所帮助。

【讨论】：

感谢您的帮助。我还有一个疑问，为什么您运行的是单节点石墨而不是至少有 2 个节点的石墨集群？您还对 cassandra 指标应用了任何过滤吗？
1.我认为这是一个成本问题，我们将一些指标转发到另一个聚合节点并保留 2 年。但是由于集群结构在不断变化，因此指标无论如何都没有可比性。我们还进行夜间备份。 2. 如上所述：我们过滤所有节点间通信指标，因为这无法扩展。