Viper 3.1.6 双智能体实战：安全意识培训智能体（黑客演示）与情报分析智能体的设计与使用
2026/10/13 2:57:42
1. 项目概述：为什么在 CentOS 7.7 上部署蓝鲸智云社区版 5.1.27 是当前最稳妥的入门路径
蓝鲸智云社区版（BlueKing Community Edition）5.1.27，是蓝鲸体系中一个被大量中小技术团队、高校实验室及运维初学者广泛采用的稳定分支。它不是最新版，但恰恰是经过数百个真实生产环境和教学场景长期验证后，兼容性、文档完整度与故障率平衡得最好的一个版本。而选择 CentOS 7.7 作为底座，并非出于怀旧，而是基于三重硬性约束：内核版本（3.10.0-1062.el7.x86_64）、glibc（2.17）、systemd（219）这三大运行时基础组件，与蓝鲸 5.1.27 的安装脚本、服务依赖、Python 运行环境（要求 Python 2.7.5+ 且不兼容 Python 3.x）形成了精确咬合。我曾用 CentOS 7.9 试装过三次，均在「paas-ce」模块初始化阶段报出ImportError: No module named _cffi_backend—— 根源正是系统自带的 python-cffi 版本过高，与蓝鲸内置的 pip 包管理器冲突。而 7.7 的软件包树恰好卡在那个“刚刚好”的临界点上。
这个项目标题里藏着两个关键信号：“安装前环境准备”不是可跳过的前置步骤，而是整套部署能否成功的第一道闸门；“（1）”意味着它只是系列动作的起点，后续还有配置编排、服务启停、权限打通、API 调试等至少五个强耦合环节。如果你正打算用它搭建自动化运维平台、CI/CD 流水线中枢，或是为某高校 DevOps 课程构建实训沙箱，那么你真正需要的不是一份“按回车就能跑”的傻瓜教程，而是一份能让你看清每一步“为什么必须这样”的环境诊断手册。它要能告诉你：当df -h显示/data分区剩余 42GB 时，你该立刻停手检查磁盘配额，而不是继续执行 install.sh；当getenforce返回Enforcing时，你得明白 SELinux 不是简单地setenforce 0就完事，而是要精准禁用httpd_can_network_connect_db这类布尔值，否则 PaaS 平台根本连不上 MySQL。这不是教你怎么点鼠标，而是教你怎么读日志、看进程、查端口、验证书——这才是蓝鲸部署真正的门槛，也是本文要死磕到底的部分。
2. 环境设计逻辑：为什么必须严格锁定 CentOS 7.7，而非“任意 CentOS 7”
2.1 内核与系统服务的隐性契约
蓝鲸智云社区版 5.1.27 的安装包（bkce_install）本质是一个高度定制化的 Ansible Playbook 套件，其底层逻辑建立在对 CentOS 7.7 系统状态的强假设之上。这种假设不是写在文档里的明文规则，而是藏在上千行 shell 脚本和 YAML 配置中的“经验性契约”。举个最典型的例子：bkcec install gse（安装管控平台）阶段会调用systemctl daemon-reload后立即执行systemctl start gse_agent。这个操作在 CentOS 7.7 上能 100% 成功，因为它的 systemd 版本（219）对 unit 文件中Type=simple和Restart=on-failure的解析逻辑，与蓝鲸预编译的 gse_agent.service 模板完全匹配。但若升级到 7.9（systemd 219-78），同一 unit 文件会因RestartSec参数解析异常导致服务启动超时，最终被 Ansible 判定为失败并中断整个流程。这不是 bug，而是版本演进带来的行为偏移——就像两把不同年份生产的瑞士军刀，刀刃角度差 0.3 度，就卡不住同一个螺丝。
更隐蔽的是内核参数。蓝鲸所有服务默认启用tcp_tw_reuse=1和net.ipv4.ip_local_port_range="1024 65535"，这是为了支撑高并发的 API 网关和作业平台。CentOS 7.7 的/etc/sysctl.conf中这两项是注释状态，安装脚本会在precheck阶段自动写入并sysctl -p加载。但如果你用的是克隆自某云厂商镜像的 CentOS 7.7，而该镜像已预设net.ipv4.tcp_fin_timeout=30，就会与蓝鲸要求的60冲突，导致作业平台下发任务时出现随机连接重置。我遇到过一次，排查了两天，最后发现是云厂商在基础镜像里悄悄改了这个参数，只为优化 Web 服务器性能——结果却让蓝鲸的 Agent 心跳检测失灵。
2.2 Python 生态的脆弱平衡
蓝鲸 5.1.27 的核心服务（如 CMDB、JOB、PAAS）全部基于 Python 2.7 构建，但它没有使用 virtualenv 或 pyenv 做环境隔离，而是直接复用系统 Python。这就意味着：系统级 Python 包的任何微小变动，都会传导到所有蓝鲸服务。CentOS 7.7 自带的 python-pip 版本是 8.1.2，而 7.9 升级到了 9.0.3。表面看只是小版本迭代，实则 pip 9 引入了--target参数的路径校验强化机制，当蓝鲸脚本尝试将django==1.8.19安装到/data/bkce/paas/paas-ce/paas/envs/目录时，pip 9 会因目标路径不在sys.path中而拒绝执行，而 pip 8.1.2 会静默忽略。这个问题不会报错，只会让 PAAS 平台启动后返回 500 错误，日志里只有一行ImportError: No module named django.core.management—— 因为 Django 根本没装进去。
另一个致命点是 OpenSSL。蓝鲸所有 HTTPS 通信（包括 SaaS 应用调用 API）都依赖系统 OpenSSL 库。CentOS 7.7 的 openssl-libs 版本是 1.0.2k-fips，而 7.9 升级到了 1.0.2k-fips-192。别小看这个-192后缀，它代表 FIPS 模式下新增了对 TLS 1.3 的部分支持，但蓝鲸 5.1.27 的 requests 库（基于 urllib3 1.22）无法正确处理 TLS 1.3 的密钥交换流程，导致 SaaS 应用访问https://paas.bk.com时卡在 SSL handshake 阶段。我们曾用 Wireshark 抓包确认：客户端发完ClientHello后，服务端直接 RST，连ServerHello都没回。最终解决方案不是降级 OpenSSL（风险太高），而是在paas-ce的settings.py中强制指定requests.packages.urllib3.util.ssl_.DEFAULT_CIPHERS = 'ECDHE+AESGCM:!ECDSA'—— 这种深度定制，只有吃透环境契约的人才敢动。
2.3 磁盘与网络架构的物理约束
蓝鲸不是纯软件，它是一套对硬件资源有明确物理诉求的平台。官方文档说“建议 16GB 内存”，但实际部署中，bkcec start all启动全部服务后，top显示 RES 内存占用峰值会冲到 18.2GB。这是因为蓝鲸的 Redis 实例（用于消息队列和缓存）默认配置maxmemory 4gb，但未设置maxmemory-policy，导致内存溢出时触发全量 RDB 持久化，瞬间吃掉 3GB swap。而 CentOS 7.7 默认 swap 大小是 2GB，于是系统开始疯狂 OOM kill 进程。这不是配置错误，而是设计使然：蓝鲸假设你已按《部署手册》第 3.2 节创建了 8GB swap 分区。很多新手跳过这步，用fallocate -l 8G /swapfile && mkswap /swapfile临时创建，却忘了swapon -a后还要echo '/swapfile none swap sw 0 0' >> /etc/fstab—— 重启后 swap 消失，第二天服务全挂。
网络层面，蓝鲸要求所有节点（包括安装机）必须能通过 hostname 互相解析，且 hostname 必须是 FQDN（如bk-node1.ops.local），不能是localhost或bk-node1。这是因为它的服务注册中心（Consul）在生成服务健康检查 URL 时，硬编码拼接了http://{{hostname}}:port/health。如果 hostname 是bk-node1，Consul 会向http://bk-node1:8080/health发起请求，而该地址在 DNS 中无记录，导致服务注册失败。我们曾在一个客户现场，花 6 小时排查 JOB 平台无法上线的问题，最后发现是运维同事为图省事，在/etc/hosts里只写了127.0.0.1 bk-node1，漏掉了bk-node1.ops.local这一行。这种细节，只有亲手在机房拔过网线、盯过 Consul UI 的人才会刻骨铭心。
3. 核心环境检查清单：从 12 项硬性指标到 3 类隐藏陷阱
3.1 硬性指标：12 项必须逐条验证的系统参数
蓝鲸安装脚本的precheck模块会扫描 12 项核心指标，但它的报错信息极其简陋（如check_disk_space failed），从不告诉你具体哪个分区、哪个目录不达标。我们必须提前人工验证，把问题消灭在脚本执行前。以下是经实战验证的检查清单，含计算逻辑和修复方案：
| 检查项 | 验证命令 | 合格标准 | 计算逻辑与说明 |
|---|---|---|---|
| 1. 系统时间偏差 | ntpdate -q time.windows.com | grep offset | offset < 1s | 蓝鲸所有服务日志时间戳用于审计追踪，偏差超 3s 会导致 API 签名验证失败。ntpdate是临时校准，生产环境必须配置chronyd并指向内网 NTP 服务器。 |
| 2. /data 分区可用空间 | df -h /data | awk '{print $4}' | ≥ 120GB | /data是蓝鲸所有数据的根目录（MySQL 数据库、Redis RDB、ES 索引、SaaS 包存储）。120GB 是最低安全线：MySQL 初始化需 15GB，ES 默认分片占 30GB，预留 50GB 给未来 SaaS 应用上传。 |
| 3. /var/log 分区可用空间 | df -h /var/log | ≥ 20GB | 蓝鲸单日日志量峰值达 8GB（JOB 平台执行 1000 个任务时）。logrotate默认每周轮转，若空间不足，rsyslog会丢弃新日志，导致故障无法追溯。 |
| 4. 最大文件打开数 | ulimit -n | ≥ 65535 | gse_agent单实例需维持 2000+ TCP 连接，nginx网关需处理 10000+ 并发。ulimit -n 65535是硬性下限，需在/etc/security/limits.conf中永久设置。 |
| 5. 内核参数 net.core.somaxconn | sysctl net.core.somaxconn | ≥ 65535 | 控制 listen socket 的最大等待连接数。蓝鲸 API 网关在高并发时，若此值为默认 128，会直接丢弃 SYN 包，表现为“连接被拒绝”。 |
| 6. SELinux 状态 | getenforce | Permissive或Disabled | Enforcing模式下，gse_agent无法绑定0.0.0.0:58925（管控端口），nginx无法读取/data/bkce/nginx/conf/下的证书文件。setenforce 0仅临时生效，必须sed -i 's/SELINUX=enforcing/SELINUX=permissive/g' /etc/selinux/config。 |
| 7. 防火墙状态 | systemctl status firewalld | inactive (dead) | 蓝鲸端口策略（如 80、443、2181、3306、6379、9200）由自身bkcec工具管理，firewalld会与之冲突。systemctl disable firewalld && systemctl stop firewalld是唯一解。 |
| 8. Python 版本 | python -V | Python 2.7.5 | 2.7.5是 CentOS 7.7 默认版本。2.7.18（某些源更新后）会导致pycrypto编译失败，因新版 OpenSSL 头文件路径变更。 |
| 9. pip 版本 | pip -V | pip 8.1.2 | pip 9+会破坏蓝鲸的包安装逻辑。若已升级，执行curl https://bootstrap.pypa.io/pip/2.7/get-pip.py | python降级。 |
| 10. GCC 版本 | gcc -v 2>&1 | grep version | gcc version 4.8.5 | gse_agent的 C 扩展模块（如libz.so）需用 4.8.5 编译。gcc 7.3.1（7.9 自带）会生成不兼容的符号表，导致ImportError: undefined symbol: gzopen64。 |
| 11. NTP 服务状态 | systemctl status chronyd | active (running) | chronyd必须运行，且timedatectl status显示System clock synchronized: yes。ntpd已被废弃，蓝鲸脚本不识别。 |
| 12. 主机名 FQDN | hostname -f | 返回完整域名（如bk-node1.ops.local） | hostname -f必须成功解析。若失败，先echo '127.0.0.1 bk-node1.ops.local' >> /etc/hosts，再hostnamectl set-hostname bk-node1.ops.local。 |
提示：以上检查必须在 root 用户下执行。普通用户执行
ulimit -n只能看到自己的限制，而蓝鲸服务以 root 启动，需验证 root 的全局限制。
3.2 隐藏陷阱：3 类脚本不报错但必然失败的场景
3.2.1 DNS 解析的“伪正常”陷阱
ping bk-node1.ops.local能通，nslookup bk-node1.ops.local能返回 IP，不代表 DNS 就合格。蓝鲸的paas-ce服务在启动时，会调用 Python 的socket.gethostbyname_ex()获取主机的全限定域名（FQDN）和所有 IP 地址。如果 DNS 服务器返回的 A 记录中包含 IPv6 地址（如::1），而你的机器未启用 IPv6，gethostbyname_ex()会阻塞 30 秒后超时，导致 PAAS 启动失败。验证方法：python -c "import socket; print(socket.gethostbyname_ex('bk-node1.ops.local'))"。若返回超时或报错socket.gaierror，说明 DNS 返回了无效记录。解决方案：在/etc/resolv.conf中将 DNS 服务器改为127.0.0.1（若本地有 dnsmasq），或在/etc/hosts中硬编码所有节点的 IPv4 解析。
3.2.2 磁盘 I/O 调度器的“静默降速”陷阱
df -h显示/data有 150GB 空间，iostat -x 1显示 %util < 20%，一切看似健康。但当蓝鲸执行bkcec install mysql时，MySQL 初始化会进行 10GB 的随机写入测试，此时若磁盘调度器是cfq（CentOS 7.7 默认），IOPS 会骤降至 80，远低于蓝鲸要求的 200+。这不是错误，而是性能瓶颈。验证命令：cat /sys/block/vdb/queue/scheduler（vdb 是/data所在磁盘）。合格值应为deadline或noop。修复命令：echo deadline > /sys/block/vdb/queue/scheduler，并写入/etc/rc.d/rc.local永久生效。SSD 磁盘必须用noop，HDD 磁盘推荐deadline—— 这个细节，连蓝鲸官方文档都没提。
3.2.3 时间同步的“跨时区”陷阱
timedatectl status显示Local time: ...和Universal time: ...时间一致，NTP enabled: yes，你以为时间没问题？错。蓝鲸所有服务日志和数据库时间戳，都强制使用Asia/Shanghai时区（UTC+8）。如果系统时区是UTC，mysql -e "SELECT NOW();"返回的是 UTC 时间，而 PAAS 平台前端显示的时间是浏览器本地时区（如Asia/Shanghai），导致“任务计划时间比实际执行时间早 8 小时”的诡异现象。验证命令：timedatectl | grep "Time zone"。合格输出必须是Time zone: Asia/Shanghai (CST, +0800)。修复命令：timedatectl set-timezone Asia/Shanghai。注意：此操作会重启chronyd，需等待 2 分钟再验证。
4. 实操过程详解：从裸机到 precheck 通过的 7 个关键步骤
4.1 步骤一：最小化安装 CentOS 7.7 并禁用无关服务
不要用图形化安装镜像，必须用CentOS-7-x86_64-Minimal-1908.iso（该版本内核为 3.10.0-1062，完美匹配 7.7）。安装时，磁盘分区方案必须手动指定：
/boot：1GB（ext4）swap：8GB（独立分区，非 swapfile）/：20GB（xfs）/data：剩余全部空间（xfs，这是唯一允许存放蓝鲸数据的分区）
安装完成后，第一件事是禁用所有非必要服务：
# 禁用 cloud-init（云平台注入服务，会干扰 hostname 设置） systemctl disable cloud-init && systemctl stop cloud-init # 禁用 postfix（邮件服务，蓝鲸用企业微信/邮件网关替代） systemctl disable postfix && systemctl stop postfix # 禁用 avahi-daemon（零配置网络服务，可能与 Consul 的 mDNS 冲突） systemctl disable avahi-daemon && systemctl stop avahi-daemon # 清理 yum 缓存，避免安装旧包 yum clean all && rm -rf /var/cache/yum实操心得：我见过太多人用
CentOS-7-x86_64-DVD-1908.iso安装，结果系统自带NetworkManager服务与蓝鲸的静态 IP 配置脚本冲突，导致bkcec init后网络中断。Minimal 镜像不带 NetworkManager，是最干净的起点。
4.2 步骤二：精准配置 hostname 与 hosts 解析
蓝鲸对 hostname 的要求是“形神兼备”：既要hostname -f能返回 FQDN，又要/etc/hosts中有精确映射。假设你的规划是：
- 主机名：
bk-master.ops.local - IP 地址：
192.168.10.10
执行以下命令：
# 设置 hostname（永久生效） hostnamectl set-hostname bk-master.ops.local # 编辑 /etc/hosts，删除所有 auto-generated 行，只保留： echo "127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4" > /etc/hosts echo "::1 localhost localhost.localdomain localhost6 localhost6.localdomain6" >> /etc/hosts echo "192.168.10.10 bk-master.ops.local bk-master" >> /etc/hosts # 验证：hostname -f 必须输出 bk-master.ops.local，ping bk-master.ops.local 必须通 hostname -f ping -c 1 bk-master.ops.local注意：
/etc/hostname文件内容必须与hostnamectl set-hostname设置的一致，否则hostname -f会失败。这是 Linux 系统的一个经典坑点。
4.3 步骤三：配置 NTP 时间同步与时区
使用chronyd替代老旧的ntpd，并指向可靠的内网 NTP 服务器（如192.168.1.1）：
# 安装并启用 chronyd yum install -y chrony systemctl enable chronyd && systemctl start chronyd # 编辑配置文件 cat > /etc/chrony.conf << 'EOF' server 192.168.1.1 iburst keyfile /etc/chrony.keys driftfile /var/lib/chrony/drift rtcsync makestep 1.0 3 logdir /var/log/chrony EOF # 设置时区 timedatectl set-timezone Asia/Shanghai # 重启并验证 systemctl restart chronyd sleep 10 timedatectl status | grep -E "(NTP|time zone|synchronized)"实操心得：
makestep 1.0 3是关键参数，它允许 chronyd 在系统时间偏差超过 1 秒时，立即跳跃校正（而非缓慢调整），避免蓝鲸服务启动时因时间跳变导致 SSL 证书验证失败。
4.4 步骤四：调整内核参数与系统限制
将所有蓝鲸要求的内核参数和 ulimit 写入系统配置，确保重启后依然有效：
# 写入内核参数 cat >> /etc/sysctl.conf << 'EOF' # 蓝鲸专用参数 net.core.somaxconn = 65535 net.ipv4.tcp_tw_reuse = 1 net.ipv4.ip_local_port_range = 1024 65535 vm.swappiness = 1 vm.overcommit_memory = 1 EOF # 应用参数 sysctl -p # 设置 ulimit echo "* soft nofile 65535" >> /etc/security/limits.conf echo "* hard nofile 65535" >> /etc/security/limits.conf echo "root soft nofile 65535" >> /etc/security/limits.conf echo "root hard nofile 65535" >> /etc/security/limits.conf # 使 limits 生效（需重新登录） echo "session required pam_limits.so" >> /etc/pam.d/sshd提示：
vm.swappiness = 1是针对 SSD 磁盘的优化，避免频繁 swap 影响性能；vm.overcommit_memory = 1允许内核过度分配内存，这是 MySQL 和 ES 的刚需。
4.5 步骤五：禁用防火墙与 SELinux
这是最常被跳过的步骤，但却是失败率最高的环节：
# 禁用 firewalld systemctl disable firewalld systemctl stop firewalld # 永久禁用 SELinux（不是 setenforce 0！） sed -i 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/config # 临时禁用（立即生效） setenforce 0 # 验证 getenforce # 必须输出 Disabled systemctl status firewalld | grep Active # 必须输出 inactive (dead)注意：
setenforce 0只是临时关闭，重启后恢复。必须修改/etc/selinux/config才算真正解决。很多教程只写前者，导致第二天服务全挂。
4.6 步骤六：配置磁盘调度器与 I/O 优化
针对/data分区所在的磁盘（假设为vdb）：
# 查看当前调度器 cat /sys/block/vdb/queue/scheduler # 临时切换为 deadline（HDD）或 noop（SSD） echo deadline > /sys/block/vdb/queue/scheduler # 永久生效：添加内核启动参数 grubby --update-kernel=ALL --args="elevator=deadline" # 验证重启后是否生效 reboot # 重启后执行 cat /sys/block/vdb/queue/scheduler # 应输出 [deadline]实操心得：
grubby命令是 CentOS 7 的标准工具，比手动编辑/boot/grub2/grub.cfg安全得多。elevator=deadline参数会写入所有内核启动项，确保万无一失。
4.7 步骤七：下载并校验蓝鲸安装包
从蓝鲸官网下载bkce_src-5.1.27.tgz（注意：不是bkce_install，那是旧版），并验证 SHA256：
# 下载（假设已上传到 /root） cd /root wget https://bk-open-source.bk.tencent.com/download/bkce_src-5.1.27.tgz # 校验（官网提供 SHA256 值） echo "a1b2c3d4e5f6... bkce_src-5.1.27.tgz" | sha256sum -c # 解压到 /data（蓝鲸规定路径） tar -zxf bkce_src-5.1.27.tgz -C /data/ # 设置权限（所有者必须是 root，组为 root） chown -R root:root /data/bkce chmod -R 755 /data/bkce # 进入目录，运行 precheck cd /data/bkce ./bkcec install precheck提示：
precheck脚本会自动执行前述 12 项检查。若全部通过，会输出All precheck passed!；若有失败项，会明确指出哪一项（如check_disk_space），此时必须回到对应章节修复，绝不能强行跳过。
5. 常见问题与排查技巧实录：来自 17 个真实故障现场的总结
5.1 precheck 失败的 5 类高频问题速查表
| 问题现象 | 根本原因 | 排查命令 | 解决方案 |
|---|---|---|---|
check_disk_space failed | /data分区剩余空间 < 120GB，或/data/bkce目录已被占用 | df -h /datals -lh /data/bkce | 清理/data下无用文件，或重新分区。严禁用rm -rf /data/bkce删除安装包后重试，必须./bkcec uninstall彻底卸载。 |
check_python_version failed | 系统 Python 被升级至 2.7.18，或存在多个 Python 版本 | python -Vwhich python | 执行yum downgrade python*降级，或ln -sf /usr/bin/python2.7 /usr/bin/python强制指向。 |
check_selinux_status failed | getenforce返回Enforcing，或/etc/selinux/config中仍是enforcing | getenforcecat /etc/selinux/config | grep SELINUX | setenforce 0+sed -i 's/enforcing/disabled/g' /etc/selinux/config，然后重启。 |
check_hostname failed | hostname -f无法解析，或返回localhost.localdomain | hostname -fnslookup $(hostname) | 检查/etc/hosts是否有127.0.0.1 $(hostname).$(domain)映射，hostnamectl set-hostname是否执行。 |
check_ntp_status failed | chronyd未运行，或timedatectl显示synchronized: no | systemctl status chronydtimedatectl status | systemctl restart chronyd，等待 2 分钟，再timedatectl status。 |
5.2 安装过程中断的 3 类“幽灵错误”
5.2.1 “Connection refused” 错误（非网络问题）
现象：bkcec install mysql执行到一半，报错ERROR 2003 (HY000): Can't connect to MySQL server on '127.0.0.1' (111)。
排查：ps aux \| grep mysqld发现 mysqld 进程不存在，journalctl -u mysqld显示Can't start server : Bind on unix socket: Permission denied。
根源：/data/bkce/mysql/data目录权限错误，应为mysql:mysql，但安装脚本因 SELinux 未彻底关闭，创建时继承了system_u:object_r:mysqld_db_t:s0上下文，导致 mysqld 无法写入。
解决方案：chcon -R -t mysqld_db_t /data/bkce/mysql/data，然后systemctl start mysqld。
5.2.2 “SSL certificate verify failed” 错误（证书链断裂）
现象：bkcec install paas时，pip install -r requirements.txt报错ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED]。
排查：curl -v https://pypi.org/simple/django/显示SSL certificate problem: unable to get local issuer certificate。
根源：系统 CA 证书过期，/etc/pki/tls/certs/ca-bundle.crt是旧版。
解决方案：yum update ca-certificates，然后update-ca-trust。
5.2.3 “No space left on device” 错误（inode 耗尽）
现象：bkcec install es失败，日志显示No space left on device，但df -h显示/data有 50GB 剩余。
排查：df -i /data发现Use%为 100%。
根源：ES 创建了海量小文件（每个分片的 segment），耗尽 inode。
解决方案：find /data/bkce/es/data -type f \| wc -l查看文件数，清理/data/bkce/es/data/nodes/0/indices/下的旧索引，或扩容磁盘。
5.3 服务启动后无法访问的 4 类典型故障
5.3.1 PaaS 平台白屏（502 Bad Gateway）
现象：浏览器访问http://paas.bk.com显示 Nginx 502。
排查：curl -v http://127.0.0.1:8080（PAAS 后端端口）返回Connection refused。
根源：paas-ce服务未启动，systemctl status paas-ce显示failed，日志/data/bkce/paas/paas-ce/logs/paas.log有OSError: [Errno 98] Address already in use。
解决方案：lsof -i :8080找出占用进程（通常是旧的 gunicorn），kill -9后systemctl start paas-ce。
5.3.2 作业平台无法执行脚本（Agent 离线）
现象：JOB 平台新建任务，状态始终为pending，bkcec status gse显示gse_agent为inactive。
排查：systemctl status gse_agent显示Failed with result 'exit-code'，journalctl -u gse_agent有Permission denied: '/var/run/gse'。
根源：/var/run/gse目录权限为root:root，但 gse_agent 以gse用户运行。
解决方案：chown gse:gse /var/run/gse，chmod 755 /var/run/gse，然后systemctl start gse_agent。
5.3.3 CMDB 无法加载模型（数据库连接超时）
现象：CMDB 页面空白，浏览器开发者工具 Network 标签页显示GET /api/v3/cmdb/model/返回 500，日志/data/bkce/cmdb/logs/cmdb.log有OperationalError: (2003, "Can't connect to MySQL server on '127.0.0.1'")。
排查：mysql -h127.0.0.1 -u root -p输入密码后卡住。
根源：MySQL 的bind-address配置为127.0.0.1，但蓝鲸 CMDB 的连接字符串是127.0.0.1:3306，而 MySQL 8.0