13. Doris 系列第13篇：生产监控全指南｜FE/BE/查询/资源五大维度，告警+采集一步落地

适合人群：Doris运维工程师、大数据运维、数仓架构师、生产监控负责人

核心价值：系统梳理Doris生产环境FE、BE、查询性能、集群健康、资源消耗五大核心监控维度，含告警阈值、指标解读、采集方式，结合官方Doris Manager工具实操，搞定集群监控落地与故障快速排查

系列说明：本文是Doris进阶第13篇，承接上篇湖仓一体，聚焦生产运维核心——监控体系搭建，基于Doris 2.2版本，结合社区官方工具（Doris Manager），覆盖从指标解读到落地采集的全流程，看完可直接搭建生产级监控告警体系。

一、开篇核心：Doris监控的“底线思维”

Doris作为生产级OLAP引擎，监控的核心目标是保障集群“高可用、高性能、高可靠”，杜绝因节点故障、资源耗尽、数据不一致导致的业务中断。

核心原则：早发现、早排查、早解决，重点监控“异常指标”而非“所有指标”，聚焦能直接反映集群健康与业务影响的核心项。

本文将从「生产告警 Checklist」切入，分五大维度拆解监控指标，补充官方工具（Doris Manager）实操，结合生产避坑细节，让监控落地更高效。

二、生产环境监控 Checklist（告警项，直接套用）

以下是生产环境必配告警项，按“严重性分级”，阈值可根据业务规模微调，优先保障核心指标零异常：

类别	告警项	阈值	严重性	核心说明
健康状态	BE 失联数量	>0	🔴 紧急	BE节点宕机，直接影响数据存储与计算，需立即重启排查
	不一致Tablet数量	>0	🔴 紧急	副本数据不一致，有数据丢失风险，需立即修复
资源消耗	BE 内存使用率	>90% 持续5分钟	🟠 严重	内存不足易导致OOM kill，需优化查询或扩容
	BE 磁盘使用率	>85%（警告）；>90%（紧急）	🟡 警告（85%）；🔴 紧急（90%）	85%触发Tablet均衡，90%拒绝写入，需清理数据或扩容
	BE CPU使用率	>90% 持续10分钟	🟠 严重	CPU瓶颈导致查询卡顿，需优化复杂查询或扩容
性能指标	慢查询数/分钟	>10（中小集群）；>50（大集群）	🟠 严重	慢查询过多占用资源，需分析优化SQL
	查询平均延迟	对比基线突增2倍	🟡 警告	性能退化，需排查Compaction、索引或资源问题
数据导入	导入失败率	>1% 持续10分钟	🟠 严重	导入异常影响数据同步，需排查数据格式或集群状态

三、FE（Frontend）监控指标（集群“大脑”，重点保可用）

FE负责元数据管理、查询解析、任务调度，是集群的核心管控节点，监控重点是「元数据健康、JVM稳定、连接正常」，避免因FE故障导致整个集群不可用。

3.1 JVM相关指标（FE基于Java开发，JVM是重灾区）

FE默认堆内存为8~16GB，若集群元数据量大（表/分区数>10万），需手动调优堆内存（修改fe.conf的-Xmx参数），核心监控指标如下：

指标名称	指标说明	告警建议	排查方向
jvm.heap.used.percent	JVM堆内存使用率	>85% 持续5分钟 → 告警	1. 调优堆内存；2. 排查内存泄漏（如频繁创建大对象）
jvm.gc.time.ms	GC总耗时（重点关注Full GC）	单次Full GC >5s 或1分钟内Minor GC>10次 → 告警	Full GC频繁：堆内存不足或内存泄漏；Minor GC频繁：年轻代设置不合理
jvm.thread.count	当前JVM线程数	线程数突增2倍以上 → 告警	可能存在死锁、连接池泄漏或恶意请求攻击
jvm.nonheap.used.percent	JVM非堆内存使用率（方法区、Metaspace）	>90% → 告警	元数据过多导致Metaspace不足，需调优-XX:MetaspaceSize参数

3.2 元数据与状态指标（核心保障元数据一致性）

FE元数据是集群的“灵魂”，一旦损坏或不一致，会导致集群无法正常运行，重点监控以下指标：

