手头刚好有一套生产 Oracle 库需要做可视化监控早期都是靠 shell 脚本加一堆 alert(log 查告警、盯表空间、看 AWR)人肉盯屏太累了而且图表化程度极低。后来决定上 Grafana 这套组合拳Grafana 负责大屏展示OracleDB Exporter 负责把数据库指标拉出来docker-compose 一把梭部署。折腾完以后整套监控体系基本不用管了打开浏览器就是一张深度监控大屏库里的会话、表空间、负载、等待事件、慢 SQL 一目了然。这篇文章就是把我完整搭建过程中的设计思路、配置细节和踩过的坑都捋一遍目标是让没接触过这套组合的兄弟也能照着落地。Grafana 本身就是个开源可视化平台数据源插件极其丰富配 OracleDB Exporter 属于很经典的监控组合。Exporter 的角色是“翻译官”Oracle 自身的动态性能视图V$视图里存着海量状态指标但数据库不会直接把这些指标通过 HTTP 吐出来Exporter 就是把这些 SQL 查询结果转成 Prometheus 格式的指标然后 Grafana 再去 Prometheus 里拉数据画图。docker-compose 则负责把这三个组件编排在同一个网络里一条命令拉起来避免环境依赖和端口冲突的麻烦。这套方案特别适合这几类人需要快速搭建 Oracle 监控看板又不愿意碰商业化监控软件的 DBA 或运维工程师已经在用 Prometheus 生态、想顺手纳管 Oracle 的团队还有那些被领导要求“下周就要看到数据库监控大屏”的救火队员。只要会写基本的 docker-compose 文件能看懂 YAML 语法再懂一点 SQL就能把这套东西跑起来。1. 整体设计与技术选型拆解1.1 为什么选 Grafana OracleDB Exporter 组合先说结论这套组合在“快速落地 图表丰富 社区复用”三个维度上平衡得很舒服。Oracle 本身有 OEMOracle Enterprise Manager但那是重量级商业套件装一个要占用不少资源License 还贵用 Zabbix 也能监控 Oracle但需要装 agent而且对 Oracle 特有指标的采集深度不如专门的 Exporter 细腻Prometheus 自带的 mysqld_exporter 只支持 MySQL/MariaDB不支持 Oracle。OracleDB Exporter 这个项目是社区里专门针对 Oracle 做的把常见的数据库健康指标都转成了 Prometheus 格式比如会话数、活跃会话、表空间使用率、SGA/PGA 内存、物理读/写、重做日志切换频率、等待事件等基本覆盖了日常巡检需要看的核心维度。Grafana 本身不存指标数据它只管展示。数据流是这样的OracleDB Exporter 通过 JDBC 连接到 Oracle 数据库周期性执行采集 SQL然后把指标暴露在一个 HTTP 端口上Prometheus 按配置的 scrape 间隔去拉取这些指标Grafana 配置 Prometheus 作为数据源再用我们导入或自建的 Dashboard 把指标可视化成图表、仪表盘、表格。我选择 docker-compose 而不是直接宿主机装二进制最大原因是环境隔离和可复制性。宿主机上装 Exporter 需要 JDK、依赖库、环境变量一旦迁移或者换机器就非常痛苦容器化以后所有依赖都锁在镜像里换个机器只要照着 compose 文件跑起来就行。而且 docker-compose 可以让 Grafana、Prometheus、Exporter 三个服务通过自定义网络互访不用把端口全暴露到公网安全性也好一些。1.2 监控大屏的指标体系设计设计一张深度监控大屏先别急着找模板而是要想清楚这屏给谁看、看什么。我给生产库做监控时按“数据库健康度三层模型”来规划第一层是“可用性”也就是库能不能连、实例是不是活着、监听是否是通的第二层是“资源消耗”CPU、内存、物理 IO、会话数、锁等待这些决定系统还能不能扛得住第三层是“性能质量”包括慢 SQL、等待事件、重做日志切换频率、Buffer Cache 命中率等这一层直接影响业务感知和调优方向。具体到面板我的大屏分成四行区域第一行主打“实例总览”包括实例状态、当前时间、数据库版本、主机名、启动时间、累计运行天数、当前活动会话数、当前总会话数第二行主打“资源水位”包括 CPU 使用率通过操作系统指标或数据库内部统计、SGA 和 PGA 使用率、物理读/写速率、日志切换次数/天第三行主打“表空间与文件”列一个表格显示每个表空间的总大小、已用空间、使用率、数据文件数并按使用率排序第四行主打“性能与等待”包括 Top 等待事件、Top SQL 的逻辑读/物理读、Buffer Cache 命中率、Library Cache 命中率、活跃会话历史趋势。这样一行一主题视觉上不会挤成一团排查问题时按区域找指标也快。1.3 docker-compose 编排的整体思路编排文件的核心是把三个服务放在同一个 bridge 网络里让服务名作为内部 DNS 互相解析。我习惯把 Exporter 和 Prometheus 放在一个自定义网络mon-net里Grafana 也挂同一个网络。下面给出一版完整的 compose 文件后面再逐步解释关键部分version: 3.8 services: oracle-exporter: image: sjetet/oracle_exporter:latest container_name: oracle-exporter environment: - DATA_SOURCE_NAMEoracle://system:your_passwordoracle-host:1521/ORCLPDB1 - ORACLE_EXPORTER_PASSWORDyour_password ports: - 9161:9161 restart: unless-stopped networks: - mon-net prometheus: image: prom/prometheus:latest container_name: prometheus volumes: - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml:ro - prom-data:/prometheus command: - --config.file/etc/prometheus/prometheus.yml - --storage.tsdb.retention.time15d ports: - 9090:9090 restart: unless-stopped networks: - mon-net grafana: image: grafana/grafana:latest container_name: grafana environment: - GF_SECURITY_ADMIN_USERadmin - GF_SECURITY_ADMIN_PASSWORDstrong_password - GF_USERS_ALLOW_SIGN_UPfalse volumes: - grafana-data:/var/lib/grafana ports: - 3000:3000 depends_on: - prometheus restart: unless-stopped networks: - mon-net volumes: prom-data: grafana-data: networks: mon-net: driver: bridge需要注意Oracle 实例所在地可能是宿主机、另一台服务器或云上 RDSoracle-host要替换成实际可达地址如果 Oracle 就在宿主机上端口又映射了 1521那这里可以直接填宿主机 IP 或者 docker 网关地址。因为容器里面访问宿主机的 IP 和宿主机自己访问 localhost 不一样填 localhost 是肯定不通的。2. OracleDB Exporter 核心细节与运行原理2.1 Exporter 的工作原理和指标来源OracleDB Exporter 项目在 GitHub 上叫sjetet/oracle_exporter它的典型实现方式是基于 Java 的 JDBC 驱动去连 Oracle然后周期性执行一堆预先写好的 SQL 查询。这些查询大多是查v$instance、v$session、v$sysstat、v$tablespace、v$datafile、v$waitclass这些动态性能视图。每次查询结果会转换成带prefix的 Prometheus 指标比如oracle_activity_count、oracle_table_space_used_bytes、oracle_physical_read_bytes等等。这里有个很关键的点Exporter 本身是拉(Pull)模型里的“被采集端”Prometheus 定期去访问它的 9161 端口拿指标。所以 Exporter 容器只要能连到 Oracle 就行不需要在 Oracle 主机上装任何额外的 agent这一点对云端 RDS 或者不允许安装第三方软件的核心库特别友好。为了安全尽量用只读账号来采集赋予它查询动态性能视图的权限即可不要用 sysdba 级别的账号。后面我会给一个最小权限 SQL 模板。2.2 镜像选择与版本兼容性sjetet/oracle_exporter 这个镜像比较常用但对 Oracle 版本和 JDBC 驱动版本有讲究。如果你的 Oracle 是 19c默认驱动通常没问题如果是 Oracle 12c 或者更高的版本建议先手动拉镜像跑一下看日志里有没有 JDBC 连接错误。新版镜像一般内置了 ojdbc11 之类的驱动兼容性比旧版好。官方镜像还有另一个选择比如cnang / oracle_exporter或者quay.io/...不同镜像的环境变量名有差异比如有的用ORACLE_EXPORTER_DSN有的用DATA_SOURCE_NAME。我按上面那个sjetet/oracle_exporter来写因为它支持DATA_SOURCE_NAME这个通用环境变量和 Prometheus 生态里其他 exporter 保持一致比较好记。下载镜像时可以手动docker pull sjetet/oracle_exporter:latest看能否正常拉取避免 compose 执行时卡在拉镜像上。有些网络环境拉 ghcr.io 或 docker hub 都比较慢建议配置镜像加速器。这个属于基础操作就不展开了。2.3 数据库账号与最小权限配置千万不要用 system 或者 sys 账号跑采集生产库的审计和安全策略会盯得很紧。我一般会创建一个专用账号CREATE USER grafana_monitor IDENTIFIED BY Strong_pass_123; GRANT CONNECT TO grafana_monitor; GRANT CREATE SESSION TO grafana_monitor; GRANT SELECT ON v_$instance TO grafana_monitor; GRANT SELECT ON v_$session TO grafana_monitor; GRANT SELECT ON v_$sysstat TO grafana_monitor; GRANT SELECT ON v_$tablespace TO grafana_monitor; GRANT SELECT ON v_$datafile TO grafana_monitor; GRANT SELECT ON v_$waitclass TO grafana_monitor; GRANT SELECT ON v_$sgastat TO grafana_monitor; GRANT SELECT ON v_$pgastat TO grafana_monitor; GRANT SELECT ON v_$parameter TO grafana_monitor; GRANT SELECT ON v_$process TO grafana_monitor; GRANT SELECT ON dba_data_files TO grafana_monitor; GRANT SELECT ON dba_free_space TO grafana_monitor; GRANT SELECT ON dba_tablespaces TO grafana_monitor; GRANT SELECT ON v_$log TO grafana_monitor; GRANT SELECT ON v_$logfile TO grafana_monitor; GRANT SELECT ON v_$tempfile TO grafana_monitor; GRANT SELECT ON dba_temp_files TO grafana_monitor;注意有些 v$ 视图名称里有下划线授予权限时要用带引号的别名写法像v_$session代表的是v$session的同义词。Oracle 里无引号标识符大写所以GRANT SELECT ON v_$session是对的。连接串的格式一般是oracle://用户名:密码主机:1521/服务名注意服务名和 SID 的区别。如果你的库用的 SID 而不是服务名需要写/SID吗通常 Exporter 的 JDBC 连接串用服务名PDB 场景推荐用 PDB 的服务名比如ORCLPDB1。如果测试发现连不上可以试试在地址后面加?poolfalse或调整 JDBC 参数但多数情况默认就行。2.4 环境变量与采集参数调优Exporter 容器内部是通过 JAVA_OPTS 和几个典型环境变量来控制行为的。常见的变量除了DATA_SOURCE_NAME还有ORACLE_EXPORTER_PORT默认 9161一般不用改。ORACLE_EXPORTER_QUERY_INTERVAL采集间隔单位秒默认 60。ORACLE_EXPORTER_QUERY_TIMEOUT单条 SQL 超时时间默认 5 秒。LOG_LEVEL日志级别默认 info排查问题可改成 debug。模拟 Prometheus 的抓取频率Exporter 自己会维护一个指标缓存。也就是说 Prometheus 抓的指标不一定是实时查询的而是 Exporter 内部按固定间隔从 Oracle 查出来的。所以会出现“Grafana 上数据有 1 分钟延迟”的正常现象。如果你需要秒级监控可以把间隔调到 15 秒但注意别太频繁每次查询视图本身也有成本特别是v$session这类视图频率太高会加大数据库负担。我一般生产环境设置为 60 秒足够满足告警和日常巡检需求。3. Prometheus 与 Grafana 配置实操过程3.1 配置 Prometheus 拉取 Exporter 指标在项目目录下新建prometheus/prometheus.yml文件内容如下global: scrape_interval: 60s evaluation_interval: 60s scrape_configs: - job_name: oracle-exporter static_configs: - targets: [oracle-exporter:9161] labels: instance: oracle-prod-01这里有个细节targets写的是oracle-exporter:9161而不是宿主机 IP。因为在 compose 网络里docker 会为每个服务分配 DNS服务名就是主机名。Prometheus 容器想访问 Exporter 容器直接通过服务名解析即可不用关心 IP 变化。如果你想让 Grafana 面板上显示业务库名就在 labels 里加instance一般值写库的主机名或业务标识后面面板可以按这个 label 过滤。用docker compose up -d启动后Prometheus 会默认从 target 地址拉取指标。怎么验证是否拉取成功打开浏览器访问 Prometheus 的 9090 端口进Status Targets能看到oracle-exporter这个 job 的状态如果出现UP说明拉取正常如果是DOWN点进去看错误信息最常见的错误就是连接被拒绝或者超时。也可以用命令行验证 Exporter 的 9161 端口是否能正常输出指标curl -s http://localhost:9161/metrics | head -n 30如果能输出oracle_开头的指标说明 Exporter 本身工作正常。3.2 Grafana 添加 Prometheus 数据源Grafana 启动后访问http://服务器IP:3000默认账号密码在 compose 里已经设置。第一次登录会提示修改密码如果是刚部署我就直接改了。然后按下面的路径添加数据源左侧导航栏点击 Configurations齿轮图标选择 Data sources点击 Add data source选择 Prometheus在 HTTP 栏目里填 URLhttp://prometheus:9090点击 Save Test看到绿色提示即可这里也要注意Grafana 容器里访问 Prometheus 也应该用 compose 服务名prometheus而不是localhost或宿主机 IP。如果你在宿主机浏览器里输http://localhost:9090能访问那是宿主机端口映射生效但 Grafana 容器内部并不能直接用 localhost 访问到 Prometheus 容器。很多新手在这里容易卡住。填好数据源以后导入模板前先点 Explore输入一个最简单的指标名比如oracle_activity_count看看有没有数据返回。这一步非常关键能帮你确认数据链路是不是通的。如果 Explore 有数据后面导入模板基本不会有大的方向性问题如果没数据先别去折腾仪表盘回头检查 Prometheus 的 target 状态和 Exporter 日志。3.3 导入现成模板与自定义大屏配置Grafana 支持直接导入 JSON 格式的 Dashboard。GitHub 上有很多现成的 OracleDB Exporter 模板搜索 keyword“sjetet oracle_exporter dashboard json”就能找到。我用的那套是社区里几百星项目的自带模板oracledb_exporter_dashboard.json里面有实例信息、表空间、等待事件、IO、内存等一堆 panel。导入方法在 Grafana 左侧点击 Dashboards然后选择 ImportUpload 对应的 JSON 文件选择数据源为刚才创建的 Prometheus点击 Import如果第一次导入后发现某些面板显示 No data不用慌多数是模板里的指标名和当前 exporter 版本指标名对不上。比如模板里写的是oracle_tablespace_used_bytes而你当前的 exporter 导出的指标实际叫oracle_table_space_used_bytes只需要点开面板编辑在 Metrics 字段里把指标名改正确就行。查询数据可以按指标名过滤在 Grafana Explore 页面输入一个指标名然后看自动补全列表里有没有就能快速确认实际指标名。自定义大屏时我最常加的两个面板表空间使用率排行榜Bar Gauge查询语句类似100 * (oracle_tablespace_used_bytes / oracle_tablespace_size_bytes)按表空间名称维度用by (tablespace_name)聚合。如果数据比较杂,用 Top 5/10 排序看起来更清爽。活跃会话数趋势Time seriesoracle_activity_count如果想把“当前活跃会话”“当前总会话”分开显示可以在查询里加不同的 label 过滤。具体 label 名要看 exporter 指标输出例如oracle_activity_count可能带type标签写查询时先用 Explore 摸清楚结构再画图。3.4 配置告警规则Grafana 的 Alerting 功能比较强大可以直接基于面板查询创建告警。在 Grafana 9 及以后的版本里点到 Alerting 页面选择 New alert rule。告警规则两个核心要素条件表达式和触发阈值。比如表空间使用率超 85% 告警表达式可以写max by (tablespace_name) (100 * (oracle_tablespace_used_bytes / oracle_tablespace_size_bytes)) 85然后设置 Evaluate every 60sFor: 5m意思是持续 5 分钟超过 85% 才触发避免瞬时抖动误报。告警通知渠道可以接钉钉、飞书、企业微信、邮件。如果不想搞太复杂可以先钉钉 webhookGrafana 内置的 Alertmanager 可以直接转发。但要注意Grafana 的告警评估是在 Grafana 内部完成的不是 Prometheus 的 alertmanager所以只要 Grafana 容器能访问外网 webhook 就行和 Prometheus 无关。我生产环境的告警规则一般分三级指标告警条件级别处理建议实例存活up 0 持续 1 分钟P1 紧急立刻检查实例/监听活跃会话数oracle_activity_count 50 持续 10 分钟P2 警告排查慢 SQL 与阻塞表空间使用率超 85% 持续 5 分钟P2 警告清理空间或扩容Buffer Cache 命中率 90% 持续 10 分钟P3 提示调优或调整 SGA物理读速率与基线对比超 2 倍P3 提示关注 IO 瓶颈4. 实操中的常见问题与排查实录4.1 Exporter 容器日志中频繁出现 ORA-01017/ORA-12505这两个 Oracle 错误刚好对应两类问题ORA-01017 是用户名或密码错误ORA-12505 是监听无法识别连接描述符里的 SID/服务名。排查思路很简单先在宿主机上用一个 oracle 客户端测试连接串确认信息无误后再在 compose 文件里检查环境变量。我遇到过最冤的情况是密码里有特殊字符比如、$、#在 YAML 里没有用单引号包裹导致连接串被截断。YAML 里DATA_SOURCE_NAME: oracle://user:abc123host:1521/ORCL这种写法会把abc当用户名、123host...当密码指定不是期望的格式很容易报 ORA-01017。解决方式整个连接串用单引号引起来并且把特殊字符按 URL 编码处理比如写成%40#写成%23。我后来直接改用ORACLE_EXPORTER_PASSWORD单独传密码的方式连接串里用户名后面留空由 exporter 自己拼装规避了一大类特殊字符问题。某些 exporter 镜像支持这种用法environment: - DATA_SOURCE_NAMEoracle://grafana_monitororacle-host:1521/ORCLPDB1 - ORACLE_EXPORTER_PASSWORDxxxxxxxx如果镜像不支持分离密码就老老实实用单引号包连接串并且做 URL 编码。4.2 Grafana 面板 Time zone 显示错乱导致图表空白Grafana 默认用浏览器的时区如果你的浏览器时区不对图表上时间轴可能显示空白或者偏移 8 小时。表面上看起来是数据问题实际上是显示时区问题。解决方法在 Dashboard 设置的 Settings 里Timeline 时区选 UTC或者统一选 08:00。还有一种情况是 Prometheus 的 scrape 时间戳和 Grafana 当前时间不一致通常是容器系统时间没同步。进入容器执行date看看如果偏差大在宿主机上配好 chrony 或者 systemd-timesyncd容器时区可以通过挂载/etc/localtime解决。最省事的做法是在 compose 里给每个服务加environment: - TZAsia/Shanghai4.3 表空间指标出现 NaN 或 no data表空间指标算使用率的时候因为某些表空间大小指标没有采集到导致分母为 0从而出现 NaN。比如临时表空间、undo 表空间可能没有对应的oracle_tablespace_size_bytes或者 exporter 版本对dba_temp_files的处理方式不一样。解决办法在 PromQL 里加or条件把缺失值置为 0例如100 * (oracle_tablespace_used_bytes / (oracle_tablespace_size_bytes oracle_tablespace_temp_size_bytes))或者直接用一个自带指标oracle_tablespace_usage_percent如果当前 exporter 版本支持的话。写查询语句之前先在 Explore 里搜oracle_tablespace看有哪些 metrics 名再按实际情况加工别盲目套模板。4.4 Exporter 内存占用越来越高Java 类的 exporter 都有一个通病JVM 默认堆比较大容器内存限制没设置好就容易 OOM 或被宿主机 kill。exporter 镜像的默认 JAVA_OPTS 可能包含-Xmx256m到-Xmx512m不等如果数据库实例数多、查询指标多内存会明显涨。解决方式在 compose 里给 exporter 服务加memory限制比如mem_limit: 512m通过环境变量传入JAVA_OPTS-Xms64m -Xmx256m限制堆大小如果监控多个 Oracle 实例建议一个容器只监控一个实例搞一套“多 exporter 多 job”的结构避免把全部采集压在一个进程上。另一个常见问题是 Prometheus 的 TSDB 存储无限增长。compose 里我加了--storage.tsdb.retention.time15d这能控制保留 15 天避免把磁盘打满。磁盘打满堪称监控系统最隐蔽的杀手它不会立刻报错会在某天把 Prometheus 写挂然后所有 dashboard 变 No data。一定提前规划好数据保留策略。4.5 端口冲突与被防火墙拦宿主机已经占用 9090、3000、9161 时compose 里端口映射会报address already in use。要么改宿主机侧端口比如9091:9090要么停掉占用进程。还有云服务器安全组必须放行 3000 端口否则浏览器访问不了 Grafana。这些相对简单但确实是我见过最多的卡壳点。另外如果部署在 docker swarm 环境compose 文件版本和 deploy 配置要不一样本文这套单机docker compose up -d足够覆盖绝大多数场景。4.6 指标名称对不上模板的终极排查方法遇到面板 No data 时第一反应不是猜而是按顺序排查先看 Grafana Explore 里能不能查到指标查不到就继续往下看 Prometheus Targets 是否 UP没 UP 就去看 Exporter 容器日志用 curl 直接访问 Exporter 9161 端口看输出里有没有oracle_前缀的指标对比面板查询里的指标名和实际导出指标名只要名字一致数据几分钟内就会出来。有时模板里用了job或instance标签过滤job名默认是你 compose 里写的 job_nameinstance默认是 target 地址。如果面板选定的值是旧环境里的 job 名也会导致查不到数据。在 Dashboard 变量设置里或者查询语句里把 job 名改成oracle-exporter把 instance 改成自己的 label 即可。整体思路就是数据链路一定是“Oracle - Exporter - Prometheus - Grafana”任何一环出问题从最源头开始定位永远最快。5. 告警通知与权限加固的最佳实践5.1 通过 Webhook 接入钉钉或飞书告警Grafana 9 的告警规则可以直接指定联系人策略。以钉钉为例先在钉钉群里添加一个自定义机器人拿到 Webhook 地址。然后在 Grafana 里创建 Contact point类型选择 WebhookURL 填钉钉机器人地址。需要注意钉钉机器人安全设置里有关键词过滤比如我设置关键词“Grafana”或“告警”那告警消息里必须包含对应关键词否则会被钉钉拦截。实际踩过这个坑全部配好后测试告警群里死活收不到后来把消息模板里加了个固定前缀才解决。Prometheus 自身的 alertmanager 也能做这件事但为了减少链路组件我直接让 Grafana 告警发 webhook。告警规则里可以设for: 5m对持续时间做约束。如果你担心告警风暴还可以在 Notification policy 里设置分组把同一实例的告警聚合到一条消息里发送不设置 grouping 的话几十个表空间同时超阈值会瞬间轰炸群聊。5.2 避免 Exporter 账号密码泄露docker-compose 文件直接写在服务器上DATA_SOURCE_NAME的密码肉眼可见有一定风险。如果环境支持可以用 docker secret 或环境变量文件.env来管理敏感信息比如environment: - DATA_SOURCE_NAME${ORACLE_DSN}然后把真正的连接串放在.env文件里并设置.env权限 600。虽然 docker inspect 还是能看到运行时环境变量但至少避免 compose 文件本身被随意复制泄露。对安全要求更高的场景可以研究 Oracle 的 Wallet 方案不过对于内部监控系统用.env隔离已经算是个不错的折中。5.3 Grafana 用户权限与匿名访问监控大屏做出来以后难免有同事想“看一眼”。建议给 Grafana 创建只读的 View 用户把 Dashboard 权限设为该用户只读。如果需要投到办公室电视上,可以配置匿名访问environment: - GF_AUTH_ANONYMOUS_ENABLEDtrue - GF_AUTH_ANONYMOUS_ORG_ROLEViewer但匿名访问只建议在内网环境开且只能在不需要交互操作的展示屏上使用。否则别人也能看到所有面板数据生产域名和 IP 容易泄露。我一般做法是给展示屏单独配一个浏览器账号开机自动打开大屏 URL避免全局开匿名权限。5.4 数据持久化与备份策略compose 里 Grafana 和 Prometheus 都用了命名 volume 做持久化这样容器升级或重启不会丢配置和历史数据。volume 的数据在/var/lib/docker/volumes/下面备份时可以直接用docker run挂载 volume 打 tar 包也可以定期把 Prometheus 的 TSDB 目录单独快照。Grafana 的 Dashboard 定义建议导出 JSON 备份到 git 仓库这样即使 Grafana 数据卷损坏也能快速恢复看板。我自己的习惯是每次改完看板立即导出一份 JSON 放到配置管理目录里这算是最便宜的备份方式。6. 最终效果与后期扩展方向整套搭建完成以后,大屏上能看到的指标大概有几十项覆盖了实例状态、会话、表空间、IO、内存、等待事件、慢 SQL 等维度。我自己用的这套从启动 compose 到全部指标刷出来前后不到半小时剩下的时间大多花在调试面板指标名上。对比之前的脚本巡检现在每天上班只需要扫一眼大屏异常数据自然会通过告警推送到群里人盯屏幕的压力小了很多。这个方案还能继续往更完整的可观测性体系扩展。比如用node_exporter监控数据库宿主机的 CPU、内存、磁盘再结合这套数据库指标就能把“数据库 操作系统”放在一个大屏里看用 Loki 把 Oracle 的 alert 日志和监听日志收集起来做日志检索用 Prometheus 的 recording rules 提前算好一些高频指标的聚合值减少 Grafana 查询时的计算压力。如果你有多个环境生产、预发、测试可以给每个环境部署一组 composer 项目用不同的job_name和instance标签区分在 Grafana 里通过一个下拉变量切换环境查看。最后分享一个我踩过多次坑后的个人习惯任何改动包括 compose 文件、Prometheus 配置、Grafana 看板 JSON都要先在测试环境验证再上生产。别觉得改个告警阈值没什么影响有一次我在生产上调 table 空间告警表达式手滑把写成了当天下午表空间涨到 95%告警没触发倒是业务先报警了。从那以后我再也不敢在生产上临时改监控配置所有规则改动都先在一个副本环境里跑一遍确认无误再说。监控系统看似是个辅助工具但它的稳定性直接影响到我们对数据库异常的感知速度值得像对待生产代码一样谨慎对待。