从分散巡检到前置运维：Opsx 如何统一接管全域资产健康检查

Asset 提供身份和运行拓扑
  ↓
Schedule 按周期触发确定性检查
  ↓
Shell 执行并计算健康状态
  ↓
结果回写 Asset metadata
  ↓
异常自动进入关联资产的 Issue
  ↓
Agent 读取 Memory、Knowledge 和上下游关系继续诊断

#!/bin/bash
set -euo pipefail

# 1. 负载检查:15 分钟平均负载
LOAD_15=$(uptime | awk -F'load average:' '{print $2}' | awk '{print $3}' | tr -d ',')
CORES=$(nproc)
LOAD_THRESHOLD=$(echo "$CORES * 1.5" | bc)

# 2. 内存检查:已用内存百分比
MEM_TOTAL=$(free -m | grep Mem | awk '{print $2}')
MEM_USED=$(free -m | grep Mem | awk '{print $3}')
MEM_PERCENT=$(echo "scale=2; ($MEM_USED / $MEM_TOTAL) * 100" | bc)

# 3. 磁盘检查:根分区使用率
DISK_ROOT=$(df -h / | tail -1 | awk '{print $5}' | tr -d '%')

# 4. 网络流量:短窗口采样(可选)
# 当前版本主要关注资源容量,流量监控由应用层处理

# 健康状态判断
HEALTH_STATUS="normal"
HEALTH_DETAIL="负载 ${LOAD_15} | 内存 ${MEM_PERCENT}% | 磁盘 ${DISK_ROOT}%"

# Critical: 磁盘 > 90% 或 内存 > 85%
if (( $(echo "$DISK_ROOT > 90" | bc -l) )) || (( $(echo "$MEM_PERCENT > 85.0" | bc -l) )); then
  HEALTH_STATUS="critical"
  HEALTH_DETAIL="[CRITICAL] 磁盘 ${DISK_ROOT}% | 内存 ${MEM_PERCENT}% | 负载 ${LOAD_15}"
# Warning: 磁盘 > 80% 或 内存 > 75%
elif (( $(echo "$DISK_ROOT > 80" | bc -l) )) || (( $(echo "$MEM_PERCENT > 75.0" | bc -l) )); then
  HEALTH_STATUS="warning"
  HEALTH_DETAIL="[WARNING] 磁盘 ${DISK_ROOT}% | 内存 ${MEM_PERCENT}% | 负载 ${LOAD_15}"
fi

echo "Host health check completed: ${HEALTH_STATUS}"
echo "Details: ${HEALTH_DETAIL}"

# 状态回写
CHECKED_AT=$(date -u +%Y-%m-%dT%H:%M:%SZ)

# 构造 JSON payload
PAYLOAD=$(jq -n \
  --arg status "$HEALTH_STATUS" \
  --arg detail "$HEALTH_DETAIL" \
  --arg checked_at "$CHECKED_AT" \
  '{
    metadata: {
      health_status: $status,
      health_detail: $detail,
      last_health_check: $checked_at
    }
  }')

# 通过 Opsx API 更新资产元数据
# OPSX_API_BASE 和认证由 Runtime 的受控配置提供
curl --fail --silent --show-error --max-time 10 \
  -X PATCH "${OPSX_API_BASE}/assets/${ASSET_ID}" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer ${OPSX_API_TOKEN}" \
  --data-binary "$PAYLOAD"

# 如果状态为 critical,自动创建高优先级 Issue
if [ "$HEALTH_STATUS" = "critical" ]; then
  echo "Critical status detected, creating issue..."
  # Issue 创建逻辑由 Schedule 的后置处理器触发
fi

{
  "asset_id": "asset_host_moapp_0002",
  "type": "host",
  "name": "host-moapp-0002",
  "metadata": {
    "health_status": "warning",
    "health_detail": "[WARNING] 磁盘 84% | 内存 73% | 负载 1.24",
    "last_health_check": "2026-08-26T00:00:15Z"
  }
}

#!/bin/bash
set -euo pipefail

HEALTH_STATUS="normal"
HEALTH_ISSUES=()

# 1. 连通性与版本
VERSION=$(gsql -d postgres -p "${DB_PORT}" -c "SELECT version();" -t 2>/dev/null | head -1 || echo "FAILED")
if [[ "$VERSION" == "FAILED" ]]; then
  HEALTH_STATUS="critical"
  HEALTH_ISSUES+=("连接失败")
  echo "Database connection failed"
  exit 1
fi

# 2. 连接数使用率
MAX_CONN=$(gsql -d postgres -p "${DB_PORT}" -t -c "SHOW max_connections;" | xargs)
CUR_CONN=$(gsql -d postgres -p "${DB_PORT}" -t -c "SELECT count(*) FROM pg_stat_activity;" | xargs)
CONN_PERCENT=$(echo "scale=2; ($CUR_CONN / $MAX_CONN) * 100" | bc)

if (( $(echo "$CONN_PERCENT > 80.0" | bc -l) )); then
  HEALTH_STATUS="warning"
  HEALTH_ISSUES+=("连接数使用率 ${CONN_PERCENT}%")
fi

