Logstash、sharding-proxy组件高级配置

记录Logstash数据同步插件在分库分表场景下相关高可用、高并发配置

一、Logstash

   1.配置文件控制任务数

vim /etc/logstash/logstash.yml

pipeline.workers: 24

pipeline.batch.size: 10000

pipeline.batch.delay: 10

Logstash建议在修改配置项以提高性能的时候，每次只修改一个配置项并观察其性能和资源消耗（cpu、io、内存）。性能检查项包括：

1、检查input和output设备
1）、CPU
2）、Memory
3）、io
2、磁盘io
3、网络io
4、检查jvm堆
5、检查工作线程设置

2.配置说明

Logstash持久化到磁盘，当发生异常情况，比如logstash重启，有可能发生数据丢失，可以选择logstash持久化到磁盘，修改之前重启logstash数据丢失，修改之后重启logstash数据不丢失。
以下是具体操作：

queue.type: persisted path.queue: /usr/share/logstash/data #队列存储路径；如果队列类型为persisted，则生效 queue.page_capacity: 250mb #队列为持久化，单个队列大小 queue.max_events: 0 #当启用持久化队列时，队列中未读事件的最大数量，0为不限制 queue.max_bytes: 1024mb #队列最大容量 queue.checkpoint.acks: 1024 #在启用持久队列时强制执行检查点的最大数量,0为不限制 queue.checkpoint.writes: 1024 #在启用持久队列时强制执行检查点之前的最大数量的写入事件，0为不限制 queue.checkpoint.interval: 1000 #当启用持久队列时，在头页面上强制一个检查点的时间间隔

优化input,filter,output的线程模型。

增大 filter和output worker 数量 通过启动参数配置 -w 48 （等于cpu核数），logstash正则解析极其消耗计算资源，而我们的业务要求大量的正则解析，因此filter是我们的瓶颈。 官方建议线程数设置大于核数，因为存在I/O等待。 增大 woker 的 batch_size 150 -> 3000 通过启动参数配置 -b 3000

内存

logstash是将输入存储在内存之中，worker数量 * batch_size = n * heap （n 代表正比例系数）

Logstash的优化相关配置

默认配置 —> pipeline.output.workers: 1官方建议是等于 CPU 内核数 可优化为 —> pipeline.output.workers: 不超过pipeline 线程数 默认配置 —> 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 参考建议 # pipeline线程数，官方建议是等于CPU内核数 pipeline.workers: 24 # 实际output时的线程数 pipeline.output.workers: 24 # 每次发送的事件数 pipeline.batch.size: 3000 # 发送延时 pipeline.batch.delay: 5 注意：当batch.size增大，es处理的事件数就会变少，写入也就越快了。此问题用以下办法解决 就是你的bulk线程池处理不过来你的请求。处理方案：调整你es集群的bulk队列大小（默认为50），或增加你的es内存 解决办法 ： 官方的建议是提高每次批处理的数量，调节传输间歇时间。当batch.size增大，es处理的事件数就会变少，写入也就愉快了。 具体的worker/output.workers数量建议等于CPU数，batch.size/batch.delay根据实际的数据量逐渐增大来测试最优值。

总结
通过设置 -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
还有请注意插件连接池的数量设置，比如mysql最大连接数，单个脚本文件中的配置设置

3.logstash-jdbc-output插件

链接池偶尔报错:HikariPool-1 – Connection is not available, request timed out after 39985ms.

记录：调试相关插件配置，最终发现是因为logstash work数过大，CPU配置，任务配置文件中关于线程，连接池配置不合理导致

二、Sharding-proxy

点击查看proxys属性配置 

主要是修改连接池，一个是proxy自己的连接池，一个是每个分片库配置使用的最大连接池，别太大，理解以下CPU抢占，线程搞太多反而影响效率，也不能太小，太小吞吐量太差