Java运维脚本案例

Java运维脚本实战指南：从自动化部署到故障自愈的完整案例解析

目录导读

1. 为什么Java运维需要脚本化？ — 运维痛点与自动化价值
2. 基于Shell+Java的微服务健康检查脚本 — 进程监控与自动重启
3. Java日志切割与归档脚本 — 避免磁盘爆满的定时任务
4. 数据库连接池泄漏检测脚本 — 通过JMX指标触发告警
5. 灰度发布回滚自动化脚本 — 结合Ansible与Java命令行工具
6. FAQ常见问题与最佳实践 — 脚本健壮性、安全性与性能优化
7. 构建可运维的Java生态闭环

---

为什么Java运维需要脚本化？

在日常运维中，Java应用（如Spring Boot、Dubbo服务）常面临三大难题：JVM内存波动、线程池阻塞、日志文件无节制增长，纯手工jstack、jmap操作不仅低效,且无法在凌晨3点自动响应故障。

脚本化的核心价值在于：

• 快速定位：通过脚本自动抓取线程快照、堆内存快照,并输出关键异常上下文。
• 自愈能力：当端口无响应或CPU飙升时,脚本自动重启服务或触发降级开关。
• 标准化操作：避免人为误操作（如误杀进程、错误环境变量）。

---

Shell+Java组合实现健康检查与自动重启

场景：某支付服务频繁因OOM（内存溢出）导致进程挂掉，需在60秒内自动拉起,并保留现场dump文件供分析。

脚本逻辑：

1. 使用curl检查/actuator/health端点，若返回非200或超时，则执行jmap -dump导出堆快照。
2. 调用jstack生成线程快照，保存至/data/logs/dump/time_xxx.hprof。
3. 执行kill -9强制终止，再通过nohup java -jar app.jar --spring.profiles.active=prod &启动新实例。
4. 将故障时间、重启次数写入restart.log，并通过curl推送钉钉告警。

#!/bin/bash
# health_check_restart.sh
URL="http://localhost:8080/actuator/health"
PID=$(pgrep -f "app.jar")
if curl -s -m 5 $URL | grep -q "UP"; then
    echo "$(date) OK"
else
    echo "$(date) DOWN, restarting..."
    jmap -dump:format=b,file=/data/dumps/dump_$(date +%s).hprof $PID
    kill -9 $PID
    sleep 2
    cd /opt/app && nohup java -Xms512m -Xmx512m -jar app.jar > /dev/null 2>&1 &
    echo "$(date) restarted" >> /var/log/restart_status.log
fi

关键点：脚本需在crontab中每分钟执行一次，并设置JMX远程监控端口以确认JVM参数是否合理。

---

Java日志切割与自动清理脚本（防止磁盘爆满）

场景：catalina.out或spring.log单日可增长5GB，导致/data分区使用率超90%。

脚本设计：

• 使用logrotate配置按大小或时间切分，但Java应用的logback更适合通过TimeBasedRollingPolicy主动归档。
• 若仍需Shell辅助，可使用find /data/logs -name "*.log" -mtime +7 -delete清理过期日志。
• 更优雅的方式是增加一个Java定时任务，通过@Scheduled(cron = "0 0 2 * * ?")调用FileCleaner组件删除7天前的压缩文件。

示例代码（Java内部实现）：

public void cleanOldLogs() {
    Path logDir = Paths.get("/data/logs");
    try (Stream<Path> stream = Files.list(logDir)) {
        stream.filter(p -> p.toString().endsWith(".zip"))
              .filter(p -> Files.getLastModifiedTime(p).toMillis() < System.currentTimeMillis() - 7*24*3600*1000)
              .forEach(p -> p.toFile().delete());
    } catch (IOException e) { log.error("clean fail", e); }
}

最佳实践：结合ScheduledExecutorService动态调整清理频率，并在删除前先压缩（tar -czf）以保留审计痕迹。

---

通过JMX检测数据库连接池泄漏并触发告警

痛点：Druid或HikariCP连接池可能因代码未正确释放连接导致连接数耗尽，手动查看jconsole耗时且滞后。

脚本方案：

1. 在Java启动参数中加入-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9999 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false。
2. 使用jstat或curl访问jolokia代理获取PoolingDataSource的activeCount。
3. Shell脚本每分钟检查activeCount是否超过阈值（如80%最大连接数），若超限则输出线程栈到leak_threads.txt，并调用kill -3 PID触发线程dump。

# 使用jcmd获取线程栈
jcmd $PID Thread.print > /data/logs/leak_$(date +%H%M).txt

进阶技巧：通过GraalVM的native-image可将此脚本编译为轻量级可执行文件,降低对Shell环境的依赖。

---

灰度发布中的自动回滚脚本（联动Ansible）

场景：新版本上线后出现5xx错误率上升,需在3分钟内回滚至上一稳定版本。

自动化流程：

1. 编写Java运维工具RollbackController，读取deploy.version文件记录当前版本号。
2. Ansible Playbook调用该工具，传递--rollback=true参数。
3. 工具内部操作：
   • 停止旧服务（systemctl stop app）。
   • 备份当前app.jar为app_backup_时间戳.jar。
   • 从/opt/releases/目录下软链接到上一版本并启动。
   • 执行curl健康检查连续3次成功才回写版本记录。

核心Shell片段：

cd /opt/app && mv app.jar backups/app_$(date +%s).jar
ln -sf /opt/releases/app-2.1.0.jar app.jar
systemctl restart app
sleep 5
if curl -sf http://localhost:8080/health; then echo "rollback ok"; else echo "fail"; fi

安全设计：回滚操作必须记录操作者工号（通过$SUDO_USER注入），并输入二次确认码（expect脚本或read -p）。

---

FAQ：脚本运维中的常见问题与防范

Q1: 脚本执行导致JVM卡死？
解决方案：所有jmap操作必须加-F（强制模式）或-dump:live，并在非业务高峰期执行，同时设置超时timeout 30 jmap ...,防止进程无响应。

Q2: 如何避免重复重启风暴？
在脚本开头声明LOCK_FILE，使用flock命令确保同一时刻只有一个脚本实例运行。

exec 9>/var/lock/restart.lock
flock -n 9 || exit 1

Q3: 机密信息（数据库密码）硬编码在脚本中安全吗？
应改为从环境变量或Vault（如HashiCorp Vault）中注入，而非明文写入文件，可通过sed替换模板文件生成临时配置。

Q4: 如何监控脚本自身是否存活？
可将脚本状态上报至Prometheus Pushgateway，或简单地向/tmp/script_alive写时间戳,由外部探针检查。

---

构建可运维的Java生态闭环

案例覆盖了监控-发现-处置-恢复四个关键动作，但仅有脚本是不够的,建议：

• 将脚本纳入Git版本控制，并添加ShellCheck静态检查。
• 为每个Java服务建立可观测性基线（如GC日志、HTTP延迟百分位数）,脚本阈值应基于历史数据动态调整。
• 定期进行故障演练（如Chaos Engineering）,验证脚本在极端情况下的有效性。

真正优秀的Java运维脚本应当具备：幂等性、可审计性、低侵入性，最后提醒务必在测试环境完整验证后，再应用于生产环境,并始终保留人工干预的逃生通道。

---

（全文约2100字）