1. 从零到一为什么需要监控达梦数据库在任何一个稍微有点规模的业务系统里数据库都是那个最核心、也最让人提心吊胆的组件。它要是打个喷嚏整个应用都得跟着感冒。我这些年经手过不少国产化替代的项目达梦数据库DM作为国产数据库的佼佼者出现的频率越来越高。从早期的Oracle迁移到新系统的选型达梦的身影无处不在。但问题也随之而来。以前用Oracle、MySQL监控生态已经非常成熟Zabbix模板、Prometheus Exporter一抓一大把告警规则也都有现成的社区最佳实践可以参考。换成达梦之后很多团队一下子就抓瞎了。数据库现在到底健不健康连接池是不是快满了有没有慢SQL正在拖垮系统磁盘空间还够用吗这些在运维眼里本该是“透明”的信息一下子变成了黑盒。这就是为什么我们需要把达梦数据库纳入到现代化的监控体系里尤其是像Prometheus这样的云原生监控事实标准。Prometheus的拉模型、多维数据模型和强大的PromQL查询语言能让我们用一套统一的语言去描述和告警所有基础设施的状态。给达梦配上Prometheus监控不是为了赶时髦而是为了把运维的“眼睛”重新装上把那种对核心组件运行状态“心里没底”的焦虑感彻底消除。这不仅仅是技术实现更是保障业务连续性的基础设施必选项。2. 监控蓝图设计达梦数据库需要关注哪些核心指标在动手部署Exporter之前我们必须先想清楚到底要监控什么漫无目的地收集一堆数据除了增加存储负担和制造告警噪音没有任何意义。对于达梦数据库我们可以从四个维度来构建监控蓝图这基本覆盖了从数据库服务本身到内部运行状态的方方面面。2.1 第一维度数据库服务可用性与连接状态这是最基础的监控回答“数据库还活着吗”以及“应用能连上吗”这两个根本问题。服务存活up指标这是Prometheus通过抓取Exporter端点自动生成的基础指标。如果up{jobdameng} 0直接意味着Exporter抓取失败数据库服务可能宕机或网络不通。这是最高优先级的告警。会话与连接数监控当前活跃会话数、总连接数以及配置的最大连接数。连接数缓慢增长可能预示连接池泄漏连接数瞬间打满则很可能前端有突发流量或出现连接风暴。关键是要计算连接数使用率当前连接数 / 最大连接数。我们一般会为这个使用率设置两个阈值超过80%告警Warning超过95%则必须紧急处理Critical。锁等待查询当前处于锁等待状态的会话数。即使数据库CPU、内存都很空闲一个行锁或表锁也可能阻塞大量业务请求造成应用超时。监控锁等待数量及其持续时间是定位数据库层面“慢”的关键。2.2 第二维度资源消耗与性能表现数据库是资源消耗大户这一层监控告诉我们数据库“累不累”。CPU与内存使用率通过Exporter间接获取数据库进程的CPU和内存占用。需要注意的是达梦数据库有独立的缓冲池、SQL缓存池等这些内存是从操作系统分配后由数据库自己管理的。因此除了看操作系统的内存使用更要关注数据库内部缓冲池的命中率。磁盘I/O监控数据文件、日志文件所在磁盘的读写吞吐量IOPS和延迟Latency。高延迟的磁盘I/O是数据库性能的隐形杀手。特别是达梦的重做日志REDO LOG写入如果延迟过高会直接影响事务提交速度。缓冲池效率这是数据库特有的核心指标。达梦的缓冲池BUFFER类似于Oracle的SGA或MySQL的InnoDB Buffer Pool。我们需要监控缓冲池命中率计算公式为(逻辑读 - 物理读) / 逻辑读。命中率长期低于95%意味着很多数据无法从内存中获取需要频繁读盘性能会急剧下降。这可能意味着缓冲池大小设置不合理或者业务存在全表扫描等非优化查询。缓冲池读写活动监控每秒的物理读/写次数了解数据库真实的磁盘I/O压力。2.3 第三维度存储容量与增长趋势“磁盘满了”是生产环境最经典的故障之一必须防患于未然。表空间使用率达梦数据库通常有SYSTEM系统、ROLL回滚、TEMP临时、MAIN用户数据等多个表空间。需要监控每个表空间的已用空间、总空间并计算使用率。对于主要业务表空间如MAIN使用率超过85%就应触发扩容预警。归档日志空间如果数据库开启了归档模式归档日志目录的磁盘空间必须严格监控。一旦归档目录满数据库会因无法生成新的归档日志而挂起所有DML操作导致业务完全停摆。数据文件增长趋势利用Prometheus的rate()或increase()函数可以计算表空间在过去一段时间如24小时内的增长量预测剩余可用天数。这对于容量规划至关重要。2.4 第四维度SQL与业务健康度这一层直接关联业务体验是高级监控的体现。慢SQL查询监控执行时间超过特定阈值如1秒、5秒的SQL语句及其执行频率。需要获取SQL文本、执行计划、累计执行时间等信息。慢SQL是性能问题的“罪魁祸首”需要定期Review并优化。事务状态监控活跃事务数、长时间未提交的事务长事务。长事务不仅会占用锁资源还可能产生大量的回滚段信息影响数据库整体性能。备份状态监控最近一次全量备份和增量备份的成功与否、完成时间及耗时。备份是数据安全的最后防线其状态必须纳入监控告警。有了这份清晰的监控蓝图我们就能有的放矢地去寻找或开发对应的Exporter来采集这些关键指标。3. 核心工具选型没有官方Exporter我们怎么办这是监控达梦数据库的第一个现实挑战Prometheus官方社区没有提供达梦数据库的Exporter。但这在开源世界和国产软件生态中很常见我们通常有几条路径可以走。3.1 路径一使用开源社区Exporter推荐首选经过社区的发展目前已经有了一些相对成熟的开源达梦Exporter。这是最省时省力的方式。dm_exporter这是目前GitHub上能找到的、相对活跃的一个项目。它通常通过达梦数据库的JDBC驱动连接执行一系列预定义的SQL查询就是我们上一章提到的那些监控指标对应的SQL然后将结果解析为Prometheus规范的指标格式metric格式暴露出来。如何评估与选择看活跃度查看GitHub仓库的最近提交时间、Issue和PR的响应情况。一个最近半年内有更新的项目通常更可靠。看支持版本确认Exporter支持的达梦数据库版本如DM8避免因版本不兼容导致无法获取指标或获取错误指标。看指标覆盖对照我们第二章设计的监控蓝图检查该Exporter是否提供了核心的指标。至少要有连接数、表空间使用率、缓冲池命中率、锁信息等。看部署方式是否提供Docker镜像、二进制包或者清晰的源码编译指南。注意使用任何第三方Exporter前务必在测试环境进行充分验证。重点检查1. 采集是否稳定会不会有内存泄漏或连接不释放。2. 指标标签label设计是否合理便于在Grafana中聚合和筛选。3. 采集SQL本身是否高效避免对生产数据库造成性能压力。3.2 路径二基于现有Exporter二次开发如果找到的社区Exporter功能不全或者某些关键指标如特定的业务表数据量无法获取可以考虑在其基础上进行二次开发。开发语言大多数数据库Exporter使用Go语言编写因为Prometheus生态本身是Go系的如MySQL的mysqld_exporter。如果你找到的dm_exporter也是Go写的那么修改起来会相对容易。核心任务二次开发主要是修改或添加collector。每个collector负责一类指标的采集。你需要在达梦数据库中编写能够准确获取目标指标的SQL语句。在Exporter代码中新增一个对应的collector结构体和方法。在该方法中执行SQL并将返回的每一行数据映射为Prometheus的Gauge,Counter等指标类型并打上合适的标签如tablespace_name,sql_id。示例添加一个“自定义业务表行数”的Collector。假设我们需要监控某张核心业务表orders的行数增长情况。我们可以新增一个business_table_collector.go在其中执行SELECT COUNT(*) AS cnt FROM orders然后将结果cnt输出为一个名为dm_business_table_rows的Gauge指标并加上table_nameorders的标签。3.3 路径三自定义脚本标准Exporter这是一个更灵活、门槛相对较低的方案适合运维团队快速上手。其核心思想是用你熟悉的脚本Shell/Python定期查询数据库然后将结果“推”或“拉”到Prometheus能识别的格式中。方案A使用Node Exporter的Textfile Collector这是我最推荐给初学者的方法。Node Exporter 除了采集机器指标还提供了一个--collector.textfile.directory参数。你可以让自定义脚本定期通过cron运行将查询结果写成Prometheus格式的.prom文件放到指定目录。Node Exporter会自动读取这些文件并暴露指标。步骤写一个Python脚本dm_monitor.py使用达梦的Python驱动如dmPython连接数据库执行SELECT ...查询。将查询结果格式化为Prometheus文本格式。例如表空间使用率dm_tablespace_usage_percent{tablespaceMAIN} 75.5。将输出写入/var/lib/node_exporter/textfile_collector/dm_metrics.prom。配置一个cron任务每分钟执行一次该脚本。启动Node Exporter时加上参数--collector.textfile.directory/var/lib/node_exporter/textfile_collector。优点简单无需单独部署和监控一个Exporter进程指标直接由Node Exporter统一暴露。脚本语言选择自由。缺点采集周期依赖于cron实时性稍差分钟级。需要确保脚本输出的指标格式绝对正确否则Node Exporter会解析失败。方案B使用Prometheus Pushgateway适用于临时性、批处理作业的监控。对于数据库监控这种需要持续抓取的场景不如Textfile Collector优雅一般不推荐作为主方案。对于大多数团队我建议的路径是优先尝试并适配一个开源社区维护的dm_exporter。如果不能满足全部需求再采用“社区Exporter Textfile Collector补足自定义指标”的混合模式。这样可以平衡效率、稳定性和灵活性。4. 实战部署以dm_exporter为例的安装与配置详解假设我们选择了一个基于Go开发的、兼容DM8的dm_exporter。下面我们来一步步完成在生产环境中的部署与配置。这里我们以在数据库服务器本地部署为例。4.1 环境准备与依赖安装达梦数据库确保达梦数据库假设为DM8已安装并运行并知道连接信息IP、端口、服务名、用户名、密码。需要创建一个专用于监控的数据库用户授予其查询系统视图如V$SESSIONS,V$TABLESPACE,DBA_DATA_FILES等的只读权限。切忌使用SYSDBA等超管账号进行监控采集这是安全红线。-- 示例创建监控用户请在达梦数据库管理工具中执行 CREATE USER MONITOR IDENTIFIED BY “YourStrongPassword123”; GRANT SELECT ON SYS.“V$SESSION” TO MONITOR; GRANT SELECT ON SYS.“V$TABLESPACE” TO MONITOR; GRANT SELECT ON SYS.“DBA_DATA_FILES” TO MONITOR; -- ... 根据Exporter需要的视图继续授权服务器准备一台可以访问达梦数据库的Linux服务器可以是数据库本机也可以是独立的监控机。安装基础的编译和运行环境。# 安装Go语言环境如果Exporter需要编译 wget https://golang.org/dl/go1.19.linux-amd64.tar.gz sudo tar -C /usr/local -xzf go1.19.linux-amd64.tar.gz echo “export PATH$PATH:/usr/local/go/bin” ~/.bashrc source ~/.bashrc go version # 安装Git sudo yum install git -y # CentOS/RHEL # 或 sudo apt install git -y # Ubuntu/Debian4.2 获取与编译dm_exporter我们假设从GitHub克隆并编译。# 1. 克隆仓库 git clone https://github.com/某个作者/dm_exporter.git cd dm_exporter # 2. 检查README.md看是否有特殊的依赖或构建指令 # 通常使用go mod进行构建 go mod tidy go build -o dm_exporter main.go # 3. 编译成功后当前目录会生成 dm_exporter 二进制文件 ls -lh dm_exporter如果项目提供直接下载的二进制包那会更简单。总之目标是得到一个可执行的dm_exporter文件。4.3 配置与启动ExporterExporter通常通过环境变量或命令行参数来接收数据库连接信息。绝对不要将密码硬编码在命令行或脚本中创建系统服务推荐使用Systemd来管理Exporter进程实现开机自启和故障重启。sudo vim /etc/systemd/system/dm_exporter.service编辑服务文件内容如下。这里我们使用环境变量文件来传递敏感信息。[Unit] DescriptionPrometheus Exporter for Dameng Database Afternetwork.target [Service] Typesimple Userprometheus # 建议创建一个非root用户来运行 Groupprometheus # 指定环境变量文件路径 EnvironmentFile/etc/default/dm_exporter # 启动命令从环境变量读取配置 ExecStart/usr/local/bin/dm_exporter \ --db.host${DM_HOST} \ --db.port${DM_PORT} \ --db.user${DM_USER} \ --db.password${DM_PASSWORD} \ --db.service${DM_SERVICE_NAME} \ --web.listen-address:9288 # 暴露指标的端口可自定义 Restartalways RestartSec10 [Install] WantedBymulti-user.target创建环境变量文件sudo vim /etc/default/dm_exporter# 达梦数据库连接信息 DM_HOSTlocalhost DM_PORT5236 DM_USERMONITOR DM_PASSWORDYourStrongPassword123 DM_SERVICE_NAMEDMSERVER关键安全步骤修改环境变量文件的权限确保只有root和所需用户可读。sudo chown root:prometheus /etc/default/dm_exporter sudo chmod 640 /etc/default/dm_exporter启动并测试服务sudo systemctl daemon-reload sudo systemctl start dm_exporter sudo systemctl enable dm_exporter sudo systemctl status dm_exporter # 检查状态是否正常 # 测试指标是否能正常获取 curl http://localhost:9288/metrics如果curl命令返回大量以dm_或promhttp_开头的文本行说明Exporter部署成功正在暴露指标。4.4 配置Prometheus抓取现在我们需要告诉Prometheus服务器去哪里抓取这个新的监控目标。编辑Prometheus服务器的配置文件prometheus.yml。在scrape_configs部分添加一个新的job。scrape_configs: - job_name: ‘dameng’ static_configs: - targets: [‘dm_exporter所在服务器的IP:9288’] # 替换为实际IP和端口 labels: instance: ‘prod-dm-01’ # 给这个实例一个易读的标签 env: ‘production’ # 可以调整抓取间隔默认为1分钟对于数据库监控可以接受 # scrape_interval: 30s # 建议为关键Exporter配置更长的超时时间因为查询SQL可能耗时 scrape_timeout: 30s重启或热重载Prometheus配置。# 如果Prometheus有systemd服务 sudo systemctl reload prometheus # 或者使用HTTP API如果启用 curl -X POST http://prometheus-server:9090/-/reload验证打开Prometheus的Web UI默认9090端口在“Status” - “Targets”页面应该能看到一个名为dameng的job其State为“UP”。至此达梦数据库的指标就已经源源不断地流入Prometheus了。接下来我们就要在Grafana中让这些数据“说话”。5. 数据可视化在Grafana中构建达梦监控仪表盘有了数据下一步就是打造一个直观、信息丰富的监控面板。Grafana是我们的最佳画布。5.1 连接数据源与初步探索添加Prometheus数据源在Grafana中进入“Configuration” - “Data Sources”添加你的Prometheus服务器地址。保存并测试连接。使用Explore功能探索指标在Grafana侧边栏点击“Explore”选择Prometheus数据源。在查询框里输入dm_Grafana会自动补全所有以dm_开头的指标。这是你熟悉Exporter提供了哪些指标的最快方式。尝试输入dm_tablespace_usage_percent或dm_sessions_current看看有没有数据。5.2 设计核心监控面板一个完整的达梦数据库监控面板可以按照我们第二章的蓝图来组织多个Row行。这里我分享几个核心图表的配置思路。5.2.1 数据库全局状态概览SingleStat Stat目的一眼看清数据库核心状态。图表与查询数据库状态使用“Stat”可视化。查询up{jobdameng”}。值为1显示绿色“Healthy”值为0显示红色“Down”。当前连接数/最大连接数使用“Stat”可视化。查询dm_sessions_current和dm_sessions_limit。可以配置阈值颜色如80%绿色80%橙色95%红色。缓冲池命中率使用“Gauge”可视化。查询公式(1 - (rate(dm_buffer_pool_physical_reads_total[5m]) / rate(dm_buffer_pool_logical_reads_total[5m]))) * 100。设置阈值如95%警告90%严重。5.2.2 资源消耗趋势Time series目的观察历史趋势定位性能瓶颈发生的时间点。图表与查询CPU/Memory Usage如果Exporter提供了进程级指标可以直接查询。或者通过Node Exporter的node_cpu_seconds_total和node_memory_MemTotal_bytes等指标结合instance标签关联到达梦数据库所在主机进行计算。活跃会话数趋势dm_sessions_current。配合Grafana的“Alert”功能可以设置当该值持续5分钟高于某个阈值时告警。物理读/写IOPSrate(dm_io_physical_reads_total[5m])和rate(dm_io_physical_writes_total[5m])。观察其与业务高峰期的关联性。5.2.3 表空间容量面板Bar gauge Time series目的直观展示各表空间使用情况预测何时需要扩容。图表与查询表空间使用率当前使用“Bar gauge”可视化。查询dm_tablespace_usage_percent。它会自动按tablespace标签分组形成横向柱状图非常直观。表空间增长趋势为每个重要的表空间如MAIN创建一个“Time series”图表。查询dm_tablespace_bytes_used。利用Grafana的“Transform”功能或PromQL的predict_linear函数可以预测未来几天何时会满。# 预测MAIN表空间在24小时后的使用量基于过去6小时的增长速度 predict_linear(dm_tablespace_bytes_used{tablespaceMAIN”}[6h], 3600*24)5.2.4 锁与慢SQL详情表Table目的当出现告警时快速定位问题会话和SQL。图表与查询当前锁等待使用“Table”可视化。查询一个能返回锁等待详细信息的指标例如假设Exporter提供了dm_lock_wait_info。表格列可以显示会话IDsession_id、被阻塞的SQLblocking_sql、等待时间wait_time_seconds等。近期慢SQL Top 10使用“Table”可视化。这需要Exporter提供类似dm_slow_sql的指标并记录SQL文本、总执行时间、执行次数等。查询可以按总耗时排序topk(10, dm_sql_total_elapsed_time_seconds)。5.3 告警规则配置可视化用于观察告警用于行动。我们需要在Prometheus的Alertmanager或Grafana自带的告警引擎中配置规则。在Prometheus的rules.yml文件中配置示例groups: - name: dameng_alerts rules: # 规则1: 数据库宕机 - alert: DamengDBDown expr: up{jobdameng”} 0 for: 1m # 持续1分钟才触发避免网络抖动误报 labels: severity: critical annotations: summary: “达梦数据库实例 {{ $labels.instance }} 宕机” description: “{{ $labels.instance }} 的Exporter无法访问持续1分钟以上。” # 规则2: 连接数过高 - alert: DamengHighConnections expr: (dm_sessions_current / dm_sessions_limit) * 100 85 for: 5m labels: severity: warning annotations: summary: “达梦数据库连接数使用率过高 (实例 {{ $labels.instance }})” description: “当前连接数使用率为 {{ $value }}% 请检查应用连接池配置或是否存在连接泄漏。” # 规则3: 表空间即将耗尽 - alert: DamengTablespaceCritical expr: dm_tablespace_usage_percent 90 for: 2m labels: severity: critical annotations: summary: “表空间 {{ $labels.tablespace }} 使用率超过90% (实例 {{ $labels.instance }})” description: “表空间 {{ $labels.tablespace }} 当前使用率为 {{ $value }}% 请立即扩容。” # 规则4: 缓冲池命中率过低 - alert: DamengLowBufferHitRate expr: (1 - (rate(dm_buffer_pool_physical_reads_total[10m]) / rate(dm_buffer_pool_logical_reads_total[10m]))) * 100 90 for: 10m labels: severity: warning annotations: summary: “达梦数据库缓冲池命中率过低 (实例 {{ $labels.instance }})” description: “过去10分钟平均缓冲池命中率仅为 {{ $value }}% 可能影响性能请考虑调整缓冲池大小或优化SQL。”配置好告警规则并关联到Alertmanager后当触发告警时可以通过邮件、钉钉、企业微信、Slack等渠道通知到DBA或运维人员。6. 避坑指南与进阶思考在实际部署和运维这套监控体系的过程中我踩过不少坑也总结出一些让监控更可靠、更有价值的经验。6.1 常见部署与配置陷阱Exporter自身成为性能瓶颈一个编写不当的Exporter如果执行的SQL过于复杂或频繁可能会消耗大量数据库资源。务必在测试环境进行压力测试观察Exporter运行期间数据库的CPU、IO和锁等待情况。优化Exporter的采集SQL避免全表扫描系统视图尽量使用高效的查询。连接泄漏与超时Exporter需要维持数据库连接。如果连接池配置不当或网络不稳定可能导致数据库端积累大量“僵尸”连接。确保Exporter有健全的连接超时和重试机制。同时定期检查达梦数据库的V$SESSIONS视图确认来自监控IP的连接是正常的短连接而不是长期挂起。指标爆炸与标签设计这是Prometheus监控的一个经典问题。如果Exporter为每一条慢SQL都生成一个独立的指标序列比如用SQL文本做标签那么SQL一多指标数量就会爆炸式增长导致Prometheus存储和查询压力巨大。合理的做法是对SQL进行指纹Fingerprint计算用哈希值作为标签而不是完整的SQL文本。或者只暴露聚合后的指标如“过去5分钟慢SQL数量”具体详情通过日志或其他系统查询。版本兼容性问题达梦数据库不同版本如DM7和DM8的系统视图、字段名可能有差异。你从网上下载的Exporter很可能只针对某个特定版本开发。部署前一定要核对Exporter中使用的SQL语句在你当前的数据版本上是否能正确执行并返回预期的字段。最好在测试库上先完整跑一遍所有采集查询。6.2 让监控产生真正的业务价值监控不是为了堆砌华丽的图表而是为了驱动行动、预防故障、辅助决策。建立性能基线监控上线后不要急着设定告警阈值。先让系统平稳运行一周观察各项指标如CPU使用率、QPS、平均响应时间在业务平峰期、高峰期的正常范围。以此为基础建立的动态基线例如白天阈值高夜间阈值低比静态阈值如CPU80%要准确得多。关联分析不要孤立地看数据库指标。在Grafana中可以将数据库的连接数、慢SQL数量与应用服务器的QPS、响应时间指标放在同一个面板里。当业务响应时间变慢时你可以一眼看出是数据库慢SQL增多导致的还是应用服务器本身的问题。这种关联分析能极大缩短故障定位时间。容量规划与成本优化表空间增长趋势、历史峰值连接数、IOPS利用率等数据是进行下一年度硬件采购或云资源扩容的最有力依据。定期输出容量报告用数据证明为什么需要更大的磁盘或更高配置的实例这比凭感觉“可能要不够了”要靠谱得多。闭环从告警到故障自愈对于某些明确、可自动处理的告警可以尝试向“自愈”演进。例如当监控到临时表空间TEMP使用率超过95%时除了告警是否可以自动触发一个安全脚本去查找并Kill掉那些占用大量临时空间的无用会话当然这种操作风险极高需要极其谨慎的设计和多次沙箱测试。监控达梦数据库从技术上看是部署一个Exporter、配置几个图表和告警。但从价值上看它是将国产核心组件的运行状态从“不可知”变为“可知、可控、可预测”的关键一步。这个过程可能会遇到工具不完善、资料匮乏的挑战但每解决一个问题你对这套系统的掌控力就增强一分。最终当告警响起你能在几分钟内精准定位到是某个表空间满了还是一条新上的SQL拖垮了缓冲池时那种一切尽在掌握的感觉就是运维工作最大的成就感所在。