简介：面向麒麟操作系统运维与安全监测实施人员的探针软件落地文档，用于解决 Kylin 3.3 探针从部署到验收全过程的配置依据问题，适合具备一定 Linux 基础、需要独立完成安装调试的工程师查阅。包内为 1 个 docx 文件，约 1002KB，以 30 页手册形式编排，从适用范围、总体目标与原则写起，依次说明作业前提条件、网络安全监测装置接入、程序安装、图形化界面配置与命令行配置的对应操作，并附告警测试与程序卸载流程。文中还给出 agent 升级组件与升级程序的界面示意、系统版本信息、产品认证、主机通讯地址及网络白名单、关键目录文件等配图，便于按目录逐节定位。已有 1574 人学习，可作为现场部署、故障排查与配置复核的对照材料。

1. 麒麟 3.3 探针不是装上就完事：先看清它在网络里的位置

麒麟系统上装 3.3 探针，真正让人返工的不是 rpm 装不上，而是装完之后装置侧一直显示离线、白名单加了照样报非法外联、U 盘插拔测不出日志。这份《Kylin 3.3 探针软件安装调试手册》把作业前提、网监装置对接、程序安装、agent 升级、图形化配置、命令行配置、告警测试和卸载串成了一条完整链路，属于典型的现场实施文档，而不是产品白皮书。它适合要在麒麟服务器上落地主机监测的运维和安全实施人员，也适合已经装完、但对着一屏配置项不敢下手的同行。下面按我实际拆这份资料的顺序讲，先把前提立住，再落配置，最后把告警测试跑成闭环。

2. 作业前提与网监装置对接：三条硬门槛先过

手册第 3 章“作业前提条件”在目录里只占一页表，但现场返工十有八九出在这一页。探针本身是个采集端，它采集到的日志最终要送到网络安全监测装置上才算完成闭环，所以“装得上”和“用得了”是两件事。前提条件里真正卡人的只有三条：系统与架构要匹配、探针到装置的网络要可达、时间和权限要干净。这三条任何一条不成立，后面图形化界面填得再漂亮，装置侧看到的也只是一台离线设备。

2.1 作业前提表：主机侧要固定下来的六项信息

手册表 1 列的是作业前提，落到操作层面，我一般会先把六项信息一次性抓全并写进实施记录，后面填配置表、写注册码、给装置侧登记 IP 全靠这份记录。这六项分别是操作系统版本、内核版本、CPU 架构、主机名、业务通信 IP、可用的磁盘与内存。其中最容易被跳过的是 CPU 架构，麒麟服务器操作系统在飞腾、鲲鹏这类平台上跑的是 aarch64，包名和 x86_64 完全不是一回事。

下面这段命令是我常用的前提信息采集脚本，一次性跑完，输出直接贴进记录表：

# 系统标识与版本，NAME/VERSION 两行足够对表 grep -E '^(NAME|VERSION)=' /etc/os-release # 内核版本，部分采集模块对内核有下限要求 uname -r # CPU 架构，决定装 x86_64 还是 aarch64 的包 uname -m # 静态主机名，注意不要和装置侧登记的机器名冲突 hostnamectl --static # 只看全局 IPv4 地址，避免把 docker0、virbr0 也记进去 ip -4 addr show scope global | awk '/inet /{print $2, $NF}' # 内存与关键分区余量，采集缓存和规则库都写在本地 free -h | awk 'NR<=2' df -h /opt /var /usr

逐行说明一下用途。第一行拿系统名和版本，用来对照手册表 3 的“型号和版本”，版本对不上时后面所有配置项都可能对不上号；第二行拿内核，采集模块里有些依赖内核审计子系统的功能，内核太旧会直接失效；第三行拿架构，装错包时 rpm 会明确报package is intended for a different architecture，这是最容易识别的一种失败；第四行是主机名，装置侧通常按“IP + 主机名”双维度识别设备，主机名重名会导致两台设备的日志混在一起；第五行只要全局地址，因为容器网桥和虚拟网桥地址填进“主机通讯地址”是无效的，装置侧根本路由不过来；最后两行看资源，探针的采集缓存、规则库、日志都落在本地盘上，/opt或/var只剩几百兆的时候，跑几天就会因为写不进去而静默停止采集。

