Imported from wanghel2020/linux-perf-check (SKILL.md). Install upstream with npx skills add wanghel2020/linux-perf-check. Copyright stays with the author.

Linux 服务器全量巡检技能

功能概述

通过SSH远程连接Linux服务器，自动收集系统指标（含数据库深度诊断），生成专业巡检报告。覆盖基础巡检 14 项 + Java 宕机诊断 + 数据库深度诊断（MySQL/PostgreSQL/Oracle 三大库，共 10 个数据库专用模块）。

支持两种模式：

• 单机巡检：指定单台服务器直接巡检
• 批量巡检：通过 inventory.json 服务器清单，并发巡检多台服务器，生成汇总报告

巡检覆盖范围（14大类）

认证方式

方式1：SSH密钥认证（推荐）

# 生成密钥
ssh-keygen -t ed25519 -C "workbuddy-inspection" -f ~/.ssh/id_ed25519_workbuddy

# 上传公钥
ssh-copy-id -i ~/.ssh/id_ed25519_workbuddy.pub root@<服务器IP>

# 验证
ssh -i ~/.ssh/id_ed25519_workbuddy root@<服务器IP>

方式2：密码认证

每次巡检时提供：服务器IP、SSH端口、用户名、密码。

使用方法

单机巡检

# 全量巡检（密码认证）— 一键跑全部模块，默认5线程并发
python ~/.workbuddy/skills/linux-perf-check/scripts/linux_inspection.py \
  --host <IP> --user root --password <密码> --check all

# 全量巡检（密钥认证）
python ~/.workbuddy/skills/linux-perf-check/scripts/linux_inspection.py \
  --host <IP> --user root --key ~/.ssh/id_ed25519_workbuddy --check all

# 指定模块巡检
python ~/.workbuddy/skills/linux-perf-check/scripts/linux_inspection.py \
  --host <IP> --user root --password <密码> \
  --check cpu,memory,disk,alert

# 调优并发（加快巡检速度）
python ~/.workbuddy/skills/linux-perf-check/scripts/linux_inspection.py \
  --host <IP> --user root --password <密码> --check all \
  --module-workers 8 --module-timeout 60

# 保存报告
python ~/.workbuddy/skills/linux-perf-check/scripts/linux_inspection.py \
  --host <IP> --user root --password <密码> \
  -o /path/to/report.txt --json-output /path/to/report.json

批量巡检

1. 编辑服务器清单

编辑 ~/.workbuddy/skills/linux-perf-check/inventory.json，添加需要巡检的服务器：

{
  "servers": [
    {
      "alias": "生产服务器-MySQL",
      "host": "192.168.26.66",
      "port": 22,
      "user": "root",
      "auth": { "type": "password", "value": "redhat" },
      "enabled": true,
      "tags": ["生产", "MySQL"]
    },
    {
      "alias": "测试服务器",
      "host": "192.168.26.100",
      "port": 22,
      "user": "root",
      "auth": { "type": "key", "value": "~/.ssh/id_ed25519_workbuddy" },
      "enabled": true,
      "tags": ["测试"]
    }
  ],
  "settings": {
    "check_modules": "all",
    "timeout": 120,
    "workers": 3,
    "module_workers": 5,
    "module_timeout": null,
    "output_dir": "./reports",
    "generate_html": true
  }
}

2. 执行批量巡检

# 基本批量巡检
python ~/.workbuddy/skills/linux-perf-check/scripts/linux_inspection.py \
  --inventory ~/.workbuddy/skills/linux-perf-check/inventory.json

# 指定并发数 + 生成HTML报告
python ~/.workbuddy/skills/linux-perf-check/scripts/linux_inspection.py \
  --inventory ~/.workbuddy/skills/linux-perf-check/inventory.json \
  --workers 5 --html

# 只巡检关键指标（快速）
python ~/.workbuddy/skills/linux-perf-check/scripts/linux_inspection.py \
  --inventory ~/.workbuddy/skills/linux-perf-check/inventory.json \
  --check cpu,memory,disk,alert

