Wazuh检测模块磁盘空间异常增长问题分析与解决方案

问题现象

在Wazuh 4.11版本环境中，管理员发现/var/ossec/queue/indexer/wazuh-states-vulnerabilities-wazuh目录占用了大量磁盘空间，达到98GB。该问题在多台工作节点上均有出现，且随着时间推移持续增长。尽管数据能够正常索引并在仪表板中显示，但SST文件未被自动清理，导致磁盘空间持续消耗。

技术背景

Wazuh的检测模块(Vulnerability Detector)负责扫描系统软件包并检测已知问题。该模块使用RocksDB作为本地存储引擎，将检测结果暂存在/var/ossec/queue/indexer/目录下，然后通过索引器连接器模块(Indexer Connector)将数据发送到Wazuh索引器。

问题分析

通过深入分析日志和系统行为，发现以下关键点：

1. 索引器连接问题：日志中出现"Unable to initialize IndexerConnector for index 'wazuh-states-vulnerabilities-wazuh': No available server"错误，表明与索引器的连接存在间歇性问题。

2. RocksDB通信超时：通过strace追踪发现，在TLS握手成功后，RocksDB内部管道(fd=32)出现ETIMEDOUT超时错误，导致数据处理流程中断。

3. 配置影响：将检测的feed更新间隔从60分钟调整为12小时后，磁盘使用量显著下降，这表明频繁的feed更新会加剧问题。

4. 凭证配置不完整：在15个工作节点中，有5个节点的索引器凭证未通过wazuh-keystore正确配置。

根本原因

综合来看，问题主要由以下因素共同导致：

1. 连接不稳定：与索引器的连接不稳定导致数据积压
2. RocksDB异常：RocksDB内部状态异常导致文件无法自动清理
3. 配置问题：部分节点缺少必要的索引器凭证配置
4. 资源竞争：高频率的feed更新在连接不稳定时加剧了数据积压

解决方案

临时解决方案

对于已出现问题的环境，可执行以下操作释放磁盘空间：

systemctl stop wazuh-manager
rm -rf /var/ossec/queue/db/*
systemctl start wazuh-manager

注意：此操作会清除所有临时数据库，仅建议在紧急情况下使用。

长期解决方案

1. 验证索引器连接：

   • 检查所有节点的索引器配置
   • 确保wazuh-keystore中包含正确的索引器凭证
   • 验证索引器集群状态为green

2. 调整feed更新频率： 在ossec.conf中适当延长检测feed的更新间隔：

   <vulnerability-detector>
     <feed-update-interval>12h</feed-update-interval>
   </vulnerability-detector>
   

3. 监控与告警：

   • 设置对/var/ossec/queue/indexer/目录大小的监控
   • 配置日志告警规则，捕获索引器连接错误

4. 性能优化：

   • 确保工作节点有足够资源处理检测任务
   • 在大型环境中考虑增加索引器节点数量

最佳实践建议

1. 定期检查/var/ossec/queue/indexer/目录大小
2. 在生产环境中实施完整的监控方案
3. 在升级或配置变更后验证所有节点的配置一致性
4. 对于大型部署，考虑使用专用节点处理检测任务

总结

Wazuh检测模块的磁盘空间异常增长问题通常由连接问题和内部状态异常共同导致。通过合理的配置调整和系统监控，可以有效预防和解决此类问题。管理员应当特别关注索引器连接稳定性和资源使用情况，确保系统长期稳定运行。