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_rateFE 查询错误率0.05 持续 5 分钟doris_fe_connectionsFE 当前连接数对比自身历史基线突增doris_fe_jvm_memory_heap_used_bytesFE 堆内存已用/ max 0.85doris_be_process_mem_bytesBE 进程内存/ 整机内存 0.8doris_be_max_disk_io_util_percent磁盘 IO 利用率峰值85% 持续 10 分钟doris_be_max_tablet_compaction_scorecompaction 积压程度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不用叫醒人只留记录规则exprfor为什么是这个值CompactionScoreHighmax(doris_be_max_tablet_compaction_score) 10030m短暂尖峰会自行消化持续 30 分钟才是趋势warning工作时间处理规则exprfor为什么是这个值BEProcessMemHighmax(doris_be_process_mem_bytes) / 64e9 0.810m80% 是 OOM 前的安全线10 分钟排除 flush 瞬时抖动FEDiskIOBusymax(doris_be_max_disk_io_util_percent) 8510m磁盘接近打满compaction 会先被拖慢FEQueryErrRatemax(doris_fe_query_err_rate) 0.055m5% 错误率说明是稳定故障不是单条 SQL 抖动critical半夜叫醒人规则exprfor为什么是这个值BENodeDowndoris_be_process_mem_bytes 02mBE 掉线直接损失副本可用性2 分钟排除进程刚重启的窗口FEHeapMemoryHighdoris_fe_jvm_memory_heap_used_bytes / doris_fe_jvm_memory_heap_max_bytes 0.855m再往上就是 Full GCFE 作为查询入口会整体卡顿Alertmanager 按级别分流避免 info 类告警淹没 critical# alertmanager.yml route: receiver: wechat_info group_by: [alertname, cluster] group_wait: 30s group_interval: 5m repeat_interval: 4h routes: - matchers: [severitywarning] receiver: wechat_warning repeat_interval: 1h - matchers: [severitycritical] receiver: wechat_critical repeat_interval: 15m receivers: - name: wechat_critical webhook_configs: - url: http://wechat-webhook.example.com/send?levelcritical收到告警后的 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_byrepeat_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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/11/4 11:07:51 · 阅读 1.2k 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_rateFE 查询错误率0.05 持续 5 分钟doris_fe_connectionsFE 当前连接数对比自身历史基线突增doris_fe_jvm_memory_heap_used_bytesFE 堆内存已用/ max 0.85doris_be_process_mem_bytesBE 进程内存/ 整机内存 0.8doris_be_max_disk_io_util_percent磁盘 IO 利用率峰值85% 持续 10 分钟doris_be_max_tablet_compaction_scorecompaction 积压程度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不用叫醒人只留记录规则exprfor为什么是这个值CompactionScoreHighmax(doris_be_max_tablet_compaction_score) 10030m短暂尖峰会自行消化持续 30 分钟才是趋势warning工作时间处理规则exprfor为什么是这个值BEProcessMemHighmax(doris_be_process_mem_bytes) / 64e9 0.810m80% 是 OOM 前的安全线10 分钟排除 flush 瞬时抖动FEDiskIOBusymax(doris_be_max_disk_io_util_percent) 8510m磁盘接近打满compaction 会先被拖慢FEQueryErrRatemax(doris_fe_query_err_rate) 0.055m5% 错误率说明是稳定故障不是单条 SQL 抖动critical半夜叫醒人规则exprfor为什么是这个值BENodeDowndoris_be_process_mem_bytes 02mBE 掉线直接损失副本可用性2 分钟排除进程刚重启的窗口FEHeapMemoryHighdoris_fe_jvm_memory_heap_used_bytes / doris_fe_jvm_memory_heap_max_bytes 0.855m再往上就是 Full GCFE 作为查询入口会整体卡顿Alertmanager 按级别分流避免 info 类告警淹没 critical# alertmanager.yml route: receiver: wechat_info group_by: [alertname, cluster] group_wait: 30s group_interval: 5m repeat_interval: 4h routes: - matchers: [severitywarning] receiver: wechat_warning repeat_interval: 1h - matchers: [severitycritical] receiver: wechat_critical repeat_interval: 15m receivers: - name: wechat_critical webhook_configs: - url: http://wechat-webhook.example.com/send?levelcritical收到告警后的 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_byrepeat_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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考