# 指定输出目录
python ~/.workbuddy/skills/linux-perf-check/scripts/linux_inspection.py \
  --inventory ~/.workbuddy/skills/linux-perf-check/inventory.json \
  --output-dir /path/to/reports --html

inventory.json 字段说明

settings 字段说明

批量巡检输出

批量巡检会在输出目录生成以下文件：

reports/
├── 192_168_26_66_20260521_134500.txt       # 单台文本报告
├── 192_168_26_66_20260521_134500.json      # 单台JSON报告
├── 192_168_26_100_20260521_134500.txt
├── 192_168_26_100_20260521_134500.json
├── batch_summary_20260521_134500.txt       # 汇总文本报告
└── batch_report_20260521_134500.html       # 汇总HTML报告

--check 模块速查

• SSH：仅需 SSH 凭证即可运行
• ⚡ DB凭证：需要额外提供数据库连接凭证（--mysql-user/--mysql-password 或 inventory.json 中的 databases[]）

多个模块用逗号分隔：--check cpu,memory,disk,alert,jvm_crash,mysql_deep,db_health,db_security

--check all 一键全量巡检 ⭐

当用户说"巡检"、"全量巡检"、"一键巡检"时，AI 自动使用 --check all。

all 自动展开为以下 19 个模块：

system,cpu,memory,disk,network,process,log,security,hardware,
middleware,backup,alert,jvm_crash,
mysql_deep,db_health,db_security,db_locks,db_backup,db_sql

凭证处理逻辑：

实际行为：

• 只要有 SSH 凭证就能跑，「数据库模块没凭证就跳过，不报错」
• 报告末尾会列出跳过的模块及原因，方便后续补齐

使用示例：

# 最简方式：一键全量
python linux_inspection.py --host 192.168.26.66 --user root --password xxx --check all

# 有 DB 凭证时能跑全部 20 个模块
python linux_inspection.py --host 192.168.26.66 --user root --password xxx \
  --check all --mysql-user root --mysql-password dbpwd

# 批量模式：inventory.json 中配置 check_modules: "all"
# 配合 databases[] 字段，自动对列表中的每类数据库执行对应模块
python linux_inspection.py --inventory inventory.json

AI 交互规范：

• 用户说「巡检」→ 直接 --check all
• 用户说「巡检一下数据库」→ --check mysql_deep,db_health,db_security
• 用户说「快速巡检」→ --check cpu,memory,disk,alert

Java 宕机分析工作流 ⭐

概述

jvm_crash 模块是专门针对 Java 应用宕机/异常场景的诊断模块。它通过 SSH 远程在服务器上自动采集 JDK 诊断数据，然后将文本化结果交给 AI 进行深度分析。

采集内容

AI 分析能力（巡检后 AI 自动进行）

AI 在拿到巡检数据后，会自动进行以下分析：

1. 死锁诊断 — 识别 Found deadlock 关键字，绘制死锁环路
2. OOM 根因 — 结合 jmap TOP 对象 + 系统 OOM 记录，定位内存泄漏嫌疑类
3. 线程阻塞 — 统计 BLOCKED 线程数，识别持锁线程和等待链
4. JVM Crash — 解析 hs_err_pid*.log 中的信号量(SIGSEGV/SIGBUS)、native 帧、问题帧
5. GC 异常 — 判断 Full GC 频率是否异常，建议 GC 策略调优
6. 建议输出 — 生成结构化诊断报告 + JVM 参数调优建议 + 代码排查方向

使用示例

# 仅巡检 Java 宕机分析
python linux_inspection.py --host 192.168.26.66 --user root --password xxx --check jvm_crash

# 全量巡检（含 Java 分析）
python linux_inspection.py --host 192.168.26.66 --user root --password xxx --check all

# 关注 CPU/内存 + Java 分析（典型场景：运维报"服务器卡"）
python linux_inspection.py --host 192.168.26.66 --user root --password xxx --check cpu,memory,jvm_crash,alert

Heap Dump 深度分析（额外步骤）

