企业官网建设流程全解析

前阵子帮一个朋友排查 Wazuh 装不上问题，他折腾了两天，换了好几个版本的 Elasticsearch、OpenSearch，最后卡在 Dashboard 登录转圈。我问他一句“你到底装的什么版本”，他发来一个截图，我一看就知道问题出在哪了：Wazuh 4.x 的三件套版本全部对不上。其实 Wazuh 安装本身并不难，难的是你踩过的坑已经让你怀疑人生。

这篇博文不是官方文档的复读，是我把 Wazuh 4.x 系列从零开始装、卸载、再装、分布式部署、Agent 接入这一整套流程跑完之后的经验汇总。里面每一个坑我都自己踩过，每条命令都是实际执行过的。如果你是第一次接触 Wazuh，或者之前装过但没起来，这篇文章应该能帮你少走几个小时弯路。

1. 装之前先把资源账算清楚：Wazuh 对服务器到底有多挑剔

Wazuh 是一个开源的主机安全监控平台，核心功能集中在威胁检测、日志分析、文件完整性监控、漏洞检测和合规管理这几块。它的架构说白了就是三个组件协同工作：Indexer 负责存储和检索数据，Server 负责收集处理日志和触发告警，Dashboard 是给你看数据的可视化界面。这三件套装完之后，你会得到一个类似 SIEM 的 Web 控制台，所有 Agent 的告警和安全事件都会汇到这里。理解了这套架构，后面的安装步骤就好懂多了——因为每一步无非就是在部署这三个东西并让它们互相通信。

1.1 不是所有机器都能跑 Wazuh：内存和 CPU 的隐形门槛

官方文档写的最低要求是 4GB 内存、2 核 CPU，但我必须告诉你实话：4GB 只能让你把页面打开，真正跑起检测任务会非常吃力。我自己实测过，4GB 内存的机器装完 All-in-One 之后，剩余可用内存不到 800MB，Agent 一接入马上开始频繁 swap，Dashboard 面板加载要等十几秒，文件完整性监控的数据库初次同步直接卡死。

我的建议是：

• 测试环境：4GB 内存起步，6GB 更稳，磁盘 50GB 够用。
• 生产环境：8GB 内存是底线，最好 16GB，磁盘按日志增长速度算，通常建议 200GB 起。
• CPU 方面，2 核勉强能动，4 核以上体验会有明显提升。

这里有个常被忽略的点：内存大小直接决定了你给 Elasticsearch/OpenSearch 分配的 JVM 堆大小。Wazuh Indexer 默认的 heap 分配会按系统总内存自动计算，但它有个毛病——如果系统内存太小，它反而会分配一个非常尴尬的值。我见过 4GB 机器上 Indexer 自动分配了 1GB heap，结果启动后一会儿就 OOM。你可以在/etc/wazuh-indexer/jvm.options里手动改-Xms和-Xmx，建议设置为物理内存的 25% 到 50%，不要超过 50%，因为还要给系统留余地。

还有一个硬件层面的坑：不要拿 32 位系统去装，Wazuh 4.x 从很早开始就放弃 32 位兼容了。另外，如果你用的是 ARM 架构的机器，部分组件虽然能跑，但官方提供的预编译包可能不完整，AI 部署脚本会自动判断架构并选择合适的包，这一步比较容易翻车，建议新手直接用 x86_64 架构的服务器，省事很多。

1.2 操作系统版本与内核的地狱匹配

Wazuh 对操作系统的支持范围比较广，CentOS 7/8/9、Rocky Linux、Ubuntu 18.04/20.04/22.04、Debian、Amazon Linux 这些主流发行版都在官方支持列表里。但“支持”和“顺利装上”是两码事，我这里直接给结论。

• 最省心的组合：Ubuntu 22.04 或 CentOS 7.9。这两个系统下 Wazuh 的依赖全都现成，我装了多次几乎没遇到过系统层面的坑。
• 最折磨人的组合：Ubuntu 24.04 搭配某些旧版本 Wazuh。新版系统太激进，Old 的依赖包装不上去，比如 libssl 版本不对、Python 版本不对，各种问题。
• 内核太新也有问题：Wazuh 的 Agent 在内核模块层面做文件监控，如果你内核版本过高而 Wazuh 版本旧，相关内核模块可能不被支持，会导致 Agent 安装成功但文件监控不生效或者直接报错。

