Wazuh 最近在安全运维圈子里讨论度很高它是一个开源的主机安全监控平台集入侵检测、日志分析、文件完整性监控、漏洞检测和合规审计于一身。很多人以为装上它就是跑一条官方脚本那么简单但真到自己动手安装 Wazuh 的时候各种莫名其妙的报错能让你从下午熬到深夜。这篇踩坑指南就是我实际部署 Wazuh 4.9 全过程的完整记录每一条坑都是我自己踩过、复现过、并验证过解决方案的希望能帮你绕开这些弯路。文章适合安全运维、等保实施人员、实验环境搭建者也适合纯粹想搞一套开源 SIEM 练手的安全爱好者。看完之后你不光能装起来还能知道装完怎么自检、组件之间怎么通信、出了问题去哪里看日志。1. Wazuh 是什么装它之前先弄懂“三件套”1.1 三个核心组件各自的角色很多人一上来就跑安装脚本跑完发现面板打不开、Agent 不上线、数据不显示然后开始盲目重装。其实这些问题大多是没搞懂 Wazuh 内部结构导致的。Wazuh 平台从逻辑上由下面几个部分组成Wazuh Indexer基于 OpenSearch 构建的分布式搜索引擎和数据存储组件。所有安全告警、事件日志、Agent 状态信息最终都落到这里它负责索引、检索和聚合数据。你可以把它理解成一个专门的“数据仓库 搜索引擎”没有它数据无处安放查询也无法进行。Wazuh Server这是 Wazuh 的“大脑”内部包含两个重要角色。一是 Wazuh Manager也就是用 C 写的分析引擎负责接收 Agent 上报的数据匹配规则、检测入侵、生成告警二是 Filebeat一个轻量日志转发器把分析引擎产生的结果转发给 Indexer。Server 对外还提供一套 RESTful API端口默认 55000Dashboard 就是靠这个 API 来拉取数据和下发指令的。Wazuh Dashboard用户在浏览器里打开的 Web 界面底层基于 OpenSearch Dashboards。安全事件展示、Agent 管理、规则配置、报告生成都在这里完成。它默认跑在 443 端口所以访问方式是 https://IP 而不是 ip:port 这种形式。Wazuh Agent装在被监控主机上的轻量级采集程序。它负责收集操作系统日志、审计信息、文件变更记录、漏洞信息然后通过 1514/udp 和 1515/tcp 端口反馈给 Wazuh Server。Agent 本身不分析不判断它就是忠实的数据采集员。这四者的数据流大致是Agent → Wazuh Server分析引擎→ Filebeat → Wazuh Indexer → Dashboard查询展示。很多人装完发现告警不显示要么是 Agent 数据根本没到 Server要么是 Server 的数据没进 Indexer要么是 Dashboard 连不上 Indexer。能顺着这条链路排查问题定位就快多了。1.2 为什么大多数场景先用 all-in-one 安装Wazuh 官方提供了两种主要部署形态多节点分布式和单机一体化。多节点一般是较大规模生产环境才需要比如将 Indexer 拆成三节点集群、Server 独立部署、Dashboard 单独放一台机器。而对于个人实验、中小规模监控甚至试点项目官方安装助手提供的-a参数一条命令就能把 Indexer、Server、Dashboard 全部装在同一台机器上这就是 all-in-one 模式。我的建议是如果你的监控目标不超过几十台机器并且对高可用没有硬性要求直接用 all-in-one。它部署快、维护成本低、通信链路都在本机需要排查的变量少很多。等这套跑熟了再根据规模拆成多节点也不迟。有一点必须提前说all-in-one 不代表“配置要求变低”它是把三个组件的资源需求叠到一台机器上内存和磁盘的消耗并不小。这正好引出一个大坑环境准备阶段就被卡住。2. 安装前必须想清楚的环境准备2.1 资源评估内存、CPU、磁盘一个都不能少Wazuh 官方文档给的最低配置大致是Indexer 需要 2 核 CPU、4GB 内存Server 需要 4 核 CPU、8GB 内存Dashboard 需要 2 核 CPU、4GB 内存。注意这是“勉强能跑”的下限不是推荐值。all-in-one 模式下三件套一起跑4 核 8GB 勉强能应付小规模实验但一旦开始接入 Agent、产生告警内存会迅速吃紧。我这里给一个比较现实的建议值组件CPU内存磁盘Wazuh Indexer2 核起4GB 起30GB 以上Wazuh Server4 核起8GB 起50GB 以上Wazuh Dashboard2 核起4GB 起20GB 以上all-in-one 综合4 核以上16GB 左右100GB 起步磁盘方面Indexer 的数据都写在/var/lib/wazuh-indexer目录日志在/var/log/wazuh-indexer如果根分区或者/var空间不够跑几天就会因为磁盘写满而故障。很多人部署时只给了 40GB 根分区装完系统剩 20GB再装 Wazuh 跑一周就报警这是最常见的资源坑。如果你是在虚拟机里装 Ubuntu 再部署 Wazuh分配内存的时候务必按这个标准来别只给 2GB 还想跑通全套。低配环境下安装助手可能直接拒绝执行这个问题后面我会单独说。2.2 操作系统选型和基础软件准备Wazuh 官方支持 Ubuntu、RHEL、CentOS、Amazon Linux、SUSE 等主流发行版。如果让我推荐首选 Ubuntu 22.04 LTS 或 24.04 LTS。原因很简单官方安装助手对 Ubuntu/Debian 系的兼容性测试做得最充分社区里的教程也大多围绕 Ubuntu 展开出了问题容易找到参考。开工之前先确保系统是干净的并且做好下面几件事执行sudo apt update sudo apt upgrade把系统基础软件包更新到最新。安装基础工具sudo apt install curl wget git python3 jq unzip。其中curl用来下载安装脚本python3是 Wazuh 部分辅助脚本依赖的运行时。不要随意替换系统的python3版本。有些朋友习惯手动装 Anaconda 或 Miniconda然后顺手改环境变量结果导致系统原来依赖/usr/bin/python3的程序全部失效连apt都开始报错。Wazuh 安装过程中会调用 Python 脚本做证书处理和集群配置Python 环境一旦坏掉安装进度会卡在非常尴尬的中段。还有一个很容易被忽略的点软件源。如果服务器访问官方软件源超时apt 或 yum 的安装速度奇慢无比甚至直接失败。部署前先确认系统基础源可用必要时配置一个稳定的镜像源。Wazuh 官方软件仓库是否可达也可以通过curl -I https://packages.wazuh.com/4.x/apt/这类命令提前验证。网络环境不支持直连官方仓库时尽量利用镜像站或离线包别在安装中途才发现拉不下来。2.3 端口规划和 Docker、Nginx、MySQL 打架的经历Wazuh 安装助手在执行到一半时会对端口做占用检查如果发现必须的端口已经被其他程序占用它会直接报错退出。很多第一次安装的人在这里栽跟头因为服务器的 443 和 9200 早就被别的服务占用了。先记住 Wazuh 各组件默认要用的端口组件端口用途Wazuh Dashboard443/tcpWeb 管理界面Wazuh Indexer9200/tcpRESTful API供 Server 和 Dashboard 查询写入Wazuh Indexer9300/tcpIndexer 集群节点间通信Wazuh Server55000/tcpWazuh Server APIWazuh Server1514/tcp、1514/udpAgent 安全事件上报Wazuh Server1515/tcpAgent 注册认证Wazuh Server1516/tcpAgentless 设备接入Wazuh Server514/udpsyslog 日志接入最常冲突的是 443 和 9200。如果同一台机器上一开始装了 Nginx443 被占或者你之前玩过 Elasticsearch、OpenSearch、MySQL 这类会监听 9200 或 9300 的服务同样导致端口被占。用 Docker 部署过 Web 应用的人也要警惕容器端口映射可能悄悄占住 443。动手安装前建议先自查一遍sudo ss -tlnp sudo lsof -i:443 sudo lsof -i:9200 sudo lsof -i:9300如果发现端口被占优先选择停用占用服务而不是给 Wazuh 改端口。因为 Wazuh 的端口牵扯到 Dashboard 的访问地址、Filebeat 的输出配置、Agent 的注册配置、防火墙规则牵一发动全身。修改端口后所有组件之间的串接都要重新配排查成本比直接停掉占用服务高得多。实际项目里我已经见过好几个因为强行改端口导致 Agent 连不上 Server 的案例。2.4 做个快照给自己留条后路这一点是我个人的强烈建议不管是在物理机还是虚拟机/云主机上部署开始执行 Wazuh 安装脚本之前先做一次完整快照或者磁盘备份。Wazuh 的安装过程会生成一堆证书、密钥、配置文件而且服务之间互相依赖。一旦某个环节出错比如证书生成一半、密码文件写坏、Indexer 配置错误你很有可能陷入“删不干净、重装又报同样错”的泥潭。这时候最快、最省心的办法就是回滚到安装前的快照重头再来。虚拟机里做快照尤其方便我甚至会在安装前后的每个关键节点各打一个快照方便做对比排查。有快照兜底安装时的心理压力会小很多。哪怕你在安装脚本上乱试参数也不用担心把系统搞到不可收拾。3. 标准安装流程拆解脚本到底干了什么3.1 获取安装助手并校验完整性Wazuh 官方提供了一条自动化安装脚本具备联网权限后下载它就好。我拿的是 4.9 版本curl -sO https://packages.wazuh.com/4.9/wazuh-install.sh curl -sO https://packages.wazuh.com/4.9/wazuh-install.sh.sha256 sha256sum wazuh-install.sh第二行是下载校验文件第三行用来比对哈希值。别嫌这步麻烦下载执行脚本这种事先验证校验和永远是对的尤其在安全工具领域。如果哈希值对不上说明下载过程出了问题千万别继续执行。3.2 一键安装参数到底该怎么理解安装是最省事的一步前提是环境满足要求sudo bash wazuh-install.sh -a-a表示 all-in-one也就是把 Wazuh Indexer、Wazuh Server、Wazuh Dashboard 一次性装到本机。整个安装过程一般需要 10 到 30 分钟取决于网络速度和机器性能。期间脚本会自动完成仓库配置、软件包安装、证书生成、服务启动和密码初始化。除了-a还有几个参数值得知道-g只生成配置文件和证书不安装软件。适合你想先看看生成的证书、再手动规划后续步骤的情况。-o覆盖已存在的证书。多节点部署或者证书有问题需要重新生成时用。-vVerbose 模式输出更详细的日志。-h查看帮助信息里面有所有支持的参数说明。在使用安装助手之前我会先跑sudo bash wazuh-install.sh -h看一下确认当前版本支持哪些参数避免记混了。3.3 安装脚本执行过程中系统到底发生了什么很多人在安装中途失败后完全不知道从哪里入手排查因为脚本就像个黑盒。所以这里我把脚本做的事情拆开讲方便你对照定位问题。脚本主要执行了以下步骤环境检查检查操作系统版本、架构、可用内存、磁盘空间、端口占用、权限。任何一项不满足要求脚本直接退出并打印对应提示。配置官方软件源并安装组件把 Wazuh 官方 apt/yum 源添加到系统然后安装wazuh-indexer、wazuh-manager、filebeat、wazuh-dashboard这些软件包。生成证书与密钥调用wazuh-certs-tool.sh生成根 CA、各节点证书和密钥输出到/root/wazuh-install-files/wazuh-certificates/目录。初始化 Indexer配置 OpenSearch 安全插件、初始化管理员账号密码、启动wazuh-indexer服务并等待集群状态变为 green。部署 Server 和 Filebeat安装并配置wazuh-manager再把 Filebeat 配置成输出到 Indexer 的 9200 端口并加载数据模板和 pipeline。部署 Dashboard安装并配置wazuh-dashboard把它的后端指向 Indexer同时启动服务。输出密码文件最后把所有服务的管理密码写入/root/wazuh-install-files/wazuh-passwords.txt。如果你在哪个阶段失败日志对应关系大概如下环境检查失败通常直接打印软件包安装失败多在 apt/yum 的报错阶段证书生成异常会提示证书文件缺失Indexer 起不来要看系统服务日志Filebeat 配置问题要查 filebeat 日志Dashboard 连不上 Indexer 会有专属报错。这个对应关系搞清楚排查效率翻倍。3.4 安装成功后的登录验证安装脚本跑完后屏幕上会显示类似这样一段话You can access the web interface https://your-ip:443并提示密码文件存放在/root/wazuh-install-files/wazuh-passwords.txt。这个阶段我强烈建议你第一时间查看并备份该文件不要做任何删改操作因为里面记录了仪表板、索引器、Filebeat 等多个组件的初始凭据。文件内容大致是# Wazuh admin user indexer_username: admin indexer_password: 随机密码 # Wazuh dashboard user indexer_username: kibanaserver indexer_password: 随机密码访问https://IP:443时用admin和文件中的密码登录。浏览器会提示证书不受信任这是自签名的正常现象选择继续访问即可。首次登录后可以到 “Dashboard” 页面查看系统概览也可以到 “Agents” 页面执行添加 Agent 的操作。这些内容等第 5 节再展开。4. 踩坑实录我在这台机器上翻车最多的地方4.1 内存检查直接卡死低配机器怎么处理我一开始用的是一台 2 核 4GB 的虚拟机执行安装脚本后没到 10 秒就报错退出。错误信息大致是系统可用内存不满足最低要求。Wazuh 安装助手在第一步环境检查里会统计可用内存低于阈值就拒绝安装这是官方保护机制避免装到一半把系统搞 OOM。踩过一次之后我试过两条路。第一条是加 Swap 空间sudo fallocate -l 8G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile echo /swapfile none swap sw 0 0 | sudo tee -a /etc/fstab加完 Swap 之后free -h看到内存明显多了。Wazuh 三个组件跑起来基本能撑住只是索引器在压力大时会频繁交换到磁盘性能会打折。对实验环境来说可以接受生产环境千万别这么做。第二条路是改脚本里的内存检查阈值类似sed -i s/^mem_unit_level_0.*/mem_unit_level_04096/ wazuh-install.sh这样去把内存单位数值改小。我帮朋友试过一次脚本是跑通了但索引器刚启动就把内存打满最后还得回到加 Swap 的方案。所以我的建议是老老实实加内存或加 Swap不要为了绕过检查去改脚本后面你会花更多时间在性能问题上。4.2 vm.max_map_count 过低OpenSearch 启动失败的经典元凶这是 Wazuh 索引器起不来的高频原因我在 Ubuntu 22.04 上几乎每次全新部署都会遇到。现象是安装脚本在索引器初始化阶段卡住然后systemctl status wazuh-indexer显示服务启动失败日志里反复出现max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]OpenSearch 底层使用的 Lucene 索引引擎对内存映射文件区有数量要求。Ubuntu 默认的vm.max_map_count是 65530不满足需求。修复方法很简单把值调大到 262144 并写入系统配置让它永久生效sudo sysctl -w vm.max_map_count262144 echo vm.max_map_count262144 | sudo tee -a /etc/sysctl.conf执行完sysctl -p让配置立即生效再重启wazuh-indexer服务。这个坑隐蔽性很强因为安装脚本本身不检查这一个内核参数Indexer 服务启动阶段才会暴露问题而且报错日志不容易一眼看懂。我建议在安装前就把这条配置写好省得到时候一脸懵。4.3 端口被占Docker、Nginx、MySQL 最容易和 Wazuh 打架我第二次完整部署时装到 Dashboard 启动阶段直接失败脚本提示 443 端口被占用。一查才发现是同一台机器上之前跑过一个 Nginx 容器Docker 的端口映射把宿主机 443 占掉了。还有一次是先前装过 MySQL习惯性监听了 9200不能说是 MySQL这里是 OpenSearch 或 Elasticsearch 会占 9200。总之机器越“复杂”端口冲突概率越高。排查端口冲突的几个命令再强调一遍sudo ss -tlnp sudo lsof -i:443 sudo lsof -i:9200 sudo lsof -i:9300如果确认某端口被占用根据占用程序决定是停服务还是改 Wazuh 端口。我个人的教训是尽量让 Wazuh 独享一台干净的机器至少不要和 Nginx、Docker 容器、Elasticsearch 这类常驻服务混装。混装的问题不只是端口还有资源争夺Docker 容器频繁写日志也可能占用大量磁盘 IO这些都会影响 Wazuh 的性能。4.4 软件源和下载异常超时、证书校验、404网络条件不理想的时候安装脚本会在拉取软件包阶段失败。最典型的报错是Unable to locate package wazuh-manager或者 apt 提示连接超时。有时候 apt 源里明明有包但因为仓库元数据没刷新导致索引不到先执行sudo apt update就好。Wazuh 官方软件源地址形如https://packages.wazuh.com/4.x/apt/。网络不通或者被防火墙拦截时可以考虑以下几种替代方案使用离 Wazuh 仓库更近的镜像地址或者把 Wazuh 软件源地址换成可访问的镜像。直接下载.deb或.rpm安装包在离线环境通过dpkg -i/rpm -ivh手动安装。但要注意手动安装软件包只是救急方案安装助手后续依赖仓库自动化操作的流程离线环境下需要手工补充大量配置不适合新手。检查系统时间。如果时间偏差过大TLS 握手会失败https 下载报证书错误。用sudo chronyc tracking或date确认时间正确。我觉得最稳妥的办法还是提前验证仓库可达性再决定要不要换镜像。不要等到脚本跑到一半才去折腾源那种中断恢复的成本更高。4.5 Agent 接入不上线的坑十有八九是网络和版本问题Dashboard 装好之后很多人急着在 “Agents” 页面添加 Agent结果发现 Agent 列表一直是空的或者状态一直是 “Disconnected”。这里头我踩过的坑主要有三类第一类是 Agent 到 Server 的端口不通。Agent 默认通过 1514/udp 和 1515/tcp 和 Server 通信。如果服务器防火墙或者云安全组没有放行这两个端口Agent 再怎么试也连不上。可以先在 Agent 主机上执行nc -vz wazuh_server_ip 1514 nc -vz wazuh_server_ip 1515第二类是 Agent 配置里的 Server 地址错误。安装 Agent 时如果不指定管理端地址它默认会去连localhost导致完全找不到目标。我推荐使用官方统一的一键安装命令格式sudo WAZUH_MANAGERwazuh_server_ip WAZUH_REGISTRATION_SERVERwazuh_server_ip WAZUH_AGENT_NAMEclient01 apt install wazuh-agent如果服务端和 Agent 都是同一个网段通常填内网 IP 就行。第三类是版本不对齐。Wazuh 的大版本必须保持一致比如管理端是 4.9Agent 最好也用 4.9。不同大版本的 Agent 和管理端通信协议可能不一致会出现能注册但不上报数据的诡异现象。更隐蔽的一个问题是 Agent 注册成功后Dashboard 要过一段时间才能看到状态变化中间可能要等几分钟。别刚注册完看没上线就反复重启给一点等待时间再配合查看/var/ossec/logs/ossec.log确认有没有新 Agent 的连接记录。4.6 密码文件丢失别慌还有工具能重置/root/wazuh-install-files/wazuh-passwords.txt这个文件是安装完毕后最不能丢的东西之一。但人有失手马有失蹄我遇到过客户把服务器重装之后才想起来密码文件在根分区里一起没了的场景。好在这个问题有官方工具可以补救。Wazuh Indexer 的安全插件里带了一个密码重置工具实测在不同版本中路径略有差异可以先全局搜索一下find / -name wazuh-passwords-tool.sh 2/dev/null找到以后执行bash /usr/share/wazuh-indexer/plugins/opensearch-security/tools/wazuh-passwords-tool.sh -a-a参数表示自动为所有内部用户生成新密码。工具跑完会打印一份新的密码清单把它保存好。重置密码之后有一个非常关键的点不能漏如果 Filebeat 配置文件/etc/filebeat/filebeat.yml里还写着旧密码那么 Filebeat 将无法再往 Indexer 写入数据Dashboard 会变成“有页面没数据”的状态。每次重置密码都要同步去刷新 Filebeat 里的输出密码然后重启 filebeat 服务。4.7 Filebeat 数据没进 Indexer检查这五个地方Dashboard 能登录、页面能打开但是 “Security events” 模块下面一直显示“无数据”。这种“表面正常实际空转”的状态最折磨人。根据我的经验按照下面这五个地方排查基本能定位 95% 的问题Filebeat 服务是否在运行systemctl status filebeat配置是否正确sudo filebeat test config能否连通 Indexersudo filebeat test output模板是否加载必要时重新执行sudo filebeat setup --index-management服务器时间是否同步时间偏差过大时告警事件的时间戳可能和索引窗口对不上导致查询看不到数据。这里我要特别提一个细节如果 Filebeat 连不上 Indexerfilebeat test output会直接报错或显示连接失败。通常原因不是密码错就是证书不匹配。Wazuh 内部各个组件之间使用证书进行 TLS 双向认证证书文件在/root/wazuh-install-files/wazuh-certificates/目录下。如果你改动过主机名或重新生成过证书而没有同步更新 Filebeat 的证书路径握手就会失败。检查/etc/filebeat/filebeat.yml里证书路径和证书名是否正确必要时重新拷贝证书。4.8 仪表板打不开空白页、502、一直转圈安装成功后访问 https://IP:443 出现空白页或 502也相当常见。这时候不要急着怀疑浏览器先确认 Dashboard 服务本身systemctl status wazuh-dashboard journalctl -u wazuh-dashboard -n 50 --no-pager然后确认 Dashboard 依赖的下游——Indexer 是否正常。Dashboard 启动过程中要连 Indexer如果 Indexer 挂了或者密码不对Dashboard 连启动都起不来。我常用的验证命令curl -k -u admin:password https://localhost:9200/_cluster/health?pretty如果响应里能看到status : green或者yellow说明 Indexer 是正常的。如果返回认证失败那重点查密码。浏览器方面建议用无痕窗口访问避免本地缓存了旧页面的 JS 和证书状态导致新服务无法正常渲染。还有一个低级但容易踩的坑Dashboard 默认只在 HTTPS 443 端口提供服务用http://去访问会得到 400 或直接被重定向。我见过有人敲 URL 时漏掉了s字母以为 Wazuh 装坏了其实只是协议写错了。5. 安装完成之后验证、加固与日常维护5.1 三个组件健康检查速查表安装不是终点验证通过才算真正完成。我每次装完会固定执行一组检查确认组件都在健康状态systemctl status wazuh-indexer systemctl status wazuh-manager systemctl status wazuh-dashboard systemctl status filebeat再确认索引器集群健康状态curl -k -u admin:password https://localhost:9200/_cluster/health?pretty如果返回的status是green非常理想如果是yellow说明索引分片有副本未分配一般不影响读取但也要留意如果是red问题就大了需要尽快看日志。all-in-one 模式下Indexer 只有单个节点集群状态更常见的是 green 或 yellow不要被 yellow 吓到先检查分片是否在初始化。Wazuh Manager 的日志文件主要在这几个位置/var/ossec/logs/ossec.log分析引擎主日志看 Agent 连接、规则命中、内部错误都在这里。/var/ossec/logs/api.logWazuh API 日志。/var/log/wazuh-indexer/索引器日志OpenSearch 相关错误都在这里。/var/log/wazuh-dashboard/Dashboard 日志前端代理和登录问题在这里。多熟悉这几个日志位置以后排查问题会顺很多。5.2 首次接入 Agent 的正确流程登录 Dashboard 后左侧菜单进入 “Agents”点击 “Add agent”选择目标操作系统填好 Agent 名称页面会生成一段对应系统的安装命令。在目标主机上执行这些命令安装完成后 Agent 会自动向管理端发起注册请求。注册成功后Agent 状态栏会从Pending变为Active。整个过程快则几十秒慢则几分钟。如果一直是Disconnected回到 4.5 的排查思路重点查端口、网络、版本。等到 Agent 上线后建议先做几个小动作验证数据链路在 Agent 主机上手动创建一个测试文件再删除观察 Dashboard 的 “File Integrity Monitoring” 模块是否出现告警。用ssh登录 Agent 主机查看 “Security events” 里是否记录登录事件。执行sudo tail /var/ossec/logs/ossec.log确认有 Agent 的事件写入。如果这几个动作都有效说明从采集、分析到展示的全链路是通的这套系统才真正算交付成功。5.3 密码、证书和升级管理Wazuh 运行过程中产生的密码和证书文件建议至少做两处备份一份放在服务器本机的非系统分区一份放在公司内部统一的密码管理系统或加密压缩包里。密码文件不要直接明文放在团队群聊这个习惯越早养成越好。证书管理方面所有组件之间走 TLS 双向认证。特别要注意一旦证书过期或替换Filebeat、Dashboard、Agent 都可能出现“连得上但握手失败”的情况。不要贪方便只换其中一个服务的证书要整套证书一起更新。升级的时候同样把/root/wazuh-install-files/wazuh-certificates/和/etc/filebeat/filebeat.yml、/var/ossec/etc/ossec.conf这些关键配置先备份一份。Wazuh 升级原则是“分阶段、先测试、再全量”。先在实验环境验证一次再上生产。升级过程中最怕的就是新旧版本 Agent 和管理端不兼容导致大面积离线这种事故的善后工作非常痛苦。6. 多节点部署有哪些不同6.1 什么时候必须拆开部署all-in-one 适合实验和小规模使用但生产环境一旦监控节点变多、事件量变大单机跑三件套迟早会成为瓶颈。这时候就要考虑把 Indexer、Server、Dashboard 拆到不同机器上。至少也要把 Indexer 独立出去因为它最吃内存和磁盘再往后Indexer 本身可以扩展成三节点集群保证高可用。多节点部署时安装助手不再是-a一条命令而是在每台机器上分别执行指定组件参数比如sudo bash wazuh-install.sh --wazuh-indexer node-1 sudo bash wazuh-install.sh --wazuh-server wazuh-1 sudo bash wazuh-install.sh --wazuh-dashboard dashboard顺序很重要先装 Indexer 集群并确认健康再装 Server最后装 Dashboard。之前我在多节点环境图省事先装了 Dashboard结果 Dashboard 起来后连不上还没初始化的 Indexer反复报错最后只能把 Dashboard 服务停掉等 Indexer 就绪后重新配置。6.2 多节点容易翻车的三个细节多节点的坑主要集中在证书、主机名和防火墙三件事上。第一证书生成时必须用-g -o参数重新生成整套证书证书里要包含所有节点的主机名或 IP。如果你漏了某个节点的 IP那台机器启动时就会因为证书校验失败而无法加入集群。第二节点之间的通信除了依赖 IP还依赖主机名解析。建议提前在所有节点上配好/etc/hosts确保互相用主机名能 Ping 通。否则 OpenSearch 集群会发现节点、但握手时因为主机名不一致而失败。第三防火墙要放行的端口比 all-in-one 多。除了前面提到的 443、1514、1515还要确保 9200 和 9300 端口在各节点之间可达。很多集群起不来的问题就是云平台安全组把节点间通信的 9300 端口给挡了。多节点部署更考验整体规划能力前期梳理清楚节点清单、证书清单、端口清单后面就轻松很多。结尾最后再分享一点我个人的体会Wazuh 安装本身并不复杂真正的难点在于把“安装完成”变成“链路正常”。很多问题不是靠重装能解决的而是需要你按着“Agent → Server → Filebeat → Indexer → Dashboard”这条数据流逐个环节去验证。我自己的习惯是装完之后先看 Systemd 服务状态再看各组件日志最后用 curl 去测 Indexer 和 API 的健康状态而不是一上来就怀疑配置。如果你正准备部署 Wazuh听我一句劝安装前把内存、端口、内核参数、软件源这些问题一次性检查完安装中把脚本每一步在干什么搞清楚安装后第一时间备份密码文件并验证 Agent 数据链路。这样你踩坑的数量会少掉一半以上。希望这篇踩坑指南能帮你把原本需要熬到深夜的部署过程压缩成一次顺畅的周末下午。