提示：df -i的 inode 使用率也要看一眼。日志类文件小而多，inode 耗尽的表现和磁盘满完全一样，但报错信息完全不同，现场很容易判断错方向。

2.2 网监装置 IP 表：探针主动上报，别把方向搞反

手册表 2 是网监装置 IP 表，需要填装置名称、装置 IP、探针上报端口这类信息。这个表看着像登记表，实际上是排错第一现场。理解方式很简单：探针是客户端，装置是服务端，探针周期性向装置的指定端口发起连接把数据送上去，所以只要主机到装置的端口通，基础上报就能成立；但如果装置侧还要下发策略、远程重启探针、拉取主机信息，那就是反向连接，需要主机侧的监听端口也对装置开放。很多“探针在线但配置下发不下去”的问题，就是只通了单向。

现场核对连通性我习惯用三条命令，分别解决“通不通”“有没有在听”“路由走对没”三个问题：

# 1. 到装置上报端口的 TCP 连通性，-w 是超时秒数，别设太长 nc -vz -w 3 10.20.30.40 8443 # 2. 本机监听端口，确认探针服务真的起来了，而不是只有进程在 ss -lntp | grep -E ':(8443|9000)\b' # 3. 看清到装置走的是哪张网卡和哪个源地址 ip route get 10.20.30.40

第一条里的端口号是占位，实际以装置侧分配和手册表 2 为准，照抄别人的端口是常见翻车点。第二条除了看端口，还要看监听地址是0.0.0.0还是某个具体 IP，如果探针只监听了127.0.0.1，装置侧再怎么配也连不进来。第三条最关键，多网卡主机上如果不指定源地址，报文很可能从管理口出去，而装置侧只信业务网段，结果就是“我这边能 ping 通，装置那边收不到”。

主机通讯地址这一项在图形化和命令行里都要填（手册表 6 和表 13），填的是装置能路由到的业务 IP，不是127.0.0.1，也不是 NAT 之后的地址。虚拟机环境里尤其容易踩：主机里看到的是192.168.x.x，装置侧看到的是宿主机映射后的地址，两边对不上时表现就是设备在线状态反复跳。

2.3 时间同步、防火墙与权限：三个不显眼但会咬人的点

时间同步排在第三，是因为它出问题时最难往这个方向想。探针采集的每条日志都带本地时间戳，装置侧按时间排序和关联，主机时间和装置时间差出几分钟，告警在装置上就会显示成“过去的告警”甚至被丢弃。麒麟系统上默认是 chrony，chronyc sources -v看源列表里有没有带*的同步源，timedatectl看System clock synchronized是不是 yes。内网环境没有外网时间源时，把装置或内网 NTP 服务器配成上游就行，别放着不同步不管。

防火墙是第二道。麒麟默认可能开着 firewalld，探针上报端口、装置下发端口都要放行，而不是简单粗暴地systemctl stop firewalld。放行的时候注意 zone 的选择，网卡在public还是trusted，结果不一样。用firewall-cmd --list-all先看当前规则，再决定加服务还是加端口，改完--reload之后重新跑一次上面的 nc 命令验证，不要凭感觉认为已经生效。

权限这块主要是 root 和 sudo 的差别。探针的配置文件、规则文件基本都在/etc和/opt下，普通用户读不到；而用sudo 命令和sudo -i之后的环境变量、工作目录不同，某些配置工具的相对路径会失效。我一般直接sudo -i进 root 环境操作，避免“命令一样但就是报找不到文件”这种玄学问题。

3. 程序安装与 agent 升级：从版本核对到组件替换

手册第 5 章“程序安装”看着是一串截图，实际包含三段独立动作：主程序安装、agent 升级组件与升级程序的替换、产品注册。这三段的顺序不能乱，尤其升级这一步，装完主程序直接跳过去注册，版本对不上会导致注册后功能不全。

3.1 系统版本、型号与安装包对应关系