所以如果你选择用虚拟机新建环境跑 Wazuh，镜像优先选系统自带 20.04 或 22.04 的，别选最新版的 24.x 镜像。

1.3 网络端口规划：还没装就先把“门牌号”定好

Wazuh 安装过程里对端口的要求非常讲究，如果你机器上跑着别的服务占用了端口，安装脚本不会替你处理冲突，只会直接报错。

默认端口规划：

尤其是 9200 端口，如果你机器上之前装过 Elasticsearch 或者别的搜索引擎，端口占用的概率极高。我在刚开始踩坑时就是遇到这个情况，安装脚本跑了大半天，最后卡在 indexer 初始化，日志里写着 "Address already in use"，一查才发现旧的 Elasticsearch 进程还赖着没走。所以安装前先执行一下端口检查：

ss -lntp | grep -E '9200|55000|1515|1516|443'

看到有结果，先把端口空出来再继续。另外，如果你的服务器开了防火墙（比如 ufw 或者 firewalld），记得提前把这几条端口规则放行，不然装完之后 Agent 和 Server 之间会像失联一样，这个坑埋得很深，因为安装脚本本身不会帮你在防火墙上打洞。

2. 安装方式选型：All-in-One、分布式还是包安装？

Wazuh 提供了几种官方安装路径，不同路径对应不同的场景。我第一次装的时候没搞清楚，直接按照网上一个老教程走了 RPM 包手动安装，结果组件之间的版本关系完全靠猜，折腾了半天才明白 Wazuh 4.x 的官方定位是让你优先使用部署助手（wazuh-install.sh）。这个工具会从一个脚本出发，自动完成索引器、服务器、仪表板三件套的安装和初始化，省去了大量手动配置的繁琐过程。不过它也不是万能的，后面我会专门讲它容易在哪里踩坑。

2.1 三种安装路线各自的适用场景

All-in-One 和分布式这两条路线是官方推荐的，它们的本质区别在于三件装配不配在同一台机器上。选哪条路线取决于你想把监控系统扛到什么样的规模。

• All-in-One 单机版：三件套都装在一台机器上，适合测试环境、个人实验室、中小企业规模（不过微型企业可能根本用不上这么重的方案）。这个方案的优势是安装简单，维护成本低，一条命令就搞定。缺点也明显：一旦这台机器挂了，监控平台整个瘫痪。
• 分布式部署：三件套分别装在三台（或更多）机器上，Indexer 甚至可以组成集群。适合生产环境，扩展性好，任何单点故障都不会影响全局。代价是安装步骤多一大截，证书分发、组件之间的网络配置、节点加入集群这些环节都得自己处理。
• 包管理器手动安装：通过apt/yum安装单个组件。这条路线最灵活，可以自定义每个组件的版本和配置，但也最容易出错，因为 Wazuh 各个组件之间存在严格的版本兼容关系，手动装很容易装出一个混搭版本组合。你如果不想让 Wazuh 团队帮你管理全部配置，只想把某个组件融入现有环境，可以考虑这个方案。

为什么不推荐新手直接从包安装开始？因为 Wazuh 三件套之间的版本关系之严格，有点像手机系统和 App 的兼容性：Indexer 版本差一点点，Dashboard 连不上；Server 多更新一个小版本，Agent 连接不稳定。手动装的时候，你一不小心就掉进版本黑洞，排查起来非常浪费时间。

2.2 为什么我建议新手先走 All-in-One

我自己测试过很多次后得出的结论是：第一次接触 Wazuh，不要直接上分布式，先用 All-in-One 把整个流程跑通，搞清楚组件之间怎么通信、Agent 怎么接入、告警怎么查看，再上生产环境做分布式会容易得多。

All-in-One 一条命令部署完成后的效果是：你可以直接通过 HTTPS 打开 Dashboard，登录后能看到所有 Agent 的安全事件、告警、漏洞信息。对有经验的工程师来说，这种“即装即用”的模式可能略显粗糙，但对新人来说，能在半小时内看到自己的第一台监控服务器上线，这种成就感很重要。

