Apache Doris 监控实操：3 步搭好 Prometheus + Grafana 告警体系

Apache Doris 监控实操3 步搭好 Prometheus Grafana 告警体系【免费下载链接】dorisApache Doris is an easy-to-use, high performance and unified analytics database.项目地址: https://gitcode.com/gh_mirrors/dori/doris生产上的 Doris 集群负载一上来你很难靠人眼盯住它——查询变慢、内存吃紧、compaction 分数堆积这些问题往往在用户投诉之前就有迹可循只是没人看。本文带你用 Apache Doris 自带的指标端点把 Prometheus、Grafana、Alertmanager 这套体系从零搭起来最终拿到三样东西能看趋势的看板、能提前 5 分钟预警的告警规则、一套收到告警后按图索骥的排查路径。先弄清Doris 的指标本来就开着不用额外配置很多教程会引导你去改 FE/BE 配置开启 Prometheus 指标但在当前版本的 Apache Doris 里这一步是多余的。FE 和 BE 启动后指标直接挂在各自的 HTTP 端口上FE 的http_port默认8030见 conf/fe.confBE 的webserver_port默认8040见 conf/be.conf两个端点都支持type参数不传时输出 Prometheus 格式text/plain; version0.0.4传typejson输出 JSON传typecore输出精简版BE 端还支持with_tablettrue附带 tablet 级别指标。先验证一下你的集群是否在正常吐指标# 抓取 FE 指标端点能看到 prometheus 格式的指标行即正常 curl http://fe_host:8030/metrics | head -20 # 抓取 BE 指标端点同样应有指标输出 curl http://be_host:8040/metrics | head -20如果这两条命令都有内容返回你的集群就已经是 Prometheus 就绪状态了。指标的定义和采集逻辑分别在 FE 指标注册模块 和 BE 指标端点实现 中排查某个指标为什么没值时可以顺着看。监控栈最快怎么跑起来不需要 Docker Compose 一把梭——Prometheus 和 Grafana 各自有独立的官方镜像直接拉起来更快、也更好排障。# 只给 Doris 建两个采集任务其余服务用各自默认配置即可 scrape_configs: # 抓取所有 FE 节点8030 为 fe.conf 中的 http_port - job_name: doris_fe static_configs: - targets: [10.0.0.11:8030, 10.0.0.12:8030] labels: component: fe # 抓取所有 BE 节点8040 为 be.conf 中的 webserver_port - job_name: doris_be static_configs: - targets: [10.0.0.21:8040, 10.0.0.22:8040, 10.0.0.23:8040] labels: component: be启动并检查抓取状态docker run -d --name prometheus -p 9090:9090 \ -v ./prometheus.yml:/etc/prometheus/prometheus.yml \ prom/prometheus docker run -d --name grafana -p 3000:3000 grafana/grafana预期结果打开http://localhost:9090/targets两个 job 下的所有 target 都显示UP即接入成功。若某个 target 是 DOWN先用上面的curl命令确认该节点本机是否还能吐出指标把问题隔离到网络层还是 Doris 本身。看板上该放哪几个数整条数据链路很短画出来就是这样在 Grafana 里导入 Prometheus 数据源URL 指向http://prometheus:9090再导入 Doris 官方社区看板Doris Cluster MonitorID 12892。如果只想自建最小面板下面这几个指标是日常巡检真正会盯的指标名所属节点含义经验参考线fe_query_per_secondFE每秒查询数突降说明有连接或调度异常fe_query_err_rateFE查询错误率持续 0 需要关注process_memBEBE 进程内存使用逼近内存上限前预警base_compaction_score/cumulative_compaction_scoreBE后台合并压力长期高位说明写入快于合并be_cpuBECPU 使用率持续 90% 以上需扩容或限流这些指标的生成逻辑在 FE 侧对应 指标注册模块 中的GAUGE_QUERY_PER_SECOND、COUNTER_QUERY_ERR等注册项在 BE 侧由 BE 指标采集模块 里的system_metrics统一维护改看板时想弄清口径可以直接查源码。出问题时先看什么告警规则只配两条最核心的一条管 FE 侧的查询健康一条管 BE 侧的内存水位。放在alert.rules.yml里由 Prometheus 的rule_files字段加载groups: - name: doris_alerts rules: # FE 查询错误率持续 5 分钟不为 0 触发 - alert: DorisQueryErrorRate expr: fe_query_err_rate 0 for: 5m labels: severity: warning annotations: summary: Doris FE 查询出现错误 description: 实例 {{ $labels.instance }} 查询错误率 {{ $value }} # BE 进程内存超过软上限的 80% 持续 5 分钟触发 - alert: DorisBEMemoryHigh expr: process_mem / process_mem_limit 0.8 for: 5m labels: severity: critical annotations: summary: Doris BE 内存水位过高 description: 实例 {{ $labels.instance }} 内存占比 {{ $value }}Alertmanager 侧只需把告警转发到你的通知渠道以企业微信为例route: receiver: wechat receivers: - name: wechat webhook_configs: # 指向你们自己的企业微信机器人转发服务 - url: http://wechat-webhook:8080/send规则生效后收到告警时按下面的路径定位比盲目重启有效得多定位时两个仓库自带工具值得用上segment 状态检查工具 可以看数据段分布是否异常查询 profile 查看器 能直接解析慢查询的执行计划找瓶颈。验证与生产环境的几个提醒搭完不要空跑一天主动制造负载验证整条链路对一张已有数据的表连续执行聚合查询回到 Grafana 观察fe_query_per_second和 BE 侧 CPU/内存面板是否在几秒内跳动——有反应才说明采集、存储、展示三环都通了。上了生产之后建议再处理三件事保留时长给 Prometheus 加--storage.tsdb.retention.time30d3 天默认保留期撑不过一次月度容量复盘。采集间隔默认 15 秒足够节点多到几十台时可以把 BE job 放到 30 秒指标基数会小不少。认证FE/BE 的 HTTP 端点如果开了enable_all_http_auth/metrics也会要求密码Prometheus 侧要相应配置基本认证别把 8030/8040 裸露在公网。小结与下一步整套体系其实只有三个动作确认/metrics端点可用、让 Prometheus 拉起来、把两条最关键的告警规则配好。剩下的工作是持续打磨看板和告警阈值。把 Doris 官方看板里的空面板逐个替换成你业务真正关心的指标为alert.rules.yml补上 BE 节点宕机target 状态的告警覆盖 Prometheus 抓不到 target 的场景结合 BE 指标采集模块 的源码弄清process_mem与各 mem tracker 的口径关系避免告警阈值拍脑袋【免费下载链接】dorisApache Doris is an easy-to-use, high performance and unified analytics database.项目地址: https://gitcode.com/gh_mirrors/dori/doris创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考