web-dev-qa-db-ja.com

一元化Javaロギング

問題のシステムにはサーバーが1つしかないため、分散ソフトウェア(Javaで記述)のロギングに関する懸念を一元化する方法を探しています。これは非常に簡単です。ただし、特定のサーバーのインスタンスが将来実行される可能性が非常に高いことを念頭に置いてください(これを必要とするアプリケーションが増える予定です)。Logging-Serverのようなものが必要になります。受信ログを処理し、サポートチームがアクセスできるようにします。

現在の状況では、いくつかのJavaアプリケーションがlog4jを使用して、データをローカルファイルに書き込みます。そのため、クライアントで問題が発生した場合、サポートチームはログを要求する必要があります。 t常に簡単で、多くの時間がかかります。サーバー障害の場合、とにかくリモートアクセスがあるため、診断の問題はそれほど大きくありませんが、それでも、Logging-Serverを介してすべてを監視することは非常に理にかなっています。

「集中ログ」に関する質問を調べていると、別の 質問 (実際には(この場合)使用可能な回答がある唯一の質問です。問題は、すべてのアプリケーションが(内の)閉じた環境で実行されていることです。 1つのネットワーク)およびセキュリティガイドラインでは、内部ソフトウェアに関するものが環境ネットワークから出ることは許可されていません。

また、どのように implement そのようなLogging-Serverになるかについての素晴らしい記事を見つけました。この記事は2001年に書かれたので、誰かがこの特定の問題をすでに解決しているのではないかと思いました。しかし、私の検索結果は何も思いつきませんでした。

私の質問:サポートチームがアクセスできる集中型サーバーを使用して、ネットワークを介したロギングを処理するロギングフレームワークはありますか?

仕様:

  • 可用性
  • サーバーは私たちが実行する必要があります。
  • Java1.5との互換性
  • 異種ネットワークとの互換性。
  • ベストケース:プロトコルはHTTPを使用してログを送信します(ファイアウォールの問題を回避するため)
  • ベストケース:log4jまたはLogBack、または基本的にslf4jを実装するものを使用します

必須ではありませんが、持っていてよかったです

  • 認証とセキュリティはもちろん問題ですが、少なくともしばらくは後退する可能性があります(オープンソフトウェアの場合は、ニーズに合わせて拡張しますOT:常にプロジェクト)。
  • データマイニングと分析は、ソフトウェアを改善するのに非常に役立つものですが、外部アプリケーションである可能性もあります。

私の最悪のシナリオは、彼らがそのようなソフトウェアではないということです。その場合、おそらくこれを自分で実装します。しかし、そのようなクライアントサーバーアプリケーションがある場合は、この特に問題のある作業を行う必要がないことを非常に高く評価します。

前もって感謝します

更新: このソリューションは、いくつかのJava対応プラットフォームで実行する必要があります。 (ほとんどの場合、Windows、Linux、一部のHP Unix)

更新: さらに多くの調査を行った結果、実際に取得できるソリューションが見つかりました。 clusterlog.net (少なくとも2015年半ばからオフライン)は分散ソフトウェアのロギングサービスを提供し、log4jおよびlogback(slf4jと互換性があります)と互換性があります。これにより、アプリケーション全体ですべてのユーザーを分析できます。したがって、報告されたバグ(または報告されていないバグ)を非常に簡単に再現できます。また、重要なイベントを電子メールで通知し、同じオリジンのログが簡単にアクセスできる形式に要約されたレポートシステムを備えています。彼らはそれをほんの数日前にここに展開し(完璧でした)、それはうまく機能しています。

更新(2016):この質問はまだ多くのトラフィックを獲得していますが、私が参照したサイトはもう存在しません。

29

SocketAppenderでLog4jを使用できるため、サーバー部分をLogEvent処理として記述する必要があります。 http://logging.Apache.org/log4j/1.2/apidocs/org/Apache/log4j/net/SocketAppender.html を参照してください。

6
Arcadien

[〜#〜] nxlog [〜#〜]またはLogStashまたはGraylogs2

または

LogStash + ElasticSearch(+オプションでKibana)

例:

1) http://logstash.net/docs/1.3.3/tutorials/getting-started-simple

2) http://logstash.net/docs/1.3.3/tutorials/getting-started-centralized

5
hB0

Facebookからすぐに使用できるソリューションがあります Scribe-内部でApacheHadoopを使用しています。しかし、私が知っているほとんどの企業は、まだそのための社内システムを開発する傾向があります。私はそのような会社の1つで働いていて、約2年前にそこでログを扱っていました。 Hadoopも使用しました。私たちの場合、次の設定がありました。

  • ログ集約用の小さな専用マシンクラスターがありました。
  • ワーカーは本番サービスからログをマイニングし、個々の行を解析します。
  • 次に、レデューサーは必要なデータを集約し、レポートを作成します。

関心のあるレポートの数は少数で固定されていました。まれに、別の種類の分析を実行する場合は、そのための専用のレデューサーコードを追加し、オプションで古いログに対して実行します。

関心のある分析の種類を事前に決定できない場合は、ワーカーが作成した構造化データをHBaseまたはその他のNoSQLデータベースに保存することをお勧めします( ここでは、たとえば、MongoDBを使用します) )。そうすれば、生のログからデータを再集計する必要がなくなり、代わりにデータストアにクエリを実行できるようになります。

このようなロギング集計ソリューションに関する優れた記事がいくつかあります。たとえば、 Pigを使用して集計データをクエリするPig は、SQLのようなクエリで大規模なHadoopベースのデータセットをクエリできます。

LogFacesを見てください。仕様が満たされているようです。 http://www.moonlit-software.com/

  • 可用性(チェック)
  • サーバーは私たちが実行する必要があります。 (小切手)
  • Java 1.5の互換性(チェック)
  • 異種ネットワークとの互換性。 (小切手)
  • ベストケース:プロトコルはHTTPを使用してログを送信します(ファイアウォールの問題を回避するため)(ほとんどTCP/UDP)
  • ベストケース:log4jまたはLogBack、または基本的にslf4jを実装するものを使用します(チェック)
  • 認証(チェック)
  • データマイニングと分析(拡張APIを介して可能)
3
Frank