Druid监控

【SpringBoot框架篇】12.使用druid的monitor工具查看sql执行性能_druid monitor-优快云博客

Spring Boot 整合 Druid 并开启监控_druid监控页面-优快云博客

硬件监控 | 硬件监控软件 - ManageEngine Applications Manager

如何深入解析 Druid Monitor 在生产环境中的配置，并探讨其关闭策略以及系统优化措施，以提升 Druid 监控系统的性能和稳定性？

Druid Monitor 生产环境配置解析与关闭策略及系统优化探讨

引言

Druid Monitor 是 Apache Druid 的一个关键组件，它主要用于监控 Druid 集群的性能和健康状态。在生产环境中，合理配置 Druid Monitor 以及优化其关闭策略对于确保 Druid 系统的稳定运行至关重要。本文将深入解析 Druid Monitor 的生产环境配置，并探讨其关闭策略与系统优化措施。

Druid Monitor 生产环境配置解析

1. 配置概述

Druid Monitor 的配置主要包括以下几个方面：

• 监控指标：确定需要监控的指标，如查询延迟、节点状态、集群负载等。
• 监控频率：设置监控数据的收集频率，以平衡实时性和资源消耗。
• 报警机制：配置报警规则，当监控指标超出阈值时，及时通知管理员。

2. 配置文件解析

Druid Monitor 的配置文件通常位于 conf/druid_monitor.properties。以下是一些关键配置项的解析：

• druid.monitor.host：Druid Monitor 的监听地址。
• druid.monitor.port：Druid Monitor 的监听端口。
• druid.monitor.queryTimeout：查询超时时间。
• druid.monitor.alerting：报警配置，包括报警类型、阈值和接收者。

关闭策略探讨

1. 关闭策略的重要性

关闭策略对于 Druid Monitor 的稳定性和资源利用至关重要。不当的关闭策略可能导致数据丢失或系统资源浪费。

2. 关闭策略类型

• 正常关闭：在系统正常关闭时，逐步停止 Druid Monitor 服务。
• 紧急关闭：在系统出现故障时，立即停止 Druid Monitor 服务。
• 优雅关闭：在关闭前，确保所有监控任务完成，并释放资源。

系统优化措施

1. 性能优化

• 资源分配：合理分配 CPU、内存和磁盘资源，确保 Druid Monitor 有足够的资源进行监控。
• 负载均衡：在多节点环境中，实现负载均衡，避免单点过载。

2. 稳定性优化

• 数据备份：定期备份监控数据，以防数据丢失。
• 故障转移：实现故障转移机制，确保在主节点故障时，从节点能够接管监控任务。

结论

Druid Monitor 在生产环境中的配置、关闭策略和系统优化是确保 Druid 监控系统稳定运行的关键。通过深入解析配置、合理制定关闭策略和采取优化措施，可以显著提升 Druid Monitor 的性能和稳定性。

参考文献

• Apache Druid 官方文档：Apache Druid Documentation
• Druid Monitor 配置文件解析：Druid Monitor Configuration

Druid监控分布式实现过程解析

什么是 Druid Monitor

Druid 是一个非常强大的数据库连接池，但是它的强大并不仅仅体现在作为一个高性能连接池加快数据访问上和连接管理上，它内置了一个强大的监控工具：Druid Monitor。不仅可以监控数据源和慢查询，还可以监控 Web 应用、URI 监控、Session 监控、Spring 监控等。

ip:port/druid/sql.html

什么是 Druid Admin

如上文所述， Druid Monitor 提供强大的监控能力，但目前仅是针对对单个服务实例的监控。 在微服务架构日益流行的时下，同一个服务可能有会有 N 个实例，监控维度需要上升至 集群。

官方在 druid 1.2.1 版本后，提供 druid-admin 模块 来解决集群监控的问题。

如下图我们可以在原有的监控集群上可以动态的切换服务名称，做到一个监控入口，实现不同服务的监控切换。

Spring Cloud Stater 封装

目前官方的 druid-admin 正在开发工程中，并不能直接编译运行（依赖包错误、不支持 java11 等）。

druid-admin 本身是一个直接可运行的 web 服务，对目前已有服务不太友好，不能做到 spring boot admin 那种即插即用

所以基于上述问题，笔者对 druid-admin 进行了相关的修改，直接抽取成 spring boot starter 引入即用。

1. 增加依赖

1 2 3 4 5 6 7 8 9 10 11 12

<dependency>     <groupId>com.pig4cloud.plugin</groupId>     <artifactId>spring-cloud-starter-druid-monitor</artifactId>     <version>0.0.1</version> </dependency> <!--注册中心客户端（支持 nacos/eureka/consul）--> <dependency>     <groupId>com.alibaba.cloud</groupId>     <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId> </dependency>

