统一观测丨使用 Prometheus 监控 Cassandra 数据库最佳实践

作者：元格

本篇内容主要包括四部分：Cassandra 概览介绍、常见关键指标解读、常见告警规则解读、如何通过 Prometheus 建立相应监控体系。

Cassandra 简介

Cassandra 是什么？ Apache Cassandra 是一个开源、分布式、去中心化、弹性可伸缩、高可用、容错、可调一致性、面向行的数据库。它的分布式设计基于 Amazon Dynamo，数据模型基于 Google BigTable。Cassandra 由 Facebook 创建，目前在 Facebook、Twitter、Apple、360 等各大 IT 企业成熟落地使用。

在这里插入图片描述

Cassandra 特点

大规模可扩展存储

Cassandra 可扩展到数百 TB，以出色的性能运行在商用集群上。

易于管理

Cassandra 群集易于大规模管理，并且可以随需求的变化动态扩容。

高可用性

Cassandra 设计为“持续在线”并已支持零停机时间升级等功能，应用于生产环境已有十多年的历史。

写密集型应用

Cassandra 特别适合写密集型应用的时序型数据，如时间序列流数据、传感器日志数据和物联网应用程序等。

统计和分析

Cassandra 支持与 Spark 等大数据计算框架集成，用户可以利用 Spark 强大的内存分析功能进行大数据统计和分析。

异地多活

Cassandra 支持异地多数据中心，数据可以跨多个云和数据中心进行复制备份。

典型适用场景

Cassandra 是一个非常灵活的分布式 NoSQL 数据库系统，适用于许多不同的场景。以下是 Cassandra 的适用场景的详细描述：

1.大数据量、高写入频率的应用场景

Cassandra 的设计目标之一就是处理大规模数据集和高写入频率的应用场景，例如社交媒体、物联网、实时数据分析等。Cassandra 能够轻松地水平扩展，使得其能够处理数百亿行数据的工作负载，并支持快速的写入和读取操作。

2.高可用性和容错性的应用场景

Cassandra 具有自动分区、复制和故障转移功能，因此非常适合需要高可用性和容错性的应用场景，例如金融交易、在线游戏等。Cassandra 的分布式体系结构确保了即使在节点故障的情况下，系统也能够继续运行，并保持一致性。

3.跨数据中心和地理位置的数据复制和同步的应用场景

Cassandra 支持多数据中心复制，因此能够轻松地在不同的数据中心之间进行数据同步和数据备份。这使得 Cassandra 非常适合需要全球扩展的应用场景，例如在线广告、电子商务等。

4.需要支持分布式事务的应用场景

Cassandra 通过支持轻量级事务来保证数据的一致性。这些事务能够跨多个节点和多个数据中心，并且能够在高吞吐量和低延迟的情况下执行。Cassandra 还支持分布式计数器，这使得它非常适合需要支持分布式事务的应用场景，例如金融交易。

5.需要灵活的数据模型，能够支持多种查询方式的应用场景
Cassandra 的灵活的数据模型和支持多种查询方式的能力，使得它非常适合需要存储和查询灵活数据模型的应用场景，例如存储时序数据、跟踪订单状态等。Cassandra 还支持多种数据结构，例如集合、映射、列表等，这使得它非常适合存储半结构化和非结构化数据。

虽然 Cassandra 非常适合许多应用场景，但也有一些情况下它可能不适合使用。以下是一些 Cassandra 不适合使用的场景：

对于小规模数据集和低写入频率的应用场景，Cassandra 可能会显得过于复杂和冗余。在这种情况下，使用传统的关系型数据库可能更加合适。
对于需要复杂数据模型和复杂查询的应用场景，Cassandra 可能会限制查询能力和灵活性，因为它不支持复杂的联接操作和事务。在这种情况下，使用传统的关系型数据库或其他 NoSQL 数据库可能更加合适。
对于需要严格的数据一致性和隔离级别的应用场景，Cassandra 的轻量级事务可能无法满足要求。在这种情况下，使用传统的关系型数据库可能更加合适。
对于需要进行复杂分析和聚合的应用场景，Cassandra 可能不是最佳选择，因为它不支持复杂的分析查询和聚合操作。在这种情况下，使用专门的分析数据库可能更加合适。

