StarRocks 告警体系全解PromSQL 监控规则、告警处置与集群恢复实践【免费下载链接】starrocksThe worlds fastest open query engine for sub-second analytics both on and off the data lakehouse. With the flexibility to support nearly any scenario, StarRocks provides best-in-class performance for multi-dimensional analytics, real-time analytics, and ad-hoc queries. A Linux Foundation project.项目地址: https://gitcode.com/GitHub_Trending/st/starrocks本指南基于 StarRocks 官方运维文档系统讲解 StarRocks 集群在生产环境中的告警体系从业务连续性、集群可用性、机器负载三个维度给出可直接落地的 PromSQL 监控规则并为每条告警提供完整的定位手段与处置方案。读完本文你将掌握 FE/BE 服务中断、机器资源、Compaction、CheckPoint、导入与查询异常等十余类核心告警的配置方法与应急恢复流程并能在源码层面理解关键动态参数的生效机制。:::note 变量约定 本文所有示例中的变量均以$前缀标识使用前请根据业务环境替换例如$job_name应替换为 Prometheus 配置中对应的 Job Name$fe_leader应替换为 Leader FE 的 IP 地址。 :::服务中断告警Service Suspension服务中断直接决定集群的可用性应作为最高优先级告警对待。FE 服务中断PromSQLcount(up{groupfe, job$job_name}) 3告警说明当活跃 FE 节点数低于设定值时触发告警。阈值可根据集群实际 FE 节点数量调整例如三 FE 集群可设为 3一旦任一 FE 失联即告警。处置方案尝试重启挂起的 FE 节点。重启前建议先确认节点进程状态与网络连通性避免误判。BE 服务中断PromSQLnode_info{typebe_node_num, job$job_name,statedead} 1告警说明当超过一个 BE 节点处于 dead 状态时触发告警单副本异常通常可被系统内部容忍双节点异常意味着数据可用性风险显著上升。处置方案尝试重启挂起的 BE 节点并观察SHOW BACKENDS中该节点的Alive状态是否恢复。机器负载告警Machine Load机器负载异常往往是大查询、高频导入或资源扩容的前兆需要结合资源使用与业务变化综合判断。BE CPU 告警PromSQL(1-(sum(rate(starrocks_be_cpu{modeidle, job$job_name,instance~.*}[5m])) by (job, instance)) / (sum(rate(starrocks_be_cpu{job$job_name,host~.*}[5m])) by (job, instance))) * 100 90告警说明当 BE 节点 CPU 利用率超过 90% 时触发告警。公式基于 5 分钟窗口内 idle 与总 CPU 时间的变化率计算利用率可平滑瞬时抖动。处置方案检查是否存在大查询或大规模数据导入并将细节反馈给技术支持团队进一步调查使用top命令按线程查看进程资源占用top -Hp $be_pid使用perf命令采集并分析性能数据# 执行 1-2 分钟后按 CTRLC 终止 sudo perf top -p $be_pid -g /tmp/perf.txt:::note 紧急处理 在紧急情况下BE 节点 CPU 利用率持续异常偏高且无有效手段降低 CPU 使用可在保留堆栈stack后尝试重启对应 BE 节点以快速恢复服务。 :::内存告警PromSQL(1-node_memory_MemAvailable_bytes{instance~.*}/node_memory_MemTotal_bytes{instance~.*})*100 90告警说明当节点内存使用率超过 90% 时触发告警。该指标为操作系统级别node_exporter覆盖 BE 进程内存、Page Cache 及同机部署的其他服务。处置方案参考获取 Heap Profile 的方法进行排查。FE 侧 JVM 内存问题可结合下文「High FE JVM Usage Alert」章节的jmap手段定位。:::note 紧急处理紧急情况下可尝试重启对应 BE 服务以恢复这里的紧急指 BE 节点内存使用持续异常偏高、且无有效手段降低内存占用。若同机混合部署的其他服务影响系统可考虑在紧急情况下先终止这些服务。 :::磁盘告警磁盘负载告警PromSQLrate(node_disk_io_time_seconds_total{instance~.*}[1m]) * 100 90告警说明当磁盘负载超过 90% 时触发告警反映磁盘 I/O 等待与繁忙程度。处置方案若集群触发node_disk_io_time_seconds_total告警首先检查是否有业务变更如有考虑回滚变更以维持原有的资源平衡。若未发现变更或无法回滚需评估是否因正常业务增长需要扩容资源。可使用iotop工具分析磁盘 I/O 占用情况——其界面与top类似包含pid、user及 I/O 信息。此外还可以通过以下 SQL 定位消耗显著 I/O 的 Tablet并回溯到具体任务与表-- all 表示所有服务10 表示采集持续 10 秒3 表示取 Top 3 结果 ADMIN EXECUTE ON $backend_id System.print(ExecEnv.io_profile_and_get_topn_stats(all, 10, 3));根路径容量告警PromSQLnode_filesystem_free_bytes{mountpoint/} /1024/1024/1024 5告警说明当根目录可用空间不足 5GB 时触发告警。处置方案常见的占用空间较大的目录包括/var、/opt与/tmp。使用以下命令检查大文件并清理不必要的内容du -sh / --max-depth1数据盘容量告警PromSQL(SUM(starrocks_be_disks_total_capacity{job$job}) by (host, path) - SUM(starrocks_be_disks_avail_capacity{job$job}) by (host, path)) / SUM(starrocks_be_disks_total_capacity{job$job}) by (host, path) * 100 90告警说明当 BE 数据盘容量利用率超过 90% 时触发告警。该指标直接来自 BE 节点上报的磁盘容量starrocks_be_disks_total_capacity/starrocks_be_disks_avail_capacity按host与path维度聚合。处置方案检查加载数据量是否有变化在 Grafana 中监控load_bytes指标。若数据加载量显著增加可能需要扩容系统资源。检查是否存在 DROP 操作若数据加载量变化不大执行SHOW BACKENDS。若其报告的磁盘用量与实际不符检查 FE Audit Log 中近期是否有 DROP DATABASE、TABLE 或 PARTITION 操作。DROP 操作的元数据会在 FE 内存中保留一天可在 24 小时内通过RECOVER语句恢复数据以避免误操作恢复后实际磁盘占用可能超过SHOW BACKENDS显示的值。删除数据在内存中的保留期可通过 FE 动态参数catalog_trash_expire_second调整默认值 86400 秒ADMIN SET FRONTEND CONFIG (catalog_trash_expire_second86400);该配置定义于 Config.javapublic static long catalog_trash_expire_second 86400L;。如需持久化请将该配置项写入 FE 配置文件fe.conf。此后删除的数据会被移动到 BE 节点的trash目录$storage_root_path/trash默认保留一天这也可能导致实际磁盘占用超过SHOW BACKENDS显示的值。trash 目录中已删除数据的保留时间可通过 BE 动态参数trash_file_expire_time_sec调整默认值 86400 秒定义于 config.hcurl http://$be_ip:$be_http_port/api/update_config?trash_file_expire_time_sec86400FE 元数据盘容量告警PromSQLnode_filesystem_free_bytes{mountpoint${meta_path}} /1024/1024/1024 10告警说明当 FE 元数据所在磁盘可用空间不足 10GB 时触发告警。元数据路径由fe.conf中的meta_dir配置指定。处置方案使用以下命令检查占用大量空间的目录并清理不必要文件du -sh /${meta_dir} --max-depth1若元数据目录占用空间较大通常是因为bdb目录过大可能与 CheckPoint 失败有关。可参考下文 CheckPoint 失败告警 排查若该方法无法解决请联系技术支持团队。集群服务异常告警Cluster Service ExceptionCompaction 告警Cumulative/Base Compaction 失败告警PromSQLincrease(starrocks_be_engine_requests_total{job$job_name ,statusfailed,typecumulative_compaction}[1m]) 3 increase(starrocks_be_engine_requests_total{job$job_name ,statusfailed,typebase_compaction}[1m]) 3告警说明当最近一分钟内 Cumulative Compaction 或 Base Compaction 失败达到 3 次时触发告警。starrocks_be_engine_requests_total是 BE 引擎层请求计数指标按status与type维度区分。处置方案在对应 BE 节点的日志中搜索以下关键字定位涉及的 Tabletgrep -E compaction be.INFO | grep failed如下日志记录表示一次 Compaction 失败W0924 17:52:56:537041 123639 comaction_task_cpp:193] compaction task:8482. tablet:8423674 failed.可通过日志上下文分析失败原因。通常失败可能由 Compaction 过程中的 DROP TABLE 或 PARTITION 操作引起。系统对 Compaction 有内部重试机制你也可以手动将 Tablet 状态置为 BAD 以触发 Clone 任务修复:::note 前置条件 执行以下操作前请确保表至少有三个完整副本。 :::ADMIN SET REPLICA STATUS PROPERTIES(tablet_id $tablet_id, backend_id $backend_id, status bad);高 Compaction 压力告警PromSQLstarrocks_fe_max_tablet_compaction_score{job$job_name,instance$fe_leader} 100告警说明当最高 Compaction Score 超过 100 时触发告警表示 Compaction 压力较高。处置方案该告警通常由高频导入、INSERT INTO VALUES或DELETE操作约每秒 1 次引起。建议将导入或 DELETE 任务的间隔设置为 5 秒以上并避免提交高并发 DELETE 任务。版本数超限告警PromSQLstarrocks_be_max_tablet_rowset_num{job$job_name} 700告警说明当 BE 节点上某个 Tablet 的数据版本Rowset数超过 700 时触发告警。数据版本堆积会显著影响查询性能与 Compaction 效率。处置方案使用以下命令定位版本数过多的 TabletSELECT BE_ID,TABLET_ID FROM information_schema.be_tablets WHERE NUM_ROWSET700;以 Tablet ID2889156为例SHOW TABLET 2889156;执行返回结果中DetailCmd字段给出的命令SHOW PROC /dbs/2601148/2889154/partitions/2889153/2889155/2889156;正常情况下如上图所示三个副本均应为NORMAL状态且RowCount、DataSize等指标保持一致。仅一个副本超过 700 版本限制可基于其他副本触发 Clone 任务修复ADMIN SET REPLICA STATUS PROPERTIES(tablet_id $tablet_id, backend_id $backend_id, status bad);两个及以上副本超过版本限制可临时调高版本数上限# 将 be_ip 替换为存储超限 Tablet 的 BE 节点 IP # 默认 be_http_port 为 8040 # tablet_max_versions 默认值为 1000 curl -XPOST http://$be_ip:$be_http_port/api/update_config?tablet_max_versions2000tablet_max_versions在 config.h 中定义为CONF_mInt16(tablet_max_versions, 1000)。CheckPoint 失败告警PromSQLstarrocks_fe_meta_log_count{job$job_name,instance$fe_master} 100000告警说明当 FE 节点的 BDB 日志数超过 100,000 时触发告警。默认情况下系统在 BDB 日志数超过 50,000 时执行一次 CheckPoint并将计数重置为 0。处置方案该告警说明 CheckPoint 未被执行需要检查 FE 日志分析 CheckPoint 过程在 Leader FE 节点的fe.log中搜索begin to generate new image: image.xxxx记录若找到则说明系统已开始生成新镜像。继续检查日志中是否有checkpoint finished save image.xxxx以确认镜像创建成功。若发现Exception when generate new image file说明镜像生成失败应根据具体错误谨慎处理元数据建议联系技术支持团队进一步分析。FE 线程数过多告警PromSQLstarrocks_fe_thread_pool{job$job_name, type!completed_task_count} 3000告警说明当 FE 线程数超过 3000 时触发告警。处置方案FE 与 BE 节点的默认线程数上限为 4096FE 侧对应thrift_server_max_worker_threads定义于 Config.java默认 4096。大量 UNION ALL 查询通常会导致线程数过多建议降低 UNION ALL 查询并发度并调整系统变量pipeline_dop。若无法调整 SQL 查询粒度可全局调整pipeline_dopSET GLOBAL pipeline_dop8;:::note 紧急处理 紧急情况下为快速恢复服务可调大 FE 动态参数thrift_server_max_worker_threads默认值 4096ADMIN SET FRONTEND CONFIG (thrift_server_max_worker_threads8192);:::FE JVM 使用率过高告警PromSQLsum(jvm_heap_size_bytes{job$job_name, typeused}) * 100 / sum(jvm_heap_size_bytes{job$job_name, typemax}) 90告警说明当 FE 节点 JVM 堆使用率超过 90% 时触发告警。处置方案该告警表明 JVM 使用率过高可使用jmap命令分析# 注意命令中指定 live 可能导致 FE 重启 jmap -histo[:live] $fe_pid jmap.dump由于该指标的详细监控信息仍在开发中直接洞察有限建议执行上述操作后将结果发送给技术支持团队分析。:::note 紧急处理 紧急情况下可重启对应 FE 节点或调大 JVMXmx大小后重启 FE 服务。 :::服务可用性告警Service Availability导入异常告警导入失败告警PromSQLrate(starrocks_fe_txn_failed{job$job_name,instance$fe_master}[5m]) * 100 5告警说明当导入事务失败数占总导入事务数的比例超过 5% 时触发告警。处置方案检查 Leader FE 节点日志搜索关键字status: ABORTED定位失败的导入任务2024-04-09 18:34:02.36308:00 INFO (thrift-server-pool-8845163|12111749) [DatabaseTransactionMgr.abortTransaction():1279] transaction:[TransactionState. txn_id: 7398864, label: 967009-2f20a55e-368d-48cf-833a-762cf1fe07c5, db id: 10139, table id list: 155532, callback id: 967009, coordinator: FE: 192.168.2.1, transaction status: ABORTED, error replicas num: 0, replica ids: , prepare time: 1712658795053, commit time: -1, finish time: 1712658842360, total cost: 47307ms, reason: [E1008]Reached timeout30000ms 192.168.1.1:8060 attachment: RLTaskTxnCommitAttachment [filteredRows0, loadedRows0, unselectedRows0, receivedBytes1033110486, taskExecutionTimeMs0, taskIdTUniqueId(hi:3395895943098091727, lo:-8990743770681178171), jobId967009, progressKafkaProgress [partitionIdToOffset2_1211970882|7_1211893755]]] successfully rollback上述日志中reason: [E1008]Reached timeout30000ms说明事务因写入超时被回滚。Routine Load 消费延迟告警PromSQL(sum by (job_name)(starrocks_fe_routine_load_max_lag_of_partition{job$job_name,instance$fe_mater})) 300000 starrocks_fe_routine_load_jobs{job$job_name,host$fe_mater,stateNEED_SCHEDULE} 3 starrocks_fe_routine_load_jobs{job$job_name,host$fe_mater,statePAUSED} 0 starrocks_fe_routine_load_jobs{job$job_name,host$fe_mater,stateUNSTABLE} 0告警说明当消费延迟超过 300,000 条时触发告警当待调度的 Routine Load 任务数超过 3 时触发告警当存在PAUSED状态任务时触发告警当存在UNSTABLE状态任务时触发告警。处置方案首先检查 Routine Load 任务状态是否为RUNNINGSHOW ROUTINE LOAD FROM $db;重点关注返回数据中的State字段。若有任务处于PAUSED状态检查ReasonOfStateChanged、ErrorLogUrls和TrackingSQL字段。通常执行TrackingSQL中的 SQL 即可定位具体错误若任务状态为RUNNING可尝试提高任务并发度。单个 Routine Load 任务的并发度由以下四个参数的最小值决定kafka_partition_numKafka Topic 的分区数desired_concurrent_number任务设置的并发度alive_be_num存活 BE 节点数max_routine_load_task_concurrent_numFE 配置参数默认值为 5定义于 Config.java。多数情况下需要调整任务并发度或 Kafka Topic 分区数必要时可联系 Kafka 运维支持。以下示例展示如何为任务设置并发度ALTER ROUTINE LOAD FOR ${routine_load_jobname} PROPERTIES ( desired_concurrent_number 5 );单数据库导入事务数超限告警PromSQLsum(starrocks_fe_txn_running{job$job_name}) by(db) 900告警说明当单个数据库的导入事务数超过 900 时触发告警v3.1 之前的版本阈值为 100。处置方案该告警通常由大量新增导入任务触发可临时调高单数据库导入事务数上限max_running_txn_num_per_db默认值为 1000见 Config.javaADMIN SET FRONTEND CONFIG (max_running_txn_num_per_db 2000);查询异常告警查询延迟告警PromSQLstarrocks_fe_query_latency_ms{job$job_name, quantile0.95} 5000告警说明当 P95 查询延迟超过 5 秒时触发告警。处置方案排查是否存在大查询检查异常期间是否有大查询消耗大量机器资源导致其他查询超时或失败。执行show proc /current_queries;查看大查询的QueryId。若需快速恢复服务可使用KILL命令终止长时间运行的查询mysql SHOW PROC /current_queries; --------------------------------------------------------------------------------------------------------------------------------------------- | QueryId | ConnectionId | Database | User | ScanBytes | ProcessRows | CPUCostSeconds | MemoryUsageBytes | ExecTime | --------------------------------------------------------------------------------------------------------------------------------------------- | 7c56495f-ae8b-11ed-8ebf-00163e00accc | 4 | tpcds_100g | root | 37.88 MB | 1075769 Rows | 11.13 Seconds | 146.70 MB | 3804 | | 7d543160-ae8b-11ed-8ebf-00163e00accc | 6 | tpcds_100g | root | 13.02 GB | 487873176 Rows | 81.23 Seconds | 6.37 GB | 2090 | --------------------------------------------------------------------------------------------------------------------------------------------- 2 rows in set (0.01 sec)从输出可以看到ScanBytes、ProcessRows、CPUCostSeconds、MemoryUsageBytes等字段可据此识别资源消耗大户。也可以重启 CPU 利用率较高的 BE 节点来解决问题。检查机器资源是否充足验证异常期间 CPU、内存、磁盘 I/O 和网络流量是否正常。若发现异常通过峰值流量变化与集群资源使用情况排查根因若问题持续可考虑重启受影响的节点。:::note 紧急处理若突发流量峰值导致资源过度使用和查询失败可降低业务流量并重启受影响的 BE 节点若高资源使用源于正常业务运行则考虑扩容节点。 :::查询失败告警PromSQLsum by (job,instance)(starrocks_fe_query_err_rate{job$job_name}) * 100 10 # 以下 PromSQL 自 v3.1.15、v3.2.11、v3.3.3 起支持 increase(starrocks_fe_query_internal_err{job$job_name})[1m] 10告警说明当查询失败率超过 0.1/秒或一分钟内失败查询数超过 10 时触发告警。处置方案告警触发时检查日志定位失败的查询grep StateERR fe.audit.log若已安装 AuditLoader 插件可通过以下查询定位对应查询SELECT stmt FROM starrocks_audit_db__.starrocks_audit_tbl__ WHERE stateERR;注意因语法错误或超时失败的查询同样会计入starrocks_fe_query_err_rate。对于内核问题导致的查询失败在fe.log中搜索错误信息获取完整堆栈与 Query Dump并联系技术支持团队排查。查询过载告警PromSQLabs((sum by (exported_job)(rate(starrocks_fe_query_total{processFE,job$job_name}[3m]))-sum by (exported_job)(rate(starrocks_fe_query_total{processFE,job$job_name}[3m] offset 1m)))/sum by (exported_job)(rate(starrocks_fe_query_total{processFE,job$job_name}[3m]))) * 100 100 abs((sum(starrocks_fe_connection_total{job$job_name})-sum(starrocks_fe_connection_total{job$job_name} offset 3m))/sum(starrocks_fe_connection_total{job$job_name})) * 100 100告警说明当 QPS 或连接数在最近一分钟内增长 100% 时触发告警。第一条规则通过对比 3 分钟窗口内查询速率与 1 分钟前的偏移值检测查询量突增第二条规则类似地检测连接数突增。处置方案检查fe.audit.log中的高频查询是否符合预期。若业务行为确有合理变化例如新服务上线或数据量增长监控机器负载并按需扩容 BE 节点。用户连接数超限告警PromSQLsum(starrocks_fe_connection_total{job$job_name}) by(user) 90告警说明当单个用户的连接数超过 90 时触发告警。用户连接数限制自 v3.1.16、v3.2.12、v3.3.4 起支持。处置方案使用SHOW PROCESSLIST检查当前连接数是否符合预期可用KILL命令终止异常连接。同时确保前端服务不过长地持有连接可考虑调整系统变量wait_timeout单位秒以加快系统自动终止空闲连接SET wait_timeout 3600;:::note 紧急处理 紧急情况下可临时调高用户连接上限以恢复服务对于 v3.1.16、v3.2.12、v3.3.4 及之后版本ALTER USER jack SET PROPERTIES (max_user_connections 1000);对于 v2.5 及更早版本SET PROPERTY FOR jack max_user_connections 1000;:::Schema Change 异常告警PromSQLincrease(starrocks_be_engine_requests_total{job$job_name,typeschema_change, statusfailed}[1m]) 1告警说明当最近一分钟内 Schema Change 任务失败数超过 1 时触发告警。处置方案执行以下语句检查Msg字段是否包含错误信息SHOW ALTER COLUMN FROM $db;若未发现消息在 Leader FE 日志中搜索上一步得到的 JobId 获取上下文。Schema Change 内存不足若 Schema Change 因内存不足失败在be.WARNING日志中搜索failed to process the version、failed to process the schema change from tablet或Memory of schema change task exceeded limitfail to execute schema change: Memory of schema change task exceed limit. DirectSchemaChange Used: 2149621304, Limit: 2147483648. You can change the limit by modify BE config [memory_limitation_per_thread_for_schema_change]该内存限制错误通常由单个 Schema Change 超过 2GB 内存限制引起该限制由 BE 动态参数memory_limitation_per_thread_for_schema_change控制定义于 config.h单位为 GB默认值 2可通过修改该参数解决curl -XPOST http://be_host:http_port/api/update_config?memory_limitation_per_thread_for_schema_change8Schema Change 超时除加列轻量实现外大多数 Schema Change 会创建大量新 Tablet、重写原始数据并通过 SWAP 方式实现Create replicas failed. Error: Error replicas:2153995399583471, 2153995399583467, 2153995399599851可通过以下方式解决调大创建 Tablet 的超时时间默认 10 秒见 Config.java 中tablet_create_timeout_secondADMIN SET FRONTEND CONFIG (tablet_create_timeout_second60);增加创建 Tablet 的线程数默认 3见 config.h 中alter_tablet_worker_countcurl -XPOST http://be_host:http_port/api/update_config?alter_tablet_worker_count6副本状态非正常Non-Normal Tablet若 Tablet 处于非正常状态在be.WARNING日志中搜索tablet is not normal并执行SHOW PROC /statistic查看集群级UnhealthyTabletNumSHOW PROC /statistic;执行SHOW PROC /statistic/$DbId查看指定数据库中的非健康 Tablet 数。执行SHOW TABLET $tablet_id查看对应 Tablet 的表信息。执行返回结果中DetailCmd字段给出的命令定位非健康 Tablet 的原因。通常非健康及不一致副本由高频导入引起——不同副本的写入进度不同步所致。可检查表是否有大量实时写入通过降低导入频率或暂停服务后重试任务来减少异常副本数量。:::note 紧急处理 紧急情况下可将非 Normal 副本置为 Bad 以触发 Clone 任务ADMIN SET REPLICA STATUS PROPERTIES(tablet_id $tablet_id, backend_id $backend_id, status bad);执行前请确保表至少有三个完整副本且仅有一个副本非正常。 :::物化视图刷新异常告警PromSQLincrease(starrocks_fe_mv_refresh_total_failed_jobs[5m]) 0告警说明当最近五分钟内物化视图刷新失败数超过 1 时触发告警。处置方案检查刷新失败的物化视图SELECT TABLE_NAME,IS_ACTIVE,INACTIVE_REASON,TASK_NAME FROM information_schema.materialized_views WHERE LAST_REFRESH_STATE ! SUCCESS;尝试手动刷新物化视图REFRESH MATERIALIZED VIEW $mv_name;若物化视图处于INACTIVE状态尝试手动激活ALTER MATERIALIZED VIEW $mv_name ACTIVE;排查刷新失败原因SELECT * FROM information_schema.task_runs WHERE task_name mv-112517 \G告警体系落地建议将上述 PromSQL 规则接入 Prometheus Alertmanager 时建议遵循以下几点统一标签所有规则中的$job_name、$fe_leader/$fe_master等变量保持一致便于按环境维度聚合与路由告警。分级处理服务中断类FE/BE Suspension建议设为最高优先级并配置即时通知容量类磁盘、内存可设置较长的评估窗口以减少误报业务可用性类导入失败、查询失败建议结合业务窗口区分告警时段。动态参数与持久化本文中通过ADMIN SET FRONTEND CONFIG、curl .../api/update_config修改的参数均为动态生效但重启后丢失。生产环境应将关键参数同时写入fe.conf与be.conf以持久化并记录变更前后基线以便回滚。组合排查多个告警往往同源——例如磁盘容量告警常伴随 Compaction 失败与版本数超限查询延迟告警常伴随 CPU 告警。定位时优先从资源层向业务层回溯可显著缩短故障恢复时间MTTR。【免费下载链接】starrocksThe worlds fastest open query engine for sub-second analytics both on and off the data lakehouse. With the flexibility to support nearly any scenario, StarRocks provides best-in-class performance for multi-dimensional analytics, real-time analytics, and ad-hoc queries. A Linux Foundation project.项目地址: https://gitcode.com/GitHub_Trending/st/starrocks创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考