手册表 3“型号和版本”和表 4“程序部署”是配套看的。表 3 告诉你目标主机是什么系统什么架构，表 4 告诉你这个环境该放哪几个文件。一个完整的部署包通常包含三类东西：探针主程序安装包、agent 升级组件、agent 升级程序（对应手册图 2 和图 3 的两部分截图）。很多现场只拿到主程序包，升级那一步就卡住，所以拿到资源的第一件事是把文件清单对一遍。

包名里的架构标识是最硬的校验点，x86_64和aarch64混装不会有任何“部分可用”的中间状态，只会直接失败。版本号同理，主程序 3.3 配 3.2 的升级组件，装完能起服务，但图 4 那个“升级信息核对”环节会显示版本不一致，这时候再回头找包，等于把前面的活重做一遍。

3.2 安装包部署：先校验再试装，最后才正式装

我装这类安全探针从来不直接敲rpm -ivh，中间一定加两步。第一步算校验值，确认传输过程中文件没坏；第二步--test试装，只做依赖和冲突检查，不动系统。这两步加起来不到一分钟，能省掉后面半小时的回滚。

# 1. 校验文件完整性，与随包提供的校验值比对 md5sum kylin-probe-3.3.aarch64.rpm # 2. 只看依赖，不安装，确认基础库都在 rpm -qpR kylin-probe-3.3.aarch64.rpm | sort -u # 3. 试装，检查文件冲突和已安装版本 rpm -ivh --test kylin-probe-3.3.aarch64.rpm # 4. 正式安装，-v 显示过程，-h 显示进度 rpm -ivh kylin-probe-3.3.aarch64.rpm # 5. 安装后立刻确认服务与端口 systemctl status kylin-agent --no-pager ss -lntp | grep kylin

--test这一步的价值在于它会把“文件已被其他包占用”“需要更新而不是安装”这类问题提前暴露。已经在旧版本上覆盖安装时，-ivh会报package is already installed，这时候要用rpm -Uvh做升级安装；如果报某个.so被占用，说明旧服务还在跑，先systemctl stop再装。

装完不要急着开图形界面，先确认文件到底落在哪。用rpm -ql列文件清单，用rpm -qc只看配置文件，这两个命令决定了后面命令行配置该改哪个路径：

# 看包内全部文件，确认安装目录结构 rpm -ql kylin-probe | head -40 # 只看配置文件，命令行配置阶段就改这些 rpm -qc kylin-probe # 看服务单元，确认服务名，别凭印象 systemctl restart rpm -ql kylin-probe | grep '\.service$'

服务名这一条要特别说。不同版本的服务单元命名可能带后缀，直接systemctl restart kylin-agent报Unit not found的时候，很多人会怀疑包没装上，其实是名字不对。用systemctl list-unit-files | grep -i kylin一次就能看清。

3.3 agent 升级：组件替换、程序执行、信息核对三步

手册图 2 到图 4 描述的是 agent 升级过程，拆开就是三件事：升级组件（文件替换）、升级程序（执行替换动作并登记版本）、升级信息核对（确认版本、组件、校验值三处一致）。这三步必须按顺序走，跳过核对直接去注册，后面出现功能缺失时根本定位不到是哪一层的问题。

我的操作顺序一般是：先备份当前 agent 目录和配置文件，再停服务，再替换组件，再跑升级程序，最后核对版本后起服务。备份这一步不要省，升级失败要回退时，没有备份就只能重装，重装又要重新配一遍白名单和审计规则，这是最典型的“五分钟省事、两小时返工”。

升级过程中有几个参数值得注意。升级程序一般支持指定安装路径和目标版本，路径要和主程序的实际安装目录一致，否则会出现“升级成功但服务起不来”；目标版本要和组件包版本严格对应，不要手填一个更高的版本号企图“一次到位”。升级完成后，图 4 那个核对界面里的版本号、组件版本、校验值三项都要对上，只对上版本号不算通过。

3.4 产品注册：绑定主机指纹，改 IP 会失效