总之，Cassandra 适合处理大规模数据集和高写入频率的应用场景，但对于小规模数据集和复杂查询、分析等场景可能不适合。 因此，在选择数据库时，需要根据具体的应用需求进行综合考虑。

Cassandra 核心概念

在这里插入图片描述

1.Cassandra 节点（Cassandra Node）

Cassandra 节点是 Cassandra 集群中的一个实例，它负责存储一部分数据，处理读写请求，并与其他节点进行通信。Cassandra 节点之间通过 Gossip 协议进行通信，以维护节点状态和拓扑。

2.Memtable（Memory Table）
Memtable 是一种类似于 SkipList 的内存结构，用于提高写入性能。Memtable 是 Cassandra 在写入过程中使用的临时数据结构，用于保存待写入到磁盘中的数据。当 Memtable 已满时，Cassandra 会将其中的数据写入到磁盘中，并在内存中继续写入新数据。

3.Key Caches

Cassandra 在读取数据时使用的缓存，用于加速读取操作。Key Cache 存储在每个节点的内存中，缓存最近使用的数据项，以便快速查找和访问数据。Cassandra 使用哈希表来存储 key/value 数据，根据 LRU（Least Recently Used）算法来管理 Key Cache 中的数据项。当 Key Cache 已满时，Cassandra 会将最近最少使用的数据项从 Key Cache 中移除以释放空间。

4.Row Caches

Row Cache 是一种内存缓存，用于存储 Cassandra 中的行级数据。Row Cache 是 Cassandra 在读取数据时使用的缓存，用于加速读取操作。Row Cache 存储在每个节点的内存中，缓存最近使用的行级数据，以便快速查找和访问数据。与 Key Cache 和 Memtable 不同，Row Cache 缓存的是完整的行级数据，而不是其中的 key/value 数据。

5.Commit Logs

Commit Logs 机制实际上就是 Cassandra 中实现 WAL（Write Ahead Log）机制的方式之一，用于在写入数据时保证数据的持久性和一致性。当 Cassandra 收到写入请求时，它首先将数据写入到内存中的 Memtable 中，并将数据追加到 Commit Logs 中。这样可以保证在系统出现故障时，数据可以从 Commit Logs 中恢复到最后一次提交的状态。

6.SSTable（Sorted String Table）

SSTable 是 Cassandra 中存储数据的物理格式。每个 SSTable 是一个已排序的字符串表，包含多个数据分区的数据，并根据分区键和列名进行排序。Cassandra 使用多个 SSTable 来存储数据，并使用 BloomFilter 和索引来快速定位数据。

7.Hints

Hints 是 Cassandra 中一种机制，用于在节点故障时保证数据的一致性和可靠性。当节点无法响应写入请求时，Cassandra 会将这些请求保存在 Hints 中，并在节点恢复后重新尝试处理这些请求。Hints 机制可以提高系统的可靠性，但可能会对性能产生影响。

8.Tombstone

在 Cassandra 中，删除操作实际上是一种“写入”操作，Cassandra 会将要删除的数据标记为Tombstone。Tombstone 是一种特殊的数据类型，它包含了要删除数据的信息（如表名、键名、时间戳等），并在磁盘上占据一定的空间。当读取数据时，Cassandra 会检查 Tombstone，如果数据被标记为 Tombstone，则视为已删除，不会返回给客户端。

9.Bloom filter

