それで、私たちは私の職場でのログインの通過について話し合いました、そして私はここにいるあなたたちの何人かがあなたのアプローチのいくつかのアイデアを私に与えることができるかどうか疑問に思いましたか？
通常、私たちのシナリオは、実際にはロギングがまったくなく、ほとんどの場合、.NETアプリ、winforms / WPFクライアントがWebサービスを介して通信するか、データベースに直接接続することです。
それで、本当の問題は、どこに、または何を記録するかということです。現時点では、ユーザーからエラーメッセージが報告されているため、ログの起動/シャットダウン、例外を想定しています...
Webサービスまたはdbへの呼び出しにそれを取りますか？ページが読み込まれますか？
ユーザーがその時点で何をしようとしていたかをどのようにして把握できますか？
ずっと行って、複数の試行/日にすべてをログに記録するか、必要なものだけをログに記録する方が良いですか（hddが安い場合）。
それはいくつかの質問だと思いますが、私はより大きな店で実際の慣行が何であるかについてもっと知りたいと思いました！
ロギングの鍵となるのは、適切な計画です。エンタープライズ ライブラリの例外とログ アプリケーション ブロック ( http://msdn.microsoft.com/en-us/library/cc467894.aspx )を調べることをお勧めします。少し学習曲線がありますが、非常にうまく機能します。現時点で私が好むアプローチは、4 つの優先度レベルを定義することです。4=未処理の例外 (イベント ログのエラー)、3=処理済みの例外 (イベント ログの警告)、2=Web サービス、データベース、メインフレーム システムなどの外部リソースへのアクセス (イベント ログの情報)、1=詳細/その他関心のある (イベント ログの情報)。
アプリケーション ブロックを使用すると、ログに記録する優先度を簡単に調整できます。したがって、開発中はすべてをログに記録しますが、本番環境で安定したシステムを取得すると、おそらくハンドルされていない例外とハンドルされた例外のみに関心があるでしょう。
更新: わかりやすくするために、winform/wpf アプリと Web サービスの両方にログインすることをお勧めします。Web シナリオでは、クライアントのエラーをアプリ サーバーに結び付けるのが難しいという問題が過去にありました。主な理由は、Web サービスを介したエラーが SOAP 例外としてラップされるためです。頭の中で思い出すことはできませんが、カスタム例外ハンドラー (エンタープライズ ライブラリの一部) を使用すると、アプリケーション サーバーからの例外の処理インスタンス ID などのデータを例外に追加できると思います。これにより、LogParser ( http://www.microsoft.com/downloads/details.aspx?FamilyID=890cd06b-abf8-4c25-91b2-f8d975cf8c07&displaylang=en )を使用して、クライアントの例外をアプリ ボックスに結び付けることが容易になります。 .
2 番目の更新: また、異なるイベントごとに個別のイベント ID を指定し、それをソース管理下のテキスト ファイルまたはスプレッドシートで追跡することも好みます。はい、それは面倒ですが、幸運にも本番環境でシステムを管理する IT チームがいる場合、IT チームはさまざまなイベントがさまざまなイベント ID を持つことを期待する傾向があることがわかります。
管理者である私は、トレースログを除くすべてのログについてイベントログ（できれば独自のログ、それ以外の場合はアプリケーションログ）にログを記録するアプリに本当に感謝しています。イベントログに記録することで、警告やエラーが重大な問題になる前に（対処できる問題である場合）、管理スタッフが警告やエラーを見つけて対処できる可能性が高くなります。トレースログを使用して問題のトラブルシューティングをさらに進めることができる開発者と協力します。
現在、カスタム.NETアプリをサポートする上での最大の問題点は、同じベンダーの8つの異なるアプリケーション（一部のコンソールアプリ、一部のWinForm、および一部のWeb）があることです。それらはいずれもイベントログに記録されず、すべて独自のカスタムログファイルがあります。ただし、すべてのWinFormとコンソールアプリでは、実行中はファイルを開いたままにするため、問題を監視することはできません。また、ログはすべてわずかに異なる方法で書き込まれるため、有用な情報を取得するには、ログを少し異なる方法で解析する必要があります。
これにより、アプリケーションの実際の状態ではなく、アプリケーションの外観（アクティブなポートで応答しているのか、プロセスワーキングセットが高くなりすぎているのかなど）を監視する必要があります。
デプロイ後にアプリケーションを保守し、使用できるログを提供する人々を考慮してください。ありがとう！
highscalability.com のこの投稿は、大規模な分散システムでのログ記録に関する優れた展望を提供します。(そして偶然にも、JoelOnSoftware の投稿に言及することから始まります)。
ずっと行って、複数の試行/日にわたってすべてをログに記録するか、必要なものだけをログに記録する方が良いですか (hdd が安価であることを考えると)。
ハードドライブが安価であるという事実は、いくつかの理由により、可能な限り詳細にログを記録する正当な理由にはなりません.ログ (ハードドライブはかなり遅い)。2 番目のポイント、およびより重要なポイント - テラバイトに相当するログから得られるものはほとんどありません。
いくつかのロギングはもちろん便利です。さまざまなレベルを持つことが唯一の方法です。たとえば、debug() info() は (構成またはコマンド ライン フラグで) 要求された場合にのみログに記録され、その後、おそらく warning() とerror() はログ ファイルに送信されます
私が書いたほとんどのもの (小さなスクリプト) については、通常、--verbose が設定されているかどうかを確認し、メッセージを出力する debug() 関数しかありません。 s" % (avar)) を必要に応じて実行し、戻ってデバッグの print() ステートメントをどこからでも削除することを心配する必要はありません。
Web アプリケーションの場合、通常、統計には Web サーバー ログとエラー ログのみを使用します。必要に応じて mod_rewrite のログなどを使用しますが、これを開発後に有効にしておくのはばかげています (各ページ要求で多くの行が作成されるため)。
アプリケーション自体にもよると思いますが、一般的に、大規模なアプリケーションでは、必要に応じてアクティブ化できる複数レベルのログを使用します。より小さなものについては、 --verbose フラグまたは同等のもの、Web アプリケーションについては、エラーをログに記録し、(ある程度) ヒットをログに記録します。
基本的に、「本番」ログでは使用できる情報のみをログに記録し、開発ログでは問題を修正するために必要な可能性のあるすべての情報をログに記録します。
簡単な答えとして、一連のカテゴリを考え出し、情報、警告、エラー、クリティカルなどの切り替え可能なログレベルを用意します。
次に、ログレベルを簡単に設定して、必要な詳細レベルを調整できるようにします。通常、設定ファイルでログレベルを設定し、アプリを停止して再起動します。
また、各レベルの意味を開発者に公開します。
編集：私はまた、定期的に、おそらく毎晩、ログファイルをローテーション、圧縮、アーカイブするシステムをセットアップします。
典型的なデスクトップアプリの場合、すべてを現在のセッションに保存し、過去nセッションまたは最大xサイズの情報メッセージを保存する可能性があります。
あなたのメッセージは整理されていると思います。4つのカテゴリを使用します。エラー、警告、情報、およびトレース。どのレベルで何が起こるかはまだわかっていません。ログファイルの解析に慣れてきたので、私は一般的に「もっとログを記録する」と言います。読みやすさを気にしないでください。ログファイルを使用する前に、ログファイルを少し処理する必要があります。
最後に、ライフタイムとストレージスペースでスプールの使用を制御できる優れたロギングフレームワークと、コードへの影響を最小限に抑える適切なAPIを見つけてください。理想的には、info("waaah")またはwarning("waah")を入力するだけで、APIがすべての凝ったタグ付けを行います。
みんなありがとう、たくさんの良い情報ですが、Martin は私にどのように進めるかについてもう少し詳しく教えてくれました。私は彼に答えを与えます。今はフロントから離れているように見えるので、いくつかのページの答えが落ちるでしょう.