本番環境でのユーザーアクションのログ記録のベストプラクティス

私は、ユーザーが次のような場合など、実稼働環境でさまざまなものをログに記録することを計画していました。

• ログイン、ログオフ
• プロフィールを変更
• アカウント設定を編集する
• パスワードを変更...など

これは生産環境で行うのに良い習慣ですか？また、これをすべて記録する良い方法は何ですか。現在、次のコードブロックを使用してログに記録しています。

public void LogMessageToFile(string msg)
        {

            System.IO.StreamWriter sw = System.IO.File.AppendText(
                GetTempPath() + @"MyLogFile.txt");
            try
            {
                string logLine = System.String.Format(
                    "{0:G}: {1}.", System.DateTime.Now, msg);
                sw.WriteLine(logLine);
            }
            finally
            {
                sw.Close();
            }
        }

これは本番でも大丈夫ですか？私のアプリケーションは非常に新しいので、数百万人のユーザーがすぐに何も期待することはなく、ウェブサイトでのアクションを追跡するためのベストプラクティスを探しています。

これは質問への直接的な答えではなく、それ以上の拡張です。

新しいアプリを起動するときは、ログイン、ログアウト、a **、すべてのスクラッチなど、ユーザーが行うすべてのログを記録することをお勧めします。Webベースの場合は、ヒートマップの使用を検討して、マウスの動作を把握してください。

70年代後半にXeroxでBravoXプロジェクトに参加したとき、ピクセルごとのマウスの動きを記録して、ユーザーがWYSIWYGエディターと呼ばれるこの奇妙なものをどのように使用するかを見つけました。昼食時にユーザーセッションの再生を視聴します。それは非常に有益でした。チャーリー・ブラウニングと呼ばれる使用パターンを発見しました。ユーザーはテキストを選択して斜体にします...次に元に戻します...次にやり直します...前後に、前後に。彼らはこのことを感情的なレベルで理解しようとしていたことがわかりました。そのため、（メモリが提供される場合、Greg Kusnikがコードを作成しました）この動作を正確にサポートするために、いくつかの特定の最適化を行いました。

録音がなければ、これをやろうとは思わなかったでしょう。

私があなたで、テキストファイルへの書き込みに固執している場合、log4netを使用して特定の「UserActions.log」ファイルにログインします。このように、通常のログ記録を混乱させません。log4net（またはその他のロギングフレームワーク）を使用することで、ホイールの再発明を回避し、ローリングファイルアペンダー、warn / error / debug / infoコード、バッチファイルの書き込みなどを活用できます。本番レベルのアプリケーション。

ただし、実際には、このすべての情報をデータベースに保存する方が良いでしょう。データベースを使用すると、データベースのソート、集計、統計の実行が簡単になります

ログファイルは、システムエラーをデバッグするための情報を取得するために使用されます。2.いたずらのためにユーザーアクティビティを調査する。3.視聴できない場合にシステムがどのように使用されるかを理解する。それを念頭に置いて：

• アプリケーションの起動時のログ環境（環境変数、その他の設定など）。これは、問題のデバッグに役立ちます。
• 各リクエストのユーザーとアクション（URLの別個の部分）を記録します。
• リクエストごとに全てのパラメータを記録しますEXCEPTパスワードの。私はログの各パラメータの周りに区切り文字を置くのが好きphone{(999)999-9999} email{aaa@aaa.com}です。パスワードが書かれてはいけませんどこでも、各ユーザーやハッシュの複数のラウンドのためのユニークな塩と片道、暗号的に安全なハッシュ関数で、データベースを除いて（脚注を参照してください）
• ログインするとき、ユーザーのIPアドレス、ユーザーID、名前、失敗したログインの数、ブラウザ、CookieセッションIDを記録し、パスワードは記録しないでください。
• ログインページおよびパスワード変更ページでパスワードを記録しないようにしてください。また、その機能がある場合は、秘密の質問または回答を記録しないでください。他のパスワードまたは暗号化キーは記録しないでください。これらのパラメーターのログに星印のようなものを書き込むと、このデータを抑制したことを覚えていることがわかります。
• 各リクエストを処理するのにかかる合計時間を記録するのが好きです： Done: 49ms
• セッション状態への変更を記録するのが好きです。これらはまれなはずです。
• 他の人が言ったように、ファイルへのロギング用の優れたロギングライブラリがありますが、データベースへのロギングについてはわかりません。
• ログを安全に保管してください。パスワードがなくても、個人情報（セーフハーバーを参照）に関するログデータの機密性に関する州法、連邦法、国際法があります。
• バックアップを取る。毎晩フルドライブバックアップにそれらを流し込む場合は、新しいサーバーにアップグレードする前に、必ず他の場所にバックアップすることを忘れないでください（これをどうやって学んだか聞かないでください）。