手册图 5 和表 5 是产品注册环节。注册的本质是把授权信息和这台主机的指纹绑定，指纹通常由主机名、主网卡 MAC、业务 IP 这类信息组合而成。这带来两个直接后果：一是克隆虚拟机批量部署时，必须每台单独注册，不能复制注册文件；二是装完之后如果改了 IP 或主机名，注册可能失效，表现是服务正常跑但装置侧不认。

离线环境的常见做法是导出设备指纹，拿到能访问授权服务的机器上换回注册码，再导回本机。这个流程里最容易错的是导出时机：一定要在主机名、IP 都定好之后再导出，先导出后改网络，等于白做。注册失败的排查顺序是先看时间是否同步、再看指纹信息是否与登记一致、最后看授权是否在有效期内，这三条能覆盖绝大多数情况。

4. 图形化与命令行配置：同一套参数的两种入口

手册第 6 章图形化配置和第 7 章命令行配置，内容是对应的：产品认证、主机通讯地址、网络白名单、关键目录文件、审计规则、服务端口、服务名称黑名单、关键系统命令名单、检测周期，一共九类。图形化适合首次落地和演示，命令行适合批量部署和远程维护。两边改的是同一份配置，所以不存在“图形化配一遍、命令行再配一遍”的必要，选一个入口做到底就行。

4.1 图形化配置工具的入口与九个配置项

图形化配置工具的入口在应用菜单里，也可以直接拉起（具体路径以rpm -ql结果为准）：

# 图形化配置工具，路径按实际包内文件调整 /opt/kylin-probe/bin/probe-config-gui # 远程通过 X11 转发时，先确认 DISPLAY 有值 echo $DISPLAY

无桌面环境时，要么在控制台登录桌面会话，要么用 X11 转发，要么干脆走命令行配置。硬在没有 DISPLAY 的 SSH 会话里跑图形工具，报的是 GTK 初始化失败，这个错误和权限、依赖都没关系，纯属环境不对。

九个配置项的填法和后果，我整理成一张表，现场照着填能少走弯路：

4.2 主机通讯地址、网络白名单与服务端口白名单

这三项放在一起讲，因为它们共同决定“什么算正常”。主机通讯地址定义探针往哪送数据，网络白名单定义什么外联是允许的，服务端口白名单定义什么监听是允许的。三者的共同逻辑是白名单制：不在名单里的行为一律上报。

网络白名单容易出错的地方在匹配方向。探针监控的是主机的对外连接，所以白名单里应该写目的地址和目的端口，而不是本机地址。有的现场把本机 IP 段写进去，结果业务访问外部数据库照样告警，然后怀疑探针误报。掩码也要写对，10.20.30.0/24和10.20.30.0/255.255.255.0在多数工具里等价，但写成10.20.30.0/32就只放行一个地址。填完之后不要立刻下结论，等一个检测周期看日志，或者手动触发一次业务访问验证。

服务端口白名单对应的是手册表 9 和表 18。这一项的实用性很高：主机上跑着数据库、中间件，监听端口一堆，不登记就天天告警。我一般按ss -lntp的实际输出逐个登记，只登记0.0.0.0和业务 IP 上的监听，127.0.0.1上的本地回环端口根据实际策略决定是否纳入。登记完保留一份清单，重装时直接对照，比重新梳理一遍快得多。

4.3 关键目录、审计规则与检测周期

关键目录文件对应手册表 8 和表 16。选择原则是“静态、少变、重要”：/etc、/boot、/usr/bin、/usr/sbin这类目录该监控，/var/log、/tmp、/run、/proc、/sys这类持续变化的目录必须排除。见过一个现场把整个/var加进去，结果日志轮转一次就产生几千条变更告警，装置侧直接被淹没，真正重要的/etc/passwd变更反而没人看。

审计规则对应表 8 和表 17。一条完整规则至少包含四个要素：监控路径、操作类型（读、写、属性变更、删除）、监控用户范围、是否递归子目录。只填路径不选操作类型是最常见的错，规则看起来加上了，实际采集端不知道要抓什么事件。用户权限变更类告警（比如有人改了 sudoers 或者给普通用户加了组）依赖的就是这一层规则，规则没配对，手册表 33 那类日志永远测不出来。