指标名称	指标说明	关键关注点
fe.is_master	标识当前FE是否为Master节点（1=Master，0=非Master）	HA部署时，必须有且仅有1个Master，否则集群异常
catalog.trash.expired.partition.count	回收站中待删除的分区数量	数量持续增长 → DROP操作积压，需检查删除任务是否阻塞
edit_log.roll.interval.ms	Edit Log（元数据操作日志）滚动间隔	间隔过长（>30min） → 元数据持久化延迟，有丢失风险
metadata.sync.time.ms	Master与Follower/Observer的元数据同步延迟	延迟>10s → 元数据不一致，需检查网络或节点状态

3.3 连接与请求指标（监控访问压力）

FE作为查询入口，连接数和请求延迟直接反映访问压力，需重点监控：

指标名称	指标说明	风险提示
qps / query.total.count	查询QPS（每秒查询数）/ 累计查询数	QPS突增 → 可能是业务峰值或恶意查询，需限流
connection.total.count	当前FE的总连接数（含MySQL客户端、BI工具、API连接）	连接数突增 → 可能是连接池泄漏或恶意扫描，需排查连接来源
http.request.latency.ms	HTTP请求延迟（如Stream Load、API调用）	延迟>500ms → 可能FE压力过大，需优化请求频率

四、BE（Backend）监控指标（集群“算力核心”，重点保性能）

BE负责数据存储、查询计算，是集群性能瓶颈的主要发生地，监控重点是「资源使用率、Tablet健康、Compaction状态」，避免因BE故障导致数据不可用或查询卡顿。

4.1 系统资源指标（基础保障，避免资源耗尽）

BE是CPU、内存、磁盘、IO的主要消耗者，需实时监控资源使用率，提前规避瓶颈：

指标名称	指标说明	告警建议	优化方向
cpu.utilization.percent	BE节点CPU使用率（不含空闲进程）	>90% 持续10分钟 → 告警	1. 优化复杂查询（如Join、大聚合）；2. 限制并发查询数；3. 节点扩容
memory.used.percent	BE节点总内存使用率（非JVM内存，BE基于C++开发）	>85% → 告警	1. 减少大查询内存占用；2. 调整BE内存配置；3. 扩容内存
disk_used_percent	BE数据磁盘使用率（单个磁盘）	>85% → 警告；>90% → 紧急告警	1. 清理过期数据/分区；2. 触发Tablet均衡；3. 磁盘扩容
io.util.percent	磁盘IO利用率（读写合并）	>90% 持续5分钟 → 告警	1. 合并小文件（减少IO次数）；2. 优化查询扫描范围；3. 更换高性能磁盘

4.2 Tablet与副本健康指标（核心中的核心）

Tablet是Doris的数据分片单位，副本一致性直接决定数据可靠性，inconsistent_tablet_num必须为0，否则有数据丢失风险：

指标名称	指标说明	重要性	排查方向
tablet.total.count	当前BE节点上的Tablet总数	⭐⭐	总数过多（>10万） → 分片过细，需调整分桶策略
tablet.inconsistent.count	副本不一致的Tablet数量	⭐⭐⭐⭐⭐	>0 → 立即排查：1. 节点是否宕机；2. 网络是否异常；3. 执行修复命令
tablet.clone.job.running	正在执行的副本修复任务数	⭐⭐⭐	持续>0且不减少 → 可能磁盘故障或修复任务阻塞，需手动干预
tablet.version.count	Tablet的版本数量（反映Compaction压力）	⭐⭐⭐	单Tablet版本>100 → Compaction积压，查询性能下降

4.3 Compaction（合并）指标（影响查询性能的关键）

Doris通过Compaction合并Tablet的小版本文件，减少查询时的版本合并开销，若Compaction积压，会导致查询变慢、磁盘空间无法释放，重点监控：

指标名称	指标说明	风险提示
compaction.pending.tasks	待执行的Compaction任务总数（含Minor/Major）	持续增长 → Compaction能力不足，需调优Compaction参数
compaction.used.time.avg.ms	平均Compaction任务耗时	耗时>10s → 单个任务过大，需调整合并策略
base_compaction.pending.tasks	待执行的Base Compaction（大合并）任务数	>5 → 大合并积压，磁盘空间无法释放，查询性能退化
cumulative_compaction.pending.tasks	待执行的Cumulative Compaction（小合并）任务数	>20 → 小合并积压，需增加Compaction线程数
⚠️ 补充：Compaction调优核心参数（be.conf）：