另外，如果你最终目标是生产环境，我的建议是先搭一台 All-in-One 当测试机，用来验证规则、测试告警逻辑、调整索引参数，再在另一批机器上搭分布式。这样你在分布式环境里遇到的“配置改坏了”一类问题，不会影响现有业务。

2.3 安装前的依赖准备：版本兼容才是天大的事

不管走哪条路线，有几个基础工具是绕不开的，这里特别提醒一下：你网上搜安装教程的时候，经常会看到 Python 安装教程、Git 安装教程、Vim 安装教程之类的文章，以为这些是必须的前置条件。实际上 Wazuh 安装脚本所需的依赖，在官方支持的系统上大多数是预装好的。

在 Ubuntu 22.04 上我的实践如下：

apt update && apt install curl tar openssl git vim -y

这几个工具基本够用。CentOS 7.9 相应地用：

yum install curl tar openssl git vim -y

关于 Python：Wazuh 的安装脚本依赖 Python 3.8 以上，但不需要你手动装。如果你系统里恰好自己编译过 Python，还要特别注意 PATH 优先级问题——安装脚本可能会调用到错误的解释器版本。这点我在第 5 部分的分布式部署中再展开。

另外，Git 在安装阶段基本用不上，除非你打算直接从 GitHub 拉 Wazuh 源码手动编译。如果你只是想用官方仓库安装，Git 可以不需要。网络热词里常出现 Git 安装教程、Python 安装教程等，那更多是通用开发环境的需求，Wazuh 安装大可不必被这些教程牵着走。

3. 实操记录：All-in-One 完整安装与配置过程

这一节开始进入正题。我将以 Ubuntu 22.04 为例，逐步演示 All-in-One 的完整安装过程，并穿插说明每一步的目的和容易踩的坑。

3.1 准备阶段：用软链接解决 /tmp 空间不足的坑

这一步看起来和 Wazuh 无关，但我在安装过程中踩过一次，印象深刻。Wazuh 的部署助手在安装阶段会下载大量组件包并解压，默认的临时目录是/tmp。如果你装系统的分区时候给/tmp分配的空间太小，安装会在中途报磁盘空间不足，整个安装流程被迫打断重来。

我踩坑现场是这样的：当时虚拟机给根分区只划了 20GB，装到一半脚本报 "No space left on device"，我第一反应是清理 apt 缓存，删掉旧内核，腾了 2GB 左右出来，重新装，又卡在同一位置。最后发现是/tmp被单独分区，只有 2GB，安装包解压一下就满了。

解决方式：把/tmp软链接到空间足够的目录，或者直接给/tmp扩容。我当时的处理办法是在根分区下新建一个/root/tmp，然后：

rm -rf /tmp && ln -s /root/tmp /tmp

之后重新执行安装，问题解除。这个坑官方文档没提，但实际操作里隔三差五会遇到。

3.2 安装脚本一段命令执行后的真实输出

Wazuh 官方给出的 All-in-One 安装命令非常简洁，就一行：

curl -sO https://packages.wazuh.com/4.9/wazuh-install.sh && bash wazuh-install.sh --generate-config-files --instances 1

这个命令里面的4.9是 Wazuh 的主版本号，你需要把它替换成当前的最新版本。可以在 Wazuh 官网上查 Latest Version。注意：不要随便用latest之类的不固定版本号，因为脚本的下载路径和版本强绑定，写死版本号是最稳的。

命令执行后，脚本会做以下几件事：

1. 检查系统版本、架构、可用内存和端口。
2. 下载并安装 Wazuh Indexer、Server、Dashboard 三个组件。
3. 生成需要的证书（自签名 CA 和节点证书）并自动配置。
4. 启动三个服务并设置开机自启。

整个流程大概十几分钟，取决于你的网络状况。如果中间哪一步失败，脚本一般会报个 "Error installing" 并退出。这时不要慌，先去日志里看具体的失败原因。

安装完成后，脚本会在控制台打印一段类似这样的信息：