在 Cassandra 中，Bloom Filter 主要用于查询 Memtable 和 SSTable中的数据是否存在，是 Cassandra 中的一种用于快速查询数据存在性的机制，用于在读取操作时加速查找数据。当 Cassandra 需要查询数据时，它会首先查找 Bloom Filter，如果数据不存在于 Bloom Filter中，则可以直接跳过读取操作，因为数据一定不存在于 Memtable 和 SSTable 中。如果数据可能存在于 SSTable 中，则继续读取 SSTable 中的数据进行验证。

监控关键指标

这里以阿里云的 Cassandra 组件为例，介绍监控 Cassandra 服务中常见的关键指标。

在这里插入图片描述

基础信息

1.CPU / 内存 / 硬盘使用率

Cassandra 作为一个高吞吐量、低延迟的分布式数据库，需要充分利用节点的硬件资源来提供高性能的数据存储和查询服务，如果节点的资源使用超过了预期或者达到了极限，可能会导致性能下降或者系统崩溃，影响业务的正常运行。因此我们首先需要关注节点实时的 CPU / 内存 / 硬盘使用率，以确保 Cassandra 服务运行的稳定性。

2.客户端连接数

连接到当前 Cassandra 服务端的客户端连接数量也是需要监控的指标之一。客户端连接数表示当前正在与 Cassandra 集群进行通信的客户端数量，如果连接数过高可能会导致集群出现资源不足的情况，从而影响系统的性能和可用性。特别是在高并发情况下，客户端连接数的监控和优化显得尤为重要。如果连接数过高，可以通过优化节点配置、增加节点数量等手段来缓解压力，从而保证系统的高可用和高性能。

3.Cassandra 数据量

Cassandra 作为一个数据库，其数据量也是需要紧密关注的监控数据之一。Cassandra 支持海量数据的存储和查询，因此在实际应用中，其数据量通常会不断增长。如果数据量过大，可能会导致节点出现资源不足、查询性能下降等问题，从而影响业务的正常运行。因此，对 Cassandra 集群的数据量进行监控和优化，可以帮助我们更好地管理和维护 Cassandra 集群。监控数据量可以通过监测磁盘使用情况、分布式存储的数据分布情况等指标来实现。如果数据量过大，可以考虑增加节点数量、升级硬件配置、进行数据迁移等措施来缓解压力，从而提高系统的可用性和性能。

4.客户端读写分布比例

最后，我们推荐监控的一个指标是客户端的读写分布比例，Cassandra 是一个支持高吞吐量、低延迟的分布式数据库，通常用于存储大量的读写数据。如果读写分布比例不均衡，可能会导致集群出现瓶颈，从而影响系统的性能和可用性。通过监控客户端的读写分布比例，我们可以及时发现问题，采取措施来优化集群的读写性能。例如，可以通过增加节点数量、调整分区策略、优化查询语句等手段来实现优化。

读写延迟和吞吐量

Cassandra 作为数据库服务，其读写延迟和吞吐量是我们必须要关注的指标之一。Cassandra 以其高吞吐量、低延迟的特点著称，因此在实际应用中，读写延迟和吞吐量是衡量 Cassandra 集群性能的重要指标。

1.读写延迟

读写延迟是 Cassandra 集群性能的重要指标，如果读写延迟较高，则可能会导致系统响应时间长、节点之间数据同步慢影响数据一致性、节点出现高负载、系统出现瓶颈等问题。因此，保持读写延迟的合理水平是确保 Cassandra 集群高可用和高性能的重要因素之一。如果发现读写延迟较高，运维人员可以通过关注其他监控数据来排查问题。读写延迟的增加可能是由多种因素导致的，例如缓存/布隆过滤器/硬盘占用等。因此，针对不同的问题，可以采取不同的排查和优化措施来提高集群的性能和可用性。

2.吞吐量

读写吞吐量是反映当前 Cassandra 集群每秒处理的读写请求次数的指标，如果吞吐量过高导致节点出现高负载，可能会影响系统的稳定性和可用性。高负载可能会导致节点出现瓶颈，从而影响系统的响应时间和可用性。因此，如果吞吐量过高，运维人员需要引起警惕，并采取有效的措施来缓解负载压力，例如增加节点数量、修改路由策略等。

