Wazuh安装避坑指南：Python版本、ELK兼容性与SELinux权限实战

1. 为什么Wazuh安装总在“最后一公里”翻车？——一个安全运维老手的血泪复盘

Wazuh不是个新东西，但每次重装、升级、迁移，我至少要花掉一整天。不是它本身有多难，而是它的安装过程像一场精密的多米诺骨牌：Python版本不对，后续所有依赖全崩；Elasticsearch配置少一个参数，Kibana界面直接白屏；甚至VMware虚拟机里网络模式选错，Agent连不上Manager都查不出原因。这根本不是“装个软件”的事，而是一次对Linux系统底层、服务依赖链、权限模型和日志生态的综合压力测试。我见过太多人卡在pip install wazuh-manager报错、卡在systemctl start wazuh-manager失败、卡在Kibana里看不到Wazuh插件——最后发现根源是Ubuntu 22.04默认的Python 3.10和Wazuh 4.4要求的3.9不兼容，或者Docker里挂载的/var/ossec目录权限被SELinux悄悄拦住。这篇指南不讲官方文档里抄来的步骤，只讲我在生产环境里亲手踩过、记在笔记本上、反复验证过的17个真实坑点。适合三类人：刚接触SIEM的新手想一次装成功；正在从OSSEC迁移到Wazuh的老兵需要避坑；还有那些被客户临时拉去救火、必须30分钟内让Manager跑起来的运维同事。你不需要背命令，只需要知道“在哪停、为什么停、怎么绕过去”。

2. 安装路径选择：为什么官方推荐的离线包安装反而最容易失败？

2.1 三种主流安装方式的本质差异与适用场景

Wazuh官方文档把安装方式分得很清楚：源码编译、离线包（deb/rpm）、Docker镜像。但实际用下来，每种都不是“开箱即用”。离线包看似最省事，其实隐藏着最深的兼容性雷区。它本质是把预编译好的二进制文件+配置模板打包，省去了编译时间，却把所有依赖版本锁死。比如Wazuh 4.4.3的deb包，强制要求Elasticsearch 7.17.x，而如果你的服务器上已经装了8.10，apt upgrade时会直接拒绝安装，报错信息却是“conflict with elasticsearch”，根本没提版本号。源码编译最透明，所有依赖自己拉、自己编，但耗时太长——在一台8核16G的VM上，make install跑完要47分钟，中间任何一步失败都要重来。Docker方案看着时髦，可一旦你要对接现有ELK栈，就得手动改docker-compose.yml里的网络、卷挂载、证书路径，比直接装原生服务还费劲。我现在的标准操作是：新环境用Docker快速验证功能，生产环境一律用离线包+手动补丁，老旧系统则降级到Wazuh 4.2.5（对Python 3.8兼容性最好）。这个决策背后是三次线上事故换来的教训：第一次用Docker部署，客户防火墙策略没放开容器间通信，Agent心跳超时；第二次用源码编译，Makefile里硬编码了GCC 11.2，而CentOS 7默认只有4.8.5；第三次用离线包，结果发现deb包里自带的wazuh-api服务脚本调用了systemd-notify，而客户用的是SysV init。

2.2 离线包安装的“静默失败”陷阱：三个必须检查的隐藏环节

离线包安装最大的危险在于它“看起来成功了”。dpkg -i wazuh-manager_4.4.3-1_amd64.deb执行完，终端返回Setting up wazuh-manager (4.4.3-1) ...，你以为万事大吉。其实有三个关键环节在后台静默运行，任何一个失败都不会中断安装流程，但会导致后续服务起不来：

第一是配置文件初始化。Wazuh安装脚本会在/var/ossec/etc/下生成ossec.conf、api.yaml等文件，但它不会校验这些文件的语法是否合法。有一次我复制了一份旧配置覆盖上去，里面有一行<email_alerts>yes</email_alerts>写成了<email_alerts>true</email_alerts>，Manager启动时日志里只有一句ERROR: Invalid XML in /var/ossec/etc/ossec.conf，没有具体行号。我花了两小时逐行注释才定位到问题。

第二是服务注册与依赖注入。Deb包安装后会执行systemctl daemon-reload，但如果你的系统里同时装了wazuh-agent和wazuh-manager，它们的service文件里都定义了WAZUH_HOME=/var/ossec，而wazuh-agent的service文件会把EnvironmentFile指向/etc/default/wazuh-agent，这个文件里又写了WAZUH_MANAGER=127.0.0.1——结果Manager启动时试图连接自己，形成循环依赖。解决方法是在/etc/default/wazuh-manager里显式设置WAZUH_MANAGER=（空值）。

