📚 课程目录第3章巡检脚本基础

Runbook联动场景容量压测巡检脚本编排优化 - 第3节

3.1 巡检脚本的定义与核心要素

巡检脚本是用于自动执行系统健康检查、状态采集、阈值判定与结果输出的可执行指令集合。在容量压测场景中，巡检脚本承担着“哨兵”角色，在压测前、中、后三个阶段持续验证系统状态是否符合预期。

  定义要点：巡检脚本 = 检查逻辑 + 判定规则 + 输出格式 + 执行策略。它不直接干预业务流量，而是通过采集指标、比对基线、生成报告来辅助运维决策。

3.1.1 巡检脚本的组成结构

组成要素	说明	容量压测场景示例
采集模块	从目标系统获取指标数据	通过 Prometheus API 拉取 CPU/内存/网络 IO
判定模块	将采集值与预设阈值或基线对比	检查 QPS 是否超过压测目标值的 80%
输出模块	格式化结果并写入日志/告警/报告	输出 JSON 格式巡检报告，推送至 Elasticsearch
执行策略	定义触发方式与重试/超时逻辑	每 30 秒执行一次，超时 10 秒，失败重试 2 次

# 巡检脚本最小示例（Python）
import requests
import json

def check_node_health(node_ip):
    # 采集
    cpu = requests.get(f"http://{node_ip}:9100/metrics", timeout=5)
    # 判定
    cpu_usage = parse_cpu(cpu.text)
    status = "PASS" if cpu_usage < 80 else "FAIL"
    # 输出
    return {"node": node_ip, "cpu": cpu_usage, "status": status}

result = check_node_health("10.0.1.10")
print(json.dumps(result, indent=2))

3.2 巡检与监控的核心区别

巡检和监控是运维可观测性的两个互补维度，但存在本质差异。在容量压测 Runbook 中，两者分工明确：监控负责持续感知，巡检负责定向验证。

对比维度	监控	巡检
触发方式	持续采集，被动接收	按计划或事件主动执行
数据粒度	高频率（秒级），全量数据	按需采样，聚焦关键指标
判定逻辑	基于动态阈值/异常检测	基于固定阈值/基线比对
输出形式	仪表盘、告警、时间序列	结构化报告、检查清单
典型场景	实时发现故障、趋势分析	变更前验证、压测前准入
资源消耗	较高（常驻进程）	较低（按需执行）

实践建议：在容量压测 Runbook 中，监控用于压测期间的实时水位感知，巡检用于压测前的环境准入检查和压测后的结果验证。两者配合使用，避免重复建设。

3.3 巡检脚本的常见模式

根据触发方式的不同，巡检脚本可分为定时触发和事件触发两种基本模式。在容量压测场景中，两种模式往往组合使用，形成“定时基线巡检 + 事件驱动深度巡检”的混合策略。

3.3.1 定时触发模式

定时触发是最常见的巡检模式，通过 cron 表达式或调度器按固定周期执行。适用于环境基线检查、资源水位周期性扫描等场景。

适用场景：压测前每 5 分钟检查一次集群节点状态；压测期间每 30 秒采集一次关键指标。
实现方式：Linux cron、Kubernetes CronJob、Airflow 定时 DAG、自定义调度器。
优点：执行周期可预测，便于与压测阶段对齐。
缺点：无法响应突发状态变化，存在检查盲区。

# Kubernetes CronJob 示例：每 5 分钟执行一次巡检
apiVersion: batch/v1
kind: CronJob
metadata:
  name: capacity-check
spec:
  schedule: "*/5 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: checker
            image: registry/checker:1.0
            command: ["python", "/scripts/check_capacity.py"]
          restartPolicy: OnFailure

3.3.2 事件触发模式

事件触发模式在特定事件发生时启动巡检，响应速度快，资源利用率高。适用于压测开始/结束、告警触发、变更完成等场景。

适用场景：压测启动时触发全量环境巡检；收到 CPU 告警时触发深度诊断巡检。
实现方式：Webhook 回调、消息队列订阅、Kubernetes Watch API、事件总线（如 Kafka）。
优点：精准响应，避免无效检查。
缺点：依赖事件源可靠性，事件丢失可能导致巡检遗漏。

# 事件触发巡检伪代码（基于 Redis Pub/Sub）
import redis

def on_pressure_start(event):
    # 压测开始事件触发全量巡检
    run_full_check()

def on_alert_triggered(event):
    # 告警事件触发专项巡检
    run_deep_check(event['metric'])

r = redis.Redis()
p = r.pubsub()
p.subscribe(**{
    'pressure:start': on_pressure_start,
    'alert:triggered': on_alert_triggered
})
p.run_in_thread(sleep_time=0.1)

3.3.3 混合模式：定时 + 事件组合

在容量压测 Runbook 中，推荐采用混合模式：定时巡检作为基线保障，事件巡检作为深度补充。以下是一个典型的组合策略：

巡检阶段	触发方式	检查内容	执行频率
压测前准入	事件触发（压测开始事件）	节点存活、磁盘空间、网络延迟、证书有效期	每次压测启动时
压测中水位	定时触发	CPU/内存/连接数/错误率	每 10 秒
压测后验证	事件触发（压测结束事件）	数据一致性、服务恢复、资源释放	每次压测结束时
环境基线扫描	定时触发	全量节点健康、配置漂移检测	每 30 分钟

注意：混合模式下需避免巡检脚本之间的冲突。例如，定时巡检正在执行时，事件巡检被触发，应通过锁机制或队列控制并发，防止重复检查或资源争抢。

3.4 巡检脚本编排优化原则

在容量压测 Runbook 中，巡检脚本的编排需要遵循以下原则，以确保高效、可靠、可维护：

幂等性：同一脚本多次执行结果一致，不产生副作用。
超时控制：每个巡检步骤设置合理超时，避免阻塞后续流程。
结果可追溯：每次巡检输出唯一 ID、时间戳、执行节点、检查项列表。
分级告警：根据巡检结果严重程度，触发不同级别的告警或阻断动作。
配置外部化：阈值、检查列表、目标地址等参数从配置文件或配置中心读取。

# 巡检脚本编排示例（YAML 配置）
checks:
  - name: node_health
    type: http
    target: "http://{{node_ip}}:9100/metrics"
    interval: 30s
    timeout: 5s
    threshold:
      cpu: 80
      memory: 90
    on_fail: warn

  - name: disk_space
    type: ssh
    target: "{{node_ip}}"
    command: "df -h / | tail -1"
    interval: 5m
    timeout: 10s
    threshold:
      used_percent: 85
    on_fail: critical