首页 文章 精选 留言 我的

精选列表

搜索[原生统一]，共10000篇文章
优秀的个人博客,低调大师

为什么企业级AI落地需要统一的Agent Identity？

企业最早接入AI时，信任问题相对简单。员工让AI写一段材料、整理一份纪要、生成一份报告，企业主要关心的是内容对不对、表达是否合规、有没有泄露敏感信息。这个阶段，AI更像一个内容助手，风险大多停留在输出层面。Agent出现之后，AI开始从内容辅助进入执行链路，企业要面对的就不再只是输出质量。一个Agent不只是回答问题，它会理解任务、调用工具、访问系统、读取数据，甚至推动流程继续往下走。它可能查询CRM里的客户资料，读取知识库里的内部制度，调用OA提交审批，或者把处理结果写回业务系统。到了这个阶段，企业关注的重点会从“它能做什么”，转向“它是否值得被信任”。这里的信任不是一句主观判断，而是一个工程问题。系统必须知道这个Agent是谁，属于哪个组织，代表谁在执行任务，当前交互来自哪里，执行过程能不能被记录和复盘。如果这些问题没有答案，Agent就很难进入生产系统。
2026-07-14
优秀的个人博客,低调大师

AI 和分析统一数据库 Cloudberry Database 1.5.0 发布

近日，Cloudberry Database v1.5.0 正式发布，本次新版本新增了若干功能，同时包含了若干产品性能/稳定性优化，修复了若干 bug。 快速下载试用：Cloudberry Database 1.5.0 新功能​ 分类 功能 查询处理 支持并行创建 AO/AOCO 表和并行刷新物化视图 支持自动使用物化视图进行查询优化 支持部署单计算节点的集群 支持使用命令行“一键”部署集群 存储 支持增量物化视图 支持在 AO 表上使用唯一索引 安全 支持登录错误输入密码次数检查 各个新功能的详细说明如下： 查询处理​ 支持并行创建 AO/AOCO 表和并行刷新物化视图。 支持使用CREATE TABLE AS语句并行创建 Append-Optimized (AO) 表和 Append-Optimized Column Oriented (AOCO) 表，同时支持并行刷新基于该表的物化视图，从而加速建表和物化视图刷新。 支持自动使用物化视图进行查询优化，即在查询规划阶段自动使用物化视图来计算部分或全部查询 (AQUMV)。这一功能使用场景： 大数据量的聚合查询：对于需要从数百万条记录中进行聚合的查询，AQUMV 能显著减少查询时间。 频繁更新的大表：在数据频繁更新的环境中，使用 IMV 可以确保查询结果的实时性和准确性。 集群管理​ 支持以单计算节点部署集群。 在 v1.5.0 以前，用户部署一套 Cloudberry Database 集群时，至少需要部署一个 Coordinator 节点和一个 Segment 节点，还需要指定繁多的配置信息和启动参数，这一过程相对复杂耗时。 从 v1.5.0 开始，用户可以像部署 PostgreSQL 一样部署单计算节点的 Cloudberry Database 集群，集群仅包含一个 Coordinator 节点，无需指定繁多的配置参数，也无需预分配多个节点的计算资源。 用户只需使用脚本工具gpdemo即可快速部署一套单节点的 Cloudberry Database 集群。 支持使用命令行工具“一键”部署集群。 在 v1.5.0 以前，如果用户想在单节点上部署带有 Segment 的小型集群用于演示，需要花费时间编写配置文件和参数。自 v1.5.0 起，用户只需要通过内置的gpdemo脚本，使用一条命令就能快速部署指定 Segment 数的 Cloudberry Database 集群。即： gpdemo 存储​ 支持增量物化视图。 增量物化视图是物化视图的一种特殊形式。当数据在基础表中发生变化时（例如插入、更新、删除操作），增量物化视图不需要重新计算整个视图中的所有数据。相反，它只更新那些自上次刷新以来发生变化的部分。这样可以节省大量的计算资源和时间，显著提高性能，尤其是在处理大型数据集时。 自 v1.5.0 起，如果查询时有中间结果集需要加速，或者在读多写少的场景下，用户可以使用增量物化视图来加速查询。 在 AO 表上使用唯一索引。 自 v1.5.0 起，你可以在 Cloudberry Database 的 Append-Optimized (AO) 或 Append-Optimized Column Store (AOCS) 表上添加唯一索引。有了唯一索引，Cloudberry Database 会在将数据插入到 AO 表时，强制检查唯一性约束，从而保证数据的唯一性，同时能够与优化器一起优化特定的查询，从而提高数据库的查询性能。但这也带来的一定的开销用于维护唯一索引，尤其是在插入数据时。 安全​ 支持创建和绑定数据库的用户密码策略配置。 Profile，即密码策略配置，用于控制数据库中用户的密码安全策略。Profile 定义了用户管理和重复使用密码的规则。通过配置 Profile，数据库管理员可以使用 SQL 语句强制添加一些约束，例如在一定次数的登录失败后锁定账户，或者控制密码重复使用次数。 自 v1.5.0 起，Cloudberry Database 支持通过 SQL 语句创建 Profile，并将 Profile 绑定到一个或多个用户中，从而控制数据库用户的密码安全策略。 变更说明​ SQL 语法变更说明​ CREATE MATERIALIZED VIEW新支持INCREMENTAL选项。你可以使用 SQL 命令CREATE INCREMENTAL MATERIALIZED VIEW来创建增量物化视图。完整的语法支持如下： CREATE [INCREMENTAL] MATERIALIZED VIEW [ IF NOT EXISTS ] table_name [ (column_name [, ...] ) ] [ USING method ] [ WITH ( storage_parameter [= value] [, ... ] ) ] [ TABLESPACE tablespace_name ] AS query [ WITH [ NO ] DATA ] 功能变更说明​ 无 参数变更说明​ 无 Bug 修复​ 修复了 AOCO 表内存越界的问题。该 Bug 导致的报错如下所示： SET default_table_access_method=ao_column; CREATE temp TABLE nocolumns(); SELECT EXISTS(SELECT * FROM nocolumns); WARNING: detected write past chunk end in ExecutorState 0x8f79b78 (seg0 slice1 127.0.1.1:7002 pid=16215) 修复了使用EXPLAIN查看查询计划时，输出结果中的operatorMem对齐问题，修复前显示如下： SET gp_resqueue_print_operator_memory_limits=ON; EXPLAIN(COSTS OFF) SELECT COUNT(*) FROM test_hj_spill; QUERY PLAN ---------------------------------------------------------------------------- Finalize AggregateoperatorMem: 100 kB -> Gather Motion 3:1 (slice1; segments: 3)operatorMem: 100 kB -> Partial AggregateoperatorMem: 100 kB -> Seq Scan on test_hj_spilloperatorMem: 100 kB 修复了在特定条件下导致快照功能内存异常的问题，这个问题可能会在某些情况下使事务处理过程中发生 core dump。 改进了并行扫描操作时，并行哈希连接中内部表格大小的估算精度。 并行扫描时新增对 Semi HashJoin 类型的支持。 改进了NOT IN语句的处理逻辑，现在它可以正确地处理包含NULL值的情况。例如，在执行像SELECT c1 FROM t1_lasj WHERE c1 NOT IN (SELECT c1n FROM t2_lasj_has_null WHERE c1n IS NULL OR c1n IS NULL);这样的查询时，将得到正确的结果。 修复了在 macOS 上编译运行遇到的问题。 修复了CREATE EXTENSION时，用户的search_path发生变更的问题。
2024-03-18
优秀的个人博客,低调大师