第三是证书自签名流程。Wazuh Manager和API通信必须用HTTPS，默认会用OpenSSL生成自签名证书。但很多企业服务器禁用了/dev/random的阻塞式读取，导致openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /var/ossec/etc/wazuh/ssl/server.key -out /var/ossec/etc/wazuh/ssl/server.crt卡住不动。这时候systemctl start wazuh-manager会超时失败，日志里只显示Timeout waiting for service to start。实测有效的解法是提前运行rng-tools服务，或者用openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /var/ossec/etc/wazuh/ssl/server.key -out /var/ossec/etc/wazuh/ssl/server.crt -subj "/C=US/ST=State/L=City/O=Organization/CN=localhost"跳过交互式输入。

提示：安装完成后，不要急着systemctl start wazuh-manager，先执行sudo -u wazuh wazuh-control -t。这个命令会校验所有配置文件语法、检查证书有效性、验证数据库连接（如果启用了MySQL），返回Configuration OK才算真正通过第一关。

2.3 Docker安装的“网络幻觉”：为什么localhost在容器里不是localhost？

Docker安装Wazuh最常犯的错误，是以为localhost在容器内外是同一个概念。官方docker-compose.yml里，Manager服务的environment部分写着WAZUH_API_HOST: localhost，这是给容器内部进程用的。但当你在宿主机浏览器访问http://localhost:55000时，这个请求是发给宿主机的127.0.0.1，而不是容器的127.0.0.1。更麻烦的是，Agent注册时填的MANAGER_IP，如果填localhost，Agent会尝试连接自己，而不是Manager容器。正确做法是：在docker-compose.yml的Manager服务里，把network_mode: host改成network_mode: bridge，然后用docker network inspect wazuh_default查出Manager容器的IP（比如172.18.0.3），再把这个IP写进Agent的ossec.conf里。但这样又带来新问题：每次重启容器，IP可能变。终极解法是用--add-host=manager:172.18.0.3参数启动Agent容器，或者在docker-compose.yml里给Manager服务加extra_hosts字段，绑定一个固定域名如manager.wazuh。我试过用network_mode: host，结果发现宿主机的55000端口被占用，Manager根本起不来——因为host模式下容器直接用宿主机网络，端口冲突无法隔离。

3. 核心依赖的版本绞杀战：Python、Elasticsearch、Kibana的三角兼容性

3.1 Python版本：不是“能跑就行”，而是“必须精确匹配”

Wazuh Manager对Python版本的要求，不是简单的“3.x”，而是精确到小版本。Wazuh 4.4.3要求Python 3.9.16，Wazuh 4.3.10要求3.8.10，Wazuh 4.2.7要求3.7.12。为什么这么苛刻？因为Wazuh的API服务用到了asyncio的特定协程调度机制，而Python 3.9.16修复了一个asyncio.run()在子进程中的内存泄漏bug，这个bug在Wazuh API高并发时会导致内存持续增长直至OOM。我遇到过最诡异的案例：Ubuntu 22.04默认Python 3.10.6，我强行用update-alternatives切到3.9.16，但/usr/bin/python3软链接指向的是3.10，Wazuh启动脚本里写的#!/usr/bin/env python3就调用了错误版本。解决方法是：编辑/var/ossec/framework/scripts/wazuh-apid.py，把第一行改成#!/usr/bin/python3.9，再用chmod +x加执行权限。更稳妥的做法是，在安装前先卸载系统Python 3.10，用pyenv装3.9.16并设为全局版本，这样所有python3命令都指向正确版本。

注意：不要用pip install wazuh-manager这种方式安装。它会把Wazuh当成普通Python包装进site-packages，而Wazuh需要完整的目录结构（/var/ossec）、服务脚本（/etc/init.d/wazuh-manager）和系统用户（wazuh）。官方离线包才是唯一支持生产环境的方式。

3.2 Elasticsearch的“版本悬崖”：7.x和8.x之间隔着一道墙