对于需要深入分析内存泄漏的场景，jvm_crash 模块提供的是轻量快照（jmap -histo）。如果发现内存异常，可进一步操作：

# 在服务器上生成 heap dump
jcmd <pid> GC.heap_dump /tmp/heap_$(date +%Y%m%d).hprof

# 转文本摘要后交给 AI 分析
jmap -histo:live <pid> > /tmp/heap_histo.txt
# 或使用 MAT 导出 leak suspects report

注意事项

• jmap -histo:live 会触发 Full GC，生产环境谨慎使用；如需无侵入版本可改用 jmap -histo（不含 :live）
• jstack / jmap 需要与目标 JVM 相同版本的 JDK，或目标进程用户权限
• 应用日志扫描默认搜索 /opt /app /home /data /usr/local /var/log 下 */logs/*.log 路径

告警阈值

报告格式

巡检完成后生成以下输出：

单机模式

1. 终端输出：结构化的巡检结果
2. 文本报告（可选 -o）：结构化巡检结果
3. JSON报告（可选 --json-output）：机器可读的结构化数据
4. 告警摘要：自动提取超阈值项

批量模式

1. 单台报告：每台服务器独立的 txt + json 报告
2. 汇总报告：batch_summary_*.txt 包含所有服务器概览和告警
3. HTML报告（--html）：暗色主题可视化报告，含跨服务器对比表格

报告生成要求

AI执行巡检后，需根据原始数据生成结构化巡检报告：

# Linux服务器巡检报告

## 基本信息
- 巡检时间: YYYY-MM-DD HH:mm:ss
- 目标主机: IP:PORT
- 操作用户: xxx

## 一、系统基础信息
| 项目 | 值 |
|------|-----|
| 操作系统 | xxx |
| 内核版本 | xxx |
| 主机名 | xxx |
| IP地址 | xxx |
| 运行时长 | xxx |

## 二、CPU负载
[状态: 正常/告警/危险]
| 项目 | 值 | 状态 |
|------|-----|------|
| CPU型号 | xxx | - |
| 物理核心 | xx核 | - |
| CPU使用率 | xx% | 正常/告警 |
| 负载(1/5/15) | x.xx/x.xx/x.xx | 正常/告警 |

## 告警汇总
| 级别 | 模块 | 问题描述 | 建议 |
|------|------|----------|------|
| 告警 | 磁盘 | /data 使用率92% | 清理日志或扩容 |

前置条件

pip install paramiko

巡检流程（AI执行）

单机巡检

1. 确认用户提供的：服务器IP、端口、用户名、密码/密钥
2. 先用--check system快速验证连通性
3. 连通后执行 --check all 全量巡检（或用户指定模块）
4. 数据库模块缺凭证时自动跳过，报告末尾标注跳过原因
5. 解析原始输出，生成结构化巡检报告
6. 高亮告警项，给出处理建议
7. 保存报告文件，交付给用户

批量巡检

1. 用户说"批量巡检"或提供多台服务器信息时，引导用户提供服务器清单
2. 编辑 inventory.json 写入服务器信息
3. 执行 --inventory + --html 批量巡检
4. 生成汇总HTML报告，展示跨服务器对比
5. 高亮有告警的服务器，给出处理建议
6. 交付HTML报告文件

MySQL深度诊断模块 🔍

mysql_deep 模块通过 SSH 连接到服务器后，再通过 TCP 连接 MySQL/MariaDB 数据库进行深度诊断。密码使用 MYSQL_PWD 环境变量传递，不会出现在进程列表中。

检测维度（14小节）

大表查询实测示例（vms66 / 2026-05-29）

当 information_schema.tables 超时（>30s）时，14.6 自动回退到 mysql.innodb_table_stats，秒级返回结果。

14.6 大表 TOP10（innodb_table_stats 回退结果）：

说明：该服务器 MySQL 的 information_schema 查询极慢（历史慢查询 TOP1 耗时 15603 秒），14.5 和 14.6 均触发超时回退。回退仅覆盖 InnoDB 表，MyISAM/其他引擎表未包含。 | 14.8 | 慢查询配置 | slow_query_log 状态、long_query_time 阈值 | | 14.9 | 安全审计 | 匿名用户、空密码、远程 root、test 数据库 | | 14.10 | 索引分析 | 无主键表检测 | | 14.11 | 主从复制 | SHOW SLAVE STATUS 关键字段 | | 14.12 | 关键配置参数 | max_allowed_packet、binlog、事务隔离级别等 | | 14.13 | InnoDB引擎状态 | BUFFER POOL、死锁、ROW OPERATIONS 摘要 | | 14.14 | 当前连接详情 | PROCESSLIST，按运行时间倒序 TOP20 |

自动告警规则

使用方式

单机模式：

# 检查本地 MySQL
python linux_inspection.py --host 192.168.26.66 --user root --password redhat \
  --check mysql_deep --mysql-user app --mysql-password dbpwd

# 检查远程 MySQL
python linux_inspection.py --host 192.168.26.66 --user root --password redhat \
  --check mysql_deep --mysql-host 192.168.1.100 --mysql-port 3307 \
  --mysql-user dba --mysql-password secret

批量模式（inventory.json）：

{
  "servers": [{
    "host": "192.168.26.66",
    "alias": "DB服务器",
    "auth": {"type": "password", "value": "redhat"},
    "db_auth": {
      "_comment": "数据库连接凭证：IP、端口、账号、密码",
      "host": "127.0.0.1",
      "port": 3306,
      "user": "root",
      "password": "mysql_root_pwd"
    }
  }],
  "settings": {
    "check_modules": ["mysql_deep", "system", "cpu", "memory", "disk"],
    "generate_html": true
  }
}

db_auth 字段说明（必填项）：

多数据库配置示例（inventory.json）：

{
  "servers": [{
    "host": "192.168.26.66",
    "alias": "混合数据库服务器",
    "auth": {"type": "password", "value": "redhat"},
    "databases": [
      {"type": "mysql", "host": "127.0.0.1", "port": 3306, "user": "root", "password": "mysql_pwd"},
      {"type": "postgresql", "host": "127.0.0.1", "port": 5432, "user": "postgres", "password": "pg_pwd", "database": "ekp"},
      {"type": "oracle", "host": "192.168.1.50", "port": 1521, "user": "scott", "password": "oracle_pwd", "database": "ORCL"}
    ]
  }],
  "settings": {
    "check_modules": ["mysql_deep", "db_health", "db_security", "system", "cpu", "memory"],
    "generate_html": true
  }
}

数据库凭证优先级：服务器级 databases[] > 服务器级 db_auth > 全局 settings.db_auth > CLI 默认值

注意事项

• 需要服务器上有 mysql CLI 客户端（通常 yum install -y mysql）
• 兼容 MySQL 5.7/8.0 和 MariaDB 10.x
• performance_schema 不可用时自动降级，显示提示信息
• slow_log 表不存在时自动跳过
• 密码通过 MYSQL_PWD 环境变量传递，不暴露在进程列表中
• 连接失败时模块会标记为异常，但不影响其他巡检模块

数据库健康诊断 (db_health) 🩺

概述

db_health 模块是数据库维度的"体检中心"，支持 MySQL / PostgreSQL / Oracle 三种数据库。通过 SSH 连接到服务器后，使用对应的 CLI 客户端（mysql / psql / sqlplus）直连数据库执行只读诊断 SQL。复用 inventory.json 中的 db_auth 字段配置数据库连接凭证。

核心诊断维度

关键诊断 SQL

PostgreSQL - 健康评分：

SELECT version(), EXTRACT(EPOCH FROM NOW() - pg_postmaster_start_time()) AS uptime_sec,
  pg_database_size(current_database()) / 1073741824.0 AS size_gb;
SELECT COUNT(*) AS total, COUNT(*) FILTER (WHERE state='active') AS active,
  COUNT(*) FILTER (WHERE state='idle') AS idle FROM pg_stat_activity;
SELECT ROUND(100.0 * SUM(blks_hit) / GREATEST(SUM(blks_hit + blks_read), 1), 2) AS cache_hit_pct
  FROM pg_stat_database WHERE datname = current_database();

Oracle - 健康评分：

SELECT banner AS version, (SYSDATE - STARTUP_TIME) * 86400 AS uptime_sec FROM v$version, v$instance WHERE banner LIKE 'Oracle%';
SELECT COUNT(*) AS total, COUNT(CASE WHEN status='ACTIVE' THEN 1 END) AS active FROM v$session;
SELECT ROUND(100 * (1 - SUM(value) / (SELECT SUM(value) FROM v$sysstat WHERE name='consistent gets')), 2) AS buffer_hit_pct
  FROM v$sysstat WHERE name = 'physical reads';

MySQL - 瓶颈分析（五大方向一键检测）：

-- CPU: 活跃连接 vs 总连接
SELECT VARIABLE_VALUE FROM performance_schema.global_status WHERE VARIABLE_NAME='Threads_running';
-- IO: 缓冲池命中率
SELECT ROUND((1 - Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests) * 100, 2) 
  FROM (SELECT SUM(VARIABLE_VALUE) FROM performance_schema.global_status WHERE VARIABLE_NAME IN ('Innodb_buffer_pool_reads','Innodb_buffer_pool_read_requests')) t;
-- 锁: 当前行锁等待
SELECT SUM(VARIABLE_VALUE) FROM performance_schema.global_status WHERE VARIABLE_NAME='Innodb_row_lock_current_waits';
-- 连接: 连接使用率
SELECT ROUND(SUM(CASE WHEN VARIABLE_NAME='Threads_connected' THEN VARIABLE_VALUE END) * 100.0 / 
  (SELECT VARIABLE_VALUE FROM performance_schema.global_variables WHERE VARIABLE_NAME='max_connections'), 2) AS conn_pct
  FROM performance_schema.global_status WHERE VARIABLE_NAME IN ('Threads_connected');
-- 慢查询: 最近1小时慢查询
SELECT COUNT(*) FROM mysql.slow_log WHERE start_time > DATE_SUB(NOW(), INTERVAL 1 HOUR);

AI 决策流程

场景1：用户说"数据库健康检查"
  → 依次执行健康评分、连接状态、缓冲池命中率 SQL
  → 汇总输出：版本、运行时间、连接数、命中率、QPS、总大小
  → 给出健康评分（0-100）和评级（优秀/良好/需关注）

场景2：用户说"数据库容量够吗"
  → 执行各库大小 SQL + TOP 20 大表
  → 检查磁盘碎片和自增ID使用率
  → 基于当前增长趋势估算剩余天数
  → 输出：当前总容量 / 预测剩余天数 / TOP N 大表 / 扩容建议

场景3：用户说"数据库瓶颈在哪"
  → 执行五大方向瓶颈检测 SQL
  → CPU高 → 追 TOP SQL；IO高 → 查缓冲池；锁多 → 追踪阻塞链
  → 输出：瓶颈方向 + 根因 + 解决建议

使用方式

# 巡检 PostgreSQL
python linux_inspection.py --host 192.168.26.66 --user root --password xxx \
  --check db_health --pg-user app --pg-password dbpwd --pg-db mydb

# 巡检 Oracle（使用 inventory.json 中的 db_auth）
python linux_inspection.py --inventory inventory.json --check db_health

# 组合巡检：系统 + 数据库健康
python linux_inspection.py --host 192.168.26.66 --user root --password xxx \
  --check system,cpu,memory,disk,db_health --mysql-user root --mysql-password xxx

数据库安全审计 (db_security) 🔒

概述

db_security 模块对数据库进行全方位安全审计，支持 MySQL / PostgreSQL / Oracle，覆盖 7 个检查维度，输出安全评分（A/B/C/D/F）。

审计维度与评分权重

关键诊断 SQL

MySQL - 综合安全审计：

-- 匿名用户/空密码/任意主机
SELECT user, host FROM mysql.user WHERE user = '' OR authentication_string = '';
SELECT user, host FROM mysql.user WHERE host = '%';

-- 用户权限列表
SELECT user, host, Select_priv, Insert_priv, Update_priv, Delete_priv,
  Create_priv, Drop_priv, Grant_priv, Super_priv FROM mysql.user;

-- 关键安全配置
SHOW VARIABLES WHERE Variable_name IN (
  'local_infile', 'secure_file_priv', 'log_bin', 'general_log',
  'sql_mode', 'default_authentication_plugin', 'validate_password.policy');

PostgreSQL - 权限审计：

SELECT rolname, rolsuper, rolcreaterole, rolcreatedb, rolcanlogin, rolvaliduntil FROM pg_roles;
SELECT grantee, table_schema, table_name, privilege_type 
  FROM information_schema.table_privileges WHERE table_schema NOT IN ('pg_catalog','information_schema');
-- pg_hba.conf 检查（需读文件）: grep -v '^#' /var/lib/pgsql/*/data/pg_hba.conf | grep -E 'trust|0.0.0.0'

