Logstash宕机时Auditbeat的处理机制及数据安全技术问询

针对你提到的Auditbeat → Logstash → Elasticsearch数据管道，当Logstash服务器宕机时，Auditbeat的处理逻辑可以从以下几个核心问题展开：

1. 是否具备重试机制？ #

是的，Auditbeat默认自带重试机制。当Logstash不可达（比如宕机、网络故障）时，Auditbeat会自动尝试重新发送未成功交付的事件。它采用指数退避策略控制重试间隔：初始重试间隔为1秒，之后每次重试间隔翻倍，直到达到最大间隔（默认60秒），避免短时间内大量重试对网络或恢复后的Logstash造成压力。

2. 重试时长为多久？ #

重试时长取决于你对output.logstash的配置：

• 默认情况下，max_retries参数设置为3，意味着Auditbeat会尝试最多3次重试，若3次都失败，默认会丢弃事件（但开启持久化队列后不会丢弃）。
• 如果你将max_retries设为-1，Auditbeat会无限重试，直到Logstash恢复可用，不会主动放弃事件。
• 重试的间隔范围是从1秒到60秒（可通过backoff.init和backoff.max参数自定义调整）。

3. 审计日志是否会丢失？ #

这取决于是否开启了持久化队列（Persistent Queue）：

• 若未开启持久化队列：Auditbeat仅将未发送事件存在内存队列中，如果Auditbeat本身意外重启，内存中的事件会丢失；但只要Auditbeat保持运行，即使Logstash宕机，内存队列会暂存事件，直到重试成功或达到重试上限（默认3次后丢弃）。
• 若开启了持久化队列：Auditbeat会将未发送的事件写入本地磁盘的队列文件中，即使Auditbeat重启或Logstash长时间宕机，事件也会被安全存储，直到成功发送到Logstash，不会丢失。

由于你已经禁用了auditd服务，Auditbeat是直接捕获审计事件的唯一入口，强烈建议开启持久化队列来保障数据安全。

暂存数据的存储位置及磁盘空间配置 #

• 存储位置：持久化队列的默认存储路径为${path.data}/queue，其中path.data在Linux系统下默认是/var/lib/auditbeat。你可以通过修改queue.disk.path参数自定义存储路径。
• 磁盘空间分配：默认情况下，持久化队列是关闭的，需要手动配置开启。开启后，默认的最大磁盘占用为1GB（由queue.disk.max_size参数控制），你可以根据实际需求调整这个值（比如设置为10GB），确保有足够空间暂存Logstash宕机期间的审计事件。

关键配置示例（开启持久化队列） #

在auditbeat.yml中添加或修改以下配置：

queue:
  disk:
    enabled: true
    max_size: 10GB  # 根据你的磁盘容量调整
    path: /var/lib/auditbeat/queue  # 可自定义路径

内容的提问来源于stack exchange，提问作者Voodoo