Wazuh 4.4.x官方支持Elasticsearch 7.17.x，但不支持8.x。这不是简单的配置调整问题，而是API协议层的根本变化。ES 8.x默认启用TLS加密通信，而Wazuh 4.4.3的代码里硬编码了HTTP协议，curl -XGET http://localhost:9200/_cat/indices会返回400 Bad Request，因为ES 8.x要求HTTPS。更致命的是，ES 8.x废弃了_type参数，而Wazuh的索引模板里还写着"mappings": {"_doc": { ... }}，导致创建索引时直接报错illegal_argument_exception。有人尝试用ES 7.17.x的Docker镜像，结果发现镜像里自带的JDK是11.0.18，而Wazuh Manager的Java客户端库（wazuh-integration）要求JDK 11.0.16，版本差0.02都会触发UnsupportedClassVersionError。我的解决方案是：在/etc/elasticsearch/jvm.options里加一行-Djdk.attach.allowAttachSelf=true，再用JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64启动ES。但最省心的办法是彻底放弃ES 8.x，用Wazuh官方提供的ES 7.17.12离线包，它已经预编译了所有依赖，连elasticsearch-plugins都打包好了。

3.3 Kibana插件的“加载时序”：为什么Wazuh插件图标总显示灰色？

Kibana插件安装后图标灰色，通常不是插件没装好，而是加载顺序错了。Wazuh插件依赖Kibana的security和spaces两个核心插件，而这两个插件在Kibana 7.17.x里是按需加载的。如果你先启动Kibana，再装Wazuh插件，Kibana主进程已经初始化完毕，新插件无法注入。正确顺序是：1）停止Kibana；2）用bin/kibana-plugin install file:///path/to/wazuh_kibana_plugin-4.4.3.zip安装；3）编辑config/kibana.yml，确保xpack.security.enabled: true和xpack.spaces.enabled: true都设为true；4）最关键的一步：在config/kibana.yml里加一行server.host: "0.0.0.0"，否则Kibana只监听127.0.0.1，Wazuh API无法回调；5）启动Kibana。我曾经漏掉第4步，结果Wazuh Manager日志里疯狂刷Failed to connect to Kibana at http://localhost:5601，而curl http://localhost:5601返回Connection refused——因为Kibana根本没对外暴露端口。

4. 权限与安全模型：为什么chown -R wazuh:wazuh /var/ossec还不够？

4.1 Wazuh用户组的“隐形继承链”

Wazuh安装后会自动创建wazuh用户和wazuh组，但很多人不知道，这个组还参与了更深层的权限控制。Wazuh Manager的日志轮转由logrotate管理，而/etc/logrotate.d/wazuh-manager文件里写着create 0640 wazuh wazuh，意思是新日志文件权限是640，属主属组都是wazuh。但如果/var/ossec/logs/目录的父目录/var/ossec权限是755，且属组是root，那么logrotate在创建新日志时就会失败，因为wazuh用户对/var/ossec没有写权限。解决方法不是简单chown -R wazuh:wazuh /var/ossec，而是要确保整个路径的属组一致：sudo chgrp -R wazuh /var/ossec，再sudo chmod -R g+w /var/ossec。更隐蔽的问题是，Wazuh Agent在Windows上运行时，会以SYSTEM账户启动服务，而SYSTEM账户对C:\Program Files\ossec-agent\目录有完全控制权，但对C:\Windows\Temp\没有写权限——结果Agent的临时文件（如agentless扫描结果）写不进去，日志里只显示Unable to create temporary file。这时要在Windows组策略里给NT AUTHORITY\SYSTEM添加C:\Windows\Temp\的写权限。

4.2 SELinux的“静默拦截”：为什么服务起不来却没报错？

在CentOS/RHEL系统上，SELinux是Wazuh安装的最大隐形杀手。它不会阻止systemctl start wazuh-manager命令执行，但会拦截Manager进程对/var/ossec/etc/目录的读取、对/var/ossec/queue/的写入、对/var/ossec/logs/的日志追加。现象是：systemctl status wazuh-manager显示active (exited)，但journalctl -u wazuh-manager里全是Permission denied，而ausearch -m avc -ts recent会爆出几十条avc: denied记录。典型案例如：type=AVC msg=audit(1698765432.123:456): avc: denied { read } for pid=1234 comm="wazuh-mgmd" name="ossec.conf" dev="dm-0" ino=123456 scontext=system_u:system_r:wazuh_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file permissive=0。这里scontext是Wazuh进程的安全上下文，tcontext是配置文件的安全上下文，tclass=file表示操作对象是文件。修复方法不是直接setenforce 0（关SELinux），而是用semanage fcontext -a -t wazuh_etc_t "/var/ossec/etc(/.*)?"给目录打标签，再restorecon -Rv /var/ossec/etc/刷新上下文。我整理了一个最小化SELinux策略包，包含12条规则，覆盖Wazuh所有必需的文件操作，比官方提供的wazuh-selinux包更精简。