# 3. 长事务检查:超过 30 分钟的活跃事务
LONG_TX=$(gsql -d postgres -p "${DB_PORT}" -t -c "
  SELECT count(*) 
  FROM pg_stat_activity 
  WHERE state = 'active' 
    AND now() - xact_start > interval '30 minutes';
" | xargs)

if [ "$LONG_TX" -gt 0 ]; then
  HEALTH_STATUS="warning"
  HEALTH_ISSUES+=("${LONG_TX} 个长事务")
fi

# 4. 错误日志检查:近一小时的 ERROR/FATAL
ERROR_LOG="${DB_LOG_DIR}/postgresql-$(date +%Y-%m-%d).log"
if [ -f "$ERROR_LOG" ]; then
  ONE_HOUR_AGO=$(date -u -d '1 hour ago' +%Y-%m-%d\ %H:%M:%S)
  ERROR_COUNT=$(grep -E "ERROR|FATAL" "$ERROR_LOG" | \
    awk -v cutoff="$ONE_HOUR_AGO" '$1 " " $2 >= cutoff' | wc -l)
  
  if [ "$ERROR_COUNT" -gt 10 ]; then
    HEALTH_STATUS="critical"
    HEALTH_ISSUES+=("近一小时 ${ERROR_COUNT} 条错误日志")
  fi
fi

# 5. 主备角色与延迟(仅备库)
ROLE=$(gsql -d postgres -p "${DB_PORT}" -t -c "SELECT pg_is_in_recovery();" | xargs)
if [ "$ROLE" = "t" ]; then
  # 这是备库,检查回放延迟
  REPL_DELAY=$(gsql -d postgres -p "${DB_PORT}" -t -c "
    SELECT EXTRACT(EPOCH FROM (now() - pg_last_xact_replay_timestamp()));
  " | xargs)
  
  if (( $(echo "$REPL_DELAY > 300" | bc -l) )); then
    HEALTH_STATUS="warning"
    HEALTH_ISSUES+=("备库延迟 ${REPL_DELAY}s")
  fi
fi

# 构造健康详情
if [ ${#HEALTH_ISSUES[@]} -eq 0 ]; then
  HEALTH_DETAIL="连接数 ${CUR_CONN}/${MAX_CONN} | 无长事务 | 无重大错误"
else
  HEALTH_DETAIL=$(IFS=' | '; echo "${HEALTH_ISSUES[*]}")
fi

echo "MogDB health check completed: ${HEALTH_STATUS}"
echo "Details: ${HEALTH_DETAIL}"

CHECKED_AT=$(date -u +%Y-%m-%dT%H:%M:%SZ)

PAYLOAD=$(jq -n \
  --arg status "$HEALTH_STATUS" \
  --arg detail "$HEALTH_DETAIL" \
  --arg checked_at "$CHECKED_AT" \
  '{
    metadata: {
      health_status: $status,
      health_detail: $detail,
      last_health_check: $checked_at
    }
  }')

curl --fail --silent --show-error --max-time 10 \
  -X PATCH "${OPSX_API_BASE}/assets/${ASSET_ID}" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer ${OPSX_API_TOKEN}" \
  --data-binary "$PAYLOAD"

# 清理 30 天前的应用日志
find /var/log/emcs-app/ -name "*.log.*" -mtime +30 -delete

# 验证清理结果
du -sh /var/log/emcs-app/
df -h /

Schedule 发现异常
  → 回写 Asset 健康状态(critical)
  → 自动创建关联资产的 Issue
  → Issue 携带异常摘要、检查时间和目标资产
  → Agent 读取 Asset Memory 和上下游关系
  → 在正确的 Runtime 上执行只读诊断
  → 提供清理方案并等待人的授权
  → 执行后验证结果,下次巡检恢复正常

Shell             → 确定性规则、快速执行、不消耗 Token
Agent + LLM       → 复杂推理、证据比较、方案生成
Asset + Knowledge → 为两者提供确定性上下文
Human             → 业务判断、风险审批、规则设计

Schedule 发现 critical
  → 自动创建 Issue
  → Agent 读取 Asset Memory、Knowledge 和上下游关系
  → 收集只读证据:日志、配置、资源使用、历史趋势
  → 生成诊断报告和处置建议
  → 人确认方案、风险和回退方式
  → 执行并验证结果
  → 过程和结论沉淀为 Knowledge 或 Playbook

Schedule 发现 critical
  → 自动创建 Issue
  → Agent 读取相关 Knowledge 和 Playbook
  → 比对当前证据与历史模式
  → 如果匹配已知场景,提示"可以使用 Playbook XYZ"
  → 人审核 Playbook 是否适用
  → 一键执行多步骤处置
  → 验证结果并更新 Playbook

Schedule 发现 critical
  → 读取对应 Knowledge 和 Playbook
  → 验证前置条件(资产状态、影响范围、执行权限)
  → 自动执行 Playbook
  → 每一步验证中间状态
  → 遇到预期外结果时停止并创建 Issue
  → 执行成功后验证最终结果
  → 更新 Asset 健康状态和执行记录

第一次:人 + Agent 共同诊断,沉淀经验
  ↓
第二次:Agent 提示可用 Playbook,人审核后执行
  ↓
第三次及以后:符合条件时自动执行,异常时升级