dashboard_install.sh: OK wazuh-indexer: OK wazuh-manager: OK --- Summary --- You can access the web interface https://<server-ip> User: admin Password: <随机生成的密码>

这段输出很重要，请先记录，因为admin的初始密码是自动生成的，如果丢了，后面要重置会比较麻烦。

3.3 证书生成与文件权限：最容易翻车的两个环节

如果你安装的是 All-in-One，部署助手会自动处理证书生成和权限配置，基本不用你手工干预。但如果你选的是手动安装或者分布式部署，证书这个环节是出错重灾区。

先说证书生成的坑。Wazuh 三件套之间全部采用 HTTPS 双向 TLS 认证，也就是每个节点都要有自己的证书，并且要由同一个 CA 签发。如果某台机器拿到的证书和另一台对不上，组件之间通信会直接失败，而且报错信息非常具有迷惑性，比如 Dashboard 页面提示 "Failed to connect to search guard" 或者索引器日志里报 "unable to parse message from REST API"。

我第一次做分布式部署时就遇到过证书混淆问题：三台机器的证书生成到同一个 tar 包里，解压的时候我少拷贝了一个文件，结果 Indexer 和 Server 之间互验证书失败，日志里全是 SSL 错误。排查了很久才发现是某个节点的证书文件缺失。

再说文件权限。Wazuh 三件套对证书文件的权限要求极其严格：用户和组必须匹配，权限位必须正确。具体来说：

• Indexer 使用的证书和密钥文件，属主必须是wazuh-indexer:wazuh-indexer，权限建议660。
• Server（Manager）使用的证书，属主必须是wazuh:wazuh，权限建议660。
• Dashboard 使用的证书，属主必须是wazuh-dashboard:wazuh-dashboard，权限建议660。

权限不对时，服务启动时会报 "Permission denied" 或者 SSL 初始化失败。这种情况用chown和chmod改一下就能解决，但如果你不知道这个规则，可能会在 SSL 错误里打转很久。

3.4 验证安装：端口、进程、页面三层检查

安装脚本执行完成后，先别急着登录 Dashboard，用这三步验证一下安装状态：

第一层：检查端口监听状态。

ss -lntp | grep -E '9200|443|55000|1515'

正常的输出应该同时看到 9200、443、55000、1515 这几个端口都在 LISTEN 状态。如果缺少某个端口，说明对应的服务没有启动成功，优先去系统日志里翻相关进程的报错。

第二层：检查关键服务进程。

systemctl status wazuh-indexer wazuh-manager wazuh-dashboard

理想状态是三个服务都显示 active (running)。如果某个服务启动失败，可以单独查看：

journalctl -u wazuh-indexer --no-pager -n 100 journalctl -u wazuh-manager --no-pager -n 100 journalctl -u wazuh-dashboard --no-pager -n 100

这里的日志是排查问题的最重要入口，比网上任何教程都更接近真实原因。

第三层：检查 Indexer 集群健康状态。

curl -k -u admin:<你的密码> https://127.0.0.1:9200/_cluster/health

正常情况下返回的status应该是green，number_of_nodes应该是1。如果返回yellow，说明索引存在副本未分配的情况；如果返回red，说明有主分片未分配，问题会比较大。这块我在第 5 章详细展开。

4. 分布式部署要点：三件套的安装顺序与衔接

生产环境一般不做 All-in-One，而是把三件套拆开。这一节我结合自己的实操给出分布式部署的完整顺序和关键细节。分布式部署中最需要注意的就是安装顺序：必须先装 Indexer，再装 Server，最后装 Dashboard，因为后面的组件在安装时就跟前面的组件建立信任关系，装反了后面接入阶段很容易报错。

4.1 先装 Wazuh Indexer

Indexer 是整条数据链路的底层存储，它不启动，后面任何组件都白搭。在分布式部署中，你需要在 Indexer 节点上单独下载安装脚本：

curl -sO https://packages.wazuh.com/4.9/wazuh-install.sh

然后先执行配置生成：

bash wazuh-install.sh --generate-config-files --instances 3

这里的--instances 3表示要生成三个节点的配置，包括证书和 yml 配置文件。执行完成后，脚本会在当前目录生成一个wazuh-install-files.tar.gz压缩包，里面包含所有节点的证书和配置文件。这个 tar 包需要你手动分发到三台机器上。

