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

时间:2024-07-13 15:29:22

???? 大家好,我是 【战神刘玉栋】,有10多年的研发经验,致力于前后端技术栈的知识沉淀和传播。 ????
???? 近期刚转战 ****,会严格把控文章质量,绝不滥竽充数,如需交流,欢迎留言评论。????

文章目录

    • 写在前面的话
    • SQL 查询阻塞信息
    • Druid 监听连接数
    • 总结陈词


写在前面的话

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

博主所在公司,后端的数据库连接池采用Druid,数据库采用Oracle,做过后端开发的都知道,生产环境出现数据库连接获取异常、连接池满等问题屡见不鲜,如何在出现此类问题的时候,更好的定位问题,是架构人员需要考虑的问题。
单纯依靠Zipkin、Prometheus、Grafana只能定位到连接数情况,具体的语法还是要依靠Oracle层面协助,本篇文章分享一下采用的解决思路。

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


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;

结果分析:
image.png
image.png
某行记录代表某个会话阻塞了另外一个会话信息,具体字段分析如下:
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获取详细信息,比如机器IDselectfromgvsession 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获取详细信息selectfromvsql t where t.sql_id = ‘f1f8cjktsm59c’

MACHINE:机器名

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


Druid 监听连接数

有了上面获取的数据,就可以考虑如何从程序层面做进一步的问题定位。
有两种思路:
1、自动监测,基于Druid的FilterEventAdapter,拦截重要事件,判定当前连接数大于一定阈值,则查询上述语法,组装结果后做出适当的响应;
2、主动查询,在统一日志界面,增加展示“连接视图”功能,主动获取某个服务的连接明细情况,展示给用户,很直观的看到占用的SQL情况;


总结陈词

上文分享若干企业实际开发中,Druid连接监控方案,希望对大家有帮助。
???? 后续会逐步分享企业实际开发中的实战经验,有需要交流的可以联系博主。