检测周期对应表 22。这一项没有标准答案，要给一个能落地的参考：采集上报周期按 1 到 5 分钟，完整性比对按 5 到 30 分钟，基线核查按天。周期越短发现越快，资源占用和告警量也越高。主机负载本来就高的时候，把周期压到 30 秒，CPU 会明显上去，日志量也会成倍增长。我的做法是先按推荐值上线观察一天，看 CPU 和日志增长量，再决定要不要调整，而不是一上来就拉满。

4.4 命令行等效配置与生效验证

命令行配置对应手册第 7 章，配置项和图形化一一对应，区别是配置文件位置和重载方式。改配置文件之前先备份，改完之后用重载而不是重启，能避免采集中断：

# 备份当前配置，改坏了能立刻回退 cp -a /etc/kylin-probe/ /etc/kylin-probe.bak.$(date +%F) # 只读方式查看当前生效配置，确认改的是哪一段 probe-cli config show --section network # 导入一份整理好的白名单，批量场景比手工点界面快 probe-cli config import --section whitelist --file /root/whitelist.conf # 重载配置，不中断采集进程 systemctl reload kylin-agent

几点说明。第一，命令行工具的准确名称以rpm -ql列出的可执行文件为准，手册第 7 章给的是等效顺序，不同版本可能有细微差别，用之前先--help看一眼。第二，reload不是所有配置都支持热加载，涉及采集模块参数变更时该重启还是要重启，改完用systemctl status看有没有报错。第三，改完必须回读验证：图形化改的在命令行show一遍，命令行改的在图形界面里看一眼，两边一致才算生效。只改不验，等告警测试失败再回头找，成本高得多。

5. 常见问题排查：五条现场翻车记录

这一章是整份手册里最值钱的部分，因为它对应的是文档没写、但现场一定会遇到的情况。下面五条都是我自己或者同行踩过的，按“现象 → 原因 → 解决”写，遇到同类问题时可以直接对照。

5.1 五条高频故障的现象、原因与处理

第一条：装完探针，装置侧一直显示离线。现象是本机服务 running、端口在监听、日志也在滚，但装置管理界面上设备状态是灰的。原因九成出在主机通讯地址填错——填了127.0.0.1、填了容器网桥地址、或者多网卡主机填了装置路由不到的网段。解决方式是先用ip route get <装置IP>确认源地址，再把这个源地址填进主机通讯地址，改完reload，然后在主机上nc -vz打一次装置端口，最后看探针日志里有没有上报成功的记录。

第二条：白名单加了，照样报非法外联。现象是明明把对端 IP 加进了白名单，告警还是一条接一条。原因通常是匹配方向配反了，白名单要写目的地址端口，写成本机地址等于没配；另一种是掩码写成了/32，实际业务走的是整个网段。解决方式是抓一次实际连接看五元组，ss -tnp看目的地址和端口，按实际值重配，配完等一个检测周期再观察，别改完立刻断言无效。

第三条：关键目录告警刷屏，一天几千条。现象是装置侧关键目录变更类告警量异常大，翻进去看全是/var/log下的日志文件。原因是监控目录选得太宽，把持续写入的动态目录纳进了完整性监控。解决办法是把/var/log、/tmp、/run、/proc、/sys、/dev/shm全部排除，只保留/etc、/boot、/usr/bin这类静态目录；已经产生的历史告警在装置侧做一次清理，避免干扰后续判断。

第四条：USB、串口、光驱告警测不出来。现象是插了 U 盘、插了串口设备，探针日志里什么都没有。原因有三层：内核审计子系统没开或规则没覆盖到设备节点、测试时用的是挂载镜像而不是真实物理设备、检测周期太长还没跑到。解决顺序是先确认审计服务在跑，再确认规则里包含设备相关路径，最后用真实 U 盘插拔测试并等一个周期。用虚拟机做测试时尤其要注意，USB 设备要真正透传给虚拟机，只在宿主机上插是测不到的。