敏感数据扫描（三库通用逻辑）：

-- MySQL 示例：扫描包含敏感信息的列
SELECT table_schema, table_name, column_name,
  CASE WHEN column_name LIKE '%pass%' OR column_name LIKE '%pwd%' THEN '密码'
       WHEN column_name LIKE '%phone%' OR column_name LIKE '%mobile%' THEN '手机号'
       WHEN column_name LIKE '%email%' OR column_name LIKE '%mail%' THEN '邮箱'
       WHEN column_name LIKE '%id_card%' THEN '身份证'
  END AS sensitive_type
FROM information_schema.COLUMNS
WHERE table_schema NOT IN ('mysql','sys','performance_schema','information_schema')
  AND (column_name REGEXP 'pass|pwd|phone|mobile|email|mail|id_card|bank|card_no|salary')
ORDER BY table_schema, table_name;

安全评分标准

数据库锁分析 (db_locks) 🔍

概述

db_locks 模块专门处理数据库锁相关故障，支持 MySQL / PostgreSQL / Oracle 的锁分析、死锁检测、阻塞链追踪。

核心诊断 SQL

MySQL - 锁统计概览：

SELECT COUNT(*) AS total_trx,
  SUM(CASE WHEN trx_state='LOCK WAIT' THEN 1 ELSE 0 END) AS lock_waiting,
  MAX(TIMESTAMPDIFF(SECOND, trx_started, NOW())) AS max_trx_age_sec
