第十八章. 系统监控 (Admin)：应用的“健康仪表盘”

本章学习路径

我们将按照以下路径，层层递进，掌握 Spring Boot Admin 的应用与原理：

18.1. 监控的基石：Spring Boot Actuator

在开始使用 Admin 监控界面之前，我们必须先理解这一切的“数据源”—— Spring Boot Actuator。不理解 Actuator，我们就无法真正理解 Admin 界面的数据从何而来，也无法在 Admin 功能不满足需求时进行扩展。

18.1.1. 为什么需要应用监控？（Actuator 的价值）

一个已经启动并运行的 Spring Boot 应用，对于开发者和运维人员来说，默认是一个“黑盒”。我们知道它在运行，但内部发生了什么？

• 它的健康状态如何？数据库连接还正常吗？
• 当前的内存（Heap）占用了多少？垃圾回收（GC）是否频繁？
• 它加载了哪些 Spring Bean？YML 配置文件中的哪些配置生效了？

在没有 Actuator 之前，我们可能需要通过 JMX 工具、复杂的日志分析甚至停止应用才能获取这些信息。Actuator 的价值在于，它为 Spring Boot 应用提供了一套 标准化的、开箱即用的“数据探针”。

18.1.2. 什么是 Actuator：Spring Boot 的“数据探针”

Actuator（全称 Spring Boot Actuator）是 Spring Boot 官方提供的一个核心组件。它并不是一个独立的软件，而是以内嵌的方式，为我们的 Spring Boot 应用增加一系列用于监控和管理的 HTTP 端点（Endpoints）。

一旦在项目中引入 spring-boot-starter-actuator 依赖，它就会自动暴露多个 URL，例如 /actuator/health、/actuator/metrics 等。当访问这些 URL 时，应用会以 JSON 格式返回当前的运行时信息。

18.1.3. 两种访问方式：JMX (jconsole) vs. HTTP (JSON)

Actuator 暴露的数据可以通过两种主要方式被消费，它们各有侧重：

在本地开发时，我们可以通过 jconsole（Java 自带的工具）连接到 DromaraApplication 进程，查看到原始的 JVM 数据。

我们可以通过 在 cmd 中 打开 jconsole（前提是 Java 环境变量设置好了）

18.1.4. Admin 的角色：Actuator 的可视化界面

虽然 Actuator 提供了数据，但直接访问 /actuator/health 得到的是一堆 JSON，这对人类阅读并不友好，而且我们无法在一个地方同时管理多个应用的 Actuator 端点。

Spring Boot Admin (SBA) 正是解决这个问题的。它是一个独立的 Spring Boot 应用（在本项目中是 ruoyi-monitor 模块），其核心职责就是：

1. 充当“客户端”：它会定时轮询（Polling）所有注册上来的其他 Spring Boot 应用（如 ruoyi-admin、ruoyi-snailjob-server）。
2. 调用 Actuator 接口：它通过 HTTP 方式调用这些应用的 /actuator/health、/actuator/metrics 等接口。
3. 提供“可视化 UI”：它将获取到的 JSON 数据进行解析和美化，以图表和仪表盘的形式，在一个统一的 Web 界面上展示出来。

所以我们可以得到以下的结论：

Actuator 是“数据生产者”（安装在每个被监控的应用上）。

Spring Boot Admin 是“数据消费者”和“展示者”（一个独立的服务）。

RuoYi-Vue-Plus 项目中，ruoyi-admin、ruoyi-snailjob-server 都内置了 Actuator；而 ruoyi-monitor 就是 Spring Boot Admin 服务。

18.1.5 本节小结

我们弄清了 Actuator 作为数据源的核心地位，以及 Admin 作为可视化界面的角色。

核心要点
Actuator 是 Spring Boot 内置的数据探针，用于暴露应用的运行时信息。
Admin 是一个独立的服务，它通过轮询 Actuator 的 HTTP 端点来提供可视化监控界面。
JMX 适用于本地深度诊断，而 HTTP 适用于远程自动化监控。

18.2. 访问监控中心与界面总览

在上一节中，我们已经建立了清晰的理论基础：Actuator 负责生产数据，Admin 负责消费和展示。但在实际开发中，我们几乎只与 Admin 的 UI 界面打交道，因为 JSON 格式的原始数据难以快速定位问题。本节我们将学习如何登录 Admin 中心，并熟悉其核心视图。