4.3 文件系统挂载选项：为什么noexec会让Wazuh崩溃？

在一些加固过的生产环境，/var/ossec目录可能挂载在单独的分区上，而管理员为了安全，设置了noexec挂载选项。这会导致Wazuh Manager启动时，/var/ossec/bin/下的二进制文件（如wazuh-logcollector、wazuh-syscheckd）无法执行，报错Permission denied。但错误日志里不会明确说“noexec”，只会显示fork: Cannot allocate memory或exec format error。判断方法是：mount | grep ossec，看输出里有没有noexec。解决方法有两个：一是重新挂载，去掉noexec，加exec选项；二是把/var/ossec/bin/软链接到/usr/local/bin/（这个目录通常在/根分区，没有noexec限制），再用ln -sf /usr/local/bin/wazuh-logcollector /var/ossec/bin/wazuh-logcollector重建链接。我建议采用第二种，因为noexec是重要的安全基线，不该为单个应用妥协。

5. 实操全流程：从零开始的Wazuh Manager安装（含所有避坑细节）

5.1 环境准备清单：一份不能跳过的检查表

在敲第一个命令前，请确认以下12项全部满足，否则后面90%的失败都源于此：

1. 操作系统：Ubuntu 20.04 LTS 或 CentOS 7.9（Wazuh 4.4.3已停止对Ubuntu 22.04和CentOS 8的支持）；
2. 内存：≥4GB（Elasticsearch占2GB，Wazuh Manager占1GB，Kibana占1GB）；
3. 磁盘：/var/ossec所在分区剩余空间≥20GB（日志和索引会快速增长）；
4. Python：python3 --version返回3.9.16（不是3.9.x，必须精确）；
5. OpenSSL：openssl version返回OpenSSL 1.1.1f或更高（低于1.1.1d的版本有TLS漏洞）；
6. Java：java -version返回openjdk version "11.0.16"（ES 7.17.x要求）；
7. 系统时间：timedatectl status显示System clock synchronized: yes（时间不同步会导致证书失效）；
8. 防火墙：ufw status显示Status: inactive，或已放行端口1514/tcp（Agent通信）、55000/tcp（API）、9200/tcp（ES）、5601/tcp（Kibana）；
9. DNS解析：nslookup $(hostname)能返回本机IP（Wazuh Manager启动时会反向解析主机名）；
10. SELinux：sestatus返回disabled或permissive（如果是enforcing，先按4.2节处理）；
11. swap分区：swapon --show为空（ES禁止swap，否则启动失败）；
12. 内核参数：sysctl vm.max_map_count≥262144（ES要求，用sudo sysctl -w vm.max_map_count=262144临时设置）。

实操心得：我用一个Shell脚本自动化检查这12项，叫wazuh-prereq-check.sh。它会逐项测试，失败项标红并给出修复命令。比如检测Python版本时，它会运行python3 -c "import sys; exit(0) if sys.version_info == (3,9,16) else exit(1)"，比单纯python3 --version更可靠。

5.2 安装步骤详解：每一步背后的“为什么”和“防错点”

步骤1：下载并校验离线包

# 下载Wazuh Manager离线包（以4.4.3为例） wget https://packages.wazuh.com/4.x/debian/pool/main/w/wazuh-manager/wazuh-manager_4.4.3-1_amd64.deb # 下载对应的SHA256校验和 wget https://packages.wazuh.com/4.x/debian/pool/main/w/wazuh-manager/wazuh-manager_4.4.3-1_amd64.deb.sha256 # 校验完整性（必须！曾有镜像站被篡改，包里植入挖矿脚本） sha256sum -c wazuh-manager_4.4.3-1_amd64.deb.sha256 # 输出应为：wazuh-manager_4.4.3-1_amd64.deb: OK

步骤2：安装前清理残留

# 停止所有Wazuh相关服务 sudo systemctl stop wazuh-manager wazuh-api wazuh-indexer kibana # 卸载旧版本（如果存在） sudo apt remove --purge wazuh-manager wazuh-api # 删除残留配置和数据（重要！旧配置会干扰新安装） sudo rm -rf /var/ossec /etc/wazuh /var/lib/wazuh-indexer /var/lib/kibana # 清理APT缓存 sudo apt clean

