

CLB摘掉了异常后端，然后呢？

我们跑在腾讯云上的业务用的是CLB四层+七层混合转发，后端挂了8台CVM做Web服务。CLB自带的健康检查是好用的——后端某台CVM进程挂了，30秒内就能探测到并自动摘除，流量不再转发过去。

但"摘除"只是自动化的第一步。实际运营中暴露了三个问题：

1. **没人知道少了一台**：CLB摘掉一台CVM后不主动通知任何人，运维团队不知道后端少了一个节点在跑
2. **剩余容量没人评估**：8台变7台可能还行，但如果连续挂两台（比如同时OOM），剩6台在高峰期可能顶不住
3. **恢复要人工操作**：异常CVM需要人手动排查→修复→重新注册到CLB，夜间没人盯就一直少一台

> **核心观点：CLB健康检查只解决了"故障隔离"，但"故障感知→容量补位→事件追溯"这三层需要云监控CM、弹性伸缩AS、云函数SCF配合才能形成完整闭环。**

下面是我们跑通的链路配置。

![Gemini_Generated_Image_s39wcis39wcis39w.png](https://developer.qcloudimg.com/http-save/yehe-12466791/738787e9d7f530547a7e05648e6cce5f.png)

---

## 一、整体架构：四段联动闭环

```
CLB健康检查（30s探测）
    ↓ 异常CVM自动摘除
云监控CM（检测到后端健康数下降）
    ↓ 触发告警策略
分级通知（P1电话+企业微信 / P2企业微信）
    ↓ 同时触发
弹性伸缩AS（自动新增CVM + 注册到CLB后端）
    ↓ 同时触发
云函数SCF（创建事件工单 + 记录上下文）
```

四段的职责边界清晰：
- **CLB**：负责"摘掉坏的"（故障隔离）
- **CM**：负责"告诉人"（故障感知）
- **AS**：负责"补一个新的"（容量自愈）
- **SCF**：负责"记下来"（事件追溯）

---

## 二、CLB健康检查配置（基础层）

### 2.1 七层监听器（HTTP）健康检查

```json
// CLB API 配置参数（也可在控制台配置）
{
    "LoadBalancerId": "lb-xxxxxxxx",
    "ListenerId": "lbl-xxxxxxxx",
    "HealthCheck": {
        "HealthSwitch": 1,
        "TimeOut": 5,
        "IntervalTime": 30,
        "HealthNum": 3,
        "UnHealthNum": 3,
        "HttpCode": 200,
        "HttpCheckPath": "/health",
        "HttpCheckDomain": "",
        "HttpCheckMethod": "GET"
    }
}
```

参数含义：

| 参数 | 值 | 说明 |
|------|-----|------|
| IntervalTime | 30秒 | 每30秒探测一次 |
| TimeOut | 5秒 | 探测超时时间 |
| UnHealthNum | 3 | 连续3次失败判定为异常（即90秒后摘除） |
| HealthNum | 3 | 连续3次成功判定为恢复 |
| HttpCheckPath | /health | 健康检查探测路径 |
| HttpCode | 200 | 期望返回200才算健康 |

### 2.2 后端服务的健康检查端点

```python
# Flask示例 - /health端点
from flask import Flask, jsonify
import psutil
import pymysql

app = Flask(__name__)

@app.route('/health')
def health_check():
    checks = {}
    
    # 检查1：进程自身存活（能响应就算过）
    checks['process'] = True
    
    # 检查2：数据库连接可用
    try:
        conn = pymysql.connect(host='10.0.1.50', port=3306, 
                               user='health_check', password='xxx',
                               connect_timeout=3)
        conn.ping()
        conn.close()
        checks['mysql'] = True
    except Exception:
        checks['mysql'] = False
    
    # 检查3：磁盘空间>10%
    disk = psutil.disk_usage('/')
    checks['disk'] = disk.percent < 90
    
    # 任一关键检查失败 → 返回503让CLB摘除
    if not all([checks['mysql'], checks['disk']]):
        return jsonify({"status": "unhealthy", "checks": checks}), 503
    
    return jsonify({"status": "healthy", "checks": checks}), 200
```

**关键设计**：健康检查端点不只检查"进程活着"，而是检查"能正常服务"——数据库连不上、磁盘满了都应该让CLB主动摘除，避免用户请求打到一个实际不能用的节点上。

---

## 三、云监控CM告警策略（感知层）

CLB摘除CVM后，云监控CM能检测到两个核心指标变化：

1. **CLB后端健康主机数**（`LbRsHealthHostCount`）——下降意味着有后端被摘掉了
2. **CLB后端异常主机数**（`LbRsUnHealthHostCount`）——上升意味着有故障

### 3.1 创建告警策略

```bash
# 使用腾讯云CLI创建告警策略
# 策略1：健康后端数低于阈值（高优先级）

tccli monitor CreateAlarmPolicy --cli-unfold-argument \
    --Module monitor \
    --PolicyName "CLB后端健康数不足-P1" \
    --MonitorType MT_QCE \
    --Namespace QCE/LB_PUBLIC \
    --Remark "CLB后端健康CVM数<=6时触发P1告警" \
    --Conditions.0.MetricName LbRsHealthHostCount \
    --Conditions.0.Period 60 \
    --Conditions.0.Operator le \
    --Conditions.0.Value 6 \
    --Conditions.0.ContinuePeriod 1 \
    --NoticeIds "notice-p1-phone-wechat"
```

```bash
# 策略2：出现异常后端（中优先级）

tccli monitor CreateAlarmPolicy --cli-unfold-argument \
    --Module monitor \
    --PolicyName "CLB出现异常后端-P2" \
    --MonitorType MT_QCE \
    --Namespace QCE/LB_PUBLIC \
    --Remark "CLB后端异常CVM数>=1时触发P2告警" \
    --Conditions.0.MetricName LbRsUnHealthHostCount \
    --Conditions.0.Period 60 \
    --Conditions.0.Operator ge \
    --Conditions.0.Value 1 \
    --Conditions.0.ContinuePeriod 2 \
    --NoticeIds "notice-p2-wechat"
```

### 3.2 分级通知策略

| 级别 | 触发条件 | 通知方式 | 通知对象 |
|------|---------|---------|---------|
| P1（严重） | 健康后端 ≤ 6台（总8台，挂了2+台） | 电话 + 企业微信 | 值班运维 + 运维主管 |
| P2（警告） | 异常后端 ≥ 1台 | 企业微信机器人 | 值班运维群 |
| P3（提示） | 健康后端恢复到8台 | 企业微信 | 值班运维群（恢复确认） |

通知模板（企业微信机器人）：

```python
# 云函数SCF中的通知格式化
def format_alert_message(alert_data):
    """格式化CM告警为企业微信Markdown消息"""
    severity_map = {
        "CLB后端健康数不足-P1": "🔴 P1-严重",
        "CLB出现异常后端-P2": "🟡 P2-警告",
    }
    
    policy_name = alert_data.get("policyName", "未知策略")
    severity = severity_map.get(policy_name, "⚪ 未知")
    
    message = f"""## {severity}：{policy_name}

> **触发时间**：{alert_data.get('firstOccurTime')}
> **实例**：{alert_data.get('dimensions', {}).get('LoadBalancerId')}
> **当前值**：{alert_data.get('currentValue')}
> **阈值**：{alert_data.get('calcValue')}

**影响范围**：
- CLB实例：{alert_data.get('dimensions', {}).get('LoadBalancerId')}
- 当前健康后端数：{alert_data.get('currentValue')}
- 总后端数：8

**自动处置状态**：
- ✅ CLB已自动摘除异常CVM
- ✅ 弹性伸缩已触发扩容（预计3分钟内完成）
- ⏳ 异常CVM待人工排查

**操作链接**：
- [CLB控制台](https://console.cloud.tencent.com/clb)
- [弹性伸缩控制台](https://console.cloud.tencent.com/autoscaling)
"""
    return message
```

---

## 四、弹性伸缩AS自动补位（自愈层）

光告警不够——如果凌晨3点挂了一台，等运维起来再处理已经扛了几小时高负载。弹性伸缩AS可以在CLB后端减少时自动补充新CVM。

### 4.1 创建伸缩组

```bash
# 伸缩组绑定到CLB的后端服务器组
tccli as CreateAutoScalingGroup --cli-unfold-argument \
    --AutoScalingGroupName "web-service-asg" \
    --LaunchConfigurationId "asc-xxxxxxxx" \
    --MinSize 6 \
    --MaxSize 12 \
    --DesiredCapacity 8 \
    --VpcId "vpc-xxxxxxxx" \
    --SubnetIds '["subnet-xxx1","subnet-xxx2"]' \
    --ForwardLoadBalancers.0.LoadBalancerId "lb-xxxxxxxx" \
    --ForwardLoadBalancers.0.ListenerId "lbl-xxxxxxxx" \
    --ForwardLoadBalancers.0.LocationId "loc-xxxxxxxx" \
    --ForwardLoadBalancers.0.TargetAttributes.0.Port 8080 \
    --ForwardLoadBalancers.0.TargetAttributes.0.Weight 10 \
    --HealthCheckType CLB \
    --LoadBalancerHealthCheckGracePeriod 120
```

关键参数说明：

| 参数 | 值 | 含义 |
|------|-----|------|
| MinSize | 6 | 最少保持6台，防止缩容过度 |
| MaxSize | 12 | 最多12台，控制成本上限 |
| DesiredCapacity | 8 | 期望8台正常运行 |
| HealthCheckType | CLB | 使用CLB健康检查结果判断实例是否健康 |
| LoadBalancerHealthCheckGracePeriod | 120 | 新实例注册后120秒内不做健康检查（给启动时间） |

### 4.2 伸缩策略：基于CM告警触发

```bash
# 扩容策略：CM检测到健康后端<8时，新增1台
tccli as CreateScalingPolicy --cli-unfold-argument \
    --AutoScalingGroupId "asg-xxxxxxxx" \
    --ScalingPolicyName "scale-out-on-unhealthy" \
    --AdjustmentType CHANGE_IN_CAPACITY \
    --AdjustmentValue 1 \
    --MetricAlarm.ComparisonOperator LESS_THAN \
    --MetricAlarm.MetricName "LB_RS_HEALTH_HOST_COUNT" \
    --MetricAlarm.Threshold 8 \
    --MetricAlarm.Period 60 \
    --MetricAlarm.ContinuousTime 1 \
    --Cooldown 300
```

```bash
# 缩容策略：所有后端都健康且CPU<30%时，减少1台（避免无限扩）
tccli as CreateScalingPolicy --cli-unfold-argument \
    --AutoScalingGroupId "asg-xxxxxxxx" \
    --ScalingPolicyName "scale-in-on-idle" \
    --AdjustmentType CHANGE_IN_CAPACITY \
    --AdjustmentValue -1 \
    --MetricAlarm.ComparisonOperator LESS_THAN \
    --MetricAlarm.MetricName "CPU_USAGE" \
    --MetricAlarm.Threshold 30 \
    --MetricAlarm.Period 300 \
    --MetricAlarm.ContinuousTime 3 \
    --Cooldown 600
```

### 4.3 启动配置（新CVM自动初始化）

新扩容的CVM需要自动完成：装软件→拉代码→启动服务→注册到CLB。

```bash
#!/bin/bash
# 启动配置中的UserData脚本（Base64编码后放入LaunchConfiguration）

# 1. 安装运行环境
yum install -y python3 python3-pip nginx
pip3 install flask gunicorn pymysql psutil

# 2. 从COS拉取最新代码包
wget -O /opt/app/release.tar.gz \
  "https://cos.ap-guangzhou.myqcloud.com/deploy-bucket/web-service/latest/release.tar.gz"
tar -xzf /opt/app/release.tar.gz -C /opt/app/

# 3. 启动服务
cd /opt/app && gunicorn -w 4 -b 0.0.0.0:8080 app:app --daemon

# 4. 等待服务就绪
for i in {1..30}; do
    if curl -s http://localhost:8080/health | grep -q "healthy"; then
        echo "Service is ready"
        break
    fi
    sleep 2
done

# 5. 输出就绪信号（CLB健康检查会在GracePeriod后开始探测）
echo "$(date) CVM initialized successfully" >> /var/log/init.log
```

---

## 五、云函数SCF事件记录（追溯层）

告警触发后，我们用SCF云函数自动记录事件上下文，方便后续排查和复盘。

```python
# SCF云函数：clb_alert_handler
# 触发方式：CM告警回调 → API网关 → SCF

import json
import datetime
import urllib.request
from tencentcloud.common import credential
from tencentcloud.cvm.v20170312 import cvm_client, models as cvm_models

# 企业微信机器人Webhook
WECHAT_WEBHOOK = "https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=YOUR_KEY"

def main_handler(event, context):
    """处理CM告警回调"""
    
    # 解析告警数据
    body = json.loads(event.get('body', '{}'))
    alert_status = body.get('alarmStatus', '')  # 1=告警 0=恢复
    policy_name = body.get('alarmPolicyInfo', {}).get('policyName', '')
    dimensions = body.get('alarmObjInfo', {}).get('dimensions', {})
    current_value = body.get('alarmObjInfo', {}).get('currentValue', '')
    
    # 构造事件记录
    event_record = {
        "event_time": datetime.datetime.now().isoformat(),
        "event_type": "clb_backend_unhealthy",
        "severity": "P1" if "P1" in policy_name else "P2",
        "clb_instance": dimensions.get('LoadBalancerId', ''),
        "current_healthy_count": current_value,
        "alert_status": "triggered" if alert_status == "1" else "recovered",
        "auto_actions": [
            "CLB已自动摘除异常后端",
            "弹性伸缩已触发扩容策略",
            "告警通知已发送"
        ]
    }
    
    # 如果是告警触发（非恢复），获取异常CVM信息
    if alert_status == "1":
        unhealthy_cvms = get_unhealthy_backends(dimensions.get('LoadBalancerId'))
        event_record["unhealthy_instances"] = unhealthy_cvms
        
        # 发送企业微信通知
        send_wechat_notification(event_record)
    
    # 记录到CLS日志（用于后续查询和复盘）
    print(json.dumps(event_record, ensure_ascii=False))
    
    return {
        "statusCode": 200,
        "body": json.dumps({"message": "Alert processed", "event": event_record})
    }


def get_unhealthy_backends(lb_id):
    """查询CLB当前异常后端列表"""
    # 调用CLB DescribeTargetHealth接口
    # 返回异常实例ID列表
    return []  # 实际实现省略，参考CLB API文档


def send_wechat_notification(event_record):
    """发送企业微信告警通知"""
    severity_emoji = "🔴" if event_record["severity"] == "P1" else "🟡"
    
    message = {
        "msgtype": "markdown",
        "markdown": {
            "content": f"""{severity_emoji} **CLB后端异常告警**

> 时间：{event_record['event_time']}
> CLB：{event_record['clb_instance']}
> 当前健康后端数：{event_record['current_healthy_count']}

**自动处置**：
- ✅ 异常CVM已从CLB摘除
- ✅ 弹性伸缩已触发补位
- ⏳ 异常CVM待排查

请值班人员确认扩容完成并排查异常实例。"""
        }
    }
    
    req = urllib.request.Request(
        WECHAT_WEBHOOK,
        data=json.dumps(message).encode('utf-8'),
        headers={'Content-Type': 'application/json'}
    )
    urllib.request.urlopen(req)
```

---

## 六、实际运行效果

这套闭环跑了2个月，几个关键数据：

| 指标 | 之前（纯CLB健康检查） | 之后（四段联动） |
|------|---------------------|----------------|
| 故障感知时间 | 不确定（可能几小时后看监控才发现少节点） | 90秒内告警通知 |
| 容量恢复时间 | 人工排查+重启+注册（平均45分钟） | 自动扩容补位（3分钟） |
| 夜间故障影响 | 第二天早上才发现、已经扛了一夜低容量 | 自动补位+告警通知值班 |
| 事件可追溯性 | 无记录，靠聊天记录还原 | SCF自动记录事件上下文+时间线 |
| 月均人工干预次数 | 12次（每次要手动操作CLB） | 3次（只处理无法自愈的根因） |

### 踩坑记录

**坑1：弹性伸缩和CLB健康检查的时序冲突**

新CVM通过AS注册到CLB后，CLB立即开始健康检查，但此时CVM的服务还没启动完（在跑UserData脚本），连续3次不健康直接被摘掉→触发AS再扩一台→无限循环。

解决：`LoadBalancerHealthCheckGracePeriod` 设为120秒（给足启动时间），UserData脚本里加就绪检测循环。

**坑2：缩容时踢掉了正在处理请求的CVM**

AS缩容时直接从CLB摘除CVM，正在处理的长连接被中断。

解决：AS配置中开启"优雅停机"（`InstanceTerminationPolicy`设为`OLDEST_INSTANCE`），且CLB侧配置连接排水（Deregistration Delay = 30s）。

**坑3：CM告警恢复通知太多**

临时网络抖动导致CLB健康检查失败→告警→30秒后恢复→恢复通知。一晚上收到十几条"告警-恢复"交替通知。

解决：CM告警策略中设置 `ContinuePeriod = 2`（连续2个周期才触发），滤掉单次探测失败的噪声。

---

## 七、和运维管理体系的打通

四段联动解决了"自动化处置"，但有一类问题自动化解决不了：根因排查。CVM为什么挂了？是OOM？磁盘满？还是代码bug？这些需要人去处理，且处理过程需要记录。

我们实际项目里通过SCF在告警触发时同步往冠服云EMS平台创建一条事件工单——工单里自动填入CLB实例ID、异常CVM ID、告警时间、当时的监控快照链接（CM的指标图表URL）。值班人员收到企业微信通知后点开工单就能看到完整上下文，排查完在工单里记录根因和处理方式，关闭工单自动归档。下次同类故障再发生，新工单会关联到历史处理记录，不需要从零排查。

---

## 小结

CLB健康检查是故障隔离的起点，但离"故障自愈"还差三步：

1. **感知**（云监控CM）：后端被摘除了 → 1分钟内让人知道
2. **自愈**（弹性伸缩AS）：少了一台 → 3分钟内自动补一台
3. **追溯**（SCF + 工单）：为什么挂的 → 有记录、能复盘、能关联

四段联动的投入成本几乎为零——CLB、CM、AS、SCF都是腾讯云原生服务，配置一次长期生效，没有额外的运维组件要维护。

我们跑在腾讯云上的业务用的是CLB四层+七层混合转发，后端挂了8台CVM做Web服务。CLB自带的健康检查是好用的——后端某台CVM进程挂了，30秒内就能探测到并自动摘除，流量不再转发过去。

腾讯云CLB健康检查+云监控CM告警联动实战：后端CVM异常自动摘除+分级告警通知+弹性伸缩自动扩容完整方案

CLB的健康检查能摘掉异常后端，但它不告诉你"为什么挂了"、不告诉你"剩余容量够不够"、不帮你扩容补位。本文记录我们把CLB健康检查→云监控CM告警→企业微信分级通知→弹性伸缩AS自动补位串成完整闭环的过程——从"摘掉一台等人处理"变成"摘掉→告警→自动扩容→工单跟进"全自动链路，含CLB配置、CM告警策略、AS伸缩规则、云函数SCF通知编排完整代码。

产品经理

云计算

后端

运维

CLB健康检查能自动摘除故障后端，但存在故障感知滞后、容量不足风险和人工恢复效率低的问题。通过云监控CM实时告警、弹性伸缩AS自动扩容补位、云函数SCF事件记录，形成故障隔离→感知→自愈→追溯的完整闭环。实际运行表明，故障感知时间从数小时缩短至90秒内，容量恢复时间从45分钟降至3分钟，大幅提升业务稳定性和运维效率。

弹性伸缩

云监控

数据库

服务器

云函数

云原生

Python

JSON

2026年中大促 | AI 领航 智绘未来

4核4G3M云服务器 新用户低至38元/年！

tcpm

对象存储COS新用户低至1元！


cngw

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

腾讯云CLB健康检查+云监控CM告警联动实战：后端CVM异常自动摘除+分级告警通知+弹性伸缩自动扩容完整方案-腾讯云开发者社区-腾讯云

腾讯云CLB健康检查+云监控CM告警联动实战：后端CVM异常自动摘除+分级告警通知+弹性伸缩自动扩容完整方案

腾讯云CLB健康检查+云监控CM告警联动实战：后端CVM异常自动摘除+分级告警通知+弹性伸缩自动扩容完整方案

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