Doris集群监控不求人：用Manager快速搭建Prometheus+Grafana看板（含自定义指标指南）
Doris集群监控实战：从零构建企业级可视化看板
第一次登录Doris Manager控制台时，那个简陋的监控界面让我有些失望——几个基础指标图表，连历史趋势都无法查看。直到发现它内置了Prometheus和Grafana全家桶，才意识到这是个被低估的监控利器。本文将分享如何用这套组合拳打造媲美大厂的监控体系，包括磁盘水位预警、慢查询分析等核心场景，以及最容易被忽略的自定义指标配置技巧。
1. 监控体系架构解析
Doris Manager的监控模块实际上采用了云原生监控的黄金组合：各节点上的Exporter采集指标 → Prometheus进行存储和告警计算 → Grafana实现可视化展示。这套架构的优势在于：
- 开箱即用：所有组件已预置在安装包中，无需额外部署
- 零配置对接：Grafana已预装官方仪表盘模板
- 弹性扩展：支持添加自定义Exporter采集业务指标
关键组件路径：
/opt/module/doris-manager/deps/ ├── prometheus-2.37.0.linux-amd64 ├── grafana-9.0.6 └── alertmanager-0.24.0提示：生产环境建议将Prometheus数据目录挂载到独立磁盘，避免监控数据影响系统稳定性
2. 五分钟快速启用监控看板
2.1 组件激活流程
- 登录Doris Manager控制台
- 进入"集群管理 → 监控配置"
- 开启Prometheus和Grafana服务开关
- 设置数据保留周期（默认7天）
- 点击"立即生效"按钮
首次启动约需2分钟完成组件初始化。成功后会在/opt/module/doris-manager/logs/下生成组件日志：
- prometheus.log
- grafana.log
2.2 关键监控指标说明
系统预置了六大类监控指标：
| 指标类型 | 示例指标 | 告警阈值建议 |
|---|---|---|
| 资源使用 | CPU利用率、内存占用 | CPU>80%持续5分钟 |
| 查询性能 | 99分位查询延迟、QPS | P99>500ms |
| 存储状态 | 磁盘使用率、副本健康度 | 磁盘>85% |
| 节点状态 | BE节点存活数、FE选举状态 | 存活BE<副本数+1 |
| 导入吞吐 | 导入速率、失败导入次数 | 失败率>1% |
| 元数据 | 表数量、分区增长速率 | 单日增长>1000分区 |
3. 深度定制监控看板
3.1 Grafana高级功能实战
访问http://<manager_ip>:3000（默认账号admin/admin），推荐进行以下优化：
- 仪表盘克隆：
# 备份原始仪表盘 cp /opt/module/doris-manager/deps/Doris-Dashboard.json \ /opt/module/doris-manager/deps/Doris-Dashboard-BAK.json - 添加智能告警：
- 进入Alert → New Alert Rule
- 设置磁盘预警规则：
disk_used_percent{instance=~".*be.*"} > 85
- 变量联动：
- 添加
$host变量：label_values(up, instance) - 在面板中使用
{host=~"$host"}实现动态过滤
- 添加
3.2 自定义指标接入
以监控业务表查询热度为例：
- 创建自定义Exporter（Python示例）：
from prometheus_client import start_http_server, Gauge import psycopg2 query_gauge = Gauge('doris_table_query_count', 'Query count by table', ['table']) def collect_metrics(): conn = psycopg2.connect("dbname=doris user=monitor") cur = conn.cursor() cur.execute(""" SELECT table_name, COUNT(*) FROM query_log WHERE time > NOW() - INTERVAL '1 hour' GROUP BY 1 """) for table, count in cur.fetchall(): query_gauge.labels(table=table).set(count) if __name__ == '__main__': start_http_server(8000) while True: collect_metrics() time.sleep(60)- 在Prometheus配置中添加抓取目标：
# 修改/opt/module/doris-manager/deps/prometheus.yml scrape_configs: - job_name: 'custom_metrics' static_configs: - targets: ['localhost:8000']- 重启Prometheus服务：
/opt/module/doris-manager/deps/prometheus-2.37.0.linux-amd64/prometheus \ --config.file=/opt/module/doris-manager/deps/prometheus.yml \ --web.listen-address=":9090"4. 生产环境优化指南
4.1 性能调优参数
在conf/manager.conf中增加：
# Prometheus配置 prometheus.storage.tsdb.retention.time=30d prometheus.query.max-concurrency=20 prometheus.query.timeout=10m # Grafana配置 grafana.dashboard.default_home_dashboard_path=/opt/module/doris-manager/deps/Doris-Prod-Dashboard.json4.2 高可用部署方案
当监控集群规模超过50节点时，建议：
Prometheus分片：
- 按业务线拆分采集任务
- 使用
hashmod实现水平分片：scrape_configs: - job_name: 'doris_be_metrics' relabel_configs: - source_labels: [__address__] modulus: 3 target_label: __tmp_hash action: hashmod - source_labels: [__tmp_hash] regex: ^0$ action: keep
Grafana多数据源：
- 配置Prometheus集群联邦查询
- 设置智能缓存：
[grafana] cache_enabled = true cache_max_age = 5m
5. 典型故障排查案例
场景：凌晨收到磁盘告警，但Grafana显示使用率仅60%
排查步骤：
- 确认Prometheus抓取间隔：
grep -A 3 'scrape_interval' /opt/module/doris-manager/deps/prometheus.yml - 检查BE节点实际磁盘状态：
ssh be-node-01 "df -h | grep doris" - 发现Prometheus的
disk_used_percent指标未包含数据目录挂载点 - 修改BE监控配置：
<be> <monitor> <disk_monitor_path>/data1,/data2</disk_monitor_path> </monitor> </be>
最终通过调整监控路径配置，实现了对数据盘的真实监控。这个案例让我养成了定期验证监控指标准确性的习惯——毕竟错误的监控比没有监控更危险。