在超过12个centos 5.8服务器的集群上，我使用本机logstash托运人部署了logstash，该托运人将/var/log/*/*.log回到中央logstash服务器。
我们尝试使用rsyslogd作为托运人，但由于rsyslogd的ImFile模块中存在一个错误，如果远程端没有回复，日志会堆积在内存中。
我们目前使用Redis作为传输机制，因此logstash01已经在本地运行redis，绑定到这些日志的VLAN的IP地址。
因此logstash-shipper在logstash01上发送到redis。 logstash01发送到在单独的进程中运行的Elasticsearch。
这就是我们所看到的。 Elasticsearch有141个被封锁的线程。 通过elasticsearch的父母表明：
futex(0x7f4ccd1939d0, FUTEX_WAIT, 26374, NULL
这里是elasticsearch的jstack
这是来自logstash的jstack
所以..昨天晚上，一些web服务器（logstash的日志）变得疯狂，平均负载超过500。
在logstash01上，有这个
Dec 19 00:44:45 logstash01 kernel: [736965.925863] Killed process 23429 (redis-server) total-vm:5493112kB, anon-rss:4248840kB, file-rss:108kB
所以OOM杀手杀死了Redis服务器，这意味着日志堆积在服务器上的内存中，这些服务器正在运送东西。这意味着apache会把内裤弄乱。 （坦率地说，我不知道如何，我只是假设它是拖尾日志）..
这是我关于事件如何展开的理论：
问题是这些：
为什么apache只要有日志的尾随就行了。 这个东西是否会阻止Apache的写作？
有一个理智的方法可以使弹性search更快/更好/有弹性吗？
有没有一种健全的方法来使得Redis具有弹性，并且不会因为被OOM而死亡
是否有一个根本的缺陷，我已经把它设置，或每个人都有这个问题？
– 编辑 –
一些规格为@lusis。
admin@log01:/etc/init$ free -m total used free shared buffers cached Mem: 7986 6041 1944 0 743 1157 -/+ buffers/cache: 4140 3845 Swap: 3813 3628 185 Filesystem Size Used Avail Use% Mounted on /dev/sda2 19G 5.3G 13G 31% / udev 3.9G 4.0K 3.9G 1% /dev tmpfs 1.6G 240K 1.6G 1% /run none 5.0M 0 5.0M 0% /run/lock none 3.9G 0 3.9G 0% /run/shm /dev/sda1 90M 72M 14M 85% /boot /dev/mapper/data-disk 471G 1.2G 469G 1% /data /dev/sda2 on / type ext3 (rw,errors=remount-ro) proc on /proc type proc (rw,noexec,nosuid,nodev) sysfs on /sys type sysfs (rw,noexec,nosuid,nodev) none on /sys/fs/fuse/connections type fusectl (rw) none on /sys/kernel/debug type debugfs (rw) none on /sys/kernel/security type securityfs (rw) udev on /dev type devtmpfs (rw,mode=0755) devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620) tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755) none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880) none on /run/shm type tmpfs (rw,nosuid,nodev) /dev/sda1 on /boot type ext2 (rw) /dev/mapper/data-disk on /data type ext3 (rw) /data/elasticsearch on /var/lib/elasticsearch type none (rw,bind) log01:/etc/init$ top top - 14:12:20 up 18 days, 21:59, 2 users, load average: 0.20, 0.35, 0.40 Tasks: 103 total, 1 running, 102 sleeping, 0 stopped, 0 zombie Cpu0 : 3.0%us, 1.0%sy, 0.0%ni, 95.7%id, 0.0%wa, 0.0%hi, 0.3%si, 0.0%st Cpu1 : 12.0%us, 1.0%sy, 0.0%ni, 86.6%id, 0.0%wa, 0.0%hi, 0.3%si, 0.0%st Cpu2 : 4.7%us, 0.3%sy, 0.0%ni, 94.9%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu3 : 5.6%us, 1.3%sy, 0.0%ni, 93.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu4 : 5.3%us, 1.3%sy, 0.0%ni, 93.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu5 : 6.4%us, 1.0%sy, 0.0%ni, 92.3%id, 0.0%wa, 0.0%hi, 0.3%si, 0.0%st Mem: 8178120k total, 6159036k used, 2019084k free, 761780k buffers
你的文章没有描述太多的规格（LS索引器上的记忆，日志量或其他许多），但我会试着回答你最好的问题，我可以先。 免责声明：我是logstash开发人员之一 –
阿帕奇疯狂可能是logstash过程的副作用。 我现在就把这个放在一边。
制作ES f / b / s的理想方法是增加更多的ES节点。 这很容易。 他们甚至根据networking拓扑自动发现对方。 在这个行业17年后，我从来没有见过像ElasticSearch那样简单的横向扩展。
对于f / b / s Redis，不要使用任何redis集群。 较新版本的Logstash可以在内部执行Redis负载平衡。 Redis输出支持插件configuration中的Redis主机列表，支持即将被添加到input端，以便与之匹配。 在此期间，您可以在索引器/客户端使用多个Redisinput定义。
我无法回答这个问题，这听起来像是你想用一个单一的（可能是动力不足的主机）做很多事情。
任何好的扩展过程都是从将并置的组件分解成不同的系统开始的。 我没有看到你的configuration在任何地方，但在logstash的瓶颈在filter的地方。 根据您所做的转换次数，可能会影响Logstash进程的内存使用情况。
Logstash和Legos很像。 您可以使用2×4砖，也可以使用两块2×2砖来完成相同的任务。 除了logstash的情况，使用较小的砖块实际上比单一的大砖块更坚固。
我们通常给出的一些一般build议是：
尽可能快地从边缘发送日志如果您可以使用纯粹的networking传输，而不是写入磁盘，那很好，但不是必需的。 Logstash是基于JVM的，具有好的和坏的含义。 使用替代托运人。 我写了一个基于Python（ https://github.com/lusis/logstash-shipper ），但我build议人们使用海狸，而不是（ https://github.com/josegonzalez/beaver ）。
以需要尽可能less过滤的格式生成日志（json或最佳的json事件格式）这并不总是可能的。 我写了一个log4j appender来执行此操作（ https://github.com/lusis/zmq-appender ），并最终将模式布局分解为自己的回购（ https://github.com/lusis/log4j-jsonevent-layout ）。 这意味着我不必在logstash中对这些日志进行任何筛选。 我只是将inputtypes设置为'json-event'
对于Apache，你可以尝试这种方法： http : //cookbook.logstash.net/recipes/apache-json-logs/
另外请注意，logstash邮件列表非常活跃，所以你应该总是从那里开始。 消毒和configuration你的configuration，因为这是最好的开始。
有些公司（比如Sonian）将ElasticSearch扩展到PB级别，而公司（如Mailchimp和Dreamhost）也将Logstash扩展到疯狂级别。 可以办到。