《企业实战分享 · Druid 连接监控》

📢 大家好，我是【战神刘玉栋】，有10多年的研发经验，致力于前后端技术栈的知识沉淀和传播。 💗

🌻 近期刚转战 CSDN，会严格把控文章质量，绝不滥竽充数，如需交流，欢迎留言评论。👍

文章目录

- 写在前面的话
- [SQL 查询阻塞信息](#SQL 查询阻塞信息)
- [Druid 监听连接数](#Druid 监听连接数)
- 总结陈词

写在前面的话

技术栈：后端 SpringCloud + 前端 Vue/Nuxt

博主所在公司，后端的数据库连接池采用Druid，数据库采用Oracle，做过后端开发的都知道，生产环境出现数据库连接获取异常、连接池满等问题屡见不鲜，如何在出现此类问题的时候，更好的定位问题，是架构人员需要考虑的问题。

单纯依靠Zipkin、Prometheus、Grafana只能定位到连接数情况，具体的语法还是要依靠Oracle层面协助，本篇文章分享一下采用的解决思路。

相关博文：《企业实战分享 · Sleuth + Zipkin 实现链路追踪》《SpringBoot 整合 Prometheus 采集自定义指标》

SQL 查询阻塞信息

查询语法：

sql 复制代码

Select 'alter system kill session '''||a_s.sid || ',' || a_s.SERIAL# ||',@'||a_s.inst_id||''' immediate;' kill_sql,
       '节点 ' || a_s.INST_ID || ' session ' || a_s.sid || ',' || a_s.SERIAL# ||' 阻塞了 节点 ' || b_s.INST_ID || ' session ' || b_s.SID || ',' ||
       b_s.SERIAL# blockinfo,
       a_s.INST_ID,
       (select n.machine from gv$session n where n.sid = a_s.sid and n.serial# = a_s.serial# ) MACHINE,
       a_s.SID,
       a_s.SCHEMANAME,
       a_s.MODULE,
       a_s.STATUS,
       '后为被阻塞信息',
       b_s.INST_ID blocked_inst_id,
       b_s.SID blocked_sid,
       b_s.SCHEMANAME blocked_SCHEMANAME,
       b_s.EVENT blocked_event,
       b_s.MODULE blocked_module,
       b_s.STATUS blocked_status,
       b_s.SQL_ID blocked_sql_id,
       obj.owner blocked_owner,
       obj.object_name blocked_object_name,
       obj.OBJECT_TYPE blocked_OBJECT_TYPE,
       case
         when b_s.ROW_WAIT_OBJ# <> -1 then
          dbms_rowid.rowid_create(1,
                                  obj.DATA_OBJECT_ID,
                                  b_s.ROW_WAIT_FILE#,
                                  b_s.ROW_WAIT_BLOCK#,
                                  b_s.ROW_WAIT_ROW#)
         else
          '-1'
       end blocked_rowid, --被阻塞数据的rowid
       decode(obj.object_type,
              'TABLE',
              'select * from ' || obj.owner || '.' || obj.object_name ||
              ' where rowid=''' ||
              dbms_rowid.rowid_create(1,
                                      obj.DATA_OBJECT_ID,
                                      b_s.ROW_WAIT_FILE#,
                                      b_s.ROW_WAIT_BLOCK#,
                                      b_s.ROW_WAIT_ROW#) || '''',
              NULL) blocked_data_querysql  --被阻塞的SQL
  from gv$session a_s, 
       gv$session b_s, 
       dba_objects obj
 where b_s.BLOCKING_INSTANCE is not null
   and b_s.BLOCKING_SESSION is not null
   and a_s.INST_ID = b_s.BLOCKING_INSTANCE
   and a_s.SID = b_s.BLOCKING_SESSION
   and b_s.ROW_WAIT_OBJ# = obj.object_id(+)
 order by a_s.inst_id, a_s.sid;

结果分析：

某行记录代表某个会话阻塞了另外一个会话信息，具体字段分析如下：

KILL_SQL：alter system kill session '1609,56765,@1' immediate;

用来删除阻塞会话，即前一个会话。

BLOCK_INFO：节点 1 session 1609,56765 阻塞了节点 1 session 836,27401

阻塞信息，描述什么阻塞了什么，这里的两个数字可以继续去gv s e s s i o n 获取详细信息，比如机器 I D s e l e c t ∗ f r o m g v session获取详细信息，比如机器ID select * from gv session获取详细信息，比如机器IDselect∗fromgvsession where sid='2329' and SERIAL#='44233';

MODULE：PL/SQL Developer/JDBC Thin Client

阻塞的是PLSQL还是程序的JDBC连接方式

BLOCKED_DATA_QUERYSQL：阻塞SQL

后面几个字段是具体的sqlID、SQL、表名、用户表等等，也可以继续用ID去v s q l 获取详细信息 s e l e c t ∗ f r o m v sql获取详细信息 select * from v sql获取详细信息select∗fromvsql t where t.sql_id = 'f1f8cjktsm59c'

MACHINE：机器名

通过K8S部署的方式，机器名包含pod名称，可以用于按服务名过滤

Druid 监听连接数

有了上面获取的数据，就可以考虑如何从程序层面做进一步的问题定位。

有两种思路：

1、自动监测，基于Druid的FilterEventAdapter，拦截重要事件，判定当前连接数大于一定阈值，则查询上述语法，组装结果后做出适当的响应；

2、主动查询，在统一日志界面，增加展示"连接视图"功能，主动获取某个服务的连接明细情况，展示给用户，很直观的看到占用的SQL情况；

总结陈词

上文分享若干企业实际开发中，Druid连接监控方案，希望对大家有帮助。

💗 后续会逐步分享企业实际开发中的实战经验，有需要交流的可以联系博主。