質問

それで、私たちは私の職場でログインをパスすることについて話し合ったのですが、ここにいる皆さんの何人かがあなたのアプローチについていくつかのアイデアを私に教えてくれないかと思いました。

通常、私たちのシナリオではログはまったく行われず、ほとんどが .NET アプリ、winforms/WPF クライアントが Web サービスを介して通信するか、データベースに直接接続します。

それで、本当の問題は、どこに、あるいは何を記録するかということです。現時点では、ユーザーからエラー メッセージが報告されています。つまり、起動/シャットダウン、例外などのログが記録されていると考えられます。

Web サービスまたはデータベースへの呼び出しにそれを適用しますか?ページが読み込まれますか?

ユーザーが当時何をしようとしていたのかをどのように理解すればよいでしょうか?

わざわざ行って、複数の試行/日数にわたってすべてをログに記録する方が良いでしょうか、それとも (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 チームがいれば、彼らは異なるイベントには異なるイベント ID が存在することを期待する傾向があることがわかります。

他のヒント

管理者として、私はトレース ログ以外のすべてのログについてイベント ログ (できれば独自のログ、それ以外の場合はアプリケーション ログ) にログを記録するアプリを非常に高く評価しています。イベント ログに記録することで、管理スタッフが重大な問題になる前に (対処できる問題であれば) 警告やエラーを見つけて対処したり、管理スタッフに連絡したりできる可能性が大幅に高まります。開発者はトレース ログを使用して問題をさらにトラブルシューティングできます。

現在、カスタム .NET アプリをサポートする際の最大の問題点は、同じベンダーから 8 つの異なるアプリケーション (いくつかのコンソール アプリ、いくつかの winforms、いくつかの Web) が存在することです。いずれもイベント ログに記録されず、すべて独自のカスタム ログ ファイルがあります。ただし、すべての winform とコンソール アプリでは、実行中にファイルを開いたままにするため、問題がないか監視できません。また、ログはすべて少しずつ異なる方法で書かれているため、有用な情報を得るには少し異なる方法でログを解析する必要があります。

これにより、アプリケーションの実際の状態ではなく、アプリケーションの外観 (アクティブなポートで応答しているか、プロセスのワーキング セットが高くなりすぎているかなど) を監視する必要があります。

アプリケーションのデプロイ後にメンテナンスを行い、使用できるログを提供する担当者を考慮してください。ありがとう!

highscalability.com のこの投稿 は、大規模な分散システムでのロギングについての良い視点を提供します。(そして偶然にも、JoelOnSoftware の投稿に言及することから始まります)。

わざわざ行って、複数の試行/日数にわたってすべてをログに記録する方が良いでしょうか、それとも (HDD が安いことを考えると) 必要なものだけをログに記録する方が良いでしょうか。

ハードドライブが安いという事実は、いくつかの理由から、可能な限りすべてを詳細に記録する良い理由にはなりません。1 つは、非常に忙しいアプリケーションの場合、アプリケーションの速度を低下させて、ディスク書き込みのログ書き込みに影響を与えることは避けたいことです (ハードドライブは非常に遅いです)。2 番目の点、そしてより重要な点ですが、テラバイト相当のログから得られるものは実際にはほとんどありません。開発には便利ですが、数分以上保存する必要はありません。

もちろん、一部のロギングは便利ですが、さまざまなレベルを持つことがそれを実現する唯一の方法です。たとえば、debug() info() は (構成またはコマンドラインフラグで) 要求された場合にのみログに記録され、その後はおそらく warning() とerror() はログファイルに送信されます

私が書いたもののほとんど (小規模なスクリプト) では、通常、--verbose が設定されているかどうかを確認し、メッセージを出力する debug() 関数しかありません。そうすれば、 debug("some value:%s" % (avar)) を必要に応じて使用できるため、デバッグ用の print() ステートメントをどこからでも戻って削除することを心配する必要はありません。

Web アプリケーションの場合、私は通常、統計用に Web サーバーのログとエラー ログだけを使用します。私は必要に応じて mod_rewrite のログなどを使用しますが、開発を超えてこれを有効にしておくのは愚かです (ページリクエストごとに多くの行が作成されるため)。

アプリケーション自体にもよると思いますが、一般的に、大規模なアプリケーションでは、必要に応じてアクティブ化できる複数レベルのログが使用されます。小さなことについては、--verbose フラグまたは同等のもの、Web アプリケーションについては、エラーと (ある程度の) ログ ヒットをログに記録します。

基本的に、「運用」ログには使用できる情報のみが記録され、開発ログには問題を修正するために必要なすべての情報が記録されます。

一般的なデスクトップ アプリの場合、現在のセッションにすべてを保存し、おそらく過去 n セッションまたは最大 x サイズの情報メッセージを保存します。

あなたのメッセージは整理されていると思います。4 つのカテゴリを使用します。エラー、警告、情報、トレース。どのレベルに何が入るのかはまだ検討中です。ログ ファイルの解析に慣れてきたので、私は通常「もっとログを記録する」と言います。読みやすさを気にする必要はありません。ログ ファイルを使用するには、おそらく少し処理する必要があります。

最終的には、有効期間とストレージ領域に応じてスプールの使用を制御できる優れたロギング フレームワークと、コードへの影響を最小限に抑える適切な API を見つけます。理想的には、ただ入力するだけです info("waaah") または warning("waah") API がすべての高度なタグ付けを行ってくれます。

簡単な答えとしては、一連のカテゴリを考え出し、切り替え可能なログ レベルを持たせることです。情報、警告、エラー、重大など。

次に、ログ レベルを簡単に設定して、必要な詳細レベルを調整できるようにします。通常は、構成ファイルでログ レベルを設定し、アプリを停止して再起動します。

また、各レベルの意味を開発者に公開します。

編集:また、定期的に (場合によっては毎晩) ログ ファイルをローテーションし、圧縮し、アーカイブするシステムもセットアップします。

皆さん、ありがとう。たくさんの良い情報がありましたが、Martin が進め方についてもう少し詳しく教えてくれました。答えは彼に教えます。今、先頭から数ページ離れると答えが落ちてしまいそうなので。

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top