Indexer 节点安装：

bash wazuh-install.sh --install-elasticsearch

实际命令名可能是--install-indexer，不同版本略有差异，请以脚本的--help输出为准。安装完成后，Indexer 会自动启动并监听 9200 端口。此时先不要急着装其他组件，先验证 Indexer 自身集群状态。

4.2 再装 Wazuh Server

Server（Manager）节点的职责是接收 Agent 的日志和事件，进行解析和告警，然后写入 Indexer。安装方式类似：

bash wazuh-install.sh --install-wazuh

Server 安装过程中需要用到前面 tar 包里的证书文件，脚本会自动从解压目录找到对应的wazuh-server.pem、wazuh-server-key.pem等文件。这里最容易出的问题就是证书路径不对或者文件权限不对。

Server 启动后，你需要验证它和 Indexer 之间的通信是否正常。这个验证在 Server 节点上执行：

/usr/share/wazuh-indexer/bin/wazuh-indexer --version

嗯，上面的命令其实不适用于 Server 节点。正确的做法是检查 Server 的配置里是否指向了正确的 Indexer 地址，然后让 Server 往 Indexer 写入一条测试数据。你可以在 Server 节点上执行：

curl -k -u admin:<密码> https://<indexer-ip>:9200

如果返回了版本信息，说明网络通路正常、证书校验也过了。

4.3 最后装 Wazuh Dashboard

Dashboard 是用户的 Web 入口，它需要连接 Indexer 和 Server，所以在三件套里它依赖的组件最多。安装命令：

bash wazuh-install.sh --install-dashboard

这里有个关键点：Dashboard 的配置文件中需要指定server.host、server.port以及指向 Indexer 和 Server 的地址。如果你在安装前没有把wazuh-install-files.tar.gz正确解压在 Dashboard 节点上，脚本会报找不到配置文件的错。

Dashboard 安装完成后，访问https://<dashboard-ip>，用admin和你记录的密码登录。如果出现登录界面但输入密码后一直转圈，大概率是 Dashboard 和 Indexer 的通信出了问题，重点查 Dashboard 节点上的journalctl -u wazuh-dashboard日志。

4.4 证书分发与节点配置同步

分布式部署的证书分发环节是最容易乱的地方。我的建议是：

1. 在所有安装命令执行前，先把wazuh-install-files.tar.gz拷贝到三台机器的同一目录下，比如/opt/wazuh-install/。
2. 解压后，确认每个节点只保留自己需要的证书文件，不要把其他节点的证书留在本机。
3. 每个节点的/etc/wazuh-indexer/opensearch.yml里，discovery.seed_hosts要写清楚集群内所有节点的 IP；如果是单节点 Indexer，记得把discovery.type设为single-node。
4. 所有节点的时间必须同步（NTP 或 chrony），否则证书校验会因时间偏差失败。这个问题很隐蔽，我见过因为服务器时间差了几分钟导致 TLS 握手失败的案例。

5. 常见问题与排查技巧实录（踩坑清单）

这一节把我在实际操作中遇到的典型问题和排查思路整理成清单，方便你按图索骥。

5.1 “Dashboard 登录一直转圈”排查思路

这个问题在 Wazuh 社区里出现的频率非常高，现象就是登录页能出来，输入 admin 密码后一直转圈，过一会儿提示无效凭据或者连接失败。

排查路径：

1. 先确认 Dashboard 能否连上 Indexer。在 Dashboard 节点执行：

curl -k -u admin:<密码> https://127.0.0.1:9200

能返回版本信息，说明本机到 Indexer 的通路没问题；如果超时或拒绝连接，重点查端口和防火墙。

2. 再确认 Dashboard 配置里的server.host是不是0.0.0.0，如果写死了127.0.0.1，远程访问会失败。

3. 查看 Dashboard 日志：

journalctl -u wazuh-dashboard --no-pager -n 100

常见错误包括 "Failed to connect to opensearch" 或者 "SearchGuard authentication failed"。

4. 如果是SearchGuard相关错误，多半是证书不一致。检查 Dashboard 使用的证书是不是和 Indexer 同一个 CA 签发的。

