擴展 Logstash（使用 redis/elasticsearch）

在超過 12 個 centos 5.8 伺服器的集群上，我使用本機 logstash shipper 部署了 logstash，它發送/var/log/*/*.log回中央 logstash 伺服器。

我們嘗試使用 rsyslogd 作為shipper，但是由於 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 停止接受請求。（為什麼？）。

問題是這些：

8. 如果只是有一些東西拖尾了它的日誌，為什麼 apache 會發瘋。是它拖尾的東西阻止了apache寫作嗎？
9. 有沒有一種理智的方法可以使彈性搜尋更快/更好/更有彈性？
10. 有沒有一種理智的方法可以使 redis 有彈性並且不會因為 OOM 而死亡
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

您的文章在規格方面沒有描述太多（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）並最終將模式佈局分解為它自己的 repo （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 擴展到瘋狂的級別。可以辦到。

引用自：https://serverfault.com/questions/459303