FROM information_schema.INNODB_TRX;

MySQL - 阻塞链追踪（完整版）：

-- MySQL 8.0+ 使用 sys.innodb_lock_waits
SELECT waiting_pid, waiting_query, blocking_pid, blocking_query,
  wait_age_secs, locked_table, locked_index, locked_type
FROM sys.innodb_lock_waits;

-- MySQL 5.7 兼容版
SELECT r.trx_mysql_thread_id AS waiting_thread,
  TIMESTAMPDIFF(SECOND, r.trx_started, NOW()) AS wait_sec,
  LEFT(r.trx_query, 100) AS waiting_query,
  b.trx_mysql_thread_id AS blocking_thread,
  LEFT(b.trx_query, 100) AS blocking_query
FROM information_schema.INNODB_LOCK_WAITS w
JOIN information_schema.INNODB_TRX r ON w.requesting_trx_id = r.trx_id
JOIN information_schema.INNODB_TRX b ON w.blocking_trx_id = b.trx_id;

PostgreSQL - 锁等待：

SELECT blocked.pid AS blocked_pid, blocked.query AS blocked_query,
  blocking.pid AS blocking_pid, blocking.query AS blocking_query,
  blocked.wait_event_type, blocked.wait_event
FROM pg_stat_activity blocked
JOIN pg_stat_activity blocking ON blocked.wait_event_type='Lock' AND blocking.pid != blocked.pid;

