2016-05-24 5 views
0

当社のパイプライン: のVMware-のNetflow - > Logstash - >のRedis - > Logstash-インデクサ - > 3xElasticRedisの長さに成長

データ私が集まっていますが流れが来ていることを私はkibanaにnotiticed

  • 1時間経過した後、 2、3と続きました。
  • 'redis-cli llen netflow'を実行すると、非常に大きな数値が徐々に増加しています。
  • 'redis-cli INFOは80kbpsでかなり一定の入力を示し、1kbpsで出力します。私はこれらがほぼ等しいと思うでしょう。
  • すべてのノードのCPU負荷はごくわずかです。

    • を私はlogstash-インデクサがすべて3つの弾性のノードに送信されることを保証した:私が試した何

  • インデクサーで多くの追加のlogstashインスタンスを起動しました。ここで、redisは40のクライアントを表示します。

私は他に何を試みるべきかわかりません。

+0

個別のコンポーネントで負荷テストを行ったことがありますか?例えば。インデクサが分単位で処理できるログの数。 Logstash Shipperから1分に何本のログラインを取得しますか? – Chro

+0

これは基本的に、インデクサーがログを処理できるかどうかを入力することです。私の経験では、Redis自体は非常に高速で、通常は問題であるLogstashと関係しています。 – Chro

答えて

0

TLDR:3つのelasticsearchノードをすべてリブートし、人生は再び良いです。

私は誤ってelasticsearchを出力として無効にし、自分のnetflowをetherに送りました。 redisのキューサイズは分単位で0に減少しました。悲しいけれども、これは、それが弾性の検索であったことを証明した。

私は弾力的なインスタンスを見ました、そして、それらの間のコミュニケーションに何かが間違っているように見えました。 3人すべては、2/3がクラスタから脱落していて、クラスタピングに永久に反応することを示すログを示しました。私は、起こっていたと思うことは、書き込みは弾力性で受け入れられており、書き込みが正常に行われる前にしばらく振り回されているということです。

これらのすべてをリブートすると、正しく交渉され、必要に応じて書き込みが行われます。

関連する問題