如果集群性能较强，可以适当提高吞吐量的监控阈值，以反映集群的实际性能水平。这样可以更好地反映 Cassandra 集群的性能和可用性，从而更好地支持业务需求。但需要注意的是，吞吐量的阈值不能过于乐观，需要综合考虑集群的硬件性能、业务需求和系统特点等多个因素，以确保集群的高可用和高性能。

缓存和布隆过滤器

缓存和布隆过滤器能够直接显著影响 Cassandra 数据库的性能。缓存可以提高查询的性能和效率，减少对磁盘的读取次数，从而提高系统的响应速度和吞吐量。如果缓存命中率高，可以显著提高 Cassandra 集群的性能和可用性。布隆过滤器可以降低数据库的查询负载，通过减少不必要的查询请求，提高集群的吞吐量和性能。如果布隆过滤器的误判率低，可以减少查询的操作次数，从而提高集群的性能和可用性。

我们推荐监控 Cassandra 服务中 key cache 命中率以及 Bloom filter 误判率这两项指标。

Key cache 命中率

Key cache 是 Cassandra 中的一种缓存机制，用于存储最常用的数据块和索引数据。当应用程序请求数据时，Cassandra 首先会查找 Key cache，如果数据块或索引数据已经存在于 Key cache 中，则可以直接返回结果，避免了对磁盘的访问。因此，Key cache 的命中率直接反映 Cassandra 集群的性能和效率。如果 Key cache 命中率较低，可能会导致 Cassandra 集群响应时间变长，影响系统的性能和可用性。

Bloom filter 误判率

Bloom filter 是 Cassandra 中用于快速查询数据是否存在的一种数据结构。Bloom filter 虽能快速判断数据是否存在，但会存在误判的情况。Bloom filter 的误判率反映了 Cassandra 集群查询数据的准确性和效率。如果 Bloom filter 误判率较高，可能会导致 Cassandra 集群查询效率下降，从而影响系统的性能和可用性。

异常和错误

异常和错误是 Cassandra 服务中需要监控的核心指标之一，反映了系统的异常情况，例如节点宕机、数据丢失、网络故障等问题。当异常和错误指标非0时，通常意味着系统出现了问题，需要及时排查和解决。例如，如果节点宕机，可能需要重新启动或替换节点，以恢复集群的正常运行。如果数据丢失，可能需要采取数据恢复措施，以确保数据的完整性和可靠性。

在某些情况下，异常和错误指标可能会出现误报或误判的情况。例如，某些异常和错误可能只是暂时的，可以自动恢复，不需要进行手动干预。因此，在分析异常和错误指标时，也需要结合其他指标，例如读写延迟、吞吐量、CPU 和内存使用率等指标，来判断和排查问题。

我们推荐监控异常请求，错误请求、dropped message 三项指标。

异常请求：异常请求指 Cassandra 集群在处理读写请求时出现异常的情况，例如请求超时、请求被拒绝等等。异常请求的出现通常意味着 Cassandra 集群出现了问题，需要及时排查和解决。因此，监控异常请求是确保 Cassandra 集群高可用和高性能的关键指标之一。
错误请求：错误请求指 Cassandra 集群在处理读写请求时出现错误的情况，例如请求的数据不存在、数据类型不匹配等等。错误请求的出现可能会影响 Cassandra 集群的查询效率和准确性，从而影响系统的性能和可用性。因此，监控错误请求也是 Cassandra 集群监控的重要指标之一。
Dropped message：Dropped message 指在 Cassandra 集群间节点之间进行通信时出现丢失消息的情况。Dropped message 的出现通常意味着 Cassandra 集群间通信出现异常，可能会影响集群的可用性和性能。因此，监控 Dropped message 也是 Cassandra 集群监控的重要指标之一。

硬件资源占用

