Apache Doris 集群监控实践：用 Prometheus + Grafana 抓住 4 类半夜告警

Apache Doris 集群监控实践：用 Prometheus + Grafana 抓住 4 类半夜告警

【免费下载链接】dorisApache Doris is an easy-to-use, high performance and unified analytics database.项目地址: https://gitcode.com/gh_mirrors/dori/doris

本文围绕 Apache Doris 监控展开，讲清楚 Prometheus 采集配置、Grafana 面板布局和 Doris 告警规则的取舍原则。读完你可以给一个 FE + BE 集群搭起一套"只报真事"的 Prometheus Grafana 告警链路，并拿到一份收到告警后 5 分钟内的定位清单。

先想清楚：Doris 到底要盯哪些东西

先不讲工具，讲四个真实运维场景，每个场景对应一组指标：

• 查询突然变慢：业务方只说"变慢了"，你要能回答是资源不够还是某条 SQL 拖后腿。
• BE 节点掉线：进程消失、OOM 被杀或网络断开，影响副本可用性和查询成功率。
• 磁盘快满：数据目录写满后写入直接失败，需要提前几天而不是几小时发现。
• FE 内存飙升：FE 是元数据和查询入口，堆内存打满会触发 Full GC，整个集群查询一起卡。

FE 侧指标统一注册在 MetricRepo，以 Prometheus 文本格式经 PrometheusMetricVisitor 输出；BE 侧指标（见 be/src/util/doris_metrics.h）经 HTTP/metrics暴露。四个场景对应的核心指标如下：

指标名	含义	建议关注阈值
doris_fe_query_err_rate	FE 查询错误率	>0.05 持续 5 分钟
doris_fe_connections	FE 当前连接数	对比自身历史基线突增
doris_fe_jvm_memory_heap_used_bytes	FE 堆内存已用	/ max > 0.85
doris_be_process_mem_bytes	BE 进程内存	/ 整机内存 > 0.8
doris_be_max_disk_io_util_percent	磁盘 IO 利用率峰值	>85% 持续 10 分钟
doris_be_max_tablet_compaction_score	compaction 积压程度	>100 持续 30 分钟
doris_be_load_mem_consumption	导入链路内存	突增且无对应导入任务

阈值不是拍脑袋：compaction score 超过 100 意味着 version 积压到查询需要合并读大量 rowset，这正是"查询变慢"的常见根因。

把指标采上来：Prometheus 采集 Doris 指标配置

FE 默认http_port = 8030、BE 默认webserver_port = 8040（见 conf/fe.conf 与 conf/be.conf），两者都在该端口提供/metrics端点，指标名分别以doris_fe_、doris_be_开头，默认就是开着的，无需额外配置，重启一次即可生效。

Prometheus 侧推荐把 Doris 目标单独拆到一个文件里，主配置只引用：

# prometheus/doris.yml scrape_configs: - job_name: doris_fe scrape_interval: 15s static_configs: - targets: ["fe1.example.com:8030"] labels: {component: fe} - job_name: doris_be scrape_interval: 15s static_configs: - targets: ["be1.example.com:8040", "be2.example.com:8040"] labels: {component: be}

# prometheus/prometheus.yml rule_files: - "doris.rules.yml" scrape_configs: - job_file: "doris.yml"

采集间隔选 15s 有两个理由：其一，Grafana 里所有rate(...[2m])窗口至少要有 8 个样本，曲线才稳定；其二，Doris 的/metrics输出是现成文本，一次抓取消纳很小，15s 对 FE/BE 几乎无压力，没必要为了"精确"压到 5s 以下。节点多起来之后，把static_configs换成file_sd_configs或 k8s service discovery 即可，规则文件不用动。

让看板说人话：Grafana 面板布局思路

不建议把面板按"FE 一块、BE 一块"堆上去，而是按问题分层，每层回答一个具体问题。每个面板只回答一个问题，问不出结论的面板删掉。

第一屏回答"集群是不是健康的"：BE 存活数量、FE 查询错误率、FE 堆内存。这一屏应该能在 3 秒内看完。

第二屏回答"查询体验有没有变差"：QPS 趋势、扫描吞吐按实例分布、compaction score。QPS 平稳而扫描吞吐掉，多半是扫描线程池或磁盘出了问题。

关键面板的 PromQL（注释写在行内）：

# 集群 BE 存活数：比 1 - up() 更直观，掉线时直接看到数字下跌 count(doris_be_process_mem_bytes) # FE 查询错误率：指标本身已按窗口算好，无需再做 rate doris_fe_query_err_rate # 各 BE 每秒扫描吞吐：按实例拆开，才能看出负载不均 sum by (instance) (rate(doris_be_query_scan_bytes[5m]))