5.2 Indexer 状态 yellow/red 的排查

Indexer 集群状态为yellow或者red是很常见的问题。

yellow表示主分片已经分配，但副本分片没有分配。在只有一台 Indexer 节点的环境里，这是因为默认的副本数为 1，但节点数只有 1，副本无法分配。解决方式是把副本数改为 0：

curl -k -u admin:<密码> https://127.0.0.1:9200/_settings -X PUT -H 'Content-Type: application/json' -d '{"index":{"number_of_replicas":0}}'

或者修改索引模板。如果你想知道为什么会这样：因为 Wazuh 默认创建的索引模板副本数为 1，在单节点集群里找不到副本节点，就会一直保持 yellow。

red状态更严重，表示有主分片没有分配。可能原因包括节点之间网络不通、磁盘空间不足（超过水位线导致分片无法分配）、或者索引数据损坏。排查方式：

curl -k -u admin:<密码> https://127.0.0.1:9200/_cat/shards?v

看哪个索引卡在 UNASSIGNED，再查看原因字段，一般会给出线索。

5.3 Filebeat 无法连接 Indexer

Wazuh Server 通过 Filebeat 将告警和事件写入 Indexer。如果 Server 的日志里有大量 "could not connect to elasticsearch" 或者 "fail to send batch" 之类的报错，需要按顺序排查：

1. Filebeat 配置文件/etc/filebeat/filebeat.yml里的hosts是否正确指向 Indexer 节点 IP。
2. 证书文件权限是否为wazuh:wazuh且权限位为660。
3. 密码是否正确，Filebeat 输出的认证信息是否和 Indexer 的内部用户一致。
4. 最后用命令手动测试 Filebeat 与 Indexer 的通路：

filebeat test output

这个命令会给出明确的连接成功或失败信息，非常实用。

5.4 升级或重装后启动失败的“老规矩”

如果你是升级版本或者重装，遇到服务启动失败先不要乱卸载，按这个顺序来：

1. 检查系统日志：

journalctl -u wazuh-manager -n 50 journalctl -u wazuh-indexer -n 50 journalctl -u wazuh-dashboard -n 50

2. 如果是配置错误导致的启动失败，通常日志末尾会写清楚哪个配置文件有问题。
3. 如果是证书问题导致的三件套互相连不上，重新生成证书并分发是最快的解决路径。

我见过有人因为升级后 Dashboard 起不来，直接把整个环境卸载重装的，其实很多升级失败的问题就出在/etc/wazuh-dashboard/opensearch_dashboards.yml里还残留旧版本配置项，手动清理掉就能恢复。

5.5 虚拟机环境下的兼容性

很多人在虚拟机上装 Wazuh，我自己也是从 VMware 虚拟机开始玩的。这里有一个额外的坑：如果你用 VMware Workstation 跑 Ubuntu，默认虚拟网卡模式如果是 NAT，Wazuh 的安装脚本通常可以正常跑，但 Agent 从外部接入时需要你额外配置端口转发，否则 Agent 上报的数据根本到不了 Server。另外虚拟机的磁盘如果分配太小，Wazuh Indexer 写数据很容易触发磁盘水位线，索引变成只读，表现是 Dashboard 里看不到新数据。所以虚拟机里建议至少分配 60GB 磁盘，并预留扩展分区的能力。

6. 装完以后还要做的事：从“能打开页面”到“真正能用”

安装完成、Dashboard 能登录，这只是第一步。要真正把 Wazuh 跑起来，还有几个必须做的配置项。

6.1 修改默认账号密码

Wazuh 安装后默认的admin密码在安装日志里打印，但这密码是随机生成的，很多人直接拿着用，也不改。建议登录后立即在 Wazuh Dashboard 里通过 “OpenSearch Dashboards Security” 插件重置密码，或者在 API 里调用相关接口修改。如果你需要给团队多人分配账号，可以创建不同角色的用户，分别授予只读、告警管理等权限，避免所有人共用 admin。

6.2 安装 Agent 并验证事件流

