线程池如何监控,才能帮助开发者快速定位线上错误?(一)

发布于 2022-6-21 16:36
浏览
0收藏

 

大部分情况下,线程池的运行情况对于使用者来说是个黑盒

 

运行情况不可知,会导致 生产出现事故问题排查困难,以及线程池参数难以定义

 

文章围绕线程池监控展开,讨论 线程池如何监控、监控的指标以及监控数据的存储展示

线程池如何监控,才能帮助开发者快速定位线上错误?(一)-开源基础软件社区

01

如何监控运行数据

 

设想一下,如果想监控线程池的运行数据,你会怎么操作?这里提供两种常规思路

  1. 线程池运行时埋点,每一次运行任务都进行统计
  2. 定时获取线程池的运行数据
    这里我推荐第二种,因为线程池的监控 API 会通过 获取主锁来控制结果的相对准确性,性能相对较差,后面会详细说明

 

为什么叫相对准确?因为任务和线程的状态在计算过程中可能会动态变化,只能给到一个近似值,保证不了绝对准确

 

模拟下定时采集线程池运行时数据的代码

private ScheduledThreadPoolExecutor collectVesselExecutor;

String collectVesselTaskName = "client.scheduled.collect.data";
collectVesselExecutor = new ScheduledThreadPoolExecutor(
        new Integer(1),
        ThreadFactoryBuilder.builder().daemon(true).prefix(collectVesselTaskName).build()
);

// 延迟 initialDelay 后循环调用. scheduleWithFixedDelay 每次执行时间为上一次任务结束时, 向后推一个时间间隔
collectVesselExecutor.scheduleWithFixedDelay(
        () -> runTimeGatherTask(),
        properties.getInitialDelay(),
        properties.getCollectInterval(),
        TimeUnit.MILLISECONDS
);

一般线程池分为两种方式创建,Spring Bean 和非 Spring Bean,假设创建的线程池是 Spring 管理的

 

我们只需要在 Spring 容器启动成功后,延迟一段时间后开始采集运行数据就 OK 了

 

不论线程池是否由 Spring 管理,采集的方式大致相同。一种从 Spring 容器取,一种是创建好线程池后放到一个自定义容器

 

02

监控的指标有哪些?

 

说一下目前 Hippo4J 定义的线程池监控指标,包括不限于。大家有业务中使用到的监控指标都可以讨论下

  • 线程池当前负载:当前线程数 / 最大线程数
  • 线程池峰值负载:当前线程数 / 最大线程数,线程池运行期间最大的负载
  • 核心线程数:线程池的核心线程数
  • 最大线程数:线程池限制同时存在的线程数
  • 当前线程数:当前线程池的线程数
  • 活跃线程数:执行任务的线程的大致数目
  • 最大出现线程数:线程池中运行以来同时存在的最大线程数
  • 阻塞队列:线程池暂存任务的容器
  • 队列容量:队列中允许元素的最大数量
  • 队列元素:队列中已存放的元素数量
  • 队列剩余容量:队列中还可以存放的元素数量
  • 线程池任务完成总量:已完成执行的任务的大致总数
  • 拒绝策略执行次数:运行时抛出的拒绝次数总数
    这些指标可以帮助我们解决大多数因为线程池而导致的问题排查。但是,事情往往不能尽善尽美

 

当前线程数、活跃线程数、最大出现线程数、线程池任务完成总量 的线程池 API 会先获取到 mainLock,然后才开始计算

 

mainLock 是线程池的主锁,线程执行、线程销毁和线程池停止等都会使用到这把锁

final ReentrantLock mainLock = this.mainLock;
mainLock.lock();
try {
    xxxxx
} finally {
    mainLock.unlock();
}

如果频繁获取这把锁,会导致原有线程池任务执行性能受到影响

 

所以,我们应该避免频繁获取这几项参数,这也是不使用线程池任务执行埋点最重要的原因

 

03

监控数据存储

 

上面的线程池监控指标如果只能支持实时查看,并不能帮忙开发日常排查错误

大部分场景下,生产上的问题发现会有延迟。比如 12:30 出现的问题,业务13:00 进行的反馈

为了更好帮助开发排错,我们需要将线程池的历史运行数据进行存储

说到线程池历史运行数据的存储,使用 时序数据库(TSDB) 是最合适的

但大部分情况下,公司不会为了这一个需求搭建或者采购时序数据库,那就可以使用折中方案,比如说 MySQL、ES 等

我们以 MySQL 为例,his_run_data 历史运行数据表,建表语句如下:

CREATE TABLE `his_run_data` (
  `thread_pool_id` varchar(56) DEFAULT NULL COMMENT '线程池ID',
  `instance_id` varchar(256) DEFAULT NULL COMMENT '实例ID',
  `current_load` bigint(20) DEFAULT NULL COMMENT '当前负载',
  `peak_load` bigint(20) DEFAULT NULL COMMENT '峰值负载',
  `pool_size` bigint(20) DEFAULT NULL COMMENT '线程数',
  `active_size` bigint(20) DEFAULT NULL COMMENT '活跃线程数',
  `queue_capacity` bigint(20) DEFAULT NULL COMMENT '队列容量',
  `queue_size` bigint(20) DEFAULT NULL COMMENT '队列元素',
  `queue_remaining_capacity` bigint(20) DEFAULT NULL COMMENT '队列剩余容量',
  `completed_task_count` bigint(20) DEFAULT NULL COMMENT '已完成任务计数',
  `reject_count` bigint(20) DEFAULT NULL COMMENT '拒绝次数',
  `timestamp` bigint(20) DEFAULT NULL COMMENT '时间戳',
  `gmt_create` datetime DEFAULT NULL COMMENT '创建时间',
  `gmt_modified` datetime DEFAULT NULL COMMENT '修改时间',
  PRIMARY KEY (`id`),
  KEY `idx_group_key` (`tp_id`,`instance_id`) USING BTREE,
  KEY `idx_timestamp` (`timestamp`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COMMENT='历史运行数据表';

可以看到,建表语句中有三个关键字段:

thread_pool_id:表示当前数据的线程池标识

instance_id:应用可能集群部署,标识集群下唯一的线程池

timestamp:记录线程池运行数据产生时的时间戳

有一个问题,线上的线程池是源源不断产生运行数据的,迟早不得把表的数据量推到上亿?

因为数据是有时效性的,过了一定时间之后,就没有必要再占用实时的资源

针对上述问题提供两种解决方案:

  1. 假设数据存储 1 天,如果超出这个时间,直接删除即可
  2. 同上所述,过期数据可以保留到备份表中,并删除 his_run_data 数据
    可能有的小伙伴还会担心,数据量太大会不会导致查询时过慢?

我们可以算一下,假设有 100 个应用,每个应用部署 10 个节点

假设数据有效期为 1 小时,那么可以产出的数据是 72 万,一天也就是 1728 万

对于 MySQL 而言,几千万数据量以下针对索引的查询,都不会产生性能瓶颈

 

文章转自公众号:龙台的技术笔记

标签
已于2022-6-21 16:36:37修改
收藏
回复
举报
回复
添加资源
添加资源将有机会获得更多曝光,你也可以直接关联已上传资源 去关联
    相关推荐