小泉水先说明一点，eladmin 虽然定位是后台权限管理系统，但一个后台系统要真正跑得稳、扛得住线上流量，监控和运维才是后置的大头。很多人拿 eladmin 做脚手架，功能点一接，以为能跑就行，结果一上线就抓瞎：SQL 慢查询发现不了、服务器 CPU 被打满也毫无感知、内存泄漏只能靠重启大法硬扛。这篇文章我把自己在 eladmin 基础之上搭建监控与运维体系的经验完整拆一遍，包含 Druid、Prometheus、Grafana、node-exporter 与钉钉告警的对接细节，也都配上实际的配置过程和排错思路，希望能帮大家少走点弯路，直接能照着搭出一套能用的监控环境。
1. 从“跑得起来”到“跑得稳”：eladmin 引入监控的整体思路
eladmin 这套框架相信很多朋友都不陌生，它把 Spring Boot 后台、Vue 前端、代码生成、权限管理这些能力整合得相当顺手。但坦白讲，很多团队用它做项目，重心全都放在功能开发上，监控这块基本靠感觉——应用挂了看日志，内存爆了重启，SQL 慢查询等到用户抱怨才知道。
我在自己负责的某套基于 eladmin 的数据管理平台里，跑了大概三个月“裸奔”阶段后，实在撑不住才下决心补齐监控运维体系。白天用户数一多，数据库连接池告警直接刷屏，后来定位到是某个统计接口每次查询都要跑三张超过百万行的表，连 Druid 监控面板里都能看到 SQL 执行时长动不动就是几秒。那一刻我才意识到，监控不是锦上添花，而是项目能不能稳定交付的地基。
再说清楚一个容易被新手忽略的点：监控运维在全链路体系里，覆盖范围并不是单指应用本身，而是包含三个核心维度。第一是基础设施层，也就是服务器节点的 CPU、内存、磁盘、网络等资源使用情况，这个层面的异常往往预示着容量瓶颈或宿主机故障。第二是应用运行层，对应的是 Java 进程的 JVM 堆内存、GC 频率、线程池状态、接口吞吐量与响应时间等。第三是数据访问层，也就是数据库连接池活跃度、慢 SQL、事务执行时长等，这一层对 eladmin 这种强后台管理系统来说尤其重要，因为大量操作都依赖数据库交互。
选型上，我最终采用的是 Prometheus 加 Grafana 加 Alerts 的组合。eladmin 本身就是 Spring Boot 架构，天然适合通过 Actuator 暴露端点，再由 Prometheus 定期拉取指标；可视化看板统一切到 Grafana，数据源直接对接 Prometheus；告警规则则由 Prometheus 内置的 Alertmanager 统一管理，走钉钉机器人把异常消息推到工作群，团队响应速度比之前盯着日志排空前提升了一个量级。这套组合的好处在于各个组件都是开源方案，社区里能查到的资料和模板非常丰富，节点扩展也灵活，无论是一个实例还是一组集群，架构上都不用推倒重来。
各层分工具体是这样的：基础设施层用 node-exporter 采集宿主机指标，一个小型单体服务在资源耗尽之前也能靠它提前预警；应用层靠 Actuator 暴露 JVM 相关信息；数据层则直接用 eladmin 内置的 Druid 数据源监控能力。三块数据汇总到 Prometheus 后，统一在 Grafana 做仪表盘展示，再配合钉钉告警推送，整套链路覆盖到的恰恰是一个中小型团队最关心的几个问题：服务器资源够不够、应用还活着没有、数据库有没有拖后腿。
这套体系搭完之后，最大的直观感受是省心。以前半夜收到用户反馈系统卡顿，还得先翻日志、再手动连到服务器看资源占用，现在打开 Grafana 先看大盘，再按时间轴回追告警信息，基本几分钟内就能锁定问题区间。团队内非专业的运维同学也能在醒目位置直接看到系统健康度，不用每个人都会读日志。
接下来我按实际的落地顺序，把每一层的监控搭建过程展开说。先从 eladmin 最基础的 Druid 监控讲起，因为它的接入成本最低，反馈却最直接。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 内置 Druid 监控：先看清楚 SQL 和数据源的真实状态
2.1 为什么第一步要先打通 Druid 监控
eladmin 默认集成了 Druid 作为数据库连接池，它在最初设计时就把监控功能内置进去了，但很多项目在实际部署中并没有启用。这其实是一种浪费，因为 Druid 监控面板提供的信息对于后端性能问题定位几乎是零成本的：直接能看到活跃连接数、SQL 执行次数、最慢的几条 SQL 以及事务相关指标。
我当时第一次打开 Druid 面板时，一行统计数据立刻刷新了我的认知——某个列表查询接口的 SQL 在一天之内被调用了近万次，单次执行平均耗时 780 毫秒，而且查询条件里走了全表扫描。如果没有 Druid 监控，这种“隐性慢查询”几乎不可能通过人工 code review 发现。所以我说，在给 eladmin 加 Prometheus 和 Grafana 之前，先把 Druid 监控打开，这一步是性价比最高的监控投入。
2.2 开启 Druid 监控面板的配置要点
eladmin 默认的 Druid 配置里，访问监控页面的 Servlet 可能未开启或者被限制在本地访问。要想远程访问并看到监控数据，需要调整配置。先看依赖是否齐全，pom.xml 里的 druid-spring-boot-starter 一定得有，这一点 eladmin 本身已经带了，不需要额外加。
然后在 application.yml 里修改 Druid 的监控相关配置。我给出一份可以用的参考配置：
yaml复制spring:
datasource:
druid:
stat-view-servlet:
enabled: true
url-pattern: /druid/*
login-username: admin
login-password: your-password
reset-enable: false
web-stat-filter:
enabled: true
url-pattern: /*
exclusions: '*.js,*.gif,*.jpg,*.png,*.css,*.ico,/druid/*'
filter:
stat:
enabled: true
slow-sql-millis: 1000
log-slow-sql: true
wall:
enabled: true
这里有两点值得特别留意。第一，slow-sql-millis 设成 1000 毫秒，是让 Druid 把超过 1 秒的查询单独记录下来，这样可以直接在“慢 SQL”选项里看到问题语句，不用每次手动到数据库开慢查询日志。第二，login-username 和 login-password 一定要改，不要用默认值，而且生产环境建议通过防火墙把 /druid 路径限制在办公网 IP 段内，避免数据源信息泄露。
配置改完后，重启服务，浏览器访问 http://你的IP:端口/druid/index.html，输入刚才配置的用户名密码就能进入监控页面。我第一次看到那些统计数据的时候，最大的感受就是信息密度极高：数据源、SQL 监控、SQL 防火墙、Spring 监控、URI 监控，几乎覆盖了日常调优的常用维度。通过 URI 监控可以直接看到哪个接口调用的数据库次数最多、耗时最长，定位性能瓶颈时连链路追踪都不用开。
这一层监控的数据对于后续接入 Prometheus 也是有用的，因为它解决了“数据库这一侧是否健康”的问题，但它不能直接回答“服务器负载高是因为哪个进程”这一层问题，所以还需要把监控视野往系统资源和 JVM 上扩展。
3. 应用与资源监控：Actuator 对接 Prometheus 的完整过程
3.1 给 eladmin 应用暴露可采集的指标端点
Druid 解决的是“数据库里发生了什么”，而应用和资源层的监控解决的是“Java 进程和服务器在承受什么”。这一层我的选型是 Spring Boot Actuator 负责暴露指标，Prometheus 负责定时拉取和存储，Grafana 负责展示和告警联动