• compaction_threads：Compaction线程数，默认4，可根据CPU核数调整（建议≤CPU核数的1/2）；

• base_compaction_check_interval_seconds：Base Compaction检查间隔，默认300s，可缩短至60s。

五、查询性能监控（业务感知核心，重点保体验）

查询性能直接影响业务体验，监控重点是「延迟、吞吐、慢查询」，快速定位性能瓶颈，优化用户体验，核心指标如下：

5.1 查询延迟与吞吐指标（整体性能基线）

指标名称	指标说明	告警建议	优化方向
query.duration.avg.ms	所有查询的平均耗时	对比历史基线突增2倍 → 告警	1. 排查慢查询；2. 检查Compaction状态；3. 优化索引/分区分桶
query.duration.p95.ms	95%查询的耗时（反映绝大多数查询的性能）	>1000ms（根据业务调整） → 告警	重点优化长尾查询，提升整体体验
query.scan.rows.per.sec	查询每秒扫描的行数（吞吐指标）	对比基线下降50% → 告警	1. 排查IO瓶颈；2. 检查索引是否生效；3. 优化查询过滤条件
query.memory.cost.avg.bytes	单查询平均占用内存	异常高（如>10GB） → 告警	排查是否存在笛卡尔积、无索引全表扫描等问题

5.2 慢查询识别与治理（性能优化重点）

慢查询是性能瓶颈的主要来源，需开启日志+监控，快速识别并优化：

1. 开启慢查询日志（fe.conf配置）：
   enable_profile = true # 开启查询Profile，便于分析 log_slow_query = true # 开启慢查询日志 slow_query_time = 5000 # 慢查询定义（单位ms），可按业务调整

2. 核心监控指标：

   • slow_query_count：单位时间内的慢查询数量（如每分钟）；

   • slow_query_duration.ms：慢查询的平均耗时。

3. 实时排查工具：
   `-- 查看当前运行中的查询（实时定位慢查询）
   SHOW PROC ‘/current_queries’;

– 查看历史慢查询记录
SHOW PROC ‘/slow_queries’;
`

5.3 Query Profile关键指标（单查询优化核心）

对单条慢查询，通过Query Profile分析瓶颈，重点关注以下指标（通过EXPLAIN ANALYZE获取）：

• ScanTime：数据扫描时间 → 过长说明扫描范围过大，需优化过滤条件、索引；

• JoinTime / AggTime：Join/聚合计算耗时 → 过长说明计算复杂，需优化Join顺序、聚合方式；

• ReturnRows vs ScanRows：过滤率 = ReturnRows / ScanRows → 过滤率越低越好（理想<1%），过滤率高说明过滤条件无效；

• MemoryUsed：查询占用内存 → 过高说明查询逻辑不合理（如无限制Group By）。

六、数据导入（Load）监控（保障数据可靠性）

Doris支持Stream Load、Broker Load、Routine Load等多种导入方式，监控重点是「导入成功率、延迟、错误行数」，避免数据同步异常：

指标名称	指标说明	关键标准	常见失败原因
load.job.success.rate	导入任务成功率（成功数/总任务数）	>99.9%	1. 数据格式错误（JSON/CSV解析失败）；2. 内存不足（mem_limit超限）；3. Tablet副本不可用；4. 权限不足
load.job.pending.count	待调度的导入任务数	持续>10 → 异常
stream_load.push.duration.avg.ms	Stream Load推送延迟（从提交到开始处理）	>1000ms → 需优化
routine_load.error.rows	Routine Load（实时导入）的错误行数	持续增长 → 异常
🛠️ 排查工具：通过SHOW LOAD查看导入任务详情，通过SHOW ROUTINE LOAD查看实时导入状态。

七、集群健康与高可用监控（保障集群稳定运行）

集群高可用依赖FE/BE节点冗余、副本均衡，重点监控「节点状态、副本均衡、HA配置」：

7.1 节点状态监控

指标名称	指标说明	告警建议
fe.alive.num	存活的FE节点数量	HA部署时 < 3 → 告警（需部署奇数个FE）
be.alive.num	存活的BE节点数量	小于集群总节点数的80% → 告警
be.last_heartbeat	BE节点最后一次向FE发送心跳的时间	>30s → 节点失联，告警

