4 步给 Apache Doris 集群接上 Prometheus 和 Grafana 监控告警

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

凌晨两点，一条企业微信弹出来："某 Doris 集群 BE 节点心跳断了两小时。" 打开 Grafana，QPS 曲线在断线那一刻直接归零，但到底是磁盘写满、进程 OOM 还是网络抖动，没人说得清。Apache Doris 其实已经把指标以 Prometheus 文本格式暴露在 FE/BE 的 HTTP 端口上，你缺的只是把 Prometheus 拉起来、Grafana 画板、Alertmanager 配一条不打扰人的告警规则。这篇文章就是补齐这三块，从 0 到 1 把 Doris 监控告警跑通，覆盖部署、指标拉取、看板导入和告警规则四个动作。

把监控栈挑齐：4 个组件各管一段

监控不是要造轮子，Doris 侧指标导出已经内置，剩下三个都是开源组件，一个集群一套就够：

数据流很直接：FE/BE /metrics → Prometheus scrape → TSDB → Grafana 面板 / Alertmanager 告警。没有中间件、没有额外 sidecar，出问题排查链路也短。

动手部署：三件套 + 拉指标

用 docker-compose 拉起 Prometheus、Grafana、Alertmanager

监控三件套都是单容器，用 compose 一次性起完最省心，后面改配置也能一键up -d重载，不用单独 docker run 三条命令。

services: prometheus: image: prom/prometheus:latest ports: ["9090:9090"] volumes: - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml grafana: image: grafana/grafana:latest ports: ["3000:3000"] alertmanager: image: prom/alertmanager:latest ports: ["9093:9093"]

起来后浏览器打开http://localhost:9090和http://localhost:3000都能进，就说明基础网络没问题。TSDB 保留时长建议 15 天起步，方便后面看周环比，用--storage.tsdb.retention.time=15d加到 Prometheus 启动参数里。

让 Prometheus 拉取 Doris FE 和 BE 的 /metrics

Doris 不需要额外装 exporter——FE 在http_port（默认 8030）、BE 在webserver_port（默认 8040）上都会把/metrics以 Prometheus 文本格式吐出来，FE 侧实现见 fe/fe-core/src/main/java/org/apache/doris/httpv2/rest/MetricsAction.java，BE 侧见 be/src/http/action/metrics_action.cpp。Prometheus 只需要把这两个地址填进scrape_configs，采集间隔用默认 15s 就够，调太短只是白耗 CPU 和磁盘。

scrape_configs: - job_name: doris_fe static_configs: - targets: ["your_fe_host:8030"] labels: role: fe - job_name: doris_be static_configs: - targets: ["your_be_host:8040"] labels: role: be

改完用promtool check config校验语法，再docker compose restart prometheus重载。回到 Prometheus 的 Status → Targets 页面，两个 target 都显示UP才算这一关通过；如果是 DOWN，先别怀疑 Doris，多半是端口没放行。

导入官方 Dashboard 并绑定数据源

Grafana 里新建数据源指向http://prometheus:9090后，可以直接导入 Apache Doris 官方维护的 Dashboard，把 QPS、延迟、内存、compaction、慢查询这些常用面板一次性铺好，不用自己画。导入 ID 在 Doris 官方文档里能找到，选你刚建的那个数据源即可；导入完先别急着看，等 1~2 个采集周期（默认 15s）面板上才会有数据。

配一条不打扰人的告警规则

告警写得最勤的人通常最先被拉黑。核心判断标准就一条：会不会导致业务直接受损——会，就是 critical；只是趋势异常、需要人看一眼，就是 warning。按这个标准分两条最典型：

• critical：BE 心跳中断。PromQL 大致是up{job="doris_be"} == 0，持续 1 分钟就发。BE 掉线意味着该节点数据副本不可写，业务侧 INSERT 会直接失败，必须电话/企业微信强提醒。
• warning：FE JVM 堆使用率超 80%。PromQL 大致是jvm_memory_bytes_used{area="heap"} / jvm_memory_bytes_max{area="heap"} > 0.8，持续 5 分钟才发。JVM 堆高但没满，可能只是慢查询积压，先看日志再决定要不要扩容。

groups: - name: doris rules: - alert: BEHeartbeatLost expr: up{job="doris_be"} == 0 for: 1m labels: {severity: critical}

for字段是"持续多久才算数"，短于 1 分钟基本只会在网络抖动时误报；长于 10 分钟则真出事时已经晚了。

踩过的坑与快速排查

上线后的三件事

1. 先把 7 天曲线跑满再调阈值。Grafana 里把 QPS、延迟 p95、BE 内存的 7 天曲线截下来看一眼，用 P95 而不是平均值做 warning 基线，否则阈值设得再"合理"也会在业务高峰天天响，一周后你会开始习惯无视所有告警。
2. 给 BE 节点打上rack或zonelabel。多机部署后 Grafana 面板可以按机房/机架切分，故障时一眼定位是单机问题还是机架问题，不用翻日志猜。
3. 告警通道做两级。critical 走电话/企业微信强提醒，warning 走邮件/Slack 汇总，一天最多汇总一次。分级做不到的话，一周后你会开始习惯无视所有告警。

延伸方向

指标看久了你会发现"CPU 高但 QPS 没涨"这类问题光看时序图查不到根因，下一步可以把 Doris 的 profile 与 Prometheus 时间轴对上，做火焰图 + 慢查询日志联动分析，比单看任何一边都快。

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