18.2.1. 登录 Admin 与凭证配置

首先，我们启动所有服务（特别是 ruoyi-monitor 模块）。在浏览器中访问系统监控菜单下的 “Admin 监控”。

系统会提示输入用户名和密码。这组凭证 并非 RuoYi 系统的用户（如 admin / admin123），而是 Spring Boot Admin 服务自身的安全配置。

文件路径：RuoYi-Vue-Plus/pom.xml

在 ruoyi 主模块的 pom 配置文件中，我们可以找到它的安全配置：

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

<profile>
    <id>dev</id>
    <properties>
        <!-- 环境标识，需要与配置文件的名称相对应 -->
        <profiles.active>dev</profiles.active>
        <logging.level>info</logging.level>
        <monitor.username>ruoyi</monitor.username>
        <monitor.password>123456</monitor.password>
    </properties>
    <activation>
        <!-- 默认环境 -->
        <activeByDefault>true</activeByDefault>
    </activation>
</profile>

使用 ruoyi 和 123456 登录后，我们就能进入监控主界面。

18.2.2. “应用”视图：实例注册与状态

登录后默认进入的是 “应用” (Applications) 视图。这是最常用的界面。

在这个视图中，我们可以看到所有已成功注册到 Admin 中心的应用实例（Instance）。一个“实例”通常就是一个正在运行的 Spring Boot 进程。

在 RuoYi-Vue-Plus 的默认配置下，我们能看到三个实例：

1. ruoyi-vue-plus：主业务应用 (ruoyi-admin 模块)。
2. ruoyi-monitor-admin：Admin 服务本身（它也在监控自己）。
3. ruoyi-snailjob-server：分布式任务调度中心。

每个实例都会显示其 健康状态，通常是 UP（在线）或 OFFLINE（离线）。点击应用左侧的箭头，可以展开查看该实例的详细信息，例如 IP 地址、端口号和实例 ID。

18.2.3. 备选视图：“应用墙”与“日志报表”

除了默认的列表视图，Admin 还提供了两种辅助视图：

应用墙
“应用墙”视图以卡片的形式平铺所有实例，比列表视图更简洁。它主要用于“概览”，快速查看所有实例的 UP / OFFLINE 状态、版本号和运行时长，适合在大屏幕上进行投屏展示。

日志报表
“日志报表”记录了所有实例 状态变更 的历史事件。例如，ruoyi-admin 何时注册、何时状态从 UP 变为 OFFLINE，都会在这里留下时间戳和记录。这对于排查“应用为什么会掉线”这类问题非常有用。

18.2.4. 本节小结

我们掌握了如何登录 Admin 监控中心，并熟悉了其核心视图的用途。

核心要点

• Admin 的登录凭证（默认 ruoyi/123456）在 RuoYi-Vue-Plus 项目的根 pom.xml 文件的 dev profile 中定义。
• “应用”视图是核心，用于查看所有注册实例的健康状态。
• “应用墙”是简洁的概览视图，“日志报表”则用于追踪实例的状态变更历史。

18.3. [核心] 实例详情：应用的“体检报告”

在上一节中，我们已经知道了如何查看所有应用的“在线”或“离线”状态。但在实际的生产环境中，一个应用“在线” (UP) 并不意味着它“健康” (Healthy)。例如，应用可能还活着，但数据库连接池已满，或 Redis 已断开连接。

本节我们将深入 Admin 的核心功能——实例详情页，学习如何阅读这份详细的“体检报告”，并模拟故障来理解关键指标的含义。

18.3.1. 关键指标：JVM、垃圾回收与内存

在“应用”视图中，点击任意一个实例的名称（例如 ruoyi-vue-plus），即可进入详情页。

在这里，我们首先关注的是 JVM（Java 虚拟机）相关的核心指标，它们是判断应用性能的基石：

• 进程与线程：显示应用的运行时长（Uptime）、CPU 使用率、当前线程总数等。
• 垃圾回收 (GC)：显示 GC（如 G1 Young Generation）发生的次数和总耗时。如果耗时过长或次数过于频繁，说明可能存在内存管理问题。
• 内存 (Memory)：以图表形式展示“堆内存 (Heap)”和“非堆内存 (Non-Heap)”的使用情况，帮助我们快速识别内存占用是否合理，有无内存泄漏的趋势。

