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 节点心跳断了两小时。 打开 GrafanaQPS 曲线在断线那一刻直接归零但到底是磁盘写满、进程 OOM 还是网络抖动没人说得清。Apache Doris 其实已经把指标以 Prometheus 文本格式暴露在 FE/BE 的 HTTP 端口上你缺的只是把 Prometheus 拉起来、Grafana 画板、Alertmanager 配一条不打扰人的告警规则。这篇文章就是补齐这三块从 0 到 1 把 Doris 监控告警跑通覆盖部署、指标拉取、看板导入和告警规则四个动作。把监控栈挑齐4 个组件各管一段监控不是要造轮子Doris 侧指标导出已经内置剩下三个都是开源组件一个集群一套就够组件职责部署位置建议Prometheus定时拉取指标TSDB 存储 PromQL 查询独立小规格节点或复用一台 FE 节点Grafana看板可视化QPS、延迟、内存、compaction 曲线与 Prometheus 同节点Alertmanager按告警规则路由到企业微信/邮件/Slack与 Prometheus 同节点Doris 内置/metrics端点FE/BE 直接吐 Prometheus 格式无需额外 exporter随 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.time15d加到 Prometheus 启动参数里。让 Prometheus 拉取 Doris FE 和 BE 的 /metricsDoris 不需要额外装 exporter——FE 在http_port默认 8030、BE 在webserver_port默认 8040上都会把/metrics以 Prometheus 文本格式吐出来FE 侧实现见 fe/fe-core/src/main/java/org/apache/doris/httpv2/rest/MetricsAction.javaBE 侧见 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。按这个标准分两条最典型criticalBE 心跳中断。PromQL 大致是up{jobdoris_be} 0持续 1 分钟就发。BE 掉线意味着该节点数据副本不可写业务侧 INSERT 会直接失败必须电话/企业微信强提醒。warningFE JVM 堆使用率超 80%。PromQL 大致是jvm_memory_bytes_used{areaheap} / jvm_memory_bytes_max{areaheap} 0.8持续 5 分钟才发。JVM 堆高但没满可能只是慢查询积压先看日志再决定要不要扩容。groups: - name: doris rules: - alert: BEHeartbeatLost expr: up{jobdoris_be} 0 for: 1m labels: {severity: critical}for字段是持续多久才算数短于 1 分钟基本只会在网络抖动时误报长于 10 分钟则真出事时已经晚了。踩过的坑与快速排查症状可能原因处理命令Prometheus Targets 显示 DOWNFE/BE 端口未对 Prometheus 所在节点放行curl -v your_be_host:8040/metrics \| head -20指标能拉但 Grafana 面板全空数据源 URL 写错或 job label 没对上在 Grafana Explore 里直接查up确认有数据FE 内存告警一直 warningJVM 堆本来就接近上限80% 阈值偏低结合jstat -gcutil fe_pid看是否真在 GC 抖动Alertmanager 收不到 Prometheus 告警Prometheus 没配alerting:段指向 alertmanagerdocker exec prom promtool check config验证配置上线后的三件事先把 7 天曲线跑满再调阈值。Grafana 里把 QPS、延迟 p95、BE 内存的 7 天曲线截下来看一眼用 P95 而不是平均值做 warning 基线否则阈值设得再合理也会在业务高峰天天响一周后你会开始习惯无视所有告警。给 BE 节点打上rack或zonelabel。多机部署后 Grafana 面板可以按机房/机架切分故障时一眼定位是单机问题还是机架问题不用翻日志猜。告警通道做两级。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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
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 节点心跳断了两小时。 打开 GrafanaQPS 曲线在断线那一刻直接归零但到底是磁盘写满、进程 OOM 还是网络抖动没人说得清。Apache Doris 其实已经把指标以 Prometheus 文本格式暴露在 FE/BE 的 HTTP 端口上你缺的只是把 Prometheus 拉起来、Grafana 画板、Alertmanager 配一条不打扰人的告警规则。这篇文章就是补齐这三块从 0 到 1 把 Doris 监控告警跑通覆盖部署、指标拉取、看板导入和告警规则四个动作。把监控栈挑齐4 个组件各管一段监控不是要造轮子Doris 侧指标导出已经内置剩下三个都是开源组件一个集群一套就够组件职责部署位置建议Prometheus定时拉取指标TSDB 存储 PromQL 查询独立小规格节点或复用一台 FE 节点Grafana看板可视化QPS、延迟、内存、compaction 曲线与 Prometheus 同节点Alertmanager按告警规则路由到企业微信/邮件/Slack与 Prometheus 同节点Doris 内置/metrics端点FE/BE 直接吐 Prometheus 格式无需额外 exporter随 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.time15d加到 Prometheus 启动参数里。让 Prometheus 拉取 Doris FE 和 BE 的 /metricsDoris 不需要额外装 exporter——FE 在http_port默认 8030、BE 在webserver_port默认 8040上都会把/metrics以 Prometheus 文本格式吐出来FE 侧实现见 fe/fe-core/src/main/java/org/apache/doris/httpv2/rest/MetricsAction.javaBE 侧见 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。按这个标准分两条最典型criticalBE 心跳中断。PromQL 大致是up{jobdoris_be} 0持续 1 分钟就发。BE 掉线意味着该节点数据副本不可写业务侧 INSERT 会直接失败必须电话/企业微信强提醒。warningFE JVM 堆使用率超 80%。PromQL 大致是jvm_memory_bytes_used{areaheap} / jvm_memory_bytes_max{areaheap} 0.8持续 5 分钟才发。JVM 堆高但没满可能只是慢查询积压先看日志再决定要不要扩容。groups: - name: doris rules: - alert: BEHeartbeatLost expr: up{jobdoris_be} 0 for: 1m labels: {severity: critical}for字段是持续多久才算数短于 1 分钟基本只会在网络抖动时误报长于 10 分钟则真出事时已经晚了。踩过的坑与快速排查症状可能原因处理命令Prometheus Targets 显示 DOWNFE/BE 端口未对 Prometheus 所在节点放行curl -v your_be_host:8040/metrics \| head -20指标能拉但 Grafana 面板全空数据源 URL 写错或 job label 没对上在 Grafana Explore 里直接查up确认有数据FE 内存告警一直 warningJVM 堆本来就接近上限80% 阈值偏低结合jstat -gcutil fe_pid看是否真在 GC 抖动Alertmanager 收不到 Prometheus 告警Prometheus 没配alerting:段指向 alertmanagerdocker exec prom promtool check config验证配置上线后的三件事先把 7 天曲线跑满再调阈值。Grafana 里把 QPS、延迟 p95、BE 内存的 7 天曲线截下来看一眼用 P95 而不是平均值做 warning 基线否则阈值设得再合理也会在业务高峰天天响一周后你会开始习惯无视所有告警。给 BE 节点打上rack或zonelabel。多机部署后 Grafana 面板可以按机房/机架切分故障时一眼定位是单机问题还是机架问题不用翻日志猜。告警通道做两级。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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
知识建站
内容驱动
阅读友好版式
SEO 精细化
线索转化