4. Doris/StarRocks 核心监控指标：FE 与 BE 关键指标

各位同学，咱们今天聊点实在的。Doris 和 StarRocks 跑起来之后，你盯着屏幕看什么呢？很多人一上来就去看 SQL 跑得快不快，其实这是结果，不是原因。我个人的习惯是，先看 FE，再看 BE，最后才看查询。顺序搞反了，排查问题就像没头苍蝇。

说白了，FE 是大脑，BE 是手脚。大脑乱了，手脚再快也没用。反过来，手脚疼了，大脑也指挥不动。咱们得把这两层的核心指标拆开揉碎了讲清楚。

4.1 FE 关键指标：大脑不能乱

FE 的监控，我重点关注两个方向：一个是查询计划耗时，一个是元数据操作。这两个要是出问题，整个集群基本就瘫了。

4.1.1 查询计划耗时

你想想看，一个 SQL 进来，FE 要先解析、生成逻辑计划、优化、再生成物理计划。这个过程如果超过 1 秒，那说明 FE 的 CPU 或者内存已经吃紧了。

我建议你盯住这几个指标：

• query_plan_cost_ms：单次查询计划生成耗时。超过 500ms 就要警惕。
• fe_plan_queue_size：等待生成计划的查询数。队列越长，说明 FE 处理不过来。
• fe_cpu_utilization：FE 进程的 CPU 使用率。超过 80% 持续 5 分钟，基本就是瓶颈了。

4.1.2 元数据操作

元数据操作是 FE 的核心职责之一。建表、删表、修改 Schema、创建分区，这些操作都会产生元数据事务。如果元数据操作堆积，整个集群的 DDL 都会卡住。

关键指标：

指标名称	正常范围	告警阈值
meta_log_count	< 1000	> 5000
meta_write_latency_ms	< 50ms	> 200ms
pending_meta_tasks	0	> 10

4.2 BE 关键指标：手脚要利索

BE 的指标就多了。我把它分成三个维度：Tablet 分布、Compaction 压力、数据导入速率。这三个维度基本能覆盖 BE 90% 的问题。

4.2.1 Tablet 分布

Tablet 是数据存储的最小单元。如果 Tablet 分布不均匀，就会出现数据倾斜。有的 BE 节点忙死，有的闲死。

我一般看这几个指标：

• tablet_num：每个 BE 上的 Tablet 数量。差异超过 20% 就要考虑重新均衡。
• tablet_size_mb：每个 Tablet 的数据大小。单个 Tablet 超过 10GB 会影响 Compaction 效率。
• tablet_version_count：Tablet 的版本数。超过 1000 说明 Compaction 跟不上写入速度。

4.2.2 Compaction 压力

Compaction 说白了就是合并小文件。Doris 和 StarRocks 是 LSM-Tree 架构，写入越快，小文件越多。如果 Compaction 跟不上，查询性能就会直线下降。

关键指标：

指标名称	说明	告警阈值
compaction_score	Compaction 压力评分	> 50
compaction_queue_size	等待合并的任务数	> 100
base_compaction_latency	基础合并耗时	> 30 分钟

4.2.3 数据导入速率

数据导入是 OLAP 系统的生命线。导入速率上不去，数据延迟就大，业务方就会来找你。

我建议你监控这几个维度：

• load_bytes_per_second：每秒导入的数据量。这个值受网络和磁盘带宽限制。
• load_rows_per_second：每秒导入的行数。行数多不代表数据量大，要看具体场景。
• load_error_rows：导入失败的行数。超过 0 就要查原因。
• load_queue_size：等待导入的任务数。队列太长说明 BE 处理不过来。

4.3 资源隔离与监控

资源隔离是 Doris/StarRocks 1.2 之后才有的功能。说白了，就是给不同的业务分配不同的资源组，避免互相干扰。

我个人的习惯是，先做资源隔离，再做监控。没有隔离的监控，就像没有护栏的悬崖——你看到了问题，但来不及反应。

4.3.1 Workload Group 配置

Workload Group 是资源隔离的核心。你可以给每个业务组分配 CPU、内存、IO 的配额。

-- 创建资源组
CREATE WORKLOAD GROUP IF NOT EXISTS 'etl_group'
PROPERTIES (
    "cpu_share" = "10",
    "memory_limit" = "30%",
    "enable_memory_overcommit" = "true"
);

-- 绑定用户到资源组
SET PROPERTY FOR 'etl_user' 'workload_group' = 'etl_group';

关键监控指标：

指标名称	说明	正常范围
workload_group_cpu_usage	资源组 CPU 使用率	< 80%
workload_group_mem_usage	资源组内存使用率	< 90%
workload_group_query_latency	资源组内查询平均耗时	根据业务定

4.3.2 监控告警策略

有了指标，还得有告警。我一般把告警分成三个级别：

1. P0（紧急）：FE 宕机、BE 宕机、元数据写入失败。需要立即响应。
2. P1（重要）：Compaction 队列堆积、Tablet 版本数超限、导入速率下降 50%。需要在 30 分钟内处理。
3. P2（一般）：CPU 使用率持续高位、内存使用率偏高。可以在日常巡检中处理。