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. 容易遗漏：工作一忙就忘了检查，等用户反馈时已经晚了
3. 无法量化：服务是"慢"还是"挂"，没有一个明确的判断标准
4. 无法追溯：出现问题后，很难知道是什么时候开始异常的

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:9997

2.2 健康检查的核心思路

我们要测试的服务健康状态，主要包括三个方面：

1. 服务可达性：服务端口是否正常监听
2. 接口功能性：关键API接口是否能正常响应
3. 模型可用性：模型推理功能是否正常

对应的测试方法也很直接：

• 对端口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.yml

3.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/checkout@v3
    
    - 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/checkout@v3
    
    - 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 "connectivity=pass" >> $GITHUB_OUTPUT
        else
          echo "❌ Web UI is not accessible (HTTP $response_code)"
          echo "connectivity=fail" >> $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_status=pass" >> $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_status=fail" >> $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_status=pass" >> $GITHUB_OUTPUT
        else
          echo "❌ Similarity comparison failed"
          echo "Response: $response"
          echo "similarity_status=fail" >> $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-mail@v3
      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：

1. 进入你的GitHub仓库
2. 点击 Settings → Secrets and variables → Actions
3. 点击 New repository secret
4. 添加以下Secrets：
   • SERVICE_IP: 你的服务器IP地址
   • MAIL_USERNAME: 发件邮箱
   • MAIL_PASSWORD: 邮箱密码或应用专用密码
   • NOTIFICATION_EMAIL: 接收告警的邮箱

更新工作流使用Secrets：

env:
  SERVICE_URL: "http://${{ secrets.SERVICE_IP }}:9997"

4.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
        
        # 计算平均响应时间
        sum=0
        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 "performance=warning" >> $GITHUB_OUTPUT
        else
          echo "✅ Performance is good"
          echo "performance=good" >> $GITHUB_OUTPUT
        fi

4.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 user@server "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.sh

4.4 创建可重用的健康检查脚本

为了让配置更清晰，我们可以把健康检查逻辑提取到单独的脚本中：

创建 scripts/health-check.sh：

#!/bin/bash

# gte-base-zh健康检查脚本
# 用法: ./health-check.sh <service_url>

set -e

SERVICE_URL=${1:-"http://localhost:9997"}
TIMEOUT=10

echo "Starting health check for gte-base-zh service..."
echo "Service URL: $SERVICE_URL"

# 函数：检查服务是否可达
check_connectivity() {
    echo "🔍 Checking service connectivity..."
    
    local max_retries=3
    local retry_count=0
    
    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 2>&1; 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 2>&1); 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 iterations=3
    local total_time=0
    
    for ((i=1; i<=iterations; 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_code=0
    
    # 安装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_code=1
    test_embedding_api || exit_code=1
    test_similarity || exit_code=1
    performance_test || exit_code=1
    
    # 生成报告
    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_URL"

5. 实际部署与问题排查

配置完成后，让我们看看如何实际部署和可能遇到的问题。

5.1 首次运行配置

1. 推送代码到GitHub：

   git add .github/workflows/health-check.yml scripts/
   git commit -m "Add gte-base-zh health check workflow"
   git push origin main
   

2. 手动触发第一次运行：

   • 进入GitHub仓库的Actions页面
   • 找到"gte-base-zh Health Check"工作流
   • 点击"Run workflow"手动触发

3. 查看运行结果：

   • 点击运行记录查看详细日志
   • 检查每个步骤的输出
   • 确认服务测试是否通过

5.2 常见问题与解决方案

问题1：curl命令超时

错误：curl: (28) Connection timed out after 10001 milliseconds

解决方案：

• 检查服务器防火墙是否开放了9997端口
• 确认服务器IP地址是否正确
• 增加超时时间：curl --max-time 30

问题2：API端点不存在

错误：404 Not Found

解决方案：

• 检查xinference的API文档，确认正确的端点路径
• 使用curl $SERVICE_URL查看可用的端点
• 调整脚本中的API路径

问题3：GitHub Actions无法访问内网服务

错误：无法连接到服务器

解决方案：

• 如果服务在内网，需要设置VPN或使用反向代理
• 考虑使用自托管的GitHub Actions Runner部署在内网
• 或者使用webhook方式，让服务器主动报告健康状态

问题4：邮件通知发送失败

错误：SMTP authentication failed

解决方案：

• 检查邮箱密码是否正确（可能需要应用专用密码）
• 尝试使用其他SMTP服务（如SendGrid、Mailgun）
• 考虑使用其他通知方式（Slack、钉钉等）

5.3 监控与优化建议

一旦健康检查系统运行起来，你还可以考虑以下优化：

1. 分级告警：

   • 轻微问题（响应时间慢）：发送到群聊
   • 严重问题（服务不可用）：@相关人员
   • 紧急问题（完全宕机）：电话通知

2. 历史数据分析：

   - name: Store check results
     if: always()
     run: |
       # 将检查结果存储到数据库或文件
       echo "$(date),${{ steps.connectivity-test.outputs.status }},${{ steps.api-test.outputs.status }}" >> health-history.csv
   

3. 自动化修复：

   - name: Try to restart service on failure
     if: failure() && steps.connectivity-test.outputs.status == 'fail'
     run: |
       # 尝试自动重启服务
       ssh user@server "systemctl restart gte-base-zh"
       sleep 30
       
       # 重新测试
       curl -f $SERVICE_URL && echo "✅ Service restored" || echo "❌ Still failing"
   

6. 总结

通过本文的指南，你应该已经掌握了如何为gte-base-zh服务搭建一个完整的自动化健康检查系统。让我们回顾一下关键点：

6.1 核心价值

1. 自动化监控：告别手动检查，实现7×24小时无人值守监控
2. 即时告警：服务异常时第一时间通知，减少故障影响时间
3. 历史追踪：所有检查结果都有记录，方便问题分析和趋势观察
4. 集成部署：与CI/CD流程无缝集成，确保每次部署后服务正常

6.2 实施步骤总结

1. 确认服务状态：确保gte-base-zh服务已正确部署并运行
2. 创建检查脚本：编写全面的健康检查脚本，覆盖连通性、功能、性能
3. 配置GitHub Actions：设置定时触发的工作流，执行健康检查
4. 添加通知机制：配置邮件、钉钉等告警方式
5. 测试与优化：手动触发测试，根据实际情况调整阈值和频率

6.3 后续扩展方向

这个基础框架还可以进一步扩展：

• 多地域监控：从不同地区测试服务可用性
• 依赖服务检查：同时检查数据库、Redis等依赖服务
• 容量预警：监控服务器资源使用情况，提前预警
• 自动化报表：定期生成服务健康报告，发送给团队

最重要的是，这个方案不仅适用于gte-base-zh，你可以用同样的方法为任何HTTP服务添加健康检查。一次配置，长期受益。

现在就去为你的gte-base-zh服务配置自动化健康检查吧，让运维工作变得更轻松、更可靠！

---

获取更多AI镜像

想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。