18.3.2. [重点] 健康状态：数据库、Redis 与磁盘的多维检查

详情页中最重要的模块是 “健康” (Health)。

Spring Boot Actuator 的 /health 端点不只是一个简单的“UP”，它是一个 组合式 的健康检查器。它会自动检测应用所依赖的各种基础组件，并汇总它们的健康状况。

在 RuoYi-Vue-Plus 中，“健康”模块会同时报告以下组件的状态：

• diskSpace：应用所在服务器的磁盘空间。如果磁盘满了，应用状态会变为 DOWN。
• db：数据库连接池。它会执行一个简单的查询（如 SELECT 1）来验证数据库连接是否可用。
• redis：Redis 服务的连接状态。
• ping：应用自身的存活状态。

只有当 所有 这些子项都处于 UP 状态时，该实例的总健康状态才会被标记为 UP。任何一个子项的失败，都会导致总状态变为 DOWN 或 UNKNOWN。

18.3.3. [实战] 故障模拟：如何解读“离线”与“异常”状态

为了深刻理解健康检查机制，我们来推演三种常见的生产故障场景，以及它们在 Admin 界面上的具体表现。

场景一：数据库服务宕机 (模拟停掉 MySQL)

1. 故障发生：MySQL 服务崩溃或网络中断。
2. Actuator 反应：ruoyi-admin 内置的 db 健康检查器在执行 SELECT 1 时失败。
3. Admin 界面表现：
   • ruoyi-admin 实例的状态会从 UP 变为 OFFLINE（或显示红色感叹号）。
   • 点入“详情”页，“健康”模块会清晰地显示 db (数据库) 指标为 DOWN，并可能附带 TimeoutException (超时) 或“连接拒绝”等错误信息。
   • ruoyi-snailjob-server 也会因为同样的原因变为 OFFLINE。
4. 恢复：当 MySQL 服务恢复后，Actuator 探针检测到连接正常，db 指标变回 UP，实例状态自动恢复为 UP。

场景二：缓存服务宕机 (模拟停掉 Redis)

1. 故障发生：Redis 服务崩溃。
2. Actuator 反应：redis 健康检查器连接 Redis 失败。
3. Admin 界面表现：
   • ruoyi-admin 实例状态变为 OFFLINE。
   • 点入“详情”页，“健康”模块会显示 redis 指标为 DOWN。

场景三：应用进程崩溃 (模拟停止 DromaraApplication)

1. 故障发生：ruoyi-admin 的 Java 进程 (JVM) 彻底停止。
2. Actuator 反应：Admin Server ( ruoyi-monitor ) 无法连接到 ruoyi-admin 的任何 Actuator 端口（因为进程都没了）。
3. Admin 界面表现：
   • ruoyi-admin 实例状态变为 OFFLINE。
   • 此时 无法点入“详情”页，因为 Admin 无法从一个已停止的应用获取任何数据。
   • 界面上通常会提示 Connection refused (连接被拒绝) 或类似的错误。

通过这三种模拟，我们能够清晰地分辨出：到底是“应用本身崩溃了”，还是“应用依赖的外部服务（如数据库）出问题了”。

18.3.4. 本节小结

我们深入学习了实例详情页的各项指标，特别是多维度的“健康”检查机制，并掌握了如何通过故障现象反推问题根源。

核心要点

• 实例详情页提供了 JVM 内存、GC 和线程等深度性能指标。
• “健康” (Health) 模块是排查问题的核心，它汇总了数据库、Redis、磁盘等多个子系统的状态。
• OFFLINE 状态必须先分析健康详情：db DOWN 意味着数据库问题；redis DOWN 意味着缓存问题；无法访问详情则通常意味着应用进程已停止。

18.4. 运行时诊断：环境与日志

在上一节中，我们学会了如何通过“健康”模块判断应用是否因外部依赖（如数据库或 Redis）而“生病”。但在实际开发中，我们还会遇到更复杂的问题，比如“为什么我本地运行正常，一到服务器上配置就不生效？”或者“我想临时追踪某个方法的日志，但我不想重启服务”。本节我们将学习 Admin 提供的另外两大诊断利器：环境配置与日志管理。

18.4.1. 环境（Environment）：查看系统与 YML 配置

