Undertow 可观测性最佳实践
Undertow 介绍
Undertow 是 Red Hat 开发的一款高性能、灵活的 Java Web 服务器，也是 WildFly 应用服务器的嵌入式组件。它支持非阻塞 I/O，基于 NIO 构建，并提供了 HTTP/2、WebSockets 和 Servlet 4.0 等现代 Web 技术支持。Undertow 以其轻量级、嵌入式友好 的特性而闻名，开发者可以轻松将其集成到自己的应用程序中，也可以作为独立服务器运行。它的模块化设计允许用户按需选择所需功能，从而实现低资源占用和高吞吐量。
Undertow 可观测性在现代应用中至关重要。APM 虽能展示 HTTP 请求的端到端耗时，但它们无法直接揭示 Undertow 内部处理请求的细节。
Undertow 线程池配置不当可能导致：
- 请求排队：线程不足时，新请求等待处理，APM 中表现为 HTTP 请求耗时增加。
- 资源浪费或瓶颈转移：线程过多会增加上下文切换开销，甚至将压力转嫁给下游服务。
因此，监控 Undertow 的 XNIO Worker 线程数、活跃线程数、任务队列大小等指标，能有效识别请求处理瓶颈，确保系统高效稳定运行。
观测云
观测云是一款专为 IT 工程师打造的全链路可观测产品，它集成了基础设施监控、应用程序性能监控和日志管理，为整个技术栈提供实时可观察性。这款产品能够帮助工程师全面了解端到端的用户体验追踪，了解应用内函数的每一次调用，以及全面监控云时代的基础设施。此外，观测云还具备快速发现系统安全风险的能力，为数字化时代提供安全保障。
部署 DataKit
DataKit 是一个开源的、跨平台的数据收集和监控工具，由观测云开发并维护。它旨在帮助用户收集、处理和分析各种数据源，如日志、指标和事件，以便进行有效的监控和故障排查。DataKit 支持多种数据输入和输出格式，可以轻松集成到现有的监控系统中。
登录观测云控制台，在「集成」 - 「DataKit」选择对应安装方式，当前采用 Linux 主机部署 DataKit。
采集器配置
DataKit 配置
DataKit 安装完成后，可以自定义开启采集器，本集成需要开启如下两个采集器。
开启 StatsD 采集器
# 开启采集器
cp /usr/local/datakit/conf.d/statsd/statsd.conf.sample /usr/local/datakit/conf.d/statsd/statsd.conf
# 重启 Datakit
datakit service -R
开启链路采集
# 开启采集器
cp /usr/local/datakit/conf.d/ddtrace/ddtrace.conf.sample /usr/local/datakit/conf.d/ddtrace/ddtrace.conf
# 重启 Datakit
datakit service -R
客户端配置
场景环境：
jdk: 1.8.0_361
spring-boot: 2.7.12-SNAPSHOT
undertow：2.2.24.Final
备注： 不同版本指标可能会有差异。
以 Java Demo 应用为例，使用 undertow 作为 web 容器配置。
##启用 Undertow pom 配置
<dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-web</artifactId><exclusions><exclusion><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-tomcat</artifactId></exclusion></exclusions>
</dependency>
<dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-undertow</artifactId>
</dependency>
Demo 项目中 undertow 运行配置如下：
server.port=8080
server.undertow.threads.worker=10
server.undertow.threads.io=2
接入 APM ，配置采集 jmx ，应用启动增加如下参数，启动命令如下：
java \
-javaagent:/xxx/dd-java-agent.jar \
-Ddd.agent.port=9529 \
-Ddd.service=demo \
-Ddd.jmxfetch.check-period=1000 \
-Ddd.jmxfetch.enabled=true \
-Ddd.jmxfetch.config.dir=/xxx/ \
-Ddd.jmxfetch.config=undertow.yaml \
-jar xxxx.jar
dd-java-agent.jar Guance 版下载地址：
wget -O dd-java-agent.jar 'https://static.guance.com/dd-image/dd-java-agent.jar'
其中 -Ddd.jmxfetch.config.dir 和 -Ddd.jmxfetch.config=undertow.yaml 需要把 undertow.yaml 放到 Java 启动可以读取到的地址。
undertow.yaml 内容如下，无需修改。
init_config:instances:- jvm_direct: truename: undertow-monitoringcollect_default_jvm_metrics: falsecollect_default_metrics: falserefresh_beans: 60conf:- include:bean_regex: "org.xnio:type=Xnio,provider=\"nio\",worker=\"XNIO-.*\""attribute:IoThreadCount:metric_type: gaugealias: undertow.io.thread.count- include:bean_regex: "jboss.threads:name=\"XNIO-.*\",type=thread-pool"attribute:CorePoolSize:metric_type: gaugealias: undertow.core.pool.sizeMaximumPoolSize:metric_type: gaugealias: undertow.max.pool.sizeActiveCount:metric_type: gaugealias: undertow.active.countLargestPoolSize:metric_type: gaugealias: undertow.largest.pool.sizeCompletedTaskCount:metric_type: gaugealias: undertow.completed.task.countPoolSize:metric_type: gaugealias: undertow.pool.sizeGrowthResistance:metric_type: gaugealias: undertow.growth.resistanceMaximumQueueSize:metric_type: gaugealias: undertow.max.queue.sizeLargestQueueSize:metric_type: gaugealias: undertow.largest.queue.sizeSubmittedTaskCount:metric_type: gaugealias: undertow.submitted.task.countRejectedTaskCount:metric_type: gaugealias: undertow.rejected.task.countSpinMissCount:metric_type: gaugealias: undertow.spin.miss.countQueueSize:metric_type: gaugealias: undertow.queue.sizeKeepAliveTimeSeconds:metric_type: gaugealias: undertow.keep.alive.time.seconds
关键指标
指标集：undertow
| 指标 | 描述 | 用途 |
|---|---|---|
| active_count | 活跃线程数 | 当前线程池中正在执行任务的线程数量。 |
| completed_task_count | 已完成任务数 | 线程池自启动以来已完成的任务总数。 |
| core_pool_size | 核心线程池大小 | 线程池中始终保持活动的线程数，即使它们处于空闲状态。 |
| io_thread_count | I/O 线程数 | Undertow 底层 XNIO 框架用于处理网络 I/O 事件（如接受连接、读写数据）的线程数量。 |
| keep_alive_time_seconds | 线程保持活跃时间 | 当线程数超过核心线程数时，多余的空闲线程在被终止前可以等待的时间。 |
| largest_pool_size | 历史最大线程池大小 | 线程池自启动以来达到的最大线程数量。 |
| largest_queue_size | 历史最大队列大小 | 任务队列自启动以来达到的最大任务数量。 |
| max_pool_size | 最大线程池大小 | 线程池允许创建的最大线程数量。这是一个关键的配置参数，限制了并发处理能力。 |
| max_queue_size | 最大队列大小 | 任务队列可以容纳的最大任务数量。 |
| pool_size | 当前线程池大小 | 当前线程池中的总线程数量（包括活跃和空闲线程）。 |
| queue_size | 当前队列大小 | 当前在任务队列中等待被执行的任务数量。持续增长通常表示处理能力不足。 |
| rejected_task_count | 被拒绝任务数 | 由于线程池已满（线程数达到最大且队列已满）或拒绝策略触发，而被拒绝执行的任务数量。这是一个重要的过载指标。 |
场景视图
登录观测云控制台，点击「场景」 -「新建仪表板」，输入 “Undertow”， 选择 “Undertow监控视图”，点击 “确定” 即可添加视图。
监控器（告警）
Undertow 排队请求数监控
简要描述：检测指标 queue_size ， 5分钟内超过100触发告警，如下图：
Undertow 线程池使用率监控
简要描述：检测指标 pool_size/max_pool_size ， 5分钟内超过90% 触发告警，如下图：
总结
这些指标提供了 Undertow 线程池运行状态的全面视图，帮助开发者和运维人员监控和优化线程池的性能。通过合理配置和监控这些指标，可以确保线程池在高并发场景下高效运行，同时避免资源浪费和性能瓶颈。