Apache Doris 监控实战从一次查询延迟告警看懂 3 个关键指标【免费下载链接】dorisApache Doris is an easy-to-use, high performance and unified analytics database.项目地址: https://gitcode.com/gh_mirrors/dori/doris一次线上事故复盘生产 Apache Doris 集群的查询延迟在某次变更后翻倍值班同学只能靠翻日志猜测原因。问题不在集群本身而在于集群的指标根本没有被采集。Doris 的 FE 和 BE 默认就暴露 Prometheus 格式的/metrics端点Prometheus 采集 Doris 指标、Grafana 展示查询延迟趋势这套 Apache Doris 监控体系搭起来只需要改几个配置文件。场景导入一次查不出原因的慢查询周一上午十点业务方反馈报表查询从平均 800 毫秒涨到 5 秒以上。你登上 FE 节点fe.log里没有任何报错重启服务也没用。事后复盘发现如果当时有监控延迟趋势图上 20 分钟的台阶式上涨会直接指向那次 SQL 变更而不是事后一条条翻 profile。这个场景的教训就是——指标必须先于故障存在。数据流Doris 指标从 /metrics 端点走向 Grafana关键模块在仓库中的位置FE 指标端点fe/fe-core/src/main/java/org/apache/doris/httpv2/rest/MetricsAction.javaFE 指标注册fe/fe-core/src/main/java/org/apache/doris/metric/MetricRepo.javaBE 指标端点与序列化be/src/util/metrics.cpp动手搭建确认 FE 与 BE 的指标端点Doris 不需要额外开关两个端点开箱即用FE 在http_portconf/fe.conf 中默认 8030提供/metricsBE 在webserver_portconf/be.conf 中默认 8040提供同名路径。先用 curl 确认能拿到数据curl -s http://fe_host:fe_http_port/metrics | grep query_latency输出中应出现# TYPE doris_fe_query_latency_ms summary这一行。配置 Prometheus 抓取新增一个抓取 jobscrape_interval建议 15 秒粒度足够画延迟趋势又不会给 FE 造成明显压力global: scrape_interval: 15s scrape_configs: - job_name: doris_fe static_configs: - targets: [fe_host:fe_http_port] labels: cluster: prod component: fe - job_name: doris_be static_configs: - targets: [be_host_1:be_http_port, be_host_2:be_http_port] labels: cluster: prod component: be在 Grafana 上看查询延迟趋势添加 Prometheus 数据源后导入社区维护的 Doris 官方看板或者先建一个最小面板用这条 PromQL 画 p95 延迟曲线doris_fe_query_latency_ms{quantile0.95}关键配置解析查询延迟是 summary 类型不是 histogram这是用 Doris 指标时最常被踩的坑。看 PrometheusMetricVisitor.java 里visitHistogram的实现延迟指标按 0.75 / 0.95 / 0.98 / 0.99 / 0.999 五个 quantile 直接输出预计算值外加_sum和_count。它不是 Prometheus 原生的 histogram所以histogram_quantile()在这里用不了——没有 bucket 可插值。想算平均延迟用 sum 除以 countdoris_fe_query_latency_ms_sum / doris_fe_query_latency_ms_count内存指标靠 type 标签区分 used 和 maxFE 堆内存的jvm_heap_size_bytes用type标签区分状态写面板时别漏掉这个 labelsum(jvm_heap_size_bytes{typeused}) / sum(jvm_heap_size_bytes{typemax}) by (instance)BE 侧指标以doris_be_为前缀具体名称建议直接翻/metrics页面确认后再写进面板避免版本差异导致查空。开启 HTTP 认证后抓取端点会连带被拦MetricsAction.java 里有一个分支一旦 FE 配置了enable_all_http_auth true/metrics也会要求 Basic Auth而 Prometheus 默认不带凭证。此时抓取日志里是 401 而不是连接失败容易被忽略。解法是把认证信息拼进抓取地址http://user:passwordfe_host:fe_http_port/metrics。groups: - name: doris_fe_alerts rules: - alert: FEQueryLatencyP99High expr: doris_fe_query_latency_ms{quantile0.99} 2000 for: 5m labels: severity: warning annotations: summary: FE p99 查询延迟超过 2 秒阈值 2000 毫秒指标单位是 ms、持续 5 分钟是延迟类告警比较稳的起点太敏感会被偶发慢查询刷爆太迟钝就失去了提前量。验证与排障一条命令验证链路是否通了curl -s http://fe_host:fe_http_port/metrics | grep -E query_latency_ms\{quantile0.99有输出说明 FE 端正常如果 Grafana 里查不到数据按下面顺序排查现象先检查什么Prometheus Targets 里目标显示 DOWNhttp_port/webserver_port是否被防火墙拦截节点是否存活Targets 正常但查询结果为空是否刚配置还没到第一个 scrape 周期等待 15~30 秒Targets 报 401/UnauthorizedFE 是否开启了enable_all_http_auth见上文认证小节想往深走两条路径一是在 FE 注册自定义指标注册逻辑都集中在 MetricRepo.java二是看 BE 侧指标如何注册与序列化入口在 util/metrics.cpp。单条慢查询的细粒度分析再配合 tools/profile_viewer.py 查看查询 profile监控指标和 profile 两者结合基本能覆盖绝大多数延迟问题。【免费下载链接】dorisApache Doris is an easy-to-use, high performance and unified analytics database.项目地址: https://gitcode.com/gh_mirrors/dori/doris创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
