服务日志采集组件

Flume、Logstash、Filebeat对比

总结：
Flume更注重于数据的传输，对于数据的预处理不如Logstash。在传输上Flume比Logstash更可靠一些，因为数据会持久化在channel中。数据只有存储在sink端中，才会从channel中删除，这个过程是通过事物来控制的，保证了数据的可靠性。Logstash是ELK组件中的一个，一般都是同ELK其它组件一起使用，更注重于数据的预处理，Logstash有比Flume丰富的插件可选，所以在扩展功能上比Flume全面。但Logstash内部没有persist queue，所以在异常情况下会出现数据丢失的问题。Filebeat是一个轻量型日志采集工具，因为Filebeat是Elastic Stack的一部分，因此能够于ELK组件无缝协作。Filebeat占用的内存要比Logstash小很多。性能比较稳健，很少出现宕机。

flume

source channel sink 多种组合

单source单channel多sink
sink1+sink2=channel
单source多channel多sink
每个sink 输出内容一致
多source单channel单sink
多个source 可以读取多种信息放在一个channel 然后输出到同一个地方

官方测试报告

官方测试报告

性能调优

性能调优

文档

User Guide
Developer Guide
flume到底会丢数据吗？其可靠性如何？——轻松搞懂Flume事务机制

配置

1. hadoop的jar
   D:\hadoop-2.9.2\share\hadoop\common\lib下所有jar包
   D:\hadoop-2.9.2\share\hadoop\common\hadoop-common-2.9.2.jar
   D:\hadoop-2.9.2\share\hadoop\hdfs\hadoop-hdfs-2.9.2.jar
   D:\hadoop-2.9.2\share\hadoop\tools\lib\hadoop-aws-2.9.2.jar
   D:\hadoop-2.9.2\share\hadoop\tools\lib\aws-java-sdk-bundle-1.11.199.jar
2. hadoop文件
   hadoop-2.9.2/etc/hadoop/core-site.xml 文件迁移到conf/目录下
3. 安装步骤
   1. 将lib.rar解压覆盖flume的lib目录
   2. agent文件
   3. log日志 log4j.properties 覆盖 flume的conf目录 备注(如果flume安装目录下没有 logs文件夹 则新建一个logs文件夹 因为flume运行日志要往里面落 flume.log.dir=./logs)
   4. 调节flume的内存参数为2G
      conf/flume-env.sh
      export JAVA_OPTS=“-Xms2000m -Xmx2000m -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=8888 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false”
   5. 启动命令
      nohup bin/flume-ng agent -n bzlog -c conf -f conf/bzlog.conf -DFlume.root.logger=INFO,LOGFILE -Dflume.monitoring.type=http -Dflume.monitoring.port=34545 >nohup 2>&1 &
   6. 告警

监控 参考文章

{
“SINK.k1”: {
“ConnectionCreatedCount”: “6”,// 创建连接数
“BatchCompleteCount”: “0”,// 完成的批数量
“EventWriteFail”: “0”,
“BatchEmptyCount”: “1087”,// 批量取空的数量 sink和source的速度对比指标
“EventDrainAttemptCount”: “2327843”,// 尝试提交的event数量
“StartTime”: “1629187270794”,
“BatchUnderflowCount”: “5”,// 正处于批量处理的batch数
“ChannelReadFail”: “0”,
“ConnectionFailedCount”: “0”,// 连接失败数
“ConnectionClosedCount”: “6”,// 关闭连接数量
“Type”: “SINK”,
“EventDrainSuccessCount”: “2327843”,// 成功发送event的数量
“StopTime”: “0”
},
“CHANNEL.c1”: {
“ChannelCapacity”: “500000”,// 通道容量
“ChannelFillPercentage”: “0.0”,// 通道使用比例
“Type”: “CHANNEL”,
“ChannelSize”: “0”,// 目前在channel中的event数量
“EventTakeSuccessCount”: “2327843”,// 从channel中成功取走的event数量
“EventTakeAttemptCount”: “2328936”,// 尝试从channel中取走event的次数
“StartTime”: “1629187270792”,
“EventPutAttemptCount”: “2327969”,// 尝试将event放入channel的次数
“EventPutSuccessCount”: “2327843”,// 成功放入channel的event数量
“StopTime”: “0”
},
“SOURCE.s4”: {
“KafkaEventGetTimer”: “20291542”,
“AppendBatchAcceptedCount”: “0”,// 追加到channel中的批数量
“EventAcceptedCount”: “581710”,// 成功放入channel的event数量
“AppendReceivedCount”: “0”,// source追加目前收到的数量
“StartTime”: “1629187271054”,// 组件开始时间
“AppendBatchReceivedCount”: “0”,// source端刚刚追加的批数量
“KafkaCommitTimer”: “2407”,
“EventReceivedCount”: “581732”,// source端成功收到的event数量
“Type”: “SOURCE”,
“KafkaEmptyCount”: “31820”,
“AppendAcceptedCount”: “0”,// 放入channel的event数量
# 打开的连接数
“OpenConnectionCount”: “0”, // 打开的连接数
“StopTime”: “0”// 组件停止时间
}
}

注意事项

1. capacity 和 transactionCapacity 注意调节好大小 transactionCapacity 需要小于 capacity 防止导致source过快sink过慢问题
2. byteCapacity 的调节充分利用内存
3. channel的capacity太大容易oom