11

編集：問題が当初考えていたものではなかったため、タイトルを変更しました。事実、logstashの開始には1分以上かかりますが、これは「沈黙」と誤解される可能性があります...

logstashを実行しようとしているので、スタンドアロンインストールの公式サイトの指示に従いました：http：//logstash.net/docs/1.1.4/tutorials/getting-started-simple

基本的に、私はファイルを取得してからlogstash-1.1.4-monolithic.jar、非常に単純な構成ファイルを作成します:( example.conf）

input {
  stdin { type => "stdin-type"  }
}
output {
  stdout { debug_format => "json" }
}

しかし、logstashを実行すると、何も出力されません（STDINにランダムなテキストを入力していますが、応答がありません）：

# java -jar logstash-1.1.4-monolithic.jar agent -f example.conf
Test
toto
hey ??? Wakeup !!!
^C

（情報：Javaバージョンは正しいです）

# java -version
java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) Client VM (build 20.1-b02, mixed mode, sharing)

誰かが私が欠けているものを教えてもらえますか？

4

4 に答える 4

7

わかりました、私は自分で見つけました。

すべてがうまく機能していました。logstashの起動が非常に長いというだけです。私の（謙虚な）サーバーで60秒以上!! その巨大な開始時間に加えて、起動時に何も印刷されないという事実...

于 2012-11-07T22:07:46.863 に答える
1

この質問はまだ関係があるので、Java <8 で実行している場合、Linux (およびおそらく Solaris) で起動時間が非常に遅くなる理由の 1 つは、それらの Oracle JVM が原因であることを指摘しておきます。プラットフォームには、乱数を取得する場所に関するバグがあります。

/dev/urandom から乱数を取得するように指示されたとしても、取得しません (少なくとも、完全ではありませんか?)。/dev/./urandom から読み取る場合、これは同じですが、内部の壊れたロジックと一致しません。Java の起動がはるかに高速であることがわかります (特に J2EE ミドルウェア環境で)。

http://bugs.java.com/view_bug.do?bug_id=6521844

とはいえ、Java 8 を使用しても、logstash --configtest の起動は依然として非常に遅いです。これは、サーバー モードの 64 ビット JVM が起動時の最適化に多くの作業を行うためである可能性があります (それでも、JRuby は多くの Ruby 関連のことを行っていると思います)。

JRuby wiki には、その他の起動パフォーマンスの改善に関するドキュメント ( https://github.com/jruby/jruby/wiki/Improving-startup-time ) がありますが、logstash の取得を大幅に高速化するにはあまり当てはまりません。これにより、「logstash --configtest」の起動時間を約 8 秒に短縮できました。

[root@node-2 ~]# DEBUG=1 /opt/logstash/bin/logstash help
DEBUG: exec /opt/logstash/vendor/jruby/bin/jruby --1.9 -J-XX:+UseParNewGC -J-XX:+UseConcMarkSweepGC -J-Djava.awt.headless=true -J-XX:CMSInitiatingOccupancyFraction=75 -J-XX:+UseCMSInitiatingOccupancyOnly -J-XX:+HeapDumpOnOutOfMemoryError -J-Xmx1g -J-XX:HeapDumpPath=/opt/logstash/heapdump.hprof /opt/logstash/lib/bootstrap/environment.rb logstash/runner.rb help

実行するコマンドを実行し、すべての Java オプションを削除して、次のように置き換えます。--dev

[root@node-2 ~]# time /opt/logstash/vendor/jruby/bin/jruby /opt/logstash/lib/bootstrap/environment.rb logstash/runner.rb agent --configtest --config /etc/logstash/logstash-submission.conf 
Configuration OK

real    0m13.367s
user    0m12.966s
sys 0m0.321s
[root@node-2 ~]# time /opt/logstash/vendor/jruby/bin/jruby --dev /opt/logstash/lib/bootstrap/environment.rb logstash/runner.rb agent --configtest --config /etc/logstash/logstash-submission.conf 
Configuration OK

real    0m6.954s
user    0m6.629s
sys 0m0.286s

7 秒はまだ良くありませんが、14 秒程度よりはましです。7 秒というのは、コーヒーを 1 口飲むのに最適な時間です。そのため、コーヒーを飲み終える前に、テストの途中で終了するという厄介な問題を回避できます。B^)

単純なエイリアスは、すぐに役立つ場合があります。

alias logstash-configtest="/opt/logstash/vendor/jruby/bin/jruby --dev /opt/logstash/lib/bootstrap/environment.rb logstash/runner.rb agent --configtest"

USE_RUBY=1 フラグを付けて logstash を実行して、ベンダーの jruby の代わりに「ruby」を使用することもできると思います。通常、logstash を実行するためにこれを行うことはありませんが、必要に応じて --configtest に役立つ可能性があります。頻繁に使用します。-- さまざまな Ruby モジュールがすべて揃っていることを確認する必要があります。そうすれば、ネイティブの Ruby とベンダーが提供する jruby の間でバージョンのずれが発生することになります...しかし、Ruby 愛好家なら、このアイデアを取り入れて実行できるかもしれません。

于 2016-09-22T11:56:04.017 に答える
0

--debug ログをアクティブにして何が起こっているかを確認するだけで結論に飛びつくと思います + キットを使用してプロファイリングし、何が自分のものになるかを正確に確認することもできます。

于 2014-09-11T18:36:19.420 に答える