“环境”选项卡提供了一个应用 运行时配置 的完整快照。它聚合了多个来源的配置属性，是排查“配置未生效”问题的首选之地。

它主要包含：

• System Properties：Java 虚拟机的系统属性（例如 java.vm.version）。
• Environment Variables：操作系统级别的环境变量。
• Application Properties：来自 application.yml 或 bootstrap.yml 的配置项。

当我们在服务器上通过 -D 参数启动应用时，可以在这里检查参数是否被成功加载。

18.4.2. [重点] 脱敏信息：查看完整配置的安全性考量

出于安全考虑，Actuator 默认会对敏感信息进行“脱敏”。当我们在“环境”选项卡中查看配置时，会发现所有包含 password、secret、key 等关键字的属性值，都会被替换为 ******。

我们需要在 RuoYi-Vue-Plus/ruoyi-admin/src/main/resources/application-dev.yml <- (注意是dev配置) 底下新增如下配置

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

--- # Actuator 环境端点配置（仅开发环境）
# ⚠️ 安全警告：此配置仅用于开发环境，生产环境必须保持默认的脱敏设置
# 此配置允许在开发环境中查看完整的配置信息（包括密码等敏感信息）
# 在生产环境中，Actuator 会自动对包含 password、secret、key 等关键字的属性值进行脱敏处理
management:
  endpoint:
    env:
      # 显示配置值的方式：
      # NEVER - 永远不显示值（默认，生产环境推荐）
      # WHEN_AUTHORIZED - 仅在授权时显示
      # ALWAYS - 总是显示（仅用于开发环境）
      show-values: ALWAYS

这是一个重要的安全特性，防止了生产环境的数据库密码等信息通过 UI 界面泄露。在 RuoYi-Vue-Plus 中，这一特性是默认开启的。如果确有必要在开发环境中查看完整信息，需要修改 Actuator 的配置，但这在生产环境中是 严格禁止 的。

18.4.3. 实时日志（Logfile）：在线查看应用日志

在传统的运维方式中，排查线上问题需要登录到服务器，使用 tail -f 命令来实时滚动日志。Spring Boot Admin 提供了“日志” (Logfile) 功能，允许我们直接在 Web 界面上查看应用的实时日志输出。

这极大地方便了开发者在不接触服务器的情况下快速定位问题。

18.4.4. [核心] 动态日志级别（Loggers）：免重启热更新

这是 Admin 监控中最实用的功能之一。

痛点：生产环境的日志级别通常设置为 INFO，以减少性能开销。但当遇到特定问题时，我们需要 DEBUG 级别的日志来追踪方法调用链。在过去，这需要修改 logback.xml 文件，然后 重启应用，这在生产环境中是代价高昂的。

解决方案：“日志配置” (Loggers) 功能允许我们 在运行时动态修改 任何一个 Java 包或类的日志级别，无需重启。

标准操作流程：

1. 在“日志配置”中，通过包名（例如 com.ruoyi.system.service）找到需要调试的类。
2. 将其日志级别从 INFO 临时调整为 DEBUG。
3. 切换到“日志”选项卡，复现操作，观察详细的 DEBUG 日志。
4. 问题定位后，务必 在“日志配置”中将其改回 INFO。

18.4.5. 启动（Startup）：分析应用启动耗时

此功能需要应用在启动时收集“启动事件”（ApplicationStartup）。RuoYi-Vue-Plus 5.x 默认配置了此项。

它以时间轴的形式，展示了 Spring Boot 应用在启动过程中，每个阶段（如环境准备、Bean 初始化）的耗时。这对于分析和优化“应用启动缓慢”问题非常有用，可以快速定位是哪个 Bean 的初始化拖慢了整体速度。

18.4.6. 本节小结

我们学习了如何使用 Admin 界面来诊断应用的配置和日志问题，特别是掌握了免重启修改日志级别的核心技巧。

核心要点

• “环境”选项卡是排查“配置未生效”问题的利器，敏感信息默认会被脱敏。
• “日志”选项卡提供了 tail -f 的功能，可以在线实时查看日志。
• “日志配置”允许在运行时动态修改日志级别（如 INFO -> DEBUG），是排查线上问题的“神器”。
• “启动”选项卡用于分析应用启动过程中的性能瓶颈。