不安装 Agent 的 Wazuh 只是个空壳监控平台，没有任何意义。Agent 的安装方式支持 RPM、DEB、MSI 安装包，也可以用脚本部署。在测试环境里，我推荐直接在 Wazuh Server 本机装一个 Agent，用来验证事件链路是否完整。

curl -s https://packages.wazuh.com/4.x/wazuh-install.sh | bash -s -- -a -i <server-ip> -p password

实际上命令细节可能因版本而异，更通用的方式是：在 Dashboard 的 Agents 页面选择“Deploy new agent”，系统会给出对应系统的安装命令，复制到目标机器执行即可。

Agent 安装完成后，回到 Dashboard 的 Agents 页面，状态变成 Active 就说明注册成功。然后在 Agent 上执行一些安全操作（比如安装一个后门程序或者修改系统文件），等一两分钟后，Dashboard 的 Security events 页面应该能看到对应的告警。如果没有告警，检查 Agent 的/var/ossec/etc/ossec.conf里 Server 地址是否配置正确。

6.3 磁盘监控与空间规划

Wazuh 运行中最现实的问题就是磁盘被日志塞满。默认的索引保留策略是 90 天，日志量大时，每天可能产生几个 GB 的数据。建议从安装之初就规划好磁盘空间，并开启索引清理策略。

Wazuh 提供了索引生命周期管理（ILM）策略，默认会按天数删除旧索引。你可以在 Dashboard 的 Indexer Settings 里调整保留时间。如果没有正确设置，索引满了以后 Indexer 会自动把索引设为只读，表现就是 Dashboard 没数据了，这个坑很常见。

我的个人实践是：测试环境保留 30 天，生产环境按合规要求 180 天到 365 天。磁盘不够了就提前扩容，别等到水位线告警再处理。

6.4 升级与维护注意事项

Wazuh 的升级策略是：小版本升级（比如 4.7 到 4.8）可以直接通过官方脚本完成，大版本升级需要先做完整备份。升级前一定要先备份这几样东西：

• /etc/wazuh-indexer目录下的配置文件和证书
• /etc/wazuh-manager目录下的规则配置
• Dashboard 的系统索引（如果你有自定义的 dashboard 面板）

升级过程里最容易翻车的地方在于 Group 配置，就是你在 Dashboard 里设置的 Agent 组策略，升级脚本会保留这些配置，但如果新旧版本的 schema 有变化，旧的配置可能导致 Wazuh Manager 起不来。所以大版本升级前，建议先在测试环境验证一遍。

另外，Wazuh 对新版本的老系统支持也是有限的。比如你还在 CentOS 7.9 上跑着老版本 Wazuh 4.5 想升级到 4.9，大概率会碰到依赖问题。我的经验是：老系统就留在旧版本，新环境直接上新版，没必要强行在旧系统上折腾最新版本。

写在最后的实操体会

安装 Wazuh 这件事，说难也难，说简单也简单，关键是别被各种教程误导。我刚开始装的时候，网上搜到一堆跟我情况完全不同的教程，有讲单节点的、有讲大规模集群的、有讲源码编译的，最后照着他们操作，反而把自己带偏了。后来学乖了，一切以官方文档和官方安装脚本为准，遇到问题先看日志再搜索，踩坑效率高了好几倍。

如果你这个周末准备装 Wazuh 来体验一把，我给的最实在的建议是这两条，也是我自己反复用到的经验：

第一条，别在一个环境里反复折腾，装坏了就重开虚拟机，比修安全监控平台要快得多。装 Wazuh 玩这个过程，本身就是练手和熟悉三件套逻辑的好机会，很多问题你在重装过程中自然就懂了。

第二条，所有改配置文件之前先备份一份，Wazuh 的配置文件之间关联性很强，一改改错一个点，半天时间就没了。我习惯在/root下面建个backup目录，把要改的配置先拷贝进去，然后再动手。这个习惯在很多其他服务上同样适用。

最后再说一句，Wazuh 这个平台本身很强大，但如果只停留在“装好了”这个阶段，你会错过它真正的价值。花点时间把文件完整性监控、漏洞检测、合规检查这些功能都打开，让它真实地监控几台机器，你才能体会到一个能落地的安全平台该有的样子。