持久队列 (PQ)

请参阅 处理背压，了解达到队列限制时的行为。

队列的适当大小取决于用例。作为一般指导原则，请考虑使用以下公式来确定持久队列的大小。

Bytes Received Per Second = Incoming Events Per Second * Raw Event Byte Size
Bytes Received Per Hour = Bytes Received per Second * 3600s
Required Queue Capacity = (Bytes Received Per Hour * Tolerated Hours of Downtime) * Multiplication Factor 

如果您使用持久队列来防止数据丢失，但不需要太多缓冲，则可以将 queue.max_bytes 设置为较小的值。较小的值可能会产生较小的队列并提高队列性能。

示例配置

queue.type: persisted
queue.max_bytes: 10mb

将 queue.checkpoint.writes 和 queue.checkpoint.acks 设置为 0 可以产生最大的性能，但可能会影响持久性。

在 Logstash 终止或出现硬件级故障的情况下，任何未经检查点的数据都会丢失。请参阅 控制持久性 以更好地了解权衡。

持久队列可以在您的 管道到管道 配置中发挥重要作用。

the `pqcheck` utility to identify which persistent queue--or queues--have been corrupted.

在 LOGSTASH_HOME 目录下运行：

bin/pqcheck <queue_directory>

其中 <queue_directory> 是持久化队列位置的完整路径。

pqcheck 实用程序 读取给定目录中的检查点文件，并输出有关这些文件当前状态的信息。该实用程序会为每个检查点文件输出以下信息：

正常页面文件的示例

此示例表示一个包含三个页面文件的正常队列。在此示例中，Logstash 当前正在写入 page.2（如 checkpoint.head 所引用）。Logstash 正在读取 page.0（如 checkpoint.0 所引用）。

ubuntu@bigger:/usr/share/logstash$ bin/pqcheck /var/lib/logstash/queue/main/
Using bundled JDK: /usr/share/logstash/jdk
OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release.
Checking queue dir: /var/lib/logstash/queue/main
checkpoint.1, fully-acked: NO, page.1 size: 67108864
  pageNum=1, firstUnackedPageNum=0, firstUnackedSeqNum=239675, minSeqNum=239675,
  elementCount=218241, isFullyAcked=no
checkpoint.head, fully-acked: NO, page.2 size: 67108864
  pageNum=2, firstUnackedPageNum=0, firstUnackedSeqNum=457916, minSeqNum=457916, elementCount=11805, isFullyAcked=no
checkpoint.0, fully-acked: NO, page.0 size: 67108864  
  pageNum=0, firstUnackedPageNum=0, firstUnackedSeqNum=176126, minSeqNum=1,
  elementCount=239674, isFullyAcked=no 

损坏页面文件的示例

如果 Logstash 无法启动和/或 pqcheck 显示异常，例如页面的 NOT_FOUND，请在队列目录上运行 pqrepair。

bin/pqcheck /var/lib/logstash/queue/main/
Using bundled JDK: /usr/share/logstash/jdk
OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release.
Checking queue dir: /var/lib/logstash/queue/main
checkpoint.head, fully-acked: NO, page.2 size: NOT FOUND 
  pageNum=2, firstUnackedPageNum=2, firstUnackedSeqNum=534041, minSeqNum=457916,
  elementCount=76127, isFullyAcked=no

pqrepair 实用程序 尝试删除损坏的队列段，以使队列恢复工作状态。它从启动它的目录开始搜索，并查找 data/queue/main。

在 LOGSTASH_HOME 目录下运行：

bin/pqrepair <queue_directory>

其中 <queue_directory> 是持久化队列位置的完整路径。

如果实用程序运行正常，则不会输出任何内容。

pqrepair 实用程序需要对该目录的写入权限。当 Logstash 作为服务运行时，文件夹权限可能会导致问题。在这种情况下，请使用 sudo。

/usr/share/logstash$ sudo -u logstash bin/pqrepair /var/lib/logstash/queue/main/

运行 pqrepair 后，重新启动 Logstash 以验证修复操作是否成功。

您可能会遇到需要清空队列的情况。例如：

要清空持久化队列：

当队列已满时，Logstash 会对输入施加反压以阻止数据流入 Logstash。此机制有助于 Logstash 控制输入阶段的数据流速率，而不会压垮 Elasticsearch 等输出。

使用 queue.max_bytes 设置来配置磁盘上队列的总容量。以下示例将队列的总容量设置为 8gb

queue.type: persisted
queue.max_bytes: 8gb

指定这些设置后，Logstash 会将事件缓冲到磁盘上，直到队列大小达到 8gb。当队列中充满了未确认的事件并且已达到大小限制时，Logstash 将不再接受新事件。

每个输入都独立处理反压。例如，当 beats 输入遇到反压时，它将不再接受新连接，并等待持久化队列有空间接受更多事件。在过滤器和输出阶段完成处理队列中现有事件并确认它们后，Logstash 会自动开始接受新事件。

持久性是存储写入的一个属性，它确保数据在写入后可用。

启用持久化队列功能后，Logstash 会将事件存储在磁盘上。Logstash 通过称为 *检查点* 的机制提交到磁盘。

队列本身是一组页面。页面有两种：头部页面和尾部页面。头部页面是写入新事件的地方。只有一个头部页面。当头部页面达到一定大小（参见 queue.page_capacity）时，它会变成尾部页面，并创建一个新的头部页面。尾部页面是不可变的，头部页面是仅追加的。其次，队列会将有关自身的信息（页面、确认等）记录到一个名为检查点文件的单独文件中。

记录检查点时，Logstash 会：

检查点过程是原子的，这意味着如果更新成功，则会保存对文件的任何更新。

您可以通过设置 queue.checkpoint.writes 来强制 Logstash 更频繁地进行检查点。此设置指定在强制进行检查点之前可以写入磁盘的事件的最大数量。默认为 1024。为了确保最大的持久性并避免持久化队列中的数据丢失，您可以设置 queue.checkpoint.writes: 1 以强制在写入每个事件后进行检查点。请记住，磁盘写入会消耗资源。将此值设置为 1 会严重影响性能。

在磁盘上，队列存储为一组页面，其中每个页面是一个文件。每个页面的大小最多为 queue.page_capacity。页面在该页面中的所有事件都已确认后被删除（垃圾回收）。如果较旧的页面至少有一个尚未确认的事件，则该页面将保留在磁盘上，直到该页面中的所有事件都成功处理。每个包含未处理事件的页面都将计入 queue.max_bytes 字节大小。