集中式日志分析平台 - ELK Stack - 关于 Logstash 的持久化队列

概括下本文的内容:

我们可以使用 Logstash 的持久化队列技术尽量保证数据可靠传输至 output;

适用场景:传输可靠性要求稍低的场景下(和 Kafka 类比),替换架构中的 Kafka 或者加固 Logstash 本身的可靠性,因为即使 queue.checkpoint.writes:1,也有可能因为磁盘故障(检查点文件 和 queue 文件同时损坏)丢至多 1 条数据,核心的问题是在于没有多副本和选举相关的实现;

Deliver 策略:at-least-once;

默认情况下,Logstash在 pipeline stages(inputs → pipeline workers)之间使用内存有界队列来缓冲事件。 这些内存中队列的大小是固定的,不可配置。 如果 Logstash 遇到临时机器故障,则内存中队列的内容将丢失。 临时机器故障是指 Logstash 或其主机异常终止但能够重新启动的情况。

为了防止异常终止期间的数据丢失,Logstash 具有持久性队列功能,将消息队列存储在磁盘上。 持久队列在 Logstash 中提供数据的持久性。

持久队列对于需要大型缓冲区的 Logstash 部署也很有用。 换言之,可以启用持久性队列来缓存磁盘上的事件而无需使用较重的组件(如 Redis,RabbitMQ 或 Apache Kafka)来实现缓冲的发布订户模型。

总而言之,启用持久队列的好处如下:

  • 处理突发事件,而不需要像 Redis 或 Apache Kafka 这样的外部缓冲机制;
  • 在正常关机期间以及 Logstash 异常终止时,提供 at-least-once 传输保证,防止消息丢失。 如果 Logstash 在事件传递时(我理解是事务执行过程中,in-flight)重新启动,Logstash 将尝试传递存储在持久性队列中的消息,直到传送成功至少一次。

持久队列的限制

以下是持久队列功能未解决的问题:

  • 不使用 request-response 协议的 input 插件无法避免数据丢失。 例如:tcp,udp,zeromq push + pull和许多其他输入没有机制来确认 receipt 的发送方。 具有确认功能的插件(如 beats 和 http)受到此队列的良好保护。
  • 它不会处理永久性的机器故障,如磁盘损坏,磁盘故障和机器丢失,持续到磁盘的数据不会被复制。

持久队列如何工作

队列位于同一进程的 input 和 filter 阶段之间:

input → queue → filter + output

当 input 有事件准备好处理时,它将事件写入队列。当写入队列成功时, input 可以向其数据源发送 ack。

Logstash 只会在 filter 和 output 完成事件处理后,确认事件已完成。队列保留 pipeline 已处理的事件的记录。事件被记录为已处理(acked),当且仅当事件已由 Logstash pipeline 完全处理。

Ack 这意味着事件已由所有配置的 filter 和 output 处理。例如,如果只有一个到 Elasticsearch的输出,当 Elasticsearch output 已成功将此事件发送到 Elasticsearch 时,事件将被 ack。

在正常关机(Kill 或 SIGTERM)期间,Logstash 将停止从队列中读取,并完成由 filter 和 output 处理的 in-flight 事件。重新启动后,Logstash 将恢复处理持久性队列中的事件以及从 input 接受新事件。

如果 Logstash 异常终止,任何 in-flight 事件将不会被 ack,并且当 Logstash 重新启动时将被 filter 和 output 重新处理。 Logstash 分批处理事件,因此对于任何给定的批处理,有可能已经成功完成了该批次,但是在发生异常终止时不能被记录为已确认,所以可以解释为什么会有重复发送。

如何配置持久化队列

要配置持久性队列,可以在Logstash设置文件中指定以下选项:

