我第一次彻底装好 Wazuh靠的不是官方一键脚本而是一整天的排错。那台机器只有 2GB 内存跑完wazuh-install.sh -a之后 indexer 直接假死日志刷了满屏的 OOM我一度以为是安装包下载损坏。后来换了 8GB 内存的新机器重新部署又陆续踩过证书不匹配、Dashboard 连不上 indexer、agent 注册后一直 disconnected 的坑。这篇就把这些坑按我实际的排查顺序写出来适合正在准备装 Wazuh 4.x 的运维、安全工程师也适合刚想从零搭一套 SIEM 试试水的新手。Wazuh 这种开源 EDR/SIEM 平台和普通的 Web 应用部署完全是两码事。它不是装完一个服务就能用而是三个核心组件互相认证、互相依赖。所以大多数人安装失败真不是官方文档写得不清楚而是缺了对这套架构的整体认知。把结构理顺再一条条过基本都能在一个下午之内装好。1. 把 Wazuh 的一体机结构先理顺后面踩坑才踩得明白1.1 三个组件各管哪摊事Wazuh 完整部署默认包含三个核心组件wazuh-indexer、wazuh-manager、wazuh-dashboard。网上很多教程喜欢把三件事混在一起说但排错时必须能分清每个组件的日志路径和服务状态。我用一个比较接地气的比喻把这套系统想成一个快递公司。wazuh-indexer 相当于仓库和档案室。它基于 OpenSearch负责存储agent上报的所有日志、告警、事件数据并提供全文检索能力。agent 传回来的东西最终都进到这里。wazuh-manager 相当于调度中心。它接收 agent 的心跳、日志和事件跑分析规则产生安全告警然后决定要不要告诉 dashboard。它还负责 agent 的注册和端到端通信。wazuh-dashboard 相当于门卫窗口。它是运行在浏览器里的可视化控制台让用户查询索引、查看告警、管理 agent、下发配置。它本身不存数据数据都从 indexer 里取。安装的时候官方脚本wazuh-install.sh -a会在单台机器上一口气装好这三个服务。这种 All-in-One 方式对测试环境和几十台 agent 的小规模接入是足够的。再往上的生产规模一般会把 indexer、manager、dashboard 分开部署但排错思路是一模一样的所以本文的经验对分布式部署同样适用。1.2 组件间的认证关系很多坑的源头我后来回想自己踩的大部分坑本质上都是没搞清楚 Wazuh 各个组件之间靠什么建立信任。dashboard 访问 indexer 时要出示自己的 TLS 证书indexer 用 CA 证书验证。filebeat 作为 manager 和 indexer 之间的桥梁也要有一份证书。manager 给 agent 下发证书agent 注册后后续通信全靠这张证书。安装器会把一套自签 CA 以及各组件证书生成好打包在wazuh-install-files.tar.gz里。如果你在安装流程里改过主机名、手动换过证书、或者把证书拷贝到了错误目录后面会出现各种看似莫名其妙的 TLS 认证失败。所以拿到这个 tar.gz 之后第一个动作应该是存到安全的位置备份而不是马上删掉。它们的证书默认放在这些目录indexer/etc/wazuh-indexer/certs/dashboard/etc/wazuh-dashboard/certs/filebeat/etc/filebeat/certs/装完如果发现组件互相 ping 不通先别急着调防火墙先用openssl x509 -in /path/to/cert -noout -text看一下证书 CN 和 SAN 跟当前服务器的主机名、IP 是否匹配。我见过太多次因为 hostname 不一致导致的 TLS 失败最后重装才解决问题。2. 安装前没被强调但最容易翻车的硬性条件2.1 内存一半安装失败的根源官方文档说 All-in-One 最低 4GB 内存、2 核 CPU这个数字我只能说“能启动”不代表“能用”。我实际测试下来4GB 机器上三个服务一起跑内存经常在 85% 以上徘徊一旦系统要做点别的OOM 就来了。如果必须在低配机器上装至少要额外满足配置 swap哪怕 2GB 都行。修改/etc/wazuh-indexer/jvm.options把-Xms和-Xmx从默认值调低。默认堆内存往往会设成物理内存的一半4GB 机器上就是 2GB再叠加 Lucene 的 off-heap 内存非常吃力。避免在装 Wazuh 的同一台机器上再跑 MySQL、Elasticsearch 这类吃内存的服务。有条件的话8GB 内存才是 All-in-One 的舒适线。这个结论不一定够严谨但踩过坑的人应该都会有同感。2.2 磁盘和系统环境先照照镜子除了内存磁盘容量是被低估得更厉害的坑。Wazuh 装上之后agent 的日志会持续进入索引哪怕只有几台测试机器一天产生几百 MB 到几 GB 的索引数据都很正常。所以单机部署至少预留 40GB 磁盘想保留更多历史日志就要按索引增长情况再放大。安装前我还建议先做这几项检查操作系统版本是否在官方支持列表内。CentOS 7 不是不行但没必要拿老系统去挑战新版本 WazuhRocky Linux 9、Ubuntu 22.04/24.04 这类长期支持版本会省事很多。包管理器源是否正常。很多人机器上之前折腾过 python 安装、nodejs 安装、docker 安装可能改过源、换过镜像、装过奇怪的仓库。Wazuh 安装器会去官方源拉包如果你的源配置是坏的安装到一半会报依赖错误。时间同步是否开启。这点特别容易被忽略但 TSL 证书校验和 agent 注册都对时间敏感建议装之前确认chronyc tracking或ntpq -p正常。/etc/hosts里有没有正确写好本机 hostname 和 IP 的对应关系。Wazuh 安装器生成证书时会取当前主机名如果解析有问题后面访问 Dashboard 会各种不顺畅。2.3 SELinux、防火墙和内核参数如果你用的是 RHEL 系系统SELinux 是 Dashboard 起不来的头号嫌疑人。Wazuh 官方仓库里其实有 SELinux 策略包但在 All-in-One 快速部署场景下很多教程直接建议禁用。我的做法是测试环境直接setenforce 0并把配置改成 disabled生产环境再花时间写策略。防火墙端口方面我踩过不少次坑至少确认下面几个端口端口用途建议55000/TCPagent enrollment 注册对 agent 网段放行1514/TCPagent 到 manager 的主通信端口对 agent 网段放行443/TCPDashboard Web 访问对管理员网段放行9200/TCPindexer API默认不对生产环境开放仅在信任网络内使用还有一个内核参数很容易被忽略vm.max_map_count。OpenSearch 启动时会检查这个值默认的 65530 在 Wazuh 场景下远远不够必须调到至少 262144否则 indexer 会报max virtual memory areas vm.max_map_count [65530] is too low并拒绝启动。检查方法sysctl vm.max_map_count如果不够执行echo vm.max_map_count262144 /etc/sysctl.d/99-max_map_count.conf sysctl -p /etc/sysctl.d/99-max_map_count.conf这个参数我在后面一次完整排障里救过大命提前调好能省下一整轮查日志的功夫。3. 跑一遍官方安装器然后学会读安装日志3.1 一条命令装完的流程官方推荐的方式是用wazuh-install.sh而不是手动去装 Elasticsearch/OpenSearch 再单独配 filebeat。手动装当然能装好但坑只会更多不建议新手尝试。All-in-One 安装流程大致是这样curl -sO https://packages.wazuh.com/4.7/wazuh-install.sh sudo bash wazuh-install.sh -a脚本会自动完成仓库配置、包安装、证书生成、服务启动最后会在屏幕上打印 Dashboard 的访问地址和管理员密码。这个密码一定要存好忘了的话后期恢复比较麻烦。如果你只是想先看配置流程可以先跑这个sudo bash wazuh-install.sh --generate-config-files它会帮你在当前目录生成wazuh-install-files.tar.gz不实际装服务。这个文件很关键它是整个集群的证书和数据配置文件源。安装器还支持分布式部署参数比如--wazuh-indexer node-1、--wazuh-server wazuh-1、--wazuh-dashboard dashboard这类玩法。一旦拆成分散架构备份wazuh-install-files.tar.gz就更加重要因为加节点、重新签发证书都要用它。3.2 安装失败时先看它大部分安装失败都不会只报一句人话而是一大段脚本输出夹杂着ERR、ERROR、failed各种字样。别慌先按下面的顺序找日志。第一站是安装器日志新版本一般写在/var/log/wazuh-install.log旧版本可能在/tmp/下。里面有每一步的执行记录搜ERR就能定位到具体是哪个组件安装失败。第二站是具体组件的日志。比如 indexer 失败就看journalctl -u wazuh-indexer --no-pager -n 100Dashboard 失败就看journalctl -u wazuh-dashboard --no-pager -n 100第三站是 Wazuh Manager 的分析日志tail -f /var/ossec/logs/ossec.log我个人的习惯是先看 systemd 状态再看对应服务日志最后回到安装日志比对基本上不出三个来回就能定位到根因。3.3 安装过程常见错误一览下面的表格是我在群里帮人排查时见过的高频错误不一定每条都对应你的场景但思路是通用的。报错关键字常见原因排查方向Connection timed out/Cannot retrieve metalink系统源或外网不通下载依赖包失败检查 DNS、网络策略先确认能解析 packages.wazuh.comERR (ES_INDEXER)indexer 安装阶段失败去 journalctl 看具体错误多数是内存/内核参数/磁盘Could not resolve hostDNS 问题或离线环境配置内部仓库镜像或提前下载 RPM/DEB 包Failed to start wazuh-dashboardSELinux 拦截、端口占用、证书权限错误检查 SELinux AVC 日志、ss -tlnp、证书目录权限The Wazuh indexer installation failed安装器把 indexer 问题合并成一行去/var/log/wazuh-indexer/翻更细的日志还有一个非常容易遇到的问题以前机器上装过 OpenSearch、Elasticsearch、Kibana端口、配置文件、CA 证书全冲突了。安装前最好先检查一下 9200、443 这类端口是否已被占用有就关掉旧服务再装。我甚至见过有人在同一台机器上跑过两套 ELK结果 Wazuh 怎么装都起不来。4. 装完不等于能用三个爆炸点逐一拆解4.1 indexer 起不来这是最常见的灾难现场indexer 是三个组件里最“娇贵”的一个因为它基于 OpenSearch对环境要求最多。装完后很常见的现象是systemctl status wazuh-indexer显示 failed或者显示 running 但curl -k https://localhost:9200就是不通。先看状态systemctl status wazuh-indexer --no-pager -l再翻日志journalctl -u wazuh-indexer --no-pager -n 200如果日志里有memory locking requested说明系统限制进程锁内存如果有max virtual memory areas ... too low就去调vm.max_map_count如果有failed to obtain node locks多半是数据目录被占用或权限不对如果看到disk watermarks说明磁盘快满了OpenSearch 进入只读保护模式。我曾经在磁盘只剩 5% 的时候重新部署 Wazuhindexer 一直报blocked by: [FORBIDDEN/12/index read-only / allow delete (api)]数据索引根本写不进去Dashboard 上永远空空如也。后来清理了旧日志才把整条链路跑通。另外再说一个初学者最容易忽略的indexer 的 JVM 堆内存。修改/etc/wazuh-indexer/jvm.options后必须重启服务systemctl daemon-reload systemctl restart wazuh-indexer改完可以用这个命令验证本机 9200 是否正常响应curl -k -u admin:你的密码 https://localhost:9200如果返回带tagline或name的 JSON 信息就说明 indexer 活过来了。4.2 Dashboard 连不上 indexer浏览器直接红屏浏览器访问https://你的服务器IP时如果看到证书不受信任的警告这是正常的因为官方安装器用的是自签名证书。继续访问后如果出现“Unable to connect to Wazuh indexer server”之类的提示问题多半出在 dashboard 和 indexer 的连接上。第一步确认 dashboard 进程在监听ss -tlnp | grep 443第二步看/etc/wazuh-dashboard/opensearch_dashboards.yml确认opensearch.hosts指向的地址是否正确。默认应该类似opensearch.hosts: [https://localhost:9200]如果你改过主机名或让 dashboard 远程访问别处的 indexer这里必须改成 indexer 可达的地址同时证书路径要指向正确的证书目录。第三步确认 filebeat 也在正常工作。Dashboard 里即使能登录如果事件数据刷不出来有一部分原因是 filebeat 把数据从 manager 推到 indexer 这一步断了。systemctl status filebeatfilebeat 的证书在/etc/filebeat/certs/如果 indexer 重启过而 filebeat 没跟着重启偶尔会出现连接池里的老连接失效重启一下就能解决。4.3 agent 死活不连先查端口再查时间agent 装好了但在 Dashboard 里一直显示 disconnected这个问题我至少被问过十次。在 agent 那台机器上看 logstail -f /var/ossec/logs/ossec.log如果日志里反复出现连接被拒绝、超时基本就是防火墙挡住了 55000 或 1514 端口。先手动测一下端口通不通telnet manager-ip 55000 telnet manager-ip 1514如果端口通了再看时间是否一致。agent 和 manager 时间差太大会导致证书校验失败表现为连接能建立但立即断开。最常见的 agent 注册错误是没配好 Manager 地址。安装 agent 之后要么在安装命令里显式传入WAZUH_MANAGERmanager的IP要么改 agent 的/var/ossec/etc/ossec.conf把serveraddress改成 manager 地址然后重启 agentsystemctl restart wazuh-agent如果之前用过旧的 registration key还可以先删掉本机/var/ossec/etc/client.keys再重启 agent 让它重新注册。这种方式适合测试生产环境要慎重别把自己锁在外面。另外注意 agent 版本和 server 版本不要跨大版本太多。新 manager 配旧 agent有时能降级兼容但行为不可预测我一般要求生产环境大版本保持一致升级时先升 server再分批升 agent。5. 一次完整排障复盘日志、内核参数、磁盘挨个查5.1 现象和受到的迷惑有一次我在 Rocky Linux 9 上部署 Wazuh 4.4装完后 indexer 反复启动失败journal 里能看到spawn ... failed with exit code 1。第一次排查时我以为是端口冲突结果ss -tlnp检查发现 9200 根本没被监听端口上空空如也。又怀疑是磁盘满df -h一看剩余 30G也不是。这时候最容易产生“我是不是装错了”的错觉甚至想重装。5.2 一步步缩小范围我当时没有重装而是坚持看日志。把 journal 里所有 ERROR 行捞出来journalctl -u wazuh-indexer --no-pager | grep -i error看到了三条关键信息max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]memory locking requested for wazuh-indexer process but memory is not lockedfailed to obtain node locks第一条给出明确解决方案马上调大sysctl -w vm.max_map_count262144 echo vm.max_map_count262144 /etc/sysctl.d/99-max_map_count.conf第二条关于 memory locking需要在/etc/wazuh-indexer/opensearch.yml里把bootstrap.memory_lock改为false或者提高系统内存锁限制。测试环境我直接改为false省事生产环境按实际安全要求处理。调完这两个参数再重启 indexer终于能起来了。结果没高兴太久Dashboard 登录进去之后没有任何数据索引写不进去又回到了磁盘只读模式的问题。这次df -h再一看确实被 Wazuh 自己的日志文件占满了agent 上报日志疯狂增长把磁盘吃光了。5.3 修复后的验证清理完磁盘我又确认了索引的只读设置已经解除然后按顺序重启服务systemctl restart wazuh-indexer systemctl restart filebeat systemctl restart wazuh-manager systemctl restart wazuh-dashboard最后在管理端重新添加 agent看 agent 状态从pending变active再往 agent 机器上做一个简单的测试动作比如 touch 一个新文件Dashboard 里能立刻看到 FIM 事件才确定这次部署真正完成。这次排障给我的教训是安装器报错只是表象真正的问题都藏在组件自己的日志里。与其反复重装不如学会从日志里提取关键字再回到系统层面对照内存、磁盘、内核参数基本上 90% 的部署问题都能自己解决。6. 上生产前的几件小事6.1 改配置之后要用对控制命令Wazuh Manager 的配置改完之后很多人习惯直接 restart wazuh-manager这其实不是最优做法。官方管理脚本更适合做这类操作/var/ossec/bin/wazuh-control restart这个脚本会处理配置文件校验、目录权限、agent 通信连接等细节比直接 systemctl 更“懂” Wazuh。如果你改了/var/ossec/etc/ossec.conf建议先做语法检查/var/ossec/bin/wazuh-control status不同版本的检查方式略有差异但wazuh-control是核心管理命令无论哪个版本都值得先记住。配置文件的改动不是即时生效的。改完 ossec.conf 之后agent 侧可能要等下一次配置下发默认间隔可能在几十分钟到一小时如果想立刻生效可以在对应 agent 上重启 agent 服务。6.2 升级不能只能依赖包管理器Wazuh 升级不是随手yum update或者apt upgrade就完事。组件之间的版本依赖很强尤其是 indexer 和数据索引的兼容性直接升可能造成旧数据无法检索。官方提供了升级脚本和文档升级前至少做到这几件事备份wazuh-install-files.tar.gz证书丢了比升级失败更痛苦。检查新版本要求的系统依赖和 Java 版本。先看官方 upgrade 说明确定是否必须先升 server 再升 agent。在大版本升级时最好先在测试环境跑一遍再动生产。我倾向于把 Wazuh 当成一个有状态的数据库应用来对待而不是普通的 Web 服务。所有涉及索引格式变更的操作都要先备份再升级。6.3 日常维护最值得盯的日志和索引上了生产环境之后日常维护不是天天看 Dashboard 的告警红点而是定期看几个关键位置/var/ossec/logs/ossec.logmanager 核心日志agent 通信问题、分析引擎问题都在这里。/var/ossec/logs/alerts/alerts.json所有告警的原始 JSON排查误报、丢告警非常有用。/var/log/wazuh-indexer/wazuh-indexer-cluster.logindexer 集群状态、分片分配、磁盘水位线。/var/log/wazuh-dashboard/wazuh-dashboard.logdashboard 登录、用户权限、连接 indexer 的报错。另外装配好之后最好马上给索引加生命周期策略否则磁盘总有一天会被横向吃满。Wazuh 的索引名一般是wazuh-alerts-*、wazuh-archives-*OpenSearch 支持 ISMIndex State Management可以设置多少天后轮转、删除或关闭冷索引。这个比每天手动清理日志靠谱多了。个人经验是装完 Wazuh 后在 Dashboard 上盯着数据看十五分钟确认 FIM 事件、告警面板、agent 状态都正常再决定要不要批量部署 agent。节省下来的沟通成本和时间远比那十五分钟多得多。