性能分析服务器硬件Linux：1cpu4GRAM假设每条日志为250Byte。分析：①logstash-Linux：1cpu4GRAM每秒500条日志；每秒删除ruby??660条日志；每秒删除grok1000个数据。②filebeat-Linux：1cpu4GRAM每秒2500-3500条数据；每台机器可以处理：24h*60min*60sec*3000*250Byte=64,800,000,000Bytes，约64G。③瓶颈是logstash从Redis中取数据，存储到ES中。打开一个logstash，每秒处理约6000条数据；打开两个logstashes，每秒处理10000条左右的数据（cpu基本满）；④logstash的启动过程占用了很多系统资源，因为在脚本中勾选了java、ruby等环境变量，启动后资源占用会恢复正常。2、关于采集日志的选择：logstash/filter没有原则要求使用filebeat或者logstash，两者作为shipper的功能是一样的。不同的是：logstash集成了很多插件，比如grok，ruby，所以相对于beat来说是重量级的；logstash启动后占用资源较多，如果硬件资源充足，可以不用考虑两者的区别；logstash基于JVM，支持跨平台；而beat是用golang写的，AIX不支持；jdk(jre)1.732bit，AIX64bit平台不支持64bit；filebeat可以直接输入到ES中，但是系统中有一种情况是logstash直接输入到ES中，会导致索引类型不同导致检索复杂，最好统一输入到els的源中。总结：logstash/filter各有优缺点，但我推荐选择：在每个需要采集的日志服务器上配置filebeat，因为它是轻量级的，用来采集日志；然后统一输出到logstash来处理日志；最后由logstash统一输出到es。3.可优化的logstash参数的优化相关配置可以根据自己的硬件进行优化：①管道线程数，官方推荐等于CPU核数。默认配置--->pipeline.workers:2;可以优化为--->pipeline.workers：CPU核数（或者CPU核数的几倍）。②实际输出线程数的默认配置--->pipeline.output.workers:1；可以优化为--->pipeline.output.workers:不超过管道线程数。③默认配置每次发送的事件数--->pipeline.batch.size:125；可以优化为--->pipeline.batch.size:1000。④发送延迟默认配置--->pipeline.batch.delay:5;可以优化为--->pipeline.batch.size:10。总结：通过设置-w参数指定pipelineworker的个数，或者直接修改配置文件logstash.yml。这将增加过滤器和输出的线程数，如果需要，将其设置为CPU内核数的几倍是安全的，线程在I/O上空闲。默认情况下，每个输出都在管道工作线程上处于活动状态。您可以在output输出中设置workers设置。不要将此值设置为大于管道工作者的数量。也可以设置输出的batch_size，比如E??S输出与batchsize一致。filter设置为multiline后，pipelineworker会自动为1。如果使用filebeat，建议在beat中使用multiline。如果使用logstash作为shipper，建议在input中设置multiline而不是filter。Logstash中的JVM配置文件：Logstash是一个基于Java的程序，需要运行在JVM中，可以通过配置jvm.options为JVM设置。比如最大最小内存，垃圾清理机制等等。JVM的内存分配不宜太大或太小，太大会拖慢操作系统。太小了，无法开始。默认如下：xms256m#minimummemoryusage;Xmx1g#最大内存使用量。4、引入RedisFilebeat相关问题，可以直接输入logstash（indexer），但是logstash没有存储功能。如果需要重启，需要先停止所有连接的beats，然后再停止logstash，会给运维带来麻烦；另外，如果logstash异常，则Data会丢失；Redis是作为数据缓冲池引入的。当logstash异常停止时，可以从Redis客户端看到缓存在Redis中的数据；Redis可以使用列表（最多4,294,967,295项）或发布-订阅存储模式；RedisasELK缓冲队列优化：bind0.0.0.0#不监听本地端口；requirepassilinux.io#为安全操作加密密码；只做队列，不需要持久化存储，关闭所有持久化功能：快照（RDB文件）和Append文件（AOF文件），性能更好；保存“”禁用快照；appendonly没有关闭RDB。关闭内存淘汰策略，将最大内存空间maxmemory0#maxmemory设置为0，也就是说我们对Redis的内存使用没有任何限制。5.Elasticsearch节点优化配置服务器硬件配置，OS参数：1）/etc/sysctl.conf配置#vim/etc/sysctl.confvm.swappiness=1#ES建议将此参数设置为1，可以大大减小体积swap分区的，强制最大使用内存，注意，这里不要设置为0，这可能会导致OOMnet.core.somaxconn=65535#定义每个端口的最大监听队列长度vm.max_map_count=262144#限制一个进程你可以拥有的VMA（VirtualMemoryAreas）的数量。虚拟内存区域是虚拟地址空间的连续区域。当VMA数超过这个值时，OOMfs.file-max=518144#设置Linux内核分配的最大文件句柄数#sysctl-p#生效2）limits.conf配置#vim/etc/security/limits。d/common-session添加如下属性：sessionrequiredpam_limits.so可能需要重启才能生效。Elasticsearch中的JVM配置文件：-Xms2g-Xmx2g将最小堆大小(Xms)和最大堆大小(Xmx)设置为彼此相等。Elasticsearch可用的堆越多，可用于缓存的内存就越多。但请注意，过多的堆会给您带来长时间的垃圾收集暂停。将Xmx设置为不超过物理RAM的50%，以确保有足够的物理内存留给内核文件系统缓存。不要将Xmx设置为高于JVM用于压缩对象指针的阈值；确切的截止值各不相同，但更接近32GB。不要超过32G。如果空间大，可以多跑几个实例，不要让一个实例占用太多内存。Elasticsearch配置文件优化参数1）主配置文件#vimelasticsearch.ymlbootstrap.memory_lock:true#锁定内存，不使用swap#缓存、线程等优化如下bootstrap.mlockall:truetransport.tcp.compress:trueindices.fielddata.缓存。size:40%indices.cache.filter.size:30%indices.cache.filter.terms.size:1024mbthreadpool:search:type:cachedsize:100queue_size:20002)setenvironmentvariable#vim/etc/profile.d/elasticsearch.shexportES_HEAP_SIZE=2g#HeapSize不超过物理内存的一半，小于32G。集群优化（我没用过集群）：ES是分布式存储。设置相同的cluster.name后，会自动发现并加入集群；集群会自动选举一个master，当master宕机时重新选举；为防止“brainSplit”，簇数应为奇数；为了有效地管理节点，您可以禁用广播发现。zen.ping.multicast.enabled:false，并设置单播节点组discovery.zen.ping.unicast.hosts:["ip1","ip2","ip3"]。6、性能检查检查输入输出的性能：Logstash运行速度与其连接的服务一样快，可以和输入输出一样快。检查系统参数：1)CPU注意CPU是否过载。在Linux/Unix系统中，可以使用top-H查看进程参数和总计。如果CPU使用率高，直接跳到检查JVM堆部分，检查Logstashworker设置。2）内存注意Logstash运行在Java虚拟机中，所以它只会使用你分配给它的最大内存。检查其他应用程序是否占用大量内存，导致Logstash使用硬盘交换，当应用程序占用内存超过物理内存时，会出现这种情况。3)I/O监控磁盘I/O检查磁盘饱和使用Logstash插件（例如使用文件输出）磁盘饱和会发生。Logstash在出现大量错误时会产生大量的错误日志，也会导致磁盘饱和。在Linux中，使用iostat、dstat或其他命令来监视磁盘I/O。4）监控网络I/O当使用大量的网络输入输出操作时，会导致网络饱和。在Linux中，您可以使用dstat或iftop来监视网络状况。检查JVM堆：堆设置太小会导致CPU占用率过高，这是JVM的垃圾回收机制造成的。检查此设置的一种快速方法是将堆大小加倍并检测性能改进。堆设置不要超过物理内存大小，操作系统和其他进程至少要预留1G内存。您可以使用jmap命令行或VisualVM之类的工具来更精确地计算JVM堆。来源：https://www.cnblogs.com/沿...