2. 接入注册中心和需要监控的服务列表

1 2 3 4 5 6 7 8 9 10 11

spring:  cloud:   nacos:    discovery:     server-addr: 127.0.0.1:8848 # druid-admin 需要监控的列表 monitor:  applications:   - pigx-upms-biz   - pigx-auth

3. 目标服务暴露 druid 监控端点

1 2 3 4 5 6 7

spring:  datasource:   druid:    stat-view-servlet:     enabled: true     allow: ""     url-pattern: /druid/*

4. 访问 druid-admin

查看集群监控ip:port/druid/sql.html

整合 Spring Boot Admin

引入上述依赖，增加如下配置即可

1 2 3 4 5 6 7 8

spring:  boot:   admin:    ui:     external-views:      - label: "SQL监控"       url: /druid/sql.html       order: 2000

使用限制

由于 druid monitor 的登录校验基于 session 设计，所有在无状态的微服务中不适用。建议直接暴露所有 druid 相关的端点，通过前置网关统一接口权限。

目前实例监控数据是保存在对应内存中，仅在查看时通过每个实例汇总后显示，后期会实现持久化。

 如何使用Druid监控

Druid 连接池最初就是为监控系统采集 JDBC 运行信息而生的，Druid 连接池内置了一个监控页面，提供了非常完备的监控信息，可以快速诊断系统的瓶颈。

好了，经过上述的一顿铺垫，相信小伙伴们对 Druid 连接池已经有一定的了解了，下面我们就通过 Druid 的监控，来看看蘑菇存在的 SQL 性能问题

通过在后端端口加上 /druid/index.html 即可打开 Druid 的内置的监控页面

http://localhost:8601/druid/index.html

此时输入账号和密码：admin 123456 （密码是可以配置的，后面在集成的时候可以看到）

这个时候，会进入到 Druid Monitor 的主页，这里能够查看到对应版本、驱动，以及 Java 版本

Druid监控首页

切换到数据源的 Tab 页面，能够看到我们配置的数据库连接池的各个参数

数据库连接池参数

下面，我们切换到 SQL 监控，是可以看到目前运行的所有 SQL 的执行情况，按时间排序即可看到，最慢的 SQL 执行时间到达了 8S

SQL监控页面

我们点击左侧的 SQL 语句，即可看到完整的 SQL 详情页，这里面记录了几个关键的信息，包括：慢SQL语句、执行耗时、发生时间、SQL 参数

慢SQL详情

其实这个 SQL 对应的就是 init 中，用来查询用户 UV 的，即从日志表中查看有多少用户访问了蘑菇

SELECT COUNT(ip)
FROM (
    SELECT ip
    FROM t_web_visit
    WHERE create_time >= "2022-08-08 00:00:00"
        AND create_time <= "2022-08-08 23:59:59"
    GROUP BY ip
) tmp

我们把 SQL 复制到 SQLyog 执行，好家伙，这次执行花了 10 S

复制SQL到SQLyog执行

上面 SQL 脚本的思路，其实是就是查询出单天内不同的 ip，但是用到了 group by 进行分组去重，最后统计 ip 的次数

我们可以针对上面的 SQL 进行优化，使用 SQL 内置的 DISTINCT() 函数进行去重

SELECT COUNT(DISTINCT(ip)) FROM t_web_visit WHERE create_time >= "2022-08-08 00:00:00" AND create_time <= "2022-08-08 23:59:59";

优化后的 SQL，可以看到执行时间已经从原来的 10 S -> 0.57 S

优化后的SQL执行

我们通过 explain 再次查看该 SQL 的索引执行情况

EXPLAIN SELECT COUNT(DISTINCT(ip)) FROM t_web_visit WHERE create_time >= "2022-08-03 00:00:00" AND create_time <= "2022-08-03 23:59:59";

通过输出结果可以看到，该语句没有走索引，进行了全表的扫描，同时查询了 658559 行数据

explain查看索引使用情况

我们分析这次查询参数，主要是使用了 create_time 进行范围查询，可以接着对查询进行优化，给 create_time 新增索引

ALTER TABLE t_web_visit ADD INDEX _create_time( `create_time` );

再次执行第一条 SQL 语句，可以看到查询时间有了大幅度的提升，直接从原来的 10S -> 0.18S

添加索引后的第一条SQL执行

在看第二条 SQL，时间也有了很大的提升，从 0.57 S -> 0.046 S

添加索引后的第二条SQL执行

最后通过 explain 分析 SQL，可以看到，优化后的 SQL ，使用了 create_time 索引，只需要查询 871 条数据

查看索引使用情况

优化后的 SQL 后，我们再打开蘑菇后台页面，可以看到页面从原来的 10S 变成了 0.9S~