☰

扩展 Logstash (使用 redis/elasticsearch)

tag-icon • tag-icon redis elasticsearch logstash oom-killer
扩展 Logstash (使用 redis/elasticsearch)

在由超过 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-killer 杀死了 redis-server，这意味着日志堆积在正在运送东西的服务器的内存中。不知何故意味着 apache 陷入了困境。（坦白说，我不知道它是怎么回事，我只是假设它正在跟踪日志）。

以下是我对事件进展的看法：

  1. 我们的流量突然激增。
  2. 生成了大量的日志。
  3. 这些都堆积在 Redis 中，因为 logstash/elasticsearch 似乎每秒只能处理 300-400 个新事件。
  4. Redis 已经完全被填满，以至于 OOM-killer 会毫无意义地将其消灭。
  5. Redis 停止接受新项目。
  6. 项目现在开始在远程主机端堆积。
  7. 一切顺利坚果。Apache 停止接受请求。（为什么？）。

问题如下：

  1. 为什么只要有什么东西拖着它的日志，apache 就会发疯。是不是拖着它的东西阻止了 apache 写入？

  2. 有没有合理的方法可以让 elasticsearch 更快/更好/更有弹性？

  3. 有没有一种合理的方法可以让 redis 具有弹性，并且不会因为 OOM 而死掉

  4. 是我设置的方式有什么根本缺陷吗，还是每个人都有这个问题？

- 编辑 -

@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

答案1

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

  1. Apache 崩溃可能是 logstash 进程出现故障的副作用。我暂时把这个放在一边。

  2. 使 ES f/b/s 成为现实的明智方法是添加更多 ES 节点。真的就是这么简单。它们甚至可以根据网络拓扑自动发现彼此。在这个行业工作了 17 年后，我从未见过像 ElasticSearch 一样易于水平扩展的东西。

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

  4. 我无法回答这个问题，只能说这听起来像是你试图用一个（可能是动力不足的）主机做太多事情。

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

Logstash 的工作原理与乐高积木非常相似。您可以使用 2x4 积木，也可以使用两块 2x2 积木来完成相同的任务。但在 Logstash 中，使用较小的积木实际上比使用一块大积木更坚固。

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

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

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

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

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

相关内容