北京网站建设 fimpycharm网站开发实例

张

张建站

2026/4/7 4:36:29

10分钟阅读

北京网站建设 fim,pycharm网站开发实例,wordpress更改默认头像,网站运营推广策划书DeOldify服务监控与运维#xff1a;基于Python的自动化健康检查脚本你是不是也遇到过这种情况#xff1f;辛辛苦苦把DeOldify老照片上色服务部署好了#xff0c;刚开始用着挺顺手#xff0c;结果某天突然发现服务挂了#xff0c;用户反馈处理失败#xff0c;自己却完全…DeOldify服务监控与运维基于Python的自动化健康检查脚本你是不是也遇到过这种情况辛辛苦苦把DeOldify老照片上色服务部署好了刚开始用着挺顺手结果某天突然发现服务挂了用户反馈处理失败自己却完全不知道是什么时候出问题的。这种“后知后觉”的体验对于线上服务来说简直是灾难。今天咱们就来聊聊怎么给部署好的DeOldify服务装上“眼睛”和“警报器”。不用复杂的运维平台就用你熟悉的Python写一个轻量级的自动化监控脚本。它能帮你定时检查服务是否活着看看GPU是不是在“偷懒”或者“过劳”一旦发现不对劲马上给你发消息。这样一来你就能在用户投诉之前把问题扼杀在摇篮里。1. 监控脚本能帮你做什么在开始写代码之前我们先搞清楚这个脚本到底要解决哪些实际问题。一个好的监控脚本应该像一位不知疲倦的哨兵帮你盯着几个关键的地方。首先最基础也最重要的是服务存活检查。简单说就是每隔一段时间去“敲敲门”看看DeOldify的API服务是不是还能正常响应。如果门敲不开那肯定是服务挂了需要立刻处理。其次是资源使用情况监控。尤其是当你的服务跑在星图GPU平台上时GPU就是最宝贵的资源。脚本需要能查看GPU的显存用了多少利用率高不高。如果显存快满了或者GPU一直处于高负荷状态可能意味着有任务卡住了或者需要优化你的推理流程。再者是服务性能监控。这里主要关注推理延迟也就是处理一张图片需要多长时间。延迟突然变长可能是模型加载出了问题或者后台有其他任务在争抢资源。最后当上面任何一项检查出现异常时脚本需要能主动告警。通过邮件、钉钉机器人或者企业微信把“哪里出了问题”和“问题的严重程度”及时推送到你手机上让你能第一时间介入。下面这个表格能让你更直观地看到监控的核心维度监控维度检查什么为什么重要异常可能意味着什么服务存活API接口HTTP状态码服务是否可访问服务进程崩溃、网络故障、端口冲突GPU显存已用显存、总显存资源是否充足内存泄漏、大图片并发处理、未释放资源GPU利用率GPU计算负载百分比GPU是否高效工作任务队列阻塞、模型推理异常推理延迟单次图片处理耗时服务响应速度模型热加载慢、硬件性能下降、资源竞争搞清楚了目标接下来我们就动手一步步把这些功能实现出来。2. 环境准备与脚本骨架我们使用Python来编写这个监控脚本主要会用到两个库requests用于调用APIpsutil跨平台或pynvmlNVIDIA专用来获取系统及GPU信息。告警部分我们会演示邮件和钉钉机器人两种最常用的方式。首先确保你的Python环境里已经安装了必要的库。打开终端执行以下命令pip install requests psutil如果你的DeOldify服务部署在具有NVIDIA GPU的机器上比如星图GPU平台并且想获取更详细的GPU信息可以额外安装NVIDIA管理库pip install pynvml接下来我们先搭建脚本的基本骨架。创建一个名为deoldify_monitor.py的文件。#!/usr/bin/env python3 DeOldify 服务健康监控脚本功能定期检查服务API状态、GPU资源、推理延迟并发送告警。 import requests import time import json import smtplib import psutil from email.mime.text import MIMEText from email.header import Header import logging from datetime import datetime # 尝试导入pynvml用于GPU监控如果不可用则降级处理 try: import pynvml NVML_AVAILABLE True except ImportError: NVML_AVAILABLE False print(警告未找到pynvml库将无法获取详细的NVIDIA GPU信息。) # 配置日志方便查看运行记录 logging.basicConfig( levellogging.INFO, format%(asctime)s - %(levelname)s - %(message)s, handlers[ logging.FileHandler(deoldify_monitor.log), logging.StreamHandler() ] ) logger logging.getLogger(__name__) # 在这里我们定义整个脚本的核心配置 # 你可以根据自己服务的实际情况修改这些值 CONFIG { # DeOldify服务的API地址 api_url: http://localhost:7860/api/predict, # 用于健康检查的测试图片URL建议是一张很小的黑白图片 test_image_url: https://example.com/path/to/small_test_image.jpg, # 检查间隔时间秒 check_interval: 300, # 5分钟 # 服务响应超时时间秒 timeout: 30, } def main(): 主监控循环 logger.info(DeOldify服务监控脚本启动。) while True: try: check_time datetime.now().strftime(%Y-%m-%d %H:%M:%S) logger.info(f开始执行健康检查 ({check_time})) # 这里是执行所有检查的地方 # 我们会在后续步骤中实现具体的检查函数 # check_service_health() # check_gpu_health() # check_inference_latency() logger.info(本次健康检查完成。) except Exception as e: logger.error(f监控循环执行出错: {e}) # 这里可以添加紧急告警逻辑 # 等待下一个检查周期 time.sleep(CONFIG[check_interval]) if __name__ __main__: main()这个骨架脚本定义了一个无限循环每5分钟可配置触发一次检查。日志会同时输出到控制台和文件deoldify_monitor.log中方便回溯。接下来我们往这个骨架里填充血肉。3. 实现核心健康检查功能现在我们来逐一实现三个核心的检查函数。我们会遵循“快速失败详细记录”的原则任何一个检查出问题都记录下足够的信息用于排查。3.1 检查服务API是否存活这是最基本的检查。我们向DeOldify的API发送一个简单的请求根据HTTP状态码和响应内容判断服务是否正常。def check_service_health(): 检查DeOldify API服务是否存活。返回: (bool, str) 是否健康状态信息 url CONFIG[api_url] health_status False message try: # 发送一个HEAD或GET请求比POST更轻量仅用于存活检查 # 注意有些API可能需要特定的端点如 /health请根据你的部署调整 response requests.get(url.replace(/api/predict, ), timeout10) if response.status_code 200: health_status True message f服务存活正常 (HTTP {response.status_code}) else: message f服务返回异常状态码: {response.status_code} except requests.exceptions.ConnectionError: message 无法连接到服务可能未启动或网络故障。 except requests.exceptions.Timeout: message 服务连接超时。 except Exception as e: message f检查服务存活性时发生未知错误: {e} logger.info(f服务存活检查: {message}) return health_status, message3.2 检查GPU资源状态GPU是DeOldify服务的核心。我们使用pynvml库来获取显存和利用率信息。如果该库不可用则尝试用psutil获取基础的CPU和内存信息作为补充。def check_gpu_health(): 检查GPU资源使用情况主要针对NVIDIA GPU。返回: (bool, dict) 是否健康包含详细信息的字典 gpu_info {} overall_healthy True messages [] if NVML_AVAILABLE: try: pynvml.nvmlInit() device_count pynvml.nvmlDeviceGetCount() gpu_info[gpu_count] device_count for i in range(device_count): handle pynvml.nvmlDeviceGetHandleByIndex(i) gpu_name pynvml.nvmlDeviceGetName(handle).decode(utf-8) # 获取显存信息 mem_info pynvml.nvmlDeviceGetMemoryInfo(handle) mem_total mem_info.total / 1024**3 # 转换为GB mem_used mem_info.used / 1024**3 mem_used_percent (mem_used / mem_total) * 100 # 获取GPU利用率 util pynvml.nvmlDeviceGetUtilizationRates(handle) gpu_util util.gpu gpu_info[fgpu_{i}] { name: gpu_name, mem_used_gb: round(mem_used, 2), mem_total_gb: round(mem_total, 2), mem_used_percent: round(mem_used_percent, 2), gpu_util_percent: gpu_util } # 设置阈值判断你可以调整这些阈值 if mem_used_percent 90: overall_healthy False messages.append(fGPU {i} ({gpu_name}) 显存占用过高: {mem_used_percent}%) if gpu_util 95: overall_healthy False messages.append(fGPU {i} ({gpu_name}) 利用率过高: {gpu_util}%) pynvml.nvmlShutdown() except Exception as e: overall_healthy False messages.append(f获取GPU信息失败: {e}) gpu_info[error] str(e) else: # 降级方案获取CPU和内存信息 messages.append(pynvml不可用仅监控系统资源。) cpu_percent psutil.cpu_percent(interval1) mem psutil.virtual_memory() gpu_info[system] { cpu_percent: cpu_percent, mem_used_percent: mem.percent } if mem.percent 90: overall_healthy False messages.append(f系统内存占用过高: {mem.percent}%) status_message GPU资源正常。 if (overall_healthy and not messages) else ; .join(messages) logger.info(fGPU资源检查: {status_message}) return overall_healthy, gpu_info3.3 检查推理延迟除了资源我们还要关心服务“干活”的速度。通过向API发送一张小的测试图片并计时来监控推理延迟。def check_inference_latency(): 发送一个测试请求到DeOldify API测量推理延迟。返回: (bool, float, str) 是否成功延迟时间(秒) 状态信息 url CONFIG[api_url] test_image_url CONFIG[test_image_url] success False latency 0.0 message # 构建API请求数据根据你的DeOldify API格式调整 payload { data: [ test_image_url, Artistic, # 渲染因子可选 Artistic、Stable等 1.0, # 可调节参数 ] } try: start_time time.time() response requests.post(url, jsonpayload, timeoutCONFIG[timeout]) end_time time.time() latency round(end_time - start_time, 2) if response.status_code 200: resp_json response.json() # 根据实际API响应结构调整判断逻辑 if data in resp_json and len(resp_json[data]) 0: success True message f推理成功延迟: {latency}秒 else: message fAPI返回成功状态但响应数据异常: {resp_json} else: message f推理请求失败状态码: {response.status_code}, 延迟: {latency}秒 except requests.exceptions.Timeout: latency CONFIG[timeout] message f推理请求超时{CONFIG[timeout]}秒。 except Exception as e: message f推理延迟检查过程出错: {e} # 设置延迟阈值例如超过30秒认为异常 if success and latency 30: success False message f推理延迟过高: {latency}秒 logger.info(f推理延迟检查: {message}) return success, latency, message4. 集成告警通知功能检查出问题不是目的及时通知到你才是。我们实现两种最常用的告警方式邮件和钉钉群机器人。4.1 邮件告警你需要一个发件邮箱并开启SMTP服务例如QQ邮箱、163邮箱或公司邮箱。def send_email_alert(subject, body, to_addrs): 通过SMTP发送邮件告警。参数: subject: 邮件主题 body: 邮件正文 to_addrs: 收件人列表如 [adminexample.com] # 邮件服务器配置需要你自行填写 mail_host smtp.163.com # SMTP服务器 mail_user your_email163.com # 发件箱地址 mail_pass your_authorization_code # 授权码不是邮箱密码 sender mail_user receivers to_addrs message MIMEText(body, plain, utf-8) message[From] Header(fDeOldify监控机器人 {sender}) message[To] Header(,.join(receivers)) message[Subject] Header(subject, utf-8) try: smtp_obj smtplib.SMTP_SSL(mail_host, 465) # 163邮箱SSL端口 # smtp_obj smtplib.SMTP(mail_host, 25) # 非SSL端口 smtp_obj.login(mail_user, mail_pass) smtp_obj.sendmail(sender, receivers, message.as_string()) smtp_obj.quit() logger.info(邮件告警发送成功。) except Exception as e: logger.error(f邮件告警发送失败: {e})4.2 钉钉机器人告警钉钉机器人配置更简单适合团队协作。你需要在钉钉群里添加一个自定义Webhook机器人并获取它的Webhook地址。def send_dingtalk_alert(webhook_url, content, is_at_allFalse, at_mobiles[]): 通过钉钉机器人发送Markdown格式告警。参数: webhook_url: 钉钉机器人的Webhook地址 content: Markdown格式的告警内容 is_at_all: 是否所有人 at_mobiles: 需要的特定手机号列表 headers {Content-Type: application/json} data { msgtype: markdown, markdown: { title: DeOldify服务告警, text: content }, at: { atMobiles: at_mobiles, isAtAll: is_at_all } } try: response requests.post(webhook_url, headersheaders, datajson.dumps(data), timeout10) if response.status_code 200: logger.info(钉钉告警发送成功。) else: logger.error(f钉钉告警发送失败状态码: {response.status_code}, 响应: {response.text}) except Exception as e: logger.error(f钉钉告警发送过程出错: {e})5. 组装与配置让监控跑起来现在我们把所有零件组装起来并完善主函数逻辑让它能根据检查结果决定是否告警。首先在CONFIG字典里添加告警配置CONFIG { api_url: http://localhost:7860/api/predict, test_image_url: https://raw.githubusercontent.com/jantic/DeOldify/master/test_images/image.png, # 示例图片 check_interval: 300, timeout: 30, # 告警配置 alert: { enable_email: False, # 是否启用邮件告警 email_receivers: [adminyour-company.com], email_sender_config: { # 需填写真实信息 host: smtp.163.com, user: your_email163.com, pass: your_auth_code, ssl_port: 465 }, enable_dingtalk: True, # 是否启用钉钉告警 dingtalk_webhook: https://oapi.dingtalk.com/robot/send?access_tokenYOUR_TOKEN_HERE, dingtalk_at_mobiles: [13800138000] # 要的手机号 } }然后更新主函数main()def main(): 主监控循环 logger.info(DeOldify服务监控脚本启动。) # 初始化告警模块配置将配置传递给发送函数这里简化处理 # 在实际脚本中你可能需要将CONFIG设为全局变量或通过参数传递 while True: check_time datetime.now().strftime(%Y-%m-%d %H:%M:%S) logger.info(f开始执行健康检查 ({check_time})) alert_messages [] # 收集本次检查的所有告警信息 check_results {} # 收集所有检查结果用于汇总报告 # 1. 检查服务存活 service_ok, service_msg check_service_health() check_results[service] {ok: service_ok, msg: service_msg} if not service_ok: alert_messages.append(f【服务存活】异常 - {service_msg}) # 2. 检查GPU资源 gpu_ok, gpu_data check_gpu_health() check_results[gpu] {ok: gpu_ok, data: gpu_data} if not gpu_ok: # 从gpu_data或日志中提取具体信息这里简化处理 alert_messages.append(【GPU资源】异常 - 显存或利用率过高) # 3. 检查推理延迟 infer_ok, latency, infer_msg check_inference_latency() check_results[inference] {ok: infer_ok, latency: latency, msg: infer_msg} if not infer_ok: alert_messages.append(f【推理延迟】异常 - {infer_msg}) # 判断是否需要发送告警 if alert_messages: alert_title f【DeOldify服务告警】{check_time} alert_body \n.join(alert_messages) alert_body f\n\n详细检查结果:\n{json.dumps(check_results, indent2, ensure_asciiFalse)} logger.warning(f发现异常准备发送告警。内容: {alert_body}) # 发送钉钉告警 if CONFIG[alert][enable_dingtalk]: ding_content f### {alert_title}\n\n \n.join([f- {msg} for msg in alert_messages]) send_dingtalk_alert( CONFIG[alert][dingtalk_webhook], ding_content, at_mobilesCONFIG[alert][dingtalk_at_mobiles] ) # 发送邮件告警 if CONFIG[alert][enable_email]: # 注意此处需要将CONFIG中的发件配置传递给send_email_alert函数 # 为了示例清晰我们假设有一个全局配置。实际使用时请调整。 send_email_alert(alert_title, alert_body, CONFIG[alert][email_receivers]) else: logger.info(所有检查项正常。) logger.info(本次健康检查完成。\n) time.sleep(CONFIG[check_interval])6. 部署为定时任务脚本写好了总不能一直手动运行吧我们需要让它能在后台自动、定时地执行。在Linux服务器上最常用的就是crontab。首先给你的脚本添加可执行权限chmod x /path/to/your/deoldify_monitor.py然后编辑当前用户的crontab计划任务crontab -e在打开的编辑器中添加一行。例如我们希望每5分钟运行一次监控脚本并将输出日志追加到指定的文件除了脚本自己的日志文件外还可以捕获cron的执行输出# 每5分钟运行一次DeOldify监控脚本 */5 * * * * /usr/bin/python3 /path/to/your/deoldify_monitor.py /var/log/deoldify_monitor_cron.log 21这里解释一下*/5 * * * *表示每5分钟。/usr/bin/python3是你的Python3解释器路径可以用which python3命令查看。/path/to/your/deoldify_monitor.py是你的脚本的绝对路径。 /var/log/deoldify_monitor_cron.log 21将脚本的标准输出和错误输出都重定向追加到指定的日志文件。这能帮你记录cron任务是否成功触发。保存并退出编辑器。cron服务会自动加载新的配置。你可以通过以下命令检查任务是否添加成功crontab -l为了让监控更可靠你还可以考虑一些进阶操作使用系统服务如systemd对于更重要的服务可以将其配置为systemd服务实现开机自启、自动重启、更完善的日志管理。日志轮转使用logrotate工具管理deoldify_monitor.log文件避免日志文件无限增大。配置进程守护使用supervisor或pm2等进程管理工具确保监控脚本本身不会意外退出。7. 总结整套流程走下来你会发现给DeOldify服务加上一个基础的监控并没有想象中那么复杂。这个Python脚本就像一个忠诚的哨兵帮你24小时盯着服务的“心跳”、“体力”GPU资源和“反应速度”推理延迟。实际使用中你可以根据自己服务的压力情况调整检查的频率和告警的阈值。比如在业务高峰期可以把检查间隔从5分钟调到2分钟如果发现GPU显存长期在85%以上就可以考虑优化模型或升级硬件了。这个脚本只是一个起点。你可以基于它扩展更多功能比如将检查结果存入数据库如InfluxDB以便绘制历史趋势图或者集成更强大的告警平台如Prometheus Alertmanager。但无论如何从这样一个简单、可控的脚本开始你已经迈出了服务稳定运维的第一步。至少下次服务再出问题的时候你会是第一个知道的而不是从用户的抱怨里才后知后觉。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。