Spring_couplet_generation 自动化运维：利用脚本实现服务监控与日志清理

Spring_couplet_generation 自动化运维用脚本守护你的AI春联服务你有没有遇到过这种情况辛辛苦苦部署好的AI服务运行了几天突然发现系统盘快满了服务进程也悄无声息地挂掉了。特别是像Spring_couplet_generation这种持续运行的服务如果不做点自动化管理很容易就变成“一次性”的玩具。我刚开始跑这个服务的时候就吃过亏。当时只顾着调模型、看生成效果结果一周后C盘直接飘红服务也停了还得手动去清理日志、重启进程特别麻烦。后来我花了一点时间写了几段简单的脚本把监控、清理、备份这些脏活累活都交给机器去做从此就省心多了。今天我就把这些自动化运维的脚本和方法分享给你。不需要你有多深的运维背景只要会一点基本的Shell或Python就能让你的春联生成服务稳定又可靠地跑起来。1. 为什么需要自动化运维在聊具体怎么做之前我们先看看如果不做自动化可能会遇到哪些头疼的问题。1.1 常见的手动运维痛点首先最直观的就是日志文件膨胀。服务运行起来日志文件会一天天变大。特别是调试阶段日志级别开得高几天下来几个G的日志文件很常见。它们通常就躺在你的系统盘比如C盘不知不觉就把空间占满了。其次是服务进程意外退出。可能是内存泄漏、外部依赖变化或者就是单纯的偶发bug导致服务进程挂掉。如果你没及时发现服务就中断了用户访问不了数据也可能丢失。再者数据和模型权重缺乏备份。你训练好的模型权重、用户生成的对联数据都是宝贵的资产。万一服务器硬盘出问题或者误操作删除了损失就大了。最后一切靠人工意味着你需要时刻盯着。查看进程状态、手动清理日志、定期备份数据这些重复性工作既枯燥又容易出错还占用你宝贵的开发时间。1.2 自动化运维带来的改变引入简单的脚本自动化之后情况就完全不同了解放双手定时任务自动执行清理、备份你再也不用惦记着“今天该清日志了”。7x24小时守护脚本可以每分钟检查一次服务状态挂了立刻拉起来保障服务高可用。防患于未然定期清理和备份从根本上避免了磁盘爆满和数据丢失的风险。可追溯自动化的操作本身也会产生日志方便你回顾和排查问题。接下来我们就从最迫切的磁盘空间问题开始看看如何用脚本自动清理日志。2. 实战编写日志自动清理脚本日志清理是维护系统盘空间健康的最直接手段。我们的目标是定期自动清理过期的、无用的日志文件同时保留最近一段时间的关键日志供排查问题。2.1 Shell脚本方案适用于Linux/macOS或WSLShell脚本轻量、直接特别适合做文件操作。下面是一个功能比较全面的清理脚本cleanup_logs.sh#!/bin/bash # 定义日志目录请根据你的实际路径修改 LOG_DIR/path/to/your/spring_couplet/logs # 定义保留最近多少天的日志 DAYS_TO_KEEP7 # 定义单个日志文件超过多大就清理例如100M MAX_LOG_SIZE100M echo $(date %Y-%m-%d %H:%M:%S) 开始执行日志清理任务... # 1. 清理超过指定天数的日志文件 echo 正在清理 $DAYS_TO_KEEP 天前的日志文件... find $LOG_DIR -name *.log -type f -mtime $DAYS_TO_KEEP -delete if [ $? -eq 0 ]; then echo 过期日志清理完成。 else echo 清理过期日志时发生错误。 fi # 2. 清理超过指定大小的日志文件 (可选按需开启) # echo 正在清理大小超过 $MAX_LOG_SIZE 的日志文件... # find $LOG_DIR -name *.log -type f -size $MAX_LOG_SIZE -delete # if [ $? -eq 0 ]; then # echo 大文件日志清理完成。 # else # echo 清理大日志文件时发生错误。 # fi # 3. 可选清理空日志文件 # find $LOG_DIR -name *.log -type f -empty -delete # 4. 记录本次清理操作到自己的日志 CLEANUP_LOG/var/log/spring_couplet_cleanup.log echo $(date %Y-%m-%d %H:%M:%S) - 清理任务执行完毕。日志目录: $LOG_DIR $CLEANUP_LOG echo $(date %Y-%m-%d %H:%M:%S) 日志清理任务结束。脚本说明和使用方法修改路径将LOG_DIR变量值替换成你服务日志的真实存放路径。设置策略DAYS_TO_KEEP7表示保留最近7天的日志更早的自动删除。你可以按需调整。赋予执行权限在终端执行chmod x cleanup_logs.sh。手动测试先执行./cleanup_logs.sh看看效果确认无误后再加入定时任务。加入定时任务使用crontab -e命令编辑定时任务。例如添加下面一行表示每天凌晨3点执行清理0 3 * * * /bin/bash /path/to/your/cleanup_logs.sh2.2 Python脚本方案跨平台通用如果你对Python更熟悉或者你的部署环境是WindowsPython脚本是个好选择。它更灵活能处理更复杂的逻辑。#!/usr/bin/env python3 # -*- coding: utf-8 -*- import os import time import logging from datetime import datetime, timedelta import argparse def setup_logging(): 设置脚本自身的日志 logging.basicConfig( levellogging.INFO, format%(asctime)s - %(levelname)s - %(message)s, handlers[ logging.FileHandler(/var/log/spring_couplet_cleanup.log), # 脚本运行日志路径 logging.StreamHandler() # 同时在控制台输出 ] ) return logging.getLogger(__name__) def cleanup_logs(log_dir, days_to_keep, max_size_mbNone): 清理日志文件 :param log_dir: 日志目录路径 :param days_to_keep: 保留最近多少天的日志 :param max_size_mb: 超过此大小MB的日志文件也被清理可选 logger setup_logging() logger.info(f开始清理日志目录: {log_dir}) if not os.path.isdir(log_dir): logger.error(f日志目录不存在: {log_dir}) return cutoff_time time.time() - (days_to_keep * 24 * 60 * 60) deleted_count 0 size_freed 0 for root, dirs, files in os.walk(log_dir): for file in files: if file.endswith(.log): file_path os.path.join(root, file) try: file_mtime os.path.getmtime(file_path) file_size os.path.getsize(file_path) to_delete False reason # 规则1检查文件修改时间 if file_mtime cutoff_time: to_delete True reason f过期超过{days_to_keep}天 # 规则2检查文件大小如果设置了 elif max_size_mb and file_size max_size_mb * 1024 * 1024: to_delete True reason f过大超过{max_size_mb}MB if to_delete: os.remove(file_path) deleted_count 1 size_freed file_size logger.info(f已删除: {file_path} - 原因: {reason}) except Exception as e: logger.error(f处理文件 {file_path} 时出错: {e}) logger.info(f清理完成。共删除 {deleted_count} 个文件释放空间约 {size_freed / (1024*1024):.2f} MB.) if __name__ __main__: parser argparse.ArgumentParser(descriptionSpring Couplet 服务日志清理工具) parser.add_argument(--log-dir, requiredTrue, help日志文件所在目录) parser.add_argument(--days, typeint, default7, help保留最近多少天的日志默认7天) parser.add_argument(--max-size-mb, typeint, help清理超过此大小MB的日志文件) args parser.parse_args() # 示例 python cleanup_logs.py --log-dir /app/logs --days 7 --max-size-mb 100 cleanup_logs(args.log_dir, args.days, args.max_size_mb)Python脚本的优势参数化可以通过命令行参数灵活指定目录、保留天数等不用改代码。日志记录完善脚本自己的操作会详细记录到日志文件方便审计。错误处理更好对文件操作有更细致的异常捕获。跨平台在Windows上也可以直接运行用系统的“任务计划程序”来定时触发。在Windows上你可以创建一个.bat批处理文件来调用这个Python脚本然后将其加入任务计划程序。解决了磁盘空间这个“慢性病”我们再来处理服务突然挂掉的“急症”。3. 实战服务进程监控与自动重启服务挂了能自动重启是保障可用性的核心。思路很简单写一个脚本定期检查进程是否存在如果不存在就启动它。3.1 使用Shell脚本监控这里提供一个基础的监控重启脚本monitor_service.sh#!/bin/bash # 服务进程名根据你的启动命令修改如 python, java, spring_couplet 等 SERVICE_NAMEpython # 示例如果你的服务是 python app.py这里填 python 或 app.py 的一部分 # 服务的启动命令 START_COMMANDcd /path/to/your/project python app.py # 检查间隔秒 CHECK_INTERVAL60 while true do # 检查进程是否存在 if pgrep -f $SERVICE_NAME /dev/null then echo $(date %Y-%m-%d %H:%M:%S) 服务进程 [$SERVICE_NAME] 运行正常。 else echo $(date %Y-%m-%d %H:%M:%S) 服务进程 [$SERVICE_NAME] 不存在尝试重启... # 执行启动命令并将输出重定向到日志文件 eval $START_COMMAND /var/log/spring_couplet_service.log 21 echo $(date %Y-%m-%d %H:%M:%S) 重启命令已发出。 fi # 等待一段时间后再次检查 sleep $CHECK_INTERVAL done使用方法修改SERVICE_NAME和START_COMMAND为你的实际值。pgrep -f会匹配命令行中包含指定字符串的进程所以要选一个唯一性高的关键词。这个脚本本身需要一直在后台运行。你可以用nohup命令启动它nohup ./monitor_service.sh 。更规范的做法是将这个监控脚本配置为一个系统服务如 systemd 服务让系统来管理它的启动和停止。3.2 更健壮的Python监控脚本用Python写监控逻辑可以更清晰也更容易添加更多功能比如发送告警通知。#!/usr/bin/env python3 import subprocess import time import logging import sys import psutil # 需要安装: pip install psutil def check_process(process_name): 检查指定进程是否在运行 for proc in psutil.process_iter([pid, name, cmdline]): try: # 检查进程命令行中是否包含关键词 if process_name.lower() in .join(proc.info[cmdline] or []).lower(): return proc.info[pid] except (psutil.NoSuchProcess, psutil.AccessDenied): pass return None def start_service(start_command): 启动服务 try: # 使用 subprocess.Popen 在后台启动 process subprocess.Popen( start_command, shellTrue, stdoutopen(/var/log/spring_couplet_service.log, a), stderrsubprocess.STDOUT ) logging.info(f服务启动成功PID: {process.pid}) return process.pid except Exception as e: logging.error(f启动服务失败: {e}) return None def main(): logging.basicConfig( levellogging.INFO, format%(asctime)s - %(levelname)s - %(message)s, handlers[ logging.FileHandler(/var/log/spring_couplet_monitor.log), logging.StreamHandler() ] ) process_keyword app.py # 用于识别进程的关键词 start_cmd cd /path/to/your/project /usr/bin/python3 app.py --port 8080 check_interval 60 # 检查间隔秒 logging.info(f开始监控服务关键词: {process_keyword}) while True: pid check_process(process_keyword) if pid is None: logging.warning(f未找到进程 [{process_keyword}]正在尝试重启...) new_pid start_service(start_cmd) if new_pid: logging.info(f服务重启成功新PID: {new_pid}) else: logging.error(服务重启失败) else: logging.debug(f服务进程运行正常PID: {pid}) # 正常时可以用DEBUG级别减少日志量 time.sleep(check_interval) if __name__ __main__: main()这个Python脚本使用了psutil库来更精确地查找进程并提供了更好的日志记录。你可以通过pip install psutil来安装这个库。有了监控和清理数据安全也不能忽视。定期备份是最后的防线。4. 实战关键数据与模型备份对于Spring_couplet_generation服务需要备份的主要是两部分用户生成的数据对联、配置等和模型权重文件。4.1 简单的增量备份脚本我们可以写一个脚本定期将重要数据打包压缩并拷贝到另一个安全的位置比如另一块硬盘、网络存储等。#!/bin/bash # 备份源目录 DATA_DIR/path/to/spring_couplet/data MODEL_DIR/path/to/spring_couplet/models # 备份目标目录 BACKUP_ROOT/backup/spring_couplet # 保留多少份备份 MAX_BACKUPS5 TIMESTAMP$(date %Y%m%d_%H%M%S) BACKUP_DIR$BACKUP_ROOT/backup_$TIMESTAMP echo $(date) 开始备份... # 1. 创建本次备份的目录 mkdir -p $BACKUP_DIR # 2. 备份数据目录使用rsync增量备份节省空间和时间 rsync -av --delete $DATA_DIR/ $BACKUP_DIR/data/ # 3. 备份模型目录模型文件大也可以考虑只备份最新的权重 # 这里简单备份整个目录生产环境可能需要更精细的策略 rsync -av --delete $MODEL_DIR/ $BACKUP_DIR/models/ # 4. 可选将备份目录打包压缩 # cd $BACKUP_ROOT tar -czf backup_$TIMESTAMP.tar.gz backup_$TIMESTAMP rm -rf backup_$TIMESTAMP # 5. 清理旧的备份只保留最新的MAX_BACKUPS份 cd $BACKUP_ROOT ls -td backup_* | tail -n $(($MAX_BACKUPS 1)) | xargs -r rm -rf echo $(date) 备份完成。备份位于: $BACKUP_DIR脚本要点rsync使用rsync命令进行备份它支持增量同步只传输变化的文件效率高。版本管理通过时间戳创建带版本的备份目录。清理旧备份避免备份目录无限增长只保留最新的几份。同样将这个脚本例如backup.sh加入crontab就可以实现定时自动备份了。5. 总结好了几个核心的自动化运维脚本就介绍到这里。从日志清理、进程监控到数据备份一套组合拳打下来你的Spring_couplet_generation服务就有了基本的“自愈”和“自理”能力。回头看看我们做的事情其实并不复杂就是用脚本把那些重复、容易忘的手动操作固化下来。但就是这么几个简单的脚本能极大地提升服务的稳定性和你的运维体验。你再也不用每天提心吊胆地查磁盘空间也不用半夜被服务中断的报警吵醒当然监控告警是更进阶的话题。我建议你从最影响你的问题开始入手。如果总是磁盘满就先部署日志清理脚本。如果服务老挂就优先搞定监控重启。一步步来慢慢把这些脚本都加上你的服务就会越来越健壮。最后别忘了定期检查一下这些自动化脚本自己的日志确保它们都在正常工作。自动化不是为了“一劳永逸”而是为了把人力从重复劳动中解放出来去处理更值得思考的问题。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。