ELK消息队列Kafka
环境信息
| 组件 | 地址 | 安装路径 | 配置文件 | 启动方式 |
| logstash | 10.1.0.149 | /etc/logstash/ | /etc/logstash/logstash.yml | systemctl (logstash.service) |
| kafka | 10.1.0.152 | /usr/local/kafka/ | /usr/local/kafka/config/ | /usr/local/kafka/bin/*.sh |
| filebeat | 生产服务器 | /etc/filebeat/ | /etc/filebeat/filebeat.yml | systemctl (filebeat.serivce) |
| elasitcsearch | 阿里云ES | none | none | none |
filebeat
filebeat是一个轻量级的日志收集工具
首先filebeat是Beats中的一员。
Beats在是一个轻量级日志采集器，其实Beats家族有6个成员，早期的ELK架构中使用Logstash收集、解析日志，但是Logstash对内存、cpu、io等资源消耗比较高。相比Logstash，Beats所占系统的CPU和内存几乎可以忽略不计
目前Beats包含六种工具：
- Packetbeat：网络数据（收集网络流量数据）
- Metricbeat：指标（收集系统、进程和文件系统级别的CPU和内存使用情况等数据）
- Filebeat：日志文件（收集文件数据）
- Winlogbeat：windows事件日志（收集Windows事件日志数据）
- Auditbeat：审计数据（收集审计日志）
- Heartbeat：运行时间监控（收集系统运行时的数据）
filebeat收集逻辑过程：当您启动Filebeat时，它将启动一个或多个input，input的指向是需要收集的日志位置。收集每一个日志文件，FileBeat都会启动一个Harverster。每个Harvester将读取日志的新内容并发送至Spooler进行日志处理分段及聚合给filebeat的output中的数据收集器
filebeat原理
Filebeat涉及两个组件：查找器prospector和采集器harvester，来读取文件(tail file)并将事件数据发送到指定的输出。
启动Filebeat时，它会启动一个或多个查找器，查看你为日志文件指定的本地路径。对于prospector所在的每个日志文件，prospector启动harvester。每个harvester都会为新内容读取单个日志文件，并将新日志数据发送到libbeat，后者将聚合事件并将聚合数据发送到你为Filebeat配置的输出。
当发送数据到Logstash或Elasticsearch时，Filebeat使用一个反压力敏感(backpressure-sensitive)的协议来解释高负荷的数据量。当Logstash数据处理繁忙时，Filebeat放慢它的读取速度。一旦压力解除，Filebeat将恢复到原来的速度，继续传输数据。
组件说明：
Crawler：负责管理和启动各个 Input
Input：负责管理和解析输入源的信息，以及为每个文件启动 Harvester。可由配置文件指定输入源信息。
Harvester: Harvester 负责读取一个文件的信息。
Pipeline: 负责管理缓存、Harvester 的信息写入以及 Output 的消费等，是 Filebeat 最核心的组件。
Output: 输出源，可由配置文件指定输出源信息。
Registrar：管理记录每个文件处理状态，包括偏移量、文件名等信息。当 Filebeat 启动时，会从 Registrar 恢复文件处理状态。
- 采集器Harvester
Harvester负责读取单个文件的内容。读取每个文件，并将内容发送到the output，每个文件启动一个harvester, harvester负责打开和关闭文件，这意味着在运行时文件描述符保持打开状态。
如果文件在读取时被删除或重命名，Filebeat将继续读取文件。这有副作用，即在harvester关闭之前，磁盘上的空间被保留。默认情况下，Filebeat将文件保持打开状态，直到达到close_inactive状态
关闭harvester会产生以下结果：
1）如果在harvester仍在读取文件时文件被删除，则关闭文件句柄，释放底层资源。
2）文件的采集只会在scan_frequency过后重新开始。
3）如果在harvester关闭的情况下移动或移除文件，则不会继续处理文件。
要控制收割机何时关闭，请使用close_ *配置选项
- 查找器Prospector
Prospector负责管理harvester并找到所有要读取的文件来源。如果输入类型为日志，则查找器将查找路径匹配的所有文件，并为每个文件启动一个harvester。每个prospector都在自己的Go协程中运行。
Filebeat目前支持两种prospector类型：log和stdin。每个prospector类型可以定义多次。日志prospector检查每个文件来查看harvester是否需要启动，是否已经运行，或者该文件是否可以被忽略（请参阅ignore_older）。
只有在harvester关闭后文件的大小发生了变化，才会读取到新行。
文件状态保存原理
Filebeat 保存每个文件的状态并经常将状态刷新到磁盘上的注册文件中。该状态用于记住harvester正在读取的最后偏移量，并确保发送所有日志行。如果输出到logstash或kafka无法访问时，Filebeat会跟踪最后发送的行，并在输出再次可用时继续读取文件。
在Filebeat运行时，每个prospector内存中也会保存文件状态信息，当重新启动Filebeat时，将使用注册文件的数据来重建文件状态，Filebeat将每个harvester在从保存的最后偏移量继续读取。每个prospector为它找到的每个文件保留一个状态。由于文件可以被重命名或移动，因此文件名和路径不足以识别文件。对于每个文件，Filebeat存储唯一标识符以检测文件是否先前已被采集过
数据消费不丢失原理
Filebeat将每个事件的传递状态存储在注册文件中，所以保证事件至少会被传送到配置的输出一次，并且不会丢失数据。
当输出阻塞或未确认所有事件的情况下，Filebeat将继续尝试发送事件，直到接收端确认已收到。如果Filebeat在发送事件的过程中关闭，它不会等待输出确认所有收到事件。但在Filebeat关闭前未确认的任何事件在重新启动Filebeat时会再次发送。这可以确保每个事件至少发送一次，但最终会将重复事件发送到输出。
也可以通过设置shutdown_timeout选项来配置Filebeat以在关闭之前等待特定时间。
注意：Filebeat的至少一次交付保证包括日志轮换和删除旧文件的限制。如果将日志文件写入磁盘并且写入速度超过Filebeat可以处理的速度，或者在输出不可用时删除了文件，则可能会丢失数据。
filebeat --- logstash
filebeat和logstash的关系
因为logstash是jvm跑的，资源消耗比较大，所以后来作者又用golang写了一个功能较少但是资源消耗也小的轻量级的logstash-forwarder，就是filebeat。
原有方案部署方案如下：filebeat将收集好的日志直接输送到logstash&elsticserach时，filebeat使用BACK-PRESSURE SENSITIVE协议控制日志采集传输速度，如果logstash在处理数据时造成数据流通道堵塞，而发送相应消息至filebeat并告知flebeat放慢采集速度等到堵塞窗口恢复，则filebeat恢复到之前数据传输速度，进行收集日志，但是在生产环境中，如果日志量非常大的情况会导致日志窗口持续积压，导致牺牲生产应用环境的性能
Kafka
kafka解决方案，可以在日志窗口负载的情况下对日志进行队列处理，以缓解生产环境性能消耗情况
参考文献
https://blog.csdn.net/qq_29595629/article/details/114287632