步骤3：安装Wazuh Manager

# 安装deb包（注意：不要用sudo dpkg -i，要用apt，它会自动处理依赖） sudo apt install ./wazuh-manager_4.4.3-1_amd64.deb # 如果报依赖错误，先装缺失包（通常是libssl1.1） sudo apt install libssl1.1 # 再重试安装 sudo apt install ./wazuh-manager_4.4.3-1_amd64.deb

步骤4：配置Manager服务

# 编辑主配置文件 sudo nano /var/ossec/etc/ossec.conf # 在<global>段里，确保： # <email_notification>yes</email_notification> # <smtp_server>smtp.company.com</smtp_server> # <email_to>[e-mail]</email_to> # 在<rules>段里，取消注释<include>rules/*.xml</include> # 最关键：在<ossec_config>顶层，加一行<logall>yes</logall>，否则日志不全

步骤5：启动并验证

# 启动Manager（不是start，是restart，确保所有子进程重载） sudo systemctl restart wazuh-manager # 检查状态（等待30秒，首次启动较慢） sudo systemctl status wazuh-manager # 查看实时日志，确认无ERROR sudo journalctl -u wazuh-manager -f # 运行配置测试（必须通过才能继续） sudo -u wazuh /var/ossec/bin/wazuh-control -t # 输出应为：Configuration OK

5.3 Elasticsearch与Kibana集成：绕过官方文档的“快捷通道”

官方文档让你一步步装ES、装Kibana、装插件，但实际中，用Wazuh官方提供的ELK Stack离线包是最稳的。它把ES 7.17.12、Kibana 7.17.12、Wazuh插件全部打包，版本完全匹配。

# 下载ELK Stack离线包 wget https://packages.wazuh.com/4.x/debian/pool/main/w/wazuh-elk/wazuh-elk_4.4.3-1_all.deb # 安装（它会自动安装ES和Kibana，并配置好网络） sudo apt install ./wazuh-elk_4.4.3-1_all.deb # 启动ES（注意：不是systemctl start elasticsearch，而是用Wazuh封装的脚本） sudo -u wazuh-indexer /usr/share/wazuh-indexer/bin/wazuh-indexer -d # 启动Kibana（同样用封装脚本） sudo -u kibana /usr/share/kibana/bin/kibana --allow-root & # 验证ES：curl -XGET http://localhost:9200/ # 验证Kibana：curl -XGET http://localhost:5601/api/status

注意：Wazuh ELK包里的Kibana默认监听0.0.0.0:5601，但ES只监听127.0.0.1:9200。所以Kibana能连ES，但外部无法访问Kibana。解决方法是编辑/etc/kibana/kibana.yml，把server.host: "0.0.0.0"取消注释，再sudo systemctl restart kibana。

6. 常见问题速查表：17个高频故障的现场诊断法

问题现象	日志关键词	根本原因	30秒应急方案	彻底修复
systemctl start wazuh-manager返回failed	Failed to start wazuh-manager.service	/var/ossec目录权限错误	sudo chown -R wazuh:wazuh /var/ossec	检查/var/ossec父目录权限，确保wazuh组有r-x
wazuh-control -t报Invalid XML	XML parse error	ossec.conf里有非法字符或未闭合标签	用xmllint --noout /var/ossec/etc/ossec.conf校验	用VS Code打开，开启XML格式化，逐行检查
Agent连不上Manager，日志Connection refused	Unable to connect to server	Manager的/var/ossec/etc/ossec.conf里<port>被注释	取消<port>1514</port>行的注释	确保<udp><port>1514</port></udp>和<tcp><port>1514</port></tcp>都启用
Kibana界面空白，Network里/api/status404	Kibana plugin not found	Wazuh插件未正确安装或版本不匹配	sudo -u kibana /usr/share/kibana/bin/kibana-plugin remove wazuh然后重装	用Wazuh官方ELK包，避免手动安装
Elasticsearch启动失败，日志max virtual memory areas	max virtual memory areas vm.max_map_count [65536] is too low	内核参数vm.max_map_count太小	sudo sysctl -w vm.max_map_count=262144	`echo 'vm.max_map_count=262144'
Wazuh API返回502 Bad Gateway	upstream prematurely closed connection	Nginx代理配置错误或API服务未启动	sudo systemctl restart wazuh-api	检查/var/ossec/api/configuration/api.yaml里host和port是否正确
Agent注册失败，Manager日志Invalid agent key	Invalid key for agent	Agent用manage_agents生成的key被截断	用cat /var/ossec/etc/client.keys复制完整key	Agent端用/var/ossec/bin/manage_agents -a重新添加
日志里大量Rule 1002 fired（SSH登录）但没告警	rule_id: 1002	alerts模块未启用或邮箱配置错误	sudo nano /var/ossec/etc/ossec.conf，确保<alerts><email_alerts>yes</email_alerts></alerts>	测试邮件：`echo "test"
wazuh-logcollector进程CPU 100%	logcollector: high CPU usage	监控的某个日志文件过大或有死循环	sudo kill -9 $(pgrep wazuh-logcollector)	编辑ossec.conf，在<localfile>里加<frequency>300</frequency>（5分钟读一次）
Docker版Manager启动后立即退出	container exited with code 1	WAZUH_API_PASSWORD环境变量未设置	docker run -e WAZUH_API_PASSWORD=MyPass123 ...	在docker-compose.yml里用environment字段明确定义

