gte-base-zh CI/CD集成GitHub Actions自动化测试gte-base-zh服务健康状态你是不是也遇到过这种情况辛辛苦苦部署了一个AI模型服务比如这个gte-base-zh文本嵌入模型部署时一切正常但过几天突然发现服务挂了用户反馈接踵而至而你却毫不知情。更让人头疼的是每次代码更新或者环境变动后都需要手动去测试服务是否正常既耗时又容易遗漏。有没有一种方法能让服务健康检查自动化出现问题第一时间通知你今天我就来分享一个实战方案用GitHub Actions为gte-base-zh服务搭建自动化健康检查流水线。这个方案不仅能自动测试服务状态还能在服务异常时通过邮件、钉钉、企业微信等方式通知你让你真正做到躺平式运维。1. 为什么需要自动化健康检查在深入技术细节之前我们先聊聊为什么要做这件事。gte-base-zh是一个文本嵌入模型它能把文本转换成向量表示是很多AI应用的基础组件。一旦这个服务出问题依赖它的所有应用都会受到影响。1.1 传统手动检查的痛点我刚开始部署gte-base-zh时采用的是最原始的方法定时手动访问每天上班第一件事就是打开浏览器访问服务地址看看是否正常查看日志文件SSH登录服务器查看/root/workspace/model_server.log文件测试接口调用手动调用一下相似度比对接口看看返回结果是否正确这种方法有几个明显的问题响应延迟服务可能在半夜挂掉但你要到第二天早上才发现容易遗漏工作一忙就忘了检查等用户反馈时已经晚了无法量化服务是慢还是挂没有一个明确的判断标准无法追溯出现问题后很难知道是什么时候开始异常的1.2 自动化检查的优势相比之下自动化健康检查能带来这些好处7×24小时监控系统永不休息随时监控服务状态即时告警异常发生几分钟内就能收到通知历史记录所有检查结果都有记录方便问题排查集成到CI/CD代码更新后自动验证服务是否正常2. 环境准备与基础概念在开始配置GitHub Actions之前我们先确保gte-base-zh服务已经正确部署并理解几个关键概念。2.1 gte-base-zh服务确认根据你提供的部署信息gte-base-zh服务应该已经通过以下方式启动# 1. 启动xinference服务 xinference-local --host 0.0.0.0 --port 9997 # 2. 通过脚本发布gte-base-zh模型服务 python /usr/local/bin/launch_model_server.py服务启动成功后你应该能通过以下方式验证# 查看服务日志 cat /root/workspace/model_server.log # 或者直接访问Web UI # 在浏览器中打开http://你的服务器IP:99972.2 健康检查的核心思路我们要测试的服务健康状态主要包括三个方面服务可达性服务端口是否正常监听接口功能性关键API接口是否能正常响应模型可用性模型推理功能是否正常对应的测试方法也很直接对端口9997发起HTTP请求检查响应状态码调用相似度比对接口验证返回结果格式和内容模拟真实使用场景测试文本嵌入功能2.3 GitHub Actions基础如果你对GitHub Actions还不熟悉这里简单介绍一下GitHub Actions是GitHub提供的持续集成/持续部署CI/CD服务它允许你在代码仓库中定义自动化工作流。每个工作流由多个步骤组成这些步骤可以在代码推送、定时触发或手动触发时自动执行。对于我们这个场景我们会用到定时触发每天或每小时自动检查服务状态HTTP请求向gte-base-zh服务发送测试请求结果判断根据响应判断服务是否健康通知发送服务异常时发送告警3. 配置GitHub Actions健康检查工作流现在我们来一步步配置完整的自动化健康检查流水线。3.1 创建GitHub仓库和工作流文件首先你需要有一个GitHub仓库来存放配置。如果你还没有可以创建一个新的仓库。在仓库中创建目录和文件# 创建工作流目录 mkdir -p .github/workflows # 创建健康检查工作流文件 touch .github/workflows/health-check.yml3.2 编写基础健康检查工作流打开.github/workflows/health-check.yml文件我们先写一个最基础的版本name: gte-base-zh Health Check on: # 定时触发每天凌晨2点检查一次 schedule: - cron: 0 2 * * * # 手动触发可以在GitHub页面上手动运行 workflow_dispatch: jobs: health-check: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkoutv3 - name: Test service availability run: | # 测试服务端口是否可达 if curl -s -o /dev/null -w %{http_code} http://你的服务器IP:9997/ | grep -q 200; then echo ✅ Service is reachable else echo ❌ Service is not reachable exit 1 fi这个基础版本只检查服务是否可达但还不够。我们需要测试具体的功能接口。3.3 完善的功能测试工作流让我们写一个更完整的版本测试gte-base-zh的核心功能name: gte-base-zh Health Check on: schedule: - cron: 0 */6 * * * # 每6小时检查一次 workflow_dispatch: env: SERVICE_URL: http://你的服务器IP:9997 # 注意实际使用时建议将IP地址存储在GitHub Secrets中 jobs: health-check: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkoutv3 - name: Test basic connectivity id: connectivity-test run: | echo Testing basic connectivity to $SERVICE_URL # 测试1: 检查Web UI是否可访问 response_code$(curl -s -o /dev/null -w %{http_code} $SERVICE_URL) if [ $response_code -eq 200 ]; then echo ✅ Web UI is accessible (HTTP $response_code) echo connectivitypass $GITHUB_OUTPUT else echo ❌ Web UI is not accessible (HTTP $response_code) echo connectivityfail $GITHUB_OUTPUT exit 1 fi - name: Test embedding API id: api-test run: | echo Testing embedding API functionality # 准备测试数据 TEST_DATA{ model: gte-base-zh, input: [今天天气真好, 天气晴朗适合外出] } # 调用嵌入接口 response$(curl -s -X POST $SERVICE_URL/v1/embeddings \ -H Content-Type: application/json \ -d $TEST_DATA) # 检查响应 if echo $response | grep -q embedding; then echo ✅ Embedding API is working correctly echo api_statuspass $GITHUB_OUTPUT # 可选记录响应时间 start_time$(date %s%3N) curl -s -o /dev/null -X POST $SERVICE_URL/v1/embeddings \ -H Content-Type: application/json \ -d $TEST_DATA end_time$(date %s%3N) duration$((end_time - start_time)) echo Response time: ${duration}ms else echo ❌ Embedding API returned unexpected response echo Response: $response echo api_statusfail $GITHUB_OUTPUT exit 1 fi - name: Test similarity comparison id: similarity-test run: | echo Testing similarity comparison functionality # 通过Web UI接口测试相似度比对 # 这里模拟Web UI的请求方式 SIMILARITY_DATA{ texts: [ {text: 人工智能是未来趋势}, {text: AI技术发展迅速} ] } response$(curl -s -X POST $SERVICE_URL/api/similarity \ -H Content-Type: application/json \ -d $SIMILARITY_DATA) if echo $response | grep -q similarity || echo $response | grep -q score; then echo ✅ Similarity comparison is working echo similarity_statuspass $GITHUB_OUTPUT else echo ❌ Similarity comparison failed echo Response: $response echo similarity_statusfail $GITHUB_OUTPUT exit 1 fi - name: Generate health report if: always() run: | echo gte-base-zh Health Check Report echo Check time: $(date) echo Service URL: $SERVICE_URL echo # 这里可以汇总所有测试结果 # 在实际使用中你可能需要更复杂的报告生成逻辑 echo All tests completed!3.4 添加告警通知测试发现问题很重要但及时通知你更重要。我们来添加告警功能- name: Send notification on failure if: failure() uses: dawidd6/action-send-mailv3 with: # 使用GitHub Secrets存储敏感信息 server_address: smtp.gmail.com server_port: 465 username: ${{ secrets.MAIL_USERNAME }} password: ${{ secrets.MAIL_PASSWORD }} subject: gte-base-zh Service Health Check Failed to: ${{ secrets.NOTIFICATION_EMAIL }} from: GitHub Actions Bot body: | gte-base-zh service health check failed! Workflow: ${{ github.workflow }} Run ID: ${{ github.run_id }} Run URL: ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }} Service URL: ${{ env.SERVICE_URL }} Please check the service immediately.除了邮件你还可以添加其他通知方式比如Slack、钉钉、企业微信等。4. 高级功能与最佳实践基础的健康检查已经能解决大部分问题但我们可以做得更好。下面是一些高级功能和最佳实践。4.1 使用GitHub Secrets保护敏感信息在之前的配置中我们硬编码了服务器IP地址这既不安全也不灵活。更好的做法是使用GitHub Secrets。在GitHub仓库中设置Secrets进入你的GitHub仓库点击 Settings → Secrets and variables → Actions点击 New repository secret添加以下SecretsSERVICE_IP: 你的服务器IP地址MAIL_USERNAME: 发件邮箱MAIL_PASSWORD: 邮箱密码或应用专用密码NOTIFICATION_EMAIL: 接收告警的邮箱更新工作流使用Secretsenv: SERVICE_URL: http://${{ secrets.SERVICE_IP }}:99974.2 添加性能监控除了检查服务是否可用我们还可以监控服务性能- name: Performance monitoring id: perf-test run: | echo Running performance tests... # 测试响应时间 declare -a response_times() for i in {1..5}; do start_time$(date %s%3N) curl -s -o /dev/null -X POST $SERVICE_URL/v1/embeddings \ -H Content-Type: application/json \ -d {model: gte-base-zh, input: [测试文本]} end_time$(date %s%3N) duration$((end_time - start_time)) response_times($duration) echo Request $i: ${duration}ms sleep 1 done # 计算平均响应时间 sum0 for time in ${response_times[]}; do sum$((sum time)) done avg$((sum / ${#response_times[]})) echo Average response time: ${avg}ms # 如果平均响应时间超过阈值发出警告 if [ $avg -gt 1000 ]; then echo ⚠️ Warning: High response time detected (${avg}ms) echo performancewarning $GITHUB_OUTPUT else echo ✅ Performance is good echo performancegood $GITHUB_OUTPUT fi4.3 集成到CI/CD流水线如果你的gte-base-zh服务部署也是通过CI/CD完成的可以把健康检查集成到部署流程中name: Deploy and Verify gte-base-zh on: push: branches: [ main ] paths: - deploy-scripts/** jobs: deploy: runs-on: ubuntu-latest steps: - name: Deploy to server run: | # 这里添加你的部署脚本 echo Deploying gte-base-zh service... # ssh userserver cd /path/to/service git pull restart service health-check: needs: deploy runs-on: ubuntu-latest steps: - name: Wait for service to be ready run: | echo Waiting for service to start... sleep 30 - name: Run comprehensive health check run: | # 运行我们之前定义的完整健康检查 # 这里可以调用一个专门的检查脚本 ./scripts/health-check.sh4.4 创建可重用的健康检查脚本为了让配置更清晰我们可以把健康检查逻辑提取到单独的脚本中创建scripts/health-check.sh#!/bin/bash # gte-base-zh健康检查脚本 # 用法: ./health-check.sh service_url set -e SERVICE_URL${1:-http://localhost:9997} TIMEOUT10 echo Starting health check for gte-base-zh service... echo Service URL: $SERVICE_URL # 函数检查服务是否可达 check_connectivity() { echo Checking service connectivity... local max_retries3 local retry_count0 while [ $retry_count -lt $max_retries ]; do if curl -s -f --max-time $TIMEOUT $SERVICE_URL /dev/null; then echo ✅ Service is reachable return 0 fi retry_count$((retry_count 1)) echo Retry $retry_count/$max_retries... sleep 2 done echo ❌ Service is not reachable after $max_retries attempts return 1 } # 函数测试嵌入API test_embedding_api() { echo Testing embedding API... local test_data{ model: gte-base-zh, input: [健康检查测试文本, 这是另一个测试句子] } local response$(curl -s --max-time $TIMEOUT -X POST $SERVICE_URL/v1/embeddings \ -H Content-Type: application/json \ -d $test_data) if echo $response | jq -e .data[0].embedding /dev/null 21; then echo ✅ Embedding API is working correctly # 检查向量维度gte-base-zh通常是768维 local dims$(echo $response | jq .data[0].embedding | length) echo Vector dimensions: $dims return 0 else echo ❌ Embedding API failed echo Response: $response return 1 fi } # 函数测试相似度计算 test_similarity() { echo Testing similarity calculation... local test_data{ texts: [ {text: 机器学习需要大量数据}, {text: 数据是AI训练的基础} ] } # 注意实际端点可能需要调整 local response$(curl -s --max-time $TIMEOUT -X POST $SERVICE_URL/api/similarity \ -H Content-Type: application/json \ -d $test_data 2/dev/null || true) if [ -n $response ] (echo $response | grep -q similarity\|score || echo $response | jq -e .score /dev/null 21); then echo ✅ Similarity calculation is working return 0 else echo ⚠️ Similarity endpoint might have different format echo Response: $response # 不把这个作为失败因为端点可能不同 return 0 fi } # 函数性能测试 performance_test() { echo Running performance test... local iterations3 local total_time0 for ((i1; iiterations; i)); do local start_time$(date %s%3N) curl -s -o /dev/null --max-time $TIMEOUT -X POST $SERVICE_URL/v1/embeddings \ -H Content-Type: application/json \ -d {model: gte-base-zh, input: [性能测试]} local end_time$(date %s%3N) local duration$((end_time - start_time)) total_time$((total_time duration)) echo Request $i: ${duration}ms sleep 0.5 done local avg_time$((total_time / iterations)) echo ✅ Average response time: ${avg_time}ms if [ $avg_time -gt 2000 ]; then echo ⚠️ Warning: Response time is higher than expected return 1 fi return 0 } # 主函数 main() { local exit_code0 # 安装jq如果不存在 if ! command -v jq /dev/null; then echo Installing jq for JSON parsing... sudo apt-get update sudo apt-get install -y jq fi # 运行所有检查 check_connectivity || exit_code1 test_embedding_api || exit_code1 test_similarity || exit_code1 performance_test || exit_code1 # 生成报告 echo echo echo Health Check Summary echo echo Service: $SERVICE_URL echo Timestamp: $(date) if [ $exit_code -eq 0 ]; then echo Status: ✅ ALL CHECKS PASSED else echo Status: ❌ SOME CHECKS FAILED fi echo return $exit_code } # 运行主函数 main更新GitHub Actions使用脚本- name: Run health check script run: | chmod x ./scripts/health-check.sh ./scripts/health-check.sh $SERVICE_URL5. 实际部署与问题排查配置完成后让我们看看如何实际部署和可能遇到的问题。5.1 首次运行配置推送代码到GitHubgit add .github/workflows/health-check.yml scripts/ git commit -m Add gte-base-zh health check workflow git push origin main手动触发第一次运行进入GitHub仓库的Actions页面找到gte-base-zh Health Check工作流点击Run workflow手动触发查看运行结果点击运行记录查看详细日志检查每个步骤的输出确认服务测试是否通过5.2 常见问题与解决方案问题1curl命令超时错误curl: (28) Connection timed out after 10001 milliseconds解决方案检查服务器防火墙是否开放了9997端口确认服务器IP地址是否正确增加超时时间curl --max-time 30问题2API端点不存在错误404 Not Found解决方案检查xinference的API文档确认正确的端点路径使用curl $SERVICE_URL查看可用的端点调整脚本中的API路径问题3GitHub Actions无法访问内网服务错误无法连接到服务器解决方案如果服务在内网需要设置VPN或使用反向代理考虑使用自托管的GitHub Actions Runner部署在内网或者使用webhook方式让服务器主动报告健康状态问题4邮件通知发送失败错误SMTP authentication failed解决方案检查邮箱密码是否正确可能需要应用专用密码尝试使用其他SMTP服务如SendGrid、Mailgun考虑使用其他通知方式Slack、钉钉等5.3 监控与优化建议一旦健康检查系统运行起来你还可以考虑以下优化分级告警轻微问题响应时间慢发送到群聊严重问题服务不可用相关人员紧急问题完全宕机电话通知历史数据分析- name: Store check results if: always() run: | # 将检查结果存储到数据库或文件 echo $(date),${{ steps.connectivity-test.outputs.status }},${{ steps.api-test.outputs.status }} health-history.csv自动化修复- name: Try to restart service on failure if: failure() steps.connectivity-test.outputs.status fail run: | # 尝试自动重启服务 ssh userserver systemctl restart gte-base-zh sleep 30 # 重新测试 curl -f $SERVICE_URL echo ✅ Service restored || echo ❌ Still failing6. 总结通过本文的指南你应该已经掌握了如何为gte-base-zh服务搭建一个完整的自动化健康检查系统。让我们回顾一下关键点6.1 核心价值自动化监控告别手动检查实现7×24小时无人值守监控即时告警服务异常时第一时间通知减少故障影响时间历史追踪所有检查结果都有记录方便问题分析和趋势观察集成部署与CI/CD流程无缝集成确保每次部署后服务正常6.2 实施步骤总结确认服务状态确保gte-base-zh服务已正确部署并运行创建检查脚本编写全面的健康检查脚本覆盖连通性、功能、性能配置GitHub Actions设置定时触发的工作流执行健康检查添加通知机制配置邮件、钉钉等告警方式测试与优化手动触发测试根据实际情况调整阈值和频率6.3 后续扩展方向这个基础框架还可以进一步扩展多地域监控从不同地区测试服务可用性依赖服务检查同时检查数据库、Redis等依赖服务容量预警监控服务器资源使用情况提前预警自动化报表定期生成服务健康报告发送给团队最重要的是这个方案不仅适用于gte-base-zh你可以用同样的方法为任何HTTP服务添加健康检查。一次配置长期受益。现在就去为你的gte-base-zh服务配置自动化健康检查吧让运维工作变得更轻松、更可靠获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。
gte-base-zh CI/CD集成：GitHub Actions自动化测试gte-base-zh服务健康状态
gte-base-zh CI/CD集成GitHub Actions自动化测试gte-base-zh服务健康状态你是不是也遇到过这种情况辛辛苦苦部署了一个AI模型服务比如这个gte-base-zh文本嵌入模型部署时一切正常但过几天突然发现服务挂了用户反馈接踵而至而你却毫不知情。更让人头疼的是每次代码更新或者环境变动后都需要手动去测试服务是否正常既耗时又容易遗漏。有没有一种方法能让服务健康检查自动化出现问题第一时间通知你今天我就来分享一个实战方案用GitHub Actions为gte-base-zh服务搭建自动化健康检查流水线。这个方案不仅能自动测试服务状态还能在服务异常时通过邮件、钉钉、企业微信等方式通知你让你真正做到躺平式运维。1. 为什么需要自动化健康检查在深入技术细节之前我们先聊聊为什么要做这件事。gte-base-zh是一个文本嵌入模型它能把文本转换成向量表示是很多AI应用的基础组件。一旦这个服务出问题依赖它的所有应用都会受到影响。1.1 传统手动检查的痛点我刚开始部署gte-base-zh时采用的是最原始的方法定时手动访问每天上班第一件事就是打开浏览器访问服务地址看看是否正常查看日志文件SSH登录服务器查看/root/workspace/model_server.log文件测试接口调用手动调用一下相似度比对接口看看返回结果是否正确这种方法有几个明显的问题响应延迟服务可能在半夜挂掉但你要到第二天早上才发现容易遗漏工作一忙就忘了检查等用户反馈时已经晚了无法量化服务是慢还是挂没有一个明确的判断标准无法追溯出现问题后很难知道是什么时候开始异常的1.2 自动化检查的优势相比之下自动化健康检查能带来这些好处7×24小时监控系统永不休息随时监控服务状态即时告警异常发生几分钟内就能收到通知历史记录所有检查结果都有记录方便问题排查集成到CI/CD代码更新后自动验证服务是否正常2. 环境准备与基础概念在开始配置GitHub Actions之前我们先确保gte-base-zh服务已经正确部署并理解几个关键概念。2.1 gte-base-zh服务确认根据你提供的部署信息gte-base-zh服务应该已经通过以下方式启动# 1. 启动xinference服务 xinference-local --host 0.0.0.0 --port 9997 # 2. 通过脚本发布gte-base-zh模型服务 python /usr/local/bin/launch_model_server.py服务启动成功后你应该能通过以下方式验证# 查看服务日志 cat /root/workspace/model_server.log # 或者直接访问Web UI # 在浏览器中打开http://你的服务器IP:99972.2 健康检查的核心思路我们要测试的服务健康状态主要包括三个方面服务可达性服务端口是否正常监听接口功能性关键API接口是否能正常响应模型可用性模型推理功能是否正常对应的测试方法也很直接对端口9997发起HTTP请求检查响应状态码调用相似度比对接口验证返回结果格式和内容模拟真实使用场景测试文本嵌入功能2.3 GitHub Actions基础如果你对GitHub Actions还不熟悉这里简单介绍一下GitHub Actions是GitHub提供的持续集成/持续部署CI/CD服务它允许你在代码仓库中定义自动化工作流。每个工作流由多个步骤组成这些步骤可以在代码推送、定时触发或手动触发时自动执行。对于我们这个场景我们会用到定时触发每天或每小时自动检查服务状态HTTP请求向gte-base-zh服务发送测试请求结果判断根据响应判断服务是否健康通知发送服务异常时发送告警3. 配置GitHub Actions健康检查工作流现在我们来一步步配置完整的自动化健康检查流水线。3.1 创建GitHub仓库和工作流文件首先你需要有一个GitHub仓库来存放配置。如果你还没有可以创建一个新的仓库。在仓库中创建目录和文件# 创建工作流目录 mkdir -p .github/workflows # 创建健康检查工作流文件 touch .github/workflows/health-check.yml3.2 编写基础健康检查工作流打开.github/workflows/health-check.yml文件我们先写一个最基础的版本name: gte-base-zh Health Check on: # 定时触发每天凌晨2点检查一次 schedule: - cron: 0 2 * * * # 手动触发可以在GitHub页面上手动运行 workflow_dispatch: jobs: health-check: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkoutv3 - name: Test service availability run: | # 测试服务端口是否可达 if curl -s -o /dev/null -w %{http_code} http://你的服务器IP:9997/ | grep -q 200; then echo ✅ Service is reachable else echo ❌ Service is not reachable exit 1 fi这个基础版本只检查服务是否可达但还不够。我们需要测试具体的功能接口。3.3 完善的功能测试工作流让我们写一个更完整的版本测试gte-base-zh的核心功能name: gte-base-zh Health Check on: schedule: - cron: 0 */6 * * * # 每6小时检查一次 workflow_dispatch: env: SERVICE_URL: http://你的服务器IP:9997 # 注意实际使用时建议将IP地址存储在GitHub Secrets中 jobs: health-check: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkoutv3 - name: Test basic connectivity id: connectivity-test run: | echo Testing basic connectivity to $SERVICE_URL # 测试1: 检查Web UI是否可访问 response_code$(curl -s -o /dev/null -w %{http_code} $SERVICE_URL) if [ $response_code -eq 200 ]; then echo ✅ Web UI is accessible (HTTP $response_code) echo connectivitypass $GITHUB_OUTPUT else echo ❌ Web UI is not accessible (HTTP $response_code) echo connectivityfail $GITHUB_OUTPUT exit 1 fi - name: Test embedding API id: api-test run: | echo Testing embedding API functionality # 准备测试数据 TEST_DATA{ model: gte-base-zh, input: [今天天气真好, 天气晴朗适合外出] } # 调用嵌入接口 response$(curl -s -X POST $SERVICE_URL/v1/embeddings \ -H Content-Type: application/json \ -d $TEST_DATA) # 检查响应 if echo $response | grep -q embedding; then echo ✅ Embedding API is working correctly echo api_statuspass $GITHUB_OUTPUT # 可选记录响应时间 start_time$(date %s%3N) curl -s -o /dev/null -X POST $SERVICE_URL/v1/embeddings \ -H Content-Type: application/json \ -d $TEST_DATA end_time$(date %s%3N) duration$((end_time - start_time)) echo Response time: ${duration}ms else echo ❌ Embedding API returned unexpected response echo Response: $response echo api_statusfail $GITHUB_OUTPUT exit 1 fi - name: Test similarity comparison id: similarity-test run: | echo Testing similarity comparison functionality # 通过Web UI接口测试相似度比对 # 这里模拟Web UI的请求方式 SIMILARITY_DATA{ texts: [ {text: 人工智能是未来趋势}, {text: AI技术发展迅速} ] } response$(curl -s -X POST $SERVICE_URL/api/similarity \ -H Content-Type: application/json \ -d $SIMILARITY_DATA) if echo $response | grep -q similarity || echo $response | grep -q score; then echo ✅ Similarity comparison is working echo similarity_statuspass $GITHUB_OUTPUT else echo ❌ Similarity comparison failed echo Response: $response echo similarity_statusfail $GITHUB_OUTPUT exit 1 fi - name: Generate health report if: always() run: | echo gte-base-zh Health Check Report echo Check time: $(date) echo Service URL: $SERVICE_URL echo # 这里可以汇总所有测试结果 # 在实际使用中你可能需要更复杂的报告生成逻辑 echo All tests completed!3.4 添加告警通知测试发现问题很重要但及时通知你更重要。我们来添加告警功能- name: Send notification on failure if: failure() uses: dawidd6/action-send-mailv3 with: # 使用GitHub Secrets存储敏感信息 server_address: smtp.gmail.com server_port: 465 username: ${{ secrets.MAIL_USERNAME }} password: ${{ secrets.MAIL_PASSWORD }} subject: gte-base-zh Service Health Check Failed to: ${{ secrets.NOTIFICATION_EMAIL }} from: GitHub Actions Bot body: | gte-base-zh service health check failed! Workflow: ${{ github.workflow }} Run ID: ${{ github.run_id }} Run URL: ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }} Service URL: ${{ env.SERVICE_URL }} Please check the service immediately.除了邮件你还可以添加其他通知方式比如Slack、钉钉、企业微信等。4. 高级功能与最佳实践基础的健康检查已经能解决大部分问题但我们可以做得更好。下面是一些高级功能和最佳实践。4.1 使用GitHub Secrets保护敏感信息在之前的配置中我们硬编码了服务器IP地址这既不安全也不灵活。更好的做法是使用GitHub Secrets。在GitHub仓库中设置Secrets进入你的GitHub仓库点击 Settings → Secrets and variables → Actions点击 New repository secret添加以下SecretsSERVICE_IP: 你的服务器IP地址MAIL_USERNAME: 发件邮箱MAIL_PASSWORD: 邮箱密码或应用专用密码NOTIFICATION_EMAIL: 接收告警的邮箱更新工作流使用Secretsenv: SERVICE_URL: http://${{ secrets.SERVICE_IP }}:99974.2 添加性能监控除了检查服务是否可用我们还可以监控服务性能- name: Performance monitoring id: perf-test run: | echo Running performance tests... # 测试响应时间 declare -a response_times() for i in {1..5}; do start_time$(date %s%3N) curl -s -o /dev/null -X POST $SERVICE_URL/v1/embeddings \ -H Content-Type: application/json \ -d {model: gte-base-zh, input: [测试文本]} end_time$(date %s%3N) duration$((end_time - start_time)) response_times($duration) echo Request $i: ${duration}ms sleep 1 done # 计算平均响应时间 sum0 for time in ${response_times[]}; do sum$((sum time)) done avg$((sum / ${#response_times[]})) echo Average response time: ${avg}ms # 如果平均响应时间超过阈值发出警告 if [ $avg -gt 1000 ]; then echo ⚠️ Warning: High response time detected (${avg}ms) echo performancewarning $GITHUB_OUTPUT else echo ✅ Performance is good echo performancegood $GITHUB_OUTPUT fi4.3 集成到CI/CD流水线如果你的gte-base-zh服务部署也是通过CI/CD完成的可以把健康检查集成到部署流程中name: Deploy and Verify gte-base-zh on: push: branches: [ main ] paths: - deploy-scripts/** jobs: deploy: runs-on: ubuntu-latest steps: - name: Deploy to server run: | # 这里添加你的部署脚本 echo Deploying gte-base-zh service... # ssh userserver cd /path/to/service git pull restart service health-check: needs: deploy runs-on: ubuntu-latest steps: - name: Wait for service to be ready run: | echo Waiting for service to start... sleep 30 - name: Run comprehensive health check run: | # 运行我们之前定义的完整健康检查 # 这里可以调用一个专门的检查脚本 ./scripts/health-check.sh4.4 创建可重用的健康检查脚本为了让配置更清晰我们可以把健康检查逻辑提取到单独的脚本中创建scripts/health-check.sh#!/bin/bash # gte-base-zh健康检查脚本 # 用法: ./health-check.sh service_url set -e SERVICE_URL${1:-http://localhost:9997} TIMEOUT10 echo Starting health check for gte-base-zh service... echo Service URL: $SERVICE_URL # 函数检查服务是否可达 check_connectivity() { echo Checking service connectivity... local max_retries3 local retry_count0 while [ $retry_count -lt $max_retries ]; do if curl -s -f --max-time $TIMEOUT $SERVICE_URL /dev/null; then echo ✅ Service is reachable return 0 fi retry_count$((retry_count 1)) echo Retry $retry_count/$max_retries... sleep 2 done echo ❌ Service is not reachable after $max_retries attempts return 1 } # 函数测试嵌入API test_embedding_api() { echo Testing embedding API... local test_data{ model: gte-base-zh, input: [健康检查测试文本, 这是另一个测试句子] } local response$(curl -s --max-time $TIMEOUT -X POST $SERVICE_URL/v1/embeddings \ -H Content-Type: application/json \ -d $test_data) if echo $response | jq -e .data[0].embedding /dev/null 21; then echo ✅ Embedding API is working correctly # 检查向量维度gte-base-zh通常是768维 local dims$(echo $response | jq .data[0].embedding | length) echo Vector dimensions: $dims return 0 else echo ❌ Embedding API failed echo Response: $response return 1 fi } # 函数测试相似度计算 test_similarity() { echo Testing similarity calculation... local test_data{ texts: [ {text: 机器学习需要大量数据}, {text: 数据是AI训练的基础} ] } # 注意实际端点可能需要调整 local response$(curl -s --max-time $TIMEOUT -X POST $SERVICE_URL/api/similarity \ -H Content-Type: application/json \ -d $test_data 2/dev/null || true) if [ -n $response ] (echo $response | grep -q similarity\|score || echo $response | jq -e .score /dev/null 21); then echo ✅ Similarity calculation is working return 0 else echo ⚠️ Similarity endpoint might have different format echo Response: $response # 不把这个作为失败因为端点可能不同 return 0 fi } # 函数性能测试 performance_test() { echo Running performance test... local iterations3 local total_time0 for ((i1; iiterations; i)); do local start_time$(date %s%3N) curl -s -o /dev/null --max-time $TIMEOUT -X POST $SERVICE_URL/v1/embeddings \ -H Content-Type: application/json \ -d {model: gte-base-zh, input: [性能测试]} local end_time$(date %s%3N) local duration$((end_time - start_time)) total_time$((total_time duration)) echo Request $i: ${duration}ms sleep 0.5 done local avg_time$((total_time / iterations)) echo ✅ Average response time: ${avg_time}ms if [ $avg_time -gt 2000 ]; then echo ⚠️ Warning: Response time is higher than expected return 1 fi return 0 } # 主函数 main() { local exit_code0 # 安装jq如果不存在 if ! command -v jq /dev/null; then echo Installing jq for JSON parsing... sudo apt-get update sudo apt-get install -y jq fi # 运行所有检查 check_connectivity || exit_code1 test_embedding_api || exit_code1 test_similarity || exit_code1 performance_test || exit_code1 # 生成报告 echo echo echo Health Check Summary echo echo Service: $SERVICE_URL echo Timestamp: $(date) if [ $exit_code -eq 0 ]; then echo Status: ✅ ALL CHECKS PASSED else echo Status: ❌ SOME CHECKS FAILED fi echo return $exit_code } # 运行主函数 main更新GitHub Actions使用脚本- name: Run health check script run: | chmod x ./scripts/health-check.sh ./scripts/health-check.sh $SERVICE_URL5. 实际部署与问题排查配置完成后让我们看看如何实际部署和可能遇到的问题。5.1 首次运行配置推送代码到GitHubgit add .github/workflows/health-check.yml scripts/ git commit -m Add gte-base-zh health check workflow git push origin main手动触发第一次运行进入GitHub仓库的Actions页面找到gte-base-zh Health Check工作流点击Run workflow手动触发查看运行结果点击运行记录查看详细日志检查每个步骤的输出确认服务测试是否通过5.2 常见问题与解决方案问题1curl命令超时错误curl: (28) Connection timed out after 10001 milliseconds解决方案检查服务器防火墙是否开放了9997端口确认服务器IP地址是否正确增加超时时间curl --max-time 30问题2API端点不存在错误404 Not Found解决方案检查xinference的API文档确认正确的端点路径使用curl $SERVICE_URL查看可用的端点调整脚本中的API路径问题3GitHub Actions无法访问内网服务错误无法连接到服务器解决方案如果服务在内网需要设置VPN或使用反向代理考虑使用自托管的GitHub Actions Runner部署在内网或者使用webhook方式让服务器主动报告健康状态问题4邮件通知发送失败错误SMTP authentication failed解决方案检查邮箱密码是否正确可能需要应用专用密码尝试使用其他SMTP服务如SendGrid、Mailgun考虑使用其他通知方式Slack、钉钉等5.3 监控与优化建议一旦健康检查系统运行起来你还可以考虑以下优化分级告警轻微问题响应时间慢发送到群聊严重问题服务不可用相关人员紧急问题完全宕机电话通知历史数据分析- name: Store check results if: always() run: | # 将检查结果存储到数据库或文件 echo $(date),${{ steps.connectivity-test.outputs.status }},${{ steps.api-test.outputs.status }} health-history.csv自动化修复- name: Try to restart service on failure if: failure() steps.connectivity-test.outputs.status fail run: | # 尝试自动重启服务 ssh userserver systemctl restart gte-base-zh sleep 30 # 重新测试 curl -f $SERVICE_URL echo ✅ Service restored || echo ❌ Still failing6. 总结通过本文的指南你应该已经掌握了如何为gte-base-zh服务搭建一个完整的自动化健康检查系统。让我们回顾一下关键点6.1 核心价值自动化监控告别手动检查实现7×24小时无人值守监控即时告警服务异常时第一时间通知减少故障影响时间历史追踪所有检查结果都有记录方便问题分析和趋势观察集成部署与CI/CD流程无缝集成确保每次部署后服务正常6.2 实施步骤总结确认服务状态确保gte-base-zh服务已正确部署并运行创建检查脚本编写全面的健康检查脚本覆盖连通性、功能、性能配置GitHub Actions设置定时触发的工作流执行健康检查添加通知机制配置邮件、钉钉等告警方式测试与优化手动触发测试根据实际情况调整阈值和频率6.3 后续扩展方向这个基础框架还可以进一步扩展多地域监控从不同地区测试服务可用性依赖服务检查同时检查数据库、Redis等依赖服务容量预警监控服务器资源使用情况提前预警自动化报表定期生成服务健康报告发送给团队最重要的是这个方案不仅适用于gte-base-zh你可以用同样的方法为任何HTTP服务添加健康检查。一次配置长期受益。现在就去为你的gte-base-zh服务配置自动化健康检查吧让运维工作变得更轻松、更可靠获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。
