下面我将从监控目标、监控维度、监控工具、监控实践四个方面，为你详细梳理 WebLogic 的监控方案。
（图片来源网络，侵删）
监控的核心目标
在开始之前，首先要明确我们为什么要监控 WebLogic,主要目标包括：
- 性能分析：定位系统瓶颈，是 CPU、内存、网络还是应用本身的问题？
- 故障预警：在问题发生前或发生初期就发出警报,防患于未然。
- 容量规划：根据历史数据和增长趋势，预测未来资源需求,为扩容提供依据。
- 健康检查：快速了解 WebLogic 域的整体运行状态。
- 问题诊断：当故障发生时，能够快速定位根因,缩短恢复时间。
监控的核心维度
这是监控的核心内容，我们需要关注 WebLogic 运行环境的方方面面，可以将其分为三大类：基础设施、JVM/应用、WebLogic 服务器。
基础设施层监控
这是最基础的层面,物理或虚拟机的健康状况直接影响上层应用。
| 监控项 | 监控目的 | 工具/方法 |
|---|---|---|
| CPU 使用率 | 检查是否过载，是否存在高 CPU 消耗的线程或进程。 | top, htop, vmstat, sar |
| 内存使用率 | 检查物理内存是否耗尽，导致系统使用 Swap，严重影响性能。 | free, vmstat, sar |
| 磁盘空间 | 防止日志、临时文件等占满磁盘，导致应用或服务器宕机。 | df -h |
| 磁盘 I/O | 检查磁盘读写性能是否存在瓶颈。 | iostat, sar -d |
| 网络流量 | 检查网络带宽是否饱和，是否存在异常流量。 | iftop, nload, sar -n |
| 操作系统负载 | 综合评估系统整体负载情况。 | uptime, w |
JVM 及应用层监控
WebLogic 运行在 JVM 之上，JVM 的状态直接决定了应用的稳定性和性能。
（图片来源网络，侵删）
| 监控项 | 监控目的 | 工具/方法 |
|---|---|---|
| 堆内存使用情况 | 检查 Eden, Old, Survivor 区的使用率，判断是否存在内存泄漏或频繁 GC。 | jstat -gc <pid> |
| 非堆内存使用 | 检查 Metaspace (或 PermGen) 是否溢出，检查线程栈、Direct Memory 等。 | jstat -capacity <pid>, jstat -permgen <pid> (旧版) |
| 垃圾回收 | 监控 GC 频率和耗时，特别是 Full GC，过长会引发 Stop-The-World，导致应用卡顿。 | jstat -gcutil <pid>, jstat -gccause <pid> |
| 线程状态 | 检查线程数量、死锁、死循环、长时间等待的线程。 | jstack <pid>, JConsole, VisualVM |
| 类加载情况 | 监控加载的类数量，防止内存溢出。 | jstat -class <pid> |
| 应用日志 | 通过关键字监控日志，如 ERROR, Exception, Timeout 等，及时发现应用异常。 |
grep, awk, ELK Stack (Elasticsearch, Logstash, Kibana) |
WebLogic 服务器自身监控
这是针对 WebLogic 作为应用服务器的特有监控项。
| 监控项 | 监控目的 | 工具/方法 |
|---|---|---|
| 服务器状态 | 监控 Admin Server 和 Managed Server 是否处于 RUNNING, ADMIN, FAILED 等状态。 |
WebLogic Console, WLST, JMX |
| JMS 监控 | 监控 JMS 服务器、连接工厂、队列、主题的状态，检查队列深度、消息数量，防止消息积压。 | WebLogic Console, JMX |
| JDBC 监控 | 监控 JDBC 数据源连接池的使用情况，活跃连接数、等待连接的请求数、总连接数等。 | WebLogic Console, JMX |
| 应用部署状态 | 监控应用是否成功部署，是否处于 ACTIVE 状态。 |
WebLogic Console, WLST |
| 线程池 | 监听线程、工作线程池的配置和使用情况。 | WebLogic Console, JMX |
| 执行队列 | 监控请求在执行队列中的等待时间，过高说明处理能力不足。 | WebLogic Console, JMX |
| HTTP 监控 | 监控 HTTP 请求量、平均响应时间、错误率（5xx, 4xx）。 | WebLogic Console, JMX, Nginx/Apache 日志 |
监控工具与实现方式
根据监控的深度和自动化程度,可以选择不同的工具组合。
命令行工具 (CLI)
适合快速、手动检查和诊断。
weblogic.Admin/WLST (WebLogic Scripting Tool)：- 功能：WebLogic 官方提供的命令行工具，功能强大，可以连接到 Admin Server，查询和管理 MBean，获取服务器状态、JDBC 连接池、JMS 队列等几乎所有信息。
- 优点：无需图形界面,可编写脚本实现自动化监控。
- 示例：
connect('user', 'password', 't3://admin-server:7001')->cmo.getServer().getState()
jps,jstat,jstack,jmap：- 功能：JDK 自带的 JVM 诊断工具，用于查看 JVM 进程、内存、GC、线程堆栈等。
- 优点：JVM 问题诊断的利器。
- 操作系统命令：
- 功能：如
top,vmstat,df等,用于监控服务器资源。
- 功能：如
WebLogic Console
图形化管理控制台。
（图片来源网络，侵删）
- 功能：提供直观的界面来查看域的整体健康状况、服务器状态、部署的应用、JDBC/JMS 配置和运行时数据。
- 优点：操作简单，可视化,适合日常巡检。
- 缺点：无法进行自动化监控和告警,需要手动刷新。
JMX (Java Management Extensions)
这是实现自动化、精细化监控的核心和标准方式。
- 功能：JMX 是 Java 的标准管理框架，WebLogic 内置了大量 MBean (Managed Bean)，这些 MBean 暴露了 WebLogic 的所有管理属性和操作，监控工具通过 JMX 协议连接到 WebLogic Server，读取这些 MBean 的数据。
- 优点：
- 标准化：Java 世界的事实标准。
- 丰富：可获取的信息非常全面和深入。
- 自动化：非常适合被第三方监控系统集成。
- 如何使用：
- 使用 JConsole/VisualVM：JDK 自带的工具，可以连接到本地或远程的 JMX 服务，手动浏览 MBean 树和查看数据。
- 使用专业监控平台：这是最推荐的方式，Prometheus, Zabbix, Nagios, Datadog, Dynatrace 等监控平台都支持通过 JMX Exporter 或自定义插件来采集 WebLogic 的 MBean 数据。
专业 APM (Application Performance Monitoring) 工具
提供端到端的性能监控,从代码级别到基础设施。
- 代表工具：Dynatrace, New Relic, Elastic APM (SkyWalking, Pinpoint)。
- 功能：
- APM：深入到方法级别，追踪一个请求在应用内部的完整调用链,精准定位慢代码。
- 基础设施监控：自动发现并监控服务器、容器等。
- 日志关联：将日志和性能数据关联起来,快速定位问题。
- 智能告警：基于 AI 的异常检测。
- 优点：功能强大，可视化效果好,问题诊断效率极高。
- 缺点：通常是商业软件,成本较高。
开源监控方案 (以 Prometheus + Grafana 为例)
这是目前非常流行的现代化监控解决方案，非常适合云原生和 DevOps 环境。
- 架构：
Prometheus：时序数据库,负责抓取指标数据。JMX Exporter：一个独立的 Java 应用，它通过 JMX 协议从 WebLogic 获取 MBean 数据，并将其转换成 Prometheus 能够理解的 HTTP 接口。Grafana：可视化工具，连接 Prometheus 数据源,创建丰富的监控仪表盘。
- 实现步骤：
- 在 WebLogic Server 所在的机器上，下载并运行
JMX Exporter。 - 配置
JMX Exporter的config.yaml文件，指定需要从哪些 MBean 中提取哪些指标。 - 配置
Prometheus的prometheus.yml文件，添加JMX Exporter的 HTTP 地址为一个target。 Prometheus会定期拉取JMX Exporter的数据。- 在
Grafana中添加Prometheus数据源,并导入或创建仪表盘来展示数据。
- 在 WebLogic Server 所在的机器上，下载并运行
监控实践建议
- 建立基线：首先在业务平稳运行期，收集各项指标数据，建立“正常”状态的基线，没有基线,任何指标都没有意义。
- 分层监控：采用“基础设施 -> JVM -> WebLogic”的分层监控策略，从底层向上层排查问题,逻辑清晰。
- 自动化告警：设置合理的告警阈值。
- CPU 持续 5 分钟 > 80%
- JVM Heap 内存使用率 > 85%
- JDBC 连接池等待请求 > 5
- 服务器状态不为
RUNNING - 关键日志中出现
OutOfMemoryError - 使用邮件、短信、钉钉/企业微信等方式及时通知。
- 可视化：使用 Grafana 或其他工具创建统一的监控大屏，将所有关键指标集中展示,方便运维人员一目了然地掌握系统健康状况。
- 日志集中化：将所有 WebLogic 服务器和应用日志收集到 ELK Stack 或 Graylog 等日志平台，方便进行全文检索、日志分析和关联告警。
- 定期巡检：除了自动化监控，还应定期（如每周）进行手动巡检，检查配置变更、备份情况等。
| 监控层级 | 关键指标 | 推荐工具/方法 |
|---|---|---|
| 基础设施 | CPU, 内存, 磁盘, 网络 | top, vmstat, Zabbix, Prometheus Node Exporter |
| JVM | 堆内存, GC, 线程 | jstat, JConsole, VisualVM, Prometheus JMX Exporter |
| WebLogic | 服务器状态, JDBC, JMS, 执行队列 | WLST/JMX, WebLogic Console, Prometheus JMX Exporter, Dynatrace |
| 应用日志 | ERROR, Exception, Timeout | ELK Stack, Graylog, Fluentd |
对于大多数企业来说，“Prometheus + JMX Exporter + Grafana” 是一个非常强大且灵活的开源监控组合，能够满足绝大多数 WebLogic 监控需求，如果预算充足，Dynatrace 这类 APM 工具能提供更深入、更智能的端到端解决方案。
