Skywalking自定义拓展线程池监控grpc线程池

最新推荐文章于 2025-09-12 04:08:21 发布
原创 最新推荐文章于 2025-09-12 04:08:21 发布 · 2.8k 阅读 · 6 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#java #开发语言

背景

SkyWalking Java Agent 8.10.0 增加了对database连接池和tomcat线程池监控的plugin：skywalking.apache.org/events/rele…

如果我们自己想增加一些针对于自己业务的线程池的监控，Skywalking也是提供了拓展点的。

实现

客户端实现

这篇官方文档描述了客户端(也就是应用端)如何上传数据到SkyWalking服务端。

skywalking.apache.org/docs/skywal…

通过查看官方对tomcat线程池的实现，可以看到主要使用了 MeterFactory.gauge API，我们可以在我们自己的组件中也用类似的写法进行模拟一下。

通过对tomcat线程池的拦截源码来看，其实核心原理就是在合适的地方拦截到Java线程池对象，然后通过调用线程池对象的getXxxSize来获取到相应的状态，然后上报，

因为我这里的需求是监控grpc运行时的业务线程池，所以首先我需要先编写我的客户端插件，用于取到grpc业务线程池，并对其进行状态监控调用，我的源代码如下：

定义拦截类，我这里是在ServerImpl.start，也就是grpc服务启动的时候进行拦截，获取线程池：

public class GrpcThreadPoolInstrumentation extends ClassEnhancePluginDefine {