その他のヒント

脚注：誰かにログインするには、提供されたパスワードを同じハッシュアルゴリズムとそのユーザーの元のハッシュからソルトでハッシュします。提供されたパスワードのハッシュがデータベースに保存されているパスワードハッシュと一致する場合、それらはログインします。これが機能するためには、パスワードの文字セットを定義し、Unicode置換文字とセット外のその他の文字を禁止する必要があります。

データベースを使用するかどうかは指定しませんが、使用していてそのデータベースがSQL Serverである場合は、AutoAuditと呼ばれるものを追加して、データとのすべての対話を自動的に記録できます。監査するオブジェクトのみを指定してください。

しかし、とにかく、メンテナンスが悪夢になるので、トラッキングを手動でコーディングしようとはしません。

また、ログを記録するために、独自にロールバックしないで、Enterprise Library LoggingまたはLog4Netなどを使用してください。

ただ一般的なアドバイス。質問に直接関係しない場合があります。

ログを何に使用するかによって異なりますか？ほとんどのログは、エラーの原因となる操作を検出するために本番環境で使用されます。ユーザーのアクションを追跡するためにそれらを保持している場合、それはログの一部ではありません。それが製品のサーバー側の機能でなければなりません。これらのことは、その後の研究のためにデータベースに確実に入れる必要があります。しかし、サーバー側は「一部のテキストが空であるためエラーが発生しました」などのログを記録しますが、これは機能の一部ではありません。これらのことは、ファイルシステムに入れる必要があります。それらには以下の内容が必要です：-user_id、error_number、error_text、file_name、function_name、thread_id、system_date_time、およびその他のコンテキスト。

今、私はファイル内のログについてのみ話している。

1）それらを非同期に保ちます。I / O操作はコストがかかります。

2）関数よりもクラスとして設計します。将来の変更は簡単です。

3）可能であれば、シングルトンのままにします。シングルトンはマルチスレッドでは難しいため、適切に設計してください。

4）ロガーとロギーの相互作用をシンプルに保つことも良い。ほとんどの場合、実際のmessage_textよりmessage_numberを送信し、ロガーにその番号からメッセージを取得させます。これは、後で一般的なログ形式を変更する場合に役立ちます。

通常、ロガーおよびログに記録する必要があるものは、設計の一部である必要があります。すべての関連情報が適切に記録されるようにするために、設計に変更があった場合を見てきました。

Log4Netをお試しください。ファイルまたはデータベースにログインできます。ここだチュートリアル！

すべてのプロジェクトでLog4Netを使用しています。

ログファイルを使用すると、いくつかの問題が発生します。まず、複数のプロセスがファイルにアクセスしようとするとエラーが発生する場合があります。また、システムの実行中にファイルを循環または消去しようとすると、問題が発生する場合があります。それを回避する方法は、データベースを使用することです。

したがって、ステップ1はデータベーステーブルを作成することです。次のフィールドをお勧めします。
*ユーザーID
*アクション（ログオン、fooの削除など）
*説明テキスト（ここではnullを許可）
*タイムスタンプ

ステップ2、ユーザーID、アクション、および説明テキストの入力を含むストアドプロシージャを作成します。現在の時刻を使用してタイムスタンプを作成するだけです。

ステップ3、便利な共有ライブラリにロギングメソッドを記述して、どこにでも簡単に組み込むことができ、必要に応じてそのメソッドを呼び出す練習を始めます。ログに記録する内容を変更するために、ログレベルフラグロジックも必要になる場合があります。

ステップ4、メンテナンスルーチンを作成して、ログテーブルから古いメッセージを時々消去します。おそらく、Xより古い場合は削除し、定期的なDBメンテナンス（インデックスの再構築など）の一環として毎週実行します。

これを一度構築すると、他のプロジェクトに関係するコードを使用できるようになります。