Wazuh这套开源安全监控平台，功能确实能打，SIEM、入侵检测、日志审计、合规检查一把梭，但你要是从零开始自己装一遍，我敢说你大概率会在前三个小时里想砸键盘。别问我怎么知道的——我第一次布 Wazuh 的时候，从拿到官方文档到三个组件全部正常运行，断断续续折腾了差不多两个整天。而且最气人的是，装完回头看，基本都是些很小的问题：证书权限不对、内核参数没改、hosts 没写、防火墙悄悄挡了个端口，有的甚至就是拼写错误。这篇文章就是把我在 Wazuh 安装这条路上踩过的坑、反复排查的细节和最终跑通的方法，按阶段全部分享出来。如果你准备在自己服务器或者虚拟机里部署 Wazuh，这套实操笔记应该能帮你把安装周期从两天压缩到两小时。
1. 装 Wazuh 之前，先把这些底子打好
1.1 版本选择和操作系统兼容性，别到时候三个组件版本对不上
Wazuh 4.x 之后，官方把架构拆成了三大件：Wazuh Indexer（存储和检索数据，底层是 OpenSearch）、Wazuh Manager（负责 agent 管理、日志分析、告警生成）和 Wazuh Dashboard（可视化界面，底层是 OpenSearch Dashboards）。看起来是三件套，但它们的版本必须严格匹配。比如 4.8 系列的 Indexer 配 4.8 的 Manager，filebeat 也要用 4.8 的模板，dashboard 同样要 4.8。你如果贪图省事，直接用系统里的 OpenSearch 旧版本混搭，大概率会在启动阶段因为字段模板不兼容报一堆解析错误。
操作系统方面，官方支持 RHEL 系和 Debian 系的主流版本，比如 CentOS 7/8、Rocky Linux、Ubuntu 20.04/22.04、Debian 11 等。我的建议是，新部署直接用 Rocky Linux 8 或者 Ubuntu 22.04 LTS，别再用 CentOS 7 了。Wazuh 4.8 以后的组件在 CentOS 7 上依赖系统 glibc 版本，有些前端库和服务跑起来会诡异报错，排查半天才发现是系统太老。我自己测试环境分别装过 CentOS 7.9、Rocky 8.6、Ubuntu 20.04，综合体验最省心的是 Rocky 8。
还有一个容易踩的坑：如果你机器上已经装了独立的 Elasticsearch、OpenSearch 或者有服务占了 9200、9300 端口，务必先停掉或者卸载，否则 Indexer 启动时端口冲突，日志里会一直报Address already in use。Wazuh Indexer 用的就是 OpenSearch，它和系统里已有的 OpenSearch 实例会抢资源，不能用“双开”的思路。
1.2 资源评估：内存不够，一切白搭
官方给的 All-in-One 最低要求是 4GB 内存、2 核 CPU，但我说实话，这个配置只够“能启动”，完全谈不上“能用”。Wazuh Indexer 底层是 OpenSearch，本身 JVM 堆内存就要占 2G 到 4G，再叠加 Dashboard 的 Node 进程、Manager 的分析引擎，4G 内存跑起来动不动就 OOM，最明显的表现就是服务进程还在，但 Web 界面卡死，或者 agent 的日志发过来就丢，过几分钟 Indexer 就挂一次。
如果你想在自己电脑上用虚拟机做测试，建议至少分配 6G 到 8G 内存。硬盘方面，SSD 是刚需。Indexer 的数据目录默认在/var/lib/wazuh-indexer，即使只接入一台测试主机，几天下来告警事件也有几百 MB 到几个 GB，机械硬盘跑 OpenSearch 的读写延迟会让你怀疑人生。另外安装包本身解压后占用不小，给/var分区至少留 30G 空间比较稳妥。
内存不足的另一个隐患是 swap 问题。Wazuh Indexer 默认配置里会开启bootstrap.memory_lock: true，也就是要求锁住内存，禁用 swap。这样做的好处是避免 GC 性能抖动，但前提是你的系统要允许进程锁定足够大的内存。如果/etc/security/limits.conf里的 memlock 没放开，Indexer 启动时就会报memory locking requested for opensearch process but memory is not locked，然后整个服务就在启动失败和重启循环里反复横跳。
1.3 系统初始化三件套：主机名、sysctl 和防火墙
部署 Wazuh 之前，先把系统底子收拾干净。第一件事是主机名。Wazuh Indexer 的集群发现机制会用到 hostname 解析，主机名最好只用字母、数字和短横线，千万别带下划线，不然 OpenSearch 在解析节点名时可能报非法字符。同时/etc/hosts里一定要有本机 IP 和主机名的对应关系，不然启动时network.host解析不到地址，服务直接起不来。
第二件事是改内核参数。最重要的一项就是vm.max_map_count，OpenSearch 要求这个值不能低于 262144，而大部分 Linux 系统默认只有 65530。不修改的话，Indexer 启动日志里会明确提示max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]。修改命令如下，需要切换到 root 用户执行：
sysctl -w vm.max_map_count=262144 echo 'vm.max_map_count=262144' >> /etc/sysctl.conf sysctl -p顺带把vm.swappiness调低一些，改为 1 或者 10，减少系统对 swap 的依赖。这个操作在内存小的机器上尤其管用。然后检查一下ulimit -l的值，如果 memlock 是 64KB，在/etc/security/limits.conf里给运行用户放开限制：
wazuh-indexer soft memlock unlimited wazuh-indexer hard memlock unlimited改完重启一下系统或者重新登录终端生效。第三件事是防火墙和 SELinux。如果你用的是 CentOS/Rocky 这类默认开启 SELinux 的系统，不想深入了解规则的话，测试环境直接setenforce 0是最省事的方案，但重启后会失效，需要同时修改/etc/selinux/config永久关闭。生产环境不建议这么干，但可以针对 9200、443、1514、1515、55000 这几个端口放行 SELinux 上下文，不过那一套规则配下来容易出错，所以我个人装机阶段都是先关掉，跑通了再慢慢收紧。
2. 安装方式选型和安装过程拆解
2.1 官方安装脚本：能把人坑哭的“黑盒”
Wazuh 官方网站提供了一键安装脚本，帮助文档看起来特别美好：下载一个脚本，敲几条命令，就自动生成证书、装好所有组件、配置好服务。实际跑起来，坑点非常密集。官方 All-in-One 安装脚本实际执行过程是这样拆分的：
curl -sO https://packages.wazuh.com/4.8/wazuh-install.sh bash wazuh-install.sh --generate-config-files bash wazuh-install.sh --wazuh-indexer node-1 bash wazuh-install.sh --start-cluster bash wazuh-install.sh --wazuh-server wazuh-1 bash wazuh-install.sh --wazuh-dashboard dashboard很多第一次接触的人以为执行一条bash wazuh-install.sh --all-in-one就完事了，但官方脚本实际还是分阶段执行的。最大的坑是--generate-config-files这一步：它会在当前目录生成一个wazuh-install-files.tar.gz压缩包，里面包含所有节点需要的证书和配置文件。如果你在中途因为断网、超时等原因中断了脚本，压缩包没生成就直接执行--wazuh-indexer node-1，脚本会报找不到wazuh-install-files.tar.gz，而且由于证书还没生成，后面所有组件都会卡在证书校验上。
我的建议是，一开始就把四步拆开来执行，一步一步看输出。每跑完一步，确认服务起来了再跑下一步。脚本执行完会在终端输出一大段内容，里面有 Dashboard 的访问地址、管理员账号和密码，还有用于 agent 登记的密码。这段输出别随手关掉，我就是因为没保存，后来要从日志里翻半天。如果真忘了，可以用官方工具重置：
bash /usr/share/wazuh-indexer/bin/wazuh-passwords-tool -a这个工具会把所有内置账号的密码重置，然后重新打印出来，前提是 Indexer 服务必须已经正常启动。
2.2 手动安装三件套：厘清组件依赖关系
如果你不想被脚本黑盒支配，可以选择手动安装。但手动安装对逻辑要求更高，你必须清楚三个组件的依赖关系。我的建议顺序是：Indexer → Manager → Filebeat → Dashboard，理由很简单：
- Indexer 是数据存储层，它最先启动，为后面的组件提供写入和查询接口；
- Manager 是数据生产层，agent 的数据、告警都汇总到它这里，但它需要 filebeat 帮它把数据推到 Indexer；
- Filebeat 是数据管道，安装 Manager 之后、Dashboard 之前配好；
- Dashboard 是展示层，它需要连接 Indexer 读取数据，最后装最合理。
手动安装时，系统里需要先配好 Wazuh 的软件源。以 Debian/Ubuntu 系为例：
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | apt-key add - echo "deb https://packages.wazuh.com/4.x/apt/ stable main" | tee /etc/apt/sources.list.d/wazuh.list apt-get updateRHEL 系的做法稍有不同，要把 GPG key 导入到 rpm 的 keyring，然后新建一个 repo 文件。第一次配源容易犯的错误是版本号写错，比如官方文档给你的可能是4.x通用源，而不是固定4.8版本。用4.x的写法，后面apt-get update不会报错，但实际拉取的软件包版本可能比你预期的要高或低，和手头其他组件版本不好对齐。建议直接写死大版本号，比如4.8，这样全链路版本一致，避免给后面的排障留坑。
2.3 Filebeat 配置：数据管道能不能通全看它
Manager 和 Indexer 都起来之后，Filebeat 是很多人忽略的一环。它的作用是把 Wazuh Manager 产生的告警和事件数据转发给 Indexer。如果你跳过 Filebeat，或者配错了 Filebeat 的输出地址，Dashboard 的界面能正常打开，但“安全事件”和“总览”页面永远只有零条数据，甚至会出现告警产生但数据检索不到的问题。
Filebeat 的配置文件在/etc/filebeat/filebeat.yml，需要检查的关键项是这几段：
output.elasticsearch: hosts: ["https://<indexer-ip>:9200"] protocol: https username: admin password: <admin-password> ssl: certificate_authorities: - /etc/filebeat/certs/root-ca.pem很多人会把hosts写成 manager 自己的地址，这就错了。Filebeat 的职责是把数据往 Indexer 送，你要写的是 Indexer 的 IP192.168.x.x和端口9200。另外，Filebeat 也要有自己的证书目录，路径在/etc/filebeat/certs/，里面至少要有root-ca.pem、filebeat.pem、filebeat-key.pem。如果你发现 Filebeat 启动日志里出现x509: certificate signed by unknown authority之类的报错，十有八九是 CA 证书路径写错，或者根本没把根证书拷到这个目录。把证书分发到 Filebeat 目录后，记得重启服务再观察日志。
3. 证书、配置和端口：安装期的三座大山
3.1 证书生成和分发，属主权限一定要看清楚
Wazuh 所有组件之间的通信都走 TLS，所以证书贯穿整个安装过程。官方脚本的--generate-config-files会在压缩包里放好 6 到 8 个证书文件，手动安装时也可以用官方证书工具生成：
bash /usr/share/wazuh-indexer/bin/wazuh-cert-tool.sh -A生成完以后，要把对应的证书分别拷贝到各个组件的 certs 目录下。这里最容易被忽略的是属主和权限问题。Indexer 的证书目录是/etc/wazuh-indexer/certs/，文件属主必须是wazuh-indexer:wazuh-indexer；Manager 的是/etc/wazuh-manager/certs/，属主是wazuh-manager:wazuh-manager；Dashboard 和 Filebeat 同理。如果你用 root 用户 scp 过去之后没改属主，服务进程会因为读不了私钥直接启动失败。修改命令通用写法是：
chown -R wazuh-indexer:wazuh-indexer /etc/wazuh-indexer/certs/ chmod 500 /etc/wazuh-indexer/certs/ chmod 400 /etc/wazuh-indexer/certs/*.pem权限建议统一压到 400 或 600。还有一个新手极易踩的坑：Dashboard 连接的 Indexer 如果用的是自签 CA，那么 root CA 文件必须和最初生成证书的那个完全一致。如果你在一次测试中分两批生成过证书，第二批证书的 CA 和第一批对不上，Dashboard 请求 Indexer 时会报 SSL 握手失败，日志里会看到OpenSearch Dashboards has not been configured to trust the OpenSearch backend之类的提示。解决办法只有一个：所有组件必须使用同一套 root CA。这也是为什么官方脚本把证书打包成一个 tar.gz 文件的原因——它就是强迫你所有节点使用同一套凭证。
3.2 opensearch.yml 和 jvm.options：改错一个参数就起不来
Indexer 的配置文件是/etc/wazuh-indexer/opensearch.yml。单机部署时，下面这几个参数是必须写对的：
network.host: 0.0.0.0 discovery.type: single-node bootstrap.memory_lock: true plugins.security.disabled: falsenetwork.host如果只写127.0.0.1，其他组件就访问不到它；写0.0.0.0表示监听所有网卡，最省事。discovery.type: single-node对单机部署很关键，不写的话它默认走集群发现流程，会一直找其他节点，启动过程可能卡住十五分钟。有一点要注意，plugins.security.disabled千万不要改成true。有人图省事关掉安全模块，想着测试环境无所谓，结果 Wazuh Dashboard 和 Filebeat 连接时全部因为鉴权失败而弹错，而且你在界面上完全看不到具体是哪一步出了问题。
JVM 堆内存配置在/etc/wazuh-indexer/jvm.options，里面的-Xms和-Xmx要显式设置。官方默认值是 1G，全流程部署后最好调整到物理内存的一半，但不能超过 32G。我这里踩过一个坑：在 16G 内存的机器上把堆调成了 12G，结果 Indexer 一直起不来，日志提示 mmap 失败，最后发现是系统max_map_count不够，而且内存锁配置也没匹配。建议先用 4G 堆跑起来，后续根据写入量再调整，不要一上来就贪大。
3.3 Dashboard 配置文件，核对清单照着抄
Dashboard 的配置文件是/etc/wazuh-dashboard/opensearch_dashboards.yml。安装完成后最小改动建议如下：
server.host: 0.0.0.0 server.port: 443 opensearch.hosts: ["https://<indexer-ip>:9200"] opensearch.ssl.verificationMode: certificate i18n.locale: "zh-CN"server.host如果不写在0.0.0.0，你用浏览器访问虚拟机的 IP 时就会直接拒绝连接。opensearch.hosts必须写 Indexer 的访问地址，协议是 https。verificationMode这里有讲究：默认是full，它不光校验 CA，还会校验证书里的 IP 或域名和你访问的地址是否一致。如果你在生成证书时只写了 hostname，没写 IP，那么用 IP 访问时校验就会失败。测试环境把它改成certificate可以跳过主机名校验，只验证 CA，能少踩很多坑。
还有一个容易被忽略的点：Dashboard 自身的 HTTPS 证书由插件管理，证书文件路径默认在/etc/wazuh-dashboard/certs/下，如果你修改了配置文件里的权限或者目录路径，记得同步把所有.pem文件的属主改成wazuh-dashboard:wazuh-dashboard，权限 400。不然服务启动时会报EACCES或者permission denied。我自己就在这段卡了半小时，最后发现只是证书文件属主是 root，dashboard 进程没有读取权限。
4. Agent 端安装与接入，最后一步也不让人省心
4.1 Agent 部署前必须确认的三项关键信息
Wazuh 部署的最后一步是安装 agent（代理端），这里同样有一堆细节。Linux 上安装 agent 之前，先确认三件事：Manager 的 IP 地址、agent 的注册密码、agent 的名称。Manager IP 没什么好说的，注册密码可以通过安装 dashboard 输出的那段文字里找到，也可以在 Manager 上执行：
cat /var/ossec/etc/authd.pass这个密码只在 agent 首次注册时需要，注册成功以后会在/var/ossec/etc/client.keys里生成一条记录，后续认证走的是证书和密钥，密码就不再起作用了。agent 名称建议起得有意义一些，比如webserver-01、db-server-02，因为在 Dashboard 的 agent 列表里显示的就是这个名字，方便后续管理。如果你起了一堆test1、test2，到后来根本分不清哪台是哪台。
安装 agent 时，官方给的命令通常是一行脚本，里面带有环境变量，安装完成后要确认/var/ossec/etc/ossec.conf里的<address>是否指向正确的 Manager IP。有些时候脚本执行完，配置文件里的地址还是默认的MANAGER_IP，需要手动改，然后重启 agent 服务：
systemctl enable wazuh-agent systemctl start wazuh-agent4.2 Agent 状态不是 Active，三种“卡住”现象逐一排查
发现 agent 装完后状态一直不对，先看 Dashboard agent 列表里的状态，总共就是三种：Active、Disconnected、Unverified。先说Unverified，这个状态说明 agent 从来没成功向 Manager 注册过。排查顺序是：第一，检查/var/ossec/etc/client.keys文件是否存在；第二，确认 1515 端口是否通的；第三，确认注册密码是否输入正确。如果端口通、密码对，但 client.keys 一直不生成，去 Manager 上执行journalctl -u wazuh-manager -f，看有没有报Unable to register之类的错误，定位到原因后再处理。
Disconnected状态表示 agent 曾经注册成功，但是当前连接中断。最常见的三个原因是：Manager 防火墙没放行 1514 端口、agent 和 Manager 之间的网络不通、agent 服务意外停止了。这个时候优先从 agent 端看日志，Linux 上执行：
journalctl -u wazuh-agent -f tail -f /var/ossec/logs/ossec.log看日志里是ERROR还是WARNING。如果看到频繁重连但失败，多半是网络问题，用telnet <manager-ip> 1514或者nc -vz <manager-ip> 1514验证一下端口连通性。在这之后，时间不同步也是一个隐藏杀器。agent 和 Manager 的系统时间差得太多，认证握手时会因为时间戳越界失败，Dashboard 上表现出忽连忽断的诡异状态。所以所有参与部署的机器，第一件事就是配好 chrony 或 ntpd，让时间保持一致。
Windows 平台的 agent 问题通常集中在安装包的权限和杀毒软件拦截上。安装 Wazuh agent 的 msiexec 命令里可以一次性指定 Manager 地址和注册密码，但 Windows 防火墙默认会拦 Skynet（老版本叫法）或 wazuh-agent 进程的入站连接，需要手动添加允许规则。另外，公司内的杀毒软件有时会把 agent 的写日志行为当成异常，导致 agent 服务反复被 kill，这种情况下最有效的思路是先在防病毒白名单里放行 Wazuh 相关目录和服务。
4.3 端口放行清单，一次性避免“排查半天发现是防火墙”
防火墙的问题放在最后说，是因为它太基础，反而容易被忽略。Agent 和 Manager 通信过程中涉及三个端口：
| 服务 | 端口 | 协议 | 用途 |
|---|---|---|---|
| Agent 事件传输 | 1514 | TCP | agent 向 Manager 发送日志和事件 |
| Agent 注册 | 1515 | TCP | agent 首次注册和密钥分发 |
| Wazuh API | 55000 | TCP | Dashboard 调用 Manager 的 API |
| Indexer API | 9200 | TCP | 各组件读写数据、认证接口 |
| Dashboard | 443 | TCP | 浏览器访问 Web 界面 |
如果你用的是 firewalld，可以这样快速放行：
firewall-cmd --permanent --add-port=1514/tcp firewall-cmd --permanent --add-port=1515/tcp firewall-cmd --permanent --add-port=55000/tcp firewall-cmd --permanent --add-port=9200/tcp firewall-cmd --permanent --add-port=443/tcp firewall-cmd --reload从 agent 到 Manager 至少放行 1514 和 1515；从 Dashboard 到 Indexer 要放行 9200；从浏览器到 Dashboard 要放行 443；从 Dashboard 到 Manager 要放行 55000。还有一点，如果组件之间是跨网段的，你还要排查云厂商的安全组规则，Wazuh 报错里有时不会给你明确提示，这种基础网络问题排查起来最费时间。我自己就多次在本地防火墙放行之后，忘了云平台安全组也有入站规则，排查了很久。
5. 安装期高频报错速查表与实操建议
5.1 高频报错速查表
| 报错现象 | 可能原因 | 快速排查方法 |
|---|---|---|
vm.max_map_count is too low | 内核参数没改 | 执行sysctl -w vm.max_map_count=262144 |
memory locking requested ... but memory is not locked | memlock 限制未放开 | 修改/etc/security/limits.conf并重启 |
Address already in use | 9200 或 443 端口被占 | ss -lntp | grep 9200定位进程 |
x509: certificate signed by unknown authority | CA 证书不一致或路径错误 | 检查 root-ca.pem 是否部署到各组件 certs 目录 |
| Wazuh Indexer 启动后反复重启 | JVM 堆内存设置过高或max_map_count不足 | 查看/var/log/wazuh-indexer/*.log |
| Dashboard 无法连接 Indexer | opensearch.hosts写错或证书不匹配 | 检查opensearch_dashboards.yml里的 hosts |
| Agent 状态为 Unverified | 1515 端口不通或注册密码错 | 查看 Manager 日志，检查 authd.pass |
| Dashboard 页面有数据但事件不显示 | Filebeat 输出地址错误或证书缺失 | 检查/etc/filebeat/filebeat.yml |
| 事件时间差 8 小时 | 系统时区未统一 | timedatectl set-timezone Asia/Shanghai |
5.2 一套我实测能跑通的 All-in-One 快速部署清单
如果你想要一个比较顺滑的部署流程，可以照我这个清单来操作，每完成一步确认一下再走下一步：
- 准备一台 Rocky Linux 8 或 Ubuntu 22.04 的虚拟机，分配 8G 内存，2 核以上，硬盘 50G。
- 设置干净的主机名，编辑
/etc/hosts，回填本机 IP 和主机名。 - 执行
sysctl -w vm.max_map_count=262144并写入配置文件，永久生效。 - 关闭 SELinux（RHEL 系）或临时放行端口，确保没有防火墙挡路。
- 下载
wazuh-install.sh，分步执行，先生成配置文件，再装 Indexer。 - 确认
systemctl status wazuh-indexer为 active 后，再开始装 Manager。 - 配置 Filebeat，替换
/etc/filebeat/filebeat.yml里的 hosts 为 Indexer IP，重启服务，确认日志无报错。 - 最后装 Dashboard，配置
opensearch_dashboards.yml，确认 Web 界面能打开。 - 用浏览器访问
https://<dashboard-ip>，用安装输出里的账号密码登录，先在“总览”页面确认数据不为空。 - 再安装第一台 agent，看状态是否变 Active。
这套流程走下来，大部分人的安装都能在半天内结束。
5.3 最后几条血泪经验
先说说我在一次环境里踩过的链式故障：那台机器内存只有 4G，但我把 Indexer 的 JVM 堆调成了 3G，然后 Dashboard 就反复 OOM，每次拉起 Dashboard 都把系统内存吃满，Manager 也跟着遭殃，agent 事件全部积压。最后我把堆调回 2G，同时加了 2G 的 swap 才勉强稳住。所以，Wazuh 的组件不是分配的资源越多越好，要综合考虑整台机器的内存余量。
另外，所有服务日志的位置一定要记熟，它们是排查问题的第一任老师：
- Indexer 日志：
/var/log/wazuh-indexer/ - Manager 日志：
/var/log/wazuh-manager/ - Dashboard 日志：
/var/log/wazuh-dashboard/ - Filebeat 日志：
/var/log/filebeat/
遇到安装异常的时候，先systemctl status 服务名看服务状态，再用journalctl -u 服务名 -f看实时日志，最后去对应日志目录翻详细错误。不要一上来就怀疑官网文档写错了，99% 的问题都出在环境差异上，而不是软件本身的 bug。
根据我自己的经验，还有一个小技巧值得分享：装组件前先打好虚拟机快照，每成功装完一个组件打一个快照。这样如果你在后面的步骤里把配置改坏了，直接回滚到上一个快照重来，比反复清包卸载要快多了。Wazuh 的卸载残留也很讨厌，重装时如果没清干净旧证书和旧配置，后面会一直受到旧证书干扰。我自己就吃过这个亏，后来干脆养成了“先快照后动手”的习惯，整个安装过程的试错成本一下就降下来了。
