做了几天测试,总结一下,顺便结贴。
1.没有原则要求使用filebeat或logstash,两者作为shipper的功能是一样的,区别在于:
a.logstash由于集成了众多插件,如grok,ruby,所以相比beat是重量级的;
b.logstash启动后占用资源更多,如果硬件资源足够则无需考虑二者差异;
c.logstash基于JVM,支持跨平台;而beat使用golang编写,AIX不支持;
d.AIX 64bit平台上需要安装jdk(jre) 1.7 32bit,64bit的不支持;
e.filebeat可以直接输入到ES,但是系统中存在logstash直接输入到ES的情况,这将造成不同的索引类型造成检索复杂
2.logstash的相关配置:
a.logstash的Default pipeline workers取决于当前cpu数量;
b.filter设置multiline后,pipline worker会自动将为1,如果使用filebeat,建议在beat中就使用multiline,如果使用logstash作为shipper,建议在input中设置multiline;
c.关于multiline,logstash的配置与filebeat的配置类似,pattern,negate是一样的,而logstash的what与filebeat的match理解起来有点费劲:previous=after,next=before( # Note: After is the equivalent to previous and before is the equivalent to to next in Logstash);
3.引入Redis 的相关问题:
a.filebeat可以直接输入到logstash(indexer),但logstash没有存储功能,如果需要重启需要先停所有连入的beat,再停logstash,造成运维麻烦;另外如果logstash发生异常则会丢失数据;引入Redis作为数据缓冲池,当logstash异常停止后可以从Redis的客户端看到数据缓存在Redis中;
b.Redis可以使用list(最长支持4,294,967,295条)或发布订阅存储模式,但是beat v1.3只支持list;
c.Redis的protected-mode需要设置为no,bind不能设置为本机:#bind 127.0.0.1;
4.ES节点配置:
a.ES是分布式存储,当设置同样的cluster.name后会自动发现并加入集群;
b.集群会自动选举一个master,当master宕机后重新选举;
c.为防止“脑裂”,可以设置discovery.zen.minimum_master_nodes: 2 减少这种概率;
d.为有效管理节点,可关闭广播 discovery.zen.ping.multicast.enabled: false,并设置单播节点组discovery.zen.ping.unicast.hosts: ["ip1", "ip2", "ip3"]
5.kibana的使用问题:
a.初次登录会设置一个默认索引,在Discover下面可以输入不同的查询条件,并保存为不同的Search;
b.在Visualize下,根据不同的Search建立各种类型的图表(柱状图、饼图、折线图);
c.在Dashboard下,使用建立的可视化图表构建看板。可以保存多个;
d.最顶端可以选择时间,有三种模式:Quick(设置一天、一周或1小时...),Relative(设置一天、一周或n小时到当前),Absolute(选择特定时间范围);
关于性能(假设每条日志250Byte):
logstash-Linux:1cpu 4GRAM
每秒500条日志
去掉ruby每秒660条日志
去掉grok后每秒1000条数据
filebeat-Linux:1cpu 4GRAM
每秒2500-3500条数据
每天每台机器可处理:24h*60min*60sec*3000*250Byte=64,800,000,000Bytes,约64G
瓶颈在logstash从redis中取数据存入ES,开启一个logstash,每秒约处理6000条数据;开启两个logstash,每秒约处理10000条数据(cpu已基本跑满);
logstash-Aix:1cpu 2GRAM
每秒750条数据
每天每台机器可处理:24h*60min*60sec*750*250Byte=16,200,000,000Bytes,约16G
去掉ruby每秒950条数据
去掉grok每秒1350条数据
logstash的启动过程占用大量系统资源,因为脚本中要检查java、ruby以及其他环境变量,启动后资源占用会恢复到正常状态。
性能的提升:
注:下面的简单翻译自ELK官网文档,若有语法问题或表达不当请参考原文:https://www.elastic.co/guide/en/logstash/2.4/performance-troubleshooting.html
1.检查输入和输出的性能
Logstash和其连接的服务运行速度一致,它可以和输入、输出的速度一样快。
2.检查系统参数:
?CPU
?注意CPU是否过载。在Linux/Unix系统中可以使用top -H查看进程参数以及总计。
?如果CPU使用过高,直接跳到检查JVM堆的章节并检查Logstash worker设置。
?Memory
?注意Logstash是运行在Java虚拟机中的,所以它只会用到你分配给它的最大内存。
?检查其他应用使用大量内存的情况,这将造成Logstash使用硬盘swap,这种情况会在应用占用内存超出物理内存范围时。
?I/O
?监控磁盘I/O检查磁盘饱和度
?使用Logstash plugin(例如使用文件输出)磁盘会发生饱和。
?当发生大量错误,Logstash生成大量错误日志时磁盘也会发生饱和。
?在Linux中,可使用iostat,dstat或者其他命令监控磁盘I/O
?监控网络I/O
?当使用大量网络操作的input、output时,会导致网络饱和。
?在Linux中可使用dstat或iftop监控网络情况。
3.检查JVM heap:
?heap设置太小会导致CPU使用率过高,这是因为JVM的垃圾回收机制导致的。
?一个快速检查该设置的方法是将heap设置为两倍大小然后检测性能改进。不要将heap设置超过物理内存大小,保留至少1G内存给操作系统和其他进程。
?你可以使用类似jmap命令行或VisualVM更加精确的计算JVM heap
4.调整Logstash worker设置:
?通过设置-w参数指定pipeline worker数量。这回提高filter和output的线程数,如果需要的话,将其设置为cpu核心数的几倍是安全的,线程在I/O上是空闲的。
?默认每个输出在一个pipeline worker线程上活动,你可以在输出中设置workers设置,不要将该值设置大于pipeline worker数。
?还可以设置输出的batch_size数,例如ES输出与batch size一致。
实验下来,改变JVM MaxHeapSize,改变batchSize,改变flushSize对Logstash的性能改进不是很明显。总结一句话,提升你的硬件性能才是王道。
后面Aix上仍将使用Logstash但是将去掉grok,ruby逻辑,仅作为一个agent输出到ELK中心服务器上,加大这台机器的配置,多个进程使劲跑!