介绍Logstash的持久队列和背压

這是FJCT Advent Calendar第二天的文章。
第一天是@fuku2014使用NiFukura DNS來認證Let’s Encrypt的DNS-01方法並獲取免費的SSL證書並自動更新。
第三天是@riow分享了一個提前下班的誤解故事和預防再次發生的策略。

在这里，当我在OJT中使用elk堆栈（elasticsearch-logstash-kibana）开发日志基础设施时，因为关于logstash的文章并不多，所以我尝试描述了我认为有趣的部分。下面主要根据logstash文档描述了以下两个内容。

1. 介绍logstash的持久队列和背压机制

介绍可以在创建类似消息队列工具时参考的架构

介绍一下Logstash。

我們將介紹Logstash，請參考以下網頁。

在開源的伺服器端資料處理管線中，同時從大量的來源中取得資料，進行轉換，然後將其發送到指定的「存儲庫（Stash）」（在我們的情況下當然是Elasticsearch）。
https://www.elastic.co/jp/products/logstash

持久化队列。

据说Logstash的弱点是没有缓冲区。因此，当处理大量日志时，通常会将MQ工具（如kafka）与其结合使用作为缓冲区的角色。
因此，为了改进这一点，从5.x开始引入了持久队列功能。
话题回到Logstash的默认设置，确实日志缓冲区是在内存中，并且无法更改。在这种情况下，数据流程如下，且由于进程消失可能导致日志丢失的可能性很高。

输入 -> 管道 -> 工人

持久队列（永久队列）功能是可修改的磁盘缓冲区。此外，在进程结束和重新启动时，可以从中间位置开始处理，以防止日志丢失。数据流程如下：

输入 → 队列 → 过滤 + 输出

设置方式

我认为您可以参考一下这篇文章，它介绍了设置方法以及内存和磁盘之间的比较。文章链接如下：
https://dev.classmethod.jp/server-side/elasticsearch/logstash-queue-persisted/

机制 (jī zhì)

数据管理构成

持久队列在页面级别上进行数据管理。每个页面具有由queue.page_capacity设置的字节容量，相当于一个文件。页面分为头页面和尾页面两种类型。头页面用于写入数据，只能进行扩展操作。头页面的大小达到最大限制后，会变为尾页面，并创建一个新的头页面。尾页面的数据将传递给日志的过滤和输出阶段，并在所有处理正常完成后从输出模块中收到ACK后被删除。
页面由多个称为事件的逻辑单位组成。可以使用queue.max_events指定一个页面的事件数量。Logstash以事件为单位进行处理。例如，页面的删除（垃圾回收）仅在所有相关事件收到ACK的情况下进行。此外，如果Logstash进程异常停止并重新启动，则会按顺序处理所有未收到ACK的事件，而不会丢失数据。

背压 yā)

当logstash的队列达到queue.max_bytes设置的最大大小时，会向数据的接收方（如beats）发出请求，要求暂停发送数据，这被称为back pressure。通过这样做，不仅可以限制logstash进程本身的负载在一定范围内，还可以避免对elasticsearch施加过大的负载。顺便提一下，“队列已满”表示队列中存在未收到ACK的事件。如果back pressure经常发生，则表示logstash无法处理系统中的数据量，因此需要增加队列大小或提升服务器性能。

管理写作

当输入一旦停止并重新启动时，我们如何知道从哪里开始？Logstash会生成checkpoint文件以监视其自身的数据写入状态，并管理写入目标head page的状态。具体而言，它会将head page的fsync状态从内存保存到磁盘上。每次写入表示为一个事件（event）。您可以通过指定queue.checkpoint.writes参数来决定内存上的多少次写入需要写入磁盘。指定为1可以最大程度地保证数据完整性，但可能会对性能产生影响。相反，提高此值可以提高Logstash的处理速度。如需更详细的信息，请参考checkpoint的源代码。

最后

我认为logstash中的Persistent queues功能可以作为创建类似消息队列工具的参考架构。当然，我也认为将其保存在磁盘上可能会对性能产生负面影响，但从我在这篇文章中验证的结果来看，

在处理10万个记录时，in-disk相对于in-memory仅有17秒左右的差距，并不算太大。对于某些系统而言，这可能是无法容忍的。

明天我们将讲述@riow先生误解并提前下班的故事以及避免再次发生的措施。可以期待到非常有趣的内容！