凌晨两点十七分，做接某银行核心支付系统的口可控监控大屏上，一条红色告警弹出：weblogic集群中三个托管服务器节点响应时间从80ms飙升至3200ms。用性值班工程师老张第一反应不是和性看数据库慢查询，而是做接直接敲下`weblogic.Admin`命令检查JMS队列积压——他太熟悉这套老伙计的脾气了。weblogic的口可控可用性监控，从来不是用性简单的ping通或端口通就万事大吉。

真正的和性监控要从连接池下手。很多团队盯着weblogic的做接控制台看“健康状态”显示“OK”，但用户已经在投诉页面转圈。口可控问题往往出在JDBC连接池的用性等待时间上。我见过一个案例：连接池最大容量设了50，和性但应用代码里有个连接泄漏的做接bug，导致实际可用连接只剩3个，口可控新请求全部在池子外边排队。用性当时监控系统只抓了线程数和CPU，完全没暴露连接池的饥饿状态。所以，监控脚本里必须加一条`weblogic.health.jdbc.activeCount`和`waitingConnectionCount`的对比，一旦等待数超过活跃数的50%，立刻触发告警。

性能监控的另一个坑是JVM的Full GC频率。weblogic跑在JVM上，老年代如果持续膨胀，每次Full GC都会让所有线程停顿几秒。我们曾用`jstat -gcutil`每30秒采样一次，发现某个节点的Full GC次数从每小时2次跳到15次，但weblogic控制台的“性能”页面上显示的平均响应时间还是绿的——因为那个平均值被大量低延迟请求稀释了。后来改成分位数统计，专门看P99响应时间，问题立刻现形。别相信平均值，在weblogic监控里，P99才是用户真实体感的温度计。

还有个细节容易被忽略：weblogic的日志文件。默认的`access.log`只记录请求路径和状态码，但如果你在`config.xml`里开启`log4j`的耗时字段，就能拿到每个接口的精确处理时间。我习惯写个shell脚本，每五分钟扫描一次最新日志，用awk提取耗时超过3秒的请求，再按接口路径做聚合。这个方法比任何APM工具都来得直接——有一次排查到某个查询接口在特定参数组合下走了全表扫描，就是靠日志里的耗时分布发现的，那会儿数据库监控和weblogic指标全是正常的。

说到可用性，不能只盯应用本身。weblogic和前端负载均衡器之间的keepalive超时配置，是个经典杀手。有个客户环境，F5上配置的idle timeout是120秒，而weblogic的`connection-timeout`默认设成180秒，结果用户鼠标停在一个页面超过两分钟，再点击时F5已经断开了连接，weblogic却还在傻等。请求直接卡死直到超时。这种问题用脚本模拟长空闲后的请求，比任何监控工具都有效——每半小时发一个延迟150秒的探测请求，看返回码是否正常。

最后说个土办法。写一个Java类，用weblogic自带的`wlclient`包调用远程EJB或JMS队列，模拟真实业务操作。这个探针每两分钟跑一次，如果连续三次失败就重启对应节点。比那种只检查`/weblogic/ready`端口的HTTP探针靠谱得多——因为那个ready端口只代表管理服务活着，不代表你的业务接口能处理请求。我们生产环境曾经遇到管理服务器正常，但某个受管服务器的EJB容器挂死的情况，愣是靠这种业务探针在半夜三点逮住的。

监控weblogic这事儿，说穿了就是别把它当黑盒。连接池、JVM堆、日志耗时、负载均衡超时、业务探针，这五个点盯住了，大部分疑难杂症都能在用户察觉前暴露出来。工具不重要，重要的是你知道该看哪里。