扩展 Logstash（使用 redis/elasticsearch）

Question

在超过 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

所以.. 昨晚，一些网络服务器（其日志由 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的服务器，然后指原木堆放在内存里面是已上市的东西..而服务器上莫名其妙意味着阿帕奇获取其短裤的扭曲。（坦率地说，我不确定如何，我只是假设它拖尾了日志）。

这是我关于事件如何展开的理论：

1. 我们遇到了交通高峰。
2. 产生了大量的日志。
3. 这些堆积在 Redis 中，因为 logstash/elasticsearch 似乎只能每秒处理 300-400 个新事件。
4. Redis 已经完全填满了，以至于 OOM 杀手毫无意义地屠杀了它。
5. Redis 停止接受新项目。
6. 项目现在开始堆积在远程主机端。
7. 一切都变得疯狂。Apache 停止接受请求。（为什么？）。

问题是这些：

8. 如果日志后面有一些东西，为什么 apache 会发疯。是不是拖着它的东西阻止了 apache 的写作？

9. 有没有一种理智的方法可以让 elasticsearch 更快/更好/更有弹性？

10. 有没有一种理智的方法可以使 redis 具有弹性并且不会因为被 OOM'd 而死亡

11. 我设置的方式是否存在根本性缺陷，或者每个人都有这个问题？

- 编辑 -

@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

Answer 1

您的帖子并没有对规格（LS 索引器上的内存、日志量或其他许多内容）进行太多描述，但我会先尽力回答您的问题。免责声明：我是 logstash 开发者之一 -

1. Apache 发疯可能是 logstash 进程起作用的副作用。我暂时把它放在一边。

2. 使 ES f/b/s 的明智方法是添加更多 ES 节点。这真的很容易。它们甚至会根据网络拓扑自动发现彼此。在这个行业工作了 17 年之后，我从未见过像 ElasticSearch 这么简单的横向扩展。

3. 对于 f/b/s Redis，不要使用任何 redis 集群。较新版本的 Logstash 可以在内部进行 Redis 负载平衡。Redis 输出支持插件配置中的 Redis 主机列表，并且即将在输入端添加支持以匹配它。在此期间，您可以在索引器/消费者端使用多个 Redis 输入定义。

4. 我无法回答这个问题，只能说听起来您正在尝试使用单个（可能功能不足的主机）做很多事情。

任何好的扩展过程都始于将并置的组件分解为不同的系统。我在任何地方都没有看到您的配置要点，但在过滤器中存在 Logstash“瓶颈”的地方。根据您正在执行的转换数量，它可能会对 Logstash 进程的内存使用产生影响。

Logstash 的工作原理很像乐高积木。您可以使用 2x4 积木或使用两个 2x2 积木来完成相同的任务。除了logstash，使用较小的砖块实际上比使用一块大砖块更坚固。

我们通常给出的一些一般建议是：

• 从边缘尽可能快地发送日志如果您可以使用纯网络传输而不是写入磁盘，那很好，但不是必需的。Logstash 是基于 JVM 的，这有好有坏。使用替代托运人。我写了一个基于 python 的（https://github.com/lusis/logstash-shipper），但我建议人们改用 Beaver （https://github.com/josegonzalez/beaver）。

• 以需要尽可能少过滤的格式（json 或最佳 json-event 格式）生成日志 这并不总是可行的。我写了一个 log4j appender 来做到这一点（https://github.com/lusis/zmq-appender）并最终将模式布局分解到它自己的仓库中（https://github.com/lusis/log4j-jsonevent-layout）。这意味着我不必在 logstash 中对这些日志进行任何过滤。我只是将输入类型设置为“json-event”

对于 apache，您可以尝试这种方法：http : //cookbook.logstash.net/recipes/apache-json-logs/

• 将事情分解成多个组件 在我所做的关于 logstash 的每一次演讲中，我都将它描述为一个 unix 管道。您可以根据需要制作任意长或短的管道。您可以通过水平转移职责来扩展 logstash。这可能意味着延长管道，但我们并不是在谈论任何与延迟开销相关的统计数据。如果您对网络有更好的控制权（即不在 EC2 上），您可以使用标准流量隔离做一些惊人的事情。

另请注意，logstash 邮件列表非常活跃，因此您应该始终从那里开始。清理和要点你的配置，因为这是最好的起点。

有些公司（如 Sonian）将 ElasticSearch 扩展到 PB 级别，有些公司（如 Mailchimp 和 Dreamhost）也将 Logstash 扩展到疯狂级别。可以办到。