面板里给所有图统一加instance变量过滤器，多集群共用一套 dashboard 时不会串数据。

告警规则：只留半夜值得被叫醒的

原则：critical 只报"服务正在受损或即将不可用"，其余降级。按三级组织如下。

info：不用叫醒人，只留记录

规则	expr	for	为什么是这个值
CompactionScoreHigh	max(doris_be_max_tablet_compaction_score) > 100	30m	短暂尖峰会自行消化，持续 30 分钟才是趋势

warning：工作时间处理

规则	expr	for	为什么是这个值
BEProcessMemHigh	max(doris_be_process_mem_bytes) / 64e9 > 0.8	10m	80% 是 OOM 前的安全线，10 分钟排除 flush 瞬时抖动
FEDiskIOBusy	max(doris_be_max_disk_io_util_percent) > 85	10m	磁盘接近打满，compaction 会先被拖慢
FEQueryErrRate	max(doris_fe_query_err_rate) > 0.05	5m	5% 错误率说明是稳定故障，不是单条 SQL 抖动

critical：半夜叫醒人

规则	expr	for	为什么是这个值
BENodeDown	doris_be_process_mem_bytes == 0	2m	BE 掉线直接损失副本可用性，2 分钟排除进程刚重启的窗口
FEHeapMemoryHigh	doris_fe_jvm_memory_heap_used_bytes / doris_fe_jvm_memory_heap_max_bytes > 0.85	5m	再往上就是 Full GC，FE 作为查询入口会整体卡顿

Alertmanager 按级别分流，避免 info 类告警淹没 critical：

# alertmanager.yml route: receiver: wechat_info group_by: [alertname, cluster] group_wait: 30s group_interval: 5m repeat_interval: 4h routes: - matchers: [severity="warning"] receiver: wechat_warning repeat_interval: 1h - matchers: [severity="critical"] receiver: wechat_critical repeat_interval: 15m receivers: - name: wechat_critical webhook_configs: - url: http://wechat-webhook.example.com/send?level=critical

收到告警后的 5 分钟定位清单

BE 掉线（BENodeDown）：先看该 target 在 Prometheus 里是否 down。if 是 down，先判断 BE 进程是否真的不在：ps aux | grep doris_be，再看机器上/var/log/messages有没有 oom-killer 记录。if 进程在但 scrape down，多半是 8040 端口或防火墙问题，走采集排查而不是业务排查。

查询变慢 / 错误率高：先看 QPS 有没有突增。if 有，是流量问题，查连接数和限流配置；if 没有，是资源问题，看 compaction score 和doris_be_scanner_thread_pool_queue_size是否积压。同时SHOW PROC '/current_queries'找出正在跑的长查询。

磁盘类告警（DiskFull / DiskIOBusy）：先看是容量还是速度。if 容量问题，查 compaction score 是否同步升高——score 高说明积压数据在放大磁盘占用，先停导入比清数据更急。

常用诊断命令：

curl -s localhost:9090/api/v1/targets | jq '.data.activeTargets[] | select(.health!="up")' tail -n 200 be.WARNING | grep -E "IO error|No space"

上线前检查 & 常见踩坑

• 端口没放通：curl fe_host:8030/metrics和curl be_host:8040/metrics都要返回指标文本，target 是 down 时第一件事查这里，别急着怀疑 Grafana。
• 标签不一致导致面板空白：scrape 时给的component/cluster标签必须和 dashboard 变量、告警规则里的引用完全一致，一个字母差就是整屏空白。
• 告警风暴：一定配group_by+repeat_interval，再对维护窗口加 silence，否则一次 BE 滚动重启会刷满企业微信群。
• 磁盘类告警给够时间：BE 数据目录写满前通常有数天缓冲，for至少给 1h，给值班留扩容和迁移的时间。
• 规则改完先空跑：新增 expr 先用 Prometheus 的 Rules 页看是否 firing、值是否合理，再挂到 Alertmanager，避免新规则上线即风暴。

小结

监控的价值不在面板数量，而在告警可信：只报半夜值得起来的，报了就 5 分钟内能定位。想继续深入，可以看 docs/ 下的配置文档生成脚本了解 FE/BE 全量配置项，以及 samples/doris-demo/ 里 JDBC 与 REST 的接入示例，配合本文的指标清单快速搭起自己的 Doris 监控大盘。

【免费下载链接】dorisApache Doris is an easy-to-use, high performance and unified analytics database.项目地址: https://gitcode.com/gh_mirrors/dori/doris