web-dev-qa-db-ja.com

ログファイルの代わりにデータベースにログを記録する

すべてのRailsアプリケーションログをデータベース（MySQLまたはMongoDB）に、ログファイルに加えて、またはその代わりに送信することに興味があります。いくつかの理由があります。ログファイル分析については、既にGoogle Analyticsを使用していますが、Analyticsでは機能しないさまざまなことを実行したいと考えています。

さらに、ログを見て問題を「リアルタイム」で調査したいと思います。ログファイルをふるいにかけるのは退屈な方法であり、ログファイルで（簡単に）許可されているよりも優れた検索とフィルタリングを行いたいと思います。

最後に、サイトの訪問者の行動に近いものを調べることもよくあります。たとえば、サイト内のパスをトレースして、エラーが発生する前にユーザーが最後に閲覧していたページを確認できます。複数のアプリサーバーがある場合、個別のログファイルが原因でこれは非常に困難になります。すべてのデータがデータベース内にある場合、特定の訪問者の適切な一連のページを簡単に確認できます。 Syslogがこの特定の問題（単一のログファイル/リポジトリ）を解決する1つの方法であることは知っていますが、データベース検索に関連するより優れた検索機能と組み合わせたいと思います。

私はこれを解決するために人々が何を推奨するのかと思っています。データベースに直接ログを記録しますか、それともログファイルをDBにダンプしますか（ただし、ログファイル自体と同じように本質的にリアルタイムであるように、そのためのアプローチは何ですか？）

私が調べたもう1つのことは、すべての要求をログに記録する小さなラックフィルターを作成しているためです。これは通常のRailsロギングがダンプするすべての余分な出力（すべてのSQLとキャッシュヒットとミスの出力など））を逃しますが、私の目標の大部分を達成します、そして、システムの他のものを邪魔しないという利点を持っているようです。

とにかく、私は正しい答えを1つ探しているわけではありません。この同じ観点から他の人が何をしているのかについてのディスカッションと情報の詳細は探していません。

ruby-on-railsdatabaselogging
63
chrisrbailey

私の会社では、構造化されたトラフィック情報をMySQLログデータベースに直接記録しています。このデータベースは、ダウンストリームで別のデータベースに複製されます。すべての分析は、最終的なデータベース複製から実行されます。私たちのサイトはかなりのトラフィックを維持しています。これまでのところ、大きな問題はないようです。ただし、IT部門は現在のセットアップのスケーラビリティに関していくつかの懸念を高めており、ログ情報を「適切な」ログファイルにオフロードすることを提案しています。ログファイルは、同じダウンストリームデータベーステーブルに再度挿入されます。これは私にこの質問をもたらします。 :)

ログファイルとログデータベース（リレーショナル）の件名に関して私が見る長所と短所の一部を次に示します。

  • ログファイルは高速で信頼性が高く、スケーラブルです（少なくとも、Yahoo！はクリックトラッキング分析にログファイルを多用していると聞きました）。
  • ログファイルはsys-adminが維持するのが簡単です。
  • ログファイルにはほとんど何でも書き込むことができるため、非常に柔軟にできます。
  • ログファイルは、大量の解析を必要とし、データ抽出のためにマップ削減型のセットアップを必要とする可能性があります。
  • log-db構造はアプリケーションに非常に近く、一部の機能のターンアラウンドタイムが大幅に短縮されます。これは祝福と呪いのどちらでもかまいません。おそらく、最終的には高度に結合されたアプリケーションと分析コードベースが作成されるため、長期的に見れば呪いになるでしょう。
  • log-dbは更新と関連する挿入（あえて正規化）を実行できるため、log-filesは挿入のみであるため、log-dbはロギングノイズと冗長性を削減できます。
  • log-dbは、データベースパーティショニングやマルチログデータベース（ダウンストリームレプリケーションを介してデータを再結合）を使用する場合も、高速でスケーラブルです。

私の状況では、ログデータベースのストレステストが必要だと思います。このようにして、少なくとも私にはどれだけの余裕があるかがわかります。

最近、Redis、Tokyo Cabinet、MongoDBなどのキーバリュー/ドキュメントベースのデータベースを調べています。これらの高速挿入データベースは、永続性、高（書き込み）スループット、さまざまな程度のクエリ機能を提供するため、スイートスポットになる可能性があります。それらは、ログファイルのギグを介した解析およびマップ削減よりもはるかに簡単にデータ抽出プロセスを作成できます。

