基于 Java 17 + Spring Boot 3.5 技术栈，针对服务器资源使用率采集和服务心跳健康探针两大需求，主流开源方案可分为「Spring 官方原生生态」「专业硬件采集库」「生产级监控栈」三大类，以下是详细对比与选型建议。
一、Spring 官方原生方案（首选，零兼容风险）
1. Spring Boot Actuator + Micrometer
这是 Spring Boot 3.x 体系下最标准、开箱即用的方案，完全适配 Java 17 和 Spring Boot 3.5，无需引入第三方额外依赖。
核心能力
心跳健康探针：内置
/actuator/health端点，返回服务整体运行状态（UP/DOWN）；支持自定义HealthIndicator扩展业务级检查（如数据库连通性、Redis 状态、第三方接口可用性）。系统资源指标：底层基于 Micrometer 统一度量模型，可采集：
CPU：系统整体 CPU 使用率、JVM 进程 CPU 使用率
内存：JVM 堆 / 非堆内存、物理内存使用率、GC 指标
存储：磁盘总容量、剩余容量、使用率
线程、类加载、HTTP 请求等应用层指标
多监控系统对接：原生支持暴露 Prometheus 格式指标，一键对接 Grafana、InfluxDB 等。
集成方式
引入依赖：
配置文件开启端点：
优缺点
优点：与 Spring Boot 无缝集成，零兼容问题，生态完善，支持自定义扩展
局限：系统硬件指标粒度偏通用，无法获取单核 CPU 详情、磁盘 IO 读写速率等精细化硬件数据
2. Spring Boot Admin
定位为 Spring Boot 应用的可视化管理平台，基于 Actuator 能力封装，适合多实例统一运维场景。
核心能力
集中展示所有服务实例的心跳状态、在线离线列表
可视化查看 CPU、内存、磁盘等资源指标趋势
支持日志级别动态调整、环境配置查看、线程 Dump 等运维操作
内置邮件、钉钉等告警通知能力
架构与兼容性
分为 Admin Server（管理端）和 Admin Client（业务端接入）
最新 3.x 版本完全兼容 Spring Boot 3.5 + Java 17
二、专业硬件信息采集库（精细化采集）
如果需要获取更底层、更精细的服务器硬件数据（如单核 CPU 使用率、磁盘 IO、传感器温度等），推荐使用以下专业库。
1. OSHI (Operating System and Hardware Information)
目前 Java 生态最活跃的系统硬件采集库，纯 Java 实现，无任何本地依赖，跨平台支持 Linux/Windows/MacOS，完全兼容 Java 17。
核心能力
CPU：整体使用率、单核使用率、CPU 型号核心数、系统负载
内存：物理内存总量 / 已用 / 可用、交换分区详情
存储：各磁盘分区使用率、磁盘读写 IO 速率、磁盘型号序列号
网络：网卡流量、IP 地址、网络接口状态
进程：当前进程资源占用、系统进程列表
Spring Boot 集成示例
引入依赖：
代码使用：
优缺点
优点：数据粒度极细，纯 Java 实现部署简单，社区活跃持续更新
局限：无内置 HTTP 端点，需要自行封装为监控接口或对接 Micrometer
2. Hyperic Sigar（备选）
老牌系统采集库，依赖本地 C 动态库（so/dll），性能优异但存在明显短板：
官方更新停滞，Java 17 模块化兼容性较差，需要额外处理 JVM 参数
跨平台部署需要对应系统的原生库文件，运维成本高
仅建议老项目兼容使用，新项目优先选择 OSHI
三、生产级完整监控栈
面向生产环境长期运维，推荐采用「采集 + 存储 + 可视化」全链路方案：
Micrometer + Prometheus + Grafana
架构逻辑
采集层：Spring Boot 内置 Micrometer 负责采集 CPU、内存、业务指标
存储层：Prometheus 定时拉取指标并持久化存储
可视化层：Grafana 搭建监控大盘，配置阈值告警
核心优势
支持资源指标趋势分析、历史数据回溯
丰富的告警规则（CPU 过高、内存溢出、服务离线心跳超时）
大量现成的 Spring Boot 监控大盘模板，开箱即用
四、心跳探针补充方案
如果需要更轻量、协议更灵活的心跳检测，可结合以下方式：
TCP 心跳：通过 Netty 自定义 TCP 端口探针，适合非 HTTP 服务
K8s 探针：部署在 Kubernetes 时，直接复用 Actuator 的 health 端点作为 livenessProbe 和 readinessProbe
自定义心跳接口：基于 OSHI 封装专属 HTTP 接口，返回业务状态 + 资源使用率的聚合数据
五、数据采集不推荐MySQL
不推荐使用 MySQL 来持久化存储 Micrometer 采集的 CPU、内存、磁盘等监控指标，也并非必须持久化到 MySQL 才能实现历史趋势可视化。
这类高频时序监控数据，行业标准方案是采用时序数据库（TSDB）存储，搭配专业可视化工具。在 Spring Boot 3.x + Micrometer 生态下，黄金组合是 Prometheus + Grafana，全程几乎无需自定义开发，开箱即可实现历史趋势图表展示。
为什么不建议用 MySQL 存监控指标？
MySQL 作为关系型数据库，并不适配监控指标「高频写入、时序聚合、海量冷数据」的核心特性，弊端非常明显：
写入性能与成本不匹配 监控指标通常采集频率为 10s~60s / 次，单应用就会产生 CPU、内存、磁盘、JVM、HTTP 等上百个指标项，长期运行数据量膨胀极快。MySQL 行式存储 + 事务机制在高频写入场景下开销大，索引会持续膨胀，写入性能会随数据量增长快速下降。
时序查询效率低下 历史趋势可视化的核心是「按时间维度聚合、降采样、多指标关联查询」。用 MySQL 实现这类查询需要编写复杂的按时间分组语句，且无法利用时序数据库的专属优化，大范围时间查询（如近 7 天、近 30 天）响应会非常慢。
Micrometer 无原生支持 Micrometer 作为度量门面，官方提供了 Prometheus、InfluxDB、VictoriaMetrics 等十余种时序存储的注册中心（Registry），但没有原生提供 MySQL/JDBC 注册中心。若要存入 MySQL，需要自行编写代码读取指标、定时入库，开发和维护成本高。
运维成本高 监控数据通常只需保留一段时间（如 30 天），过期数据需自动清理。MySQL 需要自行开发定时清理逻辑，数据量大后还需考虑分表、分区等优化，远不如时序数据库自带的 TTL 自动过期机制便捷。
六、选型建议
原文链接
欢迎访问 小易撩挨踢