Wazuh这套东西说好装也好装一条官方脚本跑完就能看到仪表板说难装也难装生产环境里拆成三个组件部署时每个环节都能把你卡上半天。群里天天有人问“为什么dashboard打不开”“为什么agent一直显示Disconnected”十有八九都是安装和初始配置阶段埋下的雷。这篇文章是我自己从测试机到生产环境反复装了多次之后整理出来的踩坑记录不吹不黑全是实际操作中验证过的经验。整个指南会覆盖这么几条线装之前怎么规划部署形态和资源软件包的获取和安装细节三个组件manager、indexer、dashboard之间的配置联动以及agent接入时最容易出错的地方。配了排查表和重装清理建议直接把能避开的坑全部提前标记出来。1. 装之前先想明白三件事1.1 Wazuh到底是由什么组成的很多人第一次接触Wazuh上来就想“装一个”。但它不是一个单体软件而是一套由多个组件拼起来的系统。想象一下你在一栋大楼里做安保门口的闸机是agent保安监控室是manager负责收数据、分析、下发策略监控录像存储和检索系统是indexer专门存日志和做全文搜索而保安面前的那块大屏幕就是dashboard可视化界面。具体到进程层面agent装在被监控的服务器上负责采集系统日志、文件完整性信息、漏洞数据然后通过加密通道推给manager。manager干的是重活事件关联分析、告警规则匹配都在这台机器上完成。indexer组件的角色是把处理好后的数据做索引和存储对外暴露9200端口供检索使用。最后dashboard是面向人的入口浏览器访问443端口登录进去看各种告警大屏和安全分析报表。有不少教程为了省事会把indexer和dashboard装在同一台机器上甚至和manager叠在一起。这种All-in-One形态适合测试环境但生产环境我强烈建议分开部署。原因很简单分开之后升级manager不会影响检索服务某个组件崩了也不会全盘跪掉。而且indexer本身就是个吃资源的大户如果和manager挤一台小内存机器上两个进程会互相抢内存直接导致OOM内存耗尽甚至服务反复重启。1.2 部署形态怎么选选择部署形态之前先明确你的场景是什么。如果是个人学习、在家里的虚拟机里面跑一跑或者公司内部搭个试用环境验证功能那All-in-One脚本安装是最高效的选择。官方一行命令就能装完默认配置即可跑起来。注意这里说的“跑起来”是指功能基本可用但性能和稳定性是打了折扣的。如果是要监控二三十台生产服务器建议把Wazuh拆成两条线一条是manager独立部署另一条是indexer和dashboard合在一起。这样agent数据进来时manager的负载和indexer的存储压力不会互相影响即使数据量突然增加导致indexer变慢也不会拖垮agent的数据上报。如果规模更大比如要管上百台机器、每天日志量以GB甚至TB级别增长那就老老实实把indexer做成三节点集群manager按区域或业务拆多个前面再架一层负载均衡。这个级别的部署已经有专门的架构师在操盘了这里不多展开。关于All-in-One的误区我也得说一句很多新手以为All-in-One就是“官方推荐的正式形态”其实恰好相反它只是官方为了降低体验门槛推出的快捷方式。换句话说它照顾的是“先跑起来看看是什么东西”的需求而不是“长期稳定承载业务”的需求。1.3 硬件配额别拍脑袋按官方基线来Wazuh官方给过一份硬件配置建议表上面写得很清楚All-in-One部署最低要求是4GB内存、2核CPU但实际上如果你真的只用4GB跑装完之后内存占用率就已经冲到80%以上稍微查几个索引页面就会卡顿如果数据量上来OOM几乎是必然的。我个人的建议是测试环境All-in-One至少给8GB内存、4核CPU磁盘预留50GB以上。如果indexer和manager分开部署manager建议4GB内存起步indexer则建议8GB起步。别心疼那几百GB的磁盘Wazuh存储的是日志和安全事件这类数据涨得飞快你甚至可以按“每天产生日志量 x 30天 x 1.5倍膨胀系数”来粗算磁盘需求。另外有个特别容易被忽略的参数vm.max_map_count。Elasticsearch系的组件Wazuh indexer基于Opensearch对这个值有硬性要求低于262144时启动会直接报错或者运行中崩溃。有的系统默认值只有65530装完indexer之后一切正常但过一段时间你会发现进程莫名其妙死了去看日志才发现是map count耗尽。所以不管是哪台机器要跑indexer都建议先把下面这段写进/etc/sysctl.conf再执行sysctl -p让它生效vm.max_map_count262144这个坑我栽过一次后来养成了习惯装之前先执行sysctl vm.max_map_count看一眼当前值。你可以直接用下面的命令临时修改重启后依然有效需要写配置文件sudo sysctl -w vm.max_map_count262144 echo vm.max_map_count262144 | sudo tee -a /etc/sysctl.conf2. 安装过程和三种常用方式2.1 在线安装来自官方仓库的包Wazuh的安装方式最常见的就是软件包安装。官方维护了YUM和APT仓库安装过程非常直观。以RHEL系为例先导入GPG密钥再添加仓库文件最后安装。CentOS系的命令我放在下面sudo rpm --import https://packages.wazuh.com/key/GPG-KEY-WAZUH cat EOF | sudo tee /etc/yum.repos.d/wazuh.repo [wazuh] gpgcheck1 gpgkeyhttps://packages.wazuh.com/key/GPG-KEY-WAZUH enabled1 nameEL-\$releasever - Wazuh baseurlhttps://packages.wazuh.com/4.x/yum/ protect1 EOFDebian系则用add-apt-repository的方式操作。仓库配好之后manager、indexer、dashboard三个组件是各自独立的包分别叫wazuh-manager、wazuh-indexer、wazuh-dashboard想装哪个就装哪个。这种方式的优势是很灵活你可以自己决定哪些组件装在哪台机器上。而且后续升级只需要yum update wazuh-manager这种粒度精确的命令不会把整个依赖树搅乱。但劣势也很明显装完一个组件不等于装完整个系统你还要手动配置证书、把filebeat的对接信息配上任何一步出错dashboard和indexer之间就连不通。2.2 快速安装官方脚本的便利与局限官方提供了一套快速安装脚本也就是wazuh-install.sh可以一鼓作气把全部组件装好。官方文档里的命令大致是curl -sO https://packages.wazuh.com/4.7/wazuh-install.sh sudo bash wazuh-install.sh --generate-config-files sudo bash wazuh-install.sh --install这里有个值得注意的点脚本执行完成后终端会输出一个随机生成的dashboard管理员密码这个密码只显示一次记得第一时间保存。如果没有保存后面想找回是比较麻烦的得去wazuh-dashboard的包目录下翻配置文件或者直接重置密码。快速脚本本质上是在调用系统包管理器安装上述几个包然后自动生成证书、自动启动服务、自动配置filebeat半小时内就能看到一个可以访问的dashboard。看起来是美滋滋但它有两个局限一是对系统的假设比较固定。它假设你的系统是干净的、没有残留的旧配置而且端口没有被占用。如果之前装过失败的Wazuh或者残留了Opensearch的进程脚本执行到一半确实可能卡住我在后面“重装”那部分会详细讲怎么清理。二是All-in-One模式下它默认把每个组件都装在同一台机器上。如果你本来想组件分离部署就不能用默认的--install参数一路走到底。不过官方脚本其实也支持先生成配置文件再在各自机器上执行安装只不过这一步需要你提前在config.yml里定义好每台机器的角色操作难度比默认模式高一个档次。2.3 离线安装内网环境的备选方案很多企业的生产环境是不允许直接访问外网的这时候在线仓库方案失效。离线安装的核心思路就是先在有外网的机器上把需要的rpm或deb包全部下载下来再拷贝到内网机器上。以RHEL系为例# 在外网机器上将wazuh仓库相关包下载到本地目录 sudo yum install --downloadonly --downloaddir/tmp/wazuh-packages wazuh-manager wazuh-indexer wazuh-dashboard filebeat然后把这些rpm包拷到目标机器的/tmp/wazuh-packages目录执行yum localinstall *.rpm或者rpm -ivh *.rpm完成安装。需要注意的是依赖包也得一并下载最简单的办法是先用yum deplist查看依赖关系把依赖包一并downloadonly下来。离线安装最大的坑在于证书生成和配置文件分发。因为官方脚本会自动化处理证书流程而手动离线安装时你必须自己用wazuh-certs-tool.sh生成所有节点的证书再手工分发到对应服务器的/etc/wazuh-indexer/certs、/etc/filebeat/certs、/etc/wazuh-dashboard/certs目录。证书的主机名如果和实际节点名对不上启动服务时会有极其隐蔽的报错这一块我在第3部分专门展开说。3. 最容易翻车的六个环节3.1 内存不足导致服务反复重启或进程消失系统日志里大量出现Killed process或者wazuh-manager.service运行几分钟后自动退出最直接的原因就是内存不足。Wazuh manager有一个比较关键的配置在/var/ossec/etc/ossec.conf里其中memory标签控制agent事件队列使用的内存大小。默认配置在某些场景下偏保守但也不建议盲目调大。如果你发现自己机器内存只有2GB那正确操作不是去调配置而是升级实例规格。Wazuh的agent事件默认会走内存队列宁可丢弃一些非关键日志也不要让系统进入OOM循环。在部署之前用下面这条命令筛查一下当前机器的内存和加载情况是个好习惯free -h cat /proc/meminfo | grep CommitLimitCommitLimit如果明显低于实际物理内存说明系统配置了overcommit限制大内存申请会被拒绝这种情况就算代码层面没bug也会被系统“礼貌地”杀掉。3.2 dashboard打不开或者502/503装完dashboard之后浏览器访问https://服务器IP结果页面一直转圈或者直接报连接被拒绝这是新手最常见的困惑之一。第一件事确认dashboard服务本身起来了没有sudo systemctl status wazuh-dashboard如果显示active (running)但页面还是打不开检查端口监听sudo ss -tlnp | grep 443443端口没监听起来大概率是启动时报错了。去日志文件/var/log/wazuh-dashboard/wazuh-dashboard.log翻一翻。常见报错是connect ECONNREFUSED 127.0.0.1:9200意思很明确dashboard连不上indexer的9200端口。那为什么indexer起了却连不上通常有两个原因。一是indexer的监听地址写死了localhost外部连不进来二是证书校验失败也就是dashboard和indexer之间没有互相信任。后者最常见后面我会单独讲。3.3 证书问题这套系统里最折磨人的点Wazuh的组件之间全部用TLS双向认证通信证书体系的复杂度高于一般Web应用。很多安装问题表面上看是“服务起不来”根因全是证书不对。Wazuh的证书工具会生成一套节点证书里面包含node name标记。比如你的manager节点名字叫wazuh-manager证书里也会带有这个标记。如果你在配置indexer的opensearch.yml时node.name没有和证书里的主机名完全一致indexer启动时会报ERROR: OpenSearch did not exit normally这个报错非常笼统第一次遇到完全不知道问题在哪。我的排查方法是打开/var/log/wazuh-indexer/wazuh-indexer-cluster.log看里面有没有unable to load certificate或者CertificateForOtherNameExtension字样。有的话去/etc/wazuh-indexer/certs目录检查证书文件和目录权限。证书文件必须是640权限属主必须和运行indexer的用户一致否则进程在读取证书这一步就直接退出。还有filebeat侧的证书问题。filebeat进程自己连不上indexer的9200时dashboard页面会提示无法获取数据但你不一定第一时间想到是filebeat的问题。排查路径是看/var/log/filebeat/filebeat日志如果出现x509: certificate is valid for wazuh-indexer, not filebeat这类报错说明filebeat拿着自己的客户端证书去当服务端证书验证被indexer拒了。解决办法是检查filebeat配置中输出的host是否是indexer的IP同时检查/etc/filebeat/certs里是否存在两个证书一个是filebeat自身的证书一个是对应CA证书缺一不可。3.4 端口占用劫持安装进程Wazuh全家桶占用的端口大致是这样的组件端口用途wazuh-manager1514/TCPagent上报日志wazuh-manager1515/TCPagent注册wazuh-manager55000/TCPAPI管理接口wazuh-indexer9200/TCP数据检索入口wazuh-dashboard443/TCPWeb访问如果你机器上已经跑着其他Elasticsearch服务、Nginx或者Prometheus这些端口很可能被占用。尤其是443和9200这两个是运维日常高频使用端口。排查端口占用很简单sudo ss -tulnp | grep -E 443|9200|1514|1515|55000如果看到占用要么把占用进程停掉要么修改Wazuh配置改端口。改端口的复杂度会连锁反应到所有下游组件比如manager改了端口所有agent都要跟着改上报端口dashboard改了端口浏览器访问时就要带端口号证书里的Common Name和IP对应关系也要调整。所以我的建议是如果端口冲突优先工程上解决端口占用问题而不是修改Wazuh默认端口集。3.5 SELinux和防火墙的流量拦截在RHEL系上安装Wazuh如果SELinux是Enforcing模式默认策略可能拦截Wazuh的进程访问网络或者读写文件。观察到的现象是服务看着在跑agent数据就是发不进来调试了很久可能都没怀疑到SELinux头上。一条缓解思路是把SELinux置为Permissive模式先确认是不是它的锅sudo setenforce 0如果置为Permissive后一切正常那基本可以断定是SELinux策略问题。这时候不要急着永久关闭SELinux生产环境关SELinux是需要论证的。更好的方案是让Wazuh的二进制和库文件加载正确的策略或者用ausearch去查具体的AVC denial记录按记录去调整策略。当然如果你这是一个内网测试环境机器上不跑其他敏感服务临时Permissive也不是不行但记得至少把日志记录开着方便回溯问题。防火墙方面云服务器额外要注意安全组层面的配置。有些云平台默认安全组只开放少数端口你在机器上用iptables开了1514/1515但云平台安全组没放行agent数据依然进不来。这一层是最隐蔽的因为iptables -L看着没问题但你忘了上面的云平台控制面板。3.6 agent注册后一直是Disconnectedagent装好之后在dashboard里看到的连接状态如果始终是Disconnected大概率是注册流程没走通。Wazuh agent注册是独立于日志上报的它通过1515端口发起注册请求然后manager返回一个钥匙之后agent用这个钥匙走1514端口建立加密通道。检查agent日志通常在/var/ossec/logs/ossec.log是一个切入步骤。常见的报错有两种一种是ERROR: Invalid key说明注册后密钥没正确写入agent配置或者在manager上重复注册导致密钥不一致。另一种是ERROR: Cannot connect to server说明1514端口网络不通拿telnet或者nc直接测一下nc -vz 服务器IP 1514 nc -vz 服务器IP 1515如果端口通但仍Disconnected建议在manager端跑sudo /var/ossec/bin/manage_agents -l查看agent列表和状态。只要密钥对得上agent和manager之间的连接一般能起来。这里有个小细节agent的配置文件ossec.conf里serveraddress指向的IP必须和agent实际能访问的manager IP一致。很多时候你填的是内网IP但agent在另一网段过不来它就会一直循环重试界面看就是永远连不上。4. 常见问题排查表与实操心得4.1 快速筛查问题定位表我把安装过程中最常碰到的现象、排查路径和对应解法整理成了表格你在遇到问题时按图索骥即可现象排查范围常见根因解决思路wazuh-manager启动失败systemctl status、/var/ossec/logs/ossec.log内存不足、端口被占用加大内存、释放端口dashboard连接拒绝ss -tlnp查443端口dashboard服务未启动、证书错误看dashboard日志、重置证书dashboard能开但加载不了数据filebeat日志、indexer日志证书不匹配、filebeat无数据接入检查filebeat输出端和证书indexer启动退出/var/log/wazuh-indexer日志vm.max_map_count过小、证书错误调整sysctl参数、重发证书agent连接不上/var/ossec/logs/ossec.log防火墙、密钥不对、IP填错放行端口、重新注册agent仪表盘登录后一直loadingfilebeat进程状态filebeat配置的indexer地址不通检查connectivity和证书系统高负载/卡顿top看进程组件抢内存拆分部署、加内存这个表不是万能的但能覆盖实验环境里90%以上启动问题。按照从上到下的顺序做排除大部分安装问题会在前三个环节就水落石出。4.2 重装和清理的正确姿势Wazuh安装过程中如果某个环节失败了很多人第一反应是“卸载重来”。但Java系的软件最大的特点就是卸载不干净Wazuh也不例外。如果你想彻底清掉一个失败的Wazuh安装建议按下面顺序操作# 停止所有相关服务 sudo systemctl stop wazuh-manager wazuh-indexer wazuh-dashboard filebeat # 卸载软件包 sudo yum remove wazuh-manager wazuh-indexer wazuh-dashboard filebeat # 删除残留的配置和数据目录 sudo rm -rf /var/ossec /var/lib/wazuh-indexer /etc/wazuh-indexer /etc/filebeat /var/lib/filebeat /etc/wazuh-dashboard注意/var/ossec目录下可能有你手工修改过的配置文件和密钥如果只是重装测试环境完全可以删但如果是生产环境请务必备份后再操作。另外数据目录一旦删除就再也找不回历史日志了操作前确认你确实不需要保留这些数据。重装的时候还有个容易踩坑的点如果之前的证书目录没有删干净新装后的证书配置可能会读到旧的、无效的证书。所以别跳过rm -rf那一步它治标也治本。4.3 升级时先备份再动手生产环境升级千万不要直接yum update wazuh-*一把梭。正确的做法是先备份manager的配置和密钥sudo tar czf wazuh-backup-$(date %F).tar.gz /var/ossec/etc /var/ossec/queue/agents-keyindexer如果存有重要告警数据做一份快照备份。云平台的话直接打磁盘快照速度快副作用小。逐个升级顺序是indexer - manager - dashboard。升级完一个看一眼对应服务状态确认没问题再动下一个。升级后如果dashboard显示版本不匹配检查filebeat的版本是否和manager对齐。filebeat和manager之间是有严格版本匹配要求的跨大版本升级时特别容易踩这个雷。Wazuh每年的小版本更新很频繁但并不是每个版本都必须追。如果你当前的版本用的是稳定的没有CVE告警和重大bug影响你完全可以等一两个小版本再跳升。每次升级前去官方changelog里看一眼破坏性变更比盲目更版本稳妥得多。4.4 运维日常的几个小习惯装好之后的日常运维有几个小习惯能帮你省掉很多大坑。定期检查磁盘使用率。Wazuh体系的日志增长是粗暴的/var/ossec/logs下面会积累大量archives和警报日志indexer的数据目录也会持续膨胀。建议至少每周执行一次df -h看磁盘水位。真等到磁盘满了indexer会自动拒绝写入然后告警链路全断。日志轮转要提前配置。manager默认配置文件里有logall开关如果要开启建议同时开启日志轮转。轮转配置在/var/ossec/etc/ossec.conf里面设置daily_rolling和size_limit否则日志文件会单文件无限增长。API连接信息要保存好。Dashboard的登录账号密码、API连接信息建议存到密码管理工具里。忘了密码虽然可以重置但重置流程会涉及到重新生成各类安全配置平白给自己找事。5. 写在最后的几个实在建议装Wazuh这套系统心态上要对它有个预判它不像装个Nginx那么手起刀落更像是在玩一套需要各个零件互相咬合的积木。config、证书、端口、防火墙、内核参数哪一环没对上后面就会以具体问题的方式当场“回报”你。如果你是我文章里提到的第一类场景纯测试、学习那All-in-One脚本跑起来先用着边用边理解组件之间的关系这是上手最快的方式。等需要进生产了再参考第2部分的方案做拆分部署也不迟。根据我个人经验还有一件事值得单独说Wazuh的社区文档其实写得挺全但很多问题是文档没覆盖的偏偏这些又是实战里最容易出现的。比如证书权限、比如实例规格过小导致的OOM、比如云平台安全组忘开端口。这些细节官方文档默认“你已经会了”而新手刚好死在“你默认我已经会了”这句话上。所以遇到问题时不要只盯着软件层面的报错也从系统层面、网络层面多想一层。最后分享一个小技巧给已经在用的人agent部署阶段大批量接入时先在manager上确认代理密钥有没有正常下发再去挨个看agent的ossec.log。这样能让你从“一台台排查”变成“先看发行端再看接收端”省下来的时间够你多喝一杯咖啡了。