Loki Stack收集MongoDB日志最佳实践(下)
前戏 小白: 前文我们提到了 Fluent Bit 采集器, 我对它的一些配置信息很感兴趣, 它是如何高效采集的? 老花：Fluent Bit 作为一个轻量级的日志收集器，特别适合在 Kubernetes 环境中作为 DaemonSet 运行。它的核心配置涉及服务(services), 解析器(parsers),输入配置(inputs), 输出配置(outputs)等。总结来说, 一套日志流可以定义多个插件, 通过tag和match来流转。 Fluent Bit 核心配置解析 Fluent Bit 架构图 在这个时序图中： Inputs：输入插件收集来自不同输入源的日志记录。 Parsers：解析器插件解析输入的日志记录。 Filters：过滤器插件对日志记录进行特定的修改，如添加或删除键值对，丰富特定元数据，或基于特定条件丢弃记录。 Storage：处理后的数据被认为是安全状态（要么在内存中，要么在文件系统中），然后记录通过适当的输出目的地进行路由。 StreamProcessor：流处理器是一个独立的子系统，它检查存储接口上的新记录。通过配置，流处理器可以附加到来自特定输入插件的记录，或通过应用标签和匹配规则。 Outputs：输出插件将处理后的数据发送到配置的输出目的地。 多线程 Fluent Bit会自动管理输入和输出插件的线程，确保在多线程环境中高效运行。过滤器始终在主线程中运行，而处理器则在各自的输入或输出的独立线程中运行。 内存管理 在容器化环境中，估算Fluent Bit的内存使用量至关重要。可以通过设置Mem_Buf_Limit选项来限制输入插件的内存使用。例如，如果设置Mem_Buf_Limit为 10MB，输出插件在最坏情况下可能会使用20MB，因此总内存需求应为30MB（10MB + 20MB），再加上一定的安全余量。 增量采集 Fluent Bit 通过检查日志文件的偏移量来实现增量采集。它会记录每个文件的最后读取位置，并在下一次采集时从该位置开始，确保不会重复采集。 缓冲与存储 Fluent Bit 通过缓冲机制临时存储处理后的数据，直到数据准备好被发送。 Fluent Bit 使用内存作为主要的临时存储位置，但在某些场景下，使用基于文件系统的持久缓冲机制可以提供聚合和数据安全能力。 输入插件发出的记录被引擎组合在一起形成块，通常大小约为 2MB，默认仅在内存中创建。 如果仅设置内存作为缓冲，它将尽可能多地在内存中存储数据。这是最快的机制，但如果服务因网络慢或远程服务无响应而无法快速分发记录，Fluent Bit 的内存使用量将增加。 背压问题 当日志或数据的产生速度, 超过其被刷新到某些目的地的能力时，会产生背压，导致服务内存消耗增加。Fluent Bit通过Mem_Buf_Limit和storage.Max_Chunks_Up配置参数限制输入插件可以摄入的数据量。 核心配置项 buf_chunk_size: 缓冲区块大小，用于存储日志数据。 buf_max_size: 缓冲区最大大小。 batch_size: 每个批次发送的日志条目数。 batch_wait: 等待更多日志条目到达以填满批次的时间。 mem_buf_limit: 内存缓冲区限制。 mem_buf_flush_count: 触发缓冲区刷新的日志条目数。 这些配置影响内存的使用, 是否产生背压, 以及写入后端outputs的效率(攒批)。 ...