在 Cassandra 监控中，监控 CPU、内存、硬盘和网络的使用情况是比较重要的指标。在这个模块，我们可以深入挖掘这些指标的监控数据，以更好地了解 Cassandra 集群的性能和可用性。

CPU 使用率：CPU 是 Cassandra 集群的计算资源，CPU 使用率反映了集群的计算负载情况。高 CPU 使用率可能会导致集群响应变慢，影响系统的性能和可用性。因此，监控 CPU 使用率是确保 Cassandra 集群高性能和高可用的重要指标之一。
内存使用率：内存是 Cassandra 集群的重要资源，内存使用率反映了集群的内存负载情况。高内存使用率可能会导致集群出现高负载，影响系统的性能和可用性。因此，监控内存使用率也是 Cassandra 集群监控的重要指标之一。
硬盘使用率：硬盘是 Cassandra 集群的存储资源，硬盘使用率反映了集群存储的负载情况。高硬盘使用率可能会导致集群存储压力过大，影响系统性能和可用性。因此，监控硬盘使用率也是 Cassandra 集群监控的重要指标之一。
网络使用率：网络是 Cassandra 集群的通信资源，网络使用率反映了集群节点之间通信的负载情况。高网络使用率可能会导致集群通信异常，影响系统的性能和可用性。因此，监控网络使用率也是 Cassandra 集群监控的重要指标之一。

存储占用

Memtable、SSTable 和 Commit Log 是 Cassandra 服务中存储数据的三部分，各自承担着不同的作用，在Cassandra 读写操作中起到了重要作用，我们推荐对这三部分数据的存储占用情况进行监控。

Memtable 存储占用：对 Memtable 存储占用情况进行监控，可以及时发现集群中写入性能和效率的问题。如果Memtable 存储占用过大，可能会导致写入性能下降，影响系统的性能和可用性。因此，监控 Memtable 存储占用情况能够帮助运维人员及时采取措施，优化集群的写入性能和效率。
SSTable 存储占用：对 SSTable 存储占用情况进行监控，可以及时发现集群中存储容量不足的问题。如果 SSTable 存储占用过大，可能会导致存储容量不足，从而影响系统的性能和可用性。因此，监控 SSTable 存储占用情况能够帮助运维人员及时采取措施，增加集群的存储容量，确保集群的高可用性和高性能。
Commit Log 存储占用：对 Commit Log 存储占用情况进行监控，能够及时发现集群中故障恢复问题。如果 Commit Log 存储占用过大，可能会导致故障恢复时间变长，影响系统的可靠性和稳定性。因此，监控 Commit Log存储占用情况能够帮助运维人员及时采取措施，优化集群的故障恢复能力，确保集群的高可靠性和高可用性。

线程池状态

我们推荐对 Cassandra 的线程池进行监控，分别统计 active task、blocked task 和 pending task 数量进行实时监控。

Active task：Active task 指正在执行中的任务数量。如果 Active task 数量过高，可能会导致线程池过载，影响系统的性能和可用性。
Blocked task：Blocked task 指正在等待获取锁的任务数量。如果 Blocked task 数量过高，可能会导致线程池阻塞，影响系统的性能和可用性。
Pending task：Pending task 指正在等待执行的任务数量。如果 Pending task 数量过高，可能会导致任务积压，影响系统的性能和可用性。

通过监控这三项指标，可以及时发现线程池中的性能问题，从而采取相应的措施，优化线程池的性能和效率。同时，监控线程池也可以帮助运维人员及时发现线程池过载、阻塞和任务积压等问题，从而确保 Cassandra 集群的高可用和高性能。

JVM 监控

Cassandra 作为一个基于 Java 编写的应用，在监控中也需要监控 JVM 相关的三项指标，分别是 JVM 应用吞吐率、JVM 垃圾回收时间和 JVM 内存使用情况。这些指标对于保障 Cassandra 的高可用和高性能非常重要。