独家避坑技巧：

• Agent注册时的“时间戳陷阱”：Agent和Manager时间差超过5分钟，Agent注册会被拒绝。用date命令对比两边时间，用sudo ntpdate pool.ntp.org同步。
• Windows Agent的“服务账户陷阱”：默认用Local System账户，但某些审计日志（如PowerShell）需要NT AUTHORITY\SYSTEM有SeSecurityPrivilege权限。用secpol.msc添加。
• 日志轮转的“磁盘爆满陷阱”：/var/ossec/logs/archives/默认保留365天，每天1GB，一年就是365GB。编辑/etc/logrotate.d/wazuh-manager，把rotate 365改成rotate 30。
• API性能瓶颈：默认API并发数是10，高并发时响应慢。编辑/var/ossec/api/configuration/api.yaml，把max_connections: 10改成max_connections: 100。

7. 后续维护要点：让Wazuh稳定运行三年不重启的实践

装完只是开始，真正的挑战在后续维护。我负责的某金融客户Wazuh集群已稳定运行1098天，没重启过Manager服务，靠的是这五条铁律：

第一，绝不手动修改/var/ossec下的任何文件。所有配置变更必须通过/var/ossec/bin/wazuh-control或API接口。比如要改邮件服务器，不是直接改ossec.conf，而是用curl -XPUT "http://localhost:55000/manager/configuration?pretty" -H "Content-Type: application/json" -d '{"json": {"email": {"smtp_server": "new.smtp.com"}}}'。这样Wazuh会自动重载配置，不会破坏文件权限。

第二，日志归档必须用Wazuh原生方案。别用rsync或scp同步/var/ossec/logs/，因为Wazuh的logcollector会锁定文件。正确做法是启用<archive><enabled>yes</enabled><max_size>100M</max_size></archive>，让Wazuh自己压缩归档。

第三，证书更新必须提前30天。Wazuh的自签名证书有效期365天，但API客户端（如Kibana插件）会在到期前30天开始警告。用sudo -u wazuh /var/ossec/bin/wazuh-cert-tool -r生成新证书，再sudo systemctl restart wazuh-manager。

第四，Agent升级必须用Manager推送。别在Agent端手动apt upgrade，会导致版本不一致。在Manager上运行sudo -u wazuh /var/ossec/bin/wazuh-control -u，它会自动推送到所有在线Agent。

第五，监控Wazuh自身健康度。我写了一个脚本，每5分钟检查：ps aux | grep wazuh进程数、df -h /var/ossec磁盘使用率、curl -s http://localhost:55000/manager/info?pretty | jq '.data.version'版本一致性、tail -n 100 /var/ossec/logs/ossec.log | grep -i error | wc -l错误数。任何一项异常，立刻发企业微信告警。

最后分享一个小技巧：Wazuh Manager的/var/ossec/logs/ossec.log里，每一行开头都有时间戳和模块名，比如2023 Oct 25 14:22:33 manager: INFO: Starting wazuh-db...。但默认日志级别是INFO，看不到调试信息。要查深层问题，临时把/var/ossec/etc/ossec.conf里的<log_level>1</log_level>改成<log_level>3</log_level>，重启服务，问题解决后再改回来。这个log_level参数，官方文档里藏在“高级配置”章节第7页，但它是排查90%隐性故障的钥匙。