長期的には、堅牢な分析データウェアハウスを用意することが重要だと思います。分析データからアプリケーションデータを解放したり、その逆を行ったりすることは、大きなメリットになります。

最後に、ディスカッションを広げたい場合に備えて、StackOverflowに同様の、または密接に関連した多くの質問があることを指摘しておきます。

編集：

rsyslog は非常に興味深く見えます。 MySQLに直接書き込むことができます。 Rubyを使用している場合は、ロギングgemを確認する必要があります。マルチターゲットのロギング機能を提供します。本当に良い。

41
newtonapple

デフォルトのロギング動作を変更する場合は、すべてのRails loggerメソッドに応答するカスタムロガーオブジェクトを作成するだけです。

  • 追加
  • デバッグ、警告、エラー、情報、致命的、不明

http://github.com/Rails/rails/blob/9d7aae710384fb5f04129c35b86c5ea5fb9d83a9/activesupport/lib/active_support/buffered_logger.rb

yourロガーであるため、個人的なロジックの実装を決定できます。データベースに、いつでも標準出力に書き込むことができます。

次に、カスタマイズするすべての基本クラスのデフォルトのロガーを置き換えます。

ActiveRecord::Base.logger = YouLogger.new

Logger.rbという初期化ファイルを簡単に作成し、そこにすべてのカスタム構成を書き込むことができます。このように、ロガーはRails起動時にすぐに置き換えられます。

9
Simone Carletti

私はRails "exception logger" を使用して、サイトが本番モードのときにすべての問題をデータベースに記録します。問題をチェックします。訪問者がリアルタイムで何をしているかを確認したい場合は、 woopra を見てください。

3
atmorell

クリス、

ここでディマのコメントは重要だと思います。 （1）DBに（リアルタイムで）アクセスログがあることに満足していますか、（2）Rails /アプリ固有のロギングにもっと興味がありますか？

（1）の場合、Apache（少なくとも）を使用すると、パイプロギングを使用してデータベースにログを記録できます。

http://httpd.Apache.org/docs/1.3/logs.html#piped

私は、入力を待機しているバックグラウンドで実行されるプログラムを作成しました。このプログラムは、それを解析してPostgres DBに記録します。私のhttpd.confファイルは、CustomLogディレクティブを使用してこのプログラムにパイプします。

これは設定が比較的簡単で、DB内のログを分析できるという明らかな利点がすべて得られます。これは、特にユーザーがエラーの直前に行っていたことをトレースする場合に、私にとって非常にうまく機能します。ただし、SQLインジェクション、バッファオーバーフロー、およびロギングプログラムの他のセキュリティ問題から保護する必要があります。

（2）の場合、私はRails開発者ではないので、一般的なアプローチについてのみ話すことができます。環境変数、アプリケーションデータ、または非常に選択的な情報のビットをログに記録する場合は、正確なニーズによっては、条件付きロギングディレクティブとロギングプログラムでのフィルタリングを組み合わせて使用​​することもできます。

実際には、Rails固有のソリューションが必要か、より一般的なWebサーバー全体のソリューションが必要かが決まります。

1
Nishad

最近自分でデータベースにログを記録するミスを犯したので、これを実行してはいけない非常に良い理由を1つ提供できると思います。それはトランザクションです。トランザクションを開始し、トランザクションの過程で大量のものをログに記録し、最終的にエラー状態になるとしましょう。エラー状態をログに記録します。 ROLLBACK。突然、記録したすべてのものがなくなってしまい、何が起こったのか、またはなぜなのかわかりません。

そして特に、Railsのコンテキストでは、AASMのような本当に便利なライブラリがトランザクション内のすべてのものをラップするので、思いもよらなかった場所でトランザクションが発生する可能性があり、これも問題のデバッグを非常に困難にします。 。

私の場合、データベースに記録したのは、状況依存ログが必要だったからです。基本的に、特定のデータベースモデルに関連するすべてのログエントリを検索できる必要がありました。ただし、正しい答えは、ログデータに適した別の場所にログを配置することです（私の場合、たまたまクエリが可能です）。

1
Bob Aman

今まで返事がなかったので寄付します

私はrsylogへのプラグインを開発して、ログをファイルではなくmongodbに保存しました

rsyslog +プラグインからのソースコード全体がここにあります https://github.com/vpereira/rsyslogd-mongo

コンパイルするには、。/ configure --helpを実行して、利用可能なオプションを確認するだけです。

1
VP.