gte-base-zh运维入门：日志轮转与服务状态监控基础教程

gte-base-zh运维入门日志轮转与服务状态监控基础教程1. 引言从“能用”到“好用”的运维第一步如果你刚刚在服务器上部署了gte-base-zh这个文本嵌入模型看着Web界面成功运行输入文本就能得到向量结果心里一定挺有成就感。但很快你可能就会遇到一些“小麻烦”服务运行了几天突然发现磁盘空间快满了一查是日志文件占了十几个G想看看服务最近有没有报错打开几十兆的日志文件浏览器直接卡死半夜收到报警说服务挂了登录服务器却不知道从哪里查起想重启服务更新配置又怕影响正在使用的业务这些问题其实都是运维的基础工作没做到位。运维听起来高大上但它的核心目标很简单让服务稳定、可靠、可维护。今天这篇文章我就带你从零开始掌握gte-base-zh服务运维的两个最基础、最实用的技能日志轮转和服务状态监控。别担心我们不用学什么复杂理论就从你手头已经跑起来的服务开始一步步把它变得“专业”起来。2. 理解你的gte-base-zh服务它到底是怎么运行的在动手优化之前我们先花几分钟搞清楚你的gte-base-zh服务是怎么工作的。这就像修车之前得先知道车的结构一样。2.1 服务架构快速了解你的gte-base-zh服务其实由三个主要部分组成模型文件放在/usr/local/bin/AI-ModelScope/gte-base-zh这个目录里这是模型的核心包括权重文件和配置文件第一次启动时会加载到内存这个过程可能需要几分钟加载完成后就一直待在内存里等着处理请求Xinference服务用xinference-local --host 0.0.0.0 --port 9997启动这是对外提供服务的“大门”所有请求都通过它进来它再把请求交给模型处理它还负责管理模型的加载和卸载启动脚本/usr/local/bin/launch_model_server.py这是一个Python脚本负责把模型“告诉”Xinference你可以在这里调整一些启动参数2.2 怎么知道服务是不是正常服务启动后你怎么确认它真的在正常工作呢这里有几个简单的方法# 方法1看启动日志这是最直接的方法 cat /root/workspace/model_server.log # 如果看到类似这样的输出说明服务启动成功了 # INFO: Model loaded successfully # INFO: Server started on port 9997 # 方法2检查进程是不是在运行 ps aux | grep xinference # 应该能看到一个xinference-local的进程 ps aux | grep launch_model_server # 应该能看到一个Python进程在运行这个脚本 # 方法3直接调用API试试 curl http://localhost:9997/v1/models # 如果返回类似 [{model_name: gte-base-zh, ...}] 的JSON说明API正常记住这几个命令后面我们会经常用到它们。3. 日志管理别让日志把你的磁盘撑爆了日志就像服务的“日记”记录了它每天干了什么、遇到了什么问题。但如果不加管理这个日记本会越来越厚最后把整个书架磁盘都占满。3.1 默认日志的问题现在你的日志都写在一个文件里/root/workspace/model_server.log。时间一长问题就来了磁盘空间告急一个文件可能长到几十GB把磁盘塞满查看困难用cat或vim打开大文件电脑可能直接卡住找不到重点重要的错误信息被埋在海量正常日志里无法按时间查找想找昨天下午的日志只能从头翻到尾3.2 最简单的解决方案手动清理在学自动化方法之前我们先看看怎么手动处理。有时候临时解决问题手动操作反而更快。# 查看日志文件大小 du -sh /root/workspace/model_server.log # 输出类似4.2G /root/workspace/model_server.log # 如果文件太大可以先备份再清空 # 1. 备份当前日志以防万一需要查历史 cp /root/workspace/model_server.log /root/workspace/model_server.log.backup.$(date %Y%m%d) # 2. 清空日志文件注意这会删除所有内容 /root/workspace/model_server.log # 或者用这个命令echo /root/workspace/model_server.log # 3. 重启服务让服务重新开始写日志 # 先找到进程ID ps aux | grep xinference | grep -v grep # 假设看到进程ID是 12345 kill 12345 # 重新启动服务 xinference-local --host 0.0.0.0 --port 9997 手动清理虽然简单但有两个大问题一是你得记住定期去清理二是清理时服务得重启一下。下面我们看看更好的方法。3.3 自动化日志轮转用logrotate省心省力Linux系统自带了一个叫logrotate的工具它能自动帮你管理日志文件。我们来配置一下。首先创建配置文件# 用vim创建配置文件如果不会用vim可以用nano sudo vim /etc/logrotate.d/gte-base-zh把下面的内容复制进去/root/workspace/model_server.log { daily # 每天检查一次 rotate 30 # 保留30个旧日志文件 compress # 压缩旧的日志节省空间 delaycompress # 延迟一天再压缩方便查看最新日志 missingok # 如果日志文件不存在也不报错 notifempty # 如果日志文件是空的就不轮转 create 644 root root # 创建新日志文件时设置权限和所有者 size 100M # 当日志超过100MB时也进行轮转 }我来解释一下这些配置的意思daily每天检查一次日志文件rotate 30保留30个旧日志文件超过30个就删除最老的compress把旧的日志压缩成.gz格式能节省70%左右的空间size 100M这是我自己加的意思是即使没到一天只要日志超过100MB也进行轮转配置好了怎么知道它能不能正常工作呢我们来测试一下# 先模拟测试dry-run模式只显示会做什么不实际执行 sudo logrotate -d /etc/logrotate.d/gte-base-zh # 如果测试没问题手动执行一次轮转 sudo logrotate -f /etc/logrotate.d/gte-base-zh # 看看效果 ls -lh /root/workspace/model_server.log* # 你应该能看到类似这样的文件 # -rw-r--r-- 1 root root 10M Mar 20 10:00 model_server.log # 新的空日志 # -rw-r--r-- 1 root root 100M Mar 20 09:59 model_server.log.1 # 昨天的日志 # -rw-r--r-- 1 root root 45M Mar 19 09:59 model_server.log.2.gz # 前天的日志已压缩配置完成后logrotate会每天自动运行通过系统的cron任务。你什么都不用做它就会自动帮你把当前的model_server.log改名为model_server.log.1创建一个新的model_server.log空的把太旧的日志文件删除只保留最近30个把.1、.2这样的日志压缩成.gz格式3.4 更灵活的日志配置按大小轮转有时候按天轮转不太够用。比如你的服务特别忙一天就能产生几十GB的日志。这时候可以改成按文件大小轮转/root/workspace/model_server.log { rotate 50 # 保留50个旧文件 compress delaycompress missingok notifempty create 644 root root size 1G # 关键在这里超过1GB就轮转 maxsize 2G # 即使没到轮转时间超过2GB也立即轮转 }这个配置的意思是只要日志文件超过1GB就立即轮转。如果日志增长特别快即使没到1GB但一天内涨到2GB了也会立即轮转。4. 服务状态监控别等用户告诉你服务挂了日志管理是“事后处理”而监控是“事前预防”。好的监控能让你在用户发现问题之前就知道服务有异常。4.1 基础监控写个简单的检查脚本我们先从最简单的开始写一个脚本定期检查服务是不是还活着。创建一个文件叫check_service.sh#!/bin/bash # 保存为 /root/workspace/check_service.sh # 配置部分 SERVICE_URLhttp://localhost:9997/v1/models LOG_FILE/root/workspace/service_check.log ERROR_THRESHOLD3 # 连续错误多少次才报警 current_errors0 # 检查服务状态 check_service() { # 尝试访问服务设置10秒超时 response_code$(curl -s -o /dev/null -w %{http_code} -m 10 $SERVICE_URL) curl_exit_code$? current_time$(date %Y-%m-%d %H:%M:%S) if [ $curl_exit_code -eq 0 ] [ $response_code -eq 200 ]; then # 服务正常 echo [$current_time] ✅ 服务正常 $LOG_FILE current_errors0 # 重置错误计数 return 0 else # 服务异常 echo [$current_time] ❌ 服务异常 - HTTP状态码: $response_code, curl退出码: $curl_exit_code $LOG_FILE ((current_errors)) # 如果连续出错达到阈值尝试重启 if [ $current_errors -ge $ERROR_THRESHOLD ]; then echo [$current_time] ⚠️ 连续$ERROR_THRESHOLD次检查失败尝试重启服务... $LOG_FILE restart_service current_errors0 # 重启后重置计数 fi return 1 fi } # 重启服务 restart_service() { echo [$(date %Y-%m-%d %H:%M:%S)] 正在重启服务... $LOG_FILE # 1. 先尝试正常停止 pkill -f xinference-local || true sleep 2 # 2. 如果还有进程强制停止 pkill -9 -f xinference-local 2/dev/null || true # 3. 重新启动 cd /root/workspace nohup xinference-local --host 0.0.0.0 --port 9997 /root/workspace/service.log 21 echo [$(date %Y-%m-%d %H:%M:%S)] 服务重启完成 $LOG_FILE } # 主循环 echo 开始监控 gte-base-zh 服务 $LOG_FILE while true; do check_service sleep 60 # 每60秒检查一次 done给脚本执行权限并运行# 给脚本执行权限 chmod x /root/workspace/check_service.sh # 在后台运行脚本 nohup /root/workspace/check_service.sh # 查看监控日志 tail -f /root/workspace/service_check.log这个脚本会每分钟检查一次服务状态。如果连续3次检查都失败它会自动尝试重启服务。你可以在service_check.log里看到所有的检查记录。4.2 进阶监控监控更多指标基础的状态检查只能告诉你服务“死没死”但我们还想知道服务“健不健康”。比如服务响应慢不慢内存占用高不高有没有处理错误的请求我们来写一个更全面的监控脚本#!/usr/bin/env python3 # 保存为 /root/workspace/advanced_monitor.py import requests import time import psutil import json from datetime import datetime import logging # 配置日志 logging.basicConfig( levellogging.INFO, format%(asctime)s - %(levelname)s - %(message)s, handlers[ logging.FileHandler(/root/workspace/advanced_monitor.log), logging.StreamHandler() # 同时输出到控制台 ] ) class ServiceMonitor: def __init__(self): self.service_url http://localhost:9997/v1/models self.stats_file /root/workspace/service_stats.json def check_service_health(self): 检查服务健康状态 try: start_time time.time() response requests.get(self.service_url, timeout5) response_time (time.time() - start_time) * 1000 # 转成毫秒 if response.status_code 200: return { status: healthy, response_time_ms: round(response_time, 2), timestamp: datetime.now().isoformat() } else: return { status: unhealthy, error: fHTTP {response.status_code}, response_time_ms: round(response_time, 2), timestamp: datetime.now().isoformat() } except requests.exceptions.Timeout: return { status: unhealthy, error: timeout, response_time_ms: 5000, # 超时设为5秒 timestamp: datetime.now().isoformat() } except Exception as e: return { status: unhealthy, error: str(e), timestamp: datetime.now().isoformat() } def check_system_resources(self): 检查系统资源使用情况 try: # 找到xinference进程 for proc in psutil.process_iter([pid, name, cmdline]): try: if proc.info[cmdline] and xinference in .join(proc.info[cmdline]): process psutil.Process(proc.info[pid]) memory_mb process.memory_info().rss / 1024 / 1024 cpu_percent process.cpu_percent(interval0.5) return { memory_usage_mb: round(memory_mb, 2), cpu_percent: round(cpu_percent, 2), timestamp: datetime.now().isoformat() } except (psutil.NoSuchProcess, psutil.AccessDenied): continue return {error: process not found, timestamp: datetime.now().isoformat()} except Exception as e: return {error: str(e), timestamp: datetime.now().isoformat()} def save_stats(self, health_stats, resource_stats): 保存统计数据 stats { health: health_stats, resources: resource_stats, check_time: datetime.now().isoformat() } # 读取历史数据 try: with open(self.stats_file, r) as f: history json.load(f) except (FileNotFoundError, json.JSONDecodeError): history [] # 只保留最近100条记录 history.append(stats) if len(history) 100: history history[-100:] # 保存数据 with open(self.stats_file, w) as f: json.dump(history, f, indent2) return stats def check_and_alert(self, stats): 检查是否需要告警 alerts [] # 检查服务状态 if stats[health][status] ! healthy: alerts.append(f服务异常: {stats[health].get(error, unknown)}) # 检查响应时间超过1秒就警告 if stats[health].get(response_time_ms, 0) 1000: alerts.append(f响应时间过长: {stats[health][response_time_ms]}ms) # 检查内存使用超过2GB就警告 if stats[resources].get(memory_usage_mb, 0) 2000: alerts.append(f内存使用过高: {stats[resources][memory_usage_mb]}MB) # 检查CPU使用超过80%就警告 if stats[resources].get(cpu_percent, 0) 80: alerts.append(fCPU使用率过高: {stats[resources][cpu_percent]}%) # 如果有告警记录到日志 if alerts: alert_msg | .join(alerts) logging.warning(f⚠️ 告警: {alert_msg}) # 这里可以添加发送邮件、短信等告警逻辑 # 比如send_alert_email(alert_msg) return alerts def run(self): 运行监控 logging.info(开始监控 gte-base-zh 服务) while True: try: # 检查服务健康状态 health_stats self.check_service_health() # 检查系统资源 resource_stats self.check_system_resources() # 保存统计数据 stats self.save_stats(health_stats, resource_stats) # 检查是否需要告警 alerts self.check_and_alert(stats) # 记录正常状态 if not alerts: logging.info( f状态正常 | f响应时间: {health_stats.get(response_time_ms, N/A)}ms | f内存: {resource_stats.get(memory_usage_mb, N/A)}MB | fCPU: {resource_stats.get(cpu_percent, N/A)}% ) # 如果服务异常尝试重启 if health_stats[status] ! healthy: error_count getattr(self, error_count, 0) 1 self.error_count error_count if error_count 3: # 连续3次异常 logging.error(服务连续3次检查异常尝试重启...) self.restart_service() self.error_count 0 else: self.error_count 0 except Exception as e: logging.error(f监控检查出错: {e}) # 每30秒检查一次 time.sleep(30) def restart_service(self): 重启服务 logging.info(正在重启服务...) # 这里可以调用之前写的重启逻辑 # 为了简单我们先用系统命令 import subprocess subprocess.run([pkill, -f, xinference-local], capture_outputTrue) time.sleep(2) subprocess.run([nohup, xinference-local, --host, 0.0.0.0, --port, 9997, ], shellTrue, capture_outputTrue) logging.info(服务重启完成) if __name__ __main__: monitor ServiceMonitor() monitor.run()运行这个监控脚本# 给执行权限 chmod x /root/workspace/advanced_monitor.py # 在后台运行 nohup python3 /root/workspace/advanced_monitor.py # 查看监控日志 tail -f /root/workspace/advanced_monitor.log # 查看统计数据 cat /root/workspace/service_stats.json | python3 -m json.tool这个监控脚本会每30秒检查一次服务状态记录响应时间、内存使用、CPU使用如果发现异常响应慢、内存高、服务挂掉会记录告警连续3次检查失败会自动重启服务所有数据都保存到JSON文件方便查看历史趋势4.3 可视化监控用简单的方式看图表如果你想知道服务的历史表现比如“昨天下午是不是比平时慢”可以写个简单的HTML页面来展示数据!-- 保存为 /root/workspace/monitor_dashboard.html -- !DOCTYPE html html head titlegte-base-zh 服务监控/title script srchttps://cdn.jsdelivr.net/npm/chart.js/script style body { font-family: Arial, sans-serif; margin: 20px; } .chart-container { width: 800px; height: 400px; margin: 20px 0; } .status { padding: 10px; margin: 10px 0; border-radius: 5px; } .healthy { background-color: #d4edda; color: #155724; } .unhealthy { background-color: #f8d7da; color: #721c24; } /style /head body h1gte-base-zh 服务监控面板/h1 div idcurrent-status classstatus 加载中... /div div h2响应时间趋势最近100次检查/h2 div classchart-container canvas idresponseTimeChart/canvas /div /div div h2内存使用趋势/h2 div classchart-container canvas idmemoryChart/canvas /div /div div h2最近检查记录/h2 table idrecent-checks border1 cellpadding10 thead tr th时间/th th状态/th th响应时间/th th内存使用/th thCPU使用/th /tr /thead tbody !-- 数据会通过JavaScript填充 -- /tbody /table /div script // 从JSON文件加载数据 async function loadStats() { try { const response await fetch(/root/workspace/service_stats.json); const data await response.json(); updateDashboard(data); } catch (error) { console.error(加载数据失败:, error); } } function updateDashboard(stats) { if (!stats || stats.length 0) { document.getElementById(current-status).innerHTML div classunhealthy暂无监控数据/div; return; } // 最新状态 const latest stats[stats.length - 1]; const statusDiv document.getElementById(current-status); if (latest.health.status healthy) { statusDiv.innerHTML div classhealthy ✅ 服务正常 | 响应时间: ${latest.health.response_time_ms || N/A}ms | 最后检查: ${new Date(latest.check_time).toLocaleString()} /div ; } else { statusDiv.innerHTML div classunhealthy ❌ 服务异常: ${latest.health.error || 未知错误} | 最后检查: ${new Date(latest.check_time).toLocaleString()} /div ; } // 准备图表数据 const labels stats.map(s new Date(s.check_time).toLocaleTimeString() ); const responseTimes stats.map(s s.health.response_time_ms || 0 ); const memoryUsage stats.map(s s.resources.memory_usage_mb || 0 ); // 更新响应时间图表 const responseTimeCtx document.getElementById(responseTimeChart).getContext(2d); new Chart(responseTimeCtx, { type: line, data: { labels: labels, datasets: [{ label: 响应时间 (ms), data: responseTimes, borderColor: rgb(75, 192, 192), tension: 0.1 }] }, options: { responsive: true, scales: { y: { beginAtZero: true } } } }); // 更新内存使用图表 const memoryCtx document.getElementById(memoryChart).getContext(2d); new Chart(memoryCtx, { type: line, data: { labels: labels, datasets: [{ label: 内存使用 (MB), data: memoryUsage, borderColor: rgb(255, 99, 132), tension: 0.1 }] }, options: { responsive: true, scales: { y: { beginAtZero: true } } } }); // 更新最近检查表格显示最近10条 const tableBody document.querySelector(#recent-checks tbody); tableBody.innerHTML ; const recentStats stats.slice(-10).reverse(); // 最新的在前面 recentStats.forEach(stat { const row document.createElement(tr); const timeCell document.createElement(td); timeCell.textContent new Date(stat.check_time).toLocaleString(); const statusCell document.createElement(td); statusCell.textContent stat.health.status; statusCell.style.color stat.health.status healthy ? green : red; const responseCell document.createElement(td); responseCell.textContent stat.health.response_time_ms ? ${stat.health.response_time_ms}ms : N/A; const memoryCell document.createElement(td); memoryCell.textContent stat.resources.memory_usage_mb ? ${stat.resources.memory_usage_mb}MB : N/A; const cpuCell document.createElement(td); cpuCell.textContent stat.resources.cpu_percent ? ${stat.resources.cpu_percent}% : N/A; row.appendChild(timeCell); row.appendChild(statusCell); row.appendChild(responseCell); row.appendChild(memoryCell); row.appendChild(cpuCell); tableBody.appendChild(row); }); } // 页面加载时获取数据 document.addEventListener(DOMContentLoaded, loadStats); // 每30秒自动刷新 setInterval(loadStats, 30000); /script /body /html要查看这个监控面板你需要一个简单的HTTP服务器# 安装Python的简单HTTP服务器如果还没安装的话 # 其实Python自带不用安装 # 在后台启动HTTP服务器端口8080 cd /root/workspace nohup python3 -m http.server 8080 # 然后在浏览器访问 # http://你的服务器IP:8080/monitor_dashboard.html这个监控面板会显示当前服务状态正常/异常响应时间的变化趋势图内存使用的变化趋势图最近10次检查的详细记录5. 把监控做成定时任务让系统自动运行我们写了这么多脚本总不能每次都手动启动吧让系统自动运行它们才是正解。5.1 使用crontab定时任务Linux有个叫crontab的工具可以定时运行命令。我们来设置一下# 编辑当前用户的crontab crontab -e在打开的文件里添加以下内容# 每分钟检查一次服务状态使用简单脚本 * * * * * /root/workspace/check_service.sh /root/workspace/cron.log 21 # 每5分钟检查一次日志文件大小如果超过1GB就轮转 */5 * * * * /usr/sbin/logrotate -f /etc/logrotate.d/gte-base-zh # 每天凌晨2点清理30天前的日志备份 0 2 * * * find /root/workspace -name model_server.log.*.gz -mtime 30 -delete # 每天凌晨3点重启监控脚本防止监控脚本自己挂掉 0 3 * * * pkill -f advanced_monitor.py cd /root/workspace nohup python3 advanced_monitor.py 我来解释一下这些配置第一行每分钟运行一次check_service.sh把输出记录到cron.log第二行每5分钟强制运行一次日志轮转即使没到预定时间如果日志超过大小限制也会轮转第三行每天凌晨2点删除30天前的压缩日志文件第四行每天凌晨3点重启Python监控脚本防止它因为内存泄漏等问题挂掉保存退出后cron就会自动运行这些任务了。你可以用下面的命令查看cron的运行日志# 查看cron日志不同系统可能位置不同 tail -f /var/log/cron # 或者 tail -f /var/log/syslog | grep CRON5.2 创建服务管理脚本我们还可以创建一个统一的脚本来管理所有运维任务#!/bin/bash # 保存为 /root/workspace/manage_service.sh case $1 in start) echo 启动 gte-base-zh 服务... nohup xinference-local --host 0.0.0.0 --port 9997 /root/workspace/service.log 21 echo 服务已启动 ;; stop) echo 停止 gte-base-zh 服务... pkill -f xinference-local || true sleep 2 echo 服务已停止 ;; restart) echo 重启 gte-base-zh 服务... $0 stop sleep 3 $0 start ;; status) echo 检查服务状态... if pgrep -f xinference-local /dev/null; then echo ✅ 服务正在运行 # 检查API是否可用 response$(curl -s -o /dev/null -w %{http_code} http://localhost:9997/v1/models) if [ $response -eq 200 ]; then echo ✅ API接口正常 else echo ❌ API接口异常 (HTTP $response) fi # 检查内存使用 pid$(pgrep -f xinference-local) if [ -n $pid ]; then memory_kb$(ps -p $pid -o rss) memory_mb$((memory_kb / 1024)) echo 内存使用: ${memory_mb}MB fi else echo ❌ 服务未运行 fi ;; logs) echo 查看服务日志... tail -f /root/workspace/model_server.log ;; monitor) echo 启动监控... nohup python3 /root/workspace/advanced_monitor.py /dev/null 21 echo 监控已启动 ;; cleanup) echo 清理旧日志... # 保留最近7天的日志文件 find /root/workspace -name model_server.log.* -mtime 7 -delete find /root/workspace -name service_check.log.* -mtime 7 -delete echo 清理完成 ;; *) echo 使用方法: $0 {start|stop|restart|status|logs|monitor|cleanup} echo echo 命令说明: echo start 启动服务 echo stop 停止服务 echo restart 重启服务 echo status 查看服务状态 echo logs 查看实时日志 echo monitor 启动监控脚本 echo cleanup 清理旧日志 exit 1 ;; esac给脚本执行权限chmod x /root/workspace/manage_service.sh现在你可以用统一的方式管理服务了# 启动服务 /root/workspace/manage_service.sh start # 查看状态 /root/workspace/manage_service.sh status # 查看实时日志 /root/workspace/manage_service.sh logs # 重启服务 /root/workspace/manage_service.sh restart # 清理旧日志 /root/workspace/manage_service.sh cleanup6. 总结你的gte-base-zh服务现在“专业”多了通过今天的学习你已经掌握了两个最核心的运维技能。让我们回顾一下都做了什么6.1 日志管理从混乱到有序认识了问题知道了为什么需要管理日志磁盘空间、查看困难等手动清理学会了临时清理大日志文件的方法自动轮转配置了logrotate让系统自动帮你管理日志按时间或按大小轮转自动压缩旧日志保留指定数量的历史文件现在你的日志再也不会把磁盘撑爆了查看历史日志也方便多了。6.2 服务监控从被动到主动基础监控写了一个简单的Shell脚本每分钟检查服务状态进阶监控用Python写了一个全面的监控脚本监控服务是否可用响应时间快慢内存和CPU使用情况自动重启失败的服务可视化监控创建了一个简单的Web面板直观查看服务状态自动化运行用crontab让监控脚本自动运行现在你可以在服务出问题之前就发现异常而不是等用户来告诉你。6.3 统一管理创建了服务管理脚本我们还创建了一个manage_service.sh脚本让你可以用统一的命令来管理服务start/stop/restart启动、停止、重启服务status查看服务状态和资源使用logs查看实时日志monitor启动监控cleanup清理旧日志6.4 下一步可以做什么如果你想让服务更加稳定还可以考虑设置告警通知当服务异常时自动发邮件或短信通知你监控更多指标比如每秒请求数、错误率、模型推理时间等使用专业监控工具比如Prometheus Grafana功能更强大容器化部署用Docker打包服务部署更简单多实例部署启动多个服务实例用Nginx做负载均衡一个挂了还有其他运维工作就像给服务穿上盔甲——平时可能感觉不到它的存在但关键时刻它能保护服务免受伤害。今天学的内容虽然基础但已经能解决80%的常见问题了。记住好的运维不是等出了问题再去解决而是提前预防问题发生。现在你的gte-base-zh服务已经有了基本的“盔甲”可以更稳定地运行了。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。