Wazuh集群架构中Agent数据同步机制的优化实践

背景与问题分析

在Wazuh安全监控平台的集群架构中，Agent节点与Master节点之间的数据同步是保证系统实时性和一致性的关键机制。当前实现中，Worker节点每10秒会向Master节点同步一次Agent信息，这一过程由Agent通过1514端口发送的健康检查(healthcheck)消息触发。

现有机制存在一个明显的性能瓶颈：当Agent的last_keep_alive时间戳更新时，系统会触发完整Agent数据记录的同步。这意味着即使只有这一个字段发生变化，Worker节点也会将Agent的所有元数据（包括操作系统信息、分组标签、配置内容等静态数据）传输到Master节点。在大型部署环境中，这种设计会导致：

1. 不必要的网络带宽消耗
2. 额外的CPU处理开销
3. 频繁的存储I/O操作
4. 整体集群性能下降

技术原理与优化方案

现有同步机制分析

当前系统使用sync_status字段作为同步触发器，该字段为字符串类型，但仅用作二元标志（同步请求/已同步）。当remoted组件检测到Agent信息变更时，会更新本地SQLite数据库(wazuh-db)并设置此字段。

优化设计思路

我们提出了一种细粒度的同步状态分类方案，充分利用现有的sync_status字段（无需修改数据库schema），将其扩展为多状态指示器：

1. 轻量级心跳同步 (syncreq_keepalive)：仅同步last_keepalive时间戳
2. 状态变更同步 (syncreq_status)：同步连接状态相关字段（包括connection_status、disconnection_time和status_code）
3. 全量数据同步 (syncreq)：在Agent启动或重新注册时同步完整元数据
4. 无需同步 (synced)：保持现有含义

这种设计的关键优势在于：

• 完全向后兼容
• 无需数据库迁移
• 保持现有接口不变
• 仅需修改remoted组件的业务逻辑

实现细节与状态机

状态转换逻辑

1. 初始状态：Agent注册后设为syncreq_status，同步基本连接信息
2. 首次心跳：升级为syncreq，触发全量同步确保Master拥有完整数据
3. 常规心跳：降级为syncreq_keepalive，仅传输时间戳
4. 异常断开：升级为syncreq_status，同步异常状态信息
5. 版本不匹配：特殊情况下设为syncreq_status

核心组件修改

remoted组件的主要修改点包括：

• 增强状态检测逻辑，准确识别变更类型
• 根据变更范围智能设置sync_status值
• 保持与wazuh-db的现有交互方式

集群守护进程(daemon)无需修改，因为它已经通过wazuh-db接口获取Agent数据，能够自然地处理不同同步级别的请求。

性能优化效果

通过实际测试，我们观察到以下改进：

1. 网络负载降低：常规心跳场景下传输数据量减少90%以上
2. 处理延迟下降：Master节点处理同步请求的时间缩短
3. 资源利用率优化：CPU和I/O负载显著降低

测试数据显示，对于一个包含10个Agent的环境，混合状态下的同步响应仅包含必要的字段，例如：

{
    "id": 1,
    "last_keepalive": 1745875894
}

而全量同步仅在必要时触发，包含完整的Agent元数据。

实施建议与注意事项

1. 升级兼容性：该优化完全兼容现有部署，无需特殊迁移步骤
2. 监控指标：建议新增同步类型统计指标，便于性能分析
3. 异常处理：保持对未知sync_status值的容错能力
4. 配置调优：可根据网络环境调整同步间隔等参数

总结

Wazuh集群架构中Agent数据同步机制的这项优化，通过引入细粒度的同步状态分类，显著提升了大规模部署下的系统性能。这种设计既保持了架构的简洁性，又解决了实际运行中的性能瓶颈，体现了"按需同步"的优化理念。该方案已在4.11版本中得到验证，可作为类似分布式系统数据同步优化的参考范例。