Oracle - 锁等待：

SELECT blocking_session, sid, serial#, wait_class, seconds_in_wait, sql_id
FROM v$session WHERE blocking_session IS NOT NULL;

AI 决策流程

场景1：用户说"看看数据库锁情况"
  → 执行锁统计 SQL → 如果有waiting事务 → 追踪阻塞链
  → 输出：总锁数 / 等待数 / 最老事务 / 阻塞源

场景2：用户说"有死锁吗"
  → 执行 SHOW ENGINE INNODB STATUS（MySQL）/ 查 PG 日志
  → 解析死锁信息：时间、涉及SQL、循环等待关系
  → 给出避免死锁建议（统一加锁顺序 / 缩短事务）

场景3：用户说"有阻塞，帮我看看"
  → 构建阻塞链图：A→B→C
  → 找到阻塞源 + 分析阻塞SQL + 事务时长
  → 建议：终止阻塞源 / 等待 / 优化SQL

锁类型速查

⚠️ 终止阻塞事务（KILL）需用户明确确认后执行。

数据库备份与调度 (db_backup) 💾

概述

db_backup 模块提供数据库备份、定时任务管理、备份验证能力，支持 MySQL(mysqldump) / PostgreSQL(pg_dump) / Oracle(expdp)。

备份命令速查

