关于ELK的搭建和性能问题讨论

[莱昂纳多达芬奇]

初用ELK，抛出几个问题，用过的朋友请不吝赐教
1.作为shipper，使用filebeat与使用logstash相比优势是什么？
2.最佳实践是shipper输出到broker（如Redis），而这一步其实是可以省的，比如filebeat可以输出到logstash再存到ES，那么瓶颈的数量级大概在多少？比如每秒多少条日志就会把接收端的logstash压趴。
3.接问题2，如果使用broker（Redis），那么性能会得到多大的提升，比如每秒可以处理多少日志？
4.继续接...，问题2和3中，如果性能仍然不能满足，能否通过启动多个“组件”，比如起两个Redis，起多个logstash进程。agent配置输出分到两个Redis上，这样是否会有问题？
5.ELK的性能能达到什么水平？或者说大家的ES每秒输入量达到了多少？硬件配置达到中等的情况下（比如4核心8GMem）。
6.logstash的一个配置问题，日志中有中文，所以在input中加了个codec=>encoding gb2312，那么在input中就没法再使用codec设置multiline了？测下来只有配在前面的一个生效，没办法把multiline放在filter中，是否有性能问题？

P.S.最后大概说说我这里的情况，因为有的服务器使用了AIX小机，只能使用logstash，而大部分服务器是Linux，考虑fileat，所以有了问题1和2；每台服务器每天日志预估会有3-5GB，所以要考虑一下性能瓶颈，目前还没有Redis，当然现在也还没进入生产；

[逗泥丸的平方]

虽然都看不懂...... 不过3~5个G 是压缩过的吗

[莱昂纳多达芬奇]

引用 1 楼 qq_35209952 的回复:

虽然都看不懂...... 不过3~5个G 是压缩过的吗

没有，就是文本文件

[莱昂纳多达芬奇]

这边有用过的朋友么？

[EnForGrass]

这一块也是刚学，看过一些资料， 可以部署多个logstash实例来协作处理日志，没尝试过。 可以用用ES cluster，至少可以提高search的性能

[EnForGrass]

第六个问题：这样设置不行？ codec => multiline { max_bytes => "10MiB" max_lines => 500 charset => "GB2312" pattern => "^(?!.*?=== >>>>>>>> ===).*$" what => "previous" }

[莱昂纳多达芬奇]

引用 5 楼 Chinajiyong 的回复:

第六个问题：这样设置不行？ codec => multiline { max_bytes => "10MiB" max_lines => 500 charset => "GB2312" pattern => "^(?!.*?=== >>>>>>>> ===).*$" what => "previous" }

这个我试试看后过来回复

[莱昂纳多达芬奇]

引用 5 楼 Chinajiyong 的回复:

第六个问题：这样设置不行？ codec => multiline { max_bytes => "10MiB" max_lines => 500 charset => "GB2312" pattern => "^(?!.*?=== >>>>>>>> ===).*$" what => "previous" }

这个我试试看后过来回复

[莱昂纳多达芬奇]

引用 5 楼 Chinajiyong 的回复:

第六个问题：这样设置不行？ codec => multiline { max_bytes => "10MiB" max_lines => 500 charset => "GB2312" pattern => "^(?!.*?=== >>>>>>>> ===).*$" what => "previous" }

这个设置是OK的，感谢！ 关于多个进程，目前想法是把日志分类，不同类型使用不同进程，应该是可以的。

[EnForGrass]

引用 8 楼 davinciyxw 的回复:

[quote=引用 5 楼 Chinajiyong 的回复:] 第六个问题：这样设置不行？ codec => multiline { max_bytes => "10MiB" max_lines => 500 charset => "GB2312" pattern => "^(?!.*?=== >>>>>>>> ===).*$" what => "previous" }

这个设置是OK的，感谢！ 关于多个进程，目前想法是把日志分类，不同类型使用不同进程，应该是可以的。[/quote] 可以尝试下，期待你后面的分享

[莱昂纳多达芬奇]

做了几天测试，总结一下，顺便结贴。 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中心服务器上，加大这台机器的配置，多个进程使劲跑！