7.2 副本均衡监控

副本均衡确保数据均匀分布在各个BE节点，避免单节点压力过大：

指标名称	指标说明	关键关注点
tablet.balance.job.running	Tablet均衡任务是否正在运行（1=运行，0=停止）	磁盘使用率差异大时，需确保均衡任务运行
be.disk.path.used.percent.stddev	各BE节点磁盘使用率的标准差	标准差>10 → 磁盘使用率差异过大，需触发均衡

7.3 高可用（HA）监控

Doris HA核心依赖FE集群，需重点监控：

• FE节点数量：必须部署奇数个（3/5个），确保Master选举正常；

• 指标fe.role：集群中应有1个Master、N个Follower/Observer，缺失Master则集群异常；

• Master切换：监控fe.master.change.count，频繁切换说明集群不稳定，需排查网络或节点故障。

八、指标采集方式（3种方式，按需选择）

结合Doris官方工具与开源组件，提供3种采集方式，优先推荐「方式1+方式2」结合，兼顾便捷性与可视化：

方式1：Doris自带HTTP接口（推荐，零依赖）

Doris FE/BE自带Prometheus格式指标接口，可直接对接Prometheus + Grafana，快速搭建监控面板：

• FE指标接口：http://fe_host:8030/metrics（默认端口8030，可在fe.conf中修改）；

• BE指标接口：http://be_host:8040/metrics（默认端口8040，可在be.conf中修改）；

• 优势：零开发、零依赖，指标全面，实时性高；

• 实操：在Prometheus配置文件中添加FE/BE节点，配置示例：
  `scrape_configs:

  • job_name: ‘doris_fe’
    static_configs:
    • targets: [‘fe1:8030’, ‘fe2:8030’, ‘fe3:8030’] # 所有FE节点
  • job_name: ‘doris_be’
    static_configs:
    • targets: [‘be1:8040’, ‘be2:8040’, ‘be3:8040’] # 所有BE节点
      `

方式2：Doris Manager（官方运维平台，推荐生产使用）

Doris Manager是Apache Doris官方开源的集群运维管理平台（GitHub地址），支持指标监控、集群管理、告警配置等功能，无需手动配置Prometheus/Grafana，开箱即用：

核心功能（贴合监控需求）：

• 指标可视化：内置FE/BE/查询/导入等核心指标面板，无需手动配置；

• 告警管理：支持自定义告警阈值、告警渠道（邮件、短信、钉钉）；

• 集群运维：支持节点启停、配置修改、日志查看，一站式运维；

• 技术栈：基于Java（71.0%）、TypeScript（25.1%）开发，开源免费，社区持续维护。

⚠️ 注意：Doris Manager最新提交时间为2023年7月，当前支持Doris 2.x版本，部署时需注意版本兼容性，可参考官方docs目录下的初始化文档（Initializing.md）进行部署。

方式3：日志监控（补充排查，兜底保障）

通过监控FE/BE日志，捕捉异常信息，作为指标监控的补充，关键日志路径与关键词：

节点类型	日志路径（默认）	关键告警关键词
FE	doris/fe/log/fe.log	FATAL、ERROR、OutOfMemoryError、tablet inconsistent
BE	doris/be/log/be.log	FATAL、ERROR、memory limit exceeded、IO error
导入日志	doris/fe/log/load_log.log	load failed、parse error、rejected rows

九、总结：Doris监控落地核心要点

Doris生产监控的核心是“聚焦关键指标、搭建闭环体系”，落地时牢记3个核心要点：

1. 必监指标：优先监控「不一致Tablet、BE节点存活、磁盘使用率、慢查询数」，这4个指标直接决定集群可用性与业务体验；

2. 采集方式：推荐「Doris自带HTTP接口 + Doris Manager」结合，既保证指标全面，又降低运维成本；

3. 告警闭环：告警不仅要“报”，还要“能排查”，结合Query Profile、日志、集群运维工具，快速定位并解决问题。

✅ 最佳实践：

• 部署Prometheus + Grafana，导入Doris官方监控模板，实现指标可视化；

• 开启Doris Manager，实现集群运维与告警一站式管理；

• 定期分析慢查询、Compaction状态，提前优化，避免性能退化；

• 制定应急预案（如BE宕机、副本不一致），确保故障快速恢复。