统一观测丨使用 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 数据库，真正做到开箱即用，一键集成。 可观测监控 Prometheus 版 目前仅 Prometheus 实例 for ECS 类型实例支持该组件接入，用户需要将 VPC 实例接入可观测监控 Prometheus 版。具体操作，请参见 Prometheus实例 for ECS。 Prometheus实例 for ECS：https://help.aliyun.com/document_detail/274450.htm#concept-1062555 登录 Prometheus 控制台。在页面左上角选择目标地域，选择 VPC 的 Prometheus 监控实例，在集成中心点击 Cassandra 组件的安装。 根据提示完成组件的安装步骤，在安装过程中需要用户自行下载和部署 JMX Agent（已提供 Agent 的下载链接）。 阿里云提供的 Cassandra 监控中采集了大量的指标，用户点击 Cassandra 卡片之后可以查看。 此外，提供了专业的大盘和内置的告警规则，来达到开箱即用的目的。 参考链接： [1]https://www.cloudwalker.io/2020/05/17/monitoring-Cassandra-with-prometheus/ [2]https://www.datadoghq.com/blog/how-to-monitor-Cassandra-performance-metrics/ [3]https://www.datadoghq.com/blog/how-to-collect-Cassandra-metrics/ [4]https://docs.datadoghq.com/integrations/Cassandra/ [5]https://www.jianshu.com/p/cc619b5bccf6 [6]https://www.jianshu.com/p/684a4a1715e4 [7]https://www.jianshu.com/p/8cf836a55a68 点击此处，了解更多产品详情
2023-07-23

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

时间: 2026-04-11 大小: 211.28KB 下载: 56次
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

时间: 2026-08-21 大小: 1MB 下载: 10次
Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

时间: 2026-09-24 大小: 189MB 下载: 9次
WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源，继承了IntelliJ IDEA强大的JS部分的功能。

时间: 2025-12-13 大小: 249.54MB 下载: 22次
热门标签
DeepSeek Jdk25 OpenAi HarmonyOS6 Nacos3 SpringBoot4 SpringCloud Docker Kubernetes Service Mesh Redis Gemini3 Rocky

欢迎您来访！

登录后，您将获得更多功能！
热门文章
联系我们

有任何问题或合作意向欢迎联系我们

Email: 99873273@qq.com

QQ: 99873273

用户登录
用户注册