MySQL - mysqldump：

# 全量备份（InnoDB 不锁表）
mysqldump -h<host> -P<port> -u<user> -p<pass> \
  --single-transaction --routines --triggers --events \
  --databases <db> | gzip > backup_<db>_$(date +%Y%m%d_%H%M%S).sql.gz

# 仅结构
mysqldump -h<host> -P<port> -u<user> -p<pass> --no-data <db> | gzip > schema.sql.gz

# 指定表
mysqldump -h<host> -P<port> -u<user> -p<pass> --single-transaction <db> t1 t2 | gzip > tables.sql.gz

PostgreSQL - pg_dump：

PGPASSWORD=<pass> pg_dump -h <host> -p <port> -U <user> -Fc \
  -f backup_<db>_$(date +%Y%m%d_%H%M%S).dump <db>
PGPASSWORD=<pass> pg_dump -h <host> -p <port> -U <user> --schema-only -f schema.sql <db>

Oracle - expdp：

expdp <user>/<pass>@<service> DIRECTORY=DATA_PUMP_DIR \
  DUMPFILE=backup_$(date +%Y%m%d).dmp FULL=Y
expdp <user>/<pass>@<service> DIRECTORY=DATA_PUMP_DIR \
  DUMPFILE=schema_$(date +%Y%m%d).dmp SCHEMAS=<schema>

定时备份 Cron 管理

# 每天凌晨2点全量备份
0 2 * * * /opt/scripts/db_backup.sh >> /var/log/db_backup.log 2>&1

# 每6小时增量备份
0 */6 * * * /opt/scripts/db_backup.sh --incremental

# 每周日全量 + 每月1号归档
0 0 * * 0 /opt/scripts/db_backup.sh --full
0 3 1 * * /opt/scripts/db_archive.sh

备份验证

# MySQL: 检查备份文件大小和 SQL 行数
gzip -l backup_*.sql.gz && zcat backup_*.sql.gz | wc -l

# PostgreSQL: 验证 dump 文件
pg_restore -l backup_*.dump | head -20

# 最近24小时是否有新备份
find /backup/ -name "*.sql.gz" -mmin -1440 | wc -l

最佳实践提醒

1. 备份前检查磁盘空间（剩余 > 预估大小 × 2）
2. MySQL InnoDB 务必使用 --single-transaction
3. 备份后验证文件完整性
4. 异地备份（上传远程存储）
5. 保留策略：7天日备 + 4周周备 + 12月月备

SQL 审核与执行 (db_sql) 📋

概述

db_sql 模块整合 SQL 审核与执行两大能力，支持 MySQL / PostgreSQL / Oracle。

功能矩阵

SQL 审核维度与关键规则

性能规范（高风险项）：

安全规范（严重项）：

SQL 重写优化示例

优化前：SELECT * FROM orders WHERE DATE(created_at) = '2024-01-01'
优化后：SELECT id, user_id, amount FROM orders
        WHERE created_at >= '2024-01-01 00:00:00' AND created_at < '2024-01-02'

