共计 4447 个字符，预计需要花费 12 分钟才能阅读完成。
性能剖析
- 服务器硬件 Linux：1cpu4GRAM
- 假如每条日志 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 的启动过程占用大量系统资源，因为脚本中要查看 java、ruby 以及其余环境变量，启动后资源占用会复原到失常状态。
2、对于收集日志的抉择：logstash/filter
没有准则要求应用 filebeat 或 logstash，两者作为 shipper 的性能是一样的。区别在于：
- logstash 因为集成了泛滥插件，如 grok、ruby，所以相比 beat 是重量级的；
- logstash 启动后占用资源更多，如果硬件资源足够则无需思考二者差别；
- logstash 基于 JVM，反对跨平台；而 beat 应用 golang 编写，AIX 不反对；
- AIX 64bit 平台上须要装置 jdk（jre）1.7 32bit，64bit 的不反对；
- filebeat 能够间接输出到 ES，然而零碎中存在 logstash 间接输出到 ES 的状况，这将造成不同的索引类型造成检索简单，最好对立输出到 els 的源。
总结：logstash/filter 总之各有千秋，然而我举荐抉择：在每个须要收集的日志服务器上配置 filebeat，因为轻量级，用于收集日志；再对立输入给 logstash，做对日志的解决；最初对立由 logstash 输入给 es。
3、logstash 的优化相干配置
能够优化的参数，可依据本人的硬件进行优化配置：
①pipeline 线程数，官网倡议是等于 CPU 内核数
- 默认配置 —> pipeline.workers: 2；
- 可优化为 —> pipeline.workers: CPU 内核数（或几倍 CPU 内核数）。
②理论 output 时的线程数
- 默认配置 —> pipeline.output.workers: 1；
- 可优化为 —> pipeline.output.workers: 不超过 pipeline 线程数。
③每次发送的事件数
- 默认配置 —> pipeline.batch.size: 125；
- 可优化为 —> pipeline.batch.size: 1000。
④发送延时
- 默认配置 —> pipeline.batch.delay: 5；
- 可优化为 —> pipeline.batch.size: 10。
总结：
- 通过设置 - w 参数指定 pipeline worker 数量，也可间接批改配置文件 logstash.yml。这会进步 filter 和 output 的线程数，如果需要的话，将其设置为 cpu 外围数的几倍是平安的，线程在 I / O 上是闲暇的。
- 默认每个输入在一个 pipeline worker 线程上流动，能够在输入 output 中设置 workers 设置，不要将该值设置大于 pipeline worker 数。
- 还能够设置输入的 batch_size 数，例如 ES 输入与 batch size 统一。
- filter 设置 multiline 后，pipline worker 会主动将为 1，如果应用 filebeat，倡议在 beat 中就应用 multiline，如果应用 logstash 作为 shipper，倡议在 input 中设置 multiline，不要在 filter 中设置 multiline。
Logstash 中的 JVM 配置文件：
Logstash 是一个基于 Java 开发的程序，须要运行在 JVM 中，能够通过配置 jvm.options 来针对 JVM 进行设定。比方内存的最大最小、垃圾清理机制等等。JVM 的内存调配不能太大不能太小，太大会拖慢操作系统。太小导致无奈启动。默认如下：
- Xms256m# 最小应用内存；
- Xmx1g# 最大应用内存。
4、引入 Redis 的相干问题
filebeat 能够间接输出到 logstash（indexer），但 logstash 没有存储性能，如果须要重启须要先停所有连入的 beat，再停 logstash，造成运维麻烦；另外如果 logstash 产生异样则会失落数据；引入 Redis 作为数据缓冲池，当 logstash 异样进行后能够从 Redis 的客户端看到数据缓存在 Redis 中；
Redis 能够应用 list(最长反对 4,294,967,295 条) 或公布订阅存储模式；
Redis 做 ELK 缓冲队列的优化：
- bind 0.0.0.0 #不要监听本地端口；
- requirepass ilinux.io #加明码，为了平安运行；
- 只做队列，没必要长久存储，把所有长久化性能关掉：
- 快照（RDB 文件）和追加式文件（AOF 文件），性能更好；
- save “” 禁用快照；
- appendonly no 敞开 RDB。
- 把内存的淘汰策略关掉，把内存空间最大
maxmemory 0 #maxmemory 为 0 的时候示意咱们对 Redis 的内存应用没有限度。5、Elasticsearch 节点优化配置
服务器硬件配置，OS 参数：
1）/etc/sysctl.conf 配置
# vim /etc/sysctl.conf
vm.swappiness = 1 #ES 举荐将此参数设置为 1，大幅升高 swap 分区的大小，强制最大水平的应用内存，留神，这里不要设置为 0, 这会很可能会造成 OOM
net.core.somaxconn = 65535 #定义了每个端口最大的监听队列的长度
vm.max_map_count= 262144 #限度一个过程能够领有的 VMA(虚拟内存区域) 的数量。虚拟内存区域是一个间断的虚拟地址空间区域。当 VMA 的数量超过这个值，OOM
fs.file-max = 518144 #设置 Linux 内核调配的文件句柄的最大数量
# sysctl -p #失效一下
2）limits.conf 配置
# vim /etc/security/limits.conf
elasticsearch soft nofile 65535
elasticsearch hard nofile 65535
elasticsearch soft memlock unlimited
elasticsearch hard memlock unlimited
3）为了使以上参数永恒失效，还要设置两个中央：
# vim /etc/pam.d/common-session-noninteractive
# vim /etc/pam.d/common-session
增加如下属性：session required pam_limits.so
可能需重启后失效。
Elasticsearch 中的 JVM 配置文件：
-Xms2g
-Xmx2g
- 将最小堆大小（Xms）和最大堆大小（Xmx）设置为彼此相等。
- Elasticsearch 可用的堆越多，可用于缓存的内存就越多。但请留神，太多的堆可能会使您长时间垃圾收集暂停。
- 设置 Xmx 为不超过物理 RAM 的 50%，以确保有足够的物理内存留给内核文件系统缓存。
- 不要设置 Xmx 为 JVM 用于压缩对象指针的临界值以上；确切的截止值有所不同，但靠近 32 GB。不要超过 32G，如果空间大，多跑几个实例，不要让一个实例太大内存。
Elasticsearch 配置文件优化参数
1）主配置文件
# vim elasticsearch.yml
bootstrap.memory_lock: true #锁住内存，不应用 swap
#缓存、线程等优化如下
bootstrap.mlockall: true
transport.tcp.compress: true
indices.fielddata.cache.size: 40%
indices.cache.filter.size: 30%
indices.cache.filter.terms.size: 1024mb
threadpool:
search:
type: cached
size: 100
queue_size: 2000
2）设置环境变量
# vim /etc/profile.d/elasticsearch.sh
export ES_HE AP _SIZE=2g #Heap Size 不超过物理内存的一半，且小于 32G。集群的优化（我未应用集群）：
- ES 是分布式存储，当设置同样的 cluster.name 后会主动发现并退出集群；
- 集群会主动选举一个 master，当 master 宕机后从新选举；
- 为避免 ” 脑裂 ”，集群中个数最好为奇数个；
- 为无效治理节点，可敞开播送 discovery. zen.ping.multicast.enabled: false，并设置单播节点组 discovery.zen.ping.unicast.hosts: [“ip1”, “ip2”, “ip3”]。
6、性能的查看
查看输出和输入的性能：Logstash 和其连贯的服务运行速度统一，它能够和输出、输入的速度一样快。
查看零碎参数：
- 1）CPU
- 留神 CPU 是否过载。在 Linux/Unix 零碎中能够应用 top- H 查看过程参数以及总计。
- 如果 CPU 应用过高，间接跳到查看 JVM 堆的章节并查看 Logstash worker 设置。
- 2）Memory
- 留神 Logstash 是运行在 Java 虚拟机中的，所以它只会用到你调配给它的最大内存。
- 查看其余利用应用大量内存的状况，这将造成 Logstash 应用硬盘 swap，这种状况会在利用占用内存超出物理内存范畴时。
- 3）I/ O 监控磁盘 I / O 查看磁盘饱和度
- 应用 Logstash plugin（例如应用文件输入）磁盘会产生饱和。
- 当产生大量谬误，Logstash 生成大量谬误日志时磁盘也会产生饱和。
- 在 Linux 中，可应用 iostat，dstat 或者其余命令监控磁盘 I /O。
- 4）监控网络 I /O
- 当应用大量网络操作的 input、output 时，会导致网络饱和。
- 在 Linux 中可应用 dstat 或 iftop 监控网络状况。
查看 JVM heap：
- heap 设置太小会导致 CPU 使用率过高，这是因为 JVM 的垃圾回收机制导致的。
- 一个疾速查看该设置的办法是将 heap 设置为两倍大小而后检测性能改良。不要将 heap 设置超过物理内存大小，保留至多 1G 内存给操作系统和其余过程。
- 你能够应用相似 jmap 命令行或 VisualVM 更加准确的计算 JVM heap。
起源：https://www.cnblogs.com/along…