第五条：检测周期调小后 CPU 飙高、告警风暴。现象是把周期从 5 分钟改成 30 秒之后，主机负载明显上升，装置侧告警量翻了好几倍重复条目。原因是采集频率和受监控目录规模不匹配，目录越大，单次比对开销越高，短周期还会让同一次变更在多个周期里重复上报。解决办法是先把目录收敛到最小必要集合，再把周期调回 1 到 5 分钟区间，重复告警通过装置侧的聚合规则处理，而不是靠拉长周期硬压。

5.2 卸载与重装：不清残留，重装必翻车

手册第 9 章讲的是程序卸载，很多人做实验装坏了就直接重装，结果端口被占、配置串味、服务起两个。正确的卸载顺序是：先停服务，再执行卸载，再清理残留配置和日志目录，再确认端口释放，最后才重新安装。

# 1. 先停服务，避免卸载时文件被占用 systemctl stop kylin-agent systemctl disable kylin-agent # 2. 卸载包，-e 后跟包名，不知道包名就先查 rpm -qa | grep -i kylin rpm -e kylin-probe # 3. 确认端口已释放，还有监听说明进程没退干净 ss -lntp | grep -E ':(8443|9000)\b' # 4. 残留目录按需清理，配置目录建议先改名而不是直接删 mv /etc/kylin-probe /etc/kylin-probe.removed.$(date +%F)

第三步是关键。rpm -e成功但进程还在的情况并不少见，尤其是升级失败后残留的子进程，这时候直接重装会出现新旧进程抢同一个端口，表现为服务起不来但日志里没有明显错误。第四步用改名而不是删除，是给自己留后悔药——重装后如果发现某条审计规则忘了备份，还能从旧目录里捞回来。

注意：卸载前一定要把白名单、审计规则、关键目录清单导出。这三样东西重配一遍至少半小时，而导出只要一条命令。

5.3 排查的基本顺序：先本地、再链路、后平台

新手排查最容易犯的错是一上来就怀疑装置侧平台，实际上大部分问题在探针本地就能看到。我的固定顺序是三步：第一步看探针服务状态和本地日志，确认事件到底采没采到；第二步看上报链路，nc打端口、看日志里有没有发送失败的记录；第三步才去装置侧看设备状态和告警列表。

本地日志一般落在/var/log下以探针命名的目录里，采集日志、上报日志、配置加载日志经常是分开的几个文件。先用tail -f盯采集日志，做一次触发动作，看有没有对应条目产生；有采集无上报，问题在网络和地址配置；无采集，问题在规则和权限。这个二分法能砍掉一大半无效排查。

6. 告警测试怎么验：从 SSH 登录到基线核查走一遍闭环

手册第 8 章列了十几类告警测试，从 SSH 登录成功、退出、失败，到命令回显、USB、串口、光驱、非法外联、非法端口、网口 up/down、关键目录变更、用户权限变更、危险命令、设备上线离线、基线核查。这些测试项不是让你一条条点过去，而是构成一个验证闭环：本地采到了、上报成功了、装置侧展示正确了，三段都通才算这项功能可用。

我的做法是先做三条基础用例，把链路打通，再批量跑剩下的。基础用例选 SSH 登录成功、危险命令执行、关键目录变更，因为它们分别覆盖登录类、命令类、文件类三条不同的采集路径，一条通不代表另外两条通。

跑这些用例有一个技巧：一次只改一个变量。同时插 U 盘又改配置文件，日志里混着多条事件，出问题时说不清是哪条没采到。另外时间点要记下来，本地日志和装置侧事件按时间对齐，差几分钟还能接受，差几小时就是时间同步的问题，回到第 2 章那三条硬门槛去查。

还有一个容易被忽略的验证点：测试完成后把测试产生的告警清理掉，或者至少在装置侧标注为测试数据。不然过几天做真实告警分析时，一堆测试记录混在里面，排查成本直线上升。我吃过这个亏，一次批量测试往装置里灌了几百条测试告警，后面做统计时全得手工剔除。从那以后我每次跑告警测试都先建一个测试时间窗口，测完立刻导出清单并在装置侧做标记，再开始正式业务观察。希望这些能帮到你，少走几段我走过的弯路。

本文还有配套的精品资源，点击获取