queue.type:指定持久化以启用持久性队列。默认情况下,持久队列被禁用(默认:queue.type:memory)。
path.queue:数据文件将被存储的目录路径。默认情况下,文件存储在path.data/queue中。
queue.page_capacity:队列页面的最大大小(以字节为单位)。队列数据由仅附加文件称为“页面”组成。默认大小为250MB。更改此值不太可能具有性能优势。
queue.max_events:队列中允许的最大事件数。默认值为0(无限制)。该值在内部用于Logstash测试。
queue.max_bytes:队列的总容量,以字节为单位。默认值为1024MB(1GB)。确保磁盘驱动器的容量大于此处指定的值。
如果同时指定了queue.max_eventsqueue.max_bytes,则Logstash将使用首先达到的条件。。

还可以指定控制检查点文件何时更新的选项(queue.checkpoint.acksqueue.checkpoint.writes)。

示例配置:

queue.type:persisted
queue.max_bytes:4gb

处理 Back Pressure

当队列已满时,Logstash 会对 input 端施加压力,以阻止流入 Logstash 的数据。这种机制有助于 Logstash 在 input 阶段控制数据流量,而不会向比如 Elasticsearch 类似的 output 端疯狂输出。

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

queue.type:persisted
queue.max_bytes:8gb

指定这些设置后,Logstash 将缓存磁盘上的事件,直到队列的大小达到8gb。当队列充满 unACKed 的事件,并且已达到大小限制时,Logstash 将不再接受新的事件。

每个 input 单独处理 Back Pressure。例如,当 beats input 遇到 back pressure 时,它不再接受新连接并等待,直到队列有空间来接受更多的事件。filter 和 output 阶段完成处理队列中的现有事件并确认它们后,Logstash 会自动开始接受新的事件。

控制 Durability

Durability 是存储写入的一种特性,可确保数据在写入后可用。

当启用持久性队列功能时,Logstash 会将事件存储在磁盘上。 Logstash以称为检查点的机制提交到磁盘。

为了讨论 Durability,我们需要介绍一些关于如何实现持久队列的细节。

首先,队列本身是一组 pages。有两种 page:head page 和 tail page。head page 是新事件写入的地方,只有一个。当 head page 达到上限(参见queue.page_capacity)时,它将成为一个 tail page,并创建一个新的 page。tail page 是不修改的,head page 是只能追加内容的。其次,队列将记录自己的详细信息(pages,ack 确认信息等)记录在一个名为checkpoint 文件的单独文件中。

记录检查点时,Logstash将:

  • 在 head page 上调用 fsync。
  • 原子地写入队列的当前状态至磁盘。

以下设置可用于调整持久性:

  • queue.checkpoint.writes:Logstash 在写入指定条数事件后,进行 checkpoint。目前,一个事件计为一个写入,但这可能会在将来的版本中更改。
  • queue.checkpoint.acks:Logstash 在指定条数事件 acked 后,进行 checkpoint。此配置用来控制 Logstash 处理(filter + output)环节的 Durability。

磁盘写入具有资源成本。调整上述值或更高值将会调整 durability。例如,如果您想要所有 input 事件具备最高 durability,可以设置queue.checkpoint.writes:1

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

如果 Logstash 终止,或者如果存在硬件级别故障,那么在持久性队列中缓存但尚未检查点的任何数据都将丢失。为了避免这种可能性,您可以设置 queue.checkpoint.writes:1,但请记住,此设置会严重影响性能。

磁盘垃圾回收

在磁盘上,队列存储为一组 page,其中每个 page 是一个文件。 每个 page 最多可以是 queue.page_capacity的大小。 在该 page 中的所有事件都被确认之后,page 被删除(垃圾回收)。 如果较旧的 page 至少有一个尚未确认的事件,则整个 page 将保留在磁盘上,直到该 page 中的所有事件成功处理。 包含未处理事件的每个 page 将对queue.max_bytes字节大小进行计数。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 212,686评论 6 492
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,668评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 158,160评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,736评论 1 284
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,847评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,043评论 1 291
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,129评论 3 410
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,872评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,318评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,645评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,777评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,470评论 4 333
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,126评论 3 317
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,861评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,095评论 1 267
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,589评论 2 362
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,687评论 2 351

推荐阅读更多精彩内容