JVM 应用吞吐率：JVM 的应用吞吐率是指 JVM 在单位时间内完成的任务数量，也就是吞吐量。高吞吐率表示 JVM 性能较好，反之则表JVM 性能较差。因此，监控 JVM 应用吞吐率可以在J VM 性能下降时及时发现问题，从而采取措施进行优化。
JVM 垃圾回收时间：JVM 垃圾回收时间是指 JVM 在进行垃圾回收时所需要的时间，高垃圾回收时间会导致JVM 性能下降。因此，监控 JVM 垃圾回收时间可以帮助运维人员及时发现垃圾回收过程中的性能问题，从而优化 JVM 性能。
JVM 内存使用情况：JVM 的内存使用情况是指 JVM 在运行过程中所占用的内存大小。如果 JVM 内存使用过高，可能会导致内存溢出，影响系统的性能和可用性。因此，监控JVM的内存使用情况能够帮助运维人员及时发现内存问题，从而采取措施进行优化。

关键告警规则

在对 Cassandra 进行告警规则配置时，我们推荐基于以上采集得到的指标，从以下几个方面进行告警规则的配置，分别是集群健康状态、资源使用情况、读写延迟和吞吐量、异常和错误及 JVM，以下是一些推荐的告警规则。

集群健康状态

我们推荐对集群中 Cassandra 宕机节点的比例进行监控，并根据需要灵活设置阈值。

在设置阈值时，需要考虑到 Cassandra 集群的规模、硬件配置、数据负载以及业务需求等因素。一般来说，如果集群中有多个节点，建议将宕机节点的比例控制在 5% 以下，如果集群规模较小，则可以设置更严格的阈值。但是，需要注意的是，过于严格的阈值可能会导致误报，过于宽松的阈值则可能会导致漏报。因此，在设置阈值时，需要根据实际情况进行调整和优化。

资源使用情况

在资源使用情况中，我们推荐对 Cassandra 集群中各个节点的 CPU、内存以及硬盘使用率配置告警规则：

CPU使用率：建议设置 CPU 使用率的告警阈值，当节点的 CPU 使用率超过阈值时，可以发出告警通知相关人员及时处理，以防止 Cassandra 集群进入不稳定状态甚至出现宕机等问题，以保障 Cassandra 集群的高可用和高性能。
内存使用率：建议设置内存使用率的告警阈值，当节点的内存使用率超过阈值时，可以发出告警通知相关人员及时处理，防止因内存不足导致系统崩溃。
硬盘使用率：建议设置硬盘使用率的告警阈值，当节点的硬盘使用率超过阈值时，可以发出告警通知相关人员及时处理，防止因磁盘空间不足导致数据丢失等问题。

读写延迟和吞吐量

Cassandra 作为一个数据库服务，其读写延迟和吞吐量是极为重要的性能指标，因此都需要配置告警规则。

读写延迟：建议当读写延迟超过一定阈值时触发告警规则。在 Cassandra 集群中，读写延迟是一个非常重要的性能指标，当读写延迟超过一定阈值时，往往会导致应用程序响应变慢，甚至造成数据丢失，因此需要对其进行监控和告警。在设置读写延迟的告警规则时，需要根据实际情况进行调整和优化。一般来说，可以设置较短的阈值，例如1秒或更短的时间。当读写延迟超过设定的阈值时，就会触发告警，通知相关人员及时处理问题。此外，也可以根据业务需求和数据负载进行调整，以便尽可能地满足应用程序的需求。
吞吐量：吞吐量反映了 Cassandra 服务当前单位时间内处理的请求数量，过高的吞吐量可能会导致系统进入不稳定状态，甚至出现宕机的情况。当 Cassandra 集群的吞吐量过高时，会导致系统资源的紧张，例如 CPU、内存和磁盘等资源可能会达到瓶颈，从而影响系统的稳定性和可用性。此外，过高的吞吐量还可能会导致数据的一致性问题，例如因写入冲突而产生的数据丢失等问题。因此，我们建议对 Cassandra 集群的吞吐量设置相应的告警规则，以便及时发现和处理过高的吞吐量问题。在设置告警规则时，需要根据实际情况进行调整和优化，例如根据业务需求和数据负载进行调整，以尽可能地满足应用程序的需求。