优化前：SELECT * FROM t WHERE id NOT IN (SELECT uid FROM blacklist)
优化后：SELECT t.* FROM t LEFT JOIN blacklist b ON t.id = b.uid WHERE b.uid IS NULL

优化前：SELECT * FROM t ORDER BY id LIMIT 100000, 20
优化后：SELECT * FROM t WHERE id > 12345 ORDER BY id LIMIT 20

使用方式

# SQL 审核 + 优化建议（AI 直接分析，无需额外参数）
python linux_inspection.py --host 192.168.26.66 --user root --password xxx \
  --check db_sql --sql "SELECT * FROM users WHERE name LIKE '%test%'"

# Schema 查询
python linux_inspection.py --host 192.168.26.66 --user root --password xxx \
  --check db_sql --schema-table users --mysql-user root --mysql-password xxx

AI 决策流程

场景1：用户说"审核这个SQL"
  → 5维度审核：语法→性能→安全→风格→DDL
  → 执行 EXPLAIN 分析执行计划
  → 输出评分 + 问题清单 + 修复建议

场景2：用户说"这个DDL有什么风险"
  → 查询表大小和行数
  → 判断数据库版本（INSTANT DDL支持）
  → 评估：锁表风险 / 执行时间 / 复制延迟 / 回滚方案

场景3：用户说"优化这个SQL"
  → EXPLAIN 分析 → 应用优化规则
  → 输出优化后SQL + 对照说明 + 性能预估改善

安全控制

注意事项

• 硬件巡检（hardware）部分命令需要root权限，非root用户会部分失败
• 中间件巡检（middleware）仅检查已安装的服务，未安装的服务会自动跳过
• 密码等敏感信息不要记录在报告中
• 大文件查找（disk模块）可能耗时较长，可单独执行
• 外网连通性测试受网络环境影响，结果仅供参考
• 批量巡检时单台失败不影响其他服务器，最终汇总报告会标注失败原因
• inventory.json 包含密码等敏感信息，不要提交到版本控制系统

性能优化记录

2026-06-03 性能优化

问题：全量巡检（--check all）耗时 20+ 分钟，主要瓶颈：

1. find / 全盘扫描 — disk 模块的 find / -xdev -type f -size +100M 和 jvm_crash 模块的 find / -name "hs_err_pid*.log" 扫描整个根文件系统，在有大量文件的服务器上可能耗时数分钟
2. ssh_db 逐条查询 — 5 个数据库模块（db_health/db_security/db_locks/db_backup/db_sql）共 ~23 条 SQL 通过独立 SSH 通道逐条执行，每次都要建立 SSH 通道对应网络往返
3. jstat 过度采样 — 每个 Java 进程执行 3 次 jstat（间隔 1s），多进程累计等待时间长
4. 日志扫描无超时 — jvm_crash 的日志扫描没有 maxdepth 和 timeout 限制

优化措施：

备份：修改前已备份至 linux-perf-check-backup-20260603-195000

2026-06-04 模块并发优化

问题：单机巡检 19 个模块串行执行，每个模块依次等待前一个完成，即使模块之间互不依赖也在排队，总耗时 = 各模块耗时之和。

优化措施：

核心架构变化：

# 新增 _exec_single_module() 函数：每个模块在独立线程中执行，创建独立SSH连接
# run_inspection() 重构：
#   1. 先做一次 SSH 连通性验证
#   2. 将 19 个模块提交到 ThreadPoolExecutor（默认5线程）
#   3. as_completed 收集结果，每个 future 独立超时
#   4. 按原始顺序排列报告段落

新增 CLI 参数：

• --module-workers N：单服务器模块并发线程数，默认 5，设为 1 回退串行
• --module-timeout N：单模块超时秒数，默认继承 --timeout

新增 inventory.json 配置项：

"settings": {
    "module_workers": 5,
    "module_timeout": null
}

合并效果（两次优化叠加）：

备份：修改前已备份至 linux_inspection.py.bak.20260604_*