企业官网建设流程全解析

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.conf）
• BE 的webserver_port，默认8040（见 conf/be.conf）

两个端点都支持type参数：不传时输出 Prometheus 格式（text/plain; version=0.0.4），传type=json输出 JSON，传type=core输出精简版；BE 端还支持with_tablet=true附带 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 Monitor（ID 12892）。如果只想自建最小面板，下面这几个指标是日常巡检真正会盯的：

这些指标的生成逻辑在 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/内存面板是否在几秒内跳动——有反应才说明采集、存储、展示三环都通了。

上了生产之后，建议再处理三件事：

1. 保留时长：给 Prometheus 加--storage.tsdb.retention.time=30d，3 天默认保留期撑不过一次月度容量复盘。
2. 采集间隔：默认 15 秒足够；节点多到几十台时可以把 BE job 放到 30 秒，指标基数会小不少。
3. 认证：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