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

引用 1 楼 qq_35209952 的回复:

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

没有，就是文本文件

这边有用过的朋友么？

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

第六个问题：这样设置不行？
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的，感谢！

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

引用 8 楼 davinciyxw 的回复:

Quote: 引用 5 楼 Chinajiyong 的回复:

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

这个设置是OK的，感谢！

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

可以尝试下，期待你后面的分享

做了几天测试，总结一下，顺便结贴。

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中心服务器上，加大这台机器的配置，多个进程使劲跑！