异常和错误

当 Cassandra 服务中出现异常和错误时，需要引起警惕。Cassandra 是一个分布式的数据库系统，异常和错误可能会对数据的一致性和可用性造成很大影响，因此需要对其进行监控和处理。

我们推荐对超时请求、失败请求以及 Dropped Message 三种异常和错误情况配置告警规则。这些异常和错误可能会影响 Cassandra 集群的可用性和性能，因此需要对其进行监控和处理。

超时请求：当 Cassandra 服务无法在指定的时间内响应请求时，就会出现超时请求的情况。超时请求可能会导致客户端无法获取所需的数据，影响系统的可用性和性能。因此，我们建议对超时请求进行监控，并设置相应的告警规则，以便及时发现和处理问题。
失败请求：当 Cassandra 服务无法成功完成请求时，就会出现失败请求的情况。失败请求可能会导致数据的不一致性，影响系统的可用性和性能。因此，我们建议对失败请求进行监控，并设置相应的告警规则，以便及时发现和处理问题。
Dropped Message：Cassandra 集群中的消息可能会丢失，例如由于网络问题或节点故障等原因。这些丢失的消息可能会导致数据的不一致性，影响系统的可用性和性能。因此，我们建议对 Dropped Message 进行监控，并设置相应的告警规则，以便及时发现和处理问题。

JVM 相关

我们推荐对 Cassandra 服务中 GC 的时间占比配置告警规则。频繁的 GC 操作可能会对应用程序的性能产生很大影响，因此需要对其进行监控和处理。

在 Cassandra中，GC（Garbage Collection）是一项重要的操作，用于回收无用的内存。当 GC 操作频繁出现时，可能会占用大量的 CPU 时间，影响系统的性能和可用性。因此，我们建议对 Cassandra 服务中 GC 的时间占比进行监控，并设置相应的告警规则，以便及时发现和处理问题。

在设置告警规则时，需要根据实际情况进行调整和优化。一般来说，可以设置较短的 GC 时间占比阈值，例如10%或更短的时间。当 GC 时间占比超过设定的阈值时，就会触发告警，通知相关人员及时处理问题。

监控体系搭建

自建 Prometheus 监控

目前广泛采用的 Cassandra 监控方案主要是基于 JMX 的监控方案。用户可以选择自行编写或者从开源社区选择合适的 Agent，然后在 Cassandra 服务启动时挂载对应的 Agent，实现对 Cassandra 集群的监控。

在挂载了对应的 agent 之后，用户需要在自建的 Prometheus 中注册服务，然后基于 Grafana 等工具定制 Cassandra监控大盘。

上在自建 Cassandra 监控方案中，可能会遇到一些问题和挑战。以下是一些可能会出现的问题和挑战：

社区的 Agent 质量良莠不齐：在开源社区中，有很多 Cassandra 监控 Agent 可供选择。但这些 Agent 质量和性能可能不尽相同。有些 Agent 可能存在 Bug 或性能问题，可能会影响 Cassandra 集群的性能和可用性。
指标缺乏解释：在监控 Cassandra 时，需要监控很多指标。但是，这些指标的含义和解释可能并不清晰，需要运维人员对其进行解释和理解。如果缺乏指标的解释，可能会导致运维人员对 Cassandra 集群的状态和性能理解不全面，无法及时发现问题。
自建的大盘不够专业：在自建 Cassandra 监控大盘时，需要对数据进行处理和可视化。但是，如果缺乏专业的技术和工具，可能会导致自建的大盘不够专业，无法满足运维人员的需求。

为了避免这些问题和挑战，我们推荐使用阿里云可观测监控 Prometheus 版去监控 Cassandra 数据库，真正做到开箱即用，一键集成。