    // 代理类
    public static final String INTERCEPT_CLASS =
            "org.apache.skywalking.apm.plugin.grpc.v1.server.GrpcDefaultThreadExecutorInterceptor";
    // 需要拦截的方法
    public static final String ENHANCE_METHOD = "start";
    // 需要拦截的类
    public static final String ENHANCE_CLASS = "io.grpc.internal.Serv
最低0.47元/天 解锁文章
【微服务】skywalking自定义链路追踪与日志采集
congge
02-03 8221
skywalking自定义链路追踪与日志采集
【微服务】skywalking自定义告警规则使用详解
congge
02-15 7154
skywalking自定义告警规则使用详解
SkyWalking自定义JVM指标
u014627036的博客
01-28 1971
Skywalking自定义JVM指标 本文奖以采集JVM类加载数量为例，详细说明Skywalking JVM自定义指标流程 探针端开发逻辑 在JVMMetric.proto（文件位置apm-protocol\apm-network\src\main\proto\language-agent）下定义对应采集指标 // 在message JVMMetric中加入对应对象，如下所示 message JVMMetric { int64 time = 1; CPU cpu = 2; rep
Skywalking系列之最新版9.2.0-JavaAgent本地构建
c_zyer的博客
12-18 2499
Skywalking-agent 9.2.0-SNAPSHOT，JDK 11 (最新的代码要看最新的要求，注意不能使用JDK8，会构建失败)，Maven 3.6.0。获取源码，加载submodule，maven构建，kywalking-agent包
分布式链路追踪SkyWalking快速入门之环境安装界面指标介绍(一)
点滴记忆，分享成长之路
01-28 2507
本篇简单介绍SkyWalking是什么，特点和整体架构组成，使用docker安装部署，页面指标项的介绍
Spring boot整合Skywalking实现线程池无侵入Tid传递及简单源码分析
念念不忘，必有回响
09-27 3120
总的来说如果线程池我们要支持无缝tid传递，需要将中的插件移动到我们的agent中，才会生效。但是仅仅支持线程池，即。
SkyWalking 线程池异步任务链路追踪
wangchl0932的博客
12-07 1221
Apache SkyWalking 提供了一套包装类来支持编程方式下的异步跟踪。这些包装类可以确保在使用线程池或并行流时，跟踪上下文（如 Trace ID）能够正确地在异步任务之间传播。通过遵循上述指导原则，您可以在应用程序中有效地实施异步任务的链路追踪，从而简化调试和性能分析过程。来包装您的任务，以确保跟踪上下文的正确传播。当处理并行流时，可以分别使用。来包装流中的转换和消费操作。对于线程池，您可以使用。来包装供给型异步任务。
SkyWalking自定义插件(Spring RabbitMQ)
Kenny的博客
02-14 2865
SkyWalking 自定义插件(Spring RabbitMQ) 官方RabbitMQ插件问题 skywalking官方提供的RabbitMQ插件存在缺陷，其只针对RabbitMQ官方原生Client实现扩展，但我们在项目中一般不直接使用原生Client，而是使用Spring RabitMQ Client，因Spring RabitMQ Consumer中存在跨线程操作，导致跟踪ID断链。 具体分析过程 官方插件源码的拦截点是原生Consumer的handleDelivery方法，源码如下: Spri
SkyWalking使用教程二：自定义监控指定方法trace等高级特性
ice-wee的专栏
03-20 7703
1 高级特性 可通过设置系统属性覆盖配置文件中的配置。请见配置覆盖. 可使用gRPC TLS将后端连接起来。请见open TLS 通过不同的SkyWalking服务实现对大集群的监控。使用命名空间隔离上下文传播。 如果后端开启了token鉴权，客户端可设置token。 应用工具包。应用工具包，是Skywalking提供的一些库的集合。通过这些库，可以将你的应用同Skywalking agent联系起来。 如果你想使用OpenTracing的Java API，可以试试兼容OpenTracing的S
Skywalking自定义指标
StarUranus的博客
10-21 2162
把Skywalking集成到自家系统时，想在原来的指标之外增加一些新指标。百度到了观测分析语言(Observability Analysis Language, OAL) (skyapm.github.io)。看完之后总算理解了指标是怎么计算的。但是我看源码里并没有这个oal文件，得编译之后才能生成。我就又搞不懂是怎么生成的了，现在只能在已经启动的服务中找到oal文件，在里面修修改改然后重启。 PS：刚开始还疑惑为啥我的cpm一直是0，后来看了下面的博客才知道跟选择的时间段有关，像我用的测试服务只要超过1
linux的grpc扩展，skywalking需要的
08-19
skywalking需要的 grpc扩展包
天行线程池代理
02-09
天行线程池代理 该项目旨在使使用线程池时无需更改用户代码即可传播SkyWalking上下文成为可能。 如果项目有帮助，请加注星标！ 如何传播 要在线程之间传播上下文，我们可能首先要增强Runnable，但这并不好，因为Runnable不仅用于线程中，因此应用ThreadPoolExecutor＃execute的建议来包装Runnable参数是一个不错的选择，但是很难做到SkyWalking的Java代理通常在增强类时添加一个字段并实现接口EnhancedInstance。 当加载增强实例的类时，它失败，因为大多数JVM不允许更改先前已加载类的类文件格式。ThreadPoolExecutor是引导类路径中的特殊类，可以在任何代码中加载。 幸运的是，如果我们只想包装Runnable参数，则无需更改ThreadPoolExecutor的布局。 因此，让我们编写另一个代理来执行此操作。 如果实
skywalking 自定义插件
batman
01-14 3641
环境 基于skywalking-java开发，就是skywalking的java agent，这次在基础上开发一个自定义的插件。 流程演示 首先新建一个model 修改pom文件 <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:sc.
skywalking线程池插件,解决lambda使用问题
bigNoseCat的博客
05-20 8091
1. 简介 分布式链路追踪其实原理都很简单，每一个请求过来的时候，把一个context存到ThreadLocal里面，然后随着线程一路传递下去就行，一个请求大多数时候都是一个线程去执行下去所以并没有什么问题，但是如果在请求中使用了ThreadPool那么ThreadLocal中的context就会失联(如果使用的是Thread，ThreadLocal是可以继续传递下去的，具体原因可以去看ThreadLocal和ThreadPool的实现这里就不过多解释了)，所以需要插件的支持去把这个失联的context给找
3分钟上手SkyWalking指标开发：计数器与Gauge实战指南
最新发布
gitblog_00414的博客
09-12 625
你是否还在为服务监控指标不满足业务需求而烦恼？是否想实时掌握接口调用频次、资源使用率等关键数据？本文将带你零基础实现SkyWalking自定义计数器（Counter）与仪表盘（Gauge）指标，3分钟上手企业级监控指标开发。 ## 指标体系基础 SkyWalking的Meter系统提供流式指标计算能力，与传统OAL定义不同，它专注于数据类型本身，支持更灵活的作用域定义。每个指标需包含： - *...
【运维】SkyWalking链路监控（追踪）
欢迎指错||纠正||建议||水评+点赞&&评论&&关注&&转发
04-03 2998
skywalking支持dubbo，SpringCloud，SpringBoot集成，代码无侵入，通信方式采用GRPC，性能较好，实现方式是java探针，支持告警，支持JVM监控，支持全局调用统计等等，功能较完善。 分布式系统的应用程序性能监视工具，专为微服务、云原生架构和基于容器（Docker、K8s、Mesos）架构而设计。 提供分布式追踪、服务网格遥测分析、度量聚合和可视化一体化解决方案。
skywalking 沉了一年的线程池插件 bug 被我解决了
芋艿V
07-15 641
点击上方“芋道源码”，选择“设为星标”管她前浪，还是后浪？能浪的浪，才是好浪！每天 10:33更新文章，每天掉亿点点头发...源码精品专栏原创 | Java 2021超神之路，很肝~中文详细注释的开源项目RPC 框架 Dubbo 源码解析网络应用框架 Netty 源码解析消息中间件 RocketMQ 源码解析数据库中间件 Sharding-JDBC 和 MyCAT 源码解析作业调度中间件 E...
10分钟搞定SkyWalking告警：MAL语言自定义业务指标全指南
gitblog_00678的博客
09-12 358
你是否还在为系统异常不能及时发现而烦恼？是否希望根据业务特点定制告警规则？本文将带你通过MAL（Meter Analysis Language）实现SkyWalking告警指标的自定义，无需复杂编程，只需简单配置即可让告警系统精准反映业务健康状态。 ## MAL语言基础：从数据类型到核心操作 MAL是SkyWalking提供的指标分析语言，支持对指标数据进行过滤、聚合和转换。在MAL中，所有操...
Apache SkyWalking自定义指标仪表盘：JSON配置详解
gitblog_00528的博客
09-12 646
SkyWalking仪表盘系统采用分层架构设计，通过JSON/YAML配置文件实现前端可视化与后端指标数据的解耦。自定义仪表盘需遵循特定的JSON Schema规范，主要包含元数据定义、布局结构和指标查询三大部分。 ```mermaid flowchart TD A[用户配置] -->|JSON/YAML| B[仪表盘解析器] B --> C{验证合法性} C -->|通...
如何通过SkyWalking诊断Undertow线程池阻塞问题？
06-13
<think>嗯，用户现在想了解如何通过SkyWalking诊断Undertow线程池阻塞问题，这其实是个很有深度的性能调优场景。从用户提供的背景来看，他们已经在使用11G内存的容器环境运行SpringBoot+Undertow，之前我给出的JVM调优建议里特意强调了直接内存和线程池的调整，现在用户更聚焦在具体问题的诊断工具上。用户能准确提到SkyWalking这个工具很好，说明他们已经有基本的APM监控能力。不过从他们之前设置的ActiveProcessorCount=6和较低的ParallelGCThreads来看，可能对资源分配的理解还不够深入。需要特别注意用户环境是8核11G的容器，但线程池配置可能需要重新评估。看用户提供的四个引用材料挺有意思的：引用1提到SkyWalking能管理Undertow线程池，这正好契合需求；引用2是Undertow替换Tomcat的指导；引用3展示了自定义线程池的代码范例；引用4则暴露了Undertow底层使用ByteBuffer池的特性——这些都需要融入回答。具体诊断思路要分三层展开：首先是线程级指标，SkyWalking的线程状态监控能直接看到worker线程的runnable/waiting比例；其次是堆栈分析，这需要教用户怎么看阻塞调用链；最后要结合系统资源，因为直接内存不足也会引发线程阻塞。用户之前设置的MaxDirectMemorySize=1g可能偏小，上次建议改成2g看来是对的。对于核心监控指标，要重点教会用户看三个图：worker线程活跃数曲线、任务队列长度波动、直接内存利用率。特别要注意当队列突然飙升时，往往就是阻塞发生的时刻。引用4提到的bufferPool很关键，因为Undertow处理请求时每个连接都要占用buffer，如果bufferSize不够就会阻塞线程。线程池调参策略要给出具体公式。根据引用3的示例，虽然不建议完全照搬，但核心思路是正确的：corePoolSize设为CPU核数*2。考虑到用户是8核环境，worker-threads=200可能偏大，需要提醒他们通过监控数据动态调整。突然想到个隐患点：用户环境是否开启了异步日志？如果日志同步输出到文件，也可能导致worker线程阻塞。这个虽然不是线程池直接问题，但会影响表现症状，应该在优化建议里补充检查项。</think> 以下是使用SkyWalking诊断和解决Undertow线程池阻塞问题的完整指南： --- ### **一、SkyWalking核心监控指标** 1. **线程池监控入口** - 路径：SkyWalking控制台 → `Metrics` → `meter` → `undertow_thread_pool_active_threads` - 关键指标： - `max_threads`：Undertow最大工作线程数 - `active_threads`：实时活跃线程数 - `queue_size`：等待队列积压量 - **阻塞诊断点**：当 `active_threads ≈ max_threads` 且 `queue_size` 持续增长时，表明线程池满载阻塞[^1] 2. **线程状态分析** - 路径：SkyWalking → `Thread` → `Thread State` - 阻塞线程特征： - `WAITING` 或 `BLOCKED` 状态线程占比 > 30% - 查看堆栈定位阻塞点（如DB查询、锁竞争等） --- ### **二、阻塞问题诊断流程** ```mermaid graph TD A[发现响应延迟激增] --> B{SkyWalking检查} B --> C[观察 active_threads=max_threads?] C -->|是| D[检查queue_size增长趋势] C -->|否| E[检查GC或外部依赖] D --> F[检查线程状态分布] F --> G[分析阻塞堆栈] ``` 1. **典型阻塞场景识别** | 监控现象 | 可能原因 | 解决方案 | |---------|----------|----------| | `queue_size` 持续增长 | 突发流量或下游响应延迟 | 限流或扩容工作线程[^2] | | 大量`BLOCKED`线程 | 同步锁竞争（如synchronized） | 优化为并发数据结构 | | 高比例`WAITING`线程 | I/O阻塞（如慢SQL） | 优化DB查询或启用异步 | 2. **堆栈分析示例** 在SkyWalking的`Thread Stack`中查找高频阻塞方法： ``` java.lang.Thread.State: WAITING at sun.misc.Unsafe.park(Native Method) - waiting on <0x000000069d5b3fe0> at io.undertow.servlet.spec.AsyncContextImpl$BlockingTask.run(AsyncContextImpl.java:762) # 此处定位阻塞点 ``` --- ### **三、优化策略与参数调整** 1. **Undertow线程池调参 (application.yml)** ```yaml server: undertow: # 优化工作线程 (公式: 核数*8 + 预计阻塞比例) worker-threads: 200 # 使用直接内存避免堆外复制 direct-buffers: true buffer-size: 32768 # 32KB缓冲区减少碎片 # 限制队列防止雪崩 io-threads: 16 ``` **调参原则**：`worker-threads = (核心数 * 8) / (1 - 阻塞系数)`（阻塞系数≈外部调用耗时占比） 2. **JVM层优化** ```bash -XX:MaxDirectMemorySize=2g # Undertow直接内存至少2G -XX:+UseZGC # 低延迟GC减少停顿 -Xmx8g -Xms8g # 预留内存给直接缓冲区 ``` 3. **集成动态线程池** ```java @Bean public Executor dynamicThreadPool() { ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor(); executor.setCorePoolSize(Runtime.getRuntime().availableProcessors() * 4); // 初始核心线程 executor.setMaxPoolSize(200); executor.setQueueCapacity(50); // 小队列避免积压 executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); return executor; } ``` --- ### **四、验证与监控闭环** 1. **优化后验证指标** - `active_threads` 波动在 max_threads 的 70% 以下 - `queue_size` 长期保持为 0 - Avg Response Time 降低 > 50% 2. **配置SkyWalking告警规则** ```yaml rules: - name: undertow_thread_block expression: undertow_thread_pool_active_threads / undertow_thread_pool_max_threads > 0.9 duration: 5m # 持续5分钟触发告警 ``` --- ### **五、常见陷阱** 1. **缓冲区不足导致I/O阻塞** - 现象：线程卡在`ByteBuffer.allocate()` - 解决：增大`-XX:MaxDirectMemorySize`或`server.undertow.buffer-size` 2. **同步转异步优化** ```java // 阻塞式 → 异步非阻塞 @Async("dynamicThreadPool") public CompletableFuture<Void> asyncProcess() { // 原阻塞操作 } ``` ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值