Logstashのスケーリング（redis / elasticsearchを使用）

12 Centos 5.8サーバー以上のクラスター上で、ネイティブのLogstash Shipperを使用してlogstashをデプロイしました。これ/var/log/*/*.logは中央のlogstashサーバーに送り返します。

出荷者としてrsyslogdを使用しようとしましたが、rsyslogdのImFileモジュールのバグにより、リモートエンドが応答しない場合、ログがメモリに蓄積されます。

現在、Redisをトランスポートメカニズムとして使用しているため、logstash01はこれらのログのVLANのIPにバインドされたローカルで実行されているredisを持っています。

そのため、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

その後、もの..出荷されたサーバ上のメモリに積み上げログ意味のRedisサーバ、殺さOOM-killerがそう何とか Apacheはツイストでその半ズボンを取得することを意味します。（率直に言って、どのように私はそれがわからない、私はちょうどそれがログを尾行していると仮定する）。

これは、イベントがどのように展開したかに関する私の理論です。

1. トラフィックが急増しました。
2. 膨大な量のログが生成されました。
3. これらはRedisに積み上げられ、logstash / elasticsearchは300〜400個の新しいイベント/秒しか処理できないようです。
4. RedisはOOM-killerが無意味に虐殺するまで完全にいっぱいになっていた。
5. Redisは新しいアイテムの受け入れを停止します。
6. アイテムは、リモートホスト側で積み上げられます。
7. すべてがおかしい。Apacheはリクエストの受け入れを停止します。（なぜ？）。

質問は次のとおりです。

8. ログの末尾に何かが残っているだけで、Apacheがおかしくなるのはなぜですか。apacheが書くことをブロックするのはそれが原因ですか？

9. elasticsearchをより速く/より良く/弾力的にする正しい方法はありますか？

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. Redisをf / b / sするには、Redisクラスタリングを使用しないでください。Logstashの新しいバージョンでは、Redisのロードバランシングを内部で実行できます。Redisの出力は、プラグイン構成でRedisホストのリストをサポートし、それに対応するために入力側にもサポートが追加されようとしています。その間、インデクサー/コンシューマー側で複数のRedis入力定義を使用できます。

4. 単一の（おそらくパワー不足のホスト）で多くのことを行おうとしているように聞こえるということ以外、これに答えることはできません。

優れたスケーリングプロセスは、併置されたコンポーネントを個別のシステムに分割することから始まります。logstashの「ボトルネック」がフィルターにある場所以外は、どこにも設定が表示されません。実行する変換の数によっては、Logstashプロセスのメモリ使用量に影響を与える可能性があります。

Logstashはレゴによく似ています。2x4ブリックを使用するか、2つの2x2ブリックを使用して同じタスクを実行できます。logstashの場合を除いて、1つの大きなレンガよりも小さなレンガを使用する方が実際には頑丈です。

私たちが通常行う一般的なアドバイスは次のとおりです。

• ログをできるだけ早くエッジから送信するディスクに書き込むのではなく、純粋なネットワークトランスポートを使用できる場合、それは便利ですが、必須ではありません。LogstashはJVMベースであり、良い意味と悪い意味があります。別の配送業者を使用します。pythonベースのもの（https://github.com/lusis/logstash-shipper）を作成しましたが、代わりにBeaverを使用することをお勧めします（https://github.com/josegonzalez/beaver）。

• できるだけフィルタリングを必要としない形式（jsonまたは最適なjson-event形式）でログを生成します。これは常に可能とは限りません。これを行うためにlog4jアペンダーを作成し（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メーリングリストは非常にアクティブであるため、常にそこから開始する必要があります。開始するのに最適な場所であるため、設定をサニタイズして要点を確認してください。

ElasticSearchをペタバイトレベルにスケーリングする企業（Sonianなど）と、Logstashを非常識なレベルにスケーリングする企業（MailchimpやDreamhostなど）があります。できます。