不多说，直接上问题。版本logstash-2.4.0，启动后提示错误：
!!! Please upgrade your java version, the current version '1.7.0_45-mockbuild_2013_10_22_03_37-b00' may cause problems. We recommend a minimum version of 1.7.0_51
{:timestamp=>"2018-11-02T17:46:20.823000+0800", :message=>"Pipeline main started"}
!!! Please upgrade your java version, the current version '1.7.0_45-mockbuild_2013_10_22_03_37-b00' may cause problems. We recommend a minimum version of 1.7.0_51
{:timestamp=>"2018-11-02T17:46:25.727000+0800", :message=>"Pipeline main started"}
{:timestamp=>"2018-11-02T17:47:10.274000+0800", :message=>"Reached open files limit: 4095, set by the 'max_open_files' option or default, files yet to open: 375248", :level=>:warn}
{:timestamp=>"2018-11-02T17:47:15.429000+0800", :message=>"Reached open files limit: 4095, set by the 'max_open_files' option or default, files yet to open: 375248", :level=>:warn}
{:timestamp=>"2018-11-02T17:47:39.819000+0800", :message=>"Reached open files limit: 4095, set by the 'max_open_files' option or default, files yet to open: 375248", :level=>:warn}
先说一下项目环境，由于项目需要，申请了8台主机，1台web应用主机（app），3台项目服务器负载均衡、每台搭载logstash处理操作日志（后面用gate1、gate2、gate3、gate4），3台日志存储服务器（es、redis集群，用es1、es2、es3代替）。
因为项目服务器上的大量操作日志，需要通过logstash进行处理送入es，看到这个问题就想到修改limit文件，于是对各个集群主机进行limit配置文件不断的配置，重启logstash，问题依旧存在。记录一下解决问题过程中遇到的各种坑。
#血案一
根据logstash抛出的问题，首先想到修改配置，初次了解logstash，应该修改哪些主机的配置呢，首先ulimit -a看了一下搭载logstash的负载均衡服务器，发现配置都已经修改过，并且配置到最大
[linkage@dandianwg-gate3 bin]$ ulimit -a
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
scheduling priority (-e)
file size (blocks, -f) unlimited
pending signals (-i)
max locked memory (kbytes, -l)
max memory size (kbytes, -m) unlimited
open files (-n)
pipe size ( bytes, -p)
POSIX message queues (bytes, -q)
real-time priority (-r)
stack size (kbytes, -s) unlimited
cpu time (seconds, -t) unlimited
max user processes (-u)
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
#很明显抛出错误的不是logstash主机，那么查看es集群的3台主机，果然配置很低
[linkage@dandianwg-es1 ~]$ ulimit -a
core file size (blocks, -c)
data seg size (kbytes, -d) unlimited
scheduling priority (-e)
file size (blocks, -f) unlimited
pending signals (-i)
max locked memory (kbytes, -l)
max memory size (kbytes, -m) unlimited
open files (-n)
pipe size ( bytes, -p)
POSIX message queues (bytes, -q)
real-time priority (-r)
stack size (kbytes, -s)
cpu time (seconds, -t) unlimited
max user processes (-u)
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
#开始对es集群的主机进行修改配置vi /etc/security/limits.conf 、vi /etc/security/limits.d/90-nproc.conf，把各项指标都调到65535
[root@dandianwg-es1 ~]$ vi /etc/security/limits.conf
# End of file
* soft nproc
* hard nproc
* soft nofile
* hard nofile [root@dandianwg-es1 ~]$
[root@dandianwg-es1 ~]$vi /etc/security/limits.d/-nproc.conf
# Default limit for number of user's processes to prevent
# accidental fork bombs.
# See rhbz # for reasoning.
* soft nproc
root soft nproc 65535
#血案二
root用户登录es集群主机ulimit -a查看配置生效，切换到普通查看配置生效居然没生效，open files依然1024（这个问题让人摸不着头脑，各种配置调试、百度，偶然发现一篇文章提到和ssh有关）
中途请教了一个大师，将文件/etc/security/limits.d/90-nproc.conf中的配置全部配成unlimited，结果不可预料的事情发生了（root没有登录权限了，普通用户可以登录并且无法切换到root，最后请网络管理部门通过单用户模式进入还原了配置，单用户模式我也不懂，类似windows的虚拟机吧）。
[linkage@dandianwg-es1 ~]$ cat /etc/security/limits.d/-nproc.conf
# Default limit for number of user's processes to prevent
# accidental fork bombs.
# See rhbz # for reasoning.
* soft nproc unlimited
root soft nproc unlimited
#首先查看了一番当前系统环境，发现ssl、ssh版本都很低，于是开始升级ssh（由于es集群3个主机系统都是克隆安装，所以3个主机系统一模一样）
[linkage@dandianwg-app bin]$ ssh -V
OpenSSH_5.3p1, OpenSSL 1.0.-fips Mar [linkage@dandianwg-app bin]$ openssl version -a
OpenSSL 1.0.1s Mar
built on: Wed Aug ::
platform: linux-x86_64
options: bn(,) rc4(16x,int) des(idx,cisc,,int) idea(int) blowfish(idx)
compiler: gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
OPENSSLDIR: "/usr/local/ssl"
#将zlib、ssl、ssh都升级了一遍，重启服务（版本分别升级到zlib-1.2.11、openssl-1.0.2p、openssh-7.9p1，升级步骤不说了，网上一大堆）
以下是升级脚本：
tar -xvf openssh-.9p1.tar.gz
tar -xvf openssl-1.0.2p.tar.gz
tar -xvf zlib-1.2..tar.gz cd /export/home/tools/zlib-1.2.
./configure --prefix=/usr
make -j4 && make install cd /export/home/tools/openssl-1.0.2p
./config --prefix=/usr --shared zlib
make -j4 && make install cd /export/home/tools/openssh-7.9
./configure --prefix=/usr --with-pam --with-zlib --with-md5-passwords --without-openssl-header-check
make && make install sed -i 's/SSHD=\/usr\/local\/sbin\/sshd/SSHD=\/usr\/sbin\/sshd/g' /etc/init.d/sshd
service sshd restart
#第三坑 由于是源码安装,安装成功之后查看版本也正常，（不管普通用户还是root，通通没有登录权限）
[linkage@dandianwg-gate2 bin]$ ssh 192.168.54.17
The authenticity of host '192.168.54.17 (192.168.54.17)' can't be established.
RSA key fingerprint is b8:f3::::2e:::d5:b4::b9:e9:a4:cc:f5.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.54.17' (RSA) to the list of known hosts.
linkage@192.168.54.17's password:
Permission denied, please try again.
linkage@192.168.54.17's password:
Permission denied, please try again.
linkage@192.168.54.17's password:
Permission denied (publickey,password,keyboard-interactive).
解决方案：导致问题的原因是由于安装新版ssh时指定了新目录--prefix=/usr，/etc/init.d/sshd的配置文件（这里只需要覆盖安装，并且不需要修改/etc/init.d/sshd就正常了）
./configure --prefix=/usr --with-pam --with-zlib --with-md5-passwords --without-openssl-header-check
cd /export/home/tools/openssh-7.9
./configure --prefix=/usr --with-pam --with-zlib --with-md5-passwords --without-openssl-header-check
make && make install
sed -i 's/SSHD=\/usr\/local\/sbin\/sshd/SSHD=\/usr\/sbin\/sshd/g' /etc/init.d/sshd
service sshd restart 修改脚本如下：
cd /export/home/tools/openssh-7.9
./configure --with-ssl-dir=/usr/local/ssl --with-openssl-includes=/usr/local/ssl/include/openssl --with-openssl-libraries=/usr/local/ssl/lib
make && make install
//将之前安装替换的配置还原
sed -i 's/SSHD=\/usr\/sbin\/sshd/SSHD=\/usr\/local\/sbin\/sshd/g' /etc/init.d/sshd
service sshd restart
#ssh升级后，通过普通用户和root登录测试，发现open files生效，（经过一些列的波折，搞定了修改open files普通用户不生效的问题）
#回到正题，解决logstash抛异常的问题，其实经过上面的填坑已经把这个异常的问题解决了，为什么logstash还在抛open files的异常？？？
原因分析：我们知道logstash可以根据业务需要配置多进程，我这里就配置了两个进程文件，一个用于文件入库es（logstash.conf），一个用于日志审计（tcp.conf，在app主机（其中一台web服务器）上有一个tcp协议接口单独处理文件的程序。
所以上面我们经过一系列的填坑，把es集群的ulimit 配置搞定了，其实真正的异常则是从app主机上抛出来的，只需要将app主机上的limit配置最大化。
经过以上的填坑，收获颇多，对linux和logstash都有了进一步的了解，一个研发在运维上的经验分享（本人是linux盲人，欢迎大神指评）。
2019-03-22记录：在几个月前经过以上一系列问题处理，现在依然出现logstash的报错Reached open files limit: 4095, set by the 'max_open_files' option or default
现补充最终解决方案，logstash